Re: [dhcwg] Lease database storage in DHCPv6

[Ralph Droms <[e-mail]>]

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


At 07:05 PM 10/28/2001 +0100, Artur Guja wrote:
>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:[e-mail]
>
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>http://www1.ietf.org/mailman/listinfo/dhcwg


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