Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?

jnc@mercury.lcs.mit.edu (Noel Chiappa) Sun, 24 January 2010 17:19 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBCE3A690B for <rrg@core3.amsl.com>; Sun, 24 Jan 2010 09:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyVPpDbgoanM for <rrg@core3.amsl.com>; Sun, 24 Jan 2010 09:19:33 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 656FA3A681E for <rrg@irtf.org>; Sun, 24 Jan 2010 09:19:33 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BAFF96BE5A7; Sun, 24 Jan 2010 12:19:34 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20100124171934.BAFF96BE5A7@mercury.lcs.mit.edu>
Date: Sun, 24 Jan 2010 12:19:34 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jan 2010 17:19:34 -0000

    > From: Scott Brim <scott.brim@gmail.com>

    >> Support for multiple PA addresses does certainly help with the
    >> multi-homing aspects, but does it help with number (address)
    >> portability at all?

    > Just for clarity: Multipath transport does not assume or rely on the
    > endpoint receiving multiple PA addresses from a network.

Huh? From the MPTCP architecture document:

  "The multipath transport protocol must allow for a logical transport
  endpoint as seen by the application to correspond to multiple physical
  network attachment points, such as multiple IP addresses on the same or
  different network interfaces."

Note the "multiple addresses on the same ... network interface[]".

Yes, it does mention other possible techniques for gaining access to multiple
parallel paths, but the first ("Use a path selector value") is not possible
at the moment, and the other ("Next-hop selection") will only affect outgoing
traffic, not incoming.

So as far as I can see, use of multiple addresses is the _principle_
technique used by MPTCP to support _site multi-homing_ (which is what I was
referring to with 'multi-homing"). Do you disagree with that?

(Yes, hosts with multiple interfaces may be more common in the future, and
MPTCP also handles that - but that's not what people generally refer to as
'multi-homing', which tends to mean 'site multi-homing' - which is, after all,
what has the routing people concerned.)

You may want to quibble with the use of "PA", but if a site has a PI address,
presumably it does site multi-homing that way.

	Noel