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

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

Hi Ian,

Thanks again for your comments. Please see inline below.

On Fri, Mar 13, 2020 at 4:48 PM <[e-mail]> wrote:

> Hi Carlos,
>
> Thanks for the update.
>
> Please see inline below.
>
> Cheers,
> Ian
>
>
>> -----
>>
>> For the following text:
>>
>>    If a client provides a QUAD IA_LL-option and the relay agent is still
>>    configured to add its preference value, the server SHOULD follow what
>>    is administratively configured in a QUAD_RELAY_PREF internal
>>    variable.  If the value is set to 1, then the realy provided
>>    preference overrides what the client has provided, while if the
>>    variable is set to 0, then the client's provided preference is
>>    considered.  It is RECOMMENDED that QUAD_RELAY_PREF is set to 1 at
>>    the server.
>>
>> I don’t agree with the recommendation here, as in section 4.2 the text
>> states that the
>> client SHOULD NOT configure a prefix from an unrequested quadrant. The
>> ‘1' recommendation
>> says ‘relay knows best’, but the client’s actually got the veto on
>> whether it will configure it
>> or not. The client clearly knows best here!
>>
>
> [CB] Good point. I agree. I've changed it.
>
>
>>
>> Also, the text using QUAD_RELAY_PREF and ‘value is set to 1’ etc. seems
>> overly prescriptive
>> for an implementation. It would be better to use more general terms e.g.
>> ‘administratively
>> configured to evaluate the client’s supplied instance of OPTION_SLAP_QUAD
>> and ignore
>> the relay supplied instance, or vice versa’.
>>
>> [CB] I'm not sure I got this point right. I've rewritten this part and
> now reads as follows:
>
> "If a client provides a QUAD IA_LL-option and the relay agent is still
> configured
> to add its preference value, the server SHOULD follow what is
> administratively
> configured in a QUAD_RELAY_PREF internal variable. If the value is set to
> 1, the
> server is administratively configured to evaluate the client's supplied
> instance
> of OPTION_SLAP_QUAD and ignore the relay supplied instance. If the
> variable is
> set to 0, then the server is administratively configured to evaluate the
> relay's
> provided preference and ignore the client supplied instance. It is
> RECOMMENDED
> that QUAD_RELAY_PREF is set to 0 at the server.”
>
>
> [if - My point here is that defining the name of a configuration parameter
> (QUAD_RELAY_PREF)
> and its allowable values is really unnecessary. I’m sure that implementors
> will use whatever
> naming they see fit.
>
> Additionally, I think the first point has got a bit mangled. Can I propose
> the following text for the
> paragraph which addresses both points:
>
> "
> The server SHOULD implement a configuration parameter to deal with
> the case where the client’s DHCP message contains an instance of
> OPTION_SLAP_QUAD,
> and the relay adds a second instance in its relay-forward message. This
> parameter
> configures the server to process either the client’s, or the relay’s
> instance of option QUAD.
> It is RECOMMENDED that the default for such a parameter is to process the
> client’s instance
> of the option.
> “
> ]
>
>
[CB] OK, I like your proposed text. Thanks a lot!


>
>
>>
>> On 28. Feb 2020, at 00:32, CARLOS JESUS BERNARDOS CANO <[e-mail]>
>> wrote:
>>
>> Hi Ian,
>>
>> Thanks a lot for your comments.
>>
>> Please see inline below.
>>
>>
>> On Tue, Jan 14, 2020 at 12:22 PM <[e-mail]> wrote:
>>
>>> 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
>>>
>>>
>>>
>>> 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.
>>>
>>
>> [if - The text still doesn’t describe how the server parses the client’s
>> request. Can I suggest
>> the. following text change:
>>
>> old:
>> The server, upon receiving a IA_LL option, inspects its content
>>        and may offer an address or addresses for each LLADDR option
>>        according to its policy. The server sends back an Advertise
>>        message ...
>>
>> new:
>> The server, upon receiving a IA_LL option, inspects its contents. For
>> each of the entries in OPTION_SLAP_QUAD, in order of the preference field
>> (highest to lowest), the server checks if it has a configured MAC address
>> pool matching the requested quadrant identifier, and an available range of
>> addresses of the requested size. If suitable addresses are found, The
>> server sends back an Advertise message…. ]
>>
>
> [if - I think this one got missed. As this is now in step 3,  the comment
> is relevant for this.]
>

[CB] OK, sorry. Please check if the new version -06 (with the changes made
before) is OK.
BTW, why do you say it is step 3? the piece of text being discussed is step
2, right?


>
>>
>>> ---
>>>
>>> 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.
>>>
>>
>> [Carlos] Again, a very good point, thanks. I've added some text at the
>> end of Sections 4.1 and 4.2.
>>
>>
>>
>> [if - A question that arises from the above is what the client should
>> then do with any other addressing information that is has been received in
>> the DHCPv6 reply (i.e. an address allocation for a requested IA_NA). Should
>> the IA_NA be used with the existing (initial, temporary) MAC address, or
>> should it not be configured and DHCP retried until a MAC address from a
>> requested quadrant is received (and a new IA_NA allocation with it?]
>>
>
> [CB] That's a very good question. I think the client should configure it
> independently from the MAC address configuration process. If the client
> wants to first configure the MAC address and then other aspects, it could
> follow a sequential process, first configuring its MAC address and then
> going for additional things, no? What do you think?
>
>
> [if - I think this question is relevant to both this draft and
> draft-ieft-dhc-mac-assign. I’ve raised it in a separate email.]
>

[CB] OK.


>
> ----
>>>>
>>>> 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.)
>>>
>>
>> [if. - I didn’t see an answer for this. Also, the relay definition
>> doesn’t state that the relay (may) implement OPTION_SLAP_QUAD.]
>>
>
> [CB] If I got your point right, the relay does not need to support IA_LL,
> only QUAD. However, an implementation of relay might look for instances of
> IA_LL instances in the client's messages and decide whether to add a QUAD
> option (and what to put there) taking into consideration the content of the
> IA_LL option. Do you agree? Should we add some text about this?
>
>
> [if - I still don’t think that this is likely to be implemented, or what
> the benefit would be given that the client can indicate a quad preference
> (if it has one), the relay can add a quad, the server can be configured to
> say which one it will use if there is a choice, and all of this can be done
> without relay message snooping logic. What is missing that would justify
> this complexity?]
>
> [CB] I'll comment on this on top of Bernie's response in a different
> e-mail.
>

Thanks!

Carlos