What's the saying? When you start to build Byzantine security or Petri net libraries you ran out of real problems ;-)
On the other hand, 777 control software, DCs, BitCoin use tons of BFT these days. Though it's probably easier to run well-implemented protocols as Dave says rather than install yet-another-abandoned-github-attempt ;-) into your network and make the protocol spec eye-watering complex trying to protect against it. Not that I think the cost of building Quorums in IGPs would be viable unless you have some insane amount of memory & parallel cycles to burn ... -1 to adoption ... --- tony On Wed, Aug 24, 2016 at 1:21 PM, <[email protected]> wrote: > > > > ---------- Forwarded message ---------- > From: Dave Katz <[email protected]> > To: "Acee Lindem (acee)" <[email protected]> > Cc: "Zhangxudong (zhangxudong, VRP)" <[email protected]>, " > [email protected]" <[email protected]>, "[email protected]" < > [email protected]> > Date: Wed, 24 Aug 2016 20:21:19 +0000 > Subject: Re: [OSPF] Solicit feedbacks on > draft-dong-ospf-maxage-flush-problem-statement > Speaking as a long time implementor of OSPF, IS-IS, et al, I agree. While > making protocols as robust as we can is a good thing, there are rapidly > diminishing returns in trying to make protocol changes to help detect > one-off bugs, especially if the protocol is not friendly to changes and > extensions. The number of possible bugs is essentially infinite. > > I’ve seen a number of bugs in other implementations that have made it into > production implementations, especially as I have had a tendency to > “stretch” the specs in ways that are guaranteed to work so long as other > implementations are following the spec. These have been few and far > between, however. > > Classic example: the 30 minute “architectural constant” refresh time. > This is *not* an architectural constant (defined as “must be true or things > won’t work”); the refresh just needs to happen often enough to keep the > LSA from being maxaged anywhere. So I made a one-line change to change the > refresh time to 50 minutes, reducing the refresh load by 40% (not really > “scaling” but it was easy, cheap, and guaranteed to work properly <cough>.) > This was fine for several years until someone introduced a router from a > small, now long-dead vendor, at which point things started flapping > weirdly. Turns out that an engineer at said company got carried away > jittering timers, and jittered the LSA age timer by 25% (very very bad). > So the LSA maxage timeout would fire after a random interval between 45 and > 60 minutes. Of course, if you were refreshing at 30 minute intervals, > you’d never notice, but at 50 you get 1/3 of your LSAs being purged by said > broken router. I initially refused to change it, but then an engineer at a > Very Large Router Company made exactly the same mistake. Sigh. > ... >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
