Friendly reminder - still hoping that the draft authors will reply to this post.
Thanx.
Les
From: Les Ginsberg (ginsberg) <[email protected]>
Sent: Wednesday, October 23, 2024 6:42 PM
To: [email protected]; [email protected]
Subject: [Lsr] Comments on draft-ietf-lsr-distoptflood-07
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.
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
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.
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.
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.
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.
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.
What changes are being requested:
Return the scope of the draft to what was present prior to V4 i.e., to
discussing only the algorithm itself - not the means of enablement.
NOTE: Specification of an algorithm type value in the registry
(https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#algorithm-type-computing-flooding-topology
) defined by the dynamic flooding draft should be included - but this in no
way precludes the use of another method of enablement if/when such a method is
standardized.
If the authors are interested in defining an alternate enabling mechanism (as
they seem to be), they should write a separate draft which defines the new
enabling mechanism. That draft should be agnostic to what algorithm is being
enabled. This can go through the usual WG procedures. If this additional
enablement method were to progress, then all algorithms which have been (or
will be) standardized could be enabled using either dynamic flooding enablement
or the new enablement method.
I hope this is clear.
Les
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
