Les, Comments inline as “Srihari2”
Thanks & Regards, srihari… [cut] I am simply trying to break an illogical and undesirable dependency. Enablement methodologies are independent of the algorithms which may be enabled, and algorithms are independent of the method used to enable them. Srihari2> This is the disconnect. What if they are dependent ? Pls see my comment below. Are you arguing that distoptflood MUST NOT be enabled using dynamic flooding (RFC 9667) just because you might prefer a different enablement method? Srihari> I see RFC9667 is an experimental work. So, technically LSR and IETF should be open for alternate methods for enablement, isn’t it. [LES:] You did not answer my question – which is disappointing. And I have clearly stated that consideration of another method of enablement is an appropriate topic for the WG to consider – so why would you ask me this question at all? Srihari2> Les, let me provide more details about my argument - my interpretation of “experimental” is we need deployment/implementation feedback. Based on network need, new solution can be (1) algorithm (work with any enablement), (2) enablement method (work for any algorithm), (3) algorithm+enablement (works for certain combinations). Your argument is that, you don’t oppose new enablement or new algorithm, but just that it should not be together. Personally, I find it little weird. As a comparison - in IDR, when we had deployment feedback about entropy label which later evolved into NHC proposal, the document that was presented had NHC along with entropy label. The wg reviewed NHC+entropy label together. Are you arguing that a given enablement method can only be used to enable certain algorithms? Srihari> If that keep things simple and easy to deploy, why not ? [LES:] I don’t find that a model that requires a unique enablement method for every algorithm “simpler”. Maybe you think there will always be one – and only one – algorithm standardized. But given that there have already been other algorithms proposed and we already have a registry for assigning algorithm IDs in anticipation of having multiple standardized algorithms, such a viewpoint isn’t justified. We should be able to easily agree on this separation without implying support or opposition to a leaderless enablement option. Srihari> I’m coming from the angle of easier deployment, lesser operational headaches. Thanks. [LES:] This isn’t a response to my post. This is you saying you think “leaderless” is simpler. My post is simply asking that “leaderless” be defined/discussed in a separate draft so that we don’t introduce inappropriate dependencies between enablement methods and algorithms. Srihari2> Les, I was reacting to how RFC9667’s algorithm registry has been setup. Given that the document talks about leader-based algorithms, it forces only one option was my interpretation. So if customer feedback is about leaderless as it makes solution simple, we should enable that solution – this was my argument. Srihari2> I have a question for you, Les. How do we make RFC9667 to be leaderless. Today it supports central and area leader approaches. How do you differentiate new algorithm that works with “leader” mode and gets a codepoint vs a new algorithm that does not require leader. I think this may create confusion unless you have already divided codepoints into categories, I don’t see that in the document. [cut] Juniper Business Use Only
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
