Re: [rrg] Aggregatable EIDs

[[e-mail]]

Hi Peter,

I suspect that there may have been a miscommunication. I actually  
meant that the economic factors that motivate non-geographic  
addressing and network deployment are so obvious as to be self-evident.

Regardless, thanks very much for the reaction...

TV

On Dec 28, 2009, at 11:31 AM, Peter Sherbin wrote:

>> I tend to think that the reasons are so obvious...
>
> Precisely. To function smoothly the Internet requires a set of  
> access points patterned in and around planet's surface, atmo- /  
> aquasphere and crust (pick the "proper" density of AP/sq.km). Keep  
> in mind that any end system can connect seamlessly (wired or  
> wireless) to any access point. The model suggests that an individual  
> ISP supports a certain part of AP grid with no control whatsoever  
> over end systems. No single ISP seems to be excited about such a  
> model.
>
> Thanks,
>
> Peter
>
> --- On Mon, 12/28/09, [e-mail] <[e-mail]>  
> wrote:
>
>> From: [e-mail] <[e-mail]>
>> Subject: Re: [rrg] Aggregatable EIDs
>> To: "RRG" <[e-mail]>
>> Date: Monday, December 28, 2009, 2:02 AM
>>
>> 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
>>> [e-mail]
>>> http://www.irtf.org/mailman/listinfo/rrg
>>
>> _______________________________________________
>> rrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/rrg
>>
>
>
>