Re: [rrg] Aggregatable EIDs

jnc@mercury.lcs.mit.edu (Noel Chiappa) Tue, 12 January 2010 21:33 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 59C6C3A6895 for <rrg@core3.amsl.com>; Tue, 12 Jan 2010 13:33:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 u6GLbfvhFYAF for <rrg@core3.amsl.com>; Tue, 12 Jan 2010 13:33:07 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 69F1E3A6838 for <rrg@irtf.org>; Tue, 12 Jan 2010 13:33:07 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 15CE26BE597; Tue, 12 Jan 2010 16:33:03 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20100112213304.15CE26BE597@mercury.lcs.mit.edu>
Date: Tue, 12 Jan 2010 16:33:03 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [rrg] Aggregatable EIDs
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, 12 Jan 2010 21:33:08 -0000

    > From: Lixia Zhang <lixia@cs.ucla.edu>

    > This proposal was considered and debated at the time, but did not
    > fly ... mainly due to the reason that has been articulated in this
    > thread of exchanges: the model does not match the ISP economics.

To expand on this a tiny bit, let me give it to you as Yakov concisely put
it to me:

In routing (i.e. path selection), for the overhead of routing to scale
'reasonably' in large networks, either the 'addressing' (i.e. the names used
by path selection) has to follow the topology, or the topology has to follow
the addressing; i.e. there has to be a certain level of congruence between the
two.

(And by 'topology' I mean actual network connectivity - we're mis-using
the term 'topology', but it's probably too late to fix that now, although
if someone has a better alternative term, I will cheerfully switch to
using it... :-)

Unfortunately for geo-addressing, for economic reasons, topology usually
follows traffic patterns (i.e. you lay/light-up fiber to match traffic flows),
and traffic patterns follow relationships in the real world (e.g.  between
customers and their suppliers/providers). So driving the topology from the
addressing end is not possible.

Instead, the only way that works is relationships -> traffic patterns ->
topology -> addressing.

	Noel