Re: R2R NHRP - ensuring far end is alive

[Yakov Rekhter <[e-mail]>]

Matt,

> Yakov (and other ROLCers),
> 	Your current R2R approach requires that "Once a shortcut is 
> established, the Requester needs to have some mechanism(s) to ensure that 
> the other end of the shortcut is alive."
> 	Possible mechanisms suggested are:
> (a) indications from the Data Link Layer
> (b) prescence of traffic in the reverse direction that comes with the Link 
> Layer address of the other end
> (c) keepalives sent by the other end
> 
> 	In some situations, keepalives may be the only option. 
> Additionally, a "hello" time (meaning as for OSPF) of the order of 10
> seconds might be required/desired. (For instance if IP encapsulated SNA is
> being sent to a mainframe which has two connections to the NBMA (for
> redundancy) ).
> 	I'm trying to understand how things would behave under such
> conditions. Especially, what is the impact of such a high rate of
> keepalives likely to be on both the network and routers ? 

You are certainly correct - in some situations keepalives may
be the only option. Moreover, these keepalives may be needed
not only for the R2R case, but for *all the cases* where a
destination is not on the NBMA network and there is more
than one path from the NBMA network to the destination.

In fact, one could observe that the problem we're trying to solve
is quite similar to the "dead router" detection problem.

Wrt to the impact on the network and routers, observe that the keepalive
traffic could (and probably should) be sent over the same shortcut
as the data. So, it is only the originator of the shortcut and
the egress router (the other end of the shortcut) that would be
involved. Also observe that the keepalive traffic is going to
be a very small fraction of the total traffic that would flow
through the shortcut, and handling of the keepalive traffic
is fairly straightforward (in terms of processing). So, the
expectation is that the amount of keepalive traffic would
be within the limits of available resources.

Yakov.