Subject: [dhcwg] Robert Wilton's Discuss on draft-ietf-dhc-slap-quadrant-09: (with DISCUSS and COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 08 Jun 2020 08:46:34 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-dhc-slap-quadrant-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-slap-quadrant/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thanks for writing this document.  I have a few points that I believe are
worthy of discussion.

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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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