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

[Ray Hunter <[e-mail]>]

Philip Homburg wrote:
> In your letter dated Mon, 23 May 2011 23:10:09 +0200 you wrote:
>    
>> Who says that NUD can't also be used to declare an interface down/
>> detect router neighbor loss?
>>
>> Maybe think of a BGP process running over TCP receiving ICMP
>> unreachables because the local NUD has declared the neighbor
>> unreachable. Meanwhile the other BGP partner router is still retrying at
>> TCP layer because NUD has not timed out on that node. Or am I seeing
>> non-existent links here?
>>      
>
> Let's say router A declares router B unreachable because of some ND problem.
> Meanwhile router B still considers router A reachable.
>
> Now obviously, router A (and the routing system) will try to avoid routing
> packets from A to B because that link is down.
>
> B still assumes that A is reachable so it will continue to forward packets to
> A. As long a A does not drop those packets, everything will be fine. I don't
> think there is a reason to drop incoming packets when a neighbor on a link is
> unreachable, but if an implementation does that, then that will break the
> independence and will cause problems.
>
> But for relatively stable links consisting of just BGP peers, it may make more
> sense to just hardwire the ND entries and disable ND.
>
>
>    
You are probably 100% correct for BGP. And I'm reasonably convinced BGP 
is relatively bullet-proof (even if one well-known network provider that 
I know does not give BGP TCP sessions priority over normal user traffic, 
so BGP neighbors can flap on high user load.) It was just one example 
off the top of my head of a dependency.

The only point I'm making is that there may well be stuff out there that 
has become reliant on the current symmetrical behavior of NUD. ARP 
caches generally took a very long time before they started sending back 
an ICMP unreachable. AFAIK NUD is pretty instantaneous once it declares 
something unreachable.

It was after all a selling-point of NDP and neighbor discovery in 
general that it "fixed" the half-open link problem.

RFC 2461 "Unlike ARP, Neighbor Discovery detects half-link failures"

And now it mightn't live up to that promise: at least in transitory 
situations that might last for an extended period of comparable duration 
to timeouts in other protocol layers / applications, unless the timers/ 
retry counts are synchronized across all nodes on the link. Timers and 
race conditions can be very tricky to catch/ debug, as I'm sure you know.

Just raising a flag. Maybe this is significant, maybe not. Just thought 
I'd ask.

regards,
RayH