Subject: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt

From: [email-masked]
Date: Mon, 21 Oct 2013 20:57:44 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title           : Customizing DHCP Configuration on the Basis of Network Topology
	Author(s)       : Ted Lemon
                          Tomek Mrugalski
	Filename        : draft-ietf-dhc-topo-conf-00.txt
	Pages           : 10
	Date            : 2013-10-21

Abstract:
   DHCP servers have evolved over the years to provide significant
   functionality beyond that which is described in the DHCP base
   specifications.  One aspect of this functionality is support for
   context-specific configuration information.  This memo describes some
   such features and makes recommendations as to how they can be used.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-topo-conf

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 22 Oct 2013 10:56:36 +0000

Ted/Tomek,

Thanks for this draft. It is very informative. One concern that I have is
that the approach described in figure 3 makes it harder to handle failures.

Another approach is to have the DHCP Server return the same FQDN returned
to all clients. Each client sends a DNS request and gets a DNS reply based
on the source IP of the request. This is the de-facto geo load balancing
which not only allows for locality but also failure. For example, let's
suppose DHCP Server resolves sip.omashu.example.org to 2001:DB8:0:0::2 and
give that IP to the client. Later this SIP Server fails, now what should
the client do? If the client possesses the domain name, it just resolves
it again, gets a different IP address (for a different SIP server) and it
is good to go. If the client only possesses the IP address of the SIP
server, it is stuck until that specific SIP server is online again.

Thanks,

Reinaldo

On 10/21/13 8:57 PM, "[email-masked]" <[email-masked]>
wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 14:19:07 +0000

On Oct 22, 2013, at 6:56 AM, Reinaldo Penno (repenno) <[email-masked]> wrote:
> For example, let's

It would be helpful if you were to review the discussion that happened on this very mailing list about a week ago about the topic of whether it makes sense to configure applications using DHCP.   If you do so, and feel that the question you ask above was not adequately addressed during that discussion, please add to the discussion.

The short answer, though, is that SIP is probably an example of an application that (a) should not be configured by DHCP and (b) if it is configured by DHCP anyway, should probably be configured using an FQDN.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 22 Oct 2013 16:10:30 +0000

Ted,

On 10/22/13 7:19 AM, "Ted Lemon" <[email-masked]> wrote:

>It would be helpful if you were to review the discussion that happened on
>this very mailing list about a week ago about the topic of whether it
>makes sense to configure applications using DHCP.   If you do so, and
>feel that the question you ask above was not adequately addressed during
>that discussion, please add to the discussion.

[RP] that is what I'm doing.

>
>The short answer, though, is that SIP is probably an example of an
>application that (a) should not be configured by DHCP and

[RP] But this draft gives as example in section 5 a DHCP server giving the
address of a SIP server as a DHCP option.

>(b) if it is configured by DHCP anyway, should probably be configured
>using an FQDN.

[RP] And this draft provides the opposite example. In the example in
section 5 the SIP server option is sent as an IP address. This draft says:

"The DHCP server then resolves the domain names listed in the options
   and sends a sip-server option containing the IP addresses that the
   resolver returned for sip.omashu.example.org, and a dns-server option
   containing the IP addresses returned by the resolver for
   dns1.omashu.example.org and dns2.omashu.example.org."

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 16:14:58 +0000

> address of a SIP server as a DHCP option.

Ah, that is the key detail I was missing.   I haven't read the full draft in quite some time; I republished it as a working group draft with comments addressed, but didn't do a full review.   And my thinking about SIP servers and DHCP has been informed by recent discussions.

You are right—we need to find a better example to use.   I'm sorry for misunderstanding—I didn't realize that this is what you were saying.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 22 Oct 2013 18:05:21 +0000

Good that we converged. My suggestion would be to use SIP Servers as an
example of something that should be passed as FQDN (assuming there is a
good reason for a deployment). We can then mention the benefits for client
in terms of Load balancing and failure.

We can replace the SIP option by something that should be returned as an
IP address, for example http://tools.ietf.org/html/rfc5192

Thanks,

Reinaldo

On 10/22/13 9:14 AM, "Ted Lemon" <[email-masked]> wrote:

>Ah, that is the key detail I was missing.   I haven't read the full draft
>in quite some time; I republished it as a working group draft with
>comments addressed, but didn't do a full review.   And my thinking about
>SIP servers and DHCP has been informed by recent discussions.
>
>You are right‹we need to find a better example to use.   I'm sorry for
>misunderstanding‹I didn't realize that this is what you were saying.
>