[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. 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.
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). 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. Thanks, Chris. [as wg-member] "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes:
Chris - Inline.-----Original Message-----From: Christian Hopps <cho...@chopps.org>Sent: Monday, October 3, 2022 5:52 PMTo: 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.orgSubject: Re: [Lsr] New Version Notification fordraft-pkaneria-lsr-multi-tlv-01.txt[As wg-member] --- inline..."Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes:> Chris ->>> -----Original Message----->>> From: Christian Hopps <cho...@chopps.org>>> Sent: Monday, October 3, 2022 8:37 AM>> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>>> Cc: Robert Raszuk <rob...@raszuk.net>; Tony Li <tony...@tony.li ; HenkSmit>> <henk.i...@xs4all.nl>; lsr@ietf.org>> Subject: Re: [Lsr] New Version Notification fordraft-pkaneria-lsr-multi-tlv-01.txt>>> [As wg-member]>>>> I think the draft should include a table of all top level TLVSas 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 andwe>> have the table to point at to be precise about what we aretalking 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 existingIS-IS> TLV Codepoints registry.>> But also realize that in some cases this extends to sub-TLVs (asone> example "16 Application-Specific Link Attributes").>> Now about the capability... There's an argument about includinga router>> capability and it seems to be that people have agreed that itshould *not*>> have any operation impact on the protocol.>> I think this is hasty. I would like to look at the above tableto see whatTLVs>> we are *exactly* talking about here (the implicit multi-tlvones). Peoplehave>> said that implementations support multi-tlv use of theseimplicit cases(e.g.,>> the draft talks about extended reachability).>>>> Really?> [LES:] Yes - really. 😊>> I could easily believe its not common. I think we should getspecific about>> vendors and versions (and maybe specific TLVS?) if we are sayingthis has>> been deployed and is in use. I've written a few IS-ISimplementations andI>> don't think *any* of them supported multiple tlvs of, forexample,extended>> reachability (seeing 2 of the same keyed info would be seen asonereplacing>> the other, or a bug if in the same LSP segment).> [LES:] All of us who have "been around for a while" have workedon> implementations that did not support MP-TLVs. Prior to newfeatures> (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 havecases> today where a single TLV is insufficient space-wise for bothneighbor> and prefix advertisements and there are multiple implementations> which already support this.>> If the WG wants to pursue an Implementation Report on this, Ihave no> objection.>> BTW, the need for this should not surprise you. Discussion ofthis> problem dates back at least to 2004: https://datatracker.ietf.org/doc> /html/draft-shen-isis-extended-tlv-00The need is not a surprise to me, no.>> Once we have this info I think a stronger case might be made foractually>> having the router capability be used *operationally* (i.e., ifyou don't seethe>> capability advertised then that router in fact doesn't sendmulti-tlv tlvsand>> they should be seen as replacements of each other), and theargument>> about it's inclusion goes away as it's then required.> [LES:] I don't agree with this argument - but I think thediscussion> triggered by posts from Gunter and Henk has already covered thiswell> from both points of view, so I won’t repeat here.That discussion had to do with whether to include a bit that is formanagement purposes only. What I am seeing here is a need for anoperationally relevant bit (i.e., determines how the protocolfunctions).[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 sendingmultipleTLVs which are not documented to be sent that way, thathistorically werenot expected to be received that way, and then we have otherimplementations that do not expect this new, convenient but ratherlooseinterpretation of the standards. Consider we have documents thatexplicitlystate that a TLV can be sent multiple times, it would be completelynormal forsomeone to then assume that when that isn't stated explicitly thatmultipleversions 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 basicrequirement to the correct functioning of the decision process.Are we just lucky that things haven't really broken yet? How can anoperatoreven know what they've got deployed? Before this document there'snothing to even refer to to document the possible differentbehaviors.If people want to argue that no operationally significant bit isneeded thenhow can an operator be expected to get this right? What is theexact processthey 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. LesThanks,Chris.[as wg-member]> Les>> Thanks,>> Chris.>> [as wg-member]
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
