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

["Bernie Volz (volz)" <[e-mail]>]

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.


  *   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]<mailto:[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]<mailto:[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?]