Subject: [dhcwg] Multi-Level DHCP

From: Robert Yabad <[email-masked]>
Date: Fri, 19 Nov 2010 12:24:12 -0800 (PST)

----- Forwarded Message ----
From: Ted Lemon <[email-masked]>
To: Robert Yabad <[email-masked]>
Sent: Fri, November 19, 2010 7:48:03 PM
Subject: Re: Multi-Level DHCP

On Nov 19, 2010, at 1:34 PM, Robert Yabad wrote:
Can we find a way to deliver some configurations from provider DHCP server to 
host N without configuring the CPE?

Maybe you should bring this up on the working group mailing list.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 19 Nov 2010 21:29:37 +0000

Passing options to a host through a CPE was close to the idea behind draft-ietf-dhc-container-opt

- Ralph

On Nov 19, 2010, at 8:24 PM 11/19/10, Robert Yabad wrote:

>> Can we find a way to deliver some configurations from provider DHCP server to host N without configuring the CPE?
> 
> <dhcp.txt>_______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Robert Yabad <[email-masked]>
Date: Fri, 19 Nov 2010 16:25:30 -0800 (PST)

Hi Ralph,
Your problem statement is very clear and absolutely very close to my case. But I 
did not get your idea in the solution,
let us take the first one (the preferred solution)

"SP server passes container option to RG client, which forwards
      contents to RG server; this alternative is the preferred solution"

 SP server --FWD--> RG Client --FWD-->RG Server --????->hosts???

Did you meant the RG server will forward these options to the attached hosts?
If so, how does the RG server knows that he should forward these options to the 
hosts?
I am sorry I have no practical experience in installing DHCP servers at all. But 
all what I need to know
is that: how to deliver some options from SP DHCP server to the cleint host 1 
for example regardless of the number of DHCP servers in the way?(please see the 
diagram that is shown below.

   Client host 1-+  +---------+           +------+                  |  |   RG    
|           |  SP  |    Client host 2-+  |   Client+--- ... ---+ DHCP |                  
+--+Server   |           |server|    Client host 3-+  +---------+           
+------+

Many Thanks
Robert

________________________________
From: Ralph Droms <[email-masked]>
To: Robert Yabad <[email-masked]>
Cc: "[email-masked] Group" <[email-masked]>
Sent: Fri, November 19, 2010 10:29:37 PM
Subject: Re: [dhcwg] Multi-Level DHCP

Passing options to a host through a CPE was close to the idea behind 
draft-ietf-dhc-container-opt

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Sat, 20 Nov 2010 14:41:18 -0500

Robert - the core idea is that:

1) the RG client passes the container option to the RG server.
2) the RG server parses the contents into TLVs (DHCP options)
3) the RG server includes those TLVs in any responses to clients

The reason for the container option is to provide a path through which the SP DHCP server can pass TLVs to the hosts without specific knowledge about the TLVs in the RG.  With the container option, the SP DHCP server can pass new TLVs, defined after the RG was deployed, or other TLVs aside from the usual DNS recursive servers and domain search list.

- Ralph

On Nov 19, 2010, at 7:25 PM 11/19/10, Robert Yabad wrote:

> Hi Ralph,
> Your problem statement is very clear and absolutely very close to my case. But I did not get your idea in the solution,
> If so, how does the RG server knows that he should forward these options to the hosts?
> I am sorry I have no practical experience in installing DHCP servers at all. But all what I need to know
> is that: how to deliver some options from SP DHCP server to the cleint host 1 for example regardless of the number of DHCP servers in the way?(please see the diagram that is shown below.
> 
> 
>    Client host 1-+  +---------+           +------+
>                  |  |   RG    |           |  SP  |
>    Client host 2-+  |   Client+--- ... ---+ DHCP |
>                  +--+Server   |           |server|
>    Client host 3-+  +---------+           +------+
> 
> 
> Many Thanks
> Robert
>