Re: Neighbor Unreachability Detection is too impatient

Erik Nordmark <nordmark@acm.org> Tue, 24 May 2011 16:36 UTC

Return-Path: <nordmark@acm.org>
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 20388E0764 for <ipv6@ietfa.amsl.com>; Tue, 24 May 2011 09:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level:
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 bYBrh7r8cZZ5 for <ipv6@ietfa.amsl.com>; Tue, 24 May 2011 09:36:19 -0700 (PDT)
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 52D91E0752 for <ipv6@ietf.org>; Tue, 24 May 2011 09:36:19 -0700 (PDT)
Received: from [171.70.217.188] (dhcp-171-70-217-188.cisco.com [171.70.217.188]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4OGaFMl012582 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 09:36:16 -0700
Message-ID: <4DDBDE7F.5070706@acm.org>
Date: Tue, 24 May 2011 09:36:15 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Philip Homburg <pch-v6ops@u-1.phicoh.com>
Subject: Re: Neighbor Unreachability Detection is too impatient
References: <m1QOaVe-0001pxC@stereo.hq.phicoh.net>
In-Reply-To: <m1QOaVe-0001pxC@stereo.hq.phicoh.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 16:36:20 -0000

On 5/23/11 12:09 PM, Philip Homburg wrote:
> In your letter dated Mon, 23 May 2011 11:46:29 -0700 you 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?
>
> Do you have more data on how this problem actually shows up practice?

One place where is shows up is when you have a stable network where the 
routers and hosts have neighbor cache entries for the peers they talk 
to. But then there is a short outage on the LAN, e.g., due to a switch 
or link failure causing spanning tree to recalculate things. Should 
e.g., the router start NUD at that point in time, then NUD is likely to 
discard the Neighbor Cache entries before STP is done.

Thus impact of the STP recalculation gets a lot worse, especially if 
this is in a massively scaled datacenter.

> The draft suggests that the main difference is more multicast traffic.
>
> How many hosts do you need to have on a single link for this to significantly
> impact the performance of the link?

Even if there are only two hosts, the issue is that the effect of an 
event like a STP recalculation expands due to NUD. We don't have that 
behavior with IPv4/ARP since it doesn't mandate short timeouts.

    Erik