Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Call for comments about the Decline design (Shawn Routhier)
----------------------------------------------------------------------
Message: 1
Date: Tue, 21 Jul 2015 00:08:06 -0700
From: Shawn Routhier <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Call for comments about the Decline design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
> On Jul 13, 2015, at 7:54 AM, Tomek Mrugalski <[email protected]> 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
> [email protected]
> 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?)
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 16, Issue 9
**************************************
