[dhcwg] Failover: poolreq message secondary-only?

Ted Lemon <mellon@nominum.com> Fri, 02 November 2001 00:55 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 TAA04331 for <dhcwg-archive@odin.ietf.org>; Thu, 1 Nov 2001 19:55:59 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA24071 for dhcwg-archive@odin.ietf.org; Thu, 1 Nov 2001 19:56:04 -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 TAA23990; Thu, 1 Nov 2001 19:48:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23966 for <dhcwg@optimus.ietf.org>; Thu, 1 Nov 2001 19:48:37 -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 TAA04121 for <dhcwg@ietf.org>; Thu, 1 Nov 2001 19:48:31 -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 fA20lCv14826 for <dhcwg@ietf.org>; Thu, 1 Nov 2001 16:47:12 -0800 (PST)
Received: from 205-140-116-229.ip.theriver.com (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id fA20nCl01293 for <dhcwg@ietf.org>; Thu, 1 Nov 2001 17:49:12 -0700 (MST)
Date: Thu, 01 Nov 2001 17:49:11 -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: <6E62BB0C-CF2B-11D5-A13B-00039317663C@nominum.com>
X-Mailer: Apple Mail (2.472)
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Failover: poolreq message secondary-only?
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 says that only the secondary can send a poolreq 
message, and indicates that the primary should attempt to reclaim backup 
leases from the secondary by updating from backup to free.   This seems 
strange to me.   Wouldn't it make more sense that whichever peer notices 
that it is short on leases would send a poolreq to the other peer, and the 
other would, if possible, send some leases out of its free pool?   The 
advantage of doing it this way is that we don't have to worry about 
conflict resolution - the secondary knows which leases it's assigned, so it 
can just send what it wants to send to the primary.

I guess either way works - it just seems cleaner to make poolreq/poolresp 
work symmetrically.


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