Implementing KEA DHCP server with Netconf support

[minexn]

I remember you plan to implement a DHCP server later this year. Have you considered KEA as a DHCP management solution? It supports Netconf, which presents significant advantages over developing a custom yang model for DHCP.

KEA's comprehensive support for IPv4 and IPv6, along with its high-performance capabilities in large-scale environments, ensures that it is well-equipped to meet the evolving demands of modern networks. Opting for KEA aligns with the industry's shift towards standardized network management protocols. It offers a future-proof solution that emphasizes security, scalability, and maintenance efficiency.

[wkz]

It looks very competent, for sure!

As for the built-in YANG model, I'm less enthused. Unless I'm missing something, which not improbable 😄, they seem to have fallen into the same trap as FRR. I.e. they've defined their models in a way that is not easily usable from a platform perspective, and not composable with other models.

Looking at this snippet:

<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server">
  <subnet6>
    <id>1</id>
    <pool>
      <start-address>2001:db8::1:0</start-address>
      <end-address>2001:db8::1:ffff</end-address>
      <prefix>2001:db8::1:0/112</prefix>
    </pool>
    <subnet>2001:db8::/64</subnet>
  </subnet6>
  <interfaces-config>
    <interfaces>eth1</interfaces>
  </interfaces-config>
  <control-socket>
    <socket-name>/tmp/kea6-sock</socket-name>
    <socket-type>unix</socket-type>
  </control-socket>
</config>

Stuff like specifying the path of UNIX sockets are great when you're configuring a daemon. But is going to be hard for us to support at the platform level. Maybe we can deviate it away as "not supported" and provide default values for properties that the platform should control.

As for the overall structure: if we where to include this in our model, you would then have the standard models (CLI example):

infix:/> configure
infix:/config/> edit interface eth1

And then alongside that, the KEA models:

infix:/> configure
infix:/config/> edit config interfaces eth1
infix:/config/> edit config subnet6 ...

The first line looks very similar to ietf-interfaces, but means something completely different, one is in singular form, the other in plural. The config container gives no indication that everything below this point is related to DHCP. It may sound superficial, but I think when you add up enough of these quirks, you loose the feeling of managing a cohesive platform.

Maybe this could be worked around with schema mounts or something.

---

In summary: very interesting project, but I'm not sure the existing sysrepo integration is an obvious winner.