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,

Please see inline below.

On Fri, Mar 13, 2020 at 6:17 PM Bernie Volz (volz) <[e-mail]> wrote:

> Hi:
>
>
>
> Regarding the last point:
>
>
>
> [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?]
>
>
>
> First, I’ve lost exactly what section/text we are talking about here …
>
>
>
> Second, I agree that there is no need for a relay to support IA_LL (look
> for in client’s message) … it just adds the SLAP_QUAD option (it can do
> this blindly to all messages, even those without a client IA_LL). There’s
> no reason for the server to care about the SLAP_QUAD option if no IA_LL is
> present in the client’s message so it does not harm for relay to blindly
> add it. Processing of the SLAP_QUAD only comes up if there is a Solicit,
> Request, Renew, Rebind with a IA_LL. For all other cases, the relay’s
> option would just be completely ignored by server.
>

[CB] OK, I've removed in the definitions part, in the relay text the need
for the relay to support IA_LL and LLADDR. This should be, unless I
misunderstood something, what Ian was referring to.

Thanks,

Carlos

>
>
>    - Bernie
>
>
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* Friday, March 13, 2020 11:48 AM
> *To:* CARLOS JESUS BERNARDOS CANO <[e-mail]>
> *Cc:* Tomek Mrugalski <[e-mail]>; Bernie Volz (volz) <
> [e-mail]>; dhcwg <[e-mail]>
> *Subject:* Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and
> draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17
>
>
>
> 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.
>
> “
>
> ]
>
>
>
>
>
>
>
>
>
> 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.]
>
>
>
>
>
>
>
> ---
>
>
>
> 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.]
>
>
>
> ----
>
>
>
> 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?]
>
>
>
>
>