On 5/23/11 1:03 PM, Ray Hunter wrote:
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?
No - the reachability state in RFC 4861 is unidirectional. This can
easily happen today on a host when TCP provides reachability
confirmations to the IP stack, which just indicates forward reachability
to the nexthop router. The return traffic might arrive to the host from
a different router.
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.
Are you assuming that the routers inject host routes into the routing
system based on the ND state? The routers inject a route for the subnet
prefix which isn't tied to the ND state in any way.
(If you look at 6lowpan plus roll you'll see a different behavior, which
is part of the reason for having explicit host registration in
draft-ietf-6lowpan-nd.)
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?
No.
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".
A rate limit makes sense. RFC 4861 already has this with one per second.
If ND retransmits more than three times it probably makes sense to
recommend binary exponential backoff for the timer.
Erik
regards,
RayH
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
