I support this draft. Allowing  > 3 retransmit is useful even for low-power 
nodes as it saves power of processing/signalling for rebuilding the NCEs for 
sleepy nodes.

It'll be good to specify a default MAX_*_CAST_SOLICIT value and a max-value in 
the draft for the deployment/implementation when there is no default 
alternative router in the link. This will save some additional signaling 
traffic noise in the event of misconfiguration. 

-Samita


-----Original Message-----
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Erik 
Nordmark
Sent: Monday, May 23, 2011 11:46 AM
To: ipv6@ietf.org
Subject: Neighbor Unreachability Detection is too impatient


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-dra...@ietf.org
To: nordm...@cisco.com
CC: nordm...@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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to