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

From: Robin Whittle <[email-masked]>
Date: Fri, 28 Sep 2007 12:33:28 +1000

In the thread "End user network size [ [Q] draft-farinacci-lisp:
IPv4 address depletion]", Heiner Hummel wrote, in part:

> But imho the future solution isn't LISP and similars, instead
> it will be Nimrod however being put on its feet.

LISP, eFIT-APT, Ivip and TRRP are intended to be incrementally
deployable now or in the next few years - I guess with the idea they
are deployed substantially by 2012.

Heiner, do you have a proposal by which Nimrod:

  http://tools.ietf.org/html/rfc1992

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.

Likewise NIAA (Node Identity Internetworking Architecture):

  http://tools.ietf.org/html/draft-schuetz-nid-arch-00

I think that whatever comes out of the LISP etc. discussions needs
to be as compatible as possible with whatever might come next.

  - Robin

--
to unsubscribe send a message to [email-masked] 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

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 28 Sep 2007 09:16:41 +0300

Just as a data point:  Some people (e.g. SMA folks at Boeing) are  
already deploying HIP for specific purposes, and there is at least  
one IETF standards track WG (P2PSIP) that considers using HIP as a  
component for their solution.  In general, you often (but not  
necessarily 100% always) can deploy HIP without changing anything  
underneath or above; we listed some options in our IETF 62 plenary  
talk in 2005 [1].

Hence, HIP is no longer "long term" in that sense.  It not only has  
been fully specified and implemented (three interoperating open  
source implementations), but some folks have started to deploy it.

However, HIP as-of-today is not a solution to the routing scalability  
problem.  It is a solution (component) to those folks that need to  
combine security, mobility, and multi-homing.  To help with the  
routing scalability problem, a large fraction of the community would  
need to adopt HIP, either directly or through some type of proxying  
[2].  While that may happen "naturally" (i.e. though market  
penetration), it is far too early to tell if such wide scale adoption  
of HIP will ever take place.  Anyway, if if anyone is interested in  
going further into that direction, I guess someone should flesh out  
the HIP proxy scenarios briefly outlined in [2].

--Pekka Nikander

[1] Slides 14-25 of http://www.tml.tkk.fi/~pnr/presentations/IETF62- 
Plenary-HIP-RG-05-03-10.pdf
[2] http://tools.ietf.org/html/draft-nikander-ram-generix-proxying-00

---

From: [email-masked]
Date: Fri, 28 Sep 2007 05:36:18 EDT

In einer eMail vom 28.09.2007 04:35:09 Westeuropäische Normalzeit schreibt  
[email-masked]:

Robin,
let me start with saying NO. At least all DFZ routers would have to  comply 
with.
 
I do not mind that LISP is going to be developed, but it takes as well an  
extra load e.g. CONS.
According to my solution there wouldn't be a need for CONS. To some extent,  
this reminds me of MADCAP, a protocol to provide worldwide uniqueness for  
assigned multicast addresses. As soon as it was developed,  
single-source-multicast obsoleted that protocol. 
 
Also, it may take years to get another chance for a funding application. So  
it fits me well that LISP work is continued meanwhile.
 
Yes, I am focused on a long-term solution, which wouldn't have any  
scalability problems at all, even if the internet were 100 000 times bigger. 
 
I always was excited about PNNI's hierarchical network, but these days I  
learned that the real credits belong to Noel and his Nimrod. However it has to  
be turned over and put on its feet. Concrete: It takes a different 
understanding  of what is a hierarchical node resp. hierarchical link.
 
By watching the RRG-discussion I also see the feud between the different  
concepts (between LISP and lvip as well). This is quite natural because  
everybody likes his own ideas best. I am convinced that at some point in time in  the 
future you will like my concept, because it will provide you 
a) an interesting protocol development which may last a few years
b) and thereafter a huge land of opportunities wrt user and TE  applications 
for decades
 
Heiner

---

From: Robin Whittle <[email-masked]>
Date: Sun, 30 Sep 2007 11:18:17 +1000

Hi Pekka,

Thanks for your explanation and the links.  You wrote, in part:

> In general, you often (but not necessarily 100%
> always) can deploy HIP without changing anything underneath or above; 

My understanding is the HIP involves 128 bit Host Identifiers, to
which sockets are bound.  From this I understand that HIP can be
installed in the operating system code of an IPv6 stack, so that
IPv6-aware applications can use it.

With respect to 99.99?% of desktop and server computers used by
ordinary folk today, I think your statement doesn't apply, since
their applications do not support IPv6.

> Hence, HIP is no longer "long term" in that sense.  It not only has been
> fully specified and implemented (three interoperating open source
> implementations), but some folks have started to deploy it.

It looks like long-term to me, since I can't imagine how most
Internet users will have all or most of their applications IPv6
compatible in the next 5 to 8 years.

  - Robin

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 30 Sep 2007 10:50:57 +0300

Hi Robin,

> their applications do not support IPv6.

Well, firstly, HIP works also with 32-bit "LSI"s, which look like  
IPv4 addresses.  However, such LSIs are not globally unique, i.e.,  
the same LSI can denote different peers at different hosts.  Hence,  
third party referrals (host A referring the identity of host B,  
identifying it by its LSI, to host C) does not work in the global  
sense.  (But it can be made to work in a closed network, with some  
care.)  There are also HIP implementations that allow using routable  
IPv4 addresses as LSI, more-or-less similar to the HIP opportunistic  
mode [1].

Second, a pretty large fraction of apps running on Windows, Mac OS X,  
and Linux, work already now with IPv6.  There are probably small  
glitches here and there, as the APIs are not used by that many people  
yet, but basically the mechanisms are there.

Third, as I wrote, it is possible to use HIP with proxies.  In that  
way the local network can continue to use IPv4 or convert to IPv6,  
independent of what the ISP network uses.  But, as I wrote, the  
details of that hasn't been specified in the form of an internet  
draft, at least not yet.

Fourth, it must be understood that in the HIP case the "API version"  
of IP and the "stack version" of IP are really distinct.  You can use  
IPv6 APIs and underlying IPv4 internetworking, or vice versa.  You  
can even use one version of the API in one end and the other version  
in the other end.  For example, already 3-4 years ago we demonstrated  
at some IETF meeting how one can use IPv4-look-alike LSIs in a telnet  
client to connect to a telnet server in a way that the telnet server  
sees the connection coming from the corresponding IPv6-look-alike  
HIT.  The same applies to underlying IP: with something like SPINAT  
[2] in between you can send packets over IPv4 in the one end and  
receive them over IPv6 at the other end (and vice versa).

Finally, while the currently only specified way of using HIP is to  
use ESP as a wrapper for the data traffic, there is nothing  
architecturally specific to that.  In principle, you could use IPv4 
+UDP, IPv4+SHIM, or even plain IPv6 wrapping as well, but then you  
wouldn't get the integrity and confidentiality that HIP provides.   
(In theory, you probably could use IPv4 without UDP or SHIM too, but  
that would be pretty brittle due to all those NATs out there; at  
minimum there would be problems with checksums.)

--Pekka Nikander

[1] http://tools.ietf.org/id/draft-henderson-hip-applications-03.txt
[2] Jukka Ylitalo, Patrik Salmela, and Hannes Tschofenig, "SPINAT:  
Integrating IPsec into Overlay Routing", in Proc. of the First  
International Conference on Security and Privacy for Emerging Areas  
in Communication Networks (SecureComm'05), Athens, Greece, September  
5-9, 2005.  http://users.tkk.fi/~jylitalo/publications/SecureComm05- 
Ylitalo-et-al.pdf

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 30 Sep 2007 12:48:51 -0400 (EDT)

> From: Robin Whittle <[email-masked]>

    > a proposal by which Nimrod: ..
    > 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

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 04 Oct 2007 16:44:22 +0200

See in line,please.
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Noel Chiappa
> 发送时间: 2007年9月30日 18:49
> 收件人: [email-masked]
> 抄送: [email-masked]
> 主题: Re: [RRG] Nimrod, NIIA, HIP... as a long term solution?
> 
etc.
> 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.

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 4 Oct 2007 14:34:34 -0400 (EDT)

> From: Xu Xiaohu <[email-masked]>

    > 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 locator
namespace. 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 hierarchical
routing'? 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.

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 locator
namespace, so this comment does not make sense to me; the entire point was
that they would co-exist.

	Noel

---

From: xuxiaohu 41208 <[email-masked]>
Date: Thu, 04 Oct 2007 22:02:41 +0200

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

> 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
> still be necessary to deploy a new locator namespace to support 
> hierarchicalrouting'? That is up to the people who design that scheme.
> 
> 
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.

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

---

From: [email-masked]
Date: Thu, 4 Oct 2007 18:00:37 EDT

In einer eMail vom 04.10.2007 22:14:01 Westeuropäische Normalzeit schreibt  
[email-masked]:

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

The NIRA project I was mentioning (and which was rejected) is not related  at 
all with the URL above.
It would have been a hierarchical model with a completely different  
understanding of what is a hierarchical node and a hierarchical link compared to  PNNI 
(which in return had its roots in Nimrod). It would have adopted from  
PNNI/Nimrod the mechanism to form a hierarchical network view, that's all  (which is 
nevertheless a great concept). But no additional namespace, no  scalability 
problem, no worldwide routing churn,no prefix aggregation, and  no other 
stretch ratio than =1.
 
Noel, could you clarify wether the additional namespace in Nimrod  correlates 
to the NODE ID in PNNI, which was a 22 byte monster in addition  to the ATM 
addresses which where 20 bytes long?
 
Heiner

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 4 Oct 2007 18:33:58 -0400 (EDT)

> From: xuxiaohu 41208 <[email-masked]>

    > 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