Re: [arch-d] Centralization or diversity

Toerless Eckert <> Wed, 08 January 2020 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61C74120059 for <>; Wed, 8 Jan 2020 10:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XTqCDHHymOMZ for <>; Wed, 8 Jan 2020 10:28:22 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACC16120880 for <>; Wed, 8 Jan 2020 10:28:22 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id 0A6C854802F; Wed, 8 Jan 2020 19:28:17 +0100 (CET)
Received: by (Postfix, from userid 10463) id EB787440059; Wed, 8 Jan 2020 19:28:16 +0100 (CET)
Date: Wed, 8 Jan 2020 19:28:16 +0100
From: Toerless Eckert <>
Cc: Brian E Carpenter <>, Andrew Campling <>, "" <>
Message-ID: <>
References: <LO2P265MB0573A1353911BFDD554DE5C8C2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [arch-d] Centralization or diversity
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jan 2020 18:28:24 -0000

On Tue, Jan 07, 2020 at 01:35:45PM -0800, wrote:
> > It's not quite clear how to enforce this via the IETF, beyond the multiple interoperable implementations of RFC6410.
> The IETF has no police force, thankfully, so enforcement is out of question anyway.

Indeed. And i have little opinions about enforcement other than
"SEP - Somebody Else's Problem (not IETF)"

Nevertheless: I think it would help for IETF to have something like
"(protocol/solution/...) implementation compliance specifications"
that would better help for external parties to vet/measure
implementations/deployments against what the IETF envisions.

And where to go from vetting/measured merics, i don't care (yet).

> The good news, however, is that Murphy does have a police force and has demonstrated repeatedly that genetic diversity in a network is a Very Good Thing.

Give or take the absence of competition due to the huge capital
investment requirements.

> Several ISPs who have learned this lesson the hard way have dual planar networks where plane 1 is all vendor A and plane 2 is all vendor B.

*yawn*. Sorry, but coming from financal (services) networks, that had
this since the 1990th, what you are saying now is like saying
"Fred Flintstone now has upgraded to a color CRT TV".

Btw: To stick to my theme of identifyin single points of failures:
around 2010 or so, national financial service (in some unnamed country),
had actually two separate planes. But built a single management plane. I think
you can guess where this story goes. The fun part with the financial
services community is how they can immediately come up with all
type of financial loss number for every period of non-availability
of network services (in units of millions of dollars).

> Some others still have to learn this.  One of the good things that might come of this effort is to write this down.

One should also remember that the cost of dual-plane may be vastly
different based on the density and structure of the country and
underlying infra (fiber trunks, power supplies, etc..). Countries
like USA and china are a lot more interesting/challenging than the
typical european country.


> Tony

> _______________________________________________
> Architecture-discuss mailing list