I am in full agreement with Tony Li. I would also like to emphasize that this discussion is about separating definition of the algorithm and definition of an enablement method into separate drafts. It is NOT about the goodness/badness of “leaderless”. That discussion will take place if/when the related draft is written/published.
Les From: Tony Li <[email protected]> Sent: Wednesday, November 6, 2024 7:50 AM To: Srihari Sangli <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; [email protected]; Tony Przygienda <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07 Srihari, 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. They are not dependent. That much is very clear. You can operate an algorithm regardless of how you decide which algorithm to use. 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. I find it equally weird that you see the enablement somehow tied to the algorithm. 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. ? Perhaps you don't understand RFC 9667. Please re-read it. It is explicitly set up so that a centralized or distributed algorithm can be selected. 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. We do not change RFC 9667. It's done. Concrete poured. Ship has sailed. Your comments make zero sense. If you want 'leaderless' then you simply remove the current discussion from the algorithm draft and only support manual, ubiquitous configuration in your implementation. Arguing for a mechanism that doesn't work makes no sense whatsoever. Regards, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
