> where implementations decide when to apply configuration that has been accepted
where implementations decide when to apply *conditional* configuration that has been accepted Thx, R. On Wed, Oct 5, 2022 at 11:32 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > This has nothing to do with centralized vs distributed. > > > > You are advocating a model where implementations decide when to apply > configuration that has been accepted. This fundamentally changes the > authority from the management tool (be it manual or automated) to the > implementation. > > > > Les > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Wednesday, October 5, 2022 1:41 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* bruno.decra...@orange.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 > > > > Hi Les, > > > > Yes you have correctly understood my last point. > > > > So your take it to always put a human to operate/run the network. > Enable statically features and always manually map user traffic to such > features. > > > > That's the legacy (old fashioned) network model. Yes it works today > in a lot of networks, but is it to stay like this forever ? > > > > My view is that networks should operate by themselves (or as much > autonomously as possible). > > > > We can do it via management plane - centralized model > > or > > We can do it in the network itself - distributed model. > > > > What are the network's overall transit capabilities should be dynamically > signalled to applications too. > > > > It is surprising you are so much endorsing a centralized (oracle like) > approach. I am even more surprised you are against using IGP to signal > itself what it is capable of supporting to help today's operators. > > > > Best, > > R. > > > > > > > > > > On Wed, Oct 5, 2022 at 10:24 PM Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > > 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> > 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> *On Behalf Of * > bruno.decra...@orange.com > *Sent:* Wednesday, October 5, 2022 2:29 AM > *To:* Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; Tony > Li <tony...@tony.li>; Christian Hopps <cho...@chopps.org> > *Cc:* Robert Raszuk <rob...@raszuk.net>; Henk Smit <henk.i...@xs4all.nl>; > 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> > > […] > > > 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 *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 *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> *On Behalf Of *Les Ginsberg (ginsberg) > *Sent:* Tuesday, October 4, 2022 7:35 PM > *To:* Tony Li <tony...@tony.li> > *Cc:* Christian Hopps <cho...@chopps.org>; Robert Raszuk < > rob...@raszuk.net>; Henk Smit <henk.i...@xs4all.nl>; 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> *On Behalf Of *Tony Li > *Sent:* Tuesday, October 4, 2022 9:16 AM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Christian Hopps <cho...@chopps.org>; Robert Raszuk < > rob...@raszuk.net>; Henk Smit <henk.i...@xs4all.nl>; 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
