Subject: RE: [Isis-wg] IDRPI field

From: "Martin, Christian" <[email-masked]>
Date: Thu, 25 May 2000 17:10:29 -0400

Henk,

I posed a question regarding this a while back.  As you know, RFC1195
indicates that the IDRPI field could be used for adminstrative tagging, a la
OSPF admin tags when the type is set to 1, or an External AS LSA (LSA 6) for
a type 2.  From an operational perspective, this would be useful additional
information that could aid in things like redistribution filtering.  Given
all the TE work being done to extend the protocol, it should be a relatively
painless addition to the next rev.

Regards,
Chris

-----Original Message-----
From: Henk Smit [mailto:[email-masked]]
Sent: Wednesday, May 24, 2000 9:54 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Isis-wg] IDRPI field

  I have never seen it in any LSPs.
 I don't know of any vendor that has implemented this.
 In fact, I'm not even sure I know that TVL 131 is supposed to do. ;-)

          Henk.

> Does anyone know if the Inter-Domain Routing
> Protocol Information field (TLV 131) is used
> very much out in the field?
> 
> Are there other values for the Inter-Domain
> Information Type than (0, 1, and 2) in use?
> I did not see any reference to them in IANA.
> 
> For Type 1 (i.e., local) are there standard
> or common formats in use?
> 
> Thanks,
> 
> Tom Holland
> Alcatel
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
> 

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Henk Smit <[email-masked]>
Date: Fri, 26 May 2000 18:46:27 +0200 (MEST)

> a type 2.

  Because TLV 131 is not well documented, different people can use it
 for different things. And if their technology gets deployed, the customers
 run into interoperability problems.

>  From an operational perspective, this would be useful additional
> information that could aid in things like redistribution filtering.

  I agree it can be useful to have that kind of information available
 in the protocol. I'm not sure TLV 131 is the right place to do that.
 E.g. as far as I can see, TLV 131 stands on itself inside an LSP, and
 is not associated with any IP prefixes. How would you want to associate
 TLV 131 with particular IP prefixes ? By looking at the ordering of
 the TLVs inside an LSP ? For the obvious reasons, that doesn't seem
 a good idea to me. Can you let us know if you have a better idea about
 how to do that ?

  BTW, I tried to answer the question whether TLV 131 was deployed in
 the real world. I did not want to touch the subject of what it could
 be used for. That is another discussion.

>  Given all the TE work being done to extend the protocol, it should
> be a relatively painless addition to the next rev.

  Agreed.
 However, if you look at the traffic-eng draft, you see there is new
 TLV for IP prefixes, TLV 135. Besides having wider metrics, this
 new TLV also has the capability to store sub-TLVs associated with an
 IP prefix. We designed to have these sub-TLVs to store TE info.
 But also other useful info can be stored there, like redistribution
 information. Feel free to implement a solution and write a draft
 about it.

  Yeah, yeah, yeah, I know I'm supposed to submit the next version
 of draft-draft-ietf-isis-traffic-0x.txt. :-)   RSN ........

         Henk.