Re: [arch-d] Centralization or diversity

Toerless Eckert <tte@cs.fau.de> Wed, 08 January 2020 19:26 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE9D12013B for <architecture-discuss@ietfa.amsl.com>; Wed, 8 Jan 2020 11:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level:
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHd9YSFvbLGL for <architecture-discuss@ietfa.amsl.com>; Wed, 8 Jan 2020 11:25:59 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865A31200CC for <architecture-discuss@ietf.org>; Wed, 8 Jan 2020 11:25:59 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A4770548048; Wed, 8 Jan 2020 20:25:53 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 97413440059; Wed, 8 Jan 2020 20:25:53 +0100 (CET)
Date: Wed, 08 Jan 2020 20:25:53 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: tony.li@tony.li
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Andrew Campling <andrew.campling@419.consulting>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Message-ID: <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de>
References: <LO2P265MB0573A1353911BFDD554DE5C8C2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <CAKKJt-dtX4kceJqY4kaB-vg4rs0uEn01SyyzR4m+UAO_0bZ=7g@mail.gmail.com> <c2633b3d-d114-217a-efca-2002bca9a084@gmail.com> <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/vEF0bYKPNcYDe9xMd_Dza_pzmG4>
Subject: Re: [arch-d] Centralization or diversity
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2020 19:26:02 -0000

On Wed, Jan 08, 2020 at 10:53:01AM -0800, tony.li@tony.li wrote:
> Nope. Been there and tried that.  ISO has PIC statements that are pretty much that for their standards.  Did not help at all.

Yes, i was thinking of ISO PICS. But i lost track of those ISO standards
since the 90th. I guess i would have to see a successfull and still
currently used standard and how its PICS do or do not help. Just
not alot of those ISO specs left in wide deployments, right.
X.500 ? Maybe i can get more insight from the security community.

> What it does do is to encourage people to write ???conformance test suites???.  These then get sold to unsuspecting customers and end-users.  Unfortunately, the quality of such suites is so low that you spend way, way, way more time debugging the test suite and you never find bugs in your implementation.

This is just the worst possible outcome, and i am sure one can learn
from those bad experiences. Just think of taking a more organized
step towards being able to collect protocol implementation information
from the industry. Right now every WG who wants to raise the level of
an IETF protocol, e.g.: to(wards) full standard is coming up with a
questionaire in an ad-hoc fashion (we're just doing this in Multicast
for IGMP/MLD). 

> >> 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.
> 
> Customers who buy into single vendor architectures are inflicting vendor lock on themselves.

My point was: If the only murphy you have is competitive pressure, it works not
it there is only limited competition, such as a total of maybe no
more than 3 competing national infrastructures. 

Remember my last mail where repeatedly half countries had no internet
from one of those three providers four many hours because of single
points of failures ?  For years and years. So much for competitive
pressure/Murphy.

Besides, Trump has already concluded that you only need to eliminate
one of the equipment vendors to solve the problem of secure, reliable
national infrastructures.
(not sure what the most fitting emoji is for this paragraph).

> > *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???.
> 
> Good.  Then I???ll say something more controversial: not everyone does it that way, yet.

See above. The best i think we (IETF) can do is to educate better about
this by appropriate documents. Certainly some additional protocol work
will result from that. I for once had simple slides 10 years ago how to fixup
non-dual plane networks to be dual-plane. And maybe we can come up with
questionaires to get better numbers from actual deployments (the
PICS discussion).

Figuring out ideas for a complete ecosystem of monetization and
deployment between competition and regulation is better left for
an ongoing bar-bof with emphasis on bar.

> >> 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.
> 
> Redundancy always has costs.  When it is needed it then pays dividends.  :-)

Actually one of the interesting conclusions was that dual-plane in
many cases is really free but deployments often just don't fully
utilize it.

Cheers
    Toerless

> Tony