Re: [arch-d] Centralization or diversity Wed, 08 January 2020 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58160120072 for <>; Wed, 8 Jan 2020 10:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M8soQBOe2jlN for <>; Wed, 8 Jan 2020 10:53:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52483120047 for <>; Wed, 8 Jan 2020 10:53:04 -0800 (PST)
Received: by with SMTP id d5so5003pjz.5 for <>; Wed, 08 Jan 2020 10:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EYGidJM4rlw4hPuMowzxxszsWC11zVHFvIKgi2XFh9Y=; b=px/0OCKxBXMyOzMpKg5SAAcsQHIzRlj6wVMgfvn71PhLwRmmj55u+DQ93cNiY9w9VG wcD7o+YDoWiJB/FEjGX+R6CcvGgtTUyAF7A7lvrl8Tbv7MTUxvv/Qx8MJ1qW/PyhkLZQ QT8bqlRROCQP/MKmJ+cfPTnS1dDJOF/w2II8KERAJ0BD/8wBxBHYG6QKUjg6Hav977TI 7yFX9ibRiReufn9lZIha15FqdB30uHOiPYoh4oyX6o3FQIDqqluETmGLsUD/wj8Dh8h5 kCARUoq7q5jsre3Mk/8QBdpQRASlRbI+L8WjPbfYqqr6LF+kVNH+Q3ajDfEqnaiFB0ca 31kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=EYGidJM4rlw4hPuMowzxxszsWC11zVHFvIKgi2XFh9Y=; b=NIfcal8Kfj6jPsroAhZaXSASbNjZM2T+TU75GcC+bRQ4vzbwt0uOXZqyeRKg5T+3xM q24VnNggaB7N+66thN6zBchEEjia2Qi1CzpCxINICO+DeI4OKzIrd4yHn52EAHxgPLha kQyBXggysgo3Y0+X5OlFxkVxE2nvGJMbAl6Xr4QO1GNWIR//UsK5ker0Maq4ntxm79Vc AfFkzcDWw1pTYTfRQ8aqXSvLL1jmvEIuIcwPahzLbybJ2Ps2sSUS3q01F3iKe6KXBDIY dG3O+53iforYqT9aazjoo3pjIAmNTOItG/eNaimItgBTaBWuD6NaZ2rhQJWGz9ISslyn VOvA==
X-Gm-Message-State: APjAAAUUvgz/dXHN1QcdkbAlROWjnqK9gn+c3lTLeaY1TpBE9Zmok19y lPb8YdUXwEGeR92/J9nkGnC0371r
X-Google-Smtp-Source: APXvYqzrINybow0HeDJbY7O4/DEFKJKsNt3fNy7jmAX24gUvHdp1HqJ4LGOTWZP0Zl9FScFSJD/tyw==
X-Received: by 2002:a17:902:8344:: with SMTP id z4mr7185852pln.41.1578509583712; Wed, 08 Jan 2020 10:53:03 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id y203sm4694028pfb.65.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 10:53:03 -0800 (PST)
Sender: Tony Li <>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <>
Date: Wed, 8 Jan 2020 10:53:01 -0800
Cc: Brian E Carpenter <>, Andrew Campling <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <LO2P265MB0573A1353911BFDD554DE5C8C2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <> <> <> <>
To: Toerless Eckert <>
X-Mailer: Apple Mail (2.3445.104.11)
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:53:05 -0000

Hi Toerless,

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

Nope. Been there and tried that.  ISO has PIC statements that are pretty much that for their standards.  Did not help at all.

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.

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

>> 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”.

Good.  Then I’ll say something more controversial: not everyone does it that way, yet.

>> 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.  :-)