Re: [dhcwg] Updates on draft-ietf-dhc-slap-quadrant

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Fri, 09 October 2020 20:28 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB673A1542 for <dhcwg@ietfa.amsl.com>; Fri, 9 Oct 2020 13:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
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 8DnGNXq70d5d for <dhcwg@ietfa.amsl.com>; Fri, 9 Oct 2020 13:28:38 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484FC3A153F for <dhcwg@ietf.org>; Fri, 9 Oct 2020 13:28:37 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id p13so10730604edi.7 for <dhcwg@ietf.org>; Fri, 09 Oct 2020 13:28:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P3pVmwEFuEsXJo3ZtDn/zCeXzzEDMI5U7dyzYKlL39o=; b=f/QdStsMSd1kn3xArJS/cYI0RRZF1sGDirPrLJLHwrjRNPRgK4ITNIONATOM9Vy3D2 hrXEtO5TbR4tiXX8U7QZhmiD2BmSyeGoctLLkZjJdsmbq45ogRtWsz/SiLt07MZ2nJUX 1qyLk0yRvvqABVfjUeAtsrK3tE/zM9SHclfs+wzzAShNh2XJEg++1LdDTXdbL8OkzLJI 0XJkO7pyt/RClXvCu9OSTD/RXzILqSkY3akE3O7LqOEXKPWXcbLPLfQyAtQ9N0dI9aVp obPbpN/2MGMhtyy1ryL9mZJPKQ8GWRY00qomWoW8f5Ta7jHM8HwIMJwfE/ihglwsFnse KddQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P3pVmwEFuEsXJo3ZtDn/zCeXzzEDMI5U7dyzYKlL39o=; b=AVha9AaE4wXAanSSLmj+jw2gp2z+emXon++EgJScr8NocS/xwoj9Rbme916TEVjqov C620RKkNfj06JrXXTHNmJ6mqGR3Kn2z/cD1sB4bloxEsgI6H0tsjWBBqx1/K/QUYsKAR 7FL+5bhQebbB1U4QmXKD15E9X1mjysVnc6FApgBq8onMdFLCshg58W7U6UOKOfUHYoAc T22dj2udCElXnIgnSqLCEjTvIq+bK7tsx5KiB+7PnxTwC0TqVpft7ltlul1dATG3jJne 8NHOSo1u9uqiFfZRxOxgZ+2CVoKPrn6qgPdlqIla+BA33PrGce8AyevNv+jFBuvS8893 NAzg==
X-Gm-Message-State: AOAM532Dw3O/yjOlpU6HjGLEIRJXzKm7avBp/IB1DNpJLo+glGf+DgjZ ZOk3NiVX9HTwAGgzNPv9t0wbyL75C0vsYWkbP4INJA==
X-Google-Smtp-Source: ABdhPJxzRLPEnH55TYKi2Uhr4hYXMsFRSi0tYzEwh58OxVLMlRhWEm+Lt7lAsWbBZdbYff5KwlEWurLF+21vHe0h4nA=
X-Received: by 2002:a50:cf8a:: with SMTP id h10mr1079690edk.43.1602275315920; Fri, 09 Oct 2020 13:28:35 -0700 (PDT)
MIME-Version: 1.0
References: <CALypLp8TdmF2kuQdRpGnVOzAT78E4ZOXp4_yB5zUCGePKeHU2Q@mail.gmail.com> <8487530A-73F6-46E9-A34F-D78497A39942@cisco.com> <dbca04d3-468a-4d37-8864-d8daaadce89e@Spark> <CALypLp9v4WN+ge30hZWvDnxVDkYs7nG=cRM5u1OnRUVMdPmuuQ@mail.gmail.com> <065A9F41-1BF3-45E2-A572-95491D308BD9@cisco.com> <50889a45-d627-4304-98d6-9d98424b7e39@Spark>
In-Reply-To: <50889a45-d627-4304-98d6-9d98424b7e39@Spark>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Fri, 9 Oct 2020 22:28:18 +0200
Message-ID: <CALypLp_foQj-vq_tKmaTrQHK5c4L82ctWCTQ=r+LsEMw0uNcnQ@mail.gmail.com>
To: Roger Marks <roger@ethair.net>
Cc: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, ROBERT GROW <bobgrow@cox.net>, Glenn Parsons <glenn.parsons@ericsson.com>, "Stanley, Dorothy" <dorothy.stanley@hpe.com>, "Bernie Volz (volz)" <volz@cisco.com>, ANTONIO DE LA OLIVA DELGADO <aoliva@it.uc3m.es>, dhcwg <dhcwg@ietf.org>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, Timothy Winters <tim@qacafe.com>, "Mourad, Alain" <Alain.Mourad@interdigital.com>
Content-Type: multipart/alternative; boundary="00000000000009f7c405b142cb94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/PpYCfPvsQTGHctc-4p-LZXGZeWw>
X-Mailman-Approved-At: Fri, 09 Oct 2020 13:29:33 -0700
Subject: Re: [dhcwg] Updates on draft-ietf-dhc-slap-quadrant
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 09 Oct 2020 20:28:42 -0000

Thanks a lot Roger for all the help.

Kind regards,

Carlos

On Fri, Oct 9, 2020 at 9:38 PM Roger Marks <roger@ethair.net> wrote:

> Carlos,
>
> Thanks for the response.
>
> Personally, I believe that the changes you indicated (from OLD to NEW, and
> the clause suggested by Bernie), would address the concerns I raised.
>
> Thanks for taking the time to consider my concerns.
>
> Cheers,
>
> Roger
> On Oct 9, 2020, 9:41 AM -0600, "Eric Vyncke (evyncke)" <evyncke@cisco.com>om>,
> wrote:
>
> Roger, Robert, Glenn, Dorothy,
>
>
>
> Sorry for being pushy again but what do you think about Carlos’ proposed
> text ? (and thank you again for spotting an ambiguity in the IETF draft)
>
>
>
> I would really like to get a reply from you before approving this IETF
> document
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> *From:* CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
> *Date:* Tuesday, 6 October 2020 at 22:07
> *To:* Roger Marks <roger@ethair.net>
> *Cc:* ROBERT GROW <bobgrow@cox.net>et>, Glenn Parsons <
> glenn.parsons@ericsson.com>gt;, "Stanley, Dorothy" <dorothy.stanley@hpe.com>om>,
> Eric Vyncke <evyncke@cisco.com>om>, "Bernie Volz (volz)" <volz@cisco.com>om>,
> ANTONIO DE LA OLIVA DELGADO <aoliva@it.uc3m.es>es>, dhcwg <dhcwg@ietf.org>rg>,
> "Rob Wilton (rwilton)" <rwilton@cisco.com>om>, Timothy Winters <
> tim@qacafe.com>gt;, "Mourad, Alain" <Alain.Mourad@interdigital.com>
> *Subject:* Re: Updates on draft-ietf-dhc-slap-quadrant
>
>
>
> Hi Roger,
>
>
>
> Thanks again for your feedback. Please see inline below.
>
>
>
> On Fri, Oct 2, 2020 at 11:37 PM Roger Marks <roger@ethair.net> wrote:
>
> Carlos and éric,
>
> Since many of the core technical comments were not implemented, I
> personally still think that the draft is still not effective.  I'll just
> reiterate that the following remain puzzling to me:
>
> (1) Why a client needs to request a specific quadrant of the local MAC
> address space, via Solicit (i.e., I don't understand the problem statement).
>
>
>
>  [Carlos] The mechanism is intended to allow a client (or relay) indicate
> a preference for obtaining addresses from a specific quadrant. There are
> some examples of scenarios where this might be relevant described in the
> document, but there might be others that appear in the future as well.
>
>
>
> (2) Why a server is prohibited from offering, in the Advertise, an address
> outside the requested quadrant.
>
>
>
> [Carlos] This part of the DHCP dialogue (Solicit-Advertise) is meant for
> the client to select the best DHCP server to meet its needs (i.e.,
> indicated preference). What do you think about the following modification
> to address your suggestion?
>
> OLD:
>    2.  The server, upon receiving an IA_LL option in Solicit, inspects
>        its contents.  For each of the entries in OPTION_SLAP_QUAD, in
>        order of the preference field (highest to lowest), the server
>        checks if it has a configured MAC address pool matching the
>        requested quadrant identifier, and an available range of
>        addresses of the requested size.  If suitable addresses are
>        found, the server sends back an Advertise message with an IA_LL
>        option containing an LLADDR option that specifies the addresses
>        being offered.  If the server supports the new QUAD IA_LL-option,
>        and manages a block of addresses belonging to a requested
>        quadrant, the addresses being offered MUST belong to a requested
>        quadrant.  If the server does not have a configured address pool
>        matching the client's request, it MUST return the IA_LL option
>        containing a Status Code option with status set to NoQuadAvail
>        (IANA-2).  If the client specified more than one SLAP quadrant,
>        the server MUST only return a NoQuadAvail status code if no
>        address pool(s) configured at the server match any of the
>        specified SLAP quadrants.  If the server has a configured address
>        pool of the correct quadrant, but no available addresses, it MUST
>        return the IA_LL option containing a Status Code option with
>        status set to NoAddrsAvail.
>
> NEW:
>    2.  The server, upon receiving an IA_LL option in Solicit, inspects
>        its contents.  For each of the entries in OPTION_SLAP_QUAD, in
>        order of the preference field (highest to lowest), the server
>        checks if it has a configured MAC address pool matching the
>        requested quadrant identifier, and an available range of
>        addresses of the requested size.  If suitable addresses are
>        found, the server sends back an Advertise message with an IA_LL
>        option containing an LLADDR option that specifies the addresses
>        being offered.  If the server manages a block of addresses belonging
>        to a requested quadrant, the addresses being offered MUST belong
>        to a requested quadrant.  If the server does not have a configured
>        address pool matching the client's request, it SHOULD return the
>        IA_LL option with the addresses being offered belonging to a
>        quadrant managed by the server (following a local policy to select
>        from which of the available quadrants). If the server has a
> configured
>        address pool of the correct quadrant, but no available addresses, it
>        MUST return the IA_LL option containing a Status Code option with
>        status set to NoAddrsAvail.
>
> The client-relay-server part of the spec would also be changed to reflect
> the same update. Besides, the following clause suggested by Bernie (thanks
> a lot!) would be added, with some minor modifications to ensure the wording
> matches the rest of the text in the section:
>
>       For cases where a server may not be configured to have pools for the
>       client or relay QUAD preferences, clients and relays SHOULD specify
>       all quadrants in the preferences to assure the client gets an address
>       (or addresses) -- if any are available. Specifying all quadrants also
>       results in a quad option supporting server responding like a non-quad
>       option supporting server, i.e., an address (or addresses) from any
>       available quadrant can be returned.
>
>
>
> (3) Given (2), why the server that cannot meet the demand does not
> provide, in the Advertise, the list of quadrants in which it *does* have
> available addresses.
>
>
>
> [Carlos] If we go for the proposed change above, this would not apply.
>
> In any case, I want to provide an explanation why this was not possible
> with the current text (if we do not add the change proposed above). This is
> because the way DHCP address allocation works (as described in
> draft-ietf-dhc-mac-assign for MAC addresses). The server includes in the
> Advertise the actual address(es) being offered, not the list of quadrants
> that it has available. This is due to the way DHCP works, and therefore
> cannot be changed. In any case, the client may send a different Solicit
> with more SLAP quadrants, to see/learn which ones are supported by
> available servers.
>
>
>
> (4) Given (2), why the client can nevertheless (though it SHOULD NOT)
> Request an address in a quadrant that was not Advertised, and,
>
>
>
> [Carlos] Again, this might not apply if we adopt the proposed change. But,
> let me provide an explanation of why the spec was originally written as it
> is, below.
>
> IETF protocols make use of normative capitalized words (like "SHOULD NOT")
> in very specific ways, described in RFCs 2119 and 8174. According to RFCs
> 2119 and 8174, "SHOULD NOT" indicates that "there may exist valid reasons
> in particular circumstances when the particular behavior is acceptable or
> even useful, but the full implications should be understood and the case
> carefully weighed before implementing any behavior described with this
> label". Therefore, there might be scenarios, carefully weighed, where a
> client requesting a quadrant that was not advertised, might make sense, and
> we leave the specification so this can be supported, instead of using "MUST
> NOT" which would totally prohibit that.
>
>
>
> (5) Given (4), why the server can nevertheless grant that request, though
> it was prohibited [per (2)] from admitting that it could do so.
>
>
>
> [Carlos] Note that the server would not have addresses from the indicated
> quadrant in this case (otherwise it would have indicated that in the
> Advertise message), and therefore it will never allocate addresses from
> this quadrant. But the server is allowed to allocate address(es) from a
> different quadrant (based on local server policies). And then the client
> may decide to use it anyway.
>
> But in any case, this would not apply either.
>
>
>
> Thanks one more time.
>
>
>
> Carlos
>
>
>
>
> I understand that the editors decided not to make changes in response to
> the relevant prior comments because the content had already been
> "extensively reviewed and approved by the DHC WG and the IETF and represent
> therefore the IETF consensus." However, that explanation doesn't provide me
> with an understanding of the technical rationale, so I remain puzzled.
>
> Please understand that these comments are from me only, not from IEEE.
>
>
>
> Cheers,
>
>
>
> Roger
>
> On Oct 1, 2020, 1:11 AM -0600, "Eric Vyncke (evyncke)" <evyncke@cisco.com>om>,
> wrote:
>
> Roger, Robert, Glenn, and Dorothy,
>
>
>
> As the IETF would like to move forward with the publication of this
> document, may I kindly ask you to quickly review the changes ?
>
>
>
> My intent, as responsible Area Director for the DHC WG, is to approve and
> publish it in a week, Thursday 8th of October, if there is no blocking
> issues from the IEEE.
>
>
>
> Thank you in advance,
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From:* CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
> *Date:* Thursday, 1 October 2020 at 08:51
> *To:* Roger Marks <roger@ethair.net>
> *Cc:* ROBERT GROW <bobgrow@cox.net>et>, Glenn Parsons <
> glenn.parsons@ericsson.com>gt;, "Bernie Volz (volz)" <volz@cisco.com>om>,
> ANTONIO DE LA OLIVA DELGADO <aoliva@it.uc3m.es>es>, Eric Vyncke <
> evyncke@cisco.com>gt;, "Stanley, Dorothy" <dorothy.stanley@hpe.com>om>, dhcwg <
> dhcwg@ietf.org>gt;, "Rob Wilton (rwilton)" <rwilton@cisco.com>
> *Subject:* Updates on draft-ietf-dhc-slap-quadrant
>
>
>
> Hi Roger, all,
>
>
>
> Thanks again for the comments on the draft. I did try to incorporate most
> of your comments. For the sake of completeness, I'm just summarizing below
> the changes I made on the draft:
>
>
>
> - I applied basically all the suggested edits (on abstract, introduction
> and terminology sections).
>
> - I made some minor changes to improve the motivation of the problem
> statement, but note that this was extensively reviewed by the DHC WG. I've
> modified the text regarding the IoT scenario to better explain the
> motivation (section 1.1.1). I've also reformulated the text in section
> 1.1.2 to better explain the rationale behind the recommendations for SLAP
> quadrant preferences in datacenter scenarios.
>
> - As suggested, I removed the section on Quadrant Selection Mechanisms
> examples (and put it in an annex).
>
> - I did check all your comments regarding the DHCPv6 extensions section
> (old section 4, now section 3). This part has been extensively reviewed and
> approved by the DHC WG and the IETF and represent therefore the IETF
> consensus. Since it refers to points related to the way the DHCPv6
> protocol works, we, the editors of the DHC WG document, do not intend to
> apply some of your comments.
>
> - I added all the suggested references and made the suggested corrections.
>
>
>
> Note that most of the comments were addressed in
> draft-ietf-dhc-slap-quadrant-10 (posted early August), but I've just posted
> draft-ietf-dhc-slap-quadrant-11 [1] with some additional changes and small
> corrections.
>
>
>
> Thanks much for providing the comments and feedback on the draft.
>
>
>
> Kind regards,
>
>
>
> Carlos
>
>
>
> [1] https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-11
>
>