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

Lixia Zhang <lixia@CS.UCLA.EDU> Thu, 24 December 2009 07:38 UTC

Return-Path: <lixia@CS.UCLA.EDU>
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 AB97E3A6935 for <rrg@core3.amsl.com>; Wed, 23 Dec 2009 23:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level:
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599]
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 toNqF+lSRPJ8 for <rrg@core3.amsl.com>; Wed, 23 Dec 2009 23:38:03 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by core3.amsl.com (Postfix) with ESMTP id C8A503A6942 for <rrg@irtf.org>; Wed, 23 Dec 2009 23:38:03 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id C02B439E80F0; Wed, 23 Dec 2009 23:37:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovNLl2bRYH78; Wed, 23 Dec 2009 23:37:46 -0800 (PST)
Received: from [10.0.1.3] (cpe-98-151-23-234.socal.res.rr.com [98.151.23.234]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id CC52A39E80DF; Wed, 23 Dec 2009 23:37:45 -0800 (PST)
Message-Id: <C889D19E-7319-45C6-B911-E936DFB8B2A0@CS.UCLA.EDU>
From: Lixia Zhang <lixia@CS.UCLA.EDU>
To: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
In-Reply-To: <2B5F3EA7272CFF47A66518E4FF3BE235045CC01B@FIESEXC014.nsn-intra.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 23 Dec 2009 23:37:44 -0800
References: <5976B445-7209-4DE5-9D83-E2920265EB27@CS.UCLA.EDU> <4B25275A.4050101@informatik.uni-wuerzburg.de><4B2665B9.2080903@tony.li> <4B269571.10406@gmail.com> <4B275C53.6040205@tony.li> <2B5F3EA7272CFF47A66518E4FF3BE235045CC01B@FIESEXC014.nsn-intra.net>
X-Mailer: Apple Mail (2.936)
Cc: rrg@irtf.org
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: Thu, 24 Dec 2009 07:39:48 -0000

On Dec 17, 2009, at 1:02 AM, Flinck, Hannu (NSN - FI/Espoo) wrote:

> 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

Hi Hannu,

I agree that the mapping itself is a critical part of the  
architecture. However I believe a mapping proposal needs to go  
together with an overall architecture, because one needs to know where  
mapping happens, mapping what to what.
Take a simple example: ILNP has kind of mapping (implemented in DNS)  
and LISP has another kind of mapping, 2 different proposals have  
rather different mappings.

Lixia

> -----Original Message-----
>> From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On
>> Behalf Of ext Tony Li
>> Sent: Tuesday, December 15, 2009 11:52
>> To: Brian E Carpenter
>> Cc: rrg@irtf.org; 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
>>
>> _______________________________________________
>> rrg mailing list
>> rrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/rrg
>>