Re: [rrg] belated msg: further description of the recommendation process Tue, 15 December 2009 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DBB13A6AA0 for <>; Tue, 15 Dec 2009 10:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.939
X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uhh2kbeJ1xLu for <>; Tue, 15 Dec 2009 10:29:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1D4863A68C1 for <>; Tue, 15 Dec 2009 10:29:43 -0800 (PST)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id nBFITAC5020361; Tue, 15 Dec 2009 13:29:11 -0500
Received: from by (mail_out_v42.5.) id o.bfb.6ef12be4 (32915); Tue, 15 Dec 2009 13:29:08 -0500 (EST)
Message-ID: <>
Date: Tue, 15 Dec 2009 13:29:08 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1260901748"
X-Mailer: 9.0 SE for Windows sub 5021
Subject: Re: [rrg] belated msg: further description of the recommendation process
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Dec 2009 18:29:45 -0000

In einer eMail vom 15.12.2009 15:40:39 Westeuropäische Normalzeit schreibt

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 

   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 

>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
Best Regards,

rrg  mailing  list

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 !