Re: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05

On Jul 14, 2004, at 12:14 PM, Steve Gonczi wrote:
> What complexity are you talking about?
> How is this different from plain DHCP?

The complexity is that now you have to specify how the DHCPREQUEST is 
done.   This is a substantial change to the draft.   And what you get 
for it is something about as reliable as a DHCPRELEASE - a best effort 
notification.

Finally, you say that this isn't any different than how DHCP works 
normally - you claim that most DHCP servers listen for the DHCPREQUEST 
and, when it is for a different server identifier, do something with 
that.   However, this doesn't match my experience - it's expensive to 
do anything with the DHCPREQUEST, and I am not aware of any servers 
that do it.   Perhaps the Cisco server does - I don't know.   There's 
no real benefit to it, because the DHCPOFFER doesn't represent a 
promise, so you can reclaim an offered lease at any time until you send 
a DHCPACK in response to the DHCPREQUEST.

So in order to gain any benefit from this, the average server is 
probably going to require a whole additional code path in addition to 
the rapid commit code path.   Whereas, if you just have the server give 
out a short lease on initial lease assignment for rapid commit 
DHCPDISCOVERs, then the lease expires quickly and is available for 
reallocation if the client doesn't renew.   This accomplishes the same 
thing you're trying to accomplish, but is much cheaper to implement and 
is completely reliable.   It's also more flexible, because a site that 
follows the single-server model doesn't have to do it, so only sites 
that want rapid commit with multiple servers have to pay a penalty for 
the additional functionality.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg