Re: Application Statement

[Bruce Cole <[e-mail]>]

> Ref:  Your note of Fri, 03 Mar 1995 14:20:35 -0500
> 
> 
> Jeffrey,
> 
> >While NHRP is certainly not a panacea for all the worlds routing
> >problems, to lobby for language whose only purpose is to denegrate
> >this solution as unworthy of deployment is, in my opinion, excessive.

I second this.  While NHRP can lead to routing loops, it can be configured
in such a way that it will not.  Routing protocols such as RIP can lead to
routing loops too, yet they have proven very useful.  Now you're probably
thinking: bad analogy because RIP routing loops are not persistent.  Well they
may be if you're redistributing between dissimilar routing protocols.
So whether or not you can have persistent routing loops depends upon
your configuration.

> On the other hand stating that
> 
>     "It is recommended that during Router-to-Router operation, options that
>     help to detect loops be invoked and NHRP requests be reissued
>     periodically."
> 
> strikes me as wishful thinking.

Certainly.  Now that the looping problem is better understood by all, it
is time to reword the draft.

I think it would be unfortunate for us to require IP routing protocol
specific solutions to this problem.  I've seen proposed solutions for BGP4 and
IDRP only.  IDRP is (as far as I know) not widely implemented, and BGP4 is one
of the more difficult IP routing protocols to configure (at least here).

If we throw up our hands on NHRP and go with routing protocol specific
mechanisms, then the single solution goal of the ROLC group is not met, and
other network layers such as IPX are left without a solution.

> >There are a great many cases where NHRP would be very effective and where
> >the routing loop problem would not arise.
> 
> It would certainly help if you'll enumerate these cases that involve
> router-to-router, and explain how NHRP mechanisms would help to prevent
> routing loop problem.

Imagine an NBMA network with a single CIDR block allocated to it.  Ie all
the stations on the NBMA net have IP addresses within the CIDR block, and
all IP stations off the net have IP addresses outside the CIDR block.
Configure NHRP to only do address resolution for destinations within the CIDR
block.  NHRP provides single hop, full mesh connectivity for the NBMA network,
without a routing loop.

Extending NHRP to be aware of topology changes, or perhaps even to generate
changes of its own would seem to be a possible solution for a class of more
complex networks.  Joel mentioned the former, but I don't think we
settled on whether or not this would be viable for a certain class of networks.

If the large cloud consists mostly of hosts not routers, there is the choice
of constraining NHRP to only be used by the hosts, not the routers.  NHRP
could still be quite useful, even for those classes of networks in which NHRP
would otherwise cause loops.

Now, it may be that the most common large clouds being designed consist
predominantly of routers that fall into the class of networks exemplified by
Joel's Feb. 3rd topology from hell.  In that case, it seems that "NHRP is not
at all viable except as an address resolution protocol", like Curtis said.  I
don't think we have yet reached this conclusion.