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

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

Hi Robert,

First of all, apologies for the time it's taken to react to your e-mail.
One of the reasons of it is related to your DISCUSS.

Thanks a lot for your review. Please find below some comments from my side.

On Mon, Jun 8, 2020 at 5:46 PM Robert Wilton via Datatracker <
[e-mail]> wrote:

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

[Carlos] Even though we shared the document months ago (so we assumed that
they have no comments from their side), it was not until recently that IEEE
reacted. We have received comments from Roger Marks on both this document
and draft-ietf-mac-assign and we have taken them into consideration (mostly
the ones related to IEEE policy assignments).

These have been applied to -10 version, to be posted soon.


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

[Carlos] This is exactly the way the mechanism works. We have fixed one
point where originally the client was forced to reject an address
allocation not matching its preference. Now the draft allows the client to
accept an allocation that differs from the expressed preferred quadrants
(as you mentioned, the client can always not accept it and try with a
different server, for example).


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

[Carlos] This has been deleted (the IEEE review also suggested to delete
it).


>
> 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.
>
>
[Carlos] This is a point worth considering. I'm going to delay a decision
on this. Since I'm going through all pending reviews, I'll take a decision
at the end. I hope this is fine with you, even if at the end we decide to
keep the section on the main body.


> 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).
>
> [Carlos] The algorithm should work as you mentioned. It's true that the
text overlaps a bit with draft-ietf-dhc-mac-assign, and it's probably my
fault as I tend to describe things maybe too much. However, at this stage,
with all the reviews the document has got, I'm very confident with all the
text there and I prefer to keep it.

Thanks a lot!

Carlos