Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6
draft-ietf-dhc-slap-quadrant-12

As with Robert, I'm interested to hear what coordination with IEEE has occurred, both for this and for the companion "mac-assign" document.

I'm also, as Warren, puzzled as to why the Shepherd Writeup claims there's no IPR claim when the datatracker disagrees, and struck by how much text here overlaps with the "mac-assign" document.

As for editorial remarks, I have some:

Section 1:
* I am unable to parse the bullet that defines the "Administratively Assigned Identifier" quadrant.

Section 1.1.1:
* "Examples of this include: sensors ..." -- remove the colon
* "... temporary MAC address, to send initial ..." -- remove the comma
* "... good for assigning addresses from, but ..." -- remove "from"
* "... easy to track users' movement." -- s/movement/movements/
* "... best SLAP quadrant to assign addresses from, ..." -- suggest "best SLAP quadrant from which to assign addresses, ..."

Section 2:
* Although I realize this section is explicit about where "IA_LL" and "LLADDR" are formally defined, it might be nice to provide their full prose names on first use.
* "... typically 6 bytes long ..." -- s/6/six/

Section 3:
* "If we now take the ..." -- suggest "Next, consider the ..."
* Generally I found this section to have a mushy sort of structure.  It begins and ends by mapping certain use cases onto certain quadrants explicitly, but in the middle seems to wander into a checklist of things you might think about without mapping those concepts toward a preferred quadrants.  You might consider firming this up with, perhaps four separate paragraphs, or even subsections, each describing ideal uses for one of the quadrants, taking into account the facets of that choice you've enumerated here.

Section 6
* I suggest omitting the IANA URL.  What if it were to change?  All you really need is the registry name.

I have one substantive / process question — the Shepherd writeup says that no IPR disclosures exist, but there does seem to be one — I wanted to make sure that this had been noted / process had been followed...

Otherwise, seems good - I must admit I don’t like the fact that there is so much repeated text with the MAC assign document, and that it isn’t clearer that MACs only really have to be unique per segment, but those are just prefernces / opinions...

Thank you for writing this,
W

I support Rob's DISCUSS.

IEEEStd802c-2017 should be a Normative reference.

— Abstract —

   The IEEE is working on mechanisms to allocate addresses in the one of
   these quadrants (IEEE 802.1CQ).

Nit: change “in the one of” to “in one of”.

   given client out of the quadrant requested by relay or client.

Nit: make it “by the relay or client.”

— Section 1 —

      Multicast
      IPv6 packets use a destination address starting in 33-33 and this
      falls within this space and therefore should not be used to avoid
      conflict with the MAC addresses used for use with IPv6 multicast
      addresses.

There are multiple problems with this sentence, starting with its being too long.  I suggest this (but please correct this if I got it wrong):

NEW
      Multicast
      IPv6 packets use a destination address starting with 33-33, which
      falls within the AAI quadrant.  Those addresses should not be used,
      in order to avoid conflict with the MAC addresses used for IPv6
      multicast.
END

   o  Quadrant "Reserved for future use" where MAC addresses may be

Nit: remove “where”.

— Section 1.1 —

   allocates the MAC address to the given client out of the quadrant
   requested by relay or client.

Nit: make it “by the relay or client.”

— Section 3 —

   o  Type of IoT deployment: e.g., industrial, domestic, rural, etc.
      For small deployments, such as domestic ones, the IoT itself can

Twice in this paragraph you say “the IoT”, when I think you mean “the IoT device”.

   IoT devices are typically very resource constrained, so
   there may only be simple decision making process

Make it “be a simple decision-making process”

   If we now take the WiFi device scenario, considering for example that
   a laptop or smartphone connects to a network using its built in MAC
   address.

This is not a complete sentence; please make it one.

   Besides,
   changing the SLAP quadrant used might also be used as an additional
   enhancement to make it harder to track the user location.

This is awkward, “used might also be used”.  I suggest, “...changing the SLAP quadrant might also...”.

   SLAP quadrant using information provided by the cloud management
   system (CMS) or virtualization infrastructure manager (VIM) running

Neither abbreviation is used elsewhere in this document, so I suggest removing both “(CMS)” and “(VIM)”.

      as some quadrants are
      better suited (e.g., ELI/SAI) for supporting migration in a large

The parenthetical is misplaced and interrupts the sentence flow.

NEW
      as some quadrants (ELI and SAI) are
      better suited for supporting migration in a large
END

or, better still:

NEW
      as the ELI and SAI quadrants are
      better suited for supporting migration in a large
END

   o  VM connectivity characteristics , e.g.,: standalone, part of a

Nit: punctuation around “e.g.” is wrong:

NEW
   o  VM connectivity characteristics, e.g., standalone, part of a
END

— Section 4.1 —

      The client SHOULD NOT pick a server that does not
       advertise an address in the requested quadrant.

This SHOULD NOT doesn’t make sense to me.  Why would it?  What would be an informed reason to pick one that doesn’t have what it wants?  Is there a reason not to just say, “The client will pick a server that advertises an address in the quadrant the client requested,” without using BCP 14 key words?

I had a little bit of a hard time understanding how all the given
examples benefit from using a specific quadrant for their allocations,
but that may just be my lack of background, and in any case is not a
reason to hold up the document.

Section 1.1.1

   o  IoT (Internet of Things): where there are a lot of cheap,
      sometimes short lived and disposable devices.  Examples of this
      include: sensors and actuators for health or home automation
      applications.  In this scenario, it is common that upon a first
      boot, the device uses a temporary MAC address, to send initial
      DHCP packets to available DHCP servers.  IoT devices typically
      request a single MAC address for each available network interface.

I'm a bit confused by the use of present tense here ("it is common"),
given that AFAIK the companion document draft-ietf-dhc-mac-assign is the
first mechanism for DHCP-based MAC address assignment.

      temporary MAC address.  This type of device is typically not
      moving.  In general, any type of SLAP quadrant would be good for
      assigning addresses from, but ELI/SAI quadrants might be more
      suitable in some scenarios, such as if the addresses need to
      belong to the CID assigned to the IoT communication device vendor.

side note: I'm curious what kind of case would require that the address
belong to the CID of the device's vendor.

Section 2

Interesting that we say that client+server support IA_LL and LLADDR but
nothing about QUAD :)

Section 3

   change address several times).  This information includes, but it is
   not limited to:

   o  Type of network the device is connected: public, work, home.

   o  Trusted network?  Y/N.
   [...]

nit: it might be nice to use a parallel structure for all of the bullet
points ('?' vs ':', prose discussion vs short answer, etc.)

   o  Mobility?  Y/N.

A few more words about what sense "mobility" is used in might be in
order.

   quadrants.  If the device is not moving and attached to a trusted
   network (e.g. at work), then it is probably best to select the ELI

side note: it's not entirely clear that "at work" implies "not moving"
-- in some environments it's common to move between desk and conference
room, potentially on a different floor or in a different building.

   Last, if we consider the data center scenario, a hypervisor might
   request local MAC addresses to be assigned to virtual machines.  As
   in the previous scenarios, the hypervisor might select the preferred
   SLAP quadrant using information provided by the cloud management
   system (CMS) or virtualization infrastructure manager (VIM) running
   on top of the hypervisor.  This information might include, but is not
   limited to:

As was (IIRC) noted by a directorate reviewer, we don't use "CMS" or
"VIM" again, and since at least "CMS" collides with another well-known
IETF acronym, there seems to be little or negative value in including
the acronyms here.

Section 4.1

I suggest using "IA_LL(LLADDR,QUAD)" in step 1 of Figure 3, as is done
for the other lines, to match the prose text's MUST-level requirement to
include LLADDR.

       option.  In order to indicate the preferred SLAP quadrant(s), the
       IA_LL option includes the new OPTION_SLAP_QUAD option in the
       IA_LL-option field (with the LLAADR option).

Even though QUAD does not give provision for nested options, it would
perhaps be better to use "alongside" or "as a sibling of" or similar,
rather than "with", to describe the relationship between QUAD and
LLADDR.
Also, nit: s/LLAADR/LLADDR/.

       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 the requested quadrant(s), the
       addresses being offered MUST belong to the requested quadrant(s).

nit: I don't expect a single block of addresses to span quadrant
boundaries, so perhaps "belonging to a requested quadrant" and "MUST
belong to a requested quadrant" would be more appropriate.

   3.  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 SHOULD NOT pick a server that does not
       advertise an address in the requested quadrant.  The client then

Perhaps "quadrant(s)" or "a requested quadrant", to match the previous
discussion?

       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.  It includes the preferred SLAP quadrant(s) in
       the new QUAD IA_LL-option.

nit: I think s/the new/a new/ is better, since we have not discussed a
new QUAD option in the Request yet.

   The client SHOULD check if the received MAC address comes from one of
   the requested quadrants.  Otherwise, the client SHOULD NOT configure
   the obtained address.  It MAY repeat the process selecting a
   different DHCP server.

"repeat the process" sounds like sending the same Renew to a different
server, that is, different from the server that assigned the address
whose renewal is being requested.  Is that expected to be effective
(either in renewing the current assignment or in getting a new
allocation in a Reply, as opposed to an "I don't know about that" error
response)?

Section 4.2

side note: It's interesting to me that QUAD is not included in a
Relay-reply(Advertise()) but is included in a regular Advertise() when
no proxy is involved.  (Likewise for wrapped Reply().)

        payload.  Depending on the server's policy, the instance(s) of
        the option to process is selected.  For each of the entries in

Just to check: this is intended to allow both "use only one, and if both
are present which to use is up to local policy" and "apply the
intersection of both requests [with some local policy for which priority
to respect]"?  I note that later on we have some text that makes it
RECOMMENDED to prefer the client's, in a discussion that does not cover
the "intersection" option at all.  So perhaps the "intersection" option
is not intended to be available?

        in a Relay-reply message.  If the server supports the semantics
        of the preferred quadrant included in the QUAD option, and
        manages a block of addresses belonging to the requested
        quadrant(s), then the addresses being offered MUST belong to the
        requested quadrant(s).  The server SHOULD apply the contents of

[same nit as for §4.1]

   10.  This message is forwarded by the Relay in a Relay-forward
        message, including a QUAD IA_LL-option with the preferred
        quadrant.

I would consider repeating the mention from above about how the QUAD is
included here in case the server has to make a new assignment, to make
sure that the client (well, proxy's) preference is available in such
cases.

Section 5.1

   quadrant-n      Identifier of the quadrant (0: AAI, 1: ELI, 2:
                   Reserved, 3: SAI).  Each quadrant MUST only appear
                   once at most in the option.  A 1-byte field.

Perhaps note that this is Reserved in the sense of the IEEE quadrant,
not the usual IETF/IANA "reserved" usage?

   assigned preference).  Note that a quadrant - preference tuple is

nit: earlier we spell this a "(quadrant, preference) pair".  Using
consistent notation/terminology seems advisable.

   used in this option (instead of using a list of quadrants ordered by
   preference) to support the case whereby a client really has no
   preference between two or three quadrants, leaving the decision to
   the server.

side note: it's not 100% clear to me that we need to exclude the "no
preference among all four quadrants" case, though I certainly am not
insisting that we include it.

   specified quadrants, it SHOULD proceed with the assignment.  If the
   server cannot provide an assignment from one of the specified
   quadrant-n fields, it MUST NOT assign any addresses and return a
   status of NoQuadAvail (IANA-2) in the IA_LL Option.

This text seems to lose some of the subtlety around NoQuadAvail vs.
NoAddrsAvail that is prsent in Section 4.1.  It would be good to be
consistent about how we discuss these cases.

Section 7

Do I understand correctly that there is no technical mechanism to
prevent a relay from inserting a QUAD option inside what is nominally
the client's IA_LL, as opposed to as a top-level option in Relay-forward
(which is what it's "supposed to" do)?  We should probably say something
about how the proxy has to be trusted to do the right thing and a
malicious proxy could change/override the client's preference.

I'm surprised that RFC 7227 is not referenced here.

Though it is not referenced (yet?), RFC 7227 says that authors of
documents defining new DHCP options are "strongly advised to explicitly
define validation measures" for recipients of such options.  I do not
see much discussion of validation measures in this document (despite
there being MUST-level requirements on the quadrant-n fields with
respect to each other), just a mention that "first occurrance wins",
which is not exactly a validation step but more of a processing one; why
is there no need to provide more detailed validation measures?

Section 8

   The work in this draft will be further developed and explored under
   the framework of the H2020 5Growth (Grant 856709) and 5G-DIVE
   projects (Grant 859881).

I'm not 100% sure that we need to speculate about the future here
(especially given that it would become stale as time passes); would it
suffice to say that "this work is supported by" the grants in question?

Section 9.1

It's not entirely clear to me that we reference RFC 8200 in a normative
fashion.

Discuss cleared.  The document has been reviewed by some members of IEEE, and appropriate mark ups have been made.

Thank you for your perseverance to see this one through.

Rob


Previous discuss comment:

Disclaimer: I'm not familiar with IEEE 802.1CQ, nor am I a DHCPv6 expert ...  Some of these questions/comments may have been answered there.

My first question relates to process:  Have members of the IEEE 802.1WG had an opportunity to review and provide input into this document?  If not, then I think that it would be good for them to be given the opportunity to do so.  In particular, they might question whether it is appropriate for a client to be able to request MAC addresses to be assigned from the SAI or "reserved for future use" address pools.  It is worth noting that there is an IETF-IEEE liaison meeting on Mon 15th, that may help. 

I'm not sure that I really like how the algorithm is defined in this document (relative to draft-ietf-dhc-mac-assign).  In draft-ietf-dhc-mac-assign, the client makes a request, and the server can respond with a completely different smaller MAC address range, i.e. the client is just providing hints/suggestions to the server.  I would be much happier if the QUAD option specified in this document behaved similarly.  I.e. the QUAD option is used by a client to specify an ordered preference of quads to use, but otherwise the server is allow to offer up an address, or block of addresses, outside the preferred quads, which the client could choose to not accept, or release.

Previous non blocking comments.

1. Introduction

   o  Quadrant "Administratively Assigned Identifier" (AAI) MAC
      addresses are assigned locally by an administrator.  Multicast
      IPv6 packets use a destination address starting in 33-33 and this
      falls within this space and therefore should not be used to avoid
      conflict with the MAC addresses used for use with IPv6 multicast
      addresses.  For 48-bit MAC addresses, 44 bits are available.

Multicast IPv6 packets shouldn't be a problem for the AAI range, on the assumption that only unicast MAC addresses get assigned.  Hence, probably the text related to Multicast IPv6 addresses can be deleted.

3.  Quadrant Selection Mechanisms examples

I see that this text as not being normative, and is potentially somewhat repeating what has been stated in the introduction.  I think that this text might be better moved to an appendix.

4.  DHCPv6 Extensions

The algorithmic description in this document seems to heavily overlap with the algorithm described in draft-ietf-dhc-mac-assign, with a fair amount of repetitive descriptive text of the algorithm.  I believe that it would be better if this option was written as a modification of the procedure defined in draft-ietf-dhc-mac-assign (particularly, if the algorithm is simplified as a I propose in my discuss).