Re: Neighbor Unreachability Detection is too impatient

sowmini.varadhan@oracle.com Tue, 24 May 2011 13:33 UTC

Return-Path: <sowmini.varadhan@oracle.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29CAE06ED for <ipv6@ietfa.amsl.com>; Tue, 24 May 2011 06:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4m90zShgeTK for <ipv6@ietfa.amsl.com>; Tue, 24 May 2011 06:33:17 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9BCE06BA for <ipv6@ietf.org>; Tue, 24 May 2011 06:33:17 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p4ODXCt2011122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2011 13:33:14 GMT
Received: from quasimodo.us.oracle.com (quasimodo.us.oracle.com [10.152.12.37]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4ODXBjp027752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 13:33:12 GMT
Received: from quasimodo.us.oracle.com (localhost [127.0.0.1]) by quasimodo.us.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4ODLSUs015424; Tue, 24 May 2011 09:21:28 -0400 (EDT)
Received: (from sowmini@localhost) by quasimodo.us.oracle.com (8.14.4+Sun/8.14.4/Submit) id p4ODLRRR015423; Tue, 24 May 2011 09:21:27 -0400 (EDT)
X-Authentication-Warning: quasimodo.us.oracle.com: sowmini set sender to sowmini.varadhan@oracle.com using -f
Date: Tue, 24 May 2011 09:21:27 -0400
From: sowmini.varadhan@oracle.com
To: Erik Nordmark <nordmark@acm.org>
Subject: Re: Neighbor Unreachability Detection is too impatient
Message-ID: <20110524132127.GB15274@quasimodo.us.oracle.com>
References: <4DDAAB85.8000103@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4DDAAB85.8000103@acm.org>
User-Agent: Mutt/1.5.21+23 (f7160c94ff70) (2010-12-30)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4DDBB39A.0147:SCFMA922111,ss=1,fgs=0
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2011 13:33:18 -0000

On (05/23/11 11:46), Erik Nordmark 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?

I think the intention is to use impatient-NUD only when the unicast NS
has been triggered by a packet whose IP destination is offlink, i.e.,
the IP destination is different from the target of the NS, so
impatient-NUD should only be applied for router NCE's (and only when
the triggering packet has a different IP destination than the NCE target). 

But if the motivation is to avoid sending mcast NS where possible, it might
not be achieved in a few other cases that we can still catch. 
E.g., even for offlink IP destinations, the switch to an alternative
default router might also result in triggering mcast NS if the new
router itself has not been resolved yet.  If the objective is to avoid
sending multicast NS, impatient-NUD would only be useful in reducing
mcast traffic if the alternative NCE is in REACHABLE/STALE/PROBE/DELAY
state. Would it make sense to REQUIRE impatient-NUD only under that
specific circumstance?

--Sowmini