All, Speaking as an operator with large ISIS networks, having a leaderless option is a requirement. I have no preference whether it’s completed in one draft, or two, as long as the WG develops a leaderless option
Thanks, Luay (Verizon) On Tue, Nov 5, 2024, 4:02 PM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > Martin – > > > > There have previously been at least two other flooding algorithms proposed. > > In the future there may be more. > > > > We have anticipated this by creating a registry to assign unique algorithm > IDs: > https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#algorithm-type-computing-flooding-topology > > > > The point being: > > > > It is within the purview of the WG to standardize multiple algorithms. > > It is within the purview of the WG to standardize multiple methods of > enablement. > > > > The two functionalities are logically independent. > > > > Therefore, a single draft should not be used to define both an algorithm > and a method of enablement as it implies (or even worse establishes) a > relationship between the two which should not exist. > > > > Maybe you think that distoptflood is great and you want to use leaderless > enablement. > > Someone else may also think that distoptflood is great but wants to use > dynamic flooding to enable it. > > > > Why should we preclude such a choice? > > > > Les > > > > *From:* [email protected] <[email protected]> > *Sent:* Tuesday, November 5, 2024 5:40 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* [email protected]; [email protected] > *Subject:* AW: [Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07 > > > > Hello Les, > > > > why exactly have the enabling mechanism and the algorithm to be separated? > > Because that was the formal decision at the last meeting? > > > > Best regards, Martin > > > > *Von: *Les Ginsberg (ginsberg) <[email protected]> > *Datum: *Montag, 4. November 2024 um 20:30 > *An: *Tony Przygienda <[email protected]>, lsr <[email protected]> > *Betreff: *[Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07 > > Tony – > > > > Thanx for the response – but we are not in agreement. > > > > Section 2 of the latest version of the draft ( > https://www.ietf.org/archive/id/draft-ietf-lsr-distoptflood-07.html#section-2 > ) defines a new way of enabling use of an alternate flooding algorithm – > including a new codepoint to do so. > > Combining this with the definition of the flooding algorithm itself (in > Section 1) in the same draft is what I and others are objecting to. > > > > The text you have removed does nothing to address the concern raised. > > > > You argue below that you think you have good reasons why an enabling > mechanism other than the existing dynamic flooding (now RFC 9667) is > needed. > > That’s fine – please submit a draft which defines the new mechanism and > articulates its goodness so that the WG can consider this work. > > > > But please do not bundle the new enabling mechanism with the definition of > the algorithm. > > Any standardized algorithm (including distoptflood) can be enabled by > whatever mechanism(s) have been standardized and any draft which defines an > algorithm needs to remain agnostic to the enabling mechanism used. > > > > There are two ways you can respond to this: > > > > You can “stick to your guns” and try to proceed with the draft as is – in > which case at least some members of the WG will oppose progressing the > draft and you may end up with no progress at all. > > > > Or, you can make the separation I requested. In which case the > distoptflood algorithm is highly likely to progress (it already had broad > support before you added the additional scope) and the WG will also get a > chance to discuss the benefits of an alternate enabling mechanism – which > clearly is something you think is needed. > > > > I hope you choose the latter option. > > > > Les > > > > As an aside: the new draft you published ( > https://datatracker.ietf.org/doc/draft-lsr-prz-interop-flood-reduction-architecture/ > ) is not visible on the LSR WG page – possibly because of the name > (“draft-lsr-prz…” rather than “draft-prz-lsr…”). > > > > > > > > > > *From:* Tony Przygienda <[email protected]> > *Sent:* Monday, November 4, 2024 11:01 AM > *To:* lsr <[email protected]> > *Subject:* [Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07 > > > > 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] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
