BIND 9.16 Branch is approaching EOL
The BIND 9.16 branch is approaching EOL. This branch was first published on March 6th, 2020, four years ago.
Read post
A couple of IETF hackathons took place recently (Prague, Yokohama, Buenos Aires) and attracted quite a few geeks and hackers interested in various technologies. One such technology is DHCP. A handful of ISC employees attended these hackathons. We hacked Secure DHCPv6 in Prague (still experimental) and DHCPv4-over-DHCPv6 in Yokohama (on master already, will be shipped in Kea 1.1). In Berlin we decided to focus on YANG and NETCONF.
A room full of geeks, hacking Kea, Sysrepo, and other code
What are YANG and NETCONF?
One of the challenges in managing a large network is that many devices and services use different configuration mechanisms. There are two problems: how to store a configuration and how to apply that configuration to a device or service. To solve this problem in a generic way, the IETF came up with two solutions: YANG and NETCONF. YANG is a data-modeling language used to model configuration and state data that was published by IETF in 2010 as RFC6020. Network Configuration Protocol (NETCONF) is a network management protocol used to deliver configuration data, standardized by IETF in 2006. Its current revision is defined in RFC4741.
Currently there are around 220 YANG models being defined in the IETF, which seems to generate a lot of attention. One of them is being worked on in the DHC working group. It is dedicated to DHCPv6 configuration and is available in this Internet-Draft. While the model covers all server, client, and relay agent functionalities, the current focus of the work is the DHCPv6 server. While the model is not mature enough for widespread use, it is sufficiently developed to conduct first lab trials, so we decided to give it a try.
Sysrepo and Kea
Kea engineers got in touch with engineers from the Sysrepo project. We discussed several possible approaches and decided to go with an architecture of Sysrepo as the main YANG module storage that connects to Kea, using a custom-developed Sysrepo plug-in that would send the configuration and any future changes to Kea. Sysrepo would expose its the models using NETCONF interface.
The work being done
One of the essential components of that project is Sysrepo Datastore, a repository for YANG models that can be manipulated both locally (using provided tools) and remotely (using Netopeer2 NETCONF server). Since we had the prototype YANG model defined in the draft-ietf-dhc-dhcpv6-yang, we decided to use that model as a base and import it into Sysrepo.
There were two crucial elements missing, though. Kea uses JSON formatted configuration files that are read from disk. To make Kea configurable using YANG/NETCONF, we had to develop: 1) some way to export data from Sysrepo to a format understandable by Kea; 2) a way for Kea to receive configuration other than reading a configuration file from disk.
To address the first issue, ISC and Sysrepo engineers developed a prototype plugin for Sysrepo. It’s a plugin that, when loaded, monitors the state of the YANG model and subscribes for notifications about any changes. When a change is detected, it retrieves a small subset of essential parameters that are necessary to run the basic features of Kea. It then generates a JSON structure and sends them to Kea using the control channel. This code is available on github: https://github.com/sysrepo/sysrepo-plugin-kea.
To address the second issue, we extended Kea with a prototype of a new command called set-config. Set-config allows delivering configuration over the command channel. For this specific purpose, we created a separate, temporary repository on github: https://github.com/isc-projects/kea-yang. Once the prototype is more mature and the code related to it is available in the main Kea repository, we will shut down the kea-yang repository.
As a result of those two features, we have a working prototype using the following architecture:
Kea and Sysrepo architecture
The prototype was able to store the YANG model and configuration for that model, export that configuration to JSON syntax that is understood by Kea and then send that configuration to Kea over the command channel. Kea was able to receive it and reconfigure itself as requested. People interested in recreating this experiment are encouraged to read the README.
The next steps
It was an exciting experiment and very intense two days of learning, hacking, and understanding new technologies. While the solution is definitely in its experimental phase, we did learn a lot. Kea engineers now have some experience with YANG models in general and the Sysrepo way of handling them in particular. We provided some feedback and suggestions for improvements to both Sysrepo engineers and the authors working on the Internet Draft in IETF. We also know how YANG integration with Kea could be done when we decide to fully develop it. For the time being, we are not going to invest any significant engineering effort into developing it further, but we will observe the project with great interest. It seems likely that in the near future, once the technology matures, Sysrepo will be the way to provide YANG capability in Kea.
Interested? ISC is looking for prospective and existing customers who are interested in sponsoring development of YANG/NETCONF integration with Kea. Depending on how popular this feature request is, we may decide to develop this into a full feature of production quality.
Thank you a lot to everyone who participated, contributed or otherwise helped with this effort. Special thanks go to Lukas Macko and Rastislav Szabo from the Sysrepo project for their suggestions, tips, and code snippets; to Linhui Sun from Tsinghua University for his continuous work on the RFC that defines the YANG model; and to Mikael Abrahamsson from T-Mobile for coordinating the effort.
See you at the next hackathon!
Tomek Mrugalski, ISC Kea lead engineer
