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

["Bernie Volz (volz)" <[e-mail]>]

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
   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”?

…
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
   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
   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.

…

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)
   "burned" MAC address, allocated from the universal address space
BV> “burned in”?
…

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”?
      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.
      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?


   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?
                 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.
                 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?
      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?

   Last, if we consider the data center scenario, an hypervisor might
BV> Change “an” to “a”.
   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).


…

   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.
…

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.”

   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.

   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.
…


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].


  *   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]<mailto:[e-mail]>>
Date: Tue, 29 Jan 2019 at 07:43
Subject: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt
To: <[e-mail]<mailto:[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<http://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]<mailto:[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.