Hey Les, weekend over, quick inlines ;-) On Sat, Aug 17, 2024 at 8:17 PM Les Ginsberg (ginsberg) <[email protected]> wrote:
> Tony – > > > > The points you raise are worthy of discussion in the WG – but they are not > the subject of this thread. > agreed. I personally would further suggest actually that in the name of intellectual honesty and the spirit of delivering highest quality specifications in IETF those non-trivial operational considerations (which does affect a certain class of customers/networks) may be added as an according section, even if the dynamic flooding draft is experimental only and to avoid the 'stale election result in the network' to also possibly mandate SPT computation to the leader before deciding on the computation algorithm. > > > The subject of this thread is whether the draft should proceed in its > current form (definition of a flooding algorithm + definition of new > control procedures) or whether the two should be split into separate drafts. > > > > I do not see why definition of a flooding algorithm – which is > functionally independent of the mechanism used to enable the use of such an > algorithm – should be defined in the same document as a control mechanism. > Les, we had the exchange on the mike and nothing in my position/reasoning changed which I laid out repeatedly. To save people the time of rewatching the recording and dense discussion I allow myself to jolt down the salient points quickly in here (and BTW, in case I missed any of your arguments except the "I think those are somehow two things and I personally like them in two drafts" I am always willing to address those) on procedural grounds 1) there is nothing in an adoption call on drafts that limits its evolution (obviously as long the content is relevant to original work and emerging requirements). Just like dynamic flooding ended up evolving from centralized computation to add leader-distributed and then all kinds of mechanisms around it there are countless examples of drafts evolving to address the original problem properly and emerging new requirements to the solution. 2) there is nothing in terms of RFCs whether framework and solution using it are to be separated or not, operational has been bundled with drafts and split sometimes, applicability the same, requirements the same (in fact it's funny the dynamic flooding lists requirements, this has been chided out by a reviewer out of RIFT draft as inappropriate, go figure ;-) security is always bundled in (you could always argue why is security considerations not a separate draft and maybe it will become even that slowly given how ever more prominent the security angle is becoming year after year). There is as much evolving tradition as common sense here to guide the process IME but nothing else. so, IMO here I just see "you like this" (which I acknowledge) against "me like that" and consensus AFAIS being just a forced popularity vote w/o any objective procedural RFCs or technical considerations to guide us further. I can of course stand corrected, I'm not 100% expert on all procedural rfcs by any means. on technical/practical grounds though those bleed in procedural of course 1) yes, the requirement to provide leaderless mode for the algorithm is a very prominent discussion topic with large networks due to blast radius and scar tissue gathered, especially in recent years with ever higher scale. Hence, having tried to move dynamic flooding to support leaderless in discussions with you and not succeeding the solution still needed this aspect to be addressed and hence it was done. 2) it is far easier to address RFPs, have customer discussions, keep those focused when a document explains what the stuff is and how it's used/needs to be deployed. Sprinkling the goodies over multiple documents may seem somehow elegant but there are endless features to be deployed and customers IME prefer to solve problems quickly and not gorge themselves on libraries of hopefully eloquent English to figure out what they need/how it works/whether it even addresses any of their problems. 3) to keep things clear, any new algorithm that wants to run leaderless is by no means stopped from doing so in the current draft. It's a simple matter of referring to it and taking a codepoint. None of this will change in any substantial way whether there is one or five documents. Neither is it impossible to simply refer to the MANET algorithm and request a dynamic flooding draft codepoint to run it only when following a leader. and to repeat points worth repeating again The authors of disttopo do not advise or advocate the deployment of multiple algorithms on a network in any way due to likely very low benefits and involved operational complexity if nothing else. And again, more than happy to include the according section/text in the draft. I think we are all in sync here. Side benefit of node-by-node migration without flag day with leaderless is just that, best invoked if something stunningly better should emerge (given the heavy, heated discussions during MANET time on two remaining proposals [Acee will remember] and 20 years successful deployment of MANET something else showing up I personally consider about as likely as polar bear migration to Egypt ) or a crippling problem in deployed algorithm is found. In short words, best never to happen and very unlikely. As last, important point, _I personally_ would like to see _at least one_ algorithm well debugged to the point of deployment by the community being _mandated as compulsory implementation_ with room left to experimentation for other possible solutions should they ever come rather than rushing "frameworks" with lots of parallel algorithm suggestions without implementations or deployment. Be it the one, well known variation of proven MANET that is in disttopo now and still undergoing tweaking based on some smart customers input ;-) or anything competing that delivers the same quality of solution (balancing, fully distributed computation with minimal blast radius optimizing well and not plagued by Paxos type of problems). This is in my eyes easier done by keeping one document explaining how stuff works and can be deployed + mandating a default algorithm (and maybe second if it has other orthogonal desirable properties). A document mandating a "framework" but not mandating at least one specific algorithm as "must implement" is in my eyes not an "interoperable standard" in its strict meaning and customer experience. In fact, IGPs until very recently had basically one algorithm to get stuff done and no'one was advocating a plethora of "flooding algorithm solutions". Scale forces us on adding flood reduction. Fine, let us experiments bloom, however let us standardize on at least one well ground out and long proven to work well, deployed algorithm any customer can trivially deploy in simplest possible, lowest risk manner. Arguably in my eyes, this "one default size is always here and fits almost e'one and sometimes there are choices" has been to a good extent part of IGP success. In more practical terms, it is doing a customer looking for interoperable solutions no favor whatsoever if each and every vendor brings one or two different algorithms to the table and none of them can interlock though some people may argue it can generate wonderful job security. With leader one is stuck with "we can reduce only with this vendor because others don't have the algorithm", with leaderless one ends up in a theoretically possible scenario of running on each part of network a different algorithm, for practical purposes not a very palatable choice by any means even if it technically works correctly. I hope that clarifies and re-clarifies my stance better than just saying "well, I like it better the other, simpler way". If people think the "framework" can be rewritten into something simpler or just listed as a few rules an algorithm running leaderless must follow without any further explanation (as is entirely possible), I think it's a fine choice, though cryptic, as well. "Frameworks" are just scaffolding, in more generic terms they're easier to prove for correctness IMO but just a couple of astringent, prescriptive rules work fine as well to guarantee correct deployment and interoperability. Either way can swing too far of course as many drafts have done IME but we have no kings here to dictate one single way and ultimately consensus and common work generates the acceptable solutions. hope that clarifies my stance abundantly --- tony >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
