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

Tony Przygienda <tonysietf@gmail.com> Wed, 24 August 2016 22:58 UTC

MIME-Version: 1.0
In-Reply-To: <mailman.600.1472070107.3902.ospf@ietf.org>
References: <mailman.600.1472070107.3902.ospf@ietf.org>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Wed, 24 Aug 2016 15:57:18 -0700
Message-ID: <CA+wi2hOibgT0Sv+a+OKf868CXvoLjs-VMKxHph+npxzaCbgKWw@mail.gmail.com>
To: ospf@ietf.org
Content-Type: multipart/alternative; boundary="001a11446d6271608e053ad93696"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/TdPZtPciJujCtIMECH3mwqRB9dI>
Subject: Re: [OSPF] OSPF Digest, Vol 126, Issue 40
Precedence: list

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, <ospf-request@ietf.org> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: Dave Katz <dkatz@juniper.net>
> To: "Acee Lindem (acee)" <acee@cisco.com>
> Cc: "Zhangxudong (zhangxudong, VRP)" <zhangxudong@huawei.com>, "
> ospf@ietf.org" <ospf@ietf.org>, "lizhenqiang@chinamobile.com" <
> lizhenqiang@chinamobile.com>
> 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.
> ...
>

Re: [OSPF] OSPF Digest, Vol 126, Issue 40 Tony Przygienda