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

[[e-mail]]

Yakov,

> David,
> 
> > 
> > This is a much simplified problem-scope as compared to your earlier
> > proposals.  Are the earlier proposals no longer under consideration? If
> > so, an explanation would be helpful.
> 
> As you recall, in the message I sent earlier, constaining shortcuts to
> a single routing domain was one of the option, but the problem with
> this option was due to the possibility of not being able to detect
> routing domain boundary. Since NHRP now requires fabric mode, this
> guarantees that all border routers within a domain are NHRP capable.
> The second alternative that was proposed has certain scaling problems
> (which were mentioned in the message). The third alternative that was
> proposed could require non-neglidgeable amount of control traffic,
> which caused some concerns.
> 
> > Also I did not see any discussion of how loop free cut-through paths are
> > guaranteed. I think that also would be helpful to the group.
> 
> There are few assumptions that I didn't state in my message:
> 
> Assumption 1: both ends of a shortcut would motior the status of the
> route that was associated with the shortcut. 

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.

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

I am still mulling around in my mind whether this change is 
sufficient to keep your alternative 2 alive as a contender!

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

> Assumption 3: a requestor should establish a shortcut only after the
> requestor determines that the information provided by NHRP is fairly
> stable (e.g., didn't change over the last few minutes). This is
> necessary in order to avoid initiating shortcuts that are based on
> transients routing information.
> 
> I don't have (yet) a formal proof that these two mechanisms are sufficient
> to prevent forwarding loops (although, I think I can construct such proofs
> for the protocols I listed). On the other hand, if you look at the examples
> of the forwarding loops that were posted to this list so far, it seems
> that these two mechanisms + constraining shortcuts to a single routing
> domain would fix the problems shown in the examples.
> 
> Yakov.
> 
Thanks,
david.