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