[kea-dev] Design for Kea Host Reservation

Marcin Siodelski marcin at isc.org
Mon Oct 6 17:28:25 UTC 2014



On 06/10/14 18:36, Tomek Mrugalski wrote:
> On 30.09.2014 13:20, Marcin Siodelski wrote:
>> I have created a new design document on Kea wiki:
>> http://kea.isc.org/wiki/HostReservationDesign for Host Reservation. It
>> summarizes the discussions that we conducted on a mailing list and
>> during the Kea hackathon.
> There was a recent update to the host reservation design page. Here are
> my comments:
> 
>   "If the allocation of the new lease fails for the reserved address or
>   prefix, the allocation engine retries using the client's hint. If that
>   fails, it proceeds with a normal allocation process."
> 
> That's completely wrong, I'm afraid. Host reservation is not a
> guideline or a suggestion, it's a strict rule the server must follow. HR
> can be used to grant or special service, but also also to confine users
> in various ways. We can't simply give them a regular address instead.
> 

I take this point. But, you might have seen my email sent earlier today
to Thomas where I state this:

"For the Host Reservation, there is an assumption that the server will
always try to use reserved resources for a host, if any. But, if the
reserved resource is unavailable for some reason (e.g. is in use) the
server should still be able to provision the client by allocating some
other resource. We may obviously speculate whether it is always
appropriate for the server to allocate a different address than the one
that the administrator wanted a client to get and whether the client
should rather not be provisioned in such case. But, I think it is not a
problem to make this configurable at the later time once the whole logic
is in place. So, this discussion is out of scope in the doc."

In my opinion we should not make too strict assumptions because I can
imagine customers having some use cases in which this would be allowed.
And, I state this again: it is much easier to restrict something (with a
configuration knob) than extend the mechanism if the use case appears.

I tend to agree that this is going to be a rare case. But for this
reason I don't see a massive escalation of issues that someone has
received different address than reserved.

As you seem to be pretty confident here, I would like you to make a
final statement on this: "that we will never, ever need a configuration
knob which would allow for dynamic allocation if reserved address is
unavailable". If you can make this statement I can remove this from the
design.

> Reservation means that the address or prefix is reserved for a given
> host and nobody else can get it. It also works the other way
> around. That host can get that specific, reserved address or
> prefix. The server is not supposed to assign anything else instead.
> Users will immediately say that the reservation didn't work.

Ok, so I am an admin I created a pool of addresses and have no HRs. Then
I decided that I want to use some addresses from this pool for HRs and I
reconfigured my server appropriately. But, I didn't send Reconfigure or
anything of this kind. One of my clients is still using an address
dedicated for someone else. The other client comes in and
wants an address but it is in use. What can I do to help my client?

One of the possible approaches would be to wait for the first client to
renew his address and once the server sees the renewing client it may
send 0 lifetimes to this client to say: "don't use this address anymore,
because I have reservation for it. Instead I am giving you this
dynamically allocated address". The reserved address gets back to the
server and waits for the second client to renew in which case the second
client gets the reserved address and the previously allocated address is
de-allocated. So, over time there is a transition and both clients
remain in service and they finally get their addresses as appropriate.
What is wrong with this?

I'd be careful expressing desire of users, especially if they have a
configuration knob to switch between one or another. But, I agree that
this may have been included in the document.

> 
> If a less than clueful admin inserts a host reservation for a lease
> that is currently assigned to someone else, we should log an error and
> be very vocal about it. It's a configuration error. The client should
> not get any other address. He should pick up the phone and call his
> support to tell his ISP or his IT that something is broken.
> 
> This is quite important. Otherwise we'll get a nasty negative comments
> from users. "Hey, I did a host reservation, but the server didn't like
> it for some reason and assigned something else. Your HR is broken."
> 

I don't want to get panicked by this. Maybe let's ask users? Maybe let's
disable this by default and display warnings when enabled?

> Here's how it should work in my option:
> 
> 1. there are no reservations
> 2. client A gets address X
> 3. admin add reservation for address X to client B
> 4. client B requests an address, the server discovers that there is a
>    reservation, but also a lease for client A. It logs an error and
>    the client B is not assigned any address.
> 5. Client B repeats discovery process in loop, with exponential backoff.
> 6. Client A eventually renews, the server discovers that the address
> it has is reserved to someone else, send X with 0 lifetime back to A
> and assigns other address Y.
> 7. Client B does another discovery attempt and get reserved address X.
> 
> Obviously, 3. is a misconfiguration, but we can't completely prevent
> that from happening.
> 
> This is the right way to recover from a misconfiguration in my
> opinion. If we implement the way you propose, then users will start
> asking questions: why didn't the host reservation work? How long till
> the server starts using the host reservation I specified? And there
> would be no easy answers, because it would depend on T1 and lease
> lifetmes (think about clients that get an address and disappear: waiting
> till T1 wouldn't be enough, you'd have to wait till valid-lifetime).
> 
> You may argue that the plan I described about generates more
> traffic. That is true, but it's a weak argument. First, such
> misconfiguration is expected to be a rare event. Second, it gives much
> better recovery time. The usual exponential backoff counts to 120
> seconds (or 3600 seconds if a client supports RFC 7083). That's still
> much better recovery time than some of the real networks we heard about
> (e.g. 7 days lifetime in cable networks).

Ok, so this is an exponential backoff for the Client B. But Client B
still needs to wait for Client A to renew and so as the server can
replace the address it is using with a new (not reserved address). So,
the Client's B retransmission period doesn't mean anything on its own.
If the Client A waits for 7 days before it Renews, Client B is out of
service for 7 days. Whereas, with the approach I described it could use
some address during the transition period.


> 
> In time, when we get reconfigure support, we will trigger it after
> step 4 to make the recovery much faster.

Obviously not for DHCPv4.

> 
> -----
> 
> My second comment is about something I tried to point out previously.
> This design as presented allows in-pool reservations. That is more
> convenient for the administrators, but it less performant.
> Allowing that is a mistake in my opinion. The algorithm should be much
> simpler:

I don't see a reason whye the reservation can't be out of the pool. So
you're proposing that when I define a reservation, the configuration
mechanism checks if this reservation happens to be in one of the pools
defined for a subnet? And if it is, reject the reservation? How would I
guarantee this for the HR configuration in the database? What about the
cases that someone reconfigured the server as we were discussing above?

Sorry if I completely misunderstood your point.

> 
> Is there HR for this client? If yes, use whatever is reserved and be
> done with it. If not, use dynamic allocation as it is defined now,
> without performing any HR queries at all. It's faster and the code is
> simpler.

So you're proposing that the server doesn't check if the lease exists
for the particular address in the lease database when it has HR?

I also don't understand "without performing any HR queries at all". The
query to the HR database has to be made to obtain information if the
reservation is specified for the host.

> 
> This is a design decision. It will have a non-trivial performance
> penalty. I'm not trying to overrule your decision here. If you
> understand the implications and still decide to go as planned, so be
> it. In any case I'll insist on running performance tests before and
> after HR is implemented.

I have no issue with performance tests. In my opinion we should run them
as soon as possible for all changes we make.

Marcin


More information about the kea-dev mailing list