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
- [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