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
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr