Subject: Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Sun, 10 Mar 2019 17:07:21 +0100

Hi,

We've posted a revision of the draft addressing the comments received.

Additional comments are more than welcome.

Thanks!

Carlos

On Mon, Feb 4, 2019 at 8:00 PM CARLOS JESUS BERNARDOS CANO <[email-masked]>
wrote:

> Thanks Bernie!
>
> Carlos
>
> On Mon, Feb 4, 2019 at 7:53 PM Bernie Volz (volz) <[email-masked]> wrote:
>
>> Great. See one response to your question (BV2).
>>
>>
>>
>>    - Bernie
>>
>>
>>
>> *From: *CARLOS JESUS BERNARDOS CANO <[email-masked]>
>> *Date: *Monday, February 4, 2019 at 1:37 PM
>> *To: *Bernie Volz <[email-masked]>
>> *Cc: *"[email-masked]" <[email-masked]>
>> *Subject: *Re: [dhcwg] Fwd: I-D Action:
>> draft-bernardos-dhc-slap-quadrant-00.txt
>>
>>
>>
>> Hi Bernie,
>>
>>
>>
>> Thanks a lot for your comments. Please see inline below.
>>
>>
>>
>>
>>
>> On Wed, Jan 30, 2019 at 7:42 PM Bernie Volz (volz) <[email-masked]>
>> wrote:
>>
>> Hi:
>>
>>
>>
>> Below are some comments on this new individual submission draft:
>>
>>
>>
>> Abstract
>>
>> …
>>
>>
>>
>>    The IEEE is working on mechanisms to allocate addresses in the one of
>>
>>    these quadrants (IEEE 802.1CQ).  There is work also in the IETF
>>
>>    working on specifying new mechanism that extends DHCPv6 operation to
>>
>> BV> drop “working”, redundant? And, add “a” – specifying a new
>>
>>
>>
>> CB> Thanks. We'll fix this.
>>
>>
>>
>>    handle the local MAC address assignments.  In this document, we
>>
>>    complement this IETF work by defining a mechanism to allow choosing
>>
>>    the SLAP quadrant to use in the allocation of the MAC address to the
>>
>>    requesting terminal/client.
>>
>>
>>
>>    This document proposes extensions to DHCPv6 protocols to enable a
>>
>>    DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant
>>
>>    to the server, so that the server allocates correspondingly the MAC
>>
>>    address to the given client or relay.
>>
>> BV> This correspondingly is a big awkward and the address(es) are always
>>
>> BV> allocated to the client, not the relay. Perhaps “so that the server
>>
>> BV> allocates the MAC address to the given client out of the quadrant
>>
>> BV> requested by relay or client”. I would assume relay’s should “win”?
>>
>>
>>
>> CB> Thanks for the proposal. It's definitely better than the original
>> text. We'll update.
>>
>>
>>
>>
>>
>> …
>>
>> 1.1.  Problem statement
>>
>>
>>
>>    The IEEE is working on mechanisms to allocate addresses in the SAI
>>
>>    quadrant (IEEE 802.1CQ project).  There is also ongoing work in the
>>
>>    IETF [I-D.bvtm-dhc-mac-assign] specifying new mechanism that extends
>>
>> BV> Add a – specifying a new
>>
>>
>>
>> CB> OK!
>>
>>
>>
>>    DHCPv6 operation to handle the local MAC address assignments.  In
>>
>>    this document, we complement ongoing IETF work with mechanisms to
>>
>> BV> Add this - we complement this ongoing
>>
>>
>>
>> CB> OK!
>>
>>
>>
>>    allow choosing the SLAP quadrant to use in the allocation of the MAC
>>
>>    address to the requesting terminal/client.  This document proposes
>>
>>    extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6
>>
>>    relay to indicate a preferred SLAP quadrant to the server, so that
>>
>>    the server allocates correspondingly the MAC address to the given
>>
>>    client or relay.
>>
>> BV> See Abstract comment.
>>
>>
>>
>> CB> OK!
>>
>>
>>
>>
>>
>> …
>>
>>
>>
>> 1.1.1.  WiFi terminals
>>
>>
>>
>>    Today, most of WiFi terminals come with interfaces that have a
>>
>> BV> Drop of – most WiFi terminals (perhaps devices may be better than
>>
>> BV> terminals – if changed, you need to do throughout)
>>
>>
>>
>> CB> OK, I'll replace interfaces with terminals in all the document.
>>
>>
>>
>>    "burned" MAC address, allocated from the universal address space
>>
>> BV> “burned in”?
>>
>>
>>
>> CB> OK, thanks.
>>
>>
>>
>> …
>>
>>
>>
>> 1.1.2.  Hypervisor: migratable vs non-migratable functions
>>
>> …
>>
>>
>>
>>    o  Migratable functions.  If a VM (providing a given function) might
>>
>>       need to be potentially migrated to another region of the data
>>
>>       center (due to maintenance, resilience, end-user mobility, etc.)
>>
>>       it is needed that this VM can keep its networking context in the
>>
>>       new region, and this includes keeping its MAC addresses.
>>
>>       Therefore, this makes better to allocate addresses from the ELI/
>>
>> BV> “this makes better” is odd wording. “Therefore, for this case, it is
>> better”?
>>
>>
>>
>> CB> OK, thanks.
>>
>>
>>
>>       SAI SLAP quadrant, which can be centrally allocated by the DHCP
>>
>>       server.
>>
>>
>>
>>    o  Non-migratable functions.  If a VM will not be migrated to another
>>
>>       region of the data center, then there are no requirements
>>
>> BV> can drop then.
>>
>>
>>
>> CB> OK!
>>
>>
>>
>>       associated to its MAC address, and then it is more efficient to
>>
>>      allocate it from the AAI SLAP quadrant, which does not need to be
>>
>>       same for all the data centers (i.e., each region can manage its
>>
>>       own, without checking for duplicates globally).
>>
>>
>>
>> 2.  Terminology
>>
>>
>>
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>
>>    document are to be interpreted as described in [RFC2119].
>>
>> BV> Please use latest working for this. For example, see Section 2 of
>> RFC8415?
>>
>>
>>
>> CB> OK, I'll fix that.
>>
>>
>>
>>
>>
>>
>>
>>    The DHCPv6 terminology relevant to this specification from the DHCPv6
>>
>>    Protocol [RFC8415] applies here.
>>
>>
>>
>>    client        A device that is interested in obtaining link-layer
>>
>>                  addresses.  It implements the basic DHCPv6 mechanisms
>>
>>                  needed by a DHCPv6 client as described in [RFC8415] and
>>
>>                  supports the new options (IA_LL and LLADDR) specified
>>
>>                  in this document.  The client may or may not support
>>
>> BV> Isn’t this what is specified in [I-D.bvtm-dhc-mac-assign], not this document?
>>
>>
>>
>> CB> Yes, you got me. I think I abused copy & paste :D. I'll fix this.
>> Sorry.
>>
>>
>>
>>                  address assignment and prefix delegation as specified
>>
>>                  in [RFC8415].
>>
>>
>>
>>    server        Software that manages link-layer address allocation and
>>
>>                  is able to respond to client queries.  It implements
>>
>>                  basic DHCPv6 server functionality as described in
>>
>>                  [RFC8415] and supports the new options (IA_LL and
>>
>>                  LLADDR) specified in this document.  The server may or
>>
>> BV> Same issue as above here.
>>
>>
>>
>> CB> Same.
>>
>>
>>
>>                  may not support address assignment and prefix
>>
>>                  delegation as specified in [RFC8415].
>>
>>
>>
>> …
>>
>>
>>
>> 3.  Quadrant selection mechanisms
>>
>>
>>
>> …
>>
>>
>>
>>    o  Operation/battery lifetime: depending on the expected lifetime of
>>
>>       the terminal a different quadrant might be preferred (as before,
>>
>>       to minimize potential address collisions in the future).  The
>>
>> BV> Shouldn’t a paragraph break go here? This seems to be different
>>
>> BV> material then operation/battery lifetime?
>>
>>
>>
>> CB> Yes, you are right. We'll fix this.
>>
>>
>>
>>       previous are examples of parameters that an IoT terminal might use
>>
>>       to select a given SLAP quadrant.  IoT terminals are typically very
>>
>>       resource constrained, so it might be as well that simple decisions
>>
>>       are just taken, for example based on pre-configured preferences.
>>
>>
>>
>> …
>>
>>
>>
>>    Additionally, the information can also be used to trigger subsequent
>>
>>    changes of MAC address, to enhance location privacy.  Besides,
>>
>>    changing the SLAP quadrant used might also be used as an additional
>>
>>    enhancement to make harder to track the user location.
>>
>> BV> Add it – to make it harder?
>>
>>
>>
>> CB> OK!
>>
>>
>>
>>
>>
>>    Last, if we consider the data center scenario, an hypervisor might
>>
>> BV> Change “an” to “a”.
>>
>>
>>
>> CB> OK!
>>
>>
>>
>>    request local MAC addresses to be assigned to virtual machines.  As
>>
>> …
>>
>>
>>
>>
>>
>>     +--------+                            +--------+
>>
>>     | DHCPv6 |                            | DHCPv6 |
>>
>>     | client |                            | server |
>>
>>     +--------+                            +--------+
>>
>>         |                                      |
>>
>>         +-------1. Solicit(IA_LL(quad))------->|
>>
>>         |                                      |
>>
>>         |<--2. Advertise(IA_LL(LLADDR,quad))--+|
>>
>>         |                                      |
>>
>>         +---3. Request(IA_LL(LLADDR,quad))---->|
>>
>>         |                                      |
>>
>>         |<------4. Reply(IA_LL(LLADDR))--------+
>>
>>         |                                      |
>>
>>         .                                      .
>>
>>         .          (timer expiring)            .
>>
>>         .                                      .
>>
>>         |                                      |
>>
>>         +------5. Renew(IA_LL(LLADDR))-------->|
>>
>>         |                                      |
>>
>>         |<-----6. Reply(IA_LL(LLADDR))---------+
>>
>>         |                                      |
>>
>>
>>
>>               Figure 3: DHCPv6 signaling flow (client-server)
>>
>>
>>
>>    1.  Link-layer addresses (i.e., MAC addresses) are assigned in
>>
>>        blocks.  The smallest block is a single address.  To request an
>>
>>        assignment, the client sends a Solicit message with a IA_LL
>>
>>        option in the message.  The IA_LL option MUST contain a LLADDR
>>
>>        option.  In order to indicate the preferred SLAP quadrant, the
>>
>>        IA_LL option includes a new quad IA-LL-option, which contains the
>>
>>        preferred quadrant.
>>
>>
>>
>> BV> I think you should just use QUAD (for OPTION_QUAD) and the text
>>
>> BV> should say “the IA_LL option includes the new OPTION_QUAD option
>>
>> BV> in the IA-LL-option field (with the LLAADR option).
>>
>>
>>
>> CB> OK, so you mean to replace for example  "Solicit(IA_LL(quad))" with "
>> Solicit(IA_LL(QUAD))" and then also fix the text according to your
>> suggestion, right?
>>
>>
>>
>> BV2> YES.
>>
>>
>>
>>
>>
>> …
>>
>>
>>
>>    5.  When the assigned addresses are about to expire, the client sends
>>
>>        a Renew message.
>>
>>
>>
>> BV> I think the RENEW should also include the QUAD option. If the server
>>
>> BV> were unable to extend the lifetime on the existing address(es), it
>>
>> BV> would need to know what quadrant to use for any “new” addresses.
>>
>>
>>
>> CB> OK, that makes sense. Thanks for the suggestion.
>>
>>
>>
>> …
>>
>>
>>
>> 4.2.  Address assignment from the SLAP quadrant indicated by the relay
>>
>>
>>
>> …
>>
>>    2.   The DHCP relay receives the Solicit message and encapsulates it
>>
>>         in a Relay-forw message.  The relay, based on local knowledge
>>
>>         and policies, includes in the Relay Agent Remote-ID Option the
>>
>>         preferred quadrant.  The relay might know which quadrant to
>>
>>         request based on local configuration (e.g., the served network
>>
>>         contains IoT devices only, thus requiring ELI/SAI) or other
>>
>>         means such as based on analyzing the Solicit message from the
>>
>>         client.
>>
>>
>>
>> BV> Use the QUAD option here to, but it is just added to Relay-Forw
>>
>> BV> message. Remove the text above about the “Relay Agent Remote-ID
>>
>> BV> option” and replace “The relay, based on local knowledge and
>>
>> BV> policies, includes in the Relay-Forw message the QUAD option
>>
>> BV> with the preferred quadrant.”
>>
>>
>>
>> CB> OK. This also makes sense.
>>
>>
>>
>>
>>
>>    3.   The server, upon receiving the forwarded Solicit message
>>
>>         including a IA_LL option, inspects its content and decide may
>>
>>         offer an address or addresses for each LLADDR option according
>>
>>         to its policy.  The server sends back an Advertise message with
>>
>>         an IA_LL option containing an LLADDR option that specifies the
>>
>>         addresses being offered.  This message is sent to the Relay in a
>>
>>         Relay-reply message.  If the server supports the semantics of
>>
>>         the preferred quadrant included in the Relay Agent Remote-ID
>>
>>         Option, and manages a block of addresses belonging to the
>>
>>         requested quadrant, then the addresses being offered SHOULD
>>
>>         belong to the requested quadrant.
>>
>> BV> Here, replace the Relay Agent Remote-ID option with the QUAD option.
>>
>>
>>
>> CB> OK.
>>
>>
>>
>>
>>
>>    4.   The relay sends the received Advertise message to the client.
>>
>>
>>
>>    5.   The client waits for available servers to send Advertise
>>
>>         responses and picks one server as defined in Section 18.2.9 of
>>
>>         [RFC8415].  The client then sends a Request message that
>>
>>         includes the IA_LL container option with the LLADDR option
>>
>>         copied from the Advertise message sent by the chosen server.
>>
>>
>>
>>    6.   The relay forwards the received Request in a Relay-forw message.
>>
>>         It adds in the Relay-forw a quad IA-LL-option with the preferred
>>
>>         quadrant.
>>
>> BV> See step 2.
>>
>>
>>
>> CB> OK.
>>
>>
>>
>> …
>>
>>
>>
>>
>>
>> 5.  DHCPv6 options definitions
>>
>>
>>
>> 5.1.  Quad (IA-LL) option
>>
>>
>>
>>    The quad option is used to specify the preferences for the selected
>>
>>    quadrants within an IA_LL.  The option must be encapsulated in the
>>
>>    IA_LL-options field of an IA_LL option.
>>
>>
>>
>> BV> And, it can also be in a Relay-Forw message!!! So, “The option must
>>
>> BV> either be encapsulated in the IA-LL-options field of an IA_LL option
>>
>> BV> or in a Relay-Forw message in the options field. It MAY also be in
>>
>> BV> a Relay-Reply if the QUAD option code was specified in a ERO option
>>
>> BV> [RFC4994].
>>
>>
>>
>> CB> OK, thanks a lot for this and all previous good suggestions. We'll
>> include them in the next revision.
>>
>>
>>
>> Carlos
>>
>>
>>
>>
>>
>>    - Bernie
>>
>>
>>
>> *From:* dhcwg <[email-masked]> *On Behalf Of *CARLOS JESUS
>> BERNARDOS CANO
>> *Sent:* Tuesday, January 29, 2019 2:33 PM
>> *To:* [email-masked]
>> *Subject:* [dhcwg] Fwd: I-D Action:
>> draft-bernardos-dhc-slap-quadrant-00.txt
>>
>>
>>
>> Hi,
>>
>>
>>
>> We have submitted a new draft describing DHCP extensions to allow a
>> client/relay specify which SLAP quadrant to use when requesting a MAC
>> address/set of addresses.
>>
>>
>>
>> Comments are very much appreciated.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Carlos
>>
>>
>>
>> ---------- Forwarded message ---------
>> From: <[email-masked]>
>> Date: Tue, 29 Jan 2019 at 07:43
>> Subject: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt
>> To: <[email-masked]>
>>
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>         Title           : SLAP quadrant selection options for DHCPv6
>>         Authors         : Carlos J. Bernardos
>>                           Alain Mourad
>>         Filename        : draft-bernardos-dhc-slap-quadrant-00.txt
>>         Pages           : 14
>>         Date            : 2019-01-28
>>
>> Abstract:
>>    The IEEE originally structured the 48-bit MAC address space in such a
>>    way that half of it was reserved for local use.  Recently, the IEEE
>>    has been working on a new specification (IEEE 802c) which defines a
>>    new "optional Structured Local Address Plan" (SLAP) that specifies
>>    different assignment approaches in four specified regions of the
>>    local MAC address space.
>>
>>    The IEEE is working on mechanisms to allocate addresses in the one of
>>    these quadrants (IEEE 802.1CQ).  There is work also in the IETF
>>    working on specifying new mechanism that extends DHCPv6 operation to
>>    handle the local MAC address assignments.  In this document, we
>>    complement this IETF work by defining a mechanism to allow choosing
>>    the SLAP quadrant to use in the allocation of the MAC address to the
>>    requesting terminal/client.
>>
>>    This document proposes extensions to DHCPv6 protocols to enable a
>>    DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant
>>    to the server, so that the server allocates correspondingly the MAC
>>    address to the given client or relay.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-bernardos-dhc-slap-quadrant/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-bernardos-dhc-slap-quadrant-00
>> https://datatracker.ietf.org/doc/html/draft-bernardos-dhc-slap-quadrant-00
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> --
>>
>> Sent from a mobile device, please excuse any brevity or typing errors.
>>
>>

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Wed, 13 Mar 2019 15:09:34 +0100

Thanks a lot Bernie for reviewing the draft and providing comments.

See you in Prague,

Carlos

On Wed, Mar 13, 2019 at 3:06 PM Bernie Volz (volz) <[email-masked]> wrote:

> Thanks much Carols for updating the draft with the comments I had provided
> earlier. It looks good!
>
>
>
> See you in Prague!
>
>
>
>    - Bernie
>
>
>
> *From:* CARLOS JESUS BERNARDOS CANO <[email-masked]>
> *Sent:* Sunday, March 10, 2019 12:07 PM
> *To:* Bernie Volz (volz) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [dhcwg] Fwd: I-D Action:
> On Mon, Feb 4, 2019 at 8:00 PM CARLOS JESUS BERNARDOS CANO <
> [email-masked]> wrote:
>
> Thanks Bernie!
>
>
>
> Carlos
>
>
>
> On Wed, Jan 30, 2019 at 7:42 PM Bernie Volz (volz) <[email-masked]> wrote:
>
> Hi:
>
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 13 Mar 2019 14:06:42 +0000

Thanks much Carols for updating the draft with the comments I had provided earlier. It looks good!

See you in Prague!

  *   Bernie

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Sent: Sunday, March 10, 2019 12:07 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt

Hi,

Thanks!

Carlos

On Mon, Feb 4, 2019 at 8:00 PM CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Bernie!

Carlos

On Mon, Feb 4, 2019 at 7:53 PM Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
Great. See one response to your question (BV2).

  *   Bernie

From: CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 4, 2019 at 1:37 PM
To: Bernie Volz <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt

Hi Bernie,

On Wed, Jan 30, 2019 at 7:42 PM Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
Hi:

Abstract
…

CB> Thanks for the proposal. It's definitely better than the original text. We'll update.

…
1.1.  Problem statement

CB> OK!

CB> OK!

CB> OK!

…

1.1.1.  WiFi terminals

CB> OK, thanks.

…

BV> “this makes better” is odd wording. “Therefore, for this case, it is better”?

CB> OK, thanks.

CB> OK!

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].
BV> Please use latest working for this. For example, see Section 2 of RFC8415?

CB> OK, I'll fix that.

CB> Yes, you got me. I think I abused copy & paste :D. I'll fix this. Sorry.

CB> Same.

…

…

…

CB> OK!

CB> OK!

    +--------+                            +--------+
    | DHCPv6 |                            | DHCPv6 |
    | client |                            | server |
    +--------+                            +--------+
        |                                      |

CB> OK, so you mean to replace for example  "Solicit(IA_LL(quad))" with "Solicit(IA_LL(QUAD))" and then also fix the text according to your suggestion, right?

BV2> YES.

…

…

…

CB> OK.

CB> OK.

…

5.1.  Quad (IA-LL) option

CB> OK, thanks a lot for this and all previous good suggestions. We'll include them in the next revision.

Carlos

  *   Bernie

From: dhcwg <[email-masked]<mailto:[email-masked]>> On Behalf Of CARLOS JESUS BERNARDOS CANO
Sent: Tuesday, January 29, 2019 2:33 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt

Hi,

We have submitted a new draft describing DHCP extensions to allow a client/relay specify which SLAP quadrant to use when requesting a MAC address/set of addresses.

Thanks,

Carlos

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, 29 Jan 2019 at 07:43
Subject: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt
To: <[email-masked]<mailto:[email-masked]>>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

[email-masked]<mailto:[email-masked]>