Re: [dna] Review of draft-ietf-dna-simple-11

Erik Nordmark <erik.nordmark@sun.com> Mon, 07 December 2009 14:14 UTC

Return-Path: <erik.nordmark@sun.com>
X-Original-To: dna@core3.amsl.com
Delivered-To: dna@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0745B3A68B6 for <dna@core3.amsl.com>; Mon, 7 Dec 2009 06:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.701
X-Spam-Level:
X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZeUnQH-1ytH for <dna@core3.amsl.com>; Mon, 7 Dec 2009 06:14:34 -0800 (PST)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 35B833A6887 for <dna@ietf.org>; Mon, 7 Dec 2009 06:14:34 -0800 (PST)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB7EDsDo008715; Mon, 7 Dec 2009 14:14:00 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nB7EDpuY651800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Dec 2009 06:13:53 -0800 (PST)
Message-ID: <4B1D0D9E.3070203@sun.com>
Date: Mon, 07 Dec 2009 06:13:50 -0800
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090929)
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <B3D250DF-D059-48D3-8867-CB1645038382@fugue.com> <BLU137-DS7F1790D475CB4996E045E939D0@phx.gbl>
In-Reply-To: <BLU137-DS7F1790D475CB4996E045E939D0@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dna@ietf.org
Subject: Re: [dna] Review of draft-ietf-dna-simple-11
X-BeenThere: dna@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <dna.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dna>
List-Post: <mailto:dna@ietf.org>
List-Help: <mailto:dna-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 14:14:35 -0000

Bernard Aboba wrote:
> Ted Lemon said:
> 
> "More, from section 4.3:
> 
>   It SHOULD also set all Neighbor
>   Cache entries for the routers on its Default Router List to STALE.
>   This is done to speed up the acquisition of a new default router when
>   link change has occurred.
> 
> It's my impression that by default, a stale routing table entry won't
> be used, so if an application writes to an open tcp connection while
> the routing table entry is stale, it will get an EHOSTUNREACH, and the
> connection will be dropped.  I have had this exact experience with
> IPv4 DNA implementations when my WiFi router signal is flaky.  This is
> much worse than taking a long time (500ms isn't really that long) to
> identify a new link.
> 
> This would also be a problem in the case where you are on a WiFi
> network with more than one device advertising the same SSID - when you
> switch to a new beacon, arguably this is a DNA event, but it would clearly
> be a mistake to break existing connections in this case.
> 
> [BA] I agree that the paragraph cited does not make sense.  RFC 4436 does
> not contain equivalent advice.  In general, Simple DNAv6 should seek to 
> minimize connectivity disruption. 

Perhaps the reference to "STALE" is not clear above?
STALE refers to a state in RFC 4861 which implies that the host would 
trigger NUD sooner rather than later. If it isn't set to STALE then it 
might take up to 30 seconds more to detect that a router has gone dead. 
Thus a neighbor cache entry of STALE doesn't have anything to do with a 
routing table entry (unless the implementation is broken.)

    Erik