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

[Xu Xiaohu <xuxh@huawei.com>]

See in line,please.
> -----邮件原件-----
> 发件人: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 代表 Noel Chiappa
> 发送时间: 2007年9月30日 18:49
> 收件人: rrg@psg.com
> 抄送: jnc@mercury.lcs.mit.edu
> 主题: Re: [RRG] Nimrod, NIIA, HIP... as a long term solution?
> 
>     > From: Robin Whittle <rw@firstpr.com.au>
> 
>     > a proposal by which Nimrod: ..
>     > could be incrementally deployed, for IPv4 and IPv6?
>     > If not, then I think that Nimrod should not be compared with LISP
etc.
>     > but should be considered as a long-term solution, to be introduced
by
>     > means as yet unknown.
> 
> A few words about what Nimrod is, and is not, and how it was planned to
> deploy it.
> 
> Nimrod is a routing architecture only; i.e. a sub-system of the
> internetworking layer. Think of it, very roughly, as BGP+IGP. (So clearly,
in
> the above sentence, if I were to write "I think that BGP+IGP should not be
> compared with LISP etc" that would clearly make no sense.)
> 
> Nimrod was built around, among other things, a new namespace for naming
> internetwork level packet-carrying assets (routers and networks), and
> aggregates (some virtual) of the same. As such, it was not intended for
use
> with 'vanilla' IPv4 as the internetwork layer.
> 

Since Nimrod has split EID and locator, is it still necessary to deploy a
new locator namespace to support hierarchical routing? IPv4 or IPv6 is
aggregatable in nature. Can't they be used directly for hierarchical
routing?

Regarding incremental deployment, IPv4 and IPv6 will coexist for a long time
during IPv6 transition. I think the transition to the new locator namespace
mentioned above will encounter the same quandary.

> The deployment plan for Nimrod was basically what we would now term a
"jack
> up" approach, to allow support of unmodified hosts. (Many Nimrod features
> would not be accessible to unmodified hosts, of course.) IPv4 addresses
would
> become EIDs; the first Nimrod router that encountered a 'bare' IPv4 packet
> would map that EID into the appropriate Nimrod locator. (Nimrod locators
> would *not* necessarily be found in every packet inside the Nimrod router
> system, but that capability would mostly not be accessible to unmodified
> hosts.)
> 
> We didn't spend a lot of time on the "jack up" part of the design
> (specifically the distibution of those mappings); I think we thought it
would
> be pretty straight-forward. Thinking about LISP a lot has enlightened me -
> although of course the network is a lot bigger these days, and has to be
> engineered to deal with stuff we didn't understand well back then (e.g.
DoS
> attacks).
> 
> 
> 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



--
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