Tony,
On 04/11/2024 20:01, Tony Przygienda wrote:
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.
the need for "leaderless operation" is something that WG should decide
about. I appreciate the "extensive discussions with customers having
large ISIS networks", but the protocol changes are made based on the WG
consensus. All we are asking for is the standard procedure to be followed.
thanks,
Peter
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]> 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]
