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

HeinerHummel@aol.com Tue, 15 December 2009 18:29 UTC

Return-Path: <HeinerHummel@aol.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 2DBB13A6AA0 for <rrg@core3.amsl.com>; Tue, 15 Dec 2009 10:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.939
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhh2kbeJ1xLu for <rrg@core3.amsl.com>; Tue, 15 Dec 2009 10:29:44 -0800 (PST)
Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by core3.amsl.com (Postfix) with ESMTP id 1D4863A68C1 for <rrg@irtf.org>; Tue, 15 Dec 2009 10:29:43 -0800 (PST)
Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id nBFITAC5020361; Tue, 15 Dec 2009 13:29:11 -0500
Received: from HeinerHummel@aol.com by imo-da04.mx.aol.com (mail_out_v42.5.) id o.bfb.6ef12be4 (32915); Tue, 15 Dec 2009 13:29:08 -0500 (EST)
From: HeinerHummel@aol.com
Message-ID: <bfb.6ef12be4.38592f74@aol.com>
Date: Tue, 15 Dec 2009 13:29:08 -0500
To: charriesun@gmail.com, rrg@irtf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1260901748"
X-Mailer: 9.0 SE for Windows sub 5021
X-AOL-SENDER: HeinerHummel@aol.com
Subject: Re: [rrg] belated msg: further description of the recommendation process
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: Tue, 15 Dec 2009 18:29:45 -0000

 
In einer eMail vom 15.12.2009 15:40:39 Westeuropäische Normalzeit schreibt  
charriesun@gmail.com:

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


_______________________________________________
rrg  mailing  list
rrg@irtf.org
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