Chris - An example of what I refer to as "Do Not Apply" is "2 IIS Neighbors". This is the old style (AKA narrow metric) neighbor advertisement which has a fixed format and does not support sub-TLVs. It is impossible to advertise information about the same neighbor in multiple TLVs (unless you just want to be redundant - which I would consider a bug outside of transient conditions where a TLV moves from one LSP to another). The discussion of "multi-part" simply has no meaning for this TLV.
Calling this "implicit single-part TLVs" isn’t as attractive to me. It would seem to require a definition of what a "single-part TLV" is - whereas saying "NA" just indicates "multi-part" isn't applicable and requires no further explanation. But I won’t argue the point as long as we have a common understanding. The significant issue at the moment is that such TLVs are currently marked as "Explicit multi-part TLV allowed" in the spreadsheet and this is wrong. Les > -----Original Message----- > From: Christian Hopps <cho...@chopps.org> > Sent: Thursday, October 6, 2022 1:56 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Christian Hopps <cho...@chopps.org>; Peter Psenak (ppsenak) > <ppse...@cisco.com>; Tony Li <tony...@tony.li>; Robert Raszuk > <rob...@raszuk.net>; Henk Smit <henk.i...@xs4all.nl>; lsr@ietf.org > Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv- > 01.txt > > > "Les Ginsberg (ginsberg)" <ginsberg=40cisco....@dmarc.ietf.org> writes: > > > > > With this in mind, Tony (as I have commented to you privately) your > > table needs to be revised as there are some TLVs to which > > “multi-part” simply doesn’t apply. > > Those are what I believe we should refer to as "implicit single-part TLVs", > TLVS that it would never make sense to do multi-part for some reason. And > we probably want to define what those reasons are. It isn't necessarily just > the lack of keying info. An unordered, unkeyed list of things (e.g., protocols > supported) has no keying info, but could be sent multi-part and still make > sense. > > I think the tricky types are the "implicit multi-part TLVs" i.e., the ones > like > Extended Reachability TLV, that were not defined to be sent multi-part but > could conceivably be advertised that way (and apparently already are but > some subset of implementations out there). > > Tony I think you may have interpreted these differently? > > Thanks, > Chris. > > > > > > > > > > Les > > > > > > > >> -----Original Message----- > > > >> From: Christian Hopps <cho...@chopps.org> > > > >> Sent: Thursday, October 6, 2022 9:34 AM > > > >> To: Peter Psenak (ppsenak) <ppse...@cisco.com> > > > >> Cc: Tony Li <tony...@tony.li>; Les Ginsberg (ginsberg) > > <ginsb...@cisco.com>; > > > >> Christian Hopps <cho...@chopps.org>; Robert Raszuk > > > >> <rob...@raszuk.net>; Henk Smit <henk.i...@xs4all.nl>; lsr@ietf.org > > > >> Subject: Re: [Lsr] New Version Notification for > > draft-pkaneria-lsr-multi-tlv- > > > >> 01.txt > > > >> > > > >> > > > >> Peter Psenak <ppse...@cisco.com> writes: > > > >> > > > >> > Tony, Les, > > > >> > > > > >> > I believe we can all agree that we do not want to change the > > behavior of > > > >> > existing implementations that support MP-TLVs based on the > > > >> advertisements of the > > > >> > MP-capability from other routers - it would break existing > > networks. Even > > > >> the > > > >> > text in the MP-TLV draft does not suggest that to be the case. > > > >> > > > >> Are people not looking at the spreadsheet Tony put together? > > > >> > > > >> Which implicit multi-part TLVs are these "existing implementations" > > > >> advertising that keep getting referred to? Please let's work with > > real data -- > > > >> the spreadsheet shows a grand total of *0* TLVs that could fall in > > this > > > >> category. > > > >> > > > >> Thanks, > > > >> Chris. > > > >> > > > >> > I find the discussion about advertising supported capabilities > > for > > > >> management > > > >> > purposes in IGPs interesting, but not specific, nor directly > > related to the > > > >> > MP-TLV draft. Keeping the two separate would make a lot of sense. > > > >> > > > > >> > > > > >> > my 2c, > > > >> > Peter > > > >> > > > > >> > > > > >> > > > > >> > On 05/10/2022 22:18, Tony Li wrote: > > > >> >> Les, > > > >> >> > > > >> >>> On Oct 5, 2022, at 1:14 PM, Les Ginsberg (ginsberg) > > > >> >>> <ginsberg=40cisco....@dmarc.ietf.org > > > >> >>> <mailto:ginsberg=40cisco....@dmarc.ietf.org>> wrote: > > > >> >>> > > > >> >>> */[LES:] It is clear that we have different opinions on this – > > and there are > > > >> >>> multiple folks on both sides of this discussion./* > > > >> >>> */What I would hope we can agree on is to separate the > > discussion of > > > >> adding > > > >> >>> advertisement of “feature supported” from the MP-TLV draft by > > writing > > > >> a > > > >> >>> separate draft on this proposal./* > > > >> >>> */This would allow the two pieces of work to progress > > independently – > > > >> as they > > > >> >>> should./* > > > >> >>> *//* > > > >> >>> */This makes sense to me since the proposal to advertise > > feature > > > >> support is > > > >> >>> clearly not limited to MP-TLV and has no bearing on how MP-TLVs > > are > > > >> >>> encoded./* > > > >> >>> *//* > > > >> >>> */Can we agree on this?/* > > > >> >> Sorry, I’m not on board with this. The two functions would end > > up > > > >> >> disconnected, all the way to the field. > > > >> >> T > > > >> >> > > > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
