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

[Yakov Rekhter <[e-mail]>]

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

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.