Subject: [dhcwg] Requesting suboptions in DHCPv6

From: Tomasz Mrugalski <[email-masked]>
Date: Sun, 23 Oct 2011 12:54:35 +0200

Dear group,
Draft mrugalski-dhc-dhcpv6-suboptions-01 [1] was presented in Quebec
meeting. It clarifies how should clients requests suboptions. There is
no text in RFC3315 that explains that. During last meeting we had a
brief discussion regarding the way suboptions are requested. There are
two reasonable approaches possible:

APPROACH 1. use a single ORO instance, put it in message directly as it
is done today. This is simple to implement and does not require
modification of existing drafts. Server will need to be smart enough to
know which requested options are top-level options, which are
sub-options and where to put them. You can't differentiate between
different instances of the same option.

APPROACH 2. use top-level ORO as it is done today, but also use ORO
instance in each scope you want to request suboptions. Require a bit
more logic, but is more flexible. Client can specify that it wants
specific suboption in only one instance of an option. Bernie provided
[5] an excellent example for this approach while discussing PD_EXCLUDE
option:

"Another reason for placing this into an IA_PD ORO option is what if
there are multiple IA_PDs and the requesting router is only interested
in supporting this in some cases. Consider the case where the requesting
router has already obtained an IA_PD (w/PD_EXCLUDE) and now needs
another because there are more prefixes needed. In this case, this
request would NOT want to include the PD_EXCLUDE for these additional
IA_PD(s) because they would NOT be used on the WAN interface? So, I
think having this be at the IA_PD level is the correct way to go."

Currently the draft describes approach 2, but please do not consider
this as a suggestion that this approach is "preferred" in any way. If we
decide that approach 1 is the way to go, I'll update the draft as
needed. Chairs suggested that a consensus should be reached about this,
before it could be adopted. It would be great if we could reach
consensus on this before Taipei (Nov. 13).

Personally, I don't have any strong opinion about this. Both approaches
are ok for me. I don't want to push one way or the other, I just want to
have clear recommendation, how to request suboptions.

I just uploaded updated version [2]. There are no significant changes,
just minor update to avoid expiration.

Your comments are more than welcome. Brief statement about supporting
approach 1 or 2 is fine, too.

Here's my attempt to summarize the discussion so far. I'm sorry if I
missed any comments. Please correct me if I did. This had some
discussion, but it was somewhat scattered around different places. Soe
far, following people states their opinions:
Aproach 1 (single ORO):
- Jouni Korhonen [6] (also stated during meeting. Prefers 1, but is
willing to accept 2 if it does not require modifications of existing drafts)
- Ted Lemon (discussion during Quebec, prefers 1 as it requires smaller
modifications in existing implementations (i.e. easier to deploy).

Aproach 2 (ORO put in proper scope):
Bernie Volz [3,5] (See Bernie's comment above about requesting
PD_EXCLUDE in only first IA_PD)
Ole Troan [4]

1. draft-mrugalski-dhc-dhcpv6-suboptions-01.txt
2. draft-mrugalski-dhc-dhcpv6-suboptions-02.txt
3. http://www.ietf.org/mail-archive/web/dhcwg/current/msg11846.html
4. http://www.ietf.org/mail-archive/web/dhcwg/current/msg11663.html
5. http://www.ietf.org/mail-archive/web/dhcwg/current/msg11846.html
6. http://www.ietf.org/mail-archive/web/dhcwg/current/msg11827.html

Thanks,
Tomek

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Oct 2011 19:21:35 +0000

My reason for preferring option 1 is actually that in general I expect that the server *knows* in which context a suboption should appear.   So if you put an ORO requesting a suboption into a particular context, you will only actually get that suboption if the server *knows* that it should go there.   We don't have any spec for how the server *knows* that suboptions should go here or there.   So if we go with option 2, we wind up with a standard that I don't think can be implemented in a way that will interoperate dependably.

By going with option 1, we leave the decision up to the server, as is the status quo, and in general we can expect the right thing to happen.   If we were to go with option 2, I agree with you that drafts would need to be updated, but I think you are underestimating the amount of work that would be required.   Given the rate at which people respond to the business of this working group on the mailing list, I think it's implausible that such an effort could occur.

---

From: Andre Kostur <[email-masked]>
Date: Mon, 24 Oct 2011 08:20:11 -0700

Not sure if this is a good example or not, but the PacketCable/CableLabs
guys already do stuff like option 2.  They have an ORO that's encoded into
their vendor-specific data which names other sub-options of the
vendor-specific data.  See CL-SP-CANN-DHCP-Reg-I07-110623 (
http://www.cablelabs.com/specifications/CL-SP-CANN-DHCP-Reg-I07-110623.pdf)
section 5.2.1.

On Sun, Oct 23, 2011 at 12:21, Ted Lemon <[email-masked]> wrote:

> My reason for preferring option 1 is actually that in general I expect that
> the server *knows* in which context a suboption should appear.   So if you
> put an ORO requesting a suboption into a particular context, you will only
> actually get that suboption if the server *knows* that it should go there.
> We don't have any spec for how the server *knows* that suboptions should go
> here or there.   So if we go with option 2, we wind up with a standard that
> I don't think can be implemented in a way that will interoperate dependably.
>
> By going with option 1, we leave the decision up to the server, as is the
> status quo, and in general we can expect the right thing to happen.   If we
> were to go with option 2, I agree with you that drafts would need to be
> updated, but I think you are underestimating the amount of work that would
> be required.   Given the rate at which people respond to the business of
> this working group on the mailing list, I think it's implausible that such
> an effort could occur.
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

-- 
 *Andre Kostur*
Senior Product Design Engineer
*P:* 604-678-2864
*E:* [email-masked]
*Toll-Free:* 1-800-877-1856

*F:* 604-678-2864
*VoIP:* sip:[email-masked]

 <http://www.incognito.com>

 <http://www.incognito.com/company/events>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Oct 2011 17:36:03 +0000

On Oct 24, 2011, at 11:20 AM, "Andre Kostur" <[email-masked]<mailto:[email-masked]>> wrote:

Not sure if this is a good example or not, but the PacketCable/CableLabs guys already do stuff like option 2.  They have an ORO that's encoded into their vendor-specific data which names other sub-options of the vendor-specific data.  See CL-SP-CANN-DHCP-Reg-I07-110623 (http://www.cablelabs.com/specifications/CL-SP-CANN-DHCP-Reg-I07-110623.pdf) section 5.2.1.

That's quite bit different because it's a vendor specific sub option list.