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
- Neighbor Unreachability Detection is too impatient Erik Nordmark
- Re: Neighbor Unreachability Detection is too impa… Wes Beebee
- Re: Neighbor Unreachability Detection is too impa… Mark Townsley
- Re: Neighbor Unreachability Detection is too impa… Philip Homburg
- Re: Neighbor Unreachability Detection is too impa… Thomas Narten
- Re: Neighbor Unreachability Detection is too impa… sowmini.varadhan
- Re: Neighbor Unreachability Detection is too impa… Erik Nordmark
- Re: Neighbor Unreachability Detection is too impa… Erik Nordmark
- Re: Neighbor Unreachability Detection is too impa… Erik Nordmark
- RE: Neighbor Unreachability Detection is too impa… Hemant Singh (shemant)
- Re: Neighbor Unreachability Detection is too impa… Philip Homburg
- Re: Neighbor Unreachability Detection is too impa… Erik Nordmark
- Re: Neighbor Unreachability Detection is too impa… Erik Nordmark
- RE: Neighbor Unreachability Detection is too impa… Hemant Singh (shemant)
- Re: Neighbor Unreachability Detection is too impa… Philip Homburg
- Re: Neighbor Unreachability Detection is too impa… Mikael Abrahamsson
- Re: Neighbor Unreachability Detection is too impa… Erik Nordmark
- Re: Neighbor Unreachability Detection is too impa… Philip Homburg
- Re: Neighbor Unreachability Detection is too impa… Erik Nordmark
- Re: Neighbor Unreachability Detection is too impa… Thomas Narten
- Re: Neighbor Unreachability Detection is too impa… Erik Nordmark
- RE: Neighbor Unreachability Detection is too impa… Alan Kavanagh
- RE: Neighbor Unreachability Detection is too impa… Samita Chakrabarti