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 Lease Expiration requirements in
Kea (Tomek Mrugalski)
2. Re: Call for comments about Lease Expiration requirements in
Kea (Thomas Markwalder)
3. Decline support requirements in Kea 1.0 (Tomek Mrugalski)
4. Re: Decline support requirements in Kea 1.0 (Thomas Markwalder)
5. Re: Decline support requirements in Kea 1.0 (Francis Dupont)
6. Re: Decline support requirements in Kea 1.0 (Marcin Siodelski)
7. Re: Decline support requirements in Kea 1.0 (Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Jun 2015 15:49:26 +0200
From: Tomek Mrugalski <[email protected]>
To: Marcin Siodelski <[email protected]>, Kea Dev List
<[email protected]>
Subject: Re: [kea-dev] Call for comments about Lease Expiration
requirements in Kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 24/06/15 14:27, Marcin Siodelski wrote:
> 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
That's a good proposal. Thanks for doing this. I have couple comments:
> G1.MUST execute lease-expiration hook for each reclaimed lease
Do we want to be more specific here that the hook will be called in the
same hook library instance (i.e. the same process/thread) as all the
other hooks? It may be easier for us to create a separate process/thread
that does lease recycling in the background, but it would be much more
difficult for hook lib developers as one of the callouts would be called
in a separate process/thread. On the other hand, if we specify this up
front in the requirements, it may limit the available designs for the
expiration framework. Hmmm, so maybe not saying anything at all here and
keep the text as is would be best?
> C1. MUST provide a configuration switch to disable lease expiration.
> It MAY be combined with the switch controlling the period between
> two consecutive processing cycles
I would reword it to "... to disable lease expiration during run-time".
I can imagine that, depending on your scenario, one of 3 approaches may
be desired: 1. expire leases once on start-up; 2. expire leases
periodically; 3. expire leases on shutdown. Case 1 is useful when you're
recovering from a blackout or other misfortune. Case 2 is the normal
operation that I expect to be used almost all the time. Case 3 is useful
when you want to squeeze top performance from your server, but still
want to have a clean database/dns afterwards.
I think you should also add two extra requirements. The first one
probably belong to a new administrative section:
A.1 There MUST be a command to manually trigger lease reclaimation.
With the CommandMgr and control socket for statistics implemented,
adding new commands is quite easy.
Another comment is about statistics. Not sure if logging and statistics
should be treated together (they are both used for debugging or general
awareness of what's happening in the system) or separately (logs and
statistics are handled in very different ways). In any case, here's one
entry that should be added:
L4 MUST decrease subnet[id].assigned-addresses statistic when reclaiming
an expired lease.
Finally, it's rather obvious, but not explicitly stated, that all
requirements apply to both v4 and v6.
Tomek
------------------------------
Message: 2
Date: Thu, 25 Jun 2015 10:10:33 -0400
From: Thomas Markwalder <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Call for comments about Lease Expiration
requirements in Kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 6/25/15 9:49 AM, Tomek Mrugalski wrote:
> On 24/06/15 14:27, Marcin Siodelski wrote:
>> 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
> That's a good proposal. Thanks for doing this. I have couple comments:
>
>> G1.MUST execute lease-expiration hook for each reclaimed lease
> Do we want to be more specific here that the hook will be called in the
> same hook library instance (i.e. the same process/thread) as all the
> other hooks? It may be easier for us to create a separate process/thread
> that does lease recycling in the background, but it would be much more
> difficult for hook lib developers as one of the callouts would be called
> in a separate process/thread. On the other hand, if we specify this up
> front in the requirements, it may limit the available designs for the
> expiration framework. Hmmm, so maybe not saying anything at all here and
> keep the text as is would be best?
>
I would not stipulate this as a requirement. As you point out, this would
bind us to a specific solution. Requirements must not dictate design or
implementation details. I could see adding it as a design consideration
in a preamble of the design document.
>> C1. MUST provide a configuration switch to disable lease expiration.
>> It MAY be combined with the switch controlling the period between
>> two consecutive processing cycles
> I would reword it to "... to disable lease expiration during run-time".
> I can imagine that, depending on your scenario, one of 3 approaches may
> be desired: 1. expire leases once on start-up; 2. expire leases
> periodically; 3. expire leases on shutdown. Case 1 is useful when you're
> recovering from a blackout or other misfortune. Case 2 is the normal
> operation that I expect to be used almost all the time. Case 3 is useful
> when you want to squeeze top performance from your server, but still
> want to have a clean database/dns afterwards.
>
> I think you should also add two extra requirements. The first one
> probably belong to a new administrative section:
> A.1 There MUST be a command to manually trigger lease reclaimation.
I would reword this to "There MUST be a means to manually trigger lease
reclamation"
> With the CommandMgr and control socket for statistics implemented,
> adding new commands is quite easy.
>
> Another comment is about statistics. Not sure if logging and statistics
> should be treated together (they are both used for debugging or general
> awareness of what's happening in the system) or separately (logs and
> statistics are handled in very different ways). In any case, here's one
> entry that should be added:
>
> L4 MUST decrease subnet[id].assigned-addresses statistic when reclaiming
> an expired lease.
>
> Finally, it's rather obvious, but not explicitly stated, that all
> requirements apply to both v4 and v6.
Obvious but should be stated. Good catch.
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
Message: 3
Date: Thu, 25 Jun 2015 16:35:11 +0200
From: Tomek Mrugalski <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Decline support requirements in Kea 1.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
All,
Here's another requirements documents written as a preparation for Kea
1.0. This one covers DECLINE messages support:
http://kea.isc.org/wiki/DeclineRequirements
There is one topic that's not covered by the requirements yet: how to
handle declined addresses in the host reservation context. One
reasonable approach is to maintain consistency with what is already
coded. Right now when the server discovers that the reserved address is
used by someone else (there's a lease for someone else), it treats the
reservation as unusable, prints a warning and continues as if there were
no reservation. I'd like to handle the decline case in similar way.
I'm not sure if that requires to be codified in the requirements page,
though.
Similar to lease expiration discussion, we want to close this discussion
by end of July.
Comments? Thoughts? Tomatoes?
Tomek
------------------------------
Message: 4
Date: Thu, 25 Jun 2015 12:37:42 -0400
From: Thomas Markwalder <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Decline support requirements in Kea 1.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 6/25/15 10:35 AM, Tomek Mrugalski wrote:
> All,
>
> Here's another requirements documents written as a preparation for Kea
> 1.0. This one covers DECLINE messages support:
>
> http://kea.isc.org/wiki/DeclineRequirements
>
> There is one topic that's not covered by the requirements yet: how to
> handle declined addresses in the host reservation context. One
> reasonable approach is to maintain consistency with what is already
> coded. Right now when the server discovers that the reserved address is
> used by someone else (there's a lease for someone else), it treats the
> reservation as unusable, prints a warning and continues as if there were
> no reservation. I'd like to handle the decline case in similar way.
> I'm not sure if that requires to be codified in the requirements page,
> though.
>
> Similar to lease expiration discussion, we want to close this discussion
> by end of July.
>
> Comments? Thoughts? Tomatoes?
>
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
G3 - Stating that a declined address must be removed from the managed
pool is a
design/implementation detail. You might reword this a "A declined
address MUST not
be assigned to a client"
C1 - I do not think this requirement is necessary. G1 and G2 already
require it be
supported. I'm not sure you gain anything by having this.
C3 - Remove the parenthetical suggestion of how-to. This belongs in a
design document.
H1 and H2 - The word "new" is unnecessary.
S1 - Change "being declined" to "currently in the declined state"
S2 - Clarify that this value resets upon server restart. Otherwise it
implies we must
keep track across restarts forever.
S3 - As with S1, "being declined" to "currently in the declined state"
------------------------------
Message: 5
Date: Thu, 25 Jun 2015 18:19:18 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Decline support requirements in Kea 1.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I have implemented a temporary state in the host (reservation) class,
it can be used for decline (I use it for secure DHCPv6 to store two
timestamps). This state is mutable (the setter is declared const)
and its extend/lifetime is the same than the host object, i.e.,
it is reset at restart or config reload. IMHO it is perfect for
keeping the (transient) fact an address is already in use.
Regards
Francis Dupont <[email protected]>
PS: from memory: #3915
Tomek Mrugalski writes:
> All,
>
> Here's another requirements documents written as a preparation for Kea
> 1.0. This one covers DECLINE messages support:
>
> http://kea.isc.org/wiki/DeclineRequirements
>
> There is one topic that's not covered by the requirements yet: how to
> handle declined addresses in the host reservation context. One
> reasonable approach is to maintain consistency with what is already
> coded. Right now when the server discovers that the reserved address is
> used by someone else (there's a lease for someone else), it treats the
> reservation as unusable, prints a warning and continues as if there were
> no reservation. I'd like to handle the decline case in similar way.
> I'm not sure if that requires to be codified in the requirements page,
> though.
>
> Similar to lease expiration discussion, we want to close this discussion
> by end of July.
>
> Comments? Thoughts? Tomatoes?
>
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 6
Date: Fri, 26 Jun 2015 08:10:27 +0200
From: Marcin Siodelski <[email protected]>
To: Thomas Markwalder <[email protected]>, [email protected]
Subject: Re: [kea-dev] Decline support requirements in Kea 1.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 25.06.2015 18:37, Thomas Markwalder wrote:
> On 6/25/15 10:35 AM, Tomek Mrugalski wrote:
>> All,
>>
>> Here's another requirements documents written as a preparation for Kea
>> 1.0. This one covers DECLINE messages support:
>>
>> http://kea.isc.org/wiki/DeclineRequirements
>>
>> There is one topic that's not covered by the requirements yet: how to
>> handle declined addresses in the host reservation context. One
>> reasonable approach is to maintain consistency with what is already
>> coded. Right now when the server discovers that the reserved address is
>> used by someone else (there's a lease for someone else), it treats the
>> reservation as unusable, prints a warning and continues as if there were
>> no reservation. I'd like to handle the decline case in similar way.
>> I'm not sure if that requires to be codified in the requirements page,
>> though.
>>
>> Similar to lease expiration discussion, we want to close this discussion
>> by end of July.
>>
>> Comments? Thoughts? Tomatoes?
>>
>> Tomek
>>
>> _______________________________________________
>> kea-dev mailing list
>> [email protected]
>> https://lists.isc.org/mailman/listinfo/kea-dev
> G3 - Stating that a declined address must be removed from the managed
> pool is a
> design/implementation detail. You might reword this a "A declined
> address MUST not
> be assigned to a client"
>
> C1 - I do not think this requirement is necessary. G1 and G2 already
> require it be
> supported. I'm not sure you gain anything by having this.
>
> C3 - Remove the parenthetical suggestion of how-to. This belongs in a
> design document.
>
>
> H1 and H2 - The word "new" is unnecessary.
>
>
> S1 - Change "being declined" to "currently in the declined state"
>
>
> S2 - Clarify that this value resets upon server restart. Otherwise it
> implies we must
> keep track across restarts forever.
>
>
> S3 - As with S1, "being declined" to "currently in the declined state"
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
I agree with Thomas's suggestions above and have the following
additional comments.
"Declined address" in the terminology - suggest replacing "unknown
entity" with a "different entity", as "unknown" is ambiguous.
"Declined state": - suggest to reword to "a state in which an address
is marked by the server as unavailable for the assignment"
G4 - rather than adding the explanation what it means to "recover an
address", it would be better to add a new term in the terminology and
use it here:
"Declined address recovery (or Address Recovery)" - a process by which
the server marks an address in the declined state as available for
assignment again, i.e. moves it out of the declined state.
G6 - I think it is too much for the requirements to imply that the
declined addresses must be kept in the database. It would be sufficient
to say that "The information about currently declined addresses MUST not
be lost after system restart or crash". Plus another requirement which
would say: "There must be a mechanism by which the system administrator
can inspect currently declined addresses".
G7 - I suggest updating this requirement to say that the log message
emitted, when the address is marked declined, includes the duration of
time for which the address will remain in the declined state.
C2 - I suggest rewording it slightly to use the terminology: "The amount
of time an address remains in the declined state MUST be configurable"
C3 - Similarly to C2 - It MUST be possible to configure the server to
keep an address in the declined state until sysadmin intervention.
Marcin
------------------------------
Message: 7
Date: Fri, 26 Jun 2015 08:31:30 +0200
From: Marcin Siodelski <[email protected]>
To: Francis Dupont <[email protected]>, Tomek Mrugalski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Decline support requirements in Kea 1.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Francis,
The Host object reflects the structure of the host reservation entries
in the database. The declined address may well be an address from the
dynamic pool for which nobody has a reservation, therefore it doesn't
logically belong to the Host object. In other words, if the specific
property is not a part of the host reservation information and will not
be stored in the database for host reservation it MUST NOT be a part of
the Host object.
If you want to utilize the Host class for something unrelated to the
host reservation (e.g. Decline, not sure about secure-DHCPv6) you should
derive from the Host class and then you can extend your derivation in a
way that is convenient for you.
I don't want the Host class to be a collection of various properties
used for diverse purposes, as it messes up the code structure and goes
against the host reservation design. For example: the Host class has a
toText function. It prints data in the context of Host Reservation.
Adding properties to this class implies that the toText function is also
updated to print these properties. One can argue that this mix of
various properties and host reservation data is not a problem for
toText, because if certain properties are not set for the Host, they are
not printed. In that case for the host reservation we don't print any
unrelated data. Yes. But, for the purpose of solely printing the
properties like declined address or secure DHCPv6 timestamps how do you
choose what is printed with the toText function and what is not? You
don't want to print all properties together with the host reservation
details, which are just a trash in the particular context in which the
properties are important.
Please remove any extraneous information, i.e. properties from the Host
class and implement it on the derivation of the Host object.
Marcin
On 25.06.2015 20:19, Francis Dupont wrote:
> I have implemented a temporary state in the host (reservation) class,
> it can be used for decline (I use it for secure DHCPv6 to store two
> timestamps). This state is mutable (the setter is declared const)
> and its extend/lifetime is the same than the host object, i.e.,
> it is reset at restart or config reload. IMHO it is perfect for
> keeping the (transient) fact an address is already in use.
>
> Regards
>
> Francis Dupont <[email protected]>
>
> PS: from memory: #3915
>
> Tomek Mrugalski writes:
>> All,
>>
>> Here's another requirements documents written as a preparation for Kea
>> 1.0. This one covers DECLINE messages support:
>>
>> http://kea.isc.org/wiki/DeclineRequirements
>>
>> There is one topic that's not covered by the requirements yet: how to
>> handle declined addresses in the host reservation context. One
>> reasonable approach is to maintain consistency with what is already
>> coded. Right now when the server discovers that the reserved address is
>> used by someone else (there's a lease for someone else), it treats the
>> reservation as unusable, prints a warning and continues as if there were
>> no reservation. I'd like to handle the decline case in similar way.
>> I'm not sure if that requires to be codified in the requirements page,
>> though.
>>
>> Similar to lease expiration discussion, we want to close this discussion
>> by end of July.
>>
>> Comments? Thoughts? Tomatoes?
>>
>> Tomek
>>
>> _______________________________________________
>> kea-dev mailing list
>> [email protected]
>> https://lists.isc.org/mailman/listinfo/kea-dev
>>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 15, Issue 10
***************************************
