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
