Re: [rrg] Aggregatable EIDs

tvest@eyeconomics.com Mon, 28 December 2009 07:03 UTC

Return-Path: <tvest@eyeconomics.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 447313A67EA for <rrg@core3.amsl.com>; Sun, 27 Dec 2009 23:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 D8h0AlnQVmWE for <rrg@core3.amsl.com>; Sun, 27 Dec 2009 23:03:18 -0800 (PST)
Received: from QMTA14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id 8E8BC3A67A5 for <rrg@irtf.org>; Sun, 27 Dec 2009 23:03:18 -0800 (PST)
Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA14.westchester.pa.mail.comcast.net with comcast id NWzR1d00217dt5G5EX30Bu; Mon, 28 Dec 2009 07:03:00 +0000
Received: from [172.16.1.4] ([76.104.56.12]) by OMTA13.westchester.pa.mail.comcast.net with comcast id NX2z1d0050FpAv83ZX2zWT; Mon, 28 Dec 2009 07:03:00 +0000
From: tvest@eyeconomics.com
To: RRG <rrg@irtf.org>
In-Reply-To: <4B382953.60608@gmail.com>
References: <000f01ca875b$8d8c8250$740c6f0a@china.huawei.com> <4B382953.60608@gmail.com>
Message-Id: <95209639-B15B-4EA4-B197-4C07860DF661@eyeconomics.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: Mon, 28 Dec 2009 02:02:58 -0500
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: Mon, 28 Dec 2009 07:03:20 -0000

On Dec 27, 2009, at 10: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.)

I'm curious. Has anyone ever fully/clearly articulated the *reasons*  
behind the absence of financial incentive to embrace addressing and  
routing solutions that would create (actually, to restore) a binding  
association between addressing and geography -- or better yet, made a  
positive argument for the financial incentives and broader economic  
factors that often recommend deploying networks in aggressively  
geography-indifferent patterns?

I tend to think that the reasons are so obvious as to be self-evident,  
but I'd be quite surprised to find that everyone's list of self- 
evident reasons is identical.

Can anyone point me to some approximation of an "authoritative list"  
of reasons? If not, does anyone see any merit (or problem) in the idea  
of compiling such a list?

Thanks in advance,

TV

> By the way, I don't consider HRA locators to be geo-based. They
> are fundmentally PA locators. The geographic part is secondary.
> In RANGI, you don't mention any geo component of the locators.
>
> But this was all a side comment. What I meant is that the problem
> of mapping PI identifiers to PA locators is just the same as
> mapping geo addresses to topological addresses. I don't see any
> evidence that the mapping can be significantly more compact
> than if the identifiers are assigned randomly. Wei Zhang seemed
> to argue that by some special assignment scheme for identfiers,
> we can get a significantly smaller map. I would like to see
> the data supporting that.
>
>> It must be something quite different from what I understand.
>>
>> This thread "Aggregatable EIDs" is concerned about aggregating EIDs  
>> and the problems with mapping the prefixes to RLOCs. This objective  
>> wouldn't even exist if both EID and RLOC-ID are  asigned a "third"  
>> information (I proposed it not long ago) which itself is  
>> universally routable and which wouldn't need any authoritative  
>> provisioner either. No need for aggregating any two EIDs! No need  
>> for mapping any EID-IP-address to any RLOC-IP-address provided that  
>> they share a common attribute that is derived from geographical  
>> coordinates.
>
> My point is that aggregation of EIDs is basically artificial.
>
>>
>> By sticking to  non-routable identifiers none of the 14 solutions  
>> becomes any better than LISP.
>
> At some level they are probably all isomorphic, yes. Except maybe  
> ILNP.
>
>> Note, not only IPv4 / IPv6 addresses are non-routable, AS numbers  
>> aren't either.
>
> But there are about 10 times fewer active AS numbers than there are  
> active
> prefixes. So flat-routing on AS numbers would gain one order of  
> magnitude
> immediately.
>
>> With 99 % of the hosts being mobile, wouldn't it be appropriate to  
>> have mainly provider-independent FQDNs
>
> Well, yes, which is why Christian Vogt's proposal for name-based
> sockets is very interesting. But actually it only hides the problem
> in the socket layer; the problem doesn't go away.
>
>>
>> and a DNS that is fairly up-to-date with the correlation between a  
>> respective HIT and the current location, i.e. completely  
>> independent of the current AS?
>
> If the locator is PA, sure. But that's the problem - making the  
> locator PA.
>
>>
>> Since the HIT is already a provider-independent host identifier,  
>> why should each host be assigned with a FQDN as another provider- 
>> independent ID? Taken the current cell-phone mobile network as an  
>> example, does every cell-phone need a FQDN-like global name besides  
>> the cell-phone number itself?
>
> Well, until people drop the stupidity of reverse DNS lookup as a  
> "security check"
> it's very hard to drop this. Of course it's bogus. (Do you really care
> that my FQDN right now is 121.98.142-??.bitstream.orcon.net.nz?)
>
>   Brian
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg