Les, I'm responding tersely on behalf of the authors the current -07 version split of the architecture part into a personal draft you find published per the WG input and is further based on extensive discussions with customers having large ISIS networks and being keenly interested in this draft as possible next improvement to deploy. The operational section summarizes the requirements to be met for successful introduction into their nets, especially the need for limited blast radius in case of misconfiguration/defects/version changes and consequently, necessary leaderless operation.
I hope some of those customers will step in here and voice support the -07 version as reality of solution that they consider meeting their requirements and deployment considerations rest inline with bits more details and to be taken more as my personal answer ---- On Thu, Oct 24, 2024 at 2:43 AM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > I have reviewed the latest update to this draft. > > > > Unfortunately, the new revision does not address the comments/concerns > expressed both at IETF 120 and on the mailing list. > > > > I do not know if the concerns of some WG members were not made clear to > the authors – or if the authors intentionally chose not to address the > concerns. > > > > In the hopes it was the former, let me restate the concerns. > those concerns as stated are yours as participant in my eyes, WG input was summarized in the introduced consensus call as "split out the (multiple) algorithm/procedures considerations" > > In order to support alternate link state flooding algorithms, two > functionalities are required: > > > > 1)There needs to be a defined way to enable an alternate flooding algorithm > this is strictly speaking utterly optional in fact > > > Today, there is one (and only one) defined way to do that: > https://www.ietf.org/archive/id/draft-ietf-lsr-dynamic-flooding-18.html > > > > In the future, other methods may be defined. > > > > 2)There needs to be a standard definition of an alternate flooding > algorithm. > This is needed so that all nodes supporting a given alternate flooding > algorithm can interoperate. > this piece has been split out into the draft https://datatracker.ietf.org/doc/draft-lsr-prz-interop-flood-reduction-architecture/ per WG input and if adopted and decides to develop a signalling that fulfils the minimum blast radius requirement can be used to signal this draft. AFAIR you seemed to express support for this work to be adopted on the mike in the last IETF meeting > > > The two functionalities are logically independent i.e., > > > > The means of enablement is agnostic to what algorithm is being enabled. > > The algorithm is agnostic to what method is used to enable it. > > > > In January 2023, draft-ietf-lsr-distoptflood-00 was adopted by the WG. > > The content of the draft was confined to defining the algorithm. > there was not any such scope limitation during adoption call as far my memory carries despite your assertions here unless you can quote relevant emails. The solution was in fact around since Mar' 2017 as draft and it was only Jan' 2018 where the workgroup started to work on alternative with dynamic-flooding > > > In April of 2024, draft-ietf-lsr-distoptflood-04 was published – > significantly changing the scope of the draft. The draft was no longer > confined to simply defining the algorithm – it also introduced a new way to > enable use of the flooding algorithm. > > Subsequent versions, including V7 (the latest version) have maintained > that new scope. > -07 has only the algorithm and operational considerations section which contents customers consider of relevance to a deployable solution > > > It is the combination of the specification of both the algorithm and the > control mechanism in the same draft which some members of the WG (including > myself) find objectionable. > again, the documents have been split and your objections should be probably channeled in guiding the work on https://datatracker.ietf.org/doc/draft-lsr-prz-interop-flood-reduction-architecture/ or improving dynamic-flooding to meet the requirement of supporting leaderless algorithms. > It is also important to note that the current scope is not what was agreed > to when the draft was adopted as a WG document. > again, your claims seem to be based on your personal opinion of "what things were then" only Additionally, as to the rest, I utterly fail to see how you "assert the primacy of dynamic flooding draft" over anything, especially since "dynamic flooding" cannot fulfill the requirements set no matter whether some registry entries are taken or not. both drafts are experimental, and to say it again, dynamic flooding does not fulfill the minimal blast radius on misconfiguration/leader problems (if the RFC gets possibly updated to fulfill the requirement the discussion of using dynamic-flooding-bis signalling may make sense) so it may not even get deployed on networks disttopo aims at and generally, the interest of anyone of operational significance to "mix" or "upgrade" or anything with more than one algorithm seem to be limited for customers to academic interest at most (but it's just my take after talking to lots parties with networks that could benefit from reduction). so, -07 is the algorithm (with modifications based on tests and customer input) + necessary operational considerations to deploy it currently as it stands -- tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
