[kea-dev] Design for Kea Host Reservation

[Tomek Mrugalski]

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.

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.

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."

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).

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

-----

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:

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.

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.

Other changes are fine.

That's it. I don't have any other comments.
Tomek