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

Suresh Krishnan <suresh.krishnan@ericsson.com> Thu, 16 July 2009 22:39 UTC

Return-Path: <suresh.krishnan@ericsson.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 3410428C279 for <dna@core3.amsl.com>; Thu, 16 Jul 2009 15:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.561
X-Spam-Level:
X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 YDBiMJChM7rr for <dna@core3.amsl.com>; Thu, 16 Jul 2009 15:39:26 -0700 (PDT)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 653A928C247 for <dna@ietf.org>; Thu, 16 Jul 2009 15:39:17 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n6GMdgH8002393; Thu, 16 Jul 2009 17:39:49 -0500
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jul 2009 17:39:46 -0500
Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jul 2009 17:39:45 -0500
Message-ID: <4A5FABFE.2030209@ericsson.com>
Date: Thu, 16 Jul 2009 18:38:54 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <4A55E27D.80200@piuha.net> <BLU137-W109A872CE0057E72AD0EF93260@phx.gbl> <BLU137-W28F2FFB5232BC48619BF5E93210@phx.gbl>
In-Reply-To: <BLU137-W28F2FFB5232BC48619BF5E93210@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jul 2009 22:39:45.0702 (UTC) FILETIME=[517C6C60:01CA0666]
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: Thu, 16 Jul 2009 22:39:27 -0000

Hi Bernard,
   Thanks for the comments.

On 09-07-16 01:38 PM, Bernard Aboba wrote:
> [BA] This section does not mention the destination MAC address.   Unless 
> that is set to the unicast MAC address of the router, it is possible 
> that the NS could be received by another router using the same linklocal 
> address.  After all, linklocal addresses need not be globally unique.

Agree. I will make this change.

>  
> "
>   
> 
> 
>         *4.5.2**.  Router Solicitation messages*
> 
> 
> 
>    This section describes the contents of the router solicitation probe
>    message sent during the probing procedure.
> 
>    Source Address:           A link-local address assigned to the
>                              probing host.
> 
>    Destination Address:      The all-routers multicast address.
> 
>    Hop Limit:                255
> 
>    The probing node SHOULD include a Source link-layer address option in
>    the probe messages if the address was obtained using DHCPv6 and the
>    lease has not expired.  Otherwise the probing node SHOULD NOT include
>    the Source link-layer address option in the probe messages.
> 
> "
>  
> [BA] Including the SSLAO in the RS seems odd because it is sent to a 
> multicast address.  Unlike the NS, the RS is not constructed for a 
> particular router, and therefore its construction should not depend how 
> the address was obtained -- since another router could receive it.  In 
> the case where the address was obtained from DHCPv6, and the host is on 
> one of the probed links, we'd expect the unicast NS to be responded to, 
> and since that does include the SSLAO, I think we're covered.

We do not know which probe will succeed first, the RS or the NS, since 
they are sent in parallel. To expedite the proceedings we include the 
SLLAO on the RS. But when we reattach to a known link (which is the case 
we optimize for) the NS will succeed and we probably don't need the 
SLLAO in the RS. I will go ahead and remove this.

>  
> 
> 
>       *4.6**.  Sending DHCPv6 probes*
> 
> 
> 
>    Where the host has acquired addresses from DHCPv6 or the host does
>    not have a global prefix, it MAY prefer to use DHCPv6 messages either
>    before or simultanously with Neighbour Discovery probing.
> 
> [BA] Doing DHCPv6 *before* NS probing does not make sense to 
> me.  Earlier, it is said that NS probing occurs simulataneously with 
> sending the RS, right after "link up".  This sentence seems to 
> contradict that.

It refers to "neighbor discovery" probing, which includes both RS and NS 
probing. Please see below.

>  
> Also, linking DHCPv6 procedures to DNA seems odd.  In DNAv4, it is made 
> clear that DNA did not resut in any changes to DHCPv4 procedures.  Is 
> that the intent here, or does DNA have some impact on how/when DHCPv6 
> messages are sent?

It does not have any impact on when DHCPv6 messages are sent. Would you 
like this text to be removed?

>  
>   
> 
> 
>       *4.7**.  Response Gathering*
> 
> 
> 
>    When a responding Neighbour Advertisement is received from a test
>    node, the host MUST verify that both the IPv6 and link layer (MAC)
>    addresses of the test node match the expected values before utilizing
>    the configuration associated with the detected network (prefixes, MTU
>    etc.).
> 
> [BA] It seems odd to check the MAC address in a response, but not to 
> talk about the destination MAC address in the request. Was this 
> intentional?

No. I will add the destination MAC address to the request as well.

>  
> Section 4.9
>  
>   If the confirmed address was assigned manually, the implementation SHOULD
>    NOT unconfigure the manually assigned address and SHOULD log an error
>    about the mismatching prefix.
> 
> [BA] Elsewhere the draft talks about stateless autoconfig and 
> DHCPv6-assigned addresses, but not manual assignment.   Is the intent of 
> the document to suggest use of DNAv6 for configuration of manually 
> assigned addresses?  If so, then some of the caveats discussed in the 
> DNAv4 document could apply.   For example, NS probes don't need much if 
> any retransmission because alternatives (RS, DHCPv6) are retransmitted.  
> But if we are talking about manual assignment, then these alternate 
> mechanisms may not help -- and NS probe retransmission can become more 
> important.


I will try to add more text regarding manually configured addresses.

Thanks
Suresh