We've had few sides meeting on this, and reviews. We were asked to remove the "election stuff".
https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-distoptflood-06&url2=draft-ietf-lsr-distoptflood-07&difftype=--html At this point, I would like to turn the table to other operators (than me) and get feedback. Thanks Dan On 2024-11-05, 9:17 AM, "Christian Hopps" <[email protected] <mailto:[email protected]>> wrote: It was pretty clear during the last IETF meeting that the WG wanted to split newly added election stuff out of the adopted algorithm document and put it in a new document to be worked on separately. Thanks, Chris. [as wg-chair] "Les Ginsberg (ginsberg)" <[email protected] <mailto:[email protected]>> writes: > Srihari – > > > > Please read my post more carefully. > > > > I am not precluding a discussion of the leaderless option by the WG. > > If there are proponents in the WG that discussion should take place. > > > > 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. > > > > Are you arguing that distoptflood MUST NOT be enabled using dynamic > flooding (RFC 9667) just because you might prefer a different > enablement method? > > Are you arguing that a given enablement method can only be used to > enable certain algorithms? > > > > We should be able to easily agree on this separation without implying > support or opposition to a leaderless enablement option. > > > > Les > > > > From: Srihari Sangli <[email protected] > <mailto:[email protected]>> > Sent: Monday, November 4, 2024 8:52 PM > To: [email protected] <mailto:[email protected]>; Les Ginsberg (ginsberg) > <[email protected] <mailto:[email protected]>> > Cc: Tony Przygienda <[email protected] <mailto:[email protected]>>; lsr > <[email protected] <mailto:[email protected]>> > Subject: Re: [Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07 > > > > Dear WG, > > > > I have been heard customers bring up the need for leaderless option > and the distoptflood mechanism, primarily driven by the intent to > minimize the blast radius. I would like to see progress on this > method and document. > > > > Thanks & Regards, > > > > srihari… > > > > > > Juniper Business Use Only > > From: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Date: Monday, 4 November 2024 at 10:12 PM > To: Les Ginsberg (ginsberg) <[email protected] > <mailto:[email protected]>> > Cc: Tony Przygienda <[email protected] <mailto:[email protected]>>, lsr > <[email protected] <mailto:[email protected]>> > Subject: [Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07 > > [External Email. Be cautious of content] > > > > Hi, > > > > As usual, Les is correct and I completely agree with him. This draft > is a classic example of mission creep. > > > > John > > > > Sent from my iPhone > > > > On Nov 4, 2024, at 3:29 PM, Les Ginsberg (ginsberg) <ginsberg= > [email protected] <mailto:[email protected]>> wrote: > > 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) <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/ <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/ <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] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]> > > > > _______________________________________________ > Lsr mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ Lsr mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> ------------------------------------------------------------------------------ External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
