Subject: Re: [OSPF] OSPF Digest, Vol 126, Issue 40

From: Tony Przygienda <[email-masked]>
Date: Wed, 24 Aug 2016 15:57:18 -0700

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-masked]> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: Dave Katz <[email-masked]>
> To: "Acee Lindem (acee)" <[email-masked]>
> Cc: "Zhangxudong (zhangxudong, VRP)" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> 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.
> ...
>