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 SAA18278 for ; Sun, 4 Nov 2001 18:57:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA11083 for dhcwg-archive@odin.ietf.org; Sun, 4 Nov 2001 18:57:54 -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 SAA11035; Sun, 4 Nov 2001 18:52:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11010 for ; Sun, 4 Nov 2001 18:52:38 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18066 for ; Sun, 4 Nov 2001 18:52:35 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fA4NqdT28763 for ; Sun, 4 Nov 2001 17:52:39 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id fA4Nqcv23426 for ; Sun, 4 Nov 2001 17:52:38 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Nov 04 17:52:38 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 4 Nov 2001 17:52:38 -0600 Message-ID: <66F66129A77AD411B76200508B65AC697B3855@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" , dhcwg@ietf.org Subject: RE: [dhcwg] Failover: who expires a lease... Date: Sun, 4 Nov 2001 17:52:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1658B.C81E1A00" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1658B.C81E1A00 Content-Type: text/plain; charset="iso-8859-1" Sounds OK to me ... while in NORMAL state, the primary would expire all leases. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Saturday, November 03, 2001 7:58 PM To: dhcwg@ietf.org Subject: [dhcwg] Failover: who expires a lease... 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 ------_=_NextPart_001_01C1658B.C81E1A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Failover: who expires a lease...

Sounds OK to me ... while in NORMAL state, the = primary would expire all leases.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Saturday, November 03, 2001 7:58 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Failover: who expires a = lease...


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=

------_=_NextPart_001_01C1658B.C81E1A00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg