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

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

    > From: xuxiaohu 41208 <xuxh@huawei.com>

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

Well, we definitely needed another namespace, to allow separation of location
and identity. Are you not convinced that was the correct decision?

If not, are you asking 'why didn't you re-use the existing IPvN syntax; i.e..
a fixed-length bit string, for the new location-only namespace'?

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

You are correct, the new namespace is locators only.

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

I think the Nimrod architecture document (RFC-1992) might help answer this.

(The NIRA document's take on Nimrod - "It did not address how to fit the
design into the policy-rich inter-domain routing environment." - confuses me
because Nimrod has a number of different fundamental capabilities intended to
support policy. Perhaps this text is simply a reflection of the fact that no
detailed examples were provided, showing exactly how to use them to provide
support for different policies. Also, Nimrod and IDPR are fundamentally the
same (especially in terms of policy, where they are exactly the same), except
that Nimrod added hierarchy - but the NIRA document doesn't make the identical
criticism of IDPR; why, I don't know.)

NIRA and Nimrod are not really comparable. NIRA is mostly a way of allowing
sources to have some control over paths, by use of lots of hierarchal
addresses (very roughly, one for each alternative path). However, as best I
can understand, while it does some routing, it still relies on being able to
use existing routing mechanisms (specifically, BGP in the core, and IGP's
locally), whereas Nimrod is intended to supplant these.


    > As a short term solution, Nimrod need a new locator namespace

Yes.

    > and all the routers in DFZ should be replaced,

Well, it depends on whether or not those parts of the DFZ wanted access to
Nimrod capabilities. It was designed to interoperate with areas of the network
using existing IPv4 routing mechanisms; even then, a 'flag-day' switch was
impossible.

The exact interoperation mechanism looked a lot like how the link-state OSPF
interoperates with other IPv4 destination-vector routing mechanisms.


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

You are mixing up Nimrod with things that might have come afterward, once
Nimrod was in place.

Any system for expanding the EID space would not have been part of Nimrod.

	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