wiki:DhcpWeeklyMinutes20120625

BIND 10 DHCP Conference Call

25 June 2012, ~11:30 PDT/19:30 BST/20:30 CEST

Attendees

Marcin
Shane
Shawn
Stephen
Tomasz

Summary of Actions

  • Tomasz - produce proposals concerning fixed leases

Pool/Lease Store

Shane led the discussion about the Pool/Lease Store Design (version 24).

This defines a number of basic data structures. It was agreed that the following should be added:

  • Relationships between the data structures
  • State transition diagram for leases

Leases

In DHCPv4 we have the idea of a "free but previously allocated" lease. We could get rid of it - it depends if we want to allocate the same address to the same client if possible. If discussion of the lease lifecycle is too long, it could go into a separate document.

This led to a discussion about where leases are stored. At present (DHCPv4) it is all in memory. There will be a performance hit if leases are written to disk and have to be accessed again. It was agreed that Tomasz should implement the database tests to see the effect of database performance.

In the long term it was likely that we would need to store some information in memory. This could possibly be handled using database caches.

Also discussed was how options (e.g. relay options) should be stored with the lease. It was agreed that for the current stage of the design, it would be stored as a blob.

DDNS

This is not on the plan for the next six months, but does impact the current design.

The current design stores FQDN option information. This may not be best - what is stored if a domain name needs to be synthesised? After some discussion it was agreed that DDNS information is the responsibility of the DDNS module. At most, the DHCP part of the code would just hold some handle to the information passed to DDNS.

Also discussed was whether the DDNS subsystem could have multiple servers (e.g. different servers for the forward and reverse zones, or a primary and fallback server). There seemed to be no reason why this could not be the case. However, it was agreed that the DHCP code did not need to worry about this - it would just pass the name/address pair and an indication as to whether the information is put in the forward/reverse/both zone: the DDNS server would take care of tracking which servers are used.

Similarly, the DDNS server would handle details about TSIG keys and the like.

The DDNS component will be the subject of another design document.

recycle time

This is a delay between the time a lease expires and the time it can be reused. (This was a requirement for a customer with whom ISC discussed a project back at the end of 2011.)

Presently we don't have this for V4 leases. For V6 leases we did have that but is was not found to be useful.

It was agreed that the field should be left in the design, but a note made that it will not be implemented initially.

Q9: Reserved leases

Currently, in V4 they are not in the pool - in V6 they are.

In the current code, fixed leases are not written to the lease file (but do exist in memory). This gives a small performance improvement.

A couple of customers use fixed leases, rewriting the configuration file and restarting the server as required.

A fixed lease has infinite lifetime. In V4 there is also a reserved lease that does something like it. Part of the use of these leases is in supporting the BOOTP protocol (although we are not supporting it in Kea).

The main argument for allowing fixed leases in pools is to simplify configuration: customers define pools then define what addresses are fixed. (In the current software, to do that they have to split the pools so that the fixed leases are not in a pool.) On the other hand, treating fixed leases as a normal lease may have a performance impact.

Tomasz said that he would put forward two proposals.

Action Tomasz - produce proposals concerning fixed leases

Q3: subnets

It was agreed not to have shared subnets for now.

Q6: Ranges

It was agreed that we did want ranges for parameters. We should also have default values. So the configuration should allow for each numeric parameter, a minimum acceptable value, a maximum acceptable value, and a default value to be used when no information is provided.

It was also agreed that a parameter hierarchy needed to be agreed. The configuration would be checked when it was changed, and the configuration change code should work through the entire hierarchy checking that the information is consistent.

Q10: Data consistency

We need to allow users flexibility, including the ability to shoot themselves in the foot if necessary. E.g. if a server were to catch fire, we should allow the user to forcibly expire the lease associated with it.

Q11: Pool selection algorithm

We need to allow users to override the pool selection algorithm through the use of call-outs.

Interface to Abstract Data Store

An interface with this abstract data store needs to be written, although this can be in the form of a class header file.

Last modified 5 years ago Last modified on Jun 26, 2012, 3:12:54 PM