RIPng

[(Mike Shand REO2 G/C2 DTN:830-4424)]

Steve,

> But for the case of unicast routing (like RIPng), I think you're right --
> doing NUD on the forwarded traffic would suffice.  In which case, it becomes
> a question of whether or not it still might be better to use some other
> approach -- I have always thought that routing protocols either do or ought
> to do their own neighbor reachability verification, and that the need for
> NUD in IPv6 was to handle the case where one or both of the neighbors is
> a host.  I should probably flush that particular mindset.  

I must confess that I too have that mindset. 

> 	- fewer packets than NUD on a busy link: N Hellos per interval,
> 	  instead of up to 2N(N-1) ND packets per interval; note that,
> 	  as in the router->host case, router->router NUD cannot take
> 	  advantage of upper-layer info to suppress the NUD pings.
>

This seems like a big win to me. Maybe not for RIP which traditionally
is slow to reconfigure, but certainly for OSPF and (dare I say it) integrated
IS-IS which tend to be used in situations where very rapid response to
router failure is required. If the interval is of the order of a second
the extra load from the full mesh conectivity checks becomes significant.
However, even for RIP is seems to me that the efficency gain is worthwhile.
Of course this is not particularly relevant to the tunnel case which first
prompted this discussion.
 
> 	- can detect failure of a neighbor *before* sending any packets
> 	  to it, and therefore need not drop or delay any data packets
> 	  while waiting for NUD to time out.

Presumably since the RIP packets are multicast you don't trigger NUD on the
sending of the RIP packets themselves rather than the data. Would that also
be true over a pt-pt link (e.g. tunnel)? 

> The disadvantage of my proposal is that it is an additional mechanism that
> is not strictly necessary.

Yes, but it doesn't rely on a somewhat tenuous connection between
the operation of the routing protocol and the forwarding process.

On the other hand you could argue that such a connection is exactly what you
do want. Examples abound of problems arising where the connectivity
indicated by the routing protocol neighbor detection is different from that
actually existing for the data itself. This is presumably one reason for
the (to my mind) somewhat incestuous relationship of IP routing protocols
running over IP. Of course that doesn't completely remove the problem, but
it goes some way to reduce its likelyhood. 

On balance I would feel more comfortable with an explicit mechanism along the
lines of Steve's proposal. OSPF or course already has such a mechanism.

	Mike