[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    RE: Neighbor Unreachability Detection is too impatient
From:       Samita Chakrabarti <samita.chakrabarti () ericsson ! com>
Date:       2011-06-09 23:15:32
Message-ID: 16D60F43CA0B724F8052D7E9323565D71E6607EFE3 () EUSAACMS0715 ! eamcs ! ericsson ! se
[Download RAW message or body]

 
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-bounces@ietf.org [mailto:ipv6-bounces@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-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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]