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

[[e-mail]]

Hi Bernie / Carlos,

The following paragraph in Bernie’s comments raises a couple of questions:

"Since this and the mac-assign document should probably go as a package, perhaps this argues for requiring implementation of both? Or perhaps we should have the server that supports and used the OPTION_QUAD echo it back (in the IA_LL-options field for clients and Relay-Reply for relay agent) as that would be one way for the client or relay agent to know the server understood it (this would also remove the need for this to be support in the ERO option). Also, if the relay agent’s value was used (overrides the clients), it would NOT be echoed back in the IA_LL-option – just in the Relay-Reply)?”

1, I’m not clear what a relay agent can do by knowing whether the server implements OPTION_QUAD or not.

If the relay is configured to add OPTION_QUAD to the relay-forward message. The contents of this is based on its (static) configuration. If the server understands it and has the correct address type available, it allocates it and sends to the relay. The relay sends the IA_LL to the client.

If the server doesn’t understand it, OPTION_QUAD is ignored, an allocation is made based on whatever the server is configured with and this gets relayed to the client. The relay doesn’t look at the contents of the IA_LL.

What useful action can the relay take based on knowing that the server doesn’t implement OPTION_QUAD?


2, The question of priority in the case that a client sends OPTION_QUAD in its IA_LL and the relay also adds OPTION_QUAD is also interesting. I can see cases where you would want the relay's option to be used over the client’s. But, in the case of a mixed environment where there are devices without OPTION_QUAD and varied types of devices that do (mobile devices, IoT, MAC address randomization for privacy etc.), you may want the server to take the client’s OPTION_QUAD (if present) over the relay’s. It would be worth having some discussion of this is the document.


Thanks,
Ian



> On 7. Jan 2020, at 22:05, Bernie Volz (volz) <[e-mail]> wrote:
> 
> In addition to Ian’s comments, I will add the following for you and the WG to consider:
>  
> For section 5.1, pref-n, I’d suggest explain what this value means (is a lower value more “preferred” or a higher?).
>  
> I’m also still wondering whether a simpler mechanism would just be to have the client provide the list of quadrant values it would like in the order of preference, so the option would be just quadrant-1, quadrant-2, […]. I’m really not sure what the pref value adds and it makes things more complicated in processing.
>  
> If you do keep the quad/pref, you should make it clear whether there is any requirement in terms of ordering or not (I would guess you would want not).
>  
> And, in either case, what does the absence of a quadrant mean – that the server SHOULD NOT assign this or assume they are of even lower preference? This is buried in the text section 4.1, item #2:
>  
>                                               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.
>  
> I think you would want to specify the processing rules in the option description (i.e., section 5.1).
>  
> And, the text earlier in sections 4.1 and 4.2 says “In order to indicate the preferred SLAP quadrant,“ but that seems to be indicating only 1 – not a list of possible values?
>  
> Perhaps in 5.1, after the fields, you should add something like:
>  
> If the client or relay agent provide the OPTION_QUAD, the server uses the quadrant-n/pref-n values to order the selection of the quadrants. If the server can provide an assignment from one the specified quadrants, it should proceed with the assignment. If the server cannot provide an assignment from one of the specified quadrant-n fields, it MUST NOT assign any addresses and return a status of NoQuadAvail in the IA_LL Option.
>  
> There is no requirement that the client or relay agent order the quadrant/pref values in any specific order; hence servers MUST NOT assume that quadrant-1/pref-1 have the highest preference (except if there is only 1 set of values).
>  
> Client and relay agent MUST NOT place the same quadrant value into the option more than once; however servers should be capable of dealing with this by using the more preferred instance (as it requires no special handling).
>  
> If the same preference value is used for more than one quadrant, the behavior as to which is more preferred is random.
>  
> But also note that servers that do not support the OPTION_QUAD will proceed with assigning from whatever may be available. So, I’m wondering if this behavior is really the best – does the client (or relay agent) need to check that the addresses were assigned from the quadrant?
>  
> Since this and the mac-assign document should probably go as a package, perhaps this argues for requiring implementation of both? Or perhaps we should have the server that supports and used the OPTION_QUAD echo it back (in the IA_LL-options field for clients and Relay-Reply for relay agent) as that would be one way for the client or relay agent to know the server understood it (this would also remove the need for this to be support in the ERO option). Also, if the relay agent’s value was used (overrides the clients), it would NOT be echoed back in the IA_LL-option – just in the Relay-Reply)?
>  
>  
> As a nit, you probably should be consistent in usage of Relay-Forw and Relay-Reply (some cases lower case is used) … and per RFC8415, the usage is:
>                 Relay-forward and Reply-reply when referring to the messages
>                 RELAY-FORW and RELAY-REPLY when referring to the msg-type of a message
> So, you want to use “Relay-forward” and “Reply-reply” in pretty much all cases?
>  
> Bernie
>  
> From: dhcwg <[e-mail]> On Behalf Of CARLOS JESUS BERNARDOS CANO
> Sent: Tuesday, January 7, 2020 12:06 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17
>  
> Dear Ian,
>  
> Thanks a lot for your very detailed review. I'll follow up on that on the mailing list and publish a new version (once we have agreed on all the changes) in the next few days.
>  
> Carlos
>  
> On Tue, Jan 7, 2020 at 4:11 PM <[e-mail] <mailto:[e-mail]>> wrote:
> Hi,
>  
> As mentioned in my previous email, here is my review of draft-ietf-dhc-slap-quadrant-01.
>  
> Thanks,
> Ian
>  
>  
> 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>
> -----
>  
> 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?
> ------
>  
> 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.
> ———
>  
> 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.
> --------
>  
>  
> Sections 6 and 7.
>  
>  
> The IANA and Security Considerations need to be completed. I’ve indicated necessary registry updates where relevant.
>  
>  
>  
> Minor Comments
> -----------------------
>  
> Section 3.
>  
> "Migratable/non-migratable VM.  If the function implemented by the VM is subject to be moved
> to another physical server or not.”
>  
> Is the above statement accurate? Surely it’s the migration of the VM (and its function) to a new
> physical server that matters here..
> ———
>  
> 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>
>  
> ———
> Section 5.1
> The ERO option is introduced here, but I’m not sure how/why this would be used. If the server was to echo a Quad option back
> to a relay, what does it do with the received information?
>  
>  
>  
>  
> Grammar / Wording comments
> -----------------------------------------
>  
>  
> 1.1.1. Wifi Devices
> "but ELI/SAI quadrants might be more suitable in some scenarios,
> such as if it is needed that the addresses belong to the CID
> assigned to the IoT communication device vendor.”
>  
> Wording is quite cumbersome, suggest:
>  
> "but ELI/SAI quadrants might be more suitable in some scenarios,
> such as if the addresses need to belong to the CID assigned to the IoT communication
>  device vendor.”
> ——
>  
> 1.1.2 Hypervisor: migratable vs non-migratable functions
>  
> If a VM (providing a given function) might  need to be potentially migrated
> to another region of the data center (due to maintenance, resilience,
> end-user mobility, etc.) it is needed that this VM can keep its
> networking context in the new region, and this includes keeping
> its MAC addresses.
>  
> The language is a bit redundnat in this sentance. Suggested re-word:
>  
> If a VM (providing a given function) needs to be migrated to another region
> of the data center (e.g. for maintenance, resilience, end-user mobility, etc.),
> the VM's networking context needs to migrate with the VM. This includes the VM's
> MAC address(es).
> ---
>  
> Non-migratable functions.  If a VM will not be migrated to another
>       region of the data center, there are no requirements associated to
>       its MAC address, and then it is more efficient to allocate it from
>       the AAI SLAP quadrant, which does not need to be same for all the
>       data centers (i.e., each region can manage its own, without
>       checking for duplicates globally).
>  
> Suggested re-word for readability:
>  
> Non-migratable functions.  If a VM will not be migrated to another
>       region of the data center, there are no requirements associated with
>       its MAC address. In this case, it is more efficient to allocate it from
>       the AAI SLAP quadrant, that does not need to be unique across
>      multiple data centers (i.e., each region can manage its own MAC address
>      assignment, without checking for duplicates globally).
> ——————
>  
> 2. Terminology
>  
> This has the following sentence:
> "The DHCPv6 terminology relevant to this specification from the DHCPv6
>    Protocol [RFC8415] applies here.”
>  
> …then goes on to redefine client and server. Suggest that the above sentence
> is replaced with:
>  
> “Where relevant, the DHCPv6 terminology from the DHCPv6
> Protocol [RFC8415] also applies here. Additionally, the following definitions are updated
> for this document."
> ----
>  
> There also needs to be a definition for the relay function, as it needs to be updated for
> the Quad option as well.
> —————
>  
>  
> 3. Quadrant selection mechanisms
>  
> s/Quadrant selection mechanisms/Quadrant Selection Mechanisms/
> ----
>  
> "We next describe some exemplary ways to perform SLAP quadrant
>    selection.  These are provided just as informational text to
>    exemplify how the quadrant preference mechanisms could be used.”
>  
> Suggested re-word:
>  
> The following section describes some examples of how the quadrant preference mechanisms could be used.
> ——
>  
> Putting the IoT, Wifi and Data Center examples into their own sub-sections would improve the structure and 
> readability.
> ———
>  
> The way that the IoT’s SLAP quadrant decision making is written implies a level of autonomy and free will
> that devices don’t possess and many of considerations are unknowable to the device itself. The bullet points are
> considerations that the device vendor/administrator may wish to use when defining the IoT device’s MAC 
> address request policy. Please reword to reflect this.
> ——
>  
> "IoT devices are typically very
>    resource constrained, so it might be as well that simple decisions
>    are just taken, for example based on pre-configured preferences.”
>  
> Suggested reword for clarity:
>  
> "IoT devices are typically very
>    resource constrained, so there may only be simple decision making
> process based on pre-configured preferences.”
> ——
>  
> s/Most modern OS/Most modern OSs/
> ——
>  
> s/and this might mean the OS to force the use or change of a local MAC address./
> and this might require that the OS forces the use of a local MAC address, or that
> the local MAC address is changed./
> ———
>  
> 4.1 Address assignment from the preferred SLAP quadrant indicated by
>       the client
>  
> s/Address assignment from the preferred SLAP quadrant indicated by
>       the client/Address Assignment from the Preferred SLAP Quadrant Indicated by
>       the Client/
> ——
>  
> s/We describe next/Next, we describe/
> ----
>  
> 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.
> ————
>  
>  
> 4.2 Address assignment from the SLAP quadrant indicated by the relay
>  
> s/Address assignment from the SLAP quadrant indicated by the relay/Address Assignment from the SLAP Quadrant Indicated by the Relay/
> ——
>  
> s/We describe next/Next, we describe/
> ——
>  
> 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.
> ———
>  
>  
> 5.1. DHCPv6 options definitions
>  
> s/DHCPv6 options definitions/DHCPv6 Option Definition/
> ——
>  
> 
> 
> 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>