nanog mailing list archives

RE: Networking Pearl Harbor in the Making


From: Robert Bonomi <bonomi () mail r-bonomi com>
Date: Mon, 7 Nov 2005 14:04:35 -0600 (CST)


Subject: RE: Networking Pearl Harbor in the Making
Date: Mon, 7 Nov 2005 11:11:52 -0500
From: "Hannigan, Martin" <hannigan () verisign com>


On Monday 07 Nov 2005 3:42 pm, Hannigan, Martin wrote:

It's an argument for vendor diversity.

No it is an argument for code base diversity (or better 
software engineering).

Vendor diversity doesn't necessarily give you this, and you 
can get this with 
one vendor.

How so? Haven't we recently seen an across the board bug in
multiple version of $vendor code?

Excerpt from "Logic 101 -- Introductory Logical Reasoning":

   "Can" does not mean the same thing as "will". 

And, thus, the fact that one vendor has an across-the-board bug does _not_ 
mean that the same situation exists at =all= vendors..

The bug in multiple versions ov $vendor's code was directly attributable to
those 'multiple versions'  all being derived (at different points in time,
and/or for different deployment niches) from the same primary 'code base'.
Note: "code base", *singular*.  The problem existed in the core code, so,
naturally, it was present in all the varients of that *single* core.


Vendor diversity might be a good idea, but for other reasons.

Sure. There are more reasons than one to do it. I was specifically
pointing out that code diversity is a good one - and not forgetting
associated cost and economic impacts as mentioned in a later followup.

Vendor diversity does *not* _guarantee_ diversity in code-base.

You have to *explicitly* spec/check/test for code-base diversity, to ensure
that you have code-base diversity.

It is _possible_ to get code-base diversity with multiple purchases from a
 single manufacturer/vendor.
It is _possible_ to have a single common code-base among purchases from
  disparate manufacturers/vendors.

The "probability" of getting things with different code-bases -- *without*
*actually*checking*for*it* -- is higher if you purchase from multiple
manufacturers/vendors, rather than from a single one.

"Higher probability" != "guaranteed"   Hence the need to explicitly check,
if said diversity is a requirement.

 


Current thread: