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

Tomek Mrugalski tomasz at isc.org
Mon Aug 3 11:53:56 UTC 2015


On 28/07/15 13:06, Thomas Markwalder wrote:
> On 7/28/15 3:38 AM, Marcin Siodelski wrote:
>> The lease expiration, as it is described  now, marks the lease as
>> 'reclaimed' by simply removing it from the lease database.  This
>> minimizes changes to the lease database backends etc. However, I am
>> quite confident (after some discussions I had so far) that at some point
>> we will want 'address affinity'. In that case, removing the lease on
>> expiration is not a right approach.
>>
>> Since we need to add new functions and indexes to retrieve expired
>> leases, *now* seems to be the best time to add the new 'state' field if
>> we want to go down this path.
>>
>> The reason I bring it in this thread is that at this point we may also
>> consider if this field can be used for declined addresses.
>>
>> The big question is how to encode the state of the lease. I'd be in
>> favor of encoding a single state on an individual bit, in which case it
>> would be possible to encode multiple states with a single INT value,
>> i.e. the lease could be in multiple states simultaneously.
>>
>> I am seeking for an answer whether we want this or not before I further
>> work on the lease expiration design, as almost all further updates are
>> going to be based on this decision.
>>
>> Marcin
> A bitmask as you suggest, is probably the most flexible.  And I believe
> that the time to add the new field is now, assuming that is the consensus.
Ok, let's assume for a moment that we go with that decision and look
into what possible states we may want to store in it. Here's the list I
came up with:

assigned - normal lease being assinged to a client
expired - lease that has expired and was processed by lease expiration.
          We decided to keep it for the address affinity. Not likely to
          happen in 1.0, but may be implemented afterwards.
declined - lease was declined. Once it's valid-lifetime (which is set
          to the probation time) elapses, the lease will be recycled

Additionally, the following may (or may not, we don't have the protocol
design yet finished, much less software design):
free  -  the lease is free and is assignable by the primary server
free_backup - the lease is free and is assignable by the backup server
reset - the lease was administratively released.

See
https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design-04,
section 7 for possible failover states. In some cases, failover state is
independent of the basic state we're considering here (e.g. the lease is
free, but is it assignable by primary or secondary?).

Having such a field would require database schema update, but I think it
would be fair price to pay in the long term. We just need to make sure
that the state is extensible. Having 32 bit integer and going with a
bitmask would be one way to go. It's the most flexible solution.
However, its flexibility my be a problem as it also allows inconsistent
data, e.g. setting lease that is assinged, expired and declined at the
same time. The alternative would be to have an enum. This, on the other
hand, has a tendency to have a number of values that would double with
each extra state we want to keep. So it seems the bitfield is the way to go.

Ok, I think I'm now convinced that the state column would be useful. If
that's the consensus, I'll update the decline design to reflect that.

Tomek



More information about the kea-dev mailing list