Subject: [dhcwg] Lease database storage in DHCPv6

From: Artur Guja <[email-masked]>
Date: Sun, 28 Oct 2001 19:05:10 +0100

Hello,

Here is a fragment of my diploma documentation.
Thell me what you think about such a scenario.

"After each change in the lease cache in memory
(allocation, update, release), the lease information
has to be saved on non-volatile storage to ensure
its maximum accuracy in case of a server crash.
To minimize storage use (especially for flash-based
storage and similar), the whole database is updated
only once every several changes (the specific number
is a configuration parameter, 0 meaning update every
time). The intermittent information is kept in a
separate file/storage, treated as a transaction cache.
On update, the whole lease database is first saved to
a separate file, and then the main database file is
unlinked and replaced by the new file. This minimizes
risk of a reboot occurring while the main file is not
up-to-date.
In case there is a serious limitation set on the use
of a non-volatile storage, the saving of the lease
database can be omitted. In such a case, no network
information is available after a server crash. The
server starts a general reconfiguration of the network
right after resuming operation, in order to establish
a known network state. Each client is sent a
reconfiguration request. This causes much network
traffic, but ensures proper operation and a fully
known address pool state."

-- 
Best regards,
 Artur                          mailto:[email-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Tue, 30 Oct 2001 07:22:06 -0500

The scenario you describe in the first paragraph is,
I believe, a reasonably well-known optimization.  One
detail to note is that the server should, on reboot,
consult the transaction cache and complete those
outstanding transactions before processing
any new requests.

In the scenario you describe in the second paragraph,
if a server has no non-volatile storage in which to
record its clients, how does the server know what
clients to contact?

In a followup message, you noted:

>As to other limitations, I'm a bit concerned about the peak network
>load right after the server restart, due to all clients reconfiguring.
>Maybe there should be a random wait defined, just as for SOLICIT, to
>desynchronise the clients.

In DHCPv6, any delay between reconfigure messages
is the responsibility of the server and is not
explicitly described in the protocol specification.
The delay is left unspecified because servers are under
explicitly administrative control and may have widely
varying requirements for load-leveling depending on the
particular network in which those servers are deployed.

- Ralph