Hi Les, Your comments stay directly in odds with text from section 2 of the subject draft specifically:
The solution proposed in this draft pays particular attention to those realities and operational requirements. *It is designed to be deployable without initial configuration,* *allows node by node introduction and removal of the feature into the network*, balances the reduced flooding not only on a single or few trees but uses the information about the origin of the fragment to spread the load across whole topology. All of those properties are guaranteed to work while asserting minimal blast radius on introduction of the feature and also changes of any node or link. Deployment of this extension presents the same risk no matter the specific properties of the underlying topology. So either this text or your comments are incorrect. My personal preference is leaderless flooding optimization. And in my books it is a feature not a bug to have a single spec/draft/rfc for flooding optimization instead of cutting it into a jigsaw puzzle of documents which many people will have a hard time to put in order when troubleshooting broken networks. Thx, Robert On Thu, Oct 24, 2024 at 3:43 AM Les Ginsberg (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. > > > > 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] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
