Re: Application Statement

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Bruce Cole writes:
> > 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 the
> y
> may be if you're redistributing between dissimilar routing protocols.
> So whether or not you can have persistent routing loops depends upon
> your configuration.

RIP was a quick hack of a routing protocol and only exists because of
the availablity of an implementation in routed for a decade and a
half.  The existance of one broken protocol should not be used as an
excuse to introduce a brand new known broken protocol.

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

IPX has always had a scalable solution.  Encapsulate it in IP.  :-)

Is a "solution" that causes routing loops when you put extra (back
door) links in for redundancy to your building(s) that still have
ethernet hubs wired up (and actually have occasion to use that
redundancy) really a solution?  Or is it snake oil?

The loop example could just as easily be building A, B, and C, with
back doors due to existing wiring (existing copper campus wiring, for
example, backup DS0s or DS1s) and a sequence of links go down.

    NBMA     ------ Rx .... A .
                            .  .
                           .   .
                        . R1   . A-C is
             --- Ry .. B   .   . slower
                        . R2   .
                           .   .
                            . .
             ------ Rz .... C.

Ry, Rz prefer NBMA route to get to A, if there is one.  Rx to A goes
down.  Ry has an alternate through B, so it uses that.  Rz gets
traffic for A and sends to Ry, since Rx can't reach it and NBMA is
preferred.  R2 now has a route to R1 and a backup route to C, which it
would normally use only if R1 and Ry went down.  Currently Ry is not
advertising a route for A to B since traffic is going toward B.  Now
R1 goes down.  R2 has a route to B.  Dynamic routing converges fast,
so B points to R2 and Ry now points to B.  But Rz still points to B
since it prefers NBMA routes and B thinks it still has a route to A
through R2.  Stable routing loop.  Note that there is a viable path
from C to A, but the path through Rz is preferred.

So much for the customer's redundancy.  In the worst case Rx comes
back up but gets no NHRP requests since Ry is perfectly happy with its
route to A through R2, and C and Rz are perfectly happy with their
route through the NBMA to get to A through Ry.

If a routing protocol were running, this obviously doesn't happen
(unless the routing protocol is RIP).  If BGP was in use (with the
customer accepting his own AS in the AS path to facilitate AS
partition repair (in this case prefering a partition repair to an
internal route), the NBMA would not accept the route with the NBMA AS
in the AS path (the customer is not allowed to heal partitions of the
NBMA) and break the loop when the AS path from Ry changed (since Rz
learned its route from the NBMA AS).  Rz then loses it's route through
the NBMA and C starts using the route 

In the RIF scheme, Rx, Ry, and Rz would take a default route and send
RIFs to better resolve next hops, including to each other, and
probably send some traffic through an extra hop (like an occasional
DNS query, when there has been no other activity for a while and no VC
is up).

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

So do simpler techniques like NARP and directed ARP.

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

We have established that routing loops can be formed that can only be
prevented by carrying the full routing attributes that exist for the
purpose of preventing routing loops.  The need for these attributes is
the reason every major Internet service provider must run IBGP today
(due to the lack of ability to carry full attributes in any IGP
available today - since no one every did LSA 8 in OSPF).

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

If you have all hosts, then you are using it as an address resolution
protocol.  What is so bad about that.  

If we continue with NHRP we need to be very clear about its
limitations.  We can probably also trim the protocol a bit.  For
example, why define a QoS option that is entirely TBD.  Why not just
resolve the address and let RSVP (or whatever) handle QoS, or define
the option when someone has a clue as to what to put in it.

The disclaimer in 8.1 should probably be clarified and the abstract
and other places that make host to router claims should not that there
are limitations described elsewhere in the document that need to be
considered.  I suggest the following:

  NHRP is an address resolution protocol and is not a substitute for a
  routing protocol.  For destinations behind NHRP capable routers that
  have a single attachment point to the NBMA, a proxy address
  resolution can be performed (analogous to proxy ARP and with similar
  limitations of applicability).

Some might call it critical of NHRP.  It is simply a clear statement
of the truth, with no attempt to offer NHRP for a purpose for which it
is not at all well suited.

Curtis