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

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

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

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