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

[Shawn Routhier]

> On Jul 13, 2015, at 7:54 AM, Tomek Mrugalski <tomasz at isc.org> 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
> 
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev

Some comments about the requirements first (yes I’m late to the party and they don’t
have to be dealt with but I’ll add them in case they are useful.

In the current ISC DHCP code the declined addresses are referred to as “abandoned”
we may want to include that somewhere in the docs (requirements, design or simply
the admin or user guides) as a reference for people migrating from ISC DHCP to Kea.

The ISC DHCP server can do a ping check on a v4 address itself and abandon the lease
if it gets a reply.  It’s unclear to me if this is an option in the current design or possibly
an extension to add later.

I think adding a per-subnet statistic to count the number of addresses ever declined might
be useful as well.

**

And some comments about the design (not quite so late to the party, maybe there is still
some beer and potato chips)

1) In ISC DHCP it is possible to recover a declined (abandoned) v4 address if the client
that the server tried to give the address to (hence the one that did the decline or failed
the ping check) requests that address.  This situation may indicate that the client actually
had that address and responded to either the server’s ping or its own ping.  This probably
indicates a bit of confusion between the two.  Unfortunately I have no information about
how likely this situation is and therefore how useful it is to address it.

The current proposal would make addressing this issue difficult as there wouldn’t be
the client id or hardware address to identify the client in the lease entry to determine
that this was the same client that did the decline.

I don’t think I’m quite as strong a proponent of using another field as Thomas is but I would
point out that if we are going to make such a change it is probably better to do it for 1.0
than to need to add it in the future.

2)  A minor note the heading for the second section is “V4 design” but it covers both v4 and v6.

3) Are we expecting the lease[4 6]_decline hook to also handle undoing any other hook work
done as part of assigning an address?  That is, is the admin responsible for arranging for
any code that is common between expire, release and decline to be invoked? 

4) Manual recovery - would it be useful to have a command to recover all addresses?  (Or
will the address argument already accept a wildcard?)