Subject: Re: [dhcwg] Multiple Provisioning Domains (future work mentioned in draft-ietf-dhc-dhcpv6-stateful-issues)

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jan 2013 19:55:35 +0000

Ted was the only one that responded with an interest in this.

Is there anyone else interested in this (perhaps you figured Ted's response was good enough)?

So, Ted, would be good for us to chat at some time to make sure we are on the same page. I assume:
- Multiple provisioning domains can apply at any time (they are not just restricted to the case where one server returns IA_NA and no IA_PD or vice versa).
- A client that is not multiple provisioning domain aware will behave as before (it will pick 'one' of the Advertisements). Is there any advantage for the servers to know whether a client supports multiple provisioning domains? (I assume not. Though on the other hand, it would just be to include the provisioning domain name option in the ORO so perhaps it is good to require this.)
- A client that is multiple provisioning domain aware would potentially fork Requests for each of the provisioning domains that it has been configured to support. What should it do if there are no supported provisioning domains (continue to Solicit -- though adhering to SOLMAX to avoid sending Solicits too frequently). And, what if there is an Advertisement without a provisioning domain identified; how is that treated - process only if no Requests issued for provisioning domains

Basically there are the following situations:

1. Only advertise messages without provisioning domains.
2. Only advertise messages with provisioning domains. There may be provisioning domains that should be used and ones that should not be used.
3. A mix of advertise messages with and without provisioning domains.

The likely basic client processing is:

1. If advertise specifies a known provisioning domain, save it (in a list for that provisioning domain). If server preferences is 255, start Request immediately (and basically ignore any other advertisements for that provisioning domain but continue waiting for other Advertisements).
2. If advertise specifies a unknown provisioning domain, ignore it. There might be some value in creating a list of unknown provisioning domain names so that a user could select to use a provisioning domain in the future without having to know the name.
3. If advertise specifies no provisioning domain, save it (in the no-provisioning domain list). If server preferences is 255 ... if no allowed provisioning domains configured, process immediately and ignore other advertisements. Otherwise, probably want to place this at the top of the no-provisioning domain list but continue waiting until timeout for other advertisements for known provisioning domains.

When timeout is reached, process any Advertisements received for known provisioning domains. If none (or perhaps always?), also process the 'no provisioning domain' list.

There's also Rapid-Commit to consider. I think that would basically be similar except of course there is no need to send a Request (just process the Reply).

Or, did you have a different model in mind?

May be best to discuss via phone and post some notes (or just the I-D) when done?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Tuesday, December 11, 2012 9:35 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] Multiple Provisioning Domains (future work mentioned in draft-ietf-dhc-dhcpv6-stateful-issues)

On Dec 11, 2012, at 5:39 PM, Bernie Volz (volz) <[email-masked]> wrote:
> If there is someone that believes they have a need for this or feels strongly that a draft to address this exist, please let me (or the WG) know so that perhaps we can partner on this draft and make use of those real world requirements.

Yes, _please_!   I've been feeling guilty about not writing this for at least a year now.

---

From: Andre Kostur <[email-masked]>
Date: Mon, 14 Jan 2013 12:48:52 -0800

Should some of those decisions be left to a client-side policy
decision as to whether it will prefer a particular provisioning domain
vs. require a particular provisioning domain?

On the server-side, I think the server would only need to know that it
is responding with a provisioning domain, perhaps keyed off of whether
the client did an ORO for a provisioning domain, plus preference.

On Mon, Jan 14, 2013 at 11:55 AM, Bernie Volz (volz) <[email-masked]> wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Andre Kostur
Distinguished Software Architect & Engineer
P: 604-678-2864
E: [email-masked]
Toll-Free: 1-800-877-1856

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