Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

[[e-mail]]

Hi Carlos,

Thanks for the update. I’ve got a few more comments on the current version, in addition to Bernie's.

Thanks and best regards,
Ian 

Overall:
Could I propose changing the option name to ‘OPTION_SLAP_QUAD’, as OPTION_QUAD is quite ambiguous, especially out of context?


Section 4.1 Step 2:

"If the server supports the new QUAD IA-LL-option, and manages
a block of addresses belonging to the requested quadrant, the
addresses being offered SHOULD belong to the requested
quadrant.  If the server does not have addresses from the
requested quadrant, it MUST return the IA_LL option
containing a Status Code option with status set to NoQuadAvail (IANA-2).”

1, This should describe the process of checking the QUAD option’s 
priorities to find the highest priority quadrant with an available address.

2, What is the case where a server has addresses available from a requested
quadrant, but makes an allocation from a different quadrant (i.e. why is this a SHOULD,
not a MUST)?

3, For the NoQuadAvail error, am I right in saying that there are two cases that could be
generated:
i, The server does not have a configured address pool matching the client’s request.
ii, The server has a configured address pool of the correct quadrant, but no available 
addresses.

Really, these are not the same error. (i) is a NoQuadAvail, but (ii) is more like the
existing Code 2 NoAddrsAvail. Would this be a better choice to use here?

4,  Is NoQuadAvail sent for every higher QUAD preference that can’t
be met? i.e. if the client specifies ELI, SAI, AAI in that order, but the server can only
supply AAI, then does it send NoQuadAvail for ELI and SLI? My guess is that it shouldn’t,
but the current text could be read to mean that.

5, It would be better throughout this paragraph to use ‘a requested quadrant’ instead of
’the requested quadrant’ as the document is describing a mechanism for indicating
the preference of multiple quadrant types.

---

Section 4.1 Step3. 
1, Does the client perform any validation that the received MAC address comes from one of 
the requested quadrants? If the address doesn’t, what does the client do? I think it would be worth having
some text on how the client is expected to behave in this case. This is especially important
in the case of the relay adding the option, as if the quadrant the relay prefers is one that the
client will not configure, then there’s a risk of breaking things.

----

Section 4.2 Step 3.

"or other means such as based on analyzing the Solicit message from the client."

I’m a little uncomfortable about this line as to implement this requires additional logic in
the relay. IME experience this does not tend to go very well
(see draft-fkhp-dhc-dhcpv6-pd-relay-requirements). If this logic is necessary, then I think
it’s behaviour needs to be properly specified. If not, I would rather see this line removed.
It could always be specified in a follow up document if necessary.

---

Section 5.1
1, For the quadrant-n description, the values 3 & 4 are listed as reserved. As this is a mapping of
 a 2-bits (Y-bit and Z-bit), why are there a total of 5 values (0-4 incl.) listed?
Also, as the table in Fig 2 already effectively gives values for each of the types, wouldn’t it 

2, There’s a discrepancy in the new text between:

"If a same preference value is used for more than one quadrant,
it is left to the server implementation which
quadrant should be preferred (if the server can
assign addresses from all of some of the quadrants
with the same assigned preference).”

and

If the same preference value is used for more than one quadrant, the
behavior as to which is more preferred is random.

I suggest that the second paragraph is deleted as the first offers more flexibility for implementors. 
However, if the option format is changed to an ordered list, then this is no longer necessary.

———

One other grammatical nits on rereading:

4. s/DHCPv6 extensions/DHCPv6 Extensions/


In addition, please see the following comments on your answers. I’ve removed the ones that are closed.


> 
> 
> Major Comments
> ———————————
> 
> Section 4.2
> 
> If the relay needs to insert the Quad option, then as I understand it, the right way to do this would be for the relay to put it into a Relay Supplied Option Option
> (RSOO RFC6422). This requires an update to the IANA table at:
> 
> https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option <https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option>
> 
> [CB] As I understand RFC6422, this is useful if the relay needs to provide info to the client, but this is not the case. We just need the relay to include the preference to be considered by the server when assigning the link-local address.

[if - On re-reading RFC6422, I agree.]


>  
> -----
> 
> Step 3. If the client is sending multiple instances of the IA_LL, how are these associated to the relevant Quad option(s) added
> by the relay, or is only a single quadrant possible for all of the IA_LLs in the client’s message?
> 
> [CB] We assumed that only a single Quad option could be sent, applying those preferences to all IA_LLs in the client message. I've added some text explicitly explaining this (in Steps 2 and 3).

[if - Isn’t there a requirement on the server as well as the relay here? The relay only adds one instance of QUAD, but the server has the requirement on how this is to be interpreted. How about the following text for both step 2 & 3 (I’ve incorporated Bernie’s text suggestion as well)?:

old:
Note that if the client is sending  multiple instances of the IA_LL
in the same message, the DHCP relay MUST include a single
QUAD option, that applies to all of the IA_LLs in the client's message.

new:
Note that if a client sends multiple instances of the IA_LL
option in the same message, the DHCP relay MUST ONLY add a single
instance of the QUAD option. The server SHOULD apply the
contents of the relay’s supplied QUAD option for all of the
client’s IA_LLs, unless configured to do otherwise.

>  
> ------
> 
> Section 5.1
> 
> The structure of the option seems needlessly complex and introduces problems/exceptions that currently aren’t discussed, but could be 
> avoided. i.e. what happens if a quadrant id appears more than once? What if two id’s have the same preference values?
> 
> Couldn’t a simple, ordered list be used here? This would be processed in order (first to last) until a match is found. RFC8026 provides
> an example of this.
> 
> [CB] Since not all the quadrants might appear in the option, we believe it's better to keep the current format, but we agree that we have to add text to discuss how different cases should be addressed, and which ones should be avoided. I've added some text to clarify that part.

[if - I’m with Bernie on this. It would be much simpler. Using an ordered list format does not mean that every value has to appear in it. ]


>  
> ———
> 
> I’m not sure if a new IANA registry of the valid values for the 'quadrant-n’ field is necessary. I’d appreciate the Chairs input on this.
> 
> [CB] I'll wait for Chairs' advise on this.

[if - I wonder if a point

>  
> ———
> 
> Section 4.1
> 
> A ’NoQuadAvail’ error code is mentioned, but this is the only place in the document it occurs. If a new
> DHCPv6 error code is being created, then this needs to be defined and the IANA registry updated:
> https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-5 <https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-5>
> 
> [CB] I've added it to the IANA considerations sections.

[if - As Bernie notes, the IANA section still needs some work.]

> 
> ----
> 
> There also needs to be a definition for the relay function, as it needs to be updated for
> the Quad option as well.
> 
> [CB] I've added it. Thanks.

[if - One question about the wording here - does the relay need to support IA_LL, or only QUAD? I don’t see
any requirement for the relay to look for instances of IA_LL in the client’s messages, and the relay doesn’t 
create them itself.)

> 
> 
> Putting the IoT, Wifi and Data Center examples into their own sub-sections would improve the structure and 
> readability.
> 
> [CB] I have mixed feelings here. I see your point, but I still like the distinction between WiFi devices (that includes both IoT and WiFi devices required additional privacy protection) and the data center (hypervisors). I'll think a bit more about it. If others have an opinion on this, that would be appreciated.
> 
> ———
> 

[if - OK]

>  
> ----
> 
> Much of the content of this section duplicates what is described in [I-D.ietf-dhc-mac-assign].
> It would be better just to have a pointer to the relevant sections of that document and describe
> the changes that the Quad option makes to this process.
> 
> [CB] I prefer to keep it is for completion. I'd like to hear other opinions as well.

[if - OK]

> 
> ——
> 
> Figure 4 seem to show that the relay adds the Quad option into the client's SOLICIT - i.e. alters the contents of the client’s
> message.
> 
> This is not described by the body text, but the diagram needs to be fixed to avoid confusion here.
> 
> [CB] I'm not sure I follow this. The next says that "The relay, based on local knowledge and policies, includes in the Relay-Forw message the QUAD option with the preferred quadrant.", so it is described in the text, or am I missing something?


[if - I should have explained this better. Figure 4 shows the following:

2. Relay-forward
(Solicit(IA_LL),QUAD)

The parentheses seem to indicate that QUAD is being inserted either into the client’s solicit message, or the relay_msg). The following format shows the encapsulations better:

Relay-forward
((RELAY_MSG(SOLICIT(IA_LL)),QUAD))
]

> 
> 
> 
>> On 30. Oct 2019, at 02:51, Tomek Mrugalski <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi,
>> This mail initiates a Working Group Last Call on two related IDs:
>> 
>> Link-Layer Addresses Assignment Mechanism for DHCPv6
>> draft-ietf-dhc-mac-assign-01
>> https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01 <https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01>
>> 
>> and
>> 
>> SLAP quadrant selection options for DHCPv6
>> draft-ietf-dhc-slap-quadrant-01
>> https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-01 <https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-01>
>> 
>> Authors believe those drafts are ready for WGLC. Please post your
>> substantial comments and your opinion whether those are ready for
>> publication or not. If you have minor editorial comments, you may send
>> them to the authors directly.
>> 
>> Please post your comments by Nov. 17th.
>> 
>> Cheers,
>> Tomek
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>