Chris -
Inline. > -----Original Message----- > From: Christian Hopps <cho...@chopps.org> > Sent: Monday, October 3, 2022 5:52 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Christian Hopps <cho...@chopps.org>; Robert Raszuk > <rob...@raszuk.net>; Tony Li <tony...@tony.li>; Henk Smit > <henk.i...@xs4all.nl>; lsr@ietf.org > Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv- > 01.txt > > > [As wg-member] --- inline... > > "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> > writes: > > > Chris - > > > >> -----Original Message----- > > > >> From: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> > >> Sent: Monday, October 3, 2022 8:37 AM > >> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> > >> Cc: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Tony Li > >> <tony...@tony.li<mailto:tony...@tony.li>>; Henk > Smit > >> <henk.i...@xs4all.nl<mailto:henk.i...@xs4all.nl>>; > >> lsr@ietf.org<mailto:lsr@ietf.org> > >> Subject: Re: [Lsr] New Version Notification for > >> draft-pkaneria-lsr-multi-tlv- > 01.txt > > > >> [As wg-member] > >> > >> I think the draft should include a table of all top level TLVS as rows and > >> for > >> columns we have > >> > >> - "Implicit Single TLV Only" (e.g., no key info) > >> - "Implicit Multi-TLV Only" > >> - "Explicit Single TLV Only" > >> - "Explicit Multi-TLV-Allowed" > >> > >> This draft then would *explicitly* cover the existing "implicit" cases and > we > >> have the table to point at to be precise about what we are talking about. > > > [LES:] I am not overly enthused about this - but I can see its > > usefulness, so I don’t oppose it. > > > > Probably best realized as an additional column in the existing IS-IS > > TLV Codepoints registry. > > > > But also realize that in some cases this extends to sub-TLVs (as one > > example "16 Application-Specific Link Attributes"). > > >> Now about the capability... There's an argument about including a router > >> capability and it seems to be that people have agreed that it should *not* > >> have any operation impact on the protocol. > > >> I think this is hasty. I would like to look at the above table to see what > TLVs > >> we are *exactly* talking about here (the implicit multi-tlv ones). People > have > >> said that implementations support multi-tlv use of these implicit cases > (e.g., > >> the draft talks about extended reachability). > >> > >> Really? > > > [LES:] Yes - really. 😊 > > >> I could easily believe its not common. I think we should get specific about > >> vendors and versions (and maybe specific TLVS?) if we are saying this has > >> been deployed and is in use. I've written a few IS-IS implementations and > I > >> don't think *any* of them supported multiple tlvs of, for example, > extended > >> reachability (seeing 2 of the same keyed info would be seen as one > replacing > >> the other, or a bug if in the same LSP segment). > > > [LES:] All of us who have "been around for a while" have worked on > > implementations that did not support MP-TLVs. Prior to new features > > (SR, TE Metric Extensions (RFC 8570), flex-algo, more extensive > > deployments of IPv6, etc.) there wasn't a need - at least for > > Neighbor/Prefix advertisements. > > > > But deployment requirements have evolved. We absolutely have cases > > today where a single TLV is insufficient space-wise for both neighbor > > and prefix advertisements and there are multiple implementations > > which already support this. > > > > If the WG wants to pursue an Implementation Report on this, I have no > > objection. > > > > BTW, the need for this should not surprise you. Discussion of this > > problem dates back at least to 2004: https://datatracker.ietf.org/doc > > /html/draft-shen-isis-extended-tlv-00 > > The need is not a surprise to me, no. > > >> Once we have this info I think a stronger case might be made for actually > >> having the router capability be used *operationally* (i.e., if you don't > >> see > the > >> capability advertised then that router in fact doesn't send multi-tlv tlvs > and > >> they should be seen as replacements of each other), and the argument > >> about it's inclusion goes away as it's then required. > > > [LES:] I don't agree with this argument - but I think the discussion > > triggered by posts from Gunter and Henk has already covered this well > > from both points of view, so I won’t repeat here. > > That discussion had to do with whether to include a bit that is for > management purposes only. What I am seeing here is a need for an > operationally relevant bit (i.e., determines how the protocol functions). > [LES:] In the discussions thus far (both on the list and discussions I have had with folks off the list) no one has suggested that the advertisement of MP-TLV support be used to determine what a given implementation sends on the wire. And there is good reason for that. If a node which supports MP-TLV were to introduce/withdraw MP-TLVs based on the advertised state of support for MP-TLVs by all nodes in the network, this would introduce flooding storms on the transitions. Not a good thing. Also (pardon the repetition - I have stated this before), such behavior would not result in a working network. MP-TLVs are not sent just because an implementation supports them. They are sent because the current configuration requires them. If an implementation suppresses MP-TLVs because it sees one or more nodes in the network isn’t advertising support, some of the information required to be advertised based on current configuration won't be advertised - which means the network isn’t working. There is no good way to utilize the advertisement to control what is sent/not sent. > AFAICT we now have implementations out there that are sending multiple > TLVs which are not documented to be sent that way, that historically were > not expected to be received that way, and then we have other > implementations that do not expect this new, convenient but rather loose > interpretation of the standards. Consider we have documents that explicitly > state that a TLV can be sent multiple times, it would be completely normal for > someone to then assume that when that isn't stated explicitly that multiple > versions of those TLV will not be sent. > [LES:] Well, implementations faced with deployment requirements where more than 255 bytes are required to be sent for a given IS Neighbor or a given prefix had to do “something” – and it was clear that MP-TLVs are the natural extension of the protocol. We did this with full awareness that if not all nodes in the network supported MP-TLVs for these TLVs the network would not work correctly. As with many aspects of scale, operators have to determine that the nodes they deploy can support the scale required in their deployment before they introduce the associated configuration. And based on customer cases I have worked on over the years, I know that operators would not be happy if we withdrew advertisements because a new node came up and did not have the necessary support. Instead of having only the new node be compromised, you would degrade the support of configured features in the entire network. Clearly a very undesirable consequence. > Thus the need for this document -- in some form. > > Having all routers work from the same link-state database is basic > requirement to the correct functioning of the decision process. > > Are we just lucky that things haven't really broken yet? How can an operator > even know what they've got deployed? Before this document there's > nothing to even refer to to document the possible different behaviors. > > If people want to argue that no operationally significant bit is needed then > how can an operator be expected to get this right? What is the exact process > they should follow to have interoperating routers? [LES:] This isn't a new problem for operators. There are many examples of extensions to the protocol which have been introduced which result in a broken network in cases of partial deployment. To list just a few: * Wide metrics * Cryptographic authentication * Support for extended LSP lifetime (> 1200 seconds) The consequences of sending MP-TLVs when not all routers support them are no more severe than the consequences of partial support for any of the above features. Operators absolutely have to know the capabilities of the routers in their network. But that is precisely what the management plane is for. That is what PICS documents are for. That is what vendor documentation is for. Folks may well complain that management tools are not as good as they need to be, but trying to compensate for this by adding management information into the protocol itself isn’t a good solution. Les > > Thanks, > Chris. > [as wg-member] > > > Les > > >> Thanks, > >> Chris. > >> [as wg-member]
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
