[dhcwg] Failover: who expires a lease...
Ted Lemon <mellon@nominum.com> Sun, 04 November 2001 01:10 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19927 for <dhcwg-archive@odin.ietf.org>; Sat, 3 Nov 2001 20:10:09 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA11233 for dhcwg-archive@odin.ietf.org; Sat, 3 Nov 2001 20:10:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10885; Sat, 3 Nov 2001 19:56:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10860 for <dhcwg@optimus.ietf.org>; Sat, 3 Nov 2001 19:56:55 -0500 (EST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19826 for <dhcwg@ietf.org>; Sat, 3 Nov 2001 19:56:52 -0500 (EST)
Received: from green.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id fA40tQv19668 for <dhcwg@ietf.org>; Sat, 3 Nov 2001 16:55:26 -0800 (PST)
Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id fA40vYM00772 for <dhcwg@ietf.org>; Sat, 3 Nov 2001 17:57:34 -0700 (MST)
Date: Sat, 03 Nov 2001 17:57:33 -0700
Mime-Version: 1.0 (Apple Message framework v472)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
From: Ted Lemon <mellon@nominum.com>
To: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <EE0FF392-D0BE-11D5-908D-00039317663C@nominum.com>
X-Mailer: Apple Mail (2.472)
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Failover: who expires a lease...
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit
The failover protocol draft doesn't seem to specify explicitly who moves a lease from the active to the expired state. This is a problem, because if both servers have the same information about the lease, and their clocks are properly synchronized, they will both expire the lease at the same time. This will result in both servers firing BNDUPD messages at each other at roughly the same moment. I don't think this will cause an actual problem, but it will cause each expiry event to result in four messages being sent instead of two. If the servers are reasonably in sync and the clocks are out of sync, this also won't be a problem, but I don't think the protocol specification should assume that that is the case. I would propose that the spec say that the primary SHOULD expire the lease. I don't think that this will cause any heartburn since the expired state is only useful when the servers are communicating. It might cause trouble if the servers are way out of sync, but in that case the hack described in the draft could be extended somewhat - if a lease has been allocated to a client but no BNDUPD has been *sent* to the peer, the peer that allocated the lease MAY move it back into the FREE or BACKUP state when it expires. My intended workaround for this problem, given the current language, is to delay updates from the secondary for a few minutes when the update moves the lease from ACTIVE to EXPIRED. This will generally mean that the primary will update the secondary and the secondary will never have to update the primary. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Failover: who expires a lease... Ted Lemon
- RE: [dhcwg] Failover: who expires a lease... Bernie Volz (EUD)