And to fall back on specific example to reinforce my case and further food for thoughts observe that RFC8279 ended up as a total mixture or architecture, default standardized algorithm (since after that TE bitmask forwarding has been standardized and u-bier is in discussion due to new, emerging requirements), operational and security considerations and whatever else (deploy in mixed networks). Having just provided an architecture document for a pure BIER-only network with forwarding non-standardized strictly would have unlikely led to a currently deployed perfectly interoperable technology (as independent tests have shown) across vendors with serious investment in silicon.
-- tony On Mon, Aug 19, 2024 at 10:46 AM Tony Przygienda <[email protected]> wrote: > 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]
