Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 2 May 2011 11:16:32 -0500

Where does this one stand?

I wasn't at the meeting and this is a bit 'late' but was just reviewing
the minutes that Ted had uploaded.

>From the draft and from the slides:

http://tools.ietf.org/html/draft-asati-dhc-relay-agent-config-00
http://www.ietf.org/proceedings/80/slides/dhc-9.pdf

I don't really understand what this is all about and there really is
very little here to go on. I must be missing something basic?

This document defines a new option (which contains suboptions of WHAT?)
and one suboption (which contains what)? Perahps figure 2 was supposed
was not supposed to be an example (Subopt X not 1)?

Seems silly to have a document which defines a new option to contain
suboptions but no suboptions are defined? If this suboption space is
elsewhere, can that document be referenced? Perhaps the these suboptions
are the normal DHCPv4 options except they are passed to the relay? But
nothing in the document makes this clear to me.

The appendix discusses applicability to MPLS IP/VPN but there is nothing
here to give us much guidance on what suboptions might exist. I would
guess that this might contain the following potential data:

   The PE configuration information, in RFC4364 environment, may
   contain one or more of the following -
    - IP address and subnet for PE-CE interface
    - VRF Configuration (RD, RT etc.)
    - Other PE-CE Interface configuration (description, vrf mapping
   etc.)
    - Selected Routing Protocol instance (for the CE)
    - Neighbor and ASN information in case of BGP or EIGRP
    - Security, QoS information etc. (for the CE)

There is already a work in progress on the VRF issue (see Kim Kinnear's
draft-ietf-dhc-vpn-option-13 document which is about to be respun and is
in IESG evaluation).

So, it is rather difficult from the information available to give an
opinion on this document. Perhaps more details were provided verbally at
the DHC WG meeting, but that technically doesn't count (??) if it never
makes it to the mailing list.

Thus, I would not support this as a DHC WG work item until the draft is
more flushed out and provides concrete information on what this is all
about (such as defining some suboptions).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rajiv Asati (rajiva)
Sent: Sunday, April 03, 2011 7:02 AM
To: Ted Lemon; John Jason Brzozowski
Cc: [email-masked]
Subject: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00

Given the positive feedback during the WG meeting on Thu, the authors
would like to request the WG adoption of
draft-asati-dhc-relay-agent-config-00. Thanks.

Cheers,
Rajiv

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 May 2011 22:40:57 -0400

> about (such as defining some suboptions).

I can't speak for the authors here, but I think the intent was to separate the transport from the payload: defining a way to carry options to the relay agent to configure it, and then subsequently defining options to be used for configuring it.   Perhaps the authors can speak to this point.

There were a number of suggestions for how to improve the mechanism suggested in the meeting, and there seemed to be interest in the option.   I will admit that in simply reading the draft, it does seem like it's not actually doing anything, so I understand where your comments are coming from.

---

From: Leaf yeh <[email-masked]>
Date: Wed, 11 May 2011 03:50:01 +0000

Ted - I will admit that in simply reading the draft, it does seem like it's not actually doing anything, ...

Got the same feeling or question as Bernie's after the quick review. Can't say yes or hum till now.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2011 08:16:32 -0400

> Ted - I will admit that in simply reading the draft, it does seem like it's not actually doing anything, ...

It occurs to me that one way to address this concern would be to write a second draft that describes a suboption that would be a payload for this mechanism.   The two drafts, presented together, would make more sense than this draft all on its own.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 12 May 2011 08:07:27 +0000

Not sure the separated drafts will get the solid reasons for each of both. 

1.  Do we really need a new option with new structure or architecture for the relay configuration in the case of IPv4 & IPv6?
2.  Would the 2nd draft raise a reasonable solution for BGP/MPLS IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)?

Best Regards,
Leaf

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 May 2011 08:10:38 -0500

I'd prefer one draft - not two. When Option 82 for DHCPv4 was defined,
it included 2 suboptions. More were added later. Why do it in two drafts
- I don't understand the value? It is much clearer if one document
defines all of this.

- Bernie

-----Original Message-----
From: Leaf yeh [mailto:[email-masked]] 
Sent: Thursday, May 12, 2011 4:07 AM
To: Ted Lemon
Cc: [email-masked]; Bernie Volz (volz)
Subject: RE: [dhcwg] WG adoption of
draft-asati-dhc-relay-agent-config-00

Not sure the separated drafts will get the solid reasons for each of
both. 

1.  Do we really need a new option with new structure or architecture
for the relay configuration in the case of IPv4 & IPv6?
2.  Would the 2nd draft raise a reasonable solution for BGP/MPLS IP/VPN
(RFC4364) per the section 1 & 3 of this draft (draft-asati)?

Best Regards,
Leaf

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, May 11, 2011 8:17 PM
To: Leaf yeh
Cc: [email-masked]; Bernie Volz
Subject: Re: [dhcwg] WG adoption of
draft-asati-dhc-relay-agent-config-00

> Ted - I will admit that in simply reading the draft, it does seem like
it's not actually doing anything, ...

It occurs to me that one way to address this concern would be to write a
second draft that describes a suboption that would be a payload for this
mechanism.   The two drafts, presented together, would make more sense
than this draft all on its own.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 May 2011 14:26:00 -0400

> 2.  Would the 2nd draft raise a reasonable solution for BGP/MPLS IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)?

I think the use case addressed by the draft does require some enabling extension.   My suggestion was to put an ORO in the Relay-Forw message and have the server send back options that way, rather than defining a new container.

Although having said that, I now feel the need to step back a pace.   It doesn't actually make sense to piggyback this functionality on top of a DHCP client message.

In any case, none of this is germane to the question of whether or not this is work the working group ought to do.   Part of the work of the working group is figuring out the right solution to the problem.   The question in the call for adoption is, do we think this is work that is worth doing?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 13 May 2011 13:36:14 -0500

While I was only CC'd, I'm still not sure exactly what this is -- Is
this the same as in Ralph's draft
http://tools.ietf.org/id/draft-ietf-dhc-container-opt-05.txt (perhaps so
as Ralph is co-author).

If so, hasn't this already been approved as a DHC WG work item given
that Ralph's now expired draft is a draft-ietf-dhc one? So, why would we
need to revisit that part of the question?

And, why isn't this new draft not just -06 of Ralph's old draft?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, May 13, 2011 2:26 PM
To: Leaf yeh
Cc: [email-masked]; Bernie Volz (volz)
Subject: Re: [dhcwg] WG adoption of

> 2.  Would the 2nd draft raise a reasonable solution for BGP/MPLS
IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)?

I think the use case addressed by the draft does require some enabling
extension.   My suggestion was to put an ORO in the Relay-Forw message
and have the server send back options that way, rather than defining a
new container.

Although having said that, I now feel the need to step back a pace.   It
doesn't actually make sense to piggyback this functionality on top of a
DHCP client message.

In any case, none of this is germane to the question of whether or not
this is work the working group ought to do.   Part of the work of the
working group is figuring out the right solution to the problem.   The
question in the call for adoption is, do we think this is work that is
worth doing?

---

From: Ralph Droms <[email-masked]>
Date: Fri, 13 May 2011 17:06:23 -0400

Bernie - this new draft has a different purpose altogether.  draft-ietf-dhc-container-opt-05 was intended for use between a client in a router (e.g., a home router) and a server.  The client in the router would then hand those parameters to a DHCP server in the router for use on other interfaces (e.g., the LAN interfaces on a home router).

draft-asati-dhc-relay-agent-config provides a path for passing configuration parameters from a server to a relay agent, which can't be done today in the Router Information option because that option is defined only to carry information from the relay agent to the server.

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 13 May 2011 16:13:00 -0500

Router usually == Relay Agent?? I think this option is for DHCPv4?

Is draft-ietf-dhc-container-opt-05 dead? If not, then perhaps there also
needs to be some discussion regarding when it vs this new document are
to be used?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Friday, May 13, 2011 5:06 PM
To: Bernie Volz (volz)
Cc: Ralph Droms; Ted Lemon; Leaf yeh; [email-masked]
Subject: Re: [dhcwg] WG adoption of

Bernie - this new draft has a different purpose altogether.
draft-ietf-dhc-container-opt-05 was intended for use between a client in
a router (e.g., a home router) and a server.  The client in the router
would then hand those parameters to a DHCP server in the router for use
on other interfaces (e.g., the LAN interfaces on a home router).

draft-asati-dhc-relay-agent-config provides a path for passing
configuration parameters from a server to a relay agent, which can't be
done today in the Router Information option because that option is
defined only to carry information from the relay agent to the server.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 13 May 2011 17:17:03 -0400

In the case of draft-ietf-dhc-container-opt-05 and talking about a home router, it's the client in the router on the WAN interface passing information to the server in the router on the LAN interface.  No relay agent involved.

I haven't heard any interest from ISPs (the primary customer) in draft-ietf-dhc-container-opt-05, so "it's dead, Jim".

- Ralph, who is a protocol engineer, not a doctor

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 May 2011 22:07:15 -0400

> http://tools.ietf.org/id/draft-ietf-dhc-container-opt-05.txt (perhaps so

No, it's to configure the relay agent, not to configure what the relay agent sends to the client.   Or so I understand it.

---

From: Leaf yeh <[email-masked]>
Date: Mon, 16 May 2011 11:10:40 +0000

Ted - My suggestion was to put an ORO in the Relay-Forw message and have the server send back options that way, rather than defining a new container. Although having said that, I now feel the need to step back a pace. It doesn't actually make sense to piggyback this functionality on top of a DHCP client message.

2 more question on the draft-asati:

a.  Not quite sure this draft will cover DHCPv6 per the format of the new proposed option in Section 4 and the description on behavior of Relay in Section 5;
b.  Supposed the new option proposed in this draft does piggyback on top of a DHCP client message per the description on behavior of Relay in Section 5, right?

Best Regards,
Leaf

PS. 

Section 5.1
The relay agent adds the DHCP relay agent configuration option (& needed sub-options) in the relayed message to request the relay agent side configuration information from the server...A relay agent adding a Relay Agent Configuration Information Option MUST add it as the last option (but before 'End Option' 255, if present) or the second last option, if option 82 is present, in the DHCP options field of any recognized BOOTP or DHCP packet forwarded from a client to a server...The relay agent MUST remove the relay agent configuration option from the DHCP response and forward the remaining response to the client.

Section 5.3
... The new option defined in this document is never passed to the client...

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 May 2011 18:16:02 +0200

> Ted - My suggestion was to put an ORO in the Relay-Forw message and have the server send back options that way, rather than defining a new container. Although having said that, I now feel the need…

In the particular use case in mind for the option, piggybacking on a client message does make sense because the config info depends on the client ID.

> a.  Not quite sure this draft will cover DHCPv6 per the format of the new proposed option in Section 4 and the description on behavior of Relay in Section 5;

Yes, the document needs more detail for DHCPv6 operation.

> b.  Supposed the new option proposed in this draft does piggyback on top of a DHCP client message per the description on behavior of Relay in Section 5, right?

Not sure what you're asking?

- Ralph

---

From: Leaf yeh <[email-masked]>
Date: Wed, 18 May 2011 01:49:28 +0000

Ted -  It doesn't actually make sense to piggyback this functionality on top of a DHCP client message.
Leaf -  b. Supposed the new option proposed in this draft does piggyback on top of a DHCP client message per the description on behavior of Relay in Section 5, right?
Ralph -  Not sure what you're asking?

Sorry for the confusion. I was trying to make sure whether this draft will insist adopting the method of the called 'piggyback' option, which is the same method as the ORO, though I can accept this concept in some use cases.

Best Regards, 
Leaf

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Wednesday, May 18, 2011 12:16 AM
To: Leaf yeh
Cc: Ralph Droms; Lemon Ted; [email-masked] Group; Bernie Volz (volz); Rajiv Asati
Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 May 2011 09:21:35 -0400

> a.  Not quite sure this draft will cover DHCPv6 per the format of the new proposed option in Section 4 and the description on behavior of Relay in Section 5;

Yes, getting DHCPv4 and DHCPv6 confused seems to be a theme this week... :)

> b.  Supposed the new option proposed in this draft does piggyback on top of a DHCP client message per the description on behavior of Relay in Section 5, right?

Right.   The thing is, configuring the relay agent is really not something that needs to happen at the same time as configuring the client.   Why isn't the relay agent simply sending a configuration request to the server at its own convenience, independent of any communication from the client?