[Kea-users] Option-82-based reservation with remote-id

Tomek Mrugalski tomasz at isc.org
Wed Feb 1 21:01:48 UTC 2017


W dniu 01.02.2017 o 11:37, Rui Pedro Caldeira pisze:
> Hello Tomek, I would like to thank your openness for my need of this
> capability and I need it badly.
> Since circuit-ids can be equal even when sent from different relays
> (different remote-ids), I need the remote-id to disambiguate the
> circuit-ids. Therefore, I need to specify the remote-id in the config
> file next to the circuit-id, like in the following example:
> 
> "reservations": [
>           {
>             "remote-id": "<Remote ID Here>",
>             "circuit-id": "02:0A:00:01:06:07:00:00:00:00:00:00",
>             "ip-address": "192.168.168.66"
>           }
>         ],
>         "subnet": "192.168.168.0/24 <http://192.168.168.0/24>"
> },
This kind of definition is not something I had in mind. The problem with
your proposal are two identifiers used: remote-id and circuit-id.
This would be impossible to store in Kea reservation tables. Kea stores
reservations in MySQL and PostgreSQL in a table that has the following
columns: identifier-type, identifier, ip-address. There are several
other columns, but they're not important for this problem.

The remote-id value is unique on its own, right? So you could use the
remote-id only to distinguish between clients, right?

We currently support several identifier-types. When we add remote-id, we
will simply enable additional value to be specified there. This way we
can continue adding new identifiers without requiring every deployment
that stores them in SQL database to change the schema.

So it would look more like this:
"reservations": [
      {
          "remote-id": "<Remote ID Here>",
          "ip-address": "192.168.168.66"
      }
     ],
     "subnet": "192.168.168.0/24 <http://192.168.168.0/24>"
},

Would something like that work for you?

> I would like to ask how fast a patch to v1.1.0 could become available.
Adding new identifier type is maybe 2 weeks of work. We need to
implement the ability to find reservations by new identifier (that's
very simple), but we also need to update all reservation storages
(config file, MySQL and PostgreSQL) to store them. Finally, we need to
develop some tests that verify they are working. At the very minimum
those would have to be unit-tests, but preferably we should also have
system tests. That's what needs to be done from the engineering perspective.

Sadly, that doesn't mean you'll get it by mid February. We are currently
working on our 1.2 milestone and remote-id was not part of that work.

> Otherwise, do you have any tips as to how can I resolve this issue?
There are couple options. First, ISC sets the roadmap in a way to
accommodate requests from support customers, if possible. If such a
request came from a customer, we would do our best to implement it
promptly. Second, ISC offers custom development contracts. Sometimes we
are asked to develop certain feature with specific deadline and agreed
functionality. Depending on the agreed schedule, the code is then
released in the upcoming release (sometimes we do an engineering drop
earlier if the customer cannot wait for a release that is couple months
away). Both of those options require some financial commitment.

Another option would be to develop a patch yourself (or find someone who
will develop it for you) and send us a patch. I must honestly say that
we recently received quite a few patches that we still haven't reviewed.
So it's not an instant process by any means, but having a patch
definitely speed things up.

Finally, there's the "convince us" option. There are lots of missing
features in Kea and our resources are limited. Therefore we try to pick
those features for implementation that are most frequently requested,
would be useful for large number of users or give us a prospect for
improving financial stability of Kea.

These are basically your options. You are not the first one to ask for
remote-id reservations, so there's non-trivial chance that we'll decide
to put it on our plan for 1.3. 1.3 doesn't have any scope or release
date defined, but I could speculate it would be release some time in the
autumn.

Hope that helps. Sorry if that's not exactly what you were hoping for.

Tomek




More information about the Kea-users mailing list