Re: [rrg] Aggregatable EIDs

[[e-mail]]

In einer eMail vom 28.12.2009 04:43:30 Westeuropäische Normalzeit schreibt  
[e-mail]:

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.)

There seems to be a fundamental misunderstanding. I have never ever thought 
 of such a crazy idea - to have geographically based exchange points.
 
I think there is no controversal: IP addresses shall get an aditional  
attribute. Many years ago it was the mask. Now in LISP it is an ETR's IP  
address, in ILNP an AS# (I think), in TARA it would be 2 octets  
square-degree-index, 12 bits square-degree minute-index, 6 bits adjusted  longitude-second, 6 
bits adjusted latitude-second = 5 octets altogether.
 
The economics won't be touched at all.  


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.

And my point is that EIDs shouldn't have to be aggregated at all, neither  
now nor ever in the future.
There is no need to do that and yet, forwarding could be done by one  
table-offset resp. 3 table-offsets - both in order to comply with the shortest  
path and also with some detouring path (in case that table element is  
temporarily set to an alternative next hop info for respective reasons)

> 
> 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.

3 years ago I was pretty in line with Ran's ILNP, because I come from PNNI. 
 Today I know PNNI's routing deficits better than all those who created it.
 


>  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.
I think Robin is right by referring to much bigger numbers than those which 
 apply currently.

Hence this factor 10 isn't a big deal. Anyway, it cannot match  
NON-AGGREGATION.
 

>> 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.
 
Wrong.With TARA the problem will go away and the benefits of Christian  
Vogt's can be harvested perfectly.
>> 
>> 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.


It is sufficient to make sure that each TARA-locator is  unique.


Heiner