Gentlebeings, The spreadsheet is NOT documenting implementations. It’s documenting what I could find in the relevant specifications.
Tony > On Oct 6, 2022, at 9:51 AM, Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> > wrote: > > Chris, > > On 06/10/2022 18:34, Christian Hopps wrote: >> 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. > > then the spreadsheet is incorrect. > > I know of implementation that can send and receive Multi part TLVs for > IPv4/IPv6 (MT) IP Reach, (MT) Extended IS reachability and IS-IS Router > CAPABILITY TLV to start with. > > thanks, > Peter >> 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
