[Kea-users] full set of option82 agent options for v4, flex-id extension

Tue Jun 6 15:49:49 UTC 2017

Hi Tomek,

thanks again for the feedback. I am trimming the mail a bit to
concentrate on the points I wanted to comment about.

On Tue, 6 Jun 2017, Tomek Mrugalski wrote:
> On 06/06/17 13:43, Christian Kratzer wrote:
>> Hi,
>>
>> another thing turned up in my quest in evaluation the move from isc to
>> kea dhcp.
>>
>> I currently have all of the following options for identifying host
>> reservations in isc dhcp:
>>
>>   host-identifier option agent.circuit-id "lineid-1001";
>>   host-identifier option agent.remote-id "/lineid-1002/";
>>   host-identifier option agent.subscriber-id "lineid-1003";
>>
<snipp/>
> Interesting case. But in general you control the values of those
> options, so you can ensure they all are unique within your network,
> right? You could try the following expression:

The point is that various hardware can often only do one thing.

The cisco l2 dhcp snooping agent for ipv4 can only insert circuit-id.

Some zyxel gear can only do remote-id.  There can be both kind of devices
in one l2 domain so we cannot separate them by other criteria.

So we need to support both.

When matching host reservations our provisioning system for isc dhcp
generates the specific host reservation required for the client.
So this is not an issue.  They will be unique per port and we will only
find a spefific lineid in one way.   We also generate any quoting
necessary so kea would just need to match.

So the short story is we could handle this ipv4 use case very nicely
if kea would support all 3 agent options circuit-id, remote-id, subscriber-id.

In this specific use case I only need circuit-id and remote-id so that would
result in two sql queries which would be perfectly fine.

<snipp/>
>> Any reason remote-id and subscriber-id were left out.  Or is this just
>> missing in the db schema ?
> When we were implementing 1.1, there were new use cases coming up with
> different identifiers. At certain point we decided that we are not going
> to implement all of them, because people simply coming with more and
> more exotic identifiers. This is why some identifiers were left out.

The point is none of them are more exoctic than the others. They are all in
use in various kinds of equipment and you often cannot choose.

So I would like to have all 3 agent options added so for the simple
use cases where we do not yet need flex-id.

Please ;)

> Some time has passed and I came up with the idea of flexible identifier,
> where you can define what will be used as the identifier. When flex-id
> became available, it can support anything, so there's no point in
> implementing dedicated identifiers anymore.
>
>> A related issue would turn up when using flex-id.  As we neeed different
>> identifiers depending on the access technology we might also need
>> different flex-id instances.   Currently we would be fine with ipv4 when
>> remote-id and subscriber-id are added.  Also in ipv6 we currently have
>> all the ldra set to option 18 interface-id.  Still a situation might
>> turn up in the future where we might need multiple variations of flex-id.
> Sure. Existing implementation of flex-id is just a first iteration. We
> could certainly improve it. See my two proposals above. Your proposal
> below is a third one. It has couple issues, but I'm sure those could be
> worked out.
>
> To be more specific, the two issues I have with this approach are:
> 1. it would be difficult to store this a database. In general, the DB
> uses subnet-id, identifier-type (integer) and indentifier-value
> (arbitrary byte string) to pick a reservation. The proposal below would
> have to fit into this somehow. It currently have 4 pieces of information
> (type: subnet-id, interface-type set to a value of interface-id, flex-id
> as a type, flex-id value) which is one too many.
> It's a solvable problem, though.

The point is that if you define multiple variations of flex-id each with a
unique name in the config you could use exactly those names as the identifier-type
in the sql database and need no schema alteration at all.

That way you could support multiple flex-id schemes at the same time.

Networks that have such a requirement will happily pay the price of another db query.

Those would need to be added to the foreign keys to host-identifier in the reservation table of course.

You could even preadd them as flexid-1, flexid-2, or add them on demand from the config.

> 2. the whole reservation system queries database (be it proper SQL or
> our own in memory db) by calling get4(subnet-id, identifier-type,
> identifier-value) query. If you define multiple expressions, there would
> be multiple queries for each incoming packet. This is not a
> deal-breaker, just a performance penalty for having too many
> expressions. With two or three of them you'd probably be ok, though.

It will mostly be two or three.  My point is that in multi vendor networks you
need to be able to handle such things.

Components like dhcp or in other networks radius will need to be flexible enough
to handle thse cases.

<snipp/>

>
> Thanks for sharing this. It's a definitely interesting use case.

Greetings
Christian

-- 
Christian Kratzer                   CK Software GmbH
Email:   ck at cksoft.de               Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0       D-71126 Gaeufelden
Fax:     +49 7032 893 997 - 9       HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843           Geschaeftsfuehrer: Christian Kratzer
Web:     http://www.cksoft.de/