Re: multihoming, was IPv10

John C Klensin <john-ietf@jck.com> Fri, 30 December 2016 03:49 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335F01294F7 for <ietf@ietfa.amsl.com>; Thu, 29 Dec 2016 19:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 rbJwBR2cA8KH for <ietf@ietfa.amsl.com>; Thu, 29 Dec 2016 19:49:05 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCAA1294EF for <ietf@ietf.org>; Thu, 29 Dec 2016 19:49:04 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cMoBj-000F8e-RW; Thu, 29 Dec 2016 22:49:03 -0500
Date: Thu, 29 Dec 2016 22:48:57 -0500
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>
Subject: Re: multihoming, was IPv10
Message-ID: <0AF4F0A30512B3CB651C72F7@PSB>
In-Reply-To: <20161229162721.34651.qmail@ary.lan>
References: <20161229162721.34651.qmail@ary.lan>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZaaKzJMvic_7b8Yw0XeOEKh0xpc>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2016 03:49:06 -0000


--On Thursday, December 29, 2016 16:27 +0000 John Levine
<johnl@taugh.com> wrote:

>> ...  However, my impression is that we
>> are seeing increasing ISP concentration (except, maybe, close
>> to the edges of the network, where it makes little
>> difference) and less of that traditional type of multihoming.
> 
> There's tons of multihoming.  Every medium sized or larger
> business wants multiple upstreams for reliability.  They
> typically get a chunk of PA IPv4 addresses from each upstream.

John,

See Brian's comments and some others for responses to what I
think was intended to be your main point.  However, I picked my
words carefully.  I said and meant "traditional type of
multihoming" and, more important in the previous sentence, "many
hosts and sites that are multihomed in the traditional sense of
advertising one set of endpoint addresses to the network and
letting the routing system sort things out".   That is, very
specifically, one address per host, advertised to multiple ISPs/
networks/ paths and not "a chunk of PA IPv4 addresses from each
upstream".  

You are talking about a different --architecturally different--
approach, one that either requires endpoint hosts to manage
different addresses and the routing options associated with each
or that requires NAT arrangements that map one-many or many-many
rather than many-one or one-one.   

I'm not going to argue that one approach is better or worse than
the other.  In particular, unless one is large enough enterprise
to arrange for PI space and for multiple providers to route it,
the traditional multihoming architecture is effectively dead.
But that is another change in the architecture of the network as
it actually functions that we are, to at least some extent,
pretending is not happening.

best,
    john