Subject: [dhcwg] My read of draft-ietf-dhc-dhcpv6-yang-00

From: Marcin Siodelski <[email-masked]>
Date: Thu, 5 Nov 2015 00:15:50 +0900

In Prague I mentioned I'd review the YANG models for DHCP. There is
never good time to review a document that ends up being 84 pages long. I
finally had a look into this today and reviewed some bits of YANG models
for DJCPv6. Note that it is not all. I just try to highlight the most
obvious things that occurred to me while reading this (mostly client and
server sections).

Abstract
"There has no unified method to configure DHCPv6 server ,relay and
   client itself, always pre-configured manually by operators."

This sentence sounds a bit odd. There are some typos. There is
extraneous "itself". Also, I am not sure what this is trying to say:
"always pre-configured manually by operators", in the context of this
draft. I think this draft doesn't eliminate manual configuration, it
merely introduces unified data structures. The configuration would still
have to be "manual", regardless if remote or local. Or maybe I am
reading something that it doesn't try to say.

Introduction
For completeness, it may also be worth to mention that not only does
this model provide means to configure the server, client and relay, but
it also provides means to gather statistics and notifications from the
server. Perhaps, this could be also mentioned in abstract.

I am not clear what the difference between "configuration" and
"management" is.

I am not very enthusiastic about the paragraph starting:
"For DHCPv6 client configuration..."

I'd suggest something more like this, because it is shorter and less
convoluted:

"The DHCPv6 client module provides means to control the DHCPv6 client
software running on host. For example, it allows for specifying whether
or not the client should request specific DHCP options when it contacts
the DHCP server. This model is not intended to be used to replace or
override host configuration, which a DHCP client (being controlled using
this model) receives from the DHCP server."

I don't understand the need for sections 2.1-2.3, as they don't convey
any information. Are they going to be extended with any specific text?

3.1 DHCPv6 server tree diagrams

Is the ultimate goal to describe *all* elements of the tree under the
tree? Or, you assume that some of those elements don't require
description  in section 3.1 because they are described in section 4?

Proposed models do not make use of the *default* values. There are many
mandatory parameters without default values, which probably implies that
I'd need to always configure them. Is this really the intent?

For example "container sol-max-rt-option" includes a leaf "enable" which
indicates whether this option will be included in the option set - I
read it as it will be sent to the client. Wouldn't it be more convenient
to assume that it is sent if specified, i.e. default for "enable" would
be true. If I don't want to send it, I'd set it to false explicitly.

"ipv6-address" - What address is this? A server could actually contain
multiple interfaces and multiple addresses on each of them. Is this an
address recommended to use to connect to the server with a NETCONF?

"pd-function" - As a matter of curiosity. You define this knob to
enable/disable prefix delegation. But, can you actually enable/disable
address assignment?

"stateless-service"
The definition of this says:
"A boolean value specifies whether the server
      support client-server exchanges involving two messages defined in
      ([RFC3315])."

which is ambiguous. It should rather explicitly mention
Information-request. Note that there are other possibilities for
exchanges involving two messages, e.g. Solicit-Reply (with Rapid Commit).

I am also wondering if it should be possible to define "pd-function" and
"rapid-commit" per network range, e.g. allow prefix delegation for
client's connected to this network but not to that network?

"interfaces-config"
Doesn't a free-text type of configuration for listing active interfaces,
together with optional unicast addresses violate the structure of the
YANG model that is hierarchical? Moreover, the current description
doesn't really explain how to enable multiple selected interfaces, or
all interfaces. Should they be listed as comma separated names? Or, is
it left up to the implementation of the server?

I also think that enabling all interfaces by default may cause
significant issues. If I forget to specify the interface configuration
and I enable the server, it would start replying to all messages it
detects on any of its interfaces. This could disrupt the operation of
the network to which the server is connected.

"vendor-info"
Is this intended to include the name of the server software and its
version? For example: isc-dhcp-4.3?

3.3. DHCPv6 Client Tree Diagrams

"cli-id"
I don't know what this is, and there is no description. Client
identifier? How does it relate to DUID?

"duid"
Per RFC3315 terminology DUID is:
"A DHCP Unique IDentifier for a DHCP
participant; each DHCP client and server
has exactly one DUID.  See section 9 for
details of the ways in which a DUID may
be constructed."

In other words defining DUID per interface would violate the rule of one
DUID per client, no?

"mo-tab"
Is there any particular reason for this awkward configuration using the
MO flags, rather than:

- "request-pd" boolean
- "request-na" boolean
- "stateless" boolean

where "stateless" being true means send Information-request, and if it
is false, the other two indicate what stateful options to request.

On that matter, there is also an interesting question how to configure
the client to request more than one IA_NA if it needs to do so.

I recognize that there is the "ro identity-associations" but it is read
only and probably to only gather the configuration that the client has
obtained, not to configure the client to request a specific address(es).
And how about hints? For example a hint for prefix length.

I also couldn't find in the models the way to configure dedicated
options for specific hosts. Container "reserved-addresses" merely
includes mappings between the DUIDs and addresses, but it is frequently
desired to also provide specific options for clients having reservations.

Also, per RFC6939 the link-layer address of the client may be provided
by the relay, in which case it should be possible to do static
reservation based on the MAC address, rather than DUID.

Marcin

---

From: Linhui Sun <[email-masked]>
Date: Mon, 9 Nov 2015 19:24:26 +0800

Hi Marcin,

Sorry for the delay and really thanks for your detailed review, please see
comments inline.

Regards,
Linhui

> extraneous "itself". Also, I am not sure what this is trying to say:
[LH]: Agree the "itself" is redundant, will remove it.

> reading something that it doesn't try to say.

[LH]: I agree the manual configuration is still inevitable with the help of
YANG model. I think the statement here is so absolute that may mislead
people. How about changing to "There has no unified method to configure
DHCPv6 server, relay and client itself, typically pre-configured by
operators through traditional configuration manners (e.g. command line
interfaces)."

> I am not clear what the difference between "configuration" and
[LH]: IMO, configuration is for those "rw" nodes while the management is
for the "ro" nodes. Do you think we need a very clear distinction between
those two terminologies? Or do you think the concept of "management" should
contain the "configuration"?

> any information. Are they going to be extended with any specific text?
[LH]: This sections are supposed to be filled with several general and
brief description of the model structure (i.e. the server, relay and client
respectively). I think we will complement this in the next version.

> description  in section 3.1 because they are described in section 4?
[LH]: The YANG validator requires us that each data node should have a
description, that is what you could see in section 4. For the Section 3, I
would prefer to provide descriptions of some important nodes.

> I'd need to always configure them. Is this really the intent?
[LH]: We are not intended to imply that people have to configure them every
time. RFC6020 does define how to make a default value for the leaf (use the
"default" statement). We will add this statements in the next version.

> be true. If I don't want to send it, I'd set it to false explicitly.
[LH]: Agree.

> address recommended to use to connect to the server with a NETCONF?
[LH]: It has nothing to do with the NETCONF. I'm just wondering wether to
remove it or make it compatible with the "interfaces-config" list. What's
your suggestion?

> enable/disable prefix delegation. But, can you actually enable/disable
[LH]: I'm afraid I cannot understand what you mean here. Do you mean we
should not enable/disable the prefix delegation?

> exchanges involving two messages, e.g. Solicit-Reply (with Rapid Commit).
[LH]: Agree, will improve the description in the next version.

> client's connected to this network but not to that network?
[LH]: I think it is a good feature and that is what you provide in Kea.
After a brief talk with Tomek before, I think we will make the nodes both
available in global and network ranges in the next version.

> the network to which the server is connected.

[LH]: I think this part definitely need to be refined, I will respond this
later.

> version? For example: isc-dhcp-4.3?
[LH]: Yes

> identifier? How does it relate to DUID?
[LH]: The only reason that "cli-id" was introduced is DUID is a large value
(i.e. not appropriate to be a key value), we use the "cli-id" as the key
value for some lists. But I think we need to omit the "cli-id" to use the
unified DUID.

> In other words defining DUID per interface would violate the rule of one
[LH]: I think that is why the client should be in a per-interface manner,
am I right?

> is false, the other two indicate what stateful options to request.
[LH]: We have discussed these before the dhc session, the "mo-tab" seems to
be difficult to understand and redundant. But I don't understand what the
"request-pd" & "request-na" mean here, I think the "stateless" is enough.

> And how about hints? For example a hint for prefix length.
[LH]: I think this should be included in the "client-configured-options"
container, how about adding the IA_PD option in that  container?

> desired to also provide specific options for clients having reservations.
[LH]: Are you talking about the server side configuration? If so, we could
specified a specific option set for specific hosts (i.e. under the "hosts"
container).

> reservation based on the MAC address, rather than DUID.
[LH]: This needs to be added to the relay portion, thanks.

>
> Marcin
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>