Re: [rrg] Aggregatable EIDs

heinerhummel@aol.com Tue, 12 January 2010 23:08 UTC

Return-Path: <HeinerHummel@aol.com>
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 295083A67F3 for <rrg@core3.amsl.com>; Tue, 12 Jan 2010 15:08:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.932
X-Spam-Level:
X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 YAUqLlO15+O4 for <rrg@core3.amsl.com>; Tue, 12 Jan 2010 15:08:44 -0800 (PST)
Received: from imr-da01.mx.aol.com (imr-da01.mx.aol.com [205.188.105.143]) by core3.amsl.com (Postfix) with ESMTP id 4560E3A6877 for <rrg@irtf.org>; Tue, 12 Jan 2010 15:08:44 -0800 (PST)
Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imr-da01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o0CN8ARj027997; Tue, 12 Jan 2010 18:08:10 -0500
Received: from HeinerHummel@aol.com by imo-ma03.mx.aol.com (mail_out_v42.5.) id 9.cf5.67b0d5bd (37167); Tue, 12 Jan 2010 18:08:05 -0500 (EST)
Received: from smtprly-me02.mx.aol.com (smtprly-me02.mx.aol.com [64.12.95.103]) by cia-ma04.mx.aol.com (v127.7) with ESMTP id MAILCIAMA046-b2b74b4d00d3ce; Tue, 12 Jan 2010 18:08:05 -0500
Received: from magic-m01.mail.aol.com (magic-m01.mail.aol.com [172.21.172.72]) by smtprly-me02.mx.aol.com (v127.7) with ESMTP id MAILSMTPRLYME021-b2b74b4d00d3ce; Tue, 12 Jan 2010 18:08:03 -0500
From: heinerhummel@aol.com
Message-ID: <145ca.6392b7c8.387e5ad3@aol.com>
Date: Tue, 12 Jan 2010 18:08:03 -0500
To: darlewis@cisco.com, lixia@cs.ucla.edu, rrg@irtf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_145ca.6392b7c8.387e5ad3_boundary"
X-Mailer: 9.0 SE for Windows sub 5021
X-AOL-ORIG-IP: 95.91.134.11
X-AOL-IP: 172.21.172.72
X-AOL-SENDER: HeinerHummel@aol.com
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 23:08:46 -0000

 
Darrel,
your question is about "partitioning" and is very important. Although that  
should be interconnectivity inside a geopatch should be the normal case,  
it may happen that there are multiple parts which are not  interconnected by 
intra-geopatch links.
The concept must provide 2 things: 1) The capability to recognize that  
there are partitions, 2) extensions to the concept which handle them. a) by  
making sure to get to the right part (if possible). b) by enabling  detours
from inside via neighboring geopatches to the other inside part. Note,  
there could be a strict link from the other half of the globe into one of  
several partitions of some geopatch.
 
Though it is important, it is yet just one detail. There is more: The  
commonly acquired maps which consisted of differently zoomed/skimmed  parts of 
the surrounding internet might be enhanced by some set of intra-domain  
TARA-links (e.g. of a global operating ISP !).
 
We all shouldn't mind facing new challenges. 
 
Heiner
PS: Good luck to LISP. But isn't one jack-up solution enough to be pursued  
?
 
 
 
 
In einer eMail vom 12.01.2010 23:40:34 Westeuropäische Normalzeit schreibt  
darlewis@cisco.com:

Are routers inside a  given geo-patch required to interconnect?  That is, 
will a packet which  is delivered to any given router inside a geopatch be 
guaranteed to be  delivered to some other router in the same geopatch?
 
I believed Tony asked  this question a few times, I've yet to see a clear 
answer.
 
-Darrel


 
____________________________________
 From: rrg-bounces@irtf.org  [mailto:rrg-bounces@irtf.org] On Behalf Of  
heinerhummel@aol.com
Sent: Tuesday, January 12, 2010 2:25  PM
To: lixia@cs.ucla.edu; rrg@irtf.org
Subject: Re:  [rrg] Aggregatable EIDs




Lixia,
Once more: My geolocation-based TARA concept is FUNDAMENTALLY  different 
from all three proposals you are mentioning (Steve Deering's  Metro-based..., 
Hain-draft, Giro). If I had no better computational  tools at hand than 
Deering, Hain or the UCLA group, I  would either be absolutely  silent          
- or in the  ILNP camp:-)
 
Lixia, I know, you have a lot of ideas, how to make prefix-handling  more 
sophisticated.
My point however  is: Get rid of any (Unicast) prefix building.  TARA is 
about providing a well-skimmed topological view of the internet  (which 
prevents table size problems as well as update churn). As opposed to  all 
submitted proposals, TARA is the only one which can provide a perfect  
visualization: Use Google to search for a route from NY, Time Square, to  S.F, Lambert 
Street - and play with the different zooms !!!
 
Heiner
 
 
In einer eMail vom 12.01.2010 19:39:25 Westeuropäische Normalzeit  schreibt 
lixia@cs.ucla.edu:

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/de
ering.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

_______________________________________________
rrg  mailing  list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg