Re: router-router NHRP

[Yakov Rekhter <[e-mail]>]

Andrew,

Here are my comments on your response.
  
> The basic issue here seems to be that the group is trying to shoe-horn one
> protocol (NHRP) into two very different applications: (a) the host address
> convergance (short-cutting routers) protocol and (b) a router-router protocol
> to support the former. The current draft "draft-ietf-rolc-nhrp-04" admits
> this by saying that router-router cases will be described in a separate 
> specification.

I think that the issue is a bit more complex, and slightly different as well.

There are two separate issues:
   (a) eliminating extra IP hops across NBMA - "short-cut"
   (b) determining the Link Layer address at the other end of the "short cut".

What makes these issues distinct is the dynamics of the information
that is used. For solving (a) unless the ultimate destination is on the same
NBMA, the information needed to determine a short cut is the routing (IP
layer) information. This information is known to be fairly dynamic. For
solving (b) we need mapping information between IP and Data Link addresses. The
dynamics of this information is determined by how frequent an ATM node
moves from one switch to another, or how often the node has to renumber
(e.g. due to changing IP providers). This information is expected to be
less dynamic than IP routing information.

The biggest challenge for (a) is to make sure that there will be no
steady state forwarding loops. The way current NHRP adresses this
challenge is by constraining at least one of the two end-points of a
short-cut to be a host (or be 1 hop away from the end-point).  This
guarantees loop-free forwarding.

> 
> It seems like the (a) protocol is nearly complete (modulo a few simple things
> like management, auto-configuration, redundancy, scalability) and the (b)
> protocol is going to need a lot of the bolt-on extras that you discuss 
> in your message. How about we make this distinction absolutely clear to the
> outside world? Then we can really design a (b) protocol that works properly
> without the artificial constraints of keeping it backward-compatible with (a)

I think this is a very good idea. 
 
> 
> That approach would also lead to significant simplifications for the (a) prot
ocol,
> in particular allowing the addressing of first-hop queries to the NHS in
> fabric mode (significant auto-configuration and multi-protocol benefits), rat
her
> than having to wrap them in an IPgram and having to pre-configure a default N
HS.

I agree. There other simplifications that we could probably put in (a) as well.

> I don't believe that there is even a need to constrain the packet formats for
> (a) and (b) to be the same.

Agreed.

> 
> There is also an argument to be had about whether a fully specified, 100-page
> document for protocol (b) is worth writing, giving the already excessive
> number of routing protocols already in existence (this *is* a routing protoco
l
> we are talking about, regardless of what some have claimed in the past). We 
> could wait and have this later on when we see how many pages there are if you
> would prefer :-)

That is probably one area where I may have a difference of opinion with you.

As long as we wouldn't aim at a perfect solution, but rather would be willing
to settle on a solution that provides an improvement over the current situation,
I suspect that it would be much less than 100 pages. We'll see :-)

Yakov.