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

"Bernard Aboba" <bernard_aboba@hotmail.com> Tue, 24 November 2009 18:14 UTC

Return-Path: <bernard_aboba@hotmail.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 38AB928C0DD for <dna@core3.amsl.com>; Tue, 24 Nov 2009 10:14:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.865
X-Spam-Level:
X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_05=-1.11]
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 v90w1LEKVogb for <dna@core3.amsl.com>; Tue, 24 Nov 2009 10:14:14 -0800 (PST)
Received: from blu0-omc4-s20.blu0.hotmail.com (blu0-omc4-s20.blu0.hotmail.com [65.55.111.159]) by core3.amsl.com (Postfix) with ESMTP id 45D8B28C114 for <dna@ietf.org>; Tue, 24 Nov 2009 10:14:14 -0800 (PST)
Received: from BLU137-DS7 ([65.55.111.135]) by blu0-omc4-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 10:14:09 -0800
X-Originating-IP: [24.19.160.219]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS73E18DE98C51F0EB7703C939D0@phx.gbl>
From: "Bernard Aboba" <bernard_aboba@hotmail.com>
To: "'Ted Lemon'" <mellon@fugue.com>, <dna@ietf.org>
References: <B3D250DF-D059-48D3-8867-CB1645038382@fugue.com>
In-Reply-To: <B3D250DF-D059-48D3-8867-CB1645038382@fugue.com>
Date: Tue, 24 Nov 2009 10:14:22 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcptLuTq2KBG1odbSZW5OOLQvFqBIQAAqEtw
Content-Language: en-us
X-OriginalArrivalTime: 24 Nov 2009 18:14:09.0643 (UTC) FILETIME=[EAF80BB0:01CA6D31]
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: Tue, 24 Nov 2009 18:14:15 -0000

Ted Lemon said:

"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."

The paragraphs above do not correctly define the meaning of "false positive"
and
"false negative".  Here is what RFC 4436 says:

      o  As a performance optimization, it must not sacrifice
         correctness.  In other words, false positives are not
         acceptable.  DNAv4 must not conclude that a host has returned
         to a previously visited link where it has an operable IP
         address if this is not in fact the case.

      o  As a performance optimization, false negatives are acceptable.
         It is not an absolute requirement that this optimization
         correctly recognize a previously visited link in all possible
         cases.  For example, if a router ignores unicast ARP Requests,
         then DNAv4 will not be able to detect that it has returned to
         the same link in the future.  This is acceptable because the
         host still operates correctly as it did without DNAv4, just
         without the performance benefit.  Users and network operators
         who desire the performance improvement offered by DNAv4 can
         upgrade their routers to support DNAv4.