Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt

Thomas Narten <narten@us.ibm.com> Tue, 24 May 2011 12:50 UTC

Return-Path: <narten@us.ibm.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 CDA40E06A2 for <ipv6@ietfa.amsl.com>; Tue, 24 May 2011 05:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Nv-k8FZSksva for <ipv6@ietfa.amsl.com>; Tue, 24 May 2011 05:50:02 -0700 (PDT)
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85BE066A for <ipv6@ietf.org>; Tue, 24 May 2011 05:50:02 -0700 (PDT)
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4OCWfb8015033 for <ipv6@ietf.org>; Tue, 24 May 2011 06:32:41 -0600
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p4OCnsAc157232 for <ipv6@ietf.org>; Tue, 24 May 2011 06:49:55 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4O6nsR8003930 for <ipv6@ietf.org>; Tue, 24 May 2011 00:49:54 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-65-251-50.mts.ibm.com [9.65.251.50]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4O6nqs1003820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 00:49:53 -0600
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4OCnpfS006392; Tue, 24 May 2011 08:49:51 -0400
Message-Id: <201105241249.p4OCnpfS006392@cichlid.raleigh.ibm.com>
To: Ray Hunter <v6ops@globis.net>
Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt
In-reply-to: <4DDABDA6.2070705@globis.net>
References: <4DDABDA6.2070705@globis.net>
Comments: In-reply-to Ray Hunter <v6ops@globis.net> message dated "Mon, 23 May 2011 22:03:50 +0200."
Date: Tue, 24 May 2011 08:49:51 -0400
From: Thomas Narten <narten@us.ibm.com>
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 12:50:02 -0000

Ray Hunter <v6ops@globis.net> writes:

> Are there any implications for different nodes having different NUD 
> timeout behavior on a link, and this no longer being symmetrical?

I do not think so.

> e.g. 1. Say Node A (router) declares node C (end node) unreachable but 
> Node B (alternate back up router) has not yet timed out node C?

IMO, this should not be an issue. 

> Now the case of router failover....

> e.g. 2. Say Node A (end host) declares node B (router) unreachable 
> locally, but node B (router) is still up and running but has not yet 
> timed out Node A.

At this point there is already a problem, because packets  do not seem
to be flowing. The sooner both peers recognize that the path is not
working and find an alternative the better.

But by definition, the two peers will *never* be able to determine
this situation at *exactly* the same time. That is, there will always
be cases where NodeA determines NodeB is unreachable before NodeB
detects NodeA is unreachable (and vice versa).

While it would be better to have both peers determine that the path to
each other is down ASAP, there is not and has never been a requirement
that both peers detect that a path is not working at the same time.

Thomas