[kea-dev] Searching in nested options

[Francis Dupont]

Leonardo Jelenkovic writes:
> First, there is an error in:
> http://kea.isc.org/docs/kea-guide.html#dhcp4-option-spaces example.
> Adding "csv-format": false to container in "option-data":
> {
>     "name": "container",
>     "code": 222,
>     "space": "dhcp4",
>     "csv-format": false
> }
> prevents error:
> kea-dhcp4.dhcp4/8616] DHCP4_PARSER_FAIL failed to create or run parser for
> configuration element option-data: option data does not match option
> definition (space: dhcp4, code: 222): no option value specified
> Same for #dhcp6-option-spaces.

=> I remember to have updated the corresponding text, can you check
with last version of the guide?

> Second, question/suggestion about nested DHCPcX options:
> Since "option-data" items have "space" element, why is it required to
> define each item for container, even if its standard option?

=> I don't understand how there can be standard options in a new space.

> Wouldn't standard options (with standard code/name) that we want in
> container be added just in "option-data" with "space" set to one in
> container definition?

=> I believe what you want is to be able to import definitions for
an option from another space, so if the same option is used in two
different spaces you have to define it once. Is it your idea?

> And finally, the real problem I have.
> Problem we have to solve can be described with a use-case:
> 1. Client sends option OPTION_PVD which is a container with suboption
> OPTION_PVD_ID.
> 2. Server could have several OPTION_PVD options (containers) with different
> suboption OPTION_PVD_ID. The OPTION_PVD option MAY be used to encapsulate
> any allocated DHCPv6 options (but only single OPTION_PVD_ID).
> 3. Server must search its OPTION_PVD options (in client's allowed space)
> and find one that matches one in client request (if found) and return that
> option.
> 
> What is the simplest way to do it? With little coding as possible :)

=> a hook (i.e., C++ code in a DSO).

> I thought that a new element needs to be introduced, e.g. "pvds", which can
> be defined globally (in dhcp6/dhcp4 space) and locally inside some subnet,
> with example format:

=> you need some syntax but fortunately a way to provide arguments
to a hook is being added.

> I didn't yet examined kea source code, and can't predict how simple/complex
> this is. I would appreciate any pointers (similar mechanisms already
> implemented), and possible ways of implementing this feature.

=> you already have vendor options (part of the standards), the hook
mechanism for any kind of extensions and with Kea >= 1.0 extended
classification. So you can implement what you'd like but of course
you prefer an easy/simple way...

Regards

Francis Dupont <fdupont at isc.org>