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)" <ginsberg=40cisco....@dmarc.ietf.org> 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 <ssangli=40juniper....@dmarc.ietf.org>
Sent: Monday, November 4, 2024 8:52 PM
To: je_dr...@yahoo.com; Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: Tony Przygienda <tonysi...@gmail.com>; lsr <lsr@ietf.org>
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: je_dr...@yahoo.com <je_drake=40yahoo....@dmarc.ietf.org>
Date: Monday, 4 November 2024 at 10:12 PM
To: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>
Cc: Tony Przygienda <tonysi...@gmail.com>, lsr <lsr@ietf.org>
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=
40cisco....@dmarc.ietf.org> 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 <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
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
