Subject: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.txt - Respond by July 29, 2015

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Jul 2015 21:15:03 +0000

Hi all,

This message starts the DHC working group last call to advance "Customizing DHCP Configuration on the Basis of Network Topology", draft-ietf-dhc-topo-conf-05, document as an Informational RFC. The authors believe that this version is ready. We did a WGLC for the 03 draft in October 2014, which raised some issues and resulted in the updates. At that time, we felt the document did not pass WGLC.

The draft is available here:

http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-05

Please send your comments by July 29th, 2015. If you do not feel this document should advance, please state your reasons why.

There are no IPR claims reported at this time.

Bernie Volz is the assigned shepherd for this document.

- Tomek & Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 22 Jul 2015 11:22:52 +0000

Hi ... just a reminder that this WGLC is coming up. Please review and comment.

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, July 08, 2015 5:15 PM
To: [email-masked]
Subject: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.txt - Respond by July 29, 2015

Hi all,

- Tomek & Bernie

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 27 Jul 2015 11:09:33 +0200

On 08.07.2015 23:15, Bernie Volz (volz) wrote:
> Hi all,
> 
>  
> 
> This message starts the DHC working group last call to advance
> "Customizing DHCP Configuration on the Basis of Network Topology”,
> draft-ietf-dhc-topo-conf-05, document as an Informational RFC. The
> authors believe that this version is ready. We did a WGLC for the 03
> draft in October 2014, which raised some issues and resulted in the
> updates. At that time, we felt the document did not pass WGLC.
> 
>  
> 
> Please send your comments by July 29th, 2015. If you do not feel this
> document should advance, please state your reasons why.
> 
>  
> 

I have read the document and I support advancing it. It provides useful
guidelines to the DHCP servers' users/administrators. It gathers
information from multiple documents in a single place, which makes DHCP
configuration use cases easy to understand.

Here are a few suggestions, that I had while reading this text...

----

The document describes various techniques for selecting the subnet
in case of both DHCPv4 and DHCPv6. Most of the sections provide the
combined text for both protocols, describing similarities and
differences. That's ok. However, in this case it seems important to have
a clear distinction whenever we talk specifically about DHCPv4 and when
we talk about DHCPv6. In all cases, when this document talks about both
protocols (general text), it should refer to them as DHCP.

For example:
- Section 3.1 is about the "DHCPv4 specific behavior", but often uses
the term "DHCP" rather than "DHCPv4".
- Section 3.2 is about the "DHCPv6 specific behavior", but often uses
the term "DHCP" rather than DHCPv6, e.g. "What this means in practice is
that the DHCP server..." or "In all cases, then, the DHCP server
will...". In Section 7: "In this example, when a request comes in to the
DHCP server... " and so on.

Having said that, it may be worthwhile putting this naming scheme into
the terminology, or mention it in the introductory text.

In section 3:
"Sometimes it is useful for the relay agents to provide additional about
the topology".

----

Something is missing here. Perhaps it was meant to say: "... to provide
additional information about the topology...".

Suggest using 'giaddr', rather than GIADDR as the former is the form
used in the RFC2131.

----

The section 3.2 says this:
"In the DHCPv6 protocol, there are two core mechanisms defined in
   [RFC3315] that allow server to distinguish which link the relay agent
   is connected to."

Then it goes through the long description of the first mechanism and it
doesn't mark the beginning of the description of the second mechanism.

Perhaps modify this:
"If for whatever reason that is not feasible (e.g. because the relay
   agent does not have a global address or ULA [RFC4193] configured on
   the client-facing interface), ... "

with:

"The second mechanism uses Interface Id option (see Section 22.18 of
[RFC3315]) inserted by the relay agent, which identifies the link that
the client is connected to. This mechanism may be used for example, when
the relay agent does not have a global address or ULA [RFC4193]
configured on the client facing interface, thus making the first
mechanism not feasible.

Alternatively:
"In the DHCPv6 protocol, there are two core mechanisms defined in
[RFC3315] that allow server to distinguish which link the relay agent
is connected to. First is using the link-address carried in the
Relay-forward and Relay-reply messages. Second is using the Interface Id
option inserted by the relay agent.

----

The following paragraph is confusing:

"The DHCP server uses an IP address from the client's message which is
   on the same link as the client to perform address assignment
   decisions or to select subnet-specific configuration for the client.
   The address that the server uses is the DHCP client's routable IP
   address or the client facing address of the relay agent.  The server
   is then able to determine the client's point of attachment and select
   appropriate subnet- or link-specific configuration."

Specifically, the first sentence could be removed for two reasons:
- it mostly duplicates the second and third sentence
- it is unclear where the "IP address" the first sentence refers to is
assigned. It can be a relay or the client, but it doesn't say so.

How about:

"To determine the client's point of attachment and link specific
configuration, the server typically uses the client facing IP address of
the relay agent. In some cases the server may use the routable IP
address of the client, if the client has the routable IP address
assigned to its interface and it is transmitted in the DHCP message."

----

I am confused with the following text:

" It should be noted that there the link-
   specific identifier is unique only within the scope of the link-
   identifying IP address.  For example, link-specific indentifier of
   "eth0" for a relay agent with IPv4 address 192.0.2.1 means something
   different than "eth0" for a relay agent with address 192.0.2.123."

because I don't know why this example (using IPv4 addresses) is provided
in the section that discusses "DHCPv6 specific behavior". I am also not
quite sure what it is intended to say.

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 27 Jul 2015 14:22:58 +0000

As document shepherd and in response to the WGLC, below are my personal comments:

First, thanks to Marcin for his review and comments as he wrote up many of the issues I had (and also caught a few more).

Second, my view is that the document is almost ready and I support it moving forward after hopefully one more edit (I do not expect any of those changes requiring another WGLC).

The corrections are to clean up wording to improve clarity of the text (see Martin's comments). Also:

In section 9, I think there are two use cases missing. The 4 use cases for "multiple subnets on a link" are:

1.       Renumbering. This is probably more applicable to DHCPv6, but could also be used in DHCPv4 (though renumbering there is not graceful as clients only support a single 'lease').

2.       Expanding the allocation space. In DHCPv4 and for DHCPv6 Prefix Delegation, there could be cases where multiple subnets are needed because a single subnet may be too small to accommodate the client population.

3.       Allocating addresses (or delegation prefixes) that are not the same as topological information. For example, the link-address is on prefix X and the addresses to be delegated is on prefix Y. This could be based on differentiating information (i.e., whether device is CPE or CM in DOCSIS) or just because the link-address/giaddr is different from the actual allocation space.

4.       Differentiated services. Multiple allocation spaces exist for different types of clients (i.e., CPE vs CM in DOCSIS).

I also question whether section 8 (Dynamic Lookup) is really necessary and appropriate to this document. There already is text in http://tools.ietf.org/html/rfc7227#section-8 that discusses this and do we really need it in multiple places? Perhaps adding a reference to this in section 7 (in first paragraph on page 14) would be sufficient?

There are also minor wording changes (adding "a" or "the", rewording several sentences to improve readability, and eliminating contractions (aren't, won't, ...)). And, there are a bunch of typos in the document:

-          "aquired" -> "acquired"

-          "indentifier" -> "identifier" (2 times)

-          "inserted" -> "inserted"

-          "identifers" -> "identifiers"
I will work directly with the authors on these issues.

--

As WG Co-chair, I would appreciate others reading the document and providing their input as to the status of the document.

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, July 08, 2015 5:15 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.txt - Respond by July 29, 2015

Hi all,

- Tomek & Bernie

---

From: 神明達哉 <[email-masked]>
Date: Tue, 28 Jul 2015 11:13:59 -0700

I've read draft-ietf-dhc-topo-conf-05.  It's generally well-written
and I see it useful for some class of readers.

I have one comment/question that might be better to be addressed
before sending it to the IESG (although I don't necessarily think it a
blocking issue): In Section 3.2 it sates:

   For completeness, we also mention an uncommon, but valid case, where
   relay agents set link-local address in the link-address field in
   relayed Relay-forward messages.  This may happen if the relay agent
   doesn't have any address with a larger scope.  Even though link local
   addresses cannot be automatically used to associate relay agent with
   a given link, with sufficient information provided the server is
   still able to correctly select the proper link.  That requires the
   DHCP server software to be able to specify relay agent link-address
   or a feature similar to 'shared subnets' (see Section 9).

First, I'm not sure how I should interpret this sentence: "This may
happen if the relay agent doesn't have any address with a larger
scope."  In its literal sense it seems to say the relay agent only has
link-local addresses.  Is that the intent?  If so, how can it even
forward messages to a server?  In theory, it's still possible if the
server (or the "next relay agent") and the relay agent shares the same
link (which might be a different link from which the relay receives
client messages).  But it's not clear if this sentence talks about
such a special case, and it won't work in the general case where a
server is located in a remote link anyway.  Or, should this sentence
actually read " This may happen if the relay agent doesn't have any
address with a larger scope on the interface to that specific link."?

Secondly, I'm not sure specifically what this means: "the DHCP server
software to be able to specify relay agent link-address".  Is there
anything specific intended here?  If so, I think it's better to
provide at least one example; if not, I'd rather remove this vague
statement.

I also have some minor (more or less) editorial comments:

- Section 3:

   Figure 2 illustrates a more complex case.  [...
   ...]  Note that some nodes act as routers (which forward all
   IPv6 traffic) and some are relay agents (i.e. run DHCPv6 specific
   software that forwards only DHCPv6 traffic).

Until we see discussions in Section 7 it's not obvious just from
Figure 2 that this is an example of IPv6 network using DHCPv6.  It
would be more reader-friendly to explain this is an example case using
IPv6 (and DHCPv6) explicitly here.

- Section 3.1: s/iserted/inserted/

   that is iserted by a relay agent.  This option is particularly useful

- Section 3.2:

   If for whatever reason that is not feasible (e.g. because the relay
   agent does not have a global address or ULA [RFC4193] configured on
   the client-facing interface), the relay agent includes an Interface-

To be pedantic "a global address or ULA" sounds a bit awkward since
ULA is also "global" in terms of address scope.  Perhaps "a globally
unique address or ULA"?

- Section 3.2: s/link local/link-local/

   doesn't have any address with a larger scope.  Even though link local
   addresses cannot be automatically used to associate relay agent with

- Section 7, Figure 4: Unless there's a specific reason, I'd suggest
  using "2001:db8::/40" etc, instead of "2001:db8:0:0::/40" based on
  the recommendation of RFC5952.  For the same reason, I'd replace
  "2001:DB8:0:0::/40" with "2001:db8::/40", etc, in the text that
  follows.

--
JINMEI, Tatuya