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

jnc@mercury.lcs.mit.edu (Noel Chiappa) Sat, 23 January 2010 16:26 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 F2B2F3A6901 for <rrg@core3.amsl.com>; Sat, 23 Jan 2010 08:26:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.59
X-Spam-Level:
X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, 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 D3Rz3dDzHBl4 for <rrg@core3.amsl.com>; Sat, 23 Jan 2010 08:26:20 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1D3393A67A4 for <rrg@irtf.org>; Sat, 23 Jan 2010 08:26:19 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9B9BE6BE55A; Sat, 23 Jan 2010 11:26:14 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20100123162614.9B9BE6BE55A@mercury.lcs.mit.edu>
Date: Sat, 23 Jan 2010 11:26:14 -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: Sat, 23 Jan 2010 16:26:21 -0000

    > From: Patrick Frejborg <pfrejborg@gmail.com>

    > Yes, and I believe that the  Trojan Horse is called MPTCP :-)

Support for multiple PA addresses does certainly help with the multi-homing
aspects, but does it help with number (address) portability at all? I mean,
you just did say (above):

    > the subscriber owns the number and can choose which ever service
    > provider [they] prefer[]. So we should keep this model in the Internet
    > as well.

So is portability an important (critical?) goal or not? If so, how would
portability be done, if multi-homing is handled with multiple PA addresses?


    > If the CES solution becomes popular and gets widely deployed, e.g. if
    > broadband routers will include an ITR stack it will increase cache
    > sizes on the ETRs in front of popular sites. 

Cache sizes in front of large content providers are the thing that concern me
the most, but I don't think you're likely to see the _average_ residential
customer getting their own mapping entry.

That's because most residential customers don't have any need for the things
you need a mapping entry for - multi-homing, address portability, etc. (Heck,
my ISP seems to change my address on a regular basis, but because I'm not
running any servers, I don't notice.)

But I am still worried about cache sizes with LCPs.


    > Can you get a better story if you combine a CES with CEE from day one,

As I pointed out, most any CES can also be a CEE without much work.

Maybe that's the solution to the LCP problem - move the mapping stuff into
their servers, so they don't have the ETR caching issue? They generally all
have customized gear anyway, so that's probably actually feasible, now that I
think about it.


Of course, in a _rational_ design we wouldn't have this
caching/identifier-lookup issue, because the system would have been designed
from day one for the DNS lookup to return an {EID, RLOC} tuple, which would
be kept together thereafter.

Blasted 'changing engines while the plane is flying' - sure produces some
ugly configurations....

	Noel