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

Ted Lemon <mellon@fugue.com> Thu, 15 July 2004 10:59 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10702; Thu, 15 Jul 2004 06:59:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl3tR-0000GN-Dh; Thu, 15 Jul 2004 06:55:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkqyS-0001vx-3J for dhcwg@megatron.ietf.org; Wed, 14 Jul 2004 17:07:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21186 for <dhcwg@ietf.org>; Wed, 14 Jul 2004 17:07:29 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkqyQ-0003mZ-Q3 for dhcwg@ietf.org; Wed, 14 Jul 2004 17:07:30 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkqoM-0001Xb-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 16:57:07 -0400
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BkqeM-00076F-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 16:46:46 -0400
Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 3614A1B2DD0; Wed, 14 Jul 2004 15:38:49 -0500 (CDT)
In-Reply-To: <BFELJLKGHEJOPOPGJBKKOEHLCJAA.steve@relicore.com>
References: <BFELJLKGHEJOPOPGJBKKOEHLCJAA.steve@relicore.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E6FD8876-D5D6-11D8-86FA-000A95D9C74C@fugue.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@fugue.com>
Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05
Date: Wed, 14 Jul 2004 13:46:38 -0700
To: "Steve Gonczi" <steve@relicore.com>
X-Mailer: Apple Mail (2.618)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 15 Jul 2004 06:55:11 -0400
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit

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