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 (1), that probably is a good question. And, as the relay and server are more “controlled” (usually in the same administrative domain), perhaps it is not a consideration – other than it may be something to point out?

Regarding (2), I would think that if the relay provided the option, it was an administratively configured choice and so should override the client (i.e., it is administrative policy). I guess we could make it configurable on the server which is to be preferred (though we’d still need to recommend a default)?

But it does get tricky with what do you tell the client in terms of what happened with its preferences (and what if the relay and client preferences match)?

Let’s see what the slap-quadrant authors want to suggest for how to address these issues?

  *   Bernie
From: [e-mail] <[e-mail]>
Sent: Wednesday, January 8, 2020 11:51 AM
To: Bernie Volz (volz) <[e-mail]>; CARLOS JESUS BERNARDOS CANO <[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

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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of CARLOS JESUS BERNARDOS CANO
Sent: Tuesday, January 7, 2020 12:06 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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

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

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

_______________________________________________
dhcwg mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dhcwg