[rrg] Summary of RANGI//re: belated msg: further description of the recommendation process
Xu Xiaohu <xuxh@huawei.com> Tue, 15 December 2009 03:20 UTC
Return-Path: <xuxh@huawei.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 16F913A693F for <rrg@core3.amsl.com>; Mon, 14 Dec 2009 19:20:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.558
X-Spam-Level: *
X-Spam-Status: No, score=1.558 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1]
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 ke1pINguAI7C for <rrg@core3.amsl.com>; Mon, 14 Dec 2009 19:20:20 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B1D4C3A697F for <rrg@irtf.org>; Mon, 14 Dec 2009 19:20:19 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO008M1BX74K@szxga03-in.huawei.com> for rrg@irtf.org; Tue, 15 Dec 2009 11:19:56 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00MT0BX75Q@szxga03-in.huawei.com> for rrg@irtf.org; Tue, 15 Dec 2009 11:19:55 +0800 (CST)
Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUO002UWBX72C@szxml04-in.huawei.com> for rrg@irtf.org; Tue, 15 Dec 2009 11:19:55 +0800 (CST)
Date: Tue, 15 Dec 2009 11:19:55 +0800
From: Xu Xiaohu <xuxh@huawei.com>
In-reply-to: <5976B445-7209-4DE5-9D83-E2920265EB27@CS.UCLA.EDU>
To: 'Lixia Zhang' <lixia@CS.UCLA.EDU>, rrg@irtf.org
Message-id: <003101ca7d35$79779820$d40c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="gb2312"
Content-transfer-encoding: quoted-printable
Thread-index: Acp6JmvVbuTr5GcWQfaItCrs1SgUlADDUqSg
Subject: [rrg] Summary of RANGI//re: 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 03:20:21 -0000
> -----邮件原件----- > 发件人: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] 代表 Lixia Zhang > 发送时间: 2009年12月11日 13:54 > 收件人: rrg@irtf.org > 主题: [rrg] belated msg: further description of the recommendation process > > sorry folks, day job crisis delayed this msg for a few days. > > Tony and I have had some discussions on how to collect the > recommendation document. One comment we have heard repeated from a > number of people is that our recommendation should document the pros > and cons of different approaches, which can be very valuable, even > independent from whichever specific recommendations we may end up with. > > 1/ To steer efforts toward that goal, we would like each proposal to > make a concise summary, preferably no longer than ~1000 words (it may > contain pointer to more detailed document), that describes the key > ideas of the proposal of exactly how it addresses routing scalability > issue, where is its cost, and where is its gain. Hi Lixia and Tony, Summary of Routing Architecture for the Next Generation Internet (RANGI) is as follows: 1. Key idea: Similar to HIP [RFC4423], RANGI introduces a host identifier layer between the network layer and the transport layer, and the transport-layer associations (i.e., TCP connections) are no longer bound to IP addresses, but to host identifiers. The major difference from the HIP is that the host identifier in RANGI is a 128-bit hierarchical and cryptographic identifier which has organizational structure. As a result, the corresponding ID->locator mapping system for such identifiers has reasonable business model and clear trust boundaries. In addition, RANGI uses IPv4-embeded IPv6 addresses as locators. The LD ID (i.e., the leftmost 96 bits) of this locator is a provider-assigned /96 IPv6 prefix, while the last four octets of this locator is a local IPv4 address (either public or private). This special locator could be used to realize 6over4 automatic tunneling (borrowing ideas from ISATAP [RFC5214]), which will reduce the deployment cost of this new routing architecture. Within RANGI, the mappings from FQDN to host identifiers are stored in the DNS system, while the mappings from host identifiers to locators are stored in a distributed id/locator mapping system (e.g., a hierarchical Distributed Hash Table (DHT) system, or a reverse DNS system). 2. Gains: RANGI achieves almost all of goals set by RRG as follows: 1) Routing Scalability: Scalability is achieved by decoupling identifiers from locators. 2) Traffic Engineering: Hosts located in a multi-homed site can suggest the upstream ISP for outbound and inbound traffics, while the first-hop LDBR (i. e., site border router) has the final decision right on the upstream ISP selection. 3) Mobility and Multi-homing: Sessions will not be interrupted due to locator change in cases of mobility or multi-homing. 4) Simplified Renumbering: When changing providers, the local IPv4 addresses of the site do not need to change. Hence the internal routers within the site don’t need renumbering. 5) Decoupling Location and Identifier: Obvious. 6) Routing Stability: Since the locators are topologically aggregatable and the internal topology within LD will not be disclosed outside, the routing stability could be improved greatly. 7) Routing Security: RANGI reuses the current routing system and does not introduce any new security risk into the routing system. 8) Incremental Deployability: RANGI allows easy transition from IPv4 network to IPv6 network. In addition, RANGI proxy allows RANGI-aware hosts to communicate to legacy IPv4 or IPv6 hosts, and vice versa. 3. Costs: 1) Host change is required; 2) First-hop LDBR change is required to support site-controlled traffic-engineering capability. 3) The ID->Locator mapping system is a new infrastructure to be deployed. 4) Proxy needs to be deployed for communication between RANGI-aware hosts and legacy hosts. 4. Documents: RANGI => http://tools.ietf.org/id/draft-xu-rangi-01.txt. RANGI Proxy => http://tools.ietf.org/id/draft-xu-rangi-proxy-01.txt. RANGI Presentation on IETF76 => http://www.ietf.org/proceedings/09nov/slides/RRG-1.ppt
- [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