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 Lease Expiration design
(Thomas Markwalder)
2. Re: Call for comments about the Decline design (Marcin Siodelski)
3. Support for RFC7550 in kea (Marcin Siodelski)
4. Re: Call for comments about the Decline design
(Thomas Markwalder)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Jul 2015 08:47:38 -0400
From: Thomas Markwalder <[email protected]>
To: Marcin Siodelski <[email protected]>, Kea Dev List
<[email protected]>
Subject: Re: [kea-dev] Call for comments about the Lease Expiration
design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 7/27/15 8:22 AM, Marcin Siodelski wrote:
> Tom,
>
> Thanks for the review. My answers inline.
>
> On 14.07.2015 20:36, Thomas Markwalder wrote:
>> On 7/6/15 8:43 AM, Marcin Siodelski wrote:
>>> All,
>>>
>>> I have put together the document
>>> http://kea.isc.org/wiki/LeaseExpirationDesign, which presents the design
>>> for the Lease Expiration in Kea 1.0.
>>>
>>> This is the first pass for this document and it is still considered
>>> early draft. In particular there are two sections about extending the
>>> MySQL and PostgreSQL backend, which are marked "TBD". I am still
>>> wondering if I should put anything into these sections, given that the
>>> changes are straight forward and writing what we want to do may take
>>> more time and actually implementing it. Nonetheless, the document is in
>>> the shape in which people can review it and provide useful comments.
>>> Please to so!
>>>
>>> Marcin
>>> _______________________________________________
>>> kea-dev mailing list
>>> [email protected]
>>> https://lists.isc.org/mailman/listinfo/kea-dev
>> Nicely done.
>>
>> I find "most early" and "least early" confusing phrases. The word
>> "early" means "before an expected time" or "in the beginning part of an
>> event".
>>
>> "most early"
>> By this you mean, the lease whose expiration date is further in the past
>> than any other lease?
>> If so, than it is the lease with the "oldest expiration date" or the
>> "most expired".
>>
>> "least early"
>> By this you mean, the lease whose expiration date is nearest to the
>> present than any other lease?
>> If so, than it is the lease with the "newest expiration date" or the
>> "least expired". So we
>> process them in order of oldest expiration to newest expiration, or most
>> expired to least expired.
>>
>> I would prefer oldest expiration/newest expiration or most expired/least
>> expired.
>>
> Ok. I don?t object to this change.
>
>> ------------------------------------------
>>
>> I think you should at least outline the MySQL/PostgreSQL changes. If
>> there are schema changes, these have ramifications and these should be
>> identified. They would impact db related tools and scripts,
>> and adding (or not adding) indexes have performance implications.
>>
> Yes. This was the goal. I didn?t do it because of the time defficiency
> (upcoming IETF meeting etc.). At the same time I wanted to initite the
> design discussion as soon as possible, to gather the feedback prior to
> the start of the 1.0 milestone.
> I?ll fill this gap in.
>
>> ------------------------------------------
>>
>> Leases Reclamation Routine -
>>
>> Where you list the operations to be performed by reclamation routines, you
>> might want to change the "bullets" to numerals and state that this is
>> the order
>> they will be performed. This is relevant when discussing the hook points.
>>
> Ok. I?ll do it.
>
>> ------------------------------------------
>>
>> New Hook Points/Discussion and skip flag -
>>
>> Does it makes sense to honor the skip at all? Unless they alter the lease
>> lifetime or cltt and update the lease in the db (or delete if from the
>> db) in their callout,
>> skipping reclamation just causes the lease to come up for reclamation on
>> the next cycle.
>> Other than just honoring it as a matter of ultimate flexibility, I'm not
>> sure I see a use-case,
>> unless of course they are implementing their own expiration mechanisms.
>>
>> If we do decide to honor the skip flag for reclamation hook point, then I
>> think it should only be done as all-or-nothing. Either we reclaim it or we
>> skip it. I don't think it makes much sense to let them delete it from
>> the DB
>> but skip updating DDNS. We should also consider creating a statistic for
>> reclaim-skips so this can be tracked. And yes, we would need to clearly
>> document the ramifications of skipping a reclamation.
>>
> The hooks framework is all about the flexibility of the user and users
> may break their own server heavily. But, we have this situation for
> other hook points too. I am in favor of letting users implement their
> own expiration mechanisms, if they want to. If they don?t want to do it,
> they just leave the ?skip? flag alone.
>
> Here:
> "I don't think it makes much sense to let them delete it from the DB but
> skip updating DDNS?.
> Did you mean, ?Skip updating DDNS but deleting the lease from the DB? ?
Correct. If skip is false we update both the DB and DDNS, if it is
true, we do not update either one.
It is perhaps, unfortunate that the skipFlag is boolean, otherwise an
alternative would be to use it like a bitmask: SKIP_DB_UPDATE,
SKIP_DDNS_UPDATE, SKIP_DB_UPDATE|SKIP_DDNS_UPDATE.
>> ------------------------------------------
>>
>> I agree with your selection of Approach 2, implementing the TimeMgr, though
>> you don't really state who/what owns the worker thread in which the
>> IOService
>> is run. TimeMgr itself might actually be the best location for this by
>> providing a method, runTimerThread(), that when invoked spawns off the
>> worker thread which simply invokes io_service_->run(). Similarly, it should
>> probably provide a stopTimeThread() method. For that matter, TimeMgr, if
>> so desired could instantiate/use its own IOService instance.
>>
> I agree that the clarification is needed.
>
>> Although mentioned under approach 1, You cannot use io_service_->poll in
>> a loop,
>> as it returns immediately if no handlers are ready, so much of the time
>> it would
>> just spin like mad and go cpu-bound.
>>
> Duly noted.
>
>> ------------------------------------------
>>
>> Shouldn't there be an implementation task for retrofitting LFC
>> scheduling in the servers
>> to use TimerMgr?
>>
>>
>>
>>
> Yep. I?ll add one.
>
> Marcin
------------------------------
Message: 2
Date: Tue, 28 Jul 2015 09:38:35 +0200
From: Marcin Siodelski <[email protected]>
To: Thomas Markwalder <[email protected]>, Tomek Mrugalski
<[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Call for comments about the Decline design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 17.07.2015 17:01, Thomas Markwalder wrote:
> On 7/13/15 10:54 AM, Tomek Mrugalski 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
> I am not crazy about special purposing HWADDR/DUID to indicate a that lease
> has been declined. I get that it is "less expensive" in the short term
> from a development standpoint. I understand the appeal of that rationale but
> if that is the only motivation it isn't enough.
>
> From an analysis standpoint HWADDR/DUID are values that identify DHCP
> clients not a indicator of lease state. We all know that proper API design
> frowns upon multi-meaning parameters and the reasons why.
>
> We must also ask ourselves if there are any other circumstances under
> which we might persist a lease other than when it has been granted or
> declined? If so, would we need to retain the actual client values for
> HWADDR/DUID or would we define more special values? If we think there
> is a reasonable possibility of other cases where we would persist leases,
> then we should design for that now. A more extensible approach would be
> to add a state or status column.
>
> I realize that would leave us with a question of what values would we then
> store in these columns when a lease is declined. Again, from an analysis
> standpoint the most meaningful values would be those of the declining
> client.
> Suppose we did retain the value(s) from the declining client, what are the
> ramifications there? It is already conceivable that a returning client
> could
> find a previous but expired lease right? We must be checking for that
> now right?
> Bear in mind too, that using the "extra" effort it takes to test a flag or
> state column is no more than the effort the it takes to to test for a
> special
> value in HWADDR/DUID.
>
> Similarly, using the viewpoint of "don't change the schema" if we can
> squeeze
> it in somewhere else is short-sighted thinking. Not just in this matter
> but in
> any other. Eventually short-cutting the solution to "save time" ALWAYS
> comes
> back to haunt you. It may be faster now but we will feel the pain
> later. We
> have schema-upgrading now built into the project so we should not be afraid
> to change it. We should strive to do it right the first time.
>
> My gut instinct is that lease should have a state or status column and we
> should use it to indicate that a lease has been declined.
> ----------------------------------------------------------
>
> Regarding declined address processing via expiration - Should we really call
> both the decline_recycle and expiration_reclaim hooks? Seems to me that it
> should only call the decline_recycle hook. From a business logic
> standpoint it
> wasn't an active lease so it cannot "expire" and therefore cannot be
> reclaimed from
> expiration. If we call both then hooks developers may have to implement
> logic
> in their callouts to distinguish between the two business cases.
>
> What about the skip flag? How/where does this fit in?
>
> ----------------------------------------------------------
>
> Regarding the optional command to get "all declined", there needs to be
> some guard
> against how many we will return, if the number of leases is large it
> could be an issue
>
> ----------------------------------------------------------
>
>
Given all the comments for the lease expiration design and the decline
design, I would like to propose that we actually implement the
additional column 'state' for the Kea 1.0.
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
------------------------------
Message: 3
Date: Tue, 28 Jul 2015 12:57:22 +0200
From: Marcin Siodelski <[email protected]>
To: Kea Dev List <[email protected]>
Subject: [kea-dev] Support for RFC7550 in kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
During the hackathon@IETF 93 I have implemented the support for RFC7550.
This document updates the RFC3315 and RFC3633 and fixes several issues
around coexistence of the IA_NA and IA_PD in messages from a single client.
Suppose the case when the client (being also a requesting router) wants
to obtain both address(es) and prefix(es). It will perfom the 4-way
exchange and include both IA_NA and IA_PD options in the Solicit and
Request. If the server is only configured to assign addresses and not
prefixes it will send the NoPrefixAvail status code in the Advertise and
Reply. This part is covered in the RFC3315 and RFC3633.
The client enters the 'bound' state in which it sends Renew every T1
time. The client may still be interested in obtaining the prefix while
it renews addresses obtained. What the client can do per RFC7550 is to
include an empty IA_PD in the Renew message (apart from the IA_NA) to
signal that it is still interested in a prefix. If the server can't
allocate the prefix it will respond with the IA_PD and include the
NoPrefixAvail status code. Both, the ability by the client to request
prefix delegation in Renew (and Rebind) and the ability by the server to
include NoPrefixAvail is a new behavior introduced by the RFC7550.
Note that RFC7550 assumes that the server *may* be configurable to use
the new behavior. If the server is not configured to use the new
behavior it will do what is stated in the RFC3315 and RFC3633. And here
is the issue...
If the client has obtained an address but is interested in also
obtaining the prefix it will include the IA_PD in its message. The
server which is not configured to use the new behavior will respond with
the NoBinding in the IA_PD if the client has sent the Renew. But, if the
client sends the IA_PD in the Rebind message and the server is not
configured to allocate new prefix for the Renew/Rebind case, it should
drop the message per RFC3633. This is problematic because the server
will drop the message with a valid IA_NA! That was one of the reasons
why we have written RFC7550, because this behavior was broken in RFC3315
and RFC3633.
The question becomes, do we want Kea to have a configuration parameter
that allows for falling back to this original behavior (prior to
RFC7550)? I have implemented this parameter and I even have tests for
this. But, on reflection I tend to think that this switch should be
removed and the only supported behavior should be per RFC7550. The
reasons why:
- The code will be simplified, because it will not have to check which
behavior should be followed.
- The administrator will have less knobs, which may cause unexpected
behavior, to use.
- Even if the client is not updated to RFC7550 it should gracefully deal
with the NoAddrsAvail in the IA_NA and NoPrefixAvail in IA_PD. If they
don't, it means they are heavily broken. At the same time, you can't
guarantee that flipping this switch one way or another doesn't harm some
of your clients.
- The RFC7550 doesn't require the server to be backward compatible and
provide the configuration switch discussed here.
- The RFC3315bis (new spec for DHCPv6) will only support the new behavior.
What people think about it? Specifically, dropping the switch.
Marcin
------------------------------
Message: 4
Date: Tue, 28 Jul 2015 07:06:24 -0400
From: Thomas Markwalder <[email protected]>
To: Marcin Siodelski <[email protected]>, Tomek Mrugalski
<[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Call for comments about the Decline design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 7/28/15 3:38 AM, Marcin Siodelski wrote:
>
> On 17.07.2015 17:01, Thomas Markwalder wrote:
>> On 7/13/15 10:54 AM, Tomek Mrugalski 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
>> I am not crazy about special purposing HWADDR/DUID to indicate a that lease
>> has been declined. I get that it is "less expensive" in the short term
>> from a development standpoint. I understand the appeal of that rationale but
>> if that is the only motivation it isn't enough.
>>
>> From an analysis standpoint HWADDR/DUID are values that identify DHCP
>> clients not a indicator of lease state. We all know that proper API design
>> frowns upon multi-meaning parameters and the reasons why.
>>
>> We must also ask ourselves if there are any other circumstances under
>> which we might persist a lease other than when it has been granted or
>> declined? If so, would we need to retain the actual client values for
>> HWADDR/DUID or would we define more special values? If we think there
>> is a reasonable possibility of other cases where we would persist leases,
>> then we should design for that now. A more extensible approach would be
>> to add a state or status column.
>>
>> I realize that would leave us with a question of what values would we then
>> store in these columns when a lease is declined. Again, from an analysis
>> standpoint the most meaningful values would be those of the declining
>> client.
>> Suppose we did retain the value(s) from the declining client, what are the
>> ramifications there? It is already conceivable that a returning client
>> could
>> find a previous but expired lease right? We must be checking for that
>> now right?
>> Bear in mind too, that using the "extra" effort it takes to test a flag or
>> state column is no more than the effort the it takes to to test for a
>> special
>> value in HWADDR/DUID.
>>
>> Similarly, using the viewpoint of "don't change the schema" if we can
>> squeeze
>> it in somewhere else is short-sighted thinking. Not just in this matter
>> but in
>> any other. Eventually short-cutting the solution to "save time" ALWAYS
>> comes
>> back to haunt you. It may be faster now but we will feel the pain
>> later. We
>> have schema-upgrading now built into the project so we should not be afraid
>> to change it. We should strive to do it right the first time.
>>
>> My gut instinct is that lease should have a state or status column and we
>> should use it to indicate that a lease has been declined.
>> ----------------------------------------------------------
>>
>> Regarding declined address processing via expiration - Should we really call
>> both the decline_recycle and expiration_reclaim hooks? Seems to me that it
>> should only call the decline_recycle hook. From a business logic
>> standpoint it
>> wasn't an active lease so it cannot "expire" and therefore cannot be
>> reclaimed from
>> expiration. If we call both then hooks developers may have to implement
>> logic
>> in their callouts to distinguish between the two business cases.
>>
>> What about the skip flag? How/where does this fit in?
>>
>> ----------------------------------------------------------
>>
>> Regarding the optional command to get "all declined", there needs to be
>> some guard
>> against how many we will return, if the number of leases is large it
>> could be an issue
>>
>> ----------------------------------------------------------
>>
>>
> Given all the comments for the lease expiration design and the decline
> design, I would like to propose that we actually implement the
> additional column 'state' for the Kea 1.0.
>
> 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.
Thomas
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 16, Issue 13
***************************************
