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

From: "Steve Gonczi" <[email-masked]>
Date: Wed, 14 Jul 2004 15:14:52 -0400

What complexity are you talking about?
How is this different from plain DHCP?

Any server that could see the initial rapid commit
DHCPDISCOVER will also be able to
see the DHCPREQUEST.

/sG

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, July 14, 2004 12:20 AM
To: Steve Gonczi
Subject: Re: [dhcwg] dhc WG last call on
draft-ietf-dhc-rapid-commit-opt-05

On Jul 13, 2004, at 4:34 PM, Steve Gonczi wrote:
> For the cost of sending out one extra message by the Rapid Commit
> client (which BTW does not cause any significant delay)
> you could eliminate the entire 3.2 section from your protocol.

What Bernie was talking about was just making the initial DHCPACK have
a very short lease time.  Subsequent DHCPACKs could have a longer lease
time.  This accomplishes the same purpose that you're talking about,
without the added complexity of requiring all servers to see the
DHCPREQUEST you're proposing to add to the exchange.

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Jul 2004 13:46:38 -0700

> 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.

---

From: Dave Miner <[email-masked]>
Date: Thu, 15 Jul 2004 13:18:26 -0400

Ted Lemon wrote:
...
> 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.

As a point of information, the Solaris DHCP server does exactly this, 
and has for as long as we've been shipping it.

Dave

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Jul 2004 10:56:50 -0700

> and has for as long as we've been shipping it.

Oh, right, that makes sense.   Cool!

It doesn't change my opinion about rapid commit, though - handling the 
DHCPREQUEST unquestionably adds work.