Re: [rrg] Aggregatable EIDs

"Darrel Lewis (darlewis)" <darlewis@cisco.com> Tue, 12 January 2010 22:40 UTC

Return-Path: <darlewis@cisco.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 87D873A68C2 for <rrg@core3.amsl.com>; Tue, 12 Jan 2010 14:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 pSe7Se0ob-9V for <rrg@core3.amsl.com>; Tue, 12 Jan 2010 14:40:35 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F1B0C3A6878 for <rrg@irtf.org>; Tue, 12 Jan 2010 14:40:34 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq8EANKITEurR7Ht/2dsb2JhbACCFI1LsiaJDwiLXYI/CIFpBI06
X-IronPort-AV: E=Sophos; i="4.49,264,1262563200"; d="scan'208,217"; a="287534237"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 12 Jan 2010 22:40:32 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0CMeWfI015316; Tue, 12 Jan 2010 22:40:32 GMT
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 14:40:32 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA93D8.3D5FC2A0"
Date: Tue, 12 Jan 2010 14:40:28 -0800
Message-ID: <C0ACCB7B60E6F14B9AC46D742C1009A1C0FA38@xmb-sjc-213.amer.cisco.com>
In-Reply-To: <13149.23b666b.387e50ba@aol.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rrg] Aggregatable EIDs
Thread-Index: AcqT1ijobxY9L/uSSLuGdsdTTz8P9gAAdtBA
References: <13149.23b666b.387e50ba@aol.com>
From: "Darrel Lewis (darlewis)" <darlewis@cisco.com>
To: heinerhummel@aol.com, lixia@cs.ucla.edu, rrg@irtf.org
X-OriginalArrivalTime: 12 Jan 2010 22:40:32.0444 (UTC) FILETIME=[3FB3AFC0:01CA93D8]
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 22:40:36 -0000

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/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
		
		_______________________________________________
		rrg mailing list
		rrg@irtf.org
		http://www.irtf.org/mailman/listinfo/rrg