RIPng

[Steve Deering]

Dimitry,

> I'm not sure that a router sending multicast routing updates should ever care
> if his updates are reaching all neighboring routers (and if he learned that
> they don't, what he is going to do about that?).

Well, there are examples in multicast routing (e.g., broadcast-and-prune
style algorithms like DVMRP or PIM-DM), where I might end up waiting for
a prune from a neighbor that I can hear, but who can't hear me and will
therefore never send a prune.  If I don't happen to also have any unicast
traffic to send via that router, then NUD won't help me detect the failure.

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.  But first, let
me explain what I had in mind, and let me know what you think.

What we are were planning on doing as part of our RIPng++ experiment was
to add periodic RIP Hello messages, which would carry a list of all routers
on that link from whom the sending router had heard a Hello within the last
n seconds (n = some small multiple of the Hello interval); if Router A fails
to see its own address in the Hellos from Router B, that indicates that
B cannot hear A and, therefore, A should ignore B's routing advertisements.
Relative to using NUD, this scheme would appear to have the following
advantages:

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

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

The latter point seems important for RIP -- I can know not to update my
routing table with info from a deaf neighbor who offers the shortest path
to a given destination, rather than doing the table update and then later
learning that the neighbor is deaf when I send data packets into that black
hole (and then I have to remember not to believe subsequewnt routing messages
from that deaf neighbor, at least not for a while [in case it recovers its
hearing], ...).

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

> And, if a router relying on the reception of routing updates does
> not get them or can't use them for lack of reachability to the advertiser,
> someone will scream rather sooner than later. 

I'd like to do better than waiting for someone to scream.  We had an incident
here where an Ethernet board went dead in one direction in a machine
running mrouted, which caused a multicast packet loop that was very nasty
and very hard to diagnose.  I would have been much happier having my
router scream at me (via its logging mechanism) and eliminate the loop,
than having the users screaming at me.

Steve