I have the same consideration as Peter. Aijun Wang China Telecom
> On Mar 29, 2020, at 17:10, Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> > wrote: > > Hi Les, > >> On 29/03/2020 00:00, Les Ginsberg (ginsberg) 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. >> 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. >> The equivalent OSPF draft >> (https://tools.ietf.org/html/draft-ketant-lsr-ospf-l2bundles-01 ) takes the >> sub-TLV approach, but since OSPF has a 16 bit length for TLVs it does not >> face the same encoding issues. >> 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. > > RFC 8668 defines a TLV to advertise attributes of the individual L2 link > members. While the TLV itself can be considered as L3 construct (and have MT > associated with it), the individual L2 Bundle Member Links inside this TLV > are not L3 constructs IMHO and should never have a MTID associated with them. > The ask here is to advertise different MTID for each individual L2 bundle > member link. > > MTID is used to construct a topology. I do not see how a L2 bundle link > member would ever become part of the L3 topology. > > my 2c, > Peter > > >> 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. >> HTH >> Les >> *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of * Tony Przygienda >> *Sent:* Saturday, March 28, 2020 10:25 AM >> *To:* peng.shaofu@ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
