Chris - Please see inline.
> -----Original Message----- > From: Christian Hopps <[email protected]> > Sent: Wednesday, October 5, 2022 7:24 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Christian Hopps <[email protected]>; Robert Raszuk > <[email protected]>; Tony Li <[email protected]>; Henk Smit > <[email protected]>; [email protected] > Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv- > 01.txt > > > [as wg-member] > > I don't think what I've written is being read correctly. > > > 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. > > I didn't suggest this. My suggestion was that a router sending multiple-TLVs > needs to advertise that it does so, and receivers would interpret what they > received (is this second TLV a replacement or is it a concatenation?) based on > that advertisement. The proposal is for a "capability" in this case and that > could serve as this advertisement. > > I believe you would argue against this as it might impact networks that just > happen to be lucky and working right now. > [LES:] My argument is the presence/use of the "capability" does not result in a working network. As I have stated multiple times, MP-TLVs are sent because the configuration requires it - not just because an implementation is capable of doing so. Preventing advertisement of what is configured does not make the network healthy. It simply trades one problem for another. > If things would have been done correctly (i.e., documented) we also would > have had the option to add a sub-tlv to the TLVs in question that indicated > they were part of a set rather than replacements. > [LES:] So, this is a new proposal - not one that has been defined or even suggested anywhere to date. And I don’t support it. It deviates from how existing MP-TLV support that is already explicitly specified is done. It is inefficient in that it requires modification of the original TLV simply to advertise additional information about the same object - which means additional LSPs will need to be regenerated/flooded/processed. It would require a flag day (or knobs of some sort) because it would not work until all implementations supported the new sub-TLV. > > MP-TLVs are not sent just because an implementation supports them. > > They are sent because the current configuration requires them. > > The SW also has the option to alert the operator that their configuration is > not supported, and to revise it, rather than play loose with standards. > > The vendors who made these changes should have brought this to the IETF > as a draft that would have clear and deterministic transition mechanism (e.g., > wide metrics had a clear transition plan documented in it's RFC). > [LES:] Hmmm...RFC 5305 says in the Introduction: "Mechanisms and procedures to migrate to the new TLVs are not discussed in this document." What are you looking at? > I'm suggesting that the most important thing to come now is to make clear > what operators need to do to have a deterministic functional network. It > doesn't have to be the way I suggested, but we have to get there somehow. > [LES:] If there was a way to do this I would be interested. Nothing proposed thus far does this. Les > Thanks, > Chris. > [as wg-member] > > > "Les Ginsberg (ginsberg)" <[email protected]> writes: > > > Chris - > > > > > > > > Inline. > > > > > > > >> -----Original Message----- > > > >> From: Christian Hopps <[email protected]> > > > >> Sent: Monday, October 3, 2022 5:52 PM > > > >> To: Les Ginsberg (ginsberg) <[email protected]> > > > >> Cc: Christian Hopps <[email protected]>; Robert Raszuk > > > >> <[email protected]>; Tony Li <[email protected]>; Henk Smit > > > >> <[email protected]>; [email protected] > > > >> Subject: Re: [Lsr] New Version Notification for > > draft-pkaneria-lsr-multi-tlv- > > > >> 01.txt > > > >> > > > >> > > > >> [As wg-member] --- inline... > > > >> > > > >> "Les Ginsberg (ginsberg)" <[email protected]> writes: > > > >> > > > >> > Chris - > > > >> > > > > >> >> -----Original Message----- > > > >> > > > > >> >> From: Christian Hopps <[email protected]> > > > >> >> Sent: Monday, October 3, 2022 8:37 AM > > > >> >> To: Les Ginsberg (ginsberg) <[email protected]> > > > >> >> Cc: Robert Raszuk <[email protected]>; Tony Li <[email protected] > >>; Henk > > > >> Smit > > > >> >> <[email protected]>; [email protected] > > > >> >> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
