Thus I personally support draft-ietf-lsr-distoptflood-07 as it is.
Best regards, Martin
Von: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Datum: Dienstag, 5. November 2024 um 16:00
An: Horneffer, Martin <martin.hornef...@telekom.de>
Cc: tonysi...@gmail.com <tonysi...@gmail.com>, lsr@ietf.org <lsr@ietf.org>
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:*martin.hornef...@telekom.de <martin.hornef...@telekom.de>
*Sent:* Tuesday, November 5, 2024 5:40 AM
*To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>
*Cc:* tonysi...@gmail.com; lsr@ietf.org
*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) <ginsberg=40cisco....@dmarc.ietf.org>
*Datum: *Montag, 4. November 2024 um 20:30
*An: *Tony Przygienda <tonysi...@gmail.com>, lsr <lsr@ietf.org>
*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 <tonysi...@gmail.com>
*Sent:* Monday, November 4, 2024 11:01 AM
*To:* lsr <lsr@ietf.org>
*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=40cisco....@dmarc.ietf.org> 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
