Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> writes:
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.
Do you know all of the implementations, and all of those that don't? If we could publish that list then we presumably could explore more simple solutions. :) People keep talking about breaking deployed networks, but that assumes there are functional networks with implicit MP-TLVs in them. I am not sure I accept the assertion that these networks are truly functional. AFAICT these networks are *lucky* to be working. There's no document to point at, there's no bit to look at, there's literally nothing to help an operator or their routers know if all the routers correctly receive and process these implicit MP-TLVs. These networks are one network change (even as small as an interface up or down event) away from failing, or may even be failing already but not yet in a noticeable way. This is the case regardless of what type of bit or functionality this document provides. So while looking for a solution here, I think less weight should be placed on these "lucky networks". I'm not saying we should intentionally break them, but they should also not count as "fully-functional" either. Thanks, Chris. [as wg-member]
thanks, PeterThanks, 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
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
