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

[Ray Hunter <[e-mail]>]

Thanks very much for replying.

I think that I understand the motivation in that multicast is expensive 
on some media, and that you thus want to avoid it.

I'm always prepared to be dazzled by my lack of knowledge or incorrect 
assumptions. I'd much rather ask a dumb question and get a smart answer 
than just say nothing.

The idea of the draft seems to be that spending more time performing 
unicast neighbor solicitations in the "probe" state might avoid deleting 
the neighbor entry, and thus the relearning the entry via "expensive" 
multicast NS from the "-" state.

Seems perfectly reasonable and something worth pursuing.

Erik Nordmark wrote:
> 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. 

Yes, on the local link the router injects RA information based on a 
(statically configured or PD learned) prefix. But routers and other 
devices also redistribute reachability information elsewhere via other 
protocols.

The assumption that ND really is independent of everything else is what 
I'm questioning myself, although I freely admit to a large dose of hand 
waving here. ND isn't like ARP, as you of course know.

An ARP cache entry would sit there silently for 4 hours by default and 
do nothing, so packets could black hole if the next hop was learned via 
a static route. Higher level protocols would have to detect the problem 
themselves.

ND removing an entry by NUD probe failure retriggers next hop 
determination, and AFAIK also actively triggers replying to remote nodes 
with an ICMP unreachable message, and so ND can thus can effectively 
disseminate reachability information far further than just the local link.

A later post I made gave an example of reachability info being 
indirectly based on ND (via a BGP neighbor peering TCP session becoming 
unreachable due to an ICMPv6 unreachable, leading to route information 
changing). I can imagine the same for EIGRP, OSPF if their neighbors 
disappear due to receipt of an ICMPv6 unreachable (although 
traditionally these implementations have tended to ignore ICMP for good 
reason).

Another example sort of device that sometimes transmist reachability 
information via TCP are WAN accelerators, that auto build network 
tunnels, and then send routing information across these. Again, an 
ICMPv6 unreachable might cause the device to tear down the tunnel.

HSRP preference metrics can also potentially be influenced by 
reachability information (ND) from another link (via track commands).

Then there are also those dreaded silent devices (that we don't talk 
much about but which are generally plonked on the very most critical 
link into the main data centre), such as network intrusion detection 
systems and firewalls, that actively monitor traffic across their links, 
but that don't take part in any official routing protocol exchanges, and 
can fail over to a back up system without informing anyone else by 
marking interfaces up and down.

Using the example of spanning tree, waiting for STP would probably mean 
waiting 35 seconds (max_age + forwarding delay) in the default case for 
the root bridge to send out topology notification BPDU's. That's a long 
time in many protocols.



So I guess the question is also, do you want NUD to inform higher layers 
of the need for a fail over ASAP of a local link failure via ICMP 
unreachables (as Thomas seemed to suggest), or do you want ND to shut up 
and just keep on retrying locally and let those higher layer protocols 
hit their own time outs and take their own fail over actions?

Current ND seems to go the ASAP route with its 3 second timeout. 
Historically, ARP seems to go the silent route.

It just feels to me like all nodes on a common link should behave the 
same way in this respect (no scientific argument, just raw gut feeling 
of deja vu, and impending packet storms)

And if all nodes on the link aren't behaving the same way, don't you 
still get say 50% of the multicasts as the partner nodes revert to the 
"-" state by timing out "too fast" for that link type?

Just seems like another reason to have this as a "per link" parameter 
rather than a "per node" parameter.

Best regards,
RayH