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: Decline support requirements in Kea 1.0 (Marcin Siodelski)
2. Re: Call for comments about Lease Expiration requirements in
Kea (Marcin Siodelski)
3. Re: Decline support requirements in Kea 1.0 (Francis Dupont)
4. Re: Decline support requirements in Kea 1.0 (Marcin Siodelski)
5. Re: Decline support requirements in Kea 1.0 (Thomas Markwalder)
6. Re: Decline support requirements in Kea 1.0 (Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Fri, 26 Jun 2015 08:42:33 +0200
From: Marcin Siodelski <[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 26.06.2015 08:10, Marcin Siodelski wrote:
>
>
> 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
BTW, I don't believe that the host reservation case requires any special
treatment in the requirements document. It will require some explanation
in the design document, though.
Marcin
------------------------------
Message: 2
Date: Fri, 26 Jun 2015 09:22:47 +0200
From: Marcin Siodelski <[email protected]>
To: Tomek Mrugalski <[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 25.06.2015 15:49, 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 provided some thoughts about concurrency between the lease expiration
and the main thread, but since this is quite a complex topic and we will
have to explore this area some more, I put an explicit note that there
are no requirements for concurrency for 1.0. I left some more detailed
explanations in the preliminary design document. I can extend those with
the thoughts about impact on hooks in the concurrent model.
I imagine that some hooks would be stateless and would not bother that
two of the functions are ran at the same time. But, I can also imagine
that for some hooks that might be a problem, if the two functions access
the same data. If we ever try to do this concurrently, we can probably
add a configuration switch to signal whether the hook is thread-safe or
thread-unsafe and use multi threading or not.
>> 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'd leave it as is. Out of those three approaches, only second one
really makes a lot of sense. The other two are either less important or
not doable. For the server startup, you're usually not ready to perform
lease expiration when you load the leases because the whole server
infrastructure is not configured yet: D2 config not processed, some
hooks libraries not loaded. In order to reliably execute the lease
expiration process your server should technically be UP (and respond to
queries). So, this falls into your second approach. The third case is
when the server shuts down. Hm, so when it shuts down leases are no
longer renewed because the server doesn't process new queries and all
existing leases gradually expire. So, reclaiming leases right before the
shut down, while technically possible, doesn't bring a lot of benefit.
Thus, most of the use cases are during the run time anyway and I don't
think that such clarification is needed.
>
> 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.
>
I added the requirement but without the "command" as it narrows down the
possible approaches. It belongs to the design mostly.
> 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:
>
I think both serve the informational role to the administrator and they
are usually used together. For example: I observe strange figures in my
statistics, I look into the logs for details. This is sort of like
different log severity levels...
> L4 MUST decrease subnet[id].assigned-addresses statistic when reclaiming
> an expired lease.
>
Thanks, I have added it.
> Finally, it's rather obvious, but not explicitly stated, that all
> requirements apply to both v4 and v6.
>
Yes. This is legitimate comment. I have added two requirements to cover
them separately.
Marcin
------------------------------
Message: 3
Date: Fri, 26 Jun 2015 10:24:05 +0000
From: Francis Dupont <[email protected]>
To: Marcin Siodelski <[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"
Can I put a summary of this in #3915?
Thanks
Francis Dupont <[email protected]>
Marcin Siodelski writes:
> 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.
------------------------------
Message: 4
Date: Fri, 26 Jun 2015 12:25:45 +0200
From: Marcin Siodelski <[email protected]>
To: Francis Dupont <[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=utf-8
I have added the reference to this discussion in the #3915.
Marcin
On 26.06.2015 12:24, Francis Dupont wrote:
> Can I put a summary of this in #3915?
>
> Thanks
>
> Francis Dupont <[email protected]>
> Marcin Siodelski writes:
> > 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.
------------------------------
Message: 5
Date: Fri, 26 Jun 2015 06:34:28 -0400
From: Thomas Markwalder <[email protected]>
To: Marcin Siodelski <[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 6/26/15 2:10 AM, Marcin Siodelski wrote:
>
> 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".
This one could lead us down a rabbit hole:
> Plus another requirement which
> would say: "There must be a mechanism by which the system administrator
> can inspect currently declined addresses".
Unless it is sufficient to accept the requirement as met by us documenting
how the information can be understood by examination of the persisted
data. At first blush it implies we will provide some sort of tool or
interface
for reporting or retrieving this information. We also made no such
requirement
for any other persisted information. I would suggest we simply drop it.
> 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
I agree with the rest of Marcin's comments.
------------------------------
Message: 6
Date: Fri, 26 Jun 2015 13:03:57 +0200
From: Marcin Siodelski <[email protected]>
To: Francis Dupont <[email protected]>, Kea Dev List
<[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 26.06.2015 12:40, Francis Dupont wrote:
>> Can I put a summary of this in #3915?
>
> => oops, I failed to get a refreshed #3915. Anyway I agree temporary
> things which are better in a derived class so I'll split the secure
> DHCPv6 additions into things which should go into the database and
> go into the Host class, and the state stuff into a derived class.
> The cost should be in #3615 a few virtual keywords so the derived
> class can redefined some generic members if needed.
>
Thanks Francis.
BTW, can you tell me where to find the requirements and the design
document for the Kea secure DHCPv6?
Marcin
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 15, Issue 11
***************************************
