Re: Neighbor Unreachability Detection is too impatient

On 5/23/11 12:25 PM, Wes Beebee wrote:
> Erik,
>
> I have seen NUD packets dropped during congestion, and for traffic to
> periodically drop out for re-resolution.  I agree with the goal of making
> NUD more robust.  However, there may be other approaches besides
> retransmitting more times.

Agreed. For instance, it makes sense to consider whether the Address 
Registration option in draft-ietf-6lowpan-nd is something that should be 
applied outside of 6lowpan.

However, such approaches imply a change to hosts and routers.

Relaxing the constraints on the ND retransmissions is something which 
doesn't require a coordinated rollout of router and host changes.
Hence I think we need to relax the retransmission constraints now, while 
looking at future directions.

    Erik

> - Wes
>
> On 5/23/11 2:46 PM, "Erik Nordmark"<nordmark@acm.org>  wrote:
>
>>
>> This draft proposes to change the requirement that NUD can not
>> retransmit more than three times, so that NUD can be more robust against
>> temporary network outages.
>>
>> Comments?
>>
>>      Erik
>>
>> -------- Original Message --------
>> Subject: New Version Notification for
>> draft-nordmark-6man-impatient-nud-00.txt
>> Date: Mon, 23 May 2011 11:43:16 -0700
>> From: internet-drafts@ietf.org
>> To: nordmark@cisco.com
>> CC: nordmark@cisco.com
>>
>> A new version of I-D, draft-nordmark-6man-impatient-nud-00.txt has been
>> successfully submitted by Erik Nordmark and posted to the IETF repository.
>>
>> Filename:  draft-nordmark-6man-impatient-nud
>> Revision:  00
>> Title:   Neighbor Unreachability Detection is too impatient
>> Creation date:  2011-05-23
>> WG ID:   Individual Submission
>> Number of pages: 5
>>
>> Abstract:
>>      IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.
>>      That function is very useful when a host has an alternative, for
>>      instance multiple default routers, since it allows the host to switch
>>      to the alternative in short time.  This time is 3 seconds after the
>>      node starts probing.  However, if there are no alternatives, this is
>>      far too impatient.  This document proposes an approach where an
>>      implementation can choose the timeout behavior to be different based
>>      on whether or not there are alternatives.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>