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]
