Subject: Re: [rrg] belated msg: further description of the recommendation process

From: Charrie Sun <[email-masked]>
Date: Tue, 15 Dec 2009 22:40:13 +0800

Hi Heiner,
   Thanks for your advice. I didn't fully catch your idea but i will try to
answer your questions inline.

>Sun Letong,
>your proposal shows that the strong belief in mapping doesn't crumble at
all.

   I didn't think that mappings should be all in blocks (is that what you
mean?) and be not crumbled, i just think that edge address being allocated
individually, especially in tomorrow's IPv6 scene is rather rare. So the
vast block mappings would make mapping table size to be happily smaller.

>Speaking in analogy once more, I have tried - in vain - to convince people
that a routable namespace a la Manhattan, New >York is better than using a
non-routable namespace where you depend on >mapping. In New York you can
progress towards your destination without asking people at each junction of
avenue and street.

 Do you mean that to put the detailed address as well as the rough (city
level, or larger) address all in a packet? Or, it is like geo-based routing?
While i consider that very persuasive, i doubt its deployability. Would
current users change their address, especially in such a large scale? Trying
to solve the problem indirectly, i.e. using mapping, would be more
applicable.

>Besides that the scalability problem could indeed become a non-issue (for
ever), it strikes me that    the inherent capabilities of geographical
coordinates-based routing wrt IP mobility aren't appreciated >neither by
Nokia nor Ericsson folks.

Sorry i didn't catch your last sentence.

>Good luck for your proposal
>
>Heiner

Best Regards,
Letong

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 15 Dec 2009 09:55:43 -0500 (EST)

> From: Brian E Carpenter <[email-masked]>

    >>> Also I feel it should support hierarchy, even if we don't need a
    >>> hierarchy from the start.

    > I was thinking about a hierarchy of namespaces

To help me understand how this would work, could you give an example?

    > Just make a couple of the basic data definitions recursive, and you've
    > got both hierarchies.

And an example of this too...

	Noel

---

From: [email-masked]
Date: Tue, 15 Dec 2009 13:29:08 EST

In einer eMail vom 15.12.2009 15:40:39 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi Heiner,
   Thanks for your advice. I didn't fully catch your idea  but i will try 
to answer your questions inline.
 
all. 

>Speaking in analogy once more, I have tried - in vain - to  convince 
people that a routable namespace a la Manhattan, New >York  is better than using 
a non-routable namespace where you depend on  >mapping. In New York you can 
progress towards your destination  without asking people at each junction of 
avenue and street.

ever), it strikes me that     the inherent capabilities of geographical 
coordinates-based  routing wrt IP mobility aren't appreciated >neither by Nokia 
nor  Ericsson folks.

 
Best Regards,
Letong

_______________________________________________
rrg  mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

No, I'm not after details of mapping.
By the  Manhattan analogy I want to say that being at some  
Avenue-X/Street-Y corner you don't neet a FIB-like table which tells you how to  go next in 
order to reach your destination. Such a table however would be  appropriate 
if the  streets had lovely names like "Lombard  Street"etc.
 
The mentioned IP Mobility capability:
To do a geographically well scoped search for a UNICAST destination IP  
address. Keep in mind: DNS also needs refreshing from time to time. Why not 
with  the up-to-date geographical location (RFC1712). No dependence on some 
home agent  or care of address server !
 
Heiner

---

From: [email-masked]
Date: Thu, 17 Dec 2009 05:03:03 EST

In einer eMail vom 17.12.2009 10:02:35 Westeuropäische Normalzeit schreibt  
[email-masked]:

Most of  the scalability discussions we have had are dealing exactly with
the  mapping system, not how to tunnel or rewrite the addresses. The
mapping  system is the architecture that uses the tunnels or address
manipulation  based on some address structure.  

A  tunneling
scheme/address rewrite together with an address structure is  not
sufficient for scalabilty. 

- Hannu

Right. It takes an architecture which doesn't require   knowing each 
topological detail from the far distance, hence which doesn't  require 
disseminating updates of respective changes. And we all know:  the farer away, the 
larger the area, the more details there  are. 
 
All the mainstream mapping-based architectures which only try to  reduce 
the scalability problem ( a little bit), just shift the  scalability problem 
(here: the update churn) to some other places.
 
Concurrently they create an extra complexity which will be terrible wrt  
better routing technologies.
 
Heiner

>-----Original Message-----
>From: [email-masked]  [mailto:[email-masked]] On 
>Behalf Of ext Tony Li
>Sent:  Tuesday, December 15, 2009 11:52
>To: Brian E Carpenter
>Cc:  [email-masked]; Lixia Zhang
>Subject: Re: [rrg] belated msg: further  description of the 
>recommendation process
>
>Brian E  Carpenter wrote:
>
>>> Mapping systems are obviously a  component of a solution but are not 
>>> by themselves a  solution.  To be considered seriously, they 
>should be  
>>> used in conjunction with some network layer  solution.
>> 
>> Hmm. Don't you think that to some extent  these should be orthogonal?
>> A mapping mechanism needs to meet the  specific requirements of a 
>> network layer mechanism, but that  doesn't require the two to be 
>> irrevocably bound to each  other.
>> 
>> I have a feeling that the mapping system should  be very general in 
>> nature, in case the first cut at either the  locator or identifier 
>> space proves to fall short. Also I feel it  should support hierarchy, 
>> even if we don't need a hierarchy from  the start.
>
>
>
>Brian,
>
>Our  recommendation is focused on providing an alternative 
>routing  architecture.  A mapping system is a fine component, 
>but would not  seem to provide a credible architecture by  itself.
>
>Tony
>

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Dec 2009 13:35:49 +0200

proposal: Compact routing in locator identifier mapping system
---------

key idea:
---------

Builds a highly scalable locator identity mapping system using compact
routing principles. Provides means for dynamic topology adaption to
facilitate efficient aggregation. Map servers are assigned as cluster
heads or landmarks based on their capability to aggregate EID
announcements.

gains:
------

Minimizes the routing table sizes in at the system level (= map
servers). Provides clear upper bounds for routing stretch that defines
the packet delivery delay of the map request/first packet.  

Organizes the mapping system based EID numbering space, minimizes the
administrative of overhead of managing EID space. No need for
administratively planned hierarchical address allocation as the system
will find convergence into a sets of EID allocations.

Availability and robustness of the overall routing system (including
xTRs and map servers) is improved because potential to use multiple map
servers and direct routes without involvement of map servers.

costs:
------

The scalability gains will materialize only in large deployments. If the
stretch is required to be bound to those of compact routing (worst case
stretch less or equal to 3, on average 1+epsilon) then xTRs need to have
memory/cache for the mappings of its cluster. 

full documentation:
-------------------

Sent to the rrg-mailing list 15th of Dec