Re: [arch-d] Centralization or diversity
Toerless Eckert <tte@cs.fau.de> Wed, 08 January 2020 18:28 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 61C74120059 for <architecture-discuss@ietfa.amsl.com>; Wed, 8 Jan 2020 10:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTqCDHHymOMZ for <architecture-discuss@ietfa.amsl.com>; Wed, 8 Jan 2020 10:28:22 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff: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 ACC16120880 for <architecture-discuss@ietf.org>; Wed, 8 Jan 2020 10:28:22 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0A6C854802F; Wed, 8 Jan 2020 19:28:17 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EB787440059; Wed, 8 Jan 2020 19:28:16 +0100 (CET)
Date: Wed, 08 Jan 2020 19:28:16 +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: <20200108182816.GS8801@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/czpOwzMvXyM2hCQddXSTiYeO67c>
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 18:28:24 -0000
On Tue, Jan 07, 2020 at 01:35:45PM -0800, tony.li@tony.li 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. Cheers Toerless > Tony > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss
- [arch-d] Centralization or diversity Martin Thomson
- Re: [arch-d] Centralization or diversity Andrew Campling
- Re: [arch-d] Centralization or diversity Jari Arkko
- Re: [arch-d] Centralization or diversity Jari Arkko
- Re: [arch-d] Centralization or diversity Stephane Bortzmeyer
- Re: [arch-d] Centralization or diversity Spencer Dawkins at IETF
- Re: [arch-d] Centralization or diversity Toerless Eckert
- Re: [arch-d] Centralization or diversity Brian E Carpenter
- Re: [arch-d] Centralization or diversity tony.li
- Re: [arch-d] Centralization or diversity Spencer Dawkins at IETF
- Re: [arch-d] Centralization or diversity Toerless Eckert
- Re: [arch-d] Centralization or diversity tony.li
- Re: [arch-d] Centralization or diversity Toerless Eckert
- Re: [arch-d] Centralization or diversity tony.li
- Re: [arch-d] Centralization or diversity John Day
- Re: [arch-d] Centralization or diversity John C Klensin
- Re: [arch-d] Centralization or diversity Toerless Eckert
- Re: [arch-d] Centralization or diversity Guntur Wiseno Putra
- Re: [arch-d] Centralization or diversity Guntur Wiseno Putra
- Re: [arch-d] Centralization or diversity Guntur Wiseno Putra
- Re: [arch-d] Centralization or diversity Guntur Wiseno Putra
- Re: [arch-d] Centralization or diversity Guntur Wiseno Putra