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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

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) <[e-mail]> 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 <[e-mail]>
> *Sent:* Sunday, March 10, 2019 12:07 PM
> *To:* Bernie Volz (volz) <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [dhcwg] Fwd: I-D Action:
> draft-bernardos-dhc-slap-quadrant-00.txt
>
>
>
> 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 <
> [e-mail]> wrote:
>
> Thanks Bernie!
>
>
>
> Carlos
>
>
>
> On Mon, Feb 4, 2019 at 7:53 PM Bernie Volz (volz) <[e-mail]> wrote:
>
> Great. See one response to your question (BV2).
>
>
>
>    - Bernie
>
>
>
> *From: *CARLOS JESUS BERNARDOS CANO <[e-mail]>
> *Date: *Monday, February 4, 2019 at 1:37 PM
> *To: *Bernie Volz <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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) <[e-mail]> 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 <[e-mail]> *On Behalf Of *CARLOS JESUS
> BERNARDOS CANO
> *Sent:* Tuesday, January 29, 2019 2:33 PM
> *To:* [e-mail]
> *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: <[e-mail]>
> Date: Tue, 29 Jan 2019 at 07:43
> Subject: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt
> To: <[e-mail]>
>
>
>
>
> 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
> [e-mail]
> 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.
>
>