[kea-dev] Call for comments about the Decline design

[Marcin Siodelski]

On 13.07.2015 16:54, Tomek Mrugalski wrote:
> Hi everyone,
> As part of the Kea 1.0 preparation, I wrote a short document about our
> intended design for Decline support. It is described here:
> 
> http://kea.isc.org/wiki/DeclineDesign
> 
> The major idea is to use special hardware address or duid values to
> indicate a declined address and keep it in the regular lease database.
> With this approach, the amount of work is greatly reduced, there is
> almost no performance degradation and this approach is proven
> (implemented years ago in Dibbler) to work well.
> 
> I'd like to hear your opinions on this proposal. We plan to conclude the
> design discussions around end of July.
> 
> Tomek
> 

I had a quick look into the document. I will go review it more
extensively, but for now I want to mostly focus on one general issue.

I would like to discuss the issue of using the special HW address or
DUID to mark the lease as declined. I think that there are some flaws
which should at least be documented. When the address gets declined for
the certain client and the lease is updated to modify the HW address or
DUID, you effectively loose the information who has declined this
address. Sure, you can take it out from the logs, assuming that your
logging level is set to the threshold when it logs such a message. But,
you can't associate a declined lease with the client who actually
declined it by looking into the lease database.

Another thing is that that it may be faster for the SQL databases to
lookup leases in the database using a numeric value, rather than DUID.
So, if you want to query for all declined leases, you could collect all
expired leases by a "declined" flag rather than by the varbinary value.

I accept the argument that there will not be many declined leases,
comparing to undeclined ones, so it may be premature to optimize
queries, but one never knows if such optimizations will not be needed in
the future. Then querying for declined leases by DUID may present some
performance degradation.

At this point however, I am mostly concerned about the representation of
the declined leases in the database, which would make troubleshooting
harder than if you had an additional field which value of 1 would
indicate declined, and 0 undeclined, and didn't modify the client
identifier.

I think some discussion in this respect would be useful in the document.
If nothing else, the implementation should hide its details and it
should be trivial and localized change to migrate out from the concept
of using the DUID for marking declined leases to additional flag.
Though, if someone has already implemented the wrapper around database
to use the DUID-based queries, the migration may cause him heart attack.

Marcin