Robert – Not certain I completely understand you – but I “think” what you are saying is that we could allow configuration independent of what nodes in the network currently support, but suppress advertisement/enabling until all nodes advertise support. Am I close??
If so, this is one of the aspects that adds complexity. And it still does not result in a working network. So, no thanks. Les From: Robert Raszuk <rob...@raszuk.net> Sent: Wednesday, October 5, 2022 12:40 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: bruno.decra...@orange.com; Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Tony Li <tony...@tony.li>; Christian Hopps <cho...@chopps.org>; Henk Smit <henk.i...@xs4all.nl>; lsr@ietf.org Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt Just to add and expand to your point Les ... The concept of "forward referencing" used in some OSes explicitly permit configuration of elements not even present on the box or in the system ahead of time. For example you can configure an interface which will be inserted later. Same for any network wide feature. However this means that activation of such network wide features can take place under dynamic conditions too. If "all nodes required" support feature X I can advertise it. (Let's assume that other nodes which do not require it will not crash). That means that having such dynamic capability may be actually pretty helpful. Thx, R. On Wed, Oct 5, 2022 at 9:33 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: Bruno – Thanx for commenting – I really want to hear from the operator community. In regards to using “functionality supported” advertisements to either issue warnings or possibly block/disable configuration changes…I think this sounds better in theory than it can be realized in practice. If you block config when not all nodes advertise support for “feature X”, what do you do with existing config which was accepted at a time when all nodes that are up/reachable did advertise the needed support, but now a new node comes up (or becomes reachable) and it does NOT advertise the support? What do you do on bootup when the saved config includes configuration that should not be accepted under the rules for “feature X”? Do implementations have to provide a knob to control whether configs should be rejected or just a warning issued? Do you think operators will now try to leverage the new “protection” they expect from implementations and feel free to relax testing on the assumption that a good implementation will prevent a “bad configuration” from being enabled? And what are the candidates for such functionality? In this thread we talk about MP-TLV support – but this is less than precise. What we are really talking about is MP-TLV support for specific TLVs. So this now requires per/TLV advertisement. And what else might be a good candidate? What about individual sub-TLV support e.g., for the different link attributes? If a node advertises a link attribute that not all nodes support then various forms of TE/flex-algo may not work. Do we then require each node to advertise every TLV it supports and every sub-TLV it supports? What about flag bits within a given TLV/sub-TLV? One response to this is to say “we will limit this to ‘important’ advertisements” – but how are we to agree on what is important and what isn’t? Do we have an operational definition of “important”? I think this quite easily leads to an explosion of advertisements and a great deal of complexity which returns very little. If an operator configures something it is because they need that in order for the network to meet the requirements of the given deployment. Blocking/disabling config might prevent some problems – but it won’t make the network functional. I am quite concerned that this is something that “sounds good” but in practice adds little value – yet places significant demands on implementations. Les From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Sent: Wednesday, October 5, 2022 2:29 AM To: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>>; Tony Li <tony...@tony.li<mailto:tony...@tony.li>>; Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> Cc: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; 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 I’ve not followed everything in details so I’ve been reluctant to comment, but nonetheless please find below a diverse set of comments. > From: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> […] > 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. > Thus the need for this document -- in some form. Thank you Chris. Definitely +1 To clarify, are we talking about: - different nodes in the flooding domain having a different understanding of the LSDB content - a (LS) protocol relying on all nodes in the flooding domain to have a consistent (view of the) LSDB (especially with FlexAlgo for which the number of (sub)TLV requiring a consistent view across the flooding domain has increased and may further increase) And a standardization group defining specifications to allow for interop? Sure, I’d be interested in an implementation report to at least learn about such (sub) TLV and those implementations. […] > From: Lsr lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> On Behalf Of Les > Ginsberg (ginsberg) > [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. Agreed. However, it’s not because this is not a new problem that this is not a problem. We don’t need to increase the problems and make things worse. And it’s not because this can be made to work (with extra work), that this can’t also fails. (and this does fail sometimes) […] > From: Lsr lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> On Behalf Of Les > Ginsberg (ginsberg) […] > Using the protocol to send what is best described as some subset of a PICS > means that we propose to use the IGP flooding mechanism to send static > information which the protocol itself cannot (and should not) use in its > operation. I’m not sure that I agree with “cannot (and should not) use in its operation”. If the correct understanding of MP TLV is required for correct operation, such information can be used by IS-IS to warn the network operator that IS-IS is not correctly working anymore. As of today, an operator may not be even aware of the problem. And a so-called “smart” implementation could even forbid a configuration change which would translate into sending a MP TLV not understood by all nodes. So on my side, I would rather welcome a continued discussion on this topic which seems important for network operations. Thank you, Regards, --Bruno Orange Restricted From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Les Ginsberg (ginsberg) Sent: Tuesday, October 4, 2022 7:35 PM To: Tony Li <tony...@tony.li<mailto:tony...@tony.li>> Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; 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 Tony – We don’t agree – but that isn’t news. Let me try to start a meaningful discussion. Using the protocol to send what is best described as some subset of a PICS means that we propose to use the IGP flooding mechanism to send static information which the protocol itself cannot (and should not) use in its operation. This consumes space, bandwidth, gets periodically refreshed unnecessarily, and now a complete copy of the information from every node resides on every router in the network when it is only needed by an “NMS”. It would be hard to come up with a better example of “IGP isn’t a dump truck” than this. If there is a belief that we can severely limit the amount of information that is sent/node, I’d have to say that I am skeptical. Once we allow this into the protocol, I don’t see any basis on which to separate what is allowed and what is disallowed. It would not be unreasonable for an operator to say that everything that is a candidate to be mentioned in a PICS is a legitimate candidate for being advertised using this mechanism. Which means the amount of information is likely to become very large – especially once it becomes the de facto way of providing protocol management information. The justification seems to be that we don’t have anything better – which represents a longstanding failure of the management plane. While I agree with you that management plane solutions are not adequate – not least because we can’t get the industry to converge on a single solution – this does not mean we should invest in the wrong solution. We would be better served spending time and effort working on the right solution - as difficult as that may be. If we despair of getting a management plane solution, my suggestion would be to use RFC 6823/6822 to define an IS-IS protocol management application that could support the advertisement of such information. This is technically straightforward to define/implement, easily extensible, and it separates the management information from the information used by the protocol. And because a separate topology can be used for the “management instance”, it would be possible to reduce the number of copies in the network. Thoughts?? Les From: Tony Li <tony1ath...@gmail.com<mailto:tony1ath...@gmail.com>> On Behalf Of Tony Li Sent: Tuesday, October 4, 2022 9:16 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; 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 Hi Les, 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. It is not a good solution. But it is the only practical solution available. At scale, we need automation. We have tried and failed (again) to get broad adoption of a management infrastructure. We continue to reject alternative approaches. The thought of someone keeping all of this in their heads is simply naive. We have already painted ourselves into this corner. There is no good way out. Tony _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
