[kea-dev] Call for comments about Lease Expiration requirements in Kea

Marcin Siodelski marcin at isc.org
Thu Jun 25 10:40:58 UTC 2015



On 24.06.2015 16:24, Thomas Markwalder wrote:
> On 6/24/15 8:27 AM, Marcin Siodelski wrote:
>> All,
>>
>> As a part of the preparation for the Kea 1.0, I would like to ask the
>> list participants to review and comment on a document presenting the
>> requirements for the "Lease Expiration", which is available here:
>>
>> http://kea.isc.org/wiki/LeaseExpirationRequirements
>>
>> Note that this is an early version of the document. The goal of the
>> early call for the review is to collect, discuss and incorporate all
>> additional requirements before the design phase starts for real. This is
>> to avoid unnecessary delays in designing the feature and making "last
>> minute" changes affecting our productivity and then implementation process.
>>
>> Just for the record... we're planning to close the requirements and the
>> design phase for "Lease Expiration" by the end of July, when we're
>> planning to start the implementation work.
>>
>> Thanks,
>>
>> Marcin Siodelski
>> DHCP Software Engineer, ISC
>>
>> _______________________________________________
>> kea-dev mailing list
>> kea-dev at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-dev
> 
> I would suggest defining the term "lease reclamation" as "the process of
> restoring an expired lease to a state where it is free to be assigned to
> a client" and adding that to the Introduction.  Many documents have a brief
> terms/definitions section to ease discussion. 
> 

I added a terminology section.

> --------
> 
> G2 - The phrase "for which DNS record exists" implies that the system
> knows this.
> I think it might be better to say "if DNS updates are enabled".   If we
> want to then
> optimize the implementation to look at the expired lease FQDN info and
> decide
> what to do, it becomes a design decision.
> 

Ok, updated as suggested.

> --------
> 
> G3 -  Is a little confusing.  Can a lease an expired lease be left in the
> database when expiration is configured?  Secondly, the requirement should
> be that the lease is again available to be assigned.  That it be removed
> from the database is really an implementation detail.
> 

I think we can, at some point, decide that the expired and reclaimed
lease may remain in the database. For example, if the client gets back
to get the new lease, the allocation engine may first check if there is
a lease in the database which the client already used. If the lease gets
removed, there is no way to do it.

> You could restate G1-3 something like this:
> 
> G1. When an expired lease is reclaimed the system shall: 
> G1.1 MUST Execute any registered lease-expiration hooks
> G1.2 MUST notify DNS of the expiration if DNS updates are enabled
> G1.3 MUST render the lease free for assignment
> 

Updated as suggested with minor changes.

> --------
> 
> G4 -  I would suggest rewording this:
> 
> "The system MUST perform lease reclamation upon an expired lease before
> reusing it."
> 
> But is this necessarily true?  If the lease is going to the same client
> do we necessarily need or/want to execute the hook(s)?  Do we need to remove
> it from the database rather than just update it? 
> 
> (An interesting question becomes if you're doing B, is the lease truly
> free if DNS info hasn't updated yet?)
> 


If the lease has expired, it must be reclaimed, i.e. the "expiration
hook" must be called because we want to guarantee to the hook
implementors that the hook is called for each expired lease. Clients
should make sure they renew before the lease expires, in which case the
expiration hook is not called. But, if the client doesn't renew on time
and the lease expires the consequence is that the expiration must be
handled. As for the DNS, there may be cases that the client acquires the
lease it had before, and there is no change to FQDN. If the lease is
"refreshed" and we can determine that there is no sense to remove DNS
record and add the same record is something you call "optimization" :-)

> ----------
> 
> G5 - Could use rewording.  As it is currently written it is untestable.
> Is it attempting to describe what happens at startup or is it a general
> statement
> that says the system will process all leases which expire?  I think you
> may be trying
> to say more than thing here.
> 
> How can we expire all leases that were removed from the database? 
> They're gone,
> we cannot know they existed.
> 
> The e.g. of "during the server startup" implies several things.  First,
> what server are
> you talking about, Dhcpv4, Dhcpv6, or an Expiration Server?  Isn't that
> a design issue?
> If not that it should be stated as part of the Introduction.
> 
> If one assumes you mean the Dchp servers, it implies that the server
> will first deal
> with all expirations before it does other things.  This might mean a
> substantial lag
> before the server begins granting leases.
> 

I think that my version of this requirement didn't convey the message,
indeed. I have updated it to say that if you delete the lease from the
lease database, the lease must be reclaimed.

To explain why I previously referred to the server startup.... The
memfile backend reads leases from the file and when it finds that the
lease is expired it doesn't load it (drops it). This is technically a
removal of the lease from the database. Now, that becomes a problem
because when the Memfile reads leases when the server is not yet
prepared to perform lease expiration (reclaimation). So, it seems that
the Memfile should probably load expired leases from the lease file and
let the housekeeper routine deal with them. But, I agree this is more an
implementation detail, so I just say that if you remove the lease from
the database, it must be reclaimed.

> ---------
> 
> P1 - should be a general requirement if we keep it.  I'm assuming this
> one is based
> on the notion that newer expirations might be reused by their former
> owners?  Otherwise
> I'm not certain we really care about the order.
> 

Moved to general requirements.

> ---------
> 
> P2, P3, I1, and I2 are all design goals or decisions and not testable
> requirements.
> 
> P2 - At what point is the impact minimal enough?
> P3 - How many calls are too many?  
> I1 - How do I write a test that verifies backend agnosticism?
> I2 - At what point can you say that an implementation has reached the
> maximum amount
> of common code?
> 

Moved to the Design document (which I just now created):

http://kea.isc.org/wiki/LeaseExpirationDesign

> ----------
> 
> The section on Concurrency is entirely design.  It is valuable
> information but
> belongs in a design discussion/document.
> 

Also this is now moved to the Design document.

I left the paragraph in the Requirements document which directs to the
Design for details. I wanted to state something about the
multi-threading in the Requirements because it is a natural question
whether lease expiration can be done concurrently with the message
processing and we have discussed this to some extent. I just wanted to
explain why this document doesn't mention it.

Thanks for the input. It is really useful.

Marcin



More information about the kea-dev mailing list