Re: router-to-router NHRP (moderately long)

[Yakov Rekhter <[e-mail]>]

David,

> If we assume that most routers within a routing domain are either at one
> or the other end of a short-cut, then that set of routers must all be 
> monitoring their local routing table state. The situation with respect to
> route monitoring is then similar to that of the second alternative. The 
> difference lies in the number of NHRP messages whose path state needs to 
> be tracked and the number of purges that need to be issued.

First of all, not all routers within a routing domain should be involved
in shortcuts. I think that "access" routers (routers that interconnect
NBMA with other subnetworks) would certainly be involved in shortcuts,
but there may be other routers, and these routers would just provide forwarding
(with no shortcuts) for the traffic that can't justify shortcuts.


However, your observations wrt to the amount of state needed and the number
of purge messages required are certainly correct. The first alternative
requires less state and less purge messages (and also less keepalive traffic).
> 
> To address the problem of the number of purges, purges in this case
> should be issued based on address prefix rather than request ID - see
> earlier e-mail from Russell ([e-mail]). The
> current NHRP spec (version IV) appears to permit this via the
> destination prefix extension. However the text on the bottom of page 19
> (2nd to last paragraph) should be modified from "discard any previous
> cached information that matches the request ID." to "discard any
> previous cached information that matches the request ID or destination
> prefix if the destination prefix extension is employed."

r2r case may have certain implications on the existing messages (if we
want to reuse them). For instance, when a router wants to establish a
shortcut to a host, the router may not know whether this host is on or
off the NBMA network.  One possible alternative is to require routers
to always use r2r NHRP (and assume that r2r NHRP has a diffent format from
the existing NHRP). Another alternative is to try to fit all the
information needed for the r2r case into the existing NHRP packet
format.  We need to discuss how this should be settled.
  
> >If the status changes at
> > the router that generate NHRP Reply, this router would send Purge
> > message, so that the NHRP Requestor would issue anothe NHRP. If the
> > status changes at the Requestor, the Requestor issues another NHRP.
> > 
> > Assumption 2: once a shortcut is established, the Requestor need to
> > have some mechanism(s) to ensure that the other end of the shortcut is
> > alive (this is needed in order to avoid black holes). Among the
> > possible mechanisms are (a) indications from the Data Link layer, (b)
> > traffic in the reverse direction that comes with the Link Layer address
> > of the other end, (c) keepalives sent by the other end. I'd like
> > to get some feedback from the WG wrt whether the amount of traffic
> > due to keepalives is viewed as a problem.
> > 
> Shouldn't be a problem if the interval between keepalives is properly tuned.

What do you think should be a reasonable interval between keepalives ?

Yakov.