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"<[email protected]> 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: [email protected]
To: [email protected]
CC: [email protected]
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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
