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]> wrote: > > > On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg) < > [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
