Adrian - I appreciate your continued attention to the draft - but have to say I am not keen on your latest suggestion.
As has been highlighted throughout this discussion, MP-TLV introduces no encoding changes to any codepoint. Therefore, the question of "legitimacy" isn’t relevant. The rules for determining what is legitimate and what isn't haven’t changed. Also, we are not introducing "duplication". The only valid case where duplication can occur is as a transient i.e., where a given TLV moves from one LSP to another. Any other occurrence of duplication would be due to a bug in the implementation. This is true both when MP-TLV is in use and when it isn't. I am not sure what you are trying to clarify. I am open to adding the text I previously suggested: “Each TLV that is part of an MP-TLV MUST be parsable independent of other TLVs in the MP-TLV. Breaking of a single sub-TLV or other data unit across TLVs MUST NOT be done.” If you have wordsmithing suggestions on that, happy to listen. Les > -----Original Message----- > From: Adrian Farrel <[email protected]> > Sent: Friday, February 21, 2025 11:05 AM > To: Les Ginsberg (ginsberg) <[email protected]>; 'Tony Li' <[email protected]>; > 'Robert Raszuk' <[email protected]> > Cc: 'lsr' <[email protected]> > Subject: RE: [Lsr] Re: [Last-Call] 答复: Re: 【Can you concatenate several > pieces together without one "explicit key" to identify them belong to the same > segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 > > I've been pondering this for a while. > Les' pointer to 8918 is helpful. > > But I wonder whether the "key" to all this is the definition of "key". > AFAICS, this is the first document to use the term in the ISIS context (do I > have > that right?). For example, if we look at RFC 5305 we see a clear definition of > the fields that our section 3.2.1 lists, but the term key is not used. > > Section 3 *does* start with an explanation... > Some TLVs support advertisement of objects of a given type, where > each object is identified by a unique set of identifiers. In this > case the "key" which uniquely identifies a given object consists of > the set of identifiers. > > Could we make this *even* more clear? It seems fine to me, but we need to > make it clear to all readers. > > Perhaps... > > Some TLVs support advertisement of objects of a given type, where > each object is identified by a unique set of identifiers that we call a > "key". If the objects are advertised in separate instances of TLVs of > the same type, the key identifies the object and indicates that the > TLV is legitimate and not a duplicate. > > Just bringing rocks ☹ > > Cheers, > Adrian > > > > > -----Original Message----- > From: Les Ginsberg (ginsberg) <[email protected]> > Sent: 21 February 2025 16:28 > To: Tony Li <[email protected]>; Robert Raszuk <[email protected]> > Cc: lsr <[email protected]> > Subject: [Lsr] Re: [Last-Call] 答复: Re: 【Can you concatenate several pieces > together without one "explicit key" to identify them belong to the same > segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 > > Robert - > > I am certain that Tony and I are in complete agreement - but I found his > response a bit cryptic. > > So, to provide more context, RFC 8918 is relevant - particularly Section 3.3. > > HTH > > Les > > > > -----Original Message----- > > From: Tony Li <[email protected]> On Behalf Of Tony Li > > Sent: Friday, February 21, 2025 8:07 AM > > To: Robert Raszuk <[email protected]> > > Cc: Les Ginsberg (ginsberg) <[email protected]>; lsr <[email protected]> > > Subject: Re: [Lsr] [Last-Call] 答复: Re: 【Can you concatenate several pieces > > together without one "explicit key" to identify them belong to the same > > segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 > > > > > > Hi Robert, > > > > > If a peer happens not to recognize content of a sub-TLV within the first > > > or > N- > > th part of the multi part TLV what is the expected behaviour ... is it to > > stop > > parsing any subsequent content of given MP-TLV or skip unrecognized sub- > > TLV and keep trying to decode the rest of them if of course it can get the > length > > of it correctly and move to the next one ? > > > > > > The beauty of TLVs is that you don’t have to parse everything to make > > progress. > > > > So you do. > > > > T > > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
