Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

神明達哉 <jinmei@wide.ad.jp> Thu, 16 October 2014 17:34 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549551A1A32 for <dhcwg@ietfa.amsl.com>; Thu, 16 Oct 2014 10:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHIOQFj1hQVe for <dhcwg@ietfa.amsl.com>; Thu, 16 Oct 2014 10:34:01 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64061A03B3 for <dhcwg@ietf.org>; Thu, 16 Oct 2014 10:34:00 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id k14so4270235wgh.19 for <dhcwg@ietf.org>; Thu, 16 Oct 2014 10:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=aC3N84xl5QKKTryXgnpQqAhcE3HQdhtkwE8JmufAhsQ=; b=TMAFjEoHYHJty5io1GHcTd4fEzodTqwbddOgIrxj4UWw7X3BRjRfHCkyfjQZ7IqfKa wMRzW51BqQS9Mv6A3M1ZO9iXx3i8+WVz4OYkJWw8t6fMNENO/J9WeRCFs9vSrljxFU7I Pdd9jL5FRmTDzDjPwGm//8GKlTG7PwCXsabBKoympCXK8SV5PXhvAgxzj1yUbGoT2fFd tyxty4mqHSGqFT3NQ0z/Bvx21iBGRk22n2p8CBhbdCgT4gu16XBKkucTs1fjB7kX/97C NF9wYmSSGjQ7CuU/b07qBa1n+mwisT8OyZMm6ZZuBzPJ4D1j7BklRFbxdosMcEakPR80 IjDg==
MIME-Version: 1.0
X-Received: by 10.194.58.8 with SMTP id m8mr3882533wjq.43.1413480839400; Thu, 16 Oct 2014 10:33:59 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.195.13.83 with HTTP; Thu, 16 Oct 2014 10:33:59 -0700 (PDT)
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B6CEE2D@xmb-rcd-x04.cisco.com>
References: <542D1698.7030203@gmail.com> <CAJE_bqcJS45ULDLaGgzgE5ZeS-hFZhWUX4819-T_jObroJnv4Q@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E1B6CEE2D@xmb-rcd-x04.cisco.com>
Date: Thu, 16 Oct 2014 10:33:59 -0700
X-Google-Sender-Auth: HylGUTcrcFm93uwVhxGdjg7UvDU
Message-ID: <CAJE_bqeNyWa=hxyaaDRqUR0zgnfQCSZZOnToXSaSWm0m4CjUYg@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/E4GyovFqrj74ZLKjRr_QPZ8Hh54
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Oct 2014 17:34:03 -0000

At Wed, 15 Oct 2014 16:16:36 +0000,
"Bernie Volz (volz)" <volz@cisco.com> wrote:

> First, I have a couple of higher level points to discuss:
>
> - What's the final goal of this document?
>
> ** The goal here is for this work to be an RFC.

Okay, in that case I'll also check overall readability as a separate
document for future versions.

> Specific comments to the draft text follow:
>
> - Title: now that our main focus is the mixed use of IA_NA and IA_PD
>   rather than generalizing the concept of stateful resources, I think
>   it makes more sense to reflect it in the title, for example,
>   "Issues and Recommendations with Multiple DHCPv6 IA Options".
>   See also my comments on Section 3 (terminology) below.
>
> ** We will leave the title as it is.

Hmm, if we are going to even more focus on the specific case of the
mix of IA_NA and IA_PD as you'll mention below, and also if it's
supposed to be published as a single document, I'd avoid making the
tile too generic.  So, I'd even make it more specific such as

    Issues and Recommendations with Mixed Use of DHCPv6 Address
    Assignment and Prefix Delegation

But it's ultimately up to the authors.  If the authors still thinks
the current title is the best, I won't insist further.

> - Abstract: this is more about readability (see above), but I'm afraid
>   the current abstract text wouldn't be really helpful for first-time
>   readers (on the other hand, it's not a problem for "me", because I
>   already know what it is). [...]
>
> ** We will leave the abstract pretty much as is. We change last sentence to mention that the (RFC) changes are to address the identified issues.

Ditto.  But I'll see how the abstract of the next version will look
like.

> - Section 1, regarding the same text and this one:
[...]
>   IMO, this document should talk a bit more about the "framework".
[...]
> ** We will rework the Introduction to remove the 'framework' concept and just focus on the IA_NA/IA_PD issues. When and if there are future IA's, those documents can indicate whether they integrate into this work (i.e., add IA_foo to IA_NA, IA_PD in the stateful issues document) or if they are separate and independent.

Okay.

> - Section 4.2: replacement for RFC 3315 17.1.3:
>
>      The client MUST ignore any Advertise message that contains no
>      addresses (IAADDR options encapsulated in IA_NA or IA_TA options)
>      and no delegated prefixes (IAPREFIX options encapsulated in IA_PD
>      options, see RFC 3633) with the exception that the client
>      MUST process an included SOL_MAX_RT option (RFC 7083), MUST
>      process an included INF_MAX_RT option (RFC 7083), and MAY
>      display any associated status message(s) to the user.
>
>   It's awkward to see it mention prefixes while this version
>   intentionally cancels the idea of "unified" text for renew/rebind.
>   It's not clear to me why Section 17.1.3 (regarding advertise) still
>   needs to provide "unified" text.
>
> ** While we could drop "and no delegated prefixes (...)", does that really help significantly especially since RFC 7083 material is being pulled in already? Also, in this case if we leave it out, people may be confused about what happens if there are no addresses but prefixes. (For most of the other changes later, RFC 3633 already covers these changes as it generally implies to replace "addresses" with "delegated prefixes" in much of the Reply processing. And, we've provided the revised text where needed for 3633.) Also, RFC 3633 already points to 17.1.3 of 3315 and this avoids having to specify replacement text for 3633.

I wouldn't necessarily insist on it, it just looks awkward to me but
otherwise is not really a problem.  Maybe it helps if you note that
you're providing unified text with the reason of why (e.g., because
RFC 3633 doesn't describe its own version of this behavior but just
refers to RFC 3315.)

> - Section 4.3: I don't understand the following text:
>
>    [...] To deal
>    with the case where servers have not yet been updated to do that,
>    clients MUST use the shortest (explicit or implicit) T1/T2 times
>    (larger than 0), from the same IA option, in the Reply.  T1/T2 times
>    from other IAs are ignored.
>
>   I guess it tries to address the corner case I pointed out for the
>   previous version of the draft:
>   http://www.ietf.org/mail-archive/web/dhcwg/current/msg15663.html
>   but I don't even understand what the client would do in this case
>   based on the new text.  To recap, what should happen if the client
>   sees the following two sets of T1/T2 according to the above text?
>   - T1a = 10, T2a = 20
>   - T1b = 0, T2b = 5
>
> ** We will include this example and explain it. Note that T1b  = 0 means that the client must calculate the T1 time (50% of lifetime) and that it obviously needs to be less than T2b. So, in this case the T1b =0, T2b = 5 would be used but the T1b time is the 'implicit' time (we can't give the value since the lifetimes are not specified).

Hmm, then the phrase "(larger than 0)" can be misleading.

> ** There are perhaps other cases, for example T1a = 10, T2a = 20, T1b = 5, T2b = 25 that are a bit more interesting since picking (b) means T1=5/T2=25 which means T2 is longer than T2a.

Personally, I'm okay with just dismissing such a case as a server
misconfiguration (as we basically require the server use the same
T1/T2 values for all IAs).  I'd be fine unless a compliant client
behavior leads to a clearly broken result, such as T1 > T2.

> ** Perhaps we need to review whether the shortest 'effective' T1 and independently shortest 'effective' T2 are a better choice (obviously the client would have to adjust T1 if this means T1>T2, but I'm not sure that could even happen since for any individual IA, T1 must be less than or equal to T2). Note that by 'effective' here I mean either the server supplied value or, if 0, the client determined value based on the lifetimes within that IA.  If we used that algorithm, for your case the answer would not change; for my example T1 would be and T2 would be 20 which are probably better values for this case.

See above.  IMO it doesn't have to be too complicated and we can
basically leave it to the diligence of the server
implementation/operation.  All I want to see is a clear and
well-defined client behavior.

> ** Comments about this issue (and perhaps additional case analysis if appropriate) would be useful.
>
> - Section 4.4.5: does this mean, if the client has bindings of
>   multiple IAs, it should (effectively) abandon all of the bindings
>   and establish new bindings for all of the IAs starting from Solicit?
>   If so, it makes sense to me, but it's not really clear from the
>   text, and I suggest clarifying that point.
>
>      When the client receives a NotOnLink status from the server in
>      response to a Confirm message, the client performs DHCP server
>      solicitation, as described in section 17, and client-initiated
>      configuration as described in section 18.
>
> ** We will create a 3315bis ticket since this is pre-existing text used "as is" from 3315. And, this is not an issue that is particular to this draft. Note that Confirm is IA_NA (IA_TA) specific as IA_PD requires a Rebind; so this is an open issue in the original 3315 and should be added by the bis document. It also is more of a clarification, rather than a "change". The bis document can clarify that when a client sends a Solicit, it MUST not be using any of the addresses or delegated prefixes for the bindings included in the Solicit.

I'm not sure if I understand this as a response to my comment...to
clarify my point, what I wanted to raise is what should happen if:

- A client with bindings for both an IA_NA and an IA_PD detects it may
  have moved to a different link, so sends a Confirm for the IA_NA.
- The client receives a NotOnLink status in response to it.

Should the client (effectively) discards the binding for IA_PD (and
for IA_NA) and try to establish new bindings for both?  Or should it
keep the binding for IA_PD (but it would break the proposed model of
this draft)?  I thought the intent is the former, and I thought it's
not clear enough and suggested to clarify it in the text.

--
JINMEI, Tatuya