[kea-dev] Design for Kea Host Reservation

Tomek Mrugalski tomasz at isc.org
Mon Oct 6 16:29:41 UTC 2014

On 06.10.2014 15:55, Marcin Siodelski wrote:
> On 01/10/14 20:52, Tomek Mrugalski wrote:
>> On 30.09.2014 13:20, Marcin Siodelski wrote:
>>> I have created a new design document on Kea wiki:
>>> http://kea.isc.org/wiki/HostReservationDesign for Host Reservation.
>> Here are my comments. I like the design a lot. I think it will address
>> our needs. We will probably tweak it a little bit over time, but it a
>> very solid proposal. Here are my comments:
>> Information stored for HR section
>> IP address(es) - should mention that list is for IPv6 only, v4 need a
>> single address only. There's no need to reserve more than one IPv4
>> address. Also, please explicitly say that IP means IPv4 and IPv6.
>> Temporary addresses. We do not support temporary addresses at all and
>> in a sane environment, there is no requirement to reserve them in any
>> way. On the contrary, it should be an explicit non-requirement. We
>> should probably state that somewhere in the design (and hope that odd
>> users wanting their temporaries to be static will never appear :)
>> We should add that currently there is no way to define what options
>> can be sent for a given class. This capability will be added in the
>> future.
>> I'd love to see DUID reservation example for DHCPv4.
>> I like the paragraph explaining what the prefixes (dhcp_, dhcp4_ etc.)
>> mean. This is sort of intuitive, but it's nice to have it explicitly
>> stated.
>> Shouldn't host_id and reservation_id be of type primary key? The diagram
>> in MySQL database schema suggests it is a simple int. I'm not a
>> MySQL expert, so this is an honest question. I think that setting a
>> field to primary key type introduces three things: first, it is being
>> assigned automatically during inserts. Second, the next value is being
>> stored and applied automatically (autoincrement). Third, a unique
>> restriction is added.
> Yes, they are supposed to be primary key. I don't know why the SQL has
> been generated without them being primary keys.
Host_id, option_id (in 2 tables) and reservation_id fields still may
contains non-unique values. NOT NULL and AUTO_INCREMENT are fine, just
something about values being unique is missing.

>> I'm a total MySQL noob, so forgive my ignorance, but why do we need
>> ALLOW_INVALID_DATES? MySQL does not simply insert invalid dates, and
>> sort of sanitizes it to zeros. MySQL doc
>> (http://dev.mysql.com/doc/refman/5.5/en/sql-mode.html, also applies to
>> older versions) says that invalid date of 2014-04-31 will be sanitized
>> to 0000-00-00.
> I don't have strong opinion here. In fact, the database schema doesn't
> use any time values at the moment. So, having this one way or another
Huh? What about expire in lease4 and lease6? If a user decides to keep
both hosts and leases (a common assumption, I suppose), then it will
affect the leases data.

> doesn't hurt. The reason why it is set to this value is that the MySQL
> workbench tends to inject this into the generated SQL. How about we
> revisit this if we introduce some time/date columns to the database?
No, let's not add something we don't need. It's cleaner approach.


More information about the kea-dev mailing list