[6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt

[Ray Hunter <[e-mail]>]

re: http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-00

I'm afraid have more questions than answers.

Are there any implications for different nodes having different NUD 
timeout behavior on a link, and this no longer being symmetrical?

If I can think of two examples......

e.g. 1. Say Node A (router) declares node C (end node) unreachable but 
Node B (alternate back up router) has not yet timed out node C?

I'm guessing this case is just like a split-brain segment, so is not 
significant compared to existing failures.

Now the case of router failover....

e.g. 2. Say Node A (end host) declares node B (router) unreachable 
locally, but node B (router) is still up and running but has not yet 
timed out Node A.

Is that significant? I suspect so. After all if the raison d'etre of 
changing NUD timers is to quicken / slow down router failover, surely 
Node B (the router) also has to time out at the same speed as the end 
host (Node A) otherwise the router will continue to advertise valid 
routes to node A, and packets will black hole/queue anyway until NUD on 
node B also notices the failure.

Vice versa is also true, if the router notices the failure first, but 
the end node does not react to the failure and hangs around retrying 
NUD, packets may queue/black hole in the other direction.

In the good old days we had things like gratuitous ARP for such events 
to attempt to wake up end nodes to refresh their cache, but if they got 
lost in some layer 2 STP thrashing it didn't help much anyway.

Is there thus a need for any over-ridden NUD parameters to be 
synchronized across all nodes on a link e.g. via RA messages?

Is there a minimum and maximum timeout needed? To prevent danger of an 
update storm [as specified in RFC2461 that all Neighbor Solicitations 
are rate-limited on a per-neighbor basis] or "stuck in stale".

regards,
RayH