re: [RRG] Nimrod, NIIA, HIP... as a long term solution?

[xuxiaohu 41208 <xuxh@huawei.com>]

----- 原邮件 -----
发件人: jnc@mercury.lcs.mit.edu (Noel Chiappa)
日期: 星期四, 十月 4日, 2007 下午8:34
主题: re: [RRG] Nimrod, NIIA, HIP... as a long term solution?

>    > From: Xu Xiaohu <xuxh@huawei.com>
> 
>    > Since Nimrod has split EID and locator, is it still 
> necessary to deploy
>    > a new locator namespace to support hierarchical routing?
> 
> Sorry, I did not understand that?
> 
> Nimrod has not been deployed, so EID and locator have not been 
> split (in the
> operational Internet). Also, of course, no other scheme which 
> splits EID and
> locator has been deployed, either.
> 
> 
> Did you mean 'why did Nimrod deploy a new locator namespace to support
> hierarchical routing'? Well, it deployed a new namespace for a 
> variety of
> reasons. Splitting location and identity was one, but we also did 
> not like the
> design of IPv4 addresses, at least for use in routing.
> 
> So, we handled both issues with the same thing, which was the new 
> locatornamespace. Rather than just have another copy of the IPv4 
> namespace for the
> separate location functionality, we designed a namespace in which 
> the names
> were i) optimally designed for use in the entire path-selection 
> subsystem, and
> ii) had the maximum amount of flexibility for the distant future 
> (i.e.  30-50
> years off - and if you think that is arrogant, remember that IPv4 
> was designed
> in about 1976, and so it is *already* 30 years old, and will be 
> around for
> some time to come).
> 
> 
> Or did you mean 'if some other scheme splits identity and 
> location, will it
> still be necessary to deploy a new locator namespace to support 
> hierarchicalrouting'? That is up to the people who design that scheme.
> 
> 
>    > IPv4 or IPv6 is aggregatable in nature. Can't they be used 
> directly for
>    > hierarchical routing?
> 
> Let's take the IPv4 case first. First, IPv4 addresses could noqt 
> be used
> direcly because we wanted to separate location and identity. (The 
> benefits of
> separating location and identity, for such uses as multi-homing, 
> ability to
> change ISP without re-addressing everything, etc are now well 
> understood, so I
> will not explain why separating identity and location is a good 
> thing.) We
> wanted the identity functionality to stay with the IPv4 address, 
> so hosts did
> not have to be modified. So we needed another namespace for location.
> 
you use IPv4 address as EID, and you need another namespace for location, it's id/locator split. what's the distinct benefit for adopting a new locator namespace in compare with existing IPv4/v6 address?

or does the new namespace can play the dual role of id and locator? in ambitious mobility scenario,the EID will not have any topological significance, so I think the new namespace can not play the dual role.

Besides, what's the difference between NIRA(http://portal.acm.org/citation.cfm?id=944768) and Nimrod? although NIRA refers to Nimrod.

> The same reasoning applies now to IPv6.
> 
> 
>    > Regarding incremental deployment, IPv4 and IPv6 will coexist 
> for a long
>    > time during IPv6 transition.
> 
> Let's not get into the future (if any) of IPv6.
> 
>    > I think the transition to the new locator namespace 
> mentioned above
>    > will encounter the same quandary.
> 
> It was never the intent to replace IPv4 addresses with the Nimrod 
> locatornamespace, so this comment does not make sense to me; the 
> entire point was
> that they would co-exist.
> 
As a short term solution, Nimrod need a new locator namespace and all the routers in DFZ should be replaced, as a long-term solution,Nimrod need to expand EID space according to the following statement. is it correct?
=========
The long-term plan (to the extent there was one :-) for architectural progress after Nimrod (e.g. to deal with the exhaustion of 32-bit EID space) was that once Nimrod and its new namespace was deployed, we could then use that as a 'fixed point' to allow deployment of some solution to expand the 'identity'
namespace. In other words, rather than having to deploy expansions to two different functions (identity and location) at the same time, we'd do first one, and then the other.
=========
> 	Noel
> 
> --
> to unsubscribe send a message to rrg-request@psg.com with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
>

begin:vcard
n:;xuxiaohu
fn:xuxiaohu
version:2.1
email;internet:xuxh@huawei.com
end:vcard