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

jnc@mercury.lcs.mit.edu (Noel Chiappa) Tue, 26 January 2010 17:17 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 C03423A67B6 for <rrg@core3.amsl.com>; Tue, 26 Jan 2010 09:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.166
X-Spam-Level:
X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 mms361kT8WXY for <rrg@core3.amsl.com>; Tue, 26 Jan 2010 09:17:32 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 02DAB3A6876 for <rrg@irtf.org>; Tue, 26 Jan 2010 09:17:31 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BE24E6BE564; Tue, 26 Jan 2010 12:17:41 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20100126171741.BE24E6BE564@mercury.lcs.mit.edu>
Date: Tue, 26 Jan 2010 12:17:41 -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: Tue, 26 Jan 2010 17:17:32 -0000

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

    > In the future core-edge split architecture the enterprise can have
    > PI-addresses ... If the future core-edge split architecture encourages
    > the usage of PI addresses, that would be a carrot for the enterprises
    > to migrate, wouldn't it?

Perhaps we are having a problem caused by your use of the term "address",
which does not seem (see below) to mean what I usually take it to mean.

(I really wish we could just stop using the term "address", because it means
so many different things to different people...)


To me, although there are apparently many different definitions for
"address", they almost all share one common attribute: that they are used by
the path-computation process. So in saying something is an "address", one is
implicitly saying 'this will be injected into the routing'.

Furthermore, "PI" means 'does not contain any information on location', i.e.
it not local to one particular scope, i.e. its scope (i.e. the part of the
network over which it must be advertised) is global.

So now we have "PI address" meaning 'something which has to be injected into
the routing, and must be visible over a global scope'.


So how is it that these 10 million (or however many companies it is) can all
have "PI address[es]"? I am sort of forced to the conclusion that what you
mean by the phrase "PI address" is something different, perhaps some sort of
identifier which is _not_ injected into the routing?

	Noel