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

Thomas Narten <> Tue, 24 November 2009 19:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48CA33A67C1 for <>; Tue, 24 Nov 2009 11:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.49
X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TlTEYSd2Glfr for <>; Tue, 24 Nov 2009 11:31:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 715AE3A67A6 for <>; Tue, 24 Nov 2009 11:31:08 -0800 (PST)
Received: from ( []) by (8.14.3/8.13.1) with ESMTP id nAOJTnOE030120 for <>; Tue, 24 Nov 2009 12:29:49 -0700
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id nAOJUa8j032780 for <>; Tue, 24 Nov 2009 12:30:41 -0700
Received: from (loopback []) by (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nAOJUaIV022630 for <>; Tue, 24 Nov 2009 12:30:36 -0700
Received: from ( []) by (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nAOJUZ82022566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 12:30:36 -0700
Received: from (localhost []) by (8.14.3/8.12.5) with ESMTP id nAOJUYtS006913; Tue, 24 Nov 2009 14:30:34 -0500
Message-Id: <>
To: Ted Lemon <>
In-reply-to: <>
References: <>
Comments: In-reply-to Ted Lemon <> message dated "Tue, 24 Nov 2009 12:52:26 -0500."
Date: Tue, 24 Nov 2009 14:30:34 -0500
From: Thomas Narten <>
Subject: Re: [dna] Review of draft-ietf-dna-simple-11
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2009 19:31:09 -0000

Ted Lemon <> writes:

> Ralph asked participants in the DHC working group to review the draft, so I gave it a read.   I have some comments.   I realize that some of these comments are partially addressed in the summary message Jari sent to the list recently, but it's difficult to know what to include and what to leave out, so I just included it all.

> >From section 2.1:

>   o  False positives are not acceptable.  A host should not conclude
>      that there is no link change when there is one.

>   o  False negatives are acceptable.  A host can conclude that there is
>      a link change when there is none.

> This seems backwards, unless there is no cost to a false negative.  If
> a host concludes that there was a link change when there was none, and
> as a consequence abandons the IP addresses it was using on the
> previous link, that's going to create a (potentially noticeable)
> hiccup while it reacquires its address.  Depending on the IP stack,
> it's possible that connections might also be broken, e.g. if a syscall
> returns EHOSTUNREACH due to a transient routing outage.

Note, as a comparison point, a stack that does not implement DNA. When
the node encounters a "link up" event, that presumably also implies a
"link down" event preceding the "link up" event, and the default
course of action should be to throw away all the old configuration
information and then start the configuration process from scratch.

Thus, the concern you cite above happens today with our current
specs. DNA doesn't make things worse.

(Of course, different stacks may do different things, but from a
specification perspective, I believe the above behavior is what the
specs imply, if they don't say it explicitely.)