RIPng

[dhaskin@baynetworks.com]

Steve,

> Dimitry,
> 
> > I'm not sure that a router sending multicast routing updates should ever care
> > if his updates are reaching all neighbouring 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.
>
I was talking about RIPng.  I agree if a routing  protocol 
(unicast or multicast) relies on two-way communications for its 
integrity it should be able to detect failures in such communications.

> 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.
>
It seems as a nice simple mechanism.  As far as RIPng is concerned, 
I have the following reservations:

- in places where RIP is still used between routers most of the 
routers (typically in stubs domains) don't generate routing 
advertisements themselves but only listen to RIP advertisements 
from one or two routers in a transit domain.  In such typical setups 
the proposed mechanism would not work unless you also require for 
RIP updates to be always sent even if only empty one.

- I view RIPv6 as a temporary solution for routing exchange between 
routers -- only to buy time until OSPFv6 and IDRP are developed. If 
you agree with this premiss, it would be difficult to justify an 
additional effort beyond research purposes to improve RIPv6 in its
operation between routers.  As far as RIP snooping by hosts, it is 
quite common today and I believe, good or bad, it, the most probably, 
will continue to be used in IPv6 by multihomed hosts.  Your proposal 
would not not help here either.

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

> Steve
> 
Dimitry