Tony – By having the new TLV 25 share the same set of sub-TLV codepoints with TLVs 22 etc., we did not have to define new sub-TLVs in order to advertise the link attributes (bandwidth, affinity, etc.) in TLV 25.
The only relationship between TLV 25 and TLV 22 lies in the “Parent L3 Neighbor Descriptor” – which includes the system-id/pseudo-node ID of the neighbor and (in the case of parallel links to the same neighbor) link endpoint identifiers. Les From: Tony Przygienda <[email protected]> Sent: Saturday, March 28, 2020 5:56 PM To: Les Ginsberg (ginsberg) <[email protected]> Cc: [email protected]; [email protected]; Dongjie (Jimmy) <[email protected]>; [email protected]; [email protected] Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network Still, taht reads utterly inconsistent to me ? This document adds the following new TLV to the IS-IS "TLV Codepoints Registry". Value: 25 Name: L2 Bundle Member Attributes The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include sub-TLV 25. On Sat, Mar 28, 2020 at 5:52 PM Tony Przygienda <[email protected]<mailto:[email protected]>> wrote: On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: Tony – There are a few misunderstandings in your post. Let me try to correct them. RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of TLVs 22,23,141,222,223. ack, forgot how l2-bundle was working in detail and on quick re-reading the language misled me since it talks about so many tlv & sub-tlv spaces. Ack, 25 is TLV. thanks for correction. Conceptually, it could have been defined as a sub-TLV, but because of the limited length of a TLV in IS-IS (255 octets) and the likelihood that advertising L2Bundle member attributes would consume a significant amount of space, we decided to use a new top-level TLV which references the associated L3 adjacency advertised in TLV 22. This means TLV22 advertisements are not impacted by the presence of TLV 25. In particular, the use of TLV 25 does not lead to multiple TLV 22 advertisements for the same adjacency, which we thought was a desirable outcome. ah, ok, now that makes sense, I didn't know the precise history here. To be orthogonal to previous MT-ID designs we should have a 225 (that's not taken AFAIR) with MTID just like we have a 222 for 22 ... not a large amount of work. I fully agree with you that an L2 bundle is a Layer 3 construct – and as such can be associated with any Layer 3 MTID in theory. However, when writing RFC 8668 we did not consider that there was a use case for topology specific link attributes. The current encoding does not support MTID. At this point, if we needed to extend RFC 8668 to support MTID we would need to allocate an additional TLV code point that included MTID – similar to the distinction between TLV 22 and TLV 222. ack, as I say 225 seems empty if need arises ;-) thanks for keeping me honest as usual ;-) --- tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
