Sooo, Tony asked that feedback on the table be unicast for now (which is wise) - but I think there is one point that needs to be understood publicly - which has to do with what is the meaning of "MP-TLV".
As per https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.html#section-3 (emphasis added): “If a router advertises multiple TLV tuples with the same Type code in an IS-IS IIH packet or in the set of LSPs for a level with the same key value, they are considered a multi-part TLV (MP-TLV).” We are not talking here about cases where a particular TLV type (such as 135 Extended IP reachability) is sent multiple times where each instance of the TLV advertises a disjoint set of prefixes. That clearly is supported by all implementations today and is NOT what is meant by “Multi-part”. A Multi-part TLV (using the example of IP Extended Reachability) is where multiple TLVs are advertising information about the same prefix. If anyone is confused about this or disagrees with this, please speak up now. 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. 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<mailto: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
