Re: [rrg] Summary of RANGI//re: belated msg: further description of the recommendation process

[Tony Li <[e-mail]>]

Received.

T


Xu Xiaohu wrote:
> 
>> -----邮件原件-----
>> 发件人: [e-mail] [mailto:[e-mail]] 代表 Lixia
> Zhang
>> 发送时间: 2009年12月11日 13:54
>> 收件人: [e-mail]
>> 主题: [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 mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg