[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