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 >>
- [rrg] belated msg: further description of the rec… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Patrick Frejborg
- Re: [rrg] belated msg: further description of the… Michael Menth
- Re: [rrg] belated msg: further description of the… Robin Whittle
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] belated msg: further description of the… Brian E Carpenter
- Re: [rrg] belated msg: further description of the… Scott Brim
- Re: [rrg] belated msg: further description of the… Noel Chiappa
- [rrg] On mapping systems Michael Menth
- Re: [rrg] belated msg: further description of the… Vince Fuller
- Re: [rrg] belated msg: further description of the… Brian E Carpenter
- [rrg] Summary of RANGI//re: belated msg: further … Xu Xiaohu
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] Summary of RANGI//re: belated msg: furt… Tony Li
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] belated msg: further description of the… $witch
- Re: [rrg] belated msg: further description of the… Charrie Sun
- Re: [rrg] belated msg: further description of the… Noel Chiappa
- Re: [rrg] belated msg: further description of the… HeinerHummel
- Re: [rrg] belated msg: further description of the… Brian E Carpenter
- Re: [rrg] belated msg: further description of the… Flinck, Hannu (NSN - FI/Espoo)
- Re: [rrg] belated msg: further description of the… Patrick Frejborg
- Re: [rrg] belated msg: further description of the… heinerhummel
- Re: [rrg] belated msg: further description of the… Flinck, Hannu (NSN - FI/Espoo)
- Re: [rrg] belated msg: further description of the… Yangyang Wang
- [rrg] Summary of GLI-Split Michael Menth
- Re: [rrg] belated msg: further description of the… Lixia Zhang