|
|
# NETCONF Requirements
|
|
|
|
|
|
This page documents our requirements for NETCONF feature planned for upcoming Kea 1.5.
|
|
|
For the actual design, see [the design page](designs/netconf-design).
|
|
|
|
|
|
## Introduction
|
|
|
|
|
|
YANG/NETCONF is technology that allows defining YANG models that represent an informational model (it's a rough equivalent to a database schema). NETCONF is a network protocol that allows managing configurations that adhere to YANG models. The goal of this new Kea feature is to expose Kea configuration over NETCONF interface, so any NETCONF-compatible tool could be used to interact with Kea configuration.
|
|
|
|
|
|
## Glossary
|
|
|
|
|
|
NETCONF - a protocol that defines how to interact with (manage) YANG configurations.
|
|
|
|
|
|
YANG - a language that allows definition of YANG models.
|
|
|
|
|
|
YANG model - a definition of possible configuration parameters for certain device. Think about this as a database schema.
|
|
|
|
|
|
YANG configuration - specific values that adhere to underlying YANG model. This about this as a data stored in a database. The data has to adhere to the underlying schema (YANG model).
|
|
|
|
|
|
SYSREPO - a software project that features YANG model, YANG configuration storage, a NETCONF interface, and a programming API.
|
|
|
|
|
|
kea-netconf - a new daemon that will serve as an intermediary between Sysrepo and Kea DHCPv4 and DHCPv6 daemons. On startup it will connect to Sysrepo, retrieve initial configuration and then will listen to upcoming NETCONF changes. The initial configuration and following changes will be sent to Kea over control channel or REST interface.
|
|
|
|
|
|
## YANG Functional Requirements
|
|
|
|
|
|
- M1. A YANG model for DHCPv4 MUST be defined and made available.
|
|
|
- M1.1. The DHCPv4 model MUST cover IPv4 shared networks.
|
|
|
- M1.2. The DHCPv4 model MUST cover IPv4 subnets.
|
|
|
- M1.3. The DHCPv4 model MUST cover IPv4 pools.
|
|
|
- M1.4. The DHCPv4 model MUST cover IPv4 host reservations within IPv4 subnets.
|
|
|
- M1.5. The DHCPv4 model MUST cover client classes with the ability to define IPv4 options. This covers storing at least the basic information to make the class usable: class name, class test (an expression that is being evaluated on each incoming packet) and a list of option values.
|
|
|
- M1.6. The DHCPv6 model SHOULD provide ability to define IPv4 options on pools level.
|
|
|
- M1.7. The DHCPv6 model MUST provide ability to define IPv4 options on subnet level.
|
|
|
- M1.8. The DHCPv6 model SHOULD provide ability to define IPv4 options on shared-network level.
|
|
|
|
|
|
- M2. A YANG model for DHCPv6 MUST be based on [draft-ietf-dhc-dhcpv6-yang-06](https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-06).
|
|
|
- M2.1. The actual model used for DHCPv6 MUST cover IPv6 shared networks.
|
|
|
- M2.2. The actual model used for DHCPv6 MUST cover IPv6 subnets.
|
|
|
- M2.3. The actual model used for DHCPv6 MUST cover IPv6 pools for addresses and prefixes.
|
|
|
- M2.4. The actual model used for DHCPv6 MUST cover at least IPv6 host reservations within IPv6 subnets.
|
|
|
- M2.5. The DHCPv6 model MUST cover client classes with the ability to define IPv6 options.
|
|
|
- M2.6. The DHCPv6 model SHOULD provide ability to define IPv6 options on pools level.
|
|
|
- M2.7. The DHCPv6 model SHOULD provide ability to define IPv6 options on subnet level.
|
|
|
- M2.8. The DHCPv6 model SHOULD provide ability to define IPv6 options on shared-network level.
|
|
|
|
|
|
Note: every time a capability to define options is mentioned, it means provide values for existing, standard options. It does not cover ability to define new options via option definitions. This capability may be added at some later stage.
|
|
|
|
|
|
Note: many of the requirements will be fulfilled by a new kea-netconf daemon that will cooperate with Kea DHCPv4 and DHCPv6 servers.
|
|
|
|
|
|
## NETCONF/SYSREPO Interface Requirements
|
|
|
|
|
|
Kea will use existing capabilities of Sysrepo to provide API for NETCONF configuration manipulation. For details, see Sysrepo documentation. As a convenience to the user, we mention that there are at least the following interfaces available:
|
|
|
|
|
|
- sysrepoctl - it's a command line tool that allows local manipulation of the NETCONF configurations.
|
|
|
- NETCONF interface - sysrepo by default opens TCP port 830 and allows NETCONF connections.
|
|
|
- RESTCONF - Sysrepo webpage mentions RESTCONF. Unfortunately, Kea team never investigated that capability, so at the current time its support is considered speculative.
|
|
|
|
|
|
A new daemon called kea-netconf will be developed.
|
|
|
|
|
|
- N.1 The kea-netconf daemon MUST be able to connect to Sysrepo and retrieve initial configuration.
|
|
|
- N.2 The kea-netconf daemon MUST be able to connect to Sysrepo and listen to upcoming configuration changes.
|
|
|
- N.3 The kea-netconf daemon MUST be able to translate NETCONF configuration changes into JSON/REST commands that are understandable by Kea DHCP daemons.
|
|
|
- N.4 The kea-netconf daemon MUST be able to send the Kea commands to standard output.
|
|
|
- N.5 The kea-netconf daemon SHOULD be able to send the Kea commands over UNIX socket.
|
|
|
- N.6 The kea-netconf daemon MAY be able to send the Kea commands over HTTP connection.
|
|
|
- N.7 The kea-netconf tool MUST be extensible. The has to be a hook-like mechanism that will allow to install additional libraries that will provide additional functionality, such as processing changes of additional elements.
|
|
|
- N.8 The kea-netconf daemon MUST use regular Kea logging routines.
|
|
|
|
|
|
## DHCPv4 Functional Requirements
|
|
|
|
|
|
- A1. The kea-dhcp4 MUST be able to retrieve its initial configuration from NETCONF during startup. This requirement means that it will be possible to configure DHCPv4 server with an almost empty configuration and it will retrieve (or more precisely, the kea-netconf daemon will receive and pass along) the configuration from SYSREPO storage.
|
|
|
|
|
|
- A2. The kea-dhcp4 MUST be able to watch for Netconf changes and apply those changes when they appear while running. This feature will allow Kea configuration to monitor any changes in NETCONF configuration automatically and update its internal configuration on the fly.
|
|
|
|
|
|
- A2.1. The kea-dhcp4 MUST be able to create/update/delete IPv4 shared networks.
|
|
|
- A2.2. The kea-dhcp4 MUST be able to create/update/delete IPv4 subnets.
|
|
|
- A2.3. The kea-dhcp4 MUST be able to create/update/delete IPv4 pools.
|
|
|
- A2.4. The kea-dhcp4 MUST be able to add new subnets to existing shared networks.
|
|
|
- A2.5. The kea-dhcp4 MUST be able to remove existing subnets from existing shared networks.
|
|
|
- A2.6. The kea-dhcp4 MUST be able to create/update/delete client classes.
|
|
|
- A3. It MUST be possible to specify parameters not handled by NETCONF using local configuration file.
|
|
|
|
|
|
## DHCPv6 Functional Requirements
|
|
|
|
|
|
- B1. The kea-dhcp6 MAY be able to retrieve its initial configuration from NETCONF during startup. This requirement means that it will be possible to configure DHCPv6 server with an almost empty configuration and it will retrieve (or more precisely, the kea-netconf daemon will receive and pass along) the configuration from SYSREPO storage.
|
|
|
- B2. The kea-dhcp6 MAY be able to watch for Netconf changes and apply those changes when they appear while running. This feature will allow Kea configuration to monitor any changes in NETCONF configuration automatically and update its internal configuration on the fly.
|
|
|
- B2.1. The kea-dhcp6 MAY be able to create/update/delete IPv6 shared networks.
|
|
|
- B2.2. The kea-dhcp6 MAY be able to create/update/delete IPv6 subnets.
|
|
|
- B2.3. The kea-dhcp6 MAY be able to add new subnets to existing shared networks.
|
|
|
- B2.4. The kea-dhcp6 MAY be able to remove existing subnets from existing shared networks.
|
|
|
- B2.5. The kea-dhcp6 MAY be able to create/update/delete client classes.
|
|
|
- B3. It MAY be possible to specify parameters not handled by NETCONF using local configuration file.
|
|
|
|
|
|
The ability to store and retrieve configuration elements via NETCONF is not mutually exclusive with other configuration storage (either classical configuration file or upcoming config backend). However, due to the complexity and sometimes conflicting nature of configuration elements and their changes, the 1.5 release will assume that all configuration elements of a given type (e.g. subnets) are always stored in one place (i.e. either all subnets are defined in a configuration file or in NETCONF configuration, but not both). In other words:
|
|
|
|
|
|
- B4. Merging configuration elements of the same type (subnets, pools, shared networks) from different sources is OUT OF SCOPE for 1.5.
|
|
|
|
|
|
## Compilation requirements
|
|
|
|
|
|
- C1. The NETCONF support MUST be optional. In other words, Kea must still compile in the environments it did in 1.4 days, although NETCONF will likely be disabled if optional dependencies (such as Sysrepo libraries being installed) are not met.
|
|
|
|
|
|
## Features out of scope
|
|
|
|
|
|
The following set of features is out of scope for 1.5.
|
|
|
|
|
|
- 1. Merging configuration elements of the same type (subnets, pools, shared networks) from different sources.
|
|
|
|
|
|
The ability to store and retrieve configuration elements via NETCONF in principle is not mutually exclusive with other configuration storage capabilities (either classical configuration file or upcoming config backend). However, due to the complexity and sometimes conflicting nature of configuration elements and their changes, the 1.5 release will assume that all configuration elements of a given type (e.g. subnets) are always stored in one place (i.e. either all subnets are defined in a configuration file or in NETCONF configuration, but not both).
|
|
|
|
|
|
- 2. NETCONF support for DDNS and CA.
|
|
|
|
|
|
The problem with implementing it is there are no models defined for CA or CA-like functionalities, so we would have to define the model first and then also implement it. Given the time constraints we have it seems unlikely to happen in 1.5 timeframe. This is out of scope for 1.5. As such, no detailed requirements are defined at this time.
|
|
|
|
|
|
## Open questions
|
|
|
|
|
|
Stephen: Need to add a requirement to state what will happen if the configuration retrieved from the database is syntactically correct but semantically incorrect (e.g. overlapping pools). |