Re: [dhcwg] Failover: transition out of potential-conflict.

Ted Lemon <mellon@fugue.com> Mon, 05 November 2001 19:03 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 OAA03164 for <dhcwg-archive@odin.ietf.org>; Mon, 5 Nov 2001 14:03:29 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21956 for dhcwg-archive@odin.ietf.org; Mon, 5 Nov 2001 14:03:31 -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 NAA21386; Mon, 5 Nov 2001 13:58:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21355 for <dhcwg@optimus.ietf.org>; Mon, 5 Nov 2001 13:58:02 -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 NAA02827 for <dhcwg@ietf.org>; Mon, 5 Nov 2001 13:57:59 -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 fA5IuRv23408; Mon, 5 Nov 2001 10:56:27 -0800 (PST)
Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id fA5IwfM01426; Mon, 5 Nov 2001 11:58:41 -0700 (MST)
Date: Mon, 05 Nov 2001 11:58:40 -0700
Subject: Re: [dhcwg] Failover: transition out of potential-conflict.
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v472)
Cc: dhcwg@ietf.org
To: Kim Kinnear <kkinnear@cisco.com>
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <4.3.2.7.2.20011105104206.023008c8@funnel.cisco.com>
Message-Id: <20917F43-D21F-11D5-908D-00039317663C@fugue.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.472)
Content-Transfer-Encoding: 7bit
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

>
>         But, I think the primary would not actually assign the IP
>         address to anyone after it goes into NORMAL state.  Part
>         of the work of the primary processing the secondary's
>         lease database is for the primary to resolve conflicts in
>         real time while receiving the BNDUPD's.  The secondary
>         cannot send the UPDDONE until the primary has processed
>         all of the BNDUPD's in some way.

I misspoke slightly there - I said "NORMAL" when I meant "CONFLICT-DONE."   
The primary will think that the address is in the free state until it gets 
the update from the secondary telling it that the secondary assigned it to 
a client.   So there's a window, potentially fairly long at a large 
installation, in which the primary can allocate that address, thinking it 
is free.   If it does so, the problem will be discovered during the 
resolution process, but it'll be too late at that point - two clients will 
have been assigned the same IP address.


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