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 Bernie,

Thanks a lot for the comments. I've updated the doc according to your
comments (-02).

Please see inline below some feedback from my side.


On Tue, Jan 7, 2020 at 10:05 PM 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?).
>

[CB] I've added some text explaining that higher means more "preferred".


>
>
> 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).
>

[CB] Following Ian's comment I've tried to explain better how to process
this. I still believe it's good to have the option as is, but we can
discuss about it and change it if needed.


>
>
> 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).
>

[CB] Good point, done.


>
>
> 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?
>

[CB] Fixed.


>
>
> 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.
>

[CB] Thanks a lot Bernie! I had drafted some similar text to address your
and Ian's comments, but your text is better.


>
>
> 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?
>

[CB] I think we don't need to specify this. The requester can always check
if the assigned address belongs to the most preferred quadrant and take any
action (if needed).


>
>
> 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)?
>

[CB] To be honest, I think I could use a bit of advice here. I removed the
ERO part (as hinted by Ian) and I'm not sure which implementation option is
best to recommend.


>
>
>
>
> 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?
>
>
[CB] I think I fixed this. I'm using "Relay-forward" "Relay-reply".

Thanks a lot!

Carlos


>
>
>    - 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]> 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
>
>
>
> ———
>
> 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]>
> 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
>
> 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]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>