[Kea-users] Feature request: Control when "evaluate-additional-classes" is executed

[Darren Ankney]

Hi Jonas,

When creating this Gitlab issue, please be sure and provide a use-case
for this change.

You are describing placing a class membership guard on the subnet or
pool (client-classes) while simultaneously not evaluating the client's
membership in the class (evaluate-additional-classes) unless the
subnet or pool is chosen.  This seems to be a logic error.  I suggest
that you consider separating the class(s) that guard pool selection or
the evaluate-additional-classes to disparate subnets such that they
are not the same classes.  This would allow you to assign parameters
(options or whatever) via the "evaluate-additional-classes" mechanism
but only if the pool was selected via membership in another class(s)
via the "client-classes" mechanism.

You also may be interested in
https://kea.readthedocs.io/en/kea-2.7.5/arm/classify.html#option-class-tagging
if some of this is being used to make a decision about the inclusion
of options.

Thank you,
Darren Ankney

On Fri, Jan 3, 2025 at 5:13 AM Peter Davies <peterd at isc.org> wrote:
>
> Hi Jonas,
>
> Thank you for your interest in Kea.
>
>
> Please create a feature request issue at https://gitlab.isc.org/isc-projects/kea .
>
> You can attach any configurations to the gitlab issue.
>
>
> Kind Regards Peter
>
> ISC Support
>
>
> ________________________________
> From: "Kea-users at lists.isc.org" <kea-users at lists.isc.org>
> To: "Kea-users at lists.isc.org" <kea-users at lists.isc.org>
> Cc: "Jonas Alfredsson" <jonas.alfredsson at protonmail.com>
> Sent: Friday, 3 January, 2025 11:02:23
> Subject: [Kea-users] Feature request: Control when "evaluate-additional-classes" is executed
>
> Hi,
>
> With Kea 2.7.5 it is now possible to add a "client-classes" limit to the pool
> argument like this:
>
> {
>     "pool": "172.27.140.2-172.27.140.10",
>     "client-classes": ["k8s-node", "special-k8s-node"]
> },
> {
>     "pool": "172.27.140.20-172.27.140.30",
>     "client-classes": ["not-k8s-node"]
> }
>
> This is nice, but I ran into an issue where when we mark these classes with
> "only-in-additional-list": true, they are only evaluated after a pool has
> been selected, thus these pools will never be chosen unless we remove the
> late evaluation from the class definitions (which would mean that all
> requests are classified, even though it is only relevant for a single
> subnet).
>
> My suggestion/request would be that these "only-in-additional-list" are
> evaluated at the level where the "evaluate-additional-classes" is defined.
> So if we have the following configuration:
>
> "subnet4": [{
>     "id": 1,
>     "subnet": "172.27.140.0/26",
>     "evaluate-additional-classes": [
>         "k8s-node",
>         "special-k8s-node",
>         "not-k8s-node"
>     ],
>     "pools": { ... }
> }]
>
> The classes defined in that list are evaluated when the subnet has been chosen,
> but before the actual pool has been chosen.
>
> I will attach a complete config file to provide more context to what I am
> trying to achieve, and I am looking forward to hear what you think of this.
>
> Best regards,
> Jonas
>
>
>
> --
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> --
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users