[kea-dev] Design for Kea Host Reservation

Marcin Siodelski marcin at isc.org
Mon Oct 6 13:46:20 UTC 2014

On 03/10/14 12:47, Thomas Markwalder wrote:
> On 9/30/14, 7:20 AM, Marcin Siodelski wrote:
> > All,
> >
> > I have created a new design document on Kea wiki:
> > http://kea.isc.org/wiki/HostReservationDesign for Host Reservation. It
> > summarizes the discussions that we conducted on a mailing list and
> > during the Kea hackathon.
> >
> > The document introduces detailed layout of the database for host
> > reservations. It also presents relations between the old and new C++
> > classes and some other details.
> >
> > At present, the document doesn't cover the design of a management tool
> > for updating and adding new host reservations to the database. I think
> > this tool is out of scope for now.
> >
> > The Trac ticket for creating a HR design is #3559. This ticket is now in
> > the review queue and the regular review should be conducted by one of
> > ISC engineers. I also encourage mail list subscribers to have a look and
> > comment.
> >
> > Marcin
> > _______________________________________________
> > kea-dev mailing list
> > kea-dev at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/kea-dev
> Marcin:
> I'm sending this out to the email list to share our jabber-chat
> yesterday.   I applaud your effort, as a stand-alone component your
> document is coherent and the design is complete enough to implement.
> Your design describes host reservation "persistence" but not how this
> will be put to use within Kea.   Without reviewing it within the larger
> context of a how it will integrate into Kea, reaching a full opinion on
> its viability is impossible.
> I believe what is needed is a high level design as a prerequisite to
> your design so one can see how host reservation use cases will flow
> through Kea.    It should cover configuration use cases as well as DHCP
> client use cases.     
> It is my impression that there was a lot of discussion and perhaps
> emails regarding the overall design, and if so codifying should not be
> too grate an effort, however  email chains do-not-a-design make ;)
> Without an overall design document I think there is too great a risk for
> stumbling into unaccounted for situations or needs.


You have a valid point. The Host Reservation indeed introduces some more
complexity to the message processing logic, as well as to the allocation
engine and this additional complexity deserves documentation. Thanks for
pointing this out.

I updated the http://kea.isc.org/wiki/HostReservationDesign document by
adding a new section "Integration of HR into DHCP Messsage Processing"
to address this. It comes with simplified flow diagrams which present
how the server will process DHCPv6 Renew/Rebind, DHCPv6 Request and
DHCPREQUEST messages with the Host Reservations in use.

Note that while diagrams sometimes dive into the details of message
processing (especially a Renew/Rebind case which seems to be more
complex), they are not meant to cover message processing end-to-end
because we do not try to design the server from the scratch. Having said
that, we may need to go over the current logic to check if we are always
doing correct things according to RFCs.

On the diagrams I tried to highlight the new elements in the message
processing. These new elements will obviously have "some" impact on the
server's performance but I think this impact may be minimized. One
notable factor is a use of SQL database, which will result in additional
queries to obtain host reservations. There are many ways to mitigate
this problem:

- SQL database tuning
- caching query results (e.g. client sends DISCOVER, get client's
reservation and keep in memory until DHCPREQUEST(s) so as additional
queries are not needed)
- dump the database to the in-memory container and don't do any
subsequent queries, expect for new reservations
- do not use database at all (and simply hold reservations in the
configuration file)

There is a great chance that if we wanted to document the ways to
mitigate the host reservation impact on the performance we would end up
having 50 page long document and many of us would still be unhappy about
some of the solutions, or lack of thereof. So, I got away from trying to
address the caching problem in the HR design doc as I want to first get
it running functionally. At the same time, I am confident that the
design, as it is now, doesn't preclude any future optimizations in this

For the Host Reservation, there is an assumption that the server will
always try to use reserved resources for a host, if any. But, if the
reserved resource is unavailable for some reason (e.g. is in use) the
server should still be able to provision the client by allocating some
other resource. We may obviously speculate whether it is always
appropriate for the server to allocate a different address than the one
that the administrator wanted a client to get and whether the client
should rather not be provisioned in such case. But, I think it is not a
problem to make this configurable at the later time once the whole logic
is in place. So, this discussion is out of scope in the doc.


More information about the kea-dev mailing list