Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains

[Wuyts Carl <[e-mail]>]

I think, as CPE vendor, there's no other possibility then to vote AGAINST this proposal.

I read:
""
Clients may select one or several administrative domains; If multiple, each is a separate state machine
""

In some other discussion some time ago, there was already some proposal on having multiple/separate state machine for dhcpv6 client.  In this proposal, I see the same thing popping up, but in another context.
For CPE devices, this is really a no-go.  Apart from splitting up state machine (and as such, multiplying memory consumption with factor X), it'll also inject extra complexity.  The CPE, the low-end, nearly free-of-charge, device again seems to be victim of these kind of proposal!!

I don't know if some other CPE vendor people are subscribed to this WG, but I'd like to read how they feel about this...

Regs
Carl




From: [e-mail] [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: maandag 20 augustus 2012 15:50
To: Ole Trøan; Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains

In the slides I presented at IETF-83 (Paris) and IETF-84 (Vancouver) about this work, the last slide had:

Multiple Administrative Domains
·         Still planning to write new Internet-Draft on multiple administrative domains
·         Basic proposal will be for Advertise to include "Administrative Domain" option which contains an "administrative domain string"
·         Clients treat Advertises with the same administrative domain string as 'equal'
·         Clients may select one or several administrative domains; If multiple, each is a separate state machine

The basic idea here is that if a client sends a Solicit with IA_NA and IA_PD, one server (or set of servers) may respond with IA_NA information and administrative domain string A and another server (or set of servers) may respond with IA_PD and administrative domain string B. This would trigger the client to initiate two separate state machines.

Of course, there is also the possibility that other server(s) may respond with both the IA_NA and IA_PD and administrative domain string C. In which case the client now has to determine whether to use one state machine (and administrative domain C) or two state machines and administrative domain A (IA_NA) & B (IA_PD).

While fairly simple in concept (and for servers [include administrative domain option] and relays [no impact]), it does greatly complicate clients.

One idea would be for clients to implement something similar to what they do for WiFi and SSIDs - a user would be required to select which administrative domains are valid. One interesting twist here is that just like with WiFI, we could also secure this -- add an encryption option which would provide a way to secure the DHCP server(s) with which you are willing to communicate.


I haven't started work on this draft as it wasn't clear how much interest there is and if there are real world requirements for something like this. If there is sufficient interest, I would be happy to start work on it.

- Bernie

-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Ole Trøan
Sent: Monday, August 20, 2012 8:45 AM
To: Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

Ted,

>> could we go forward with this draft that clarifies how multiple stateful options work in a single session, and with the general assumption that a client will choose one DHCP server and that server is authoritative?
>
> My concern is that if you do so, it will essentially result in clients standardizing on whatever behavior you specify, and so whether we write another standard or not, it will not be available in practice.

to turn the question around.
is there anyone who thinks that we should _not_ make multiple stateful options work in a single DHCP session?

cheers,
Ole