Re: [rrg] Aggregatable EIDs

Lixia Zhang <lixia@cs.ucla.edu> Tue, 12 January 2010 18:39 UTC

Return-Path: <lixia@cs.ucla.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 7D49C3A683B for <rrg@core3.amsl.com>; Tue, 12 Jan 2010 10:39:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.171
X-Spam-Level:
X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599]
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 ufQv9iFHEOwv for <rrg@core3.amsl.com>; Tue, 12 Jan 2010 10:39:04 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by core3.amsl.com (Postfix) with ESMTP id 656ED3A6817 for <rrg@irtf.org>; Tue, 12 Jan 2010 10:39:04 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 3AB1139E80DF for <rrg@irtf.org>; Tue, 12 Jan 2010 10:39:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfZnLba8XZlO for <rrg@irtf.org>; Tue, 12 Jan 2010 10:39:00 -0800 (PST)
Received: from Cs-32-34.CS.UCLA.EDU (Cs-32-34.CS.UCLA.EDU [131.179.32.34]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 6D38E39E80B1 for <rrg@irtf.org>; Tue, 12 Jan 2010 10:39:00 -0800 (PST)
Message-Id: <B4606DCF-BD70-4BFD-A572-9E7369DF779F@cs.ucla.edu>
From: Lixia Zhang <lixia@cs.ucla.edu>
To: rrg@irtf.org
In-Reply-To: <4B382953.60608@gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 12 Jan 2010 10:39:00 -0800
References: <000f01ca875b$8d8c8250$740c6f0a@china.huawei.com> <4B382953.60608@gmail.com>
X-Mailer: Apple Mail (2.936)
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 18:39:05 -0000

On Dec 27, 2009, at 7:43 PM, Brian E Carpenter wrote:

> Hi,
>
> On 2009-12-28 14:17, Xu Xiaohu wrote:
> ...
>>> This argument fails for exactly the same reason that geographically
>>> based BGP aggregation fails.
>>
>> Brian, who has ever done it ?
>
> Nobody, as far as I know.
>
>> Why do you say this and what do you mean by saying this ?
>
> There have been a lot of geo-based or metro-based proposals over
> the years. Most recently, draft-hain-ipv6-geo-addr.
> As far as I know, none of them has ever been deployed, because
> this isn't how Internet economics works. There is no financial
> incentive to deploy geographically based exchange points which also
> act as address delegators to customers. (Note, there is no technical
> argument against it. But nobody knows how to make money out of it.)

the above comment seems alluding to the long historical debate in geo- 
based addressing, that the young folks here may not be totally aware  
(I wish I were one of you people:).  So here are a few pointers to  
related material.

The concept was a rather old one, Greg Finn had some related proposal  
back in early 80s (I didn't bother to hunt down the URL but I believe  
a long tech report is still on the web).

In the early days of IPv6 design, Steve Deering gave a strong pushing  
in this direction.  The best ref is probably his plenary talk at July  
1995 IETF meeting:
"Metro-Based Addressing",
ftp://ftp.ietf.org/ietf-online-proceedings/95jul/presentations/allocation/deering.slides.ps

This proposal was considered and debated at the time, but did not fly  
(though effort in that direction continued on, e.g. the draft-hain- 
ipv6-geo-addr mentioned above), mainly due to the reason that has been  
articulated in this thread of exchanges: the model does not match the  
ISP economics.

However as it happens to any debate, opinions often swing further than  
proper. From time to time one hears the interpretation from that  
debate as "geo info cannot be used in routing" which is not the case.
What that debate taught us (at least me) is that, for routing  
decisions, ISP info must take the high order bit.
However after that high order bit is taken into account, geo info can  
be very useful to further optimize the routing decisions.
as a simple evaluation, we used the BGP data from Rotueviews and RIPE  
for a measurement study, the result is reported in a paper a few years  
back:
"Geographically Informed Inter-Domain Routing"
http://www.cs.ucla.edu/~rveloso/papers/giro.pdf
or if you just want a quick look of the idea, here is the presentation  
slides:
http://www.cs.ucla.edu/~rveloso/papers/07ICNP_giro.ppt

Lixia