Les, thanks for reading the draft. To start, I see no technical objections or suggestions from your side I could address. 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.
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). 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 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 4/ Introduced example/default algorithm does not only reduce but also balance and is based on a long deployed/understood MANET style work 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. thanks --- tony On Tue, Jun 25, 2024 at 9:40 AM Les Ginsberg (ginsberg) <ginsberg= [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] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
