Hello Les, that makes me wonder which algorithms those are and who would really needs to use them and would suffer from only having the one from distoptflood…
@all: Being responsible for the network design of one of the large ISIS networks, I am with those who currently use mesh groups to tame the IGP flooding (as described in RFC9667). I would rather prefer an automatic mechanism that makes ISIS flooding robust and scalable. But I see no hurry in doing this. Our mesh groups work well since years. Esp. with operational experiences from the past 12 months which were related to other extensions of ISIS, RFC9667 scares me in more respect than just for leader election. Leader election sound like something that can break, and thus I’d rather avoid it. But also additional (sub)TLVs in the IGP, which even are necessary for a technology to work, feel like additional complexity you’d better avoid whenever possible. All in all I don’t think our change advisory board would ever agree to activate this IGP extension, if the whole benefit is to remove a few config lines and clean up the network design by something that worked well for several years. In other words: regardless of all theoretical benefits, RFC9667 would most likely not be used in our network. distoptflood however looks like a simpler approach, with just one optional TLV and just one algo that should serve all kinds of topology. This might have much better chances to be accepted in a multi-service carrier-grade network like ours. Thus I personally support draft-ietf-lsr-distoptflood-07 as it is. Best regards, Martin Von: Les Ginsberg (ginsberg) <[email protected]> Datum: Dienstag, 5. November 2024 um 16:00 An: Horneffer, Martin <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Betreff: RE: [Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07 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]<mailto:[email protected]>> Datum: Montag, 4. November 2024 um 20:30 An: Tony Przygienda <[email protected]<mailto:[email protected]>>, lsr <[email protected]<mailto:[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]<mailto:[email protected]>> Sent: Monday, November 4, 2024 11:01 AM To: lsr <[email protected]<mailto:[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) <[email protected]<mailto:[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]
