Re: [dna] AD review of draft-ietf-dna-simple

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 25 August 2009 04:16 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 C56F828C1D2 for <dna@core3.amsl.com>; Mon, 24 Aug 2009 21:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.025
X-Spam-Level:
X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[AWL=1.573, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 HZ3RfTXTjGVJ for <dna@core3.amsl.com>; Mon, 24 Aug 2009 21:16:25 -0700 (PDT)
Received: from blu0-omc2-s13.blu0.hotmail.com (blu0-omc2-s13.blu0.hotmail.com [65.55.111.88]) by core3.amsl.com (Postfix) with ESMTP id 70B0B28C340 for <dna@ietf.org>; Mon, 24 Aug 2009 21:16:25 -0700 (PDT)
Received: from BLU137-W31 ([65.55.111.72]) by blu0-omc2-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 21:16:31 -0700
Message-ID: <BLU137-W31D2A60E1CF54188BF229A93F80@phx.gbl>
Content-Type: multipart/alternative; boundary="_85200a1b-2a91-4d70-b3e2-8b81b3906fcf_"
X-Originating-IP: [12.42.66.130]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Jari Arkko <jari.arkko@piuha.net>, Suresh Krishnan <suresh.krishnan@ericsson.com>
Date: Mon, 24 Aug 2009 21:16:31 -0700
Importance: Normal
In-Reply-To: <4A92457A.80009@piuha.net>
References: <4A55E27D.80200@piuha.net> <BLU137-W109A872CE0057E72AD0EF93260@phx.gbl> <BLU137-W28F2FFB5232BC48619BF5E93210@phx.gbl> <4A5FABFE.2030209@ericsson.com> <4A92457A.80009@piuha.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Aug 2009 04:16:31.0942 (UTC) FILETIME=[D3743660:01CA253A]
Cc: dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org
Subject: Re: [dna] AD review of draft-ietf-dna-simple
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, 25 Aug 2009 04:16:26 -0000

In DNAv4 we examined the use case of switching between manually configured addresses.   

This is something that could not be done prior to DNAv4, but is possible with it. 

However, it became clear that there were some problems:

1. DNA probe retransmission strategy.  In typical situations little or no retransmission of DNA probes is required, since if the probes are lost, the normal dynamic assignment mechanisms (with their retransmission schemes) will still function.  However, if the address is assigned manually, the dynamic assignment alternative may not be available.  Therefore DNA probe retransmission needs to be more aggressive, or else risk not assigning an address at all, or possibly (see below) assigning the wrong address. 

2. Where an address is assigned manually in one network but dynamically assigned on another, it is necessary for the host to use dynamic assignment mechanisms, in case it turns out to be attached to a network on which dynamic assignment is practiced.  However, when it is attached to the "manual assignment" network using both DNA probes and dynamic assignment, this could result in the host obtaining two valid addresses -- a "manual" and a "dynamic" one.  In that case, the standard advice of "take the dynamically assigned address if it conflicts with the DNA probe result" is no longer valid -- a manually assigned address needs to take priority.  One might also argue that when attached to a "manual" network, dynamic assignment mechanisms should be treated as a confirmed probe, in that once connection to the "manual" network is confirmed, the manual address should be plumbed, and the dynamic address should be thrown away. 

Given these issues, the DNAv4 document cites some of the above concerns and recommends against use for manual addressing.  If and when manual addressing is implemented for DNAv4, we will probably learn enough to provide some guidance about how it can be done effectively.  But we don't appear to have that understanding now. 

My recommendation for the DNAv6 document would be to include a small section outlining the above concerns for DNAv6, indicating that manual addressing is NOT RECOMMENDED.  






> Date: Mon, 24 Aug 2009 10:47:06 +0300
> From: jari.arkko@piuha.net
> To: suresh.krishnan@ericsson.com
> CC: bernard_aboba@hotmail.com; draft-ietf-dna-simple@tools.ietf.org; dna@ietf.org
> Subject: Re: [dna] AD review of draft-ietf-dna-simple
> 
> Suresh,
> 
> > I will try to add more text regarding manually configured addresses.
> 
> My preference would be to leave explicitly state that DNAv6 does not 
> apply to such addresses. I don't really see the use case to begin with...
> 
> Jari
>