Subject: [dhcwg] Review of draft-ietf-dhc-topo-conf-01

From: Simon Perreault <[email-masked]>
Date: Tue, 25 Mar 2014 11:24:03 -0400

Here's my review...

Summary: Nicely written, very tutorial-like material. Nothing
controversial here. I like.

> 2. Terminology
> 
>    an IP address with a scope of use wider than the local link.

Is there something missing here? What is the term being defined?

> 5. Relay agent running on a host
> 
>    Relay agent is a DHCP software that may be run on any IP node.
>    Although it is typically run on a a router, it doesn't have to be
>    one.  Relay agent can be run on a host connected to two links.  That
>    case is presented in Figure 2.  There is router B that is connected
>    to links D and E. At the same time there is also a host that is
>    connected to the same links.  The relay agent software is running on
>    that host.  That is uncommon, but legal configuration.

Is there supposed to be a visual difference in figure 2 between relay E
and e.g. relay A? Is this text simply saying that router and relay are
two separate logical functions that are often, but not necessarily,
co-located? If so, maybe it would be useful to adjust figures 1 and 2
such that all relays that are also routers are identified as
"router+relay" or something like that.

>    However, all modern commercial DHCP servers handle name resolution by
>    querying the resolver each time a DHCP packet comes in.  This means
>    that if DHCP servers and DNS servers are managed by different
>    administrative entities, there is no need for the administrators of
>    the DHCP servers and DNS servers to communicate when changes are
>    made.  When changes are made to the DNS server, these changes are
>    immediately and automatically adopted by the DHCP server.  Similarly,
>    when DHCP server configurations change, DNS server administrators
>    need not be aware of this.

I would have liked further information on how DNS TTLs can/cannot be
reflected in DHCP. What are the impacts? Does reconfigure play a role?
Is the BCP to simply not care about TTL?

In addition, a comparison with geographic DNS would be very useful.

> 9. Relay Agent Configurations
> 
>    It's worth mentioning that although we talk about relay agents and
>    routers in this document mostly as if they are the same device, this
>    is by no means required by the DHCP protocol.  The relay agent is
>    simply a service that operates on a link, receiving link-local
>    multicasts or broadcasts and relaying them, using IP routing, to a
>    DHCP server.  As long as the relay has an IP address on the link, and
>    a default route or more specific route through which it can reach a
>    DHCP server, it need not be a router, or even have multiple
>    interfaces.

This section seems extremely redundant with section 5. Could they be
merged into one?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 26 Mar 2014 03:38:35 +0000

Additional to Simon's comments, here are my review from me.

In general, this is a mature document with clear structure and scope.

Section 3, it is helpful if there are some text to explain/emphases the diff between figure 1 and figure 2 when these figures first presented. In current version, it is not clearly understandable until section 5 and 6.

The footer of Figure 3 and Figure 4 have some errors. They are currently noted as "figure 2 and figure 3"

It may be worthy of adding some text regarding to Relay Agent Information Option (RFC 3046) and Relay-Supplied DHCP Options (RFC 6422), which may initiatively provide more helpful topology information by Relay Agent. This may particularly help in the scenarios of multiple subnets (in section 10). The relay agent may be dedicated to a certain subnet and identify this subnet in Reply-Supplied Option.

Sheng

>-----Original Message-----
>From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Perreault
>Sent: Tuesday, March 25, 2014 11:24 PM
>To: <[email-masked]>
>Subject: [dhcwg] Review of draft-ietf-dhc-topo-conf-01
>
>Here's my review...
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Qi Sun <[email-masked]>
Date: Wed, 26 Mar 2014 19:46:57 +0800

Dear all,

I volunteered to review the document. The document is well written and easy to review. I have some comments in addition to Simon and Sheng’s.

1. Sec 2, Terminology:

[Qi] Is this the definition for “Link-identifying IP address”?

  provider edge router.  The provider router closest to the customer.

[Qi] Suggest:
Provider Edge router (PE router): ...

  customer premise equipment device.  Typically a router belonging to
  the customer that connects directly to the provider link.

[Qi] Suggest:
Customer Premise Equipment device (CPE device): ...

2. Sec 3, on Page 6
   In either case, the DHCP server is able to obtain an IP address that
  it knows is on-link for the link to which the DHCP client is
  connected: either the DHCPv4 client's routable IPv4 address, or the
  relay agent's IP address on the link to which the client is
   connected.

[Qi] The word “obtain” here is confusing: it seems the DHCP server obtains an IP address for its own configuration. Obviously not.

3. The 1st paragraph on Page 7
   DHCPv6 also has support for more finely grained link identification,
  using Lightweight DHCPv6 Relay Agents [RFC6221] (LDRA).  In this
  case, in addition to receiving an IPv6 address that is on-link for
  the link to which the client is connected, the DHCPv6 server also
  receives an Interface Identifier option from the relay agent that can
  be used to more precisely identify the client's location on the
   network.

[Qi] IMHO, the word “receive” here is also confusing, as “obtain” in the previous note.

4. Section 5

s/on a a router/on a router/
BTW, where is the host that connects to the same links with the router B in Figure 2?

Thanks for writing this.

Best Regards,
Qi

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 29 Mar 2014 14:22:36 +0000

Below are some comments I had sent to Tomek a while back ... I think some (or all) of these might have already been noted by others.

I also believe it is worth mentioning RFC 3257, Link Selection sub-option for the Relay Agent Information Option for DHCPv4 - as using these avoids the overloading of giaddr to be both the "location" of the client and the relay address.

---

Section 10.  Mutliple subnets on the same link

Multiple is misspelled in section title.

Section 4, figure is labeled as both Figure 2 and Figure 3?

   {"prefixes":

     {"10.0.0.0/24": {"options": {"routers": ["10.0.0.1"]}

              "on-link": ["a"]}}

      "10.0.1.0/24": {"options": {"routers": ["10.0.1.1"}}

              "on-link": ["b"]}

      "10.0.2.0/24": {"options": {"routers": ["10.0.2.1"}}

              "on-link": ["f"]}

      "10.0.3.0/24": {"options": {"routers": ["10.0.3.1"}}

              "on-link": ["g"]}}

   Figure 2

                                 Figure 3

I also think the text which follows this figure should refer to figure 2, not 3.

Actually the problem is that this should be Figure 3, not 2. And the later "Figure 3" (Section 7) should be Figure 4.

(As a side issue, I wonder whether for v4 example the "prefixes" would be better as "subnet"? Also,

- Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Qi Sun
Sent: Wednesday, March 26, 2014 7:47 AM
To: <[email-masked]>
Subject: Re: [dhcwg] Review of draft-ietf-dhc-topo-conf-01

Dear all,

I volunteered to review the document. The document is well written and easy to review. I have some comments in addition to Simon and Sheng's.

1. Sec 2, Terminology:

[Qi] Is this the definition for "Link-identifying IP address"?

[Qi] Suggest:

[Qi] Suggest:

2. Sec 3, on Page 6

[Qi] The word "obtain" here is confusing: it seems the DHCP server obtains an IP address for its own configuration. Obviously not.

  using Lightweight DHCPv6 Relay Agents [RFC6221<http://tools.ietf.org/html/rfc6221>] (LDRA).  In this

[Qi] IMHO, the word "receive" here is also confusing, as "obtain" in the previous note.

4. Section 5

Thanks for writing this.

Best Regards,
Qi

---

From: Cong Liu <[email-masked]>
Date: Mon, 31 Mar 2014 13:31:36 +0800

Hi all,
I think this work is very helpful and well documented. Here are some minor
comments on this draft.

1. In section 2, the xml missed <list></list> tag.

2. Page 5 paragraph 4, "In either case ..."

Which cases? This sentence only discusses DHCPv4, and DHCPv6 is discussed
in the next paragraph.
Since the next paragraph mentioned dhcpv6 options, it's better to mention
option 82 in this paragraph.

3. In page 6 paragraph 2, "and in some cases which layer 2 link the client
is connected to"

Which paragraph discussed this (L2 link)? I don't get it.

4. In section 3, paragraphs in page 5 and page 6 have no pointer to the two
figures (and are not explaining the figures),
so I suggest to put them in separate sections or subsections.

5. In section 4 Figure 3, replace the 10.0.x/24 prefix with RFC5737 prefix.
(not sure about this, it's quite minor)

6. In section 5, "Relay agent can be run on a host connected to two links."

It can, but one link is enough for a host besides the cascade case.
There're some words in section 9, but I'd like some words in section 5 too.

7. In section 8, "When changes are made to the DNS server, these changes are
    immediately and automatically adopted by the DHCP server."

Wouldn't the changes be adopted by the DHCP server when the next DHCP query
(that requests the corresponding address) comes,
not "immediately"? Although there's no much difference...

Best Regards,
Cong Liu

2014-03-29 22:22 GMT+08:00 Bernie Volz (volz) <[email-masked]>:

>  Below are some comments I had sent to Tomek a while back ... I think some
> (or all) of these might have already been noted by others.
>
>
>
> I also believe it is worth mentioning RFC 3257, Link Selection sub-option
> for the Relay Agent Information Option for DHCPv4 - as using these avoids
> the overloading of giaddr to be both the "location" of the client and the
> relay address.
>
>
>
> ---
>
>
>
> Actually the problem is that this should be Figure 3, not 2. And the later
> "Figure 3" (Section 7) should be Figure 4.
>
>
>
> *From:* dhcwg [mailto:[email-masked]] *On Behalf Of *Qi Sun
> *Sent:* Wednesday, March 26, 2014 7:47 AM
> *To:* <[email-masked]>
> *Subject:* Re: [dhcwg] Review of draft-ietf-dhc-topo-conf-01
>
>
>
> Dear all,
>
>
>
> I volunteered to review the document. The document is well written and
> easy to review. I have some comments in addition to Simon and Sheng's.
>
>
>
> 1. Sec 2, Terminology:
>
> [Qi] The word "obtain" here is confusing: it seems the DHCP server obtains
> an IP address for its own configuration. Obviously not.
>
>
>