Re: [rrg] belated msg: further description of the recommendation process Thu, 17 December 2009 10:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 147233A6877 for <>; Thu, 17 Dec 2009 02:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.026
X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4TfGhZjG4CNy for <>; Thu, 17 Dec 2009 02:03:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8FF683A6862 for <>; Thu, 17 Dec 2009 02:03:49 -0800 (PST)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id nBHA3K1N001096; Thu, 17 Dec 2009 05:03:20 -0500
Received: from by (mail_out_v42.5.) id o.c24.73ed5ac8 (44668); Thu, 17 Dec 2009 05:03:14 -0500 (EST)
Received: from ( []) by (v126.13) with ESMTP id MAILCIAMC017-5c6f4b2a01d714a; Thu, 17 Dec 2009 05:03:09 -0500
Received: from ( []) by (v127.6) with ESMTP id MAILSMTPRLYMB035-5c6f4b2a01d714a; Thu, 17 Dec 2009 05:03:03 -0500
Message-ID: <>
Date: Thu, 17 Dec 2009 05:03:03 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_436.5e8314b9.385b5bd7_boundary"
X-Mailer: 9.0 SE for Windows sub 5021
Cc:, lixia@CS.UCLA.EDU
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: Thu, 17 Dec 2009 10:03:51 -0000

In einer eMail vom 17.12.2009 10:02:35 Westeuropäische Normalzeit schreibt

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.

>-----Original Message-----
>From:  [] On 
>Behalf Of ext Tony Li
>Sent:  Tuesday, December 15, 2009 11:52
>To: Brian E Carpenter
>Cc:; 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.
>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.
>rrg  mailing  list
rrg  mailing  list