Tony – Thanx for the prompt response.
Please see inline. From: Tony Przygienda <[email protected]> Sent: Tuesday, June 25, 2024 6:44 AM To: Les Ginsberg (ginsberg) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [Lsr] Comments on draft-ietf-lsr-distoptflood-04 Les, thanks for reading the draft. To start, I see no technical objections or suggestions from your side I could address. [LES:] Please see my original point #1 below. And what you ask for/claim/object to is WG chair/AD scope AFAIU so I just keep the answer short as WG participant from my side. [LES:] I considered asking the WG chairs to “enforce” the original scope of the draft, but I was/am hoping that we can have a friendly conversation and reach consensus without asking for “the police”. First, dynamic-flooding draft you mention is experimental work and I don’t know how it is structured or what it contains even plays in this discussion here except addressing somewhat similar problem. Both drafts are obviously independent experiments per the draft/rfc tracks and further, I did not see any kind of “scope restriction” on the adoption call on either and neither is the new version of distopflood doing something completely unrelated to the previous versions (footnote: as matter of gratuity we included considerations allowing to deploy it in presence of dynamic-flooding). [LES:] As a WG member, I read the early versions of the draft. The content was limited to definition of the flooding algorithm. That is what I endorsed when I supported adoption of the draft. This is primarily what is Section 2 of both the older versions and latest version of the draft. In V4 you introduced definition of a new control mechanism for the actual enablement of the algorithm in Section 1 (a section heavily rewritten from V3) and the introduction of new IANA requirements (though you neglect to mention in the IANA section the new code point you define in Section 1.4). I never anticipated this as in scope for the draft when I voted for WG adoption – nor do I find it logical to do so (See my Point #1 below). So you now have at least one input as regards scope. Please do not ignore it. Second, in case people on the list still wonder; this draft lives/is necessary because of extensive customer input and experience as to desired/undesirable operation properties of a solution for flood reduction [LES:] I have never questioned the usefulness of the proposed algorithm. 1/ distoptflood does not precondition any centralised instance that can due to bugs/misconfiguration/network changes affect behavior of lots of nodes, i.e. has no blast radius beyond a single node (or more precisely, blast radius that an algorithm creates at most as explained in the draft) 2/ distoptflood does not need any configuration (at least for the default/example algorithm given) 3/ In distoptflood different algorithms can be introduced/changed/mixed node by node rather than generating flag days due to a centralised instance configuration [LES:] Points 1,2,3 are talking about the merits of the new mechanism for controlling enablement. This is a discussion worth having – but not in the context of a draft whose sole purpose should be the definition of the algorithm (i.e., Section 2). I am happy to comment on your new proposal when/if you properly present it to the WG in a separate draft. 4/ Introduced example/default algorithm does not only reduce but also balance and is based on a long deployed/understood MANET style work [LES:] Now you are talking about the merits of the algorithm. On this I agree and this is why I have supported this work up to now. As to “I want this draft and another draft and another split draft” I consider it your personal preference and nothing else for the moment. I judge the current draft giving a clear example of a example/default algorithm with a framework allowing to plug in new algorithms easily far more practical than multiple split RFCs that need to be cobbled together to have actually something that is operationally significant. [LES:] Clearly, the control mechanism (whether that defined in dynamic-flooding or what you have defined in revised Section 1) is independent of the algorithm(s) which may be enabled using the control mechanism. That is compelling reason to separate discussion of the two. Les thanks --- tony On Tue, Jun 25, 2024 at 9:40 AM Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: In the past, I have supported the WG adoption and progression of this draft, which, prior to V4, has confined itself to defining a flooding algorithm designed to greatly reduce redundant flooding in highly meshed topologies. V4 of the draft, in addition to defining the optimized flooding algorithm, has introduced a new infrastructure to control what optimized flooding algorithms are in use in a given network. This is an alternative to the control mechanism defined in https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/ While discussion of an alternative to the control mechanism defined by the dynamic-flooding draft is certainly a topic appropriate for the LSR WG to consider, coupling this with the definition of a specific algorithm is highly inappropriate for multiple reasons. 1)Any control mechanism, whether that defined in the dynamic flooding draft or an alternative proposal, is logically independent from the algorithms which might be deployed using the control mechanism. Indeed, even disptflood-04 allows that the algorithm defined in the draft could be enabled using the control mechanism defined by the dynamic-flooding draft. It therefore is inappropriate for the control mechanism and a specific algorithm to be coupled into a single draft. (NOTE that the dynamic-flooding draft confined itself to only defining the control mechanism.) 2)Adoption of the distoptflood draft was approved by the WG based on the scope of the work being definition of an optimized flooding algorithm. The WG never approved adoption of the definition an alternative optimized flooding control mechanism. Introducing definition of a new control mechanism into the existing draft expands the scope of the draft well beyond that which was approved by the WG adoption. As I stated above, discussion of an alternative control mechanism for enabling optimized flooding algorithms is an appropriate topic for the WG to consider, but the authors of distoptflood have usurped the WG process by introducing this major change in scope without providing the WG an opportunity to consider the additional work. I call upon the authors of draft-ietf-lsr-distoptflood-04 to restore the original scope of the draft to defining the optimized flooding algorithm by removing discussion of the alternative control mechanism. If the authors wish to propose an alternative control mechanism for deploying optimized flooding algorithms, I encourage them to do so by writing a new draft whose scope is confined to the definition of the new control mechanism. Thanx. Les _______________________________________________ Lsr mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
