NETCONF and YANG – why you need it

By Tomas Hedqvist

Managing network devices using NETCONF and YANG
Click image to enlarge

How do you manage your devices? Still using CLI:s and scripting? Or have you considered NETCONF  or REST

Nowadays you have a lot options when choosing management interfaces, some better than others. You have a lot to gain from choosing the right management protocols and data models if you want to automate network management, or ensure your devices can be managed in multi-vendor networks. You have even more to gain from choosing a modern, standardized management protocol if you want to manage virtual network functions (VNF) and leverage the benefits of software defined networking (SDN) and network functions virtualization (NFV).

I have listed four questions that could help you choose network interface and decide if NETCONF and YANG  is something you need.

1 - Do you need to configure a network or just a device?

In very small networks with up to a few dozen devices, managing them one by one may not be a very big concern. But in larger networks, with tens of thousands of devices, it sure is. Scripting has been the traditional way to solve this but is unreliable and definitely not standardized.

Configuration changes are best performed using transactions. Using transactions, you make sure that either the complete configuration, consisting of a sequence of changes, is applied or rolled back entirely. No half-done configuration changes in other words.

REST APIs works well for machine communication, especially when connecting to cloud services, which makes it useful for integration with orchestration. But it does not provide transactions, so it is a less optimal choice for device management.

NETCONF on the other hand is designed for device configuration and provides network-wide transactions, making it possible to change configuration for all devices in the network at once. A change will either succeed on all devices or it will not be activated at all. This way you make sure you have the same configuration in all devices.

2 - Do you need a standardized management interface?

Most networks, at least larger ones, are built with devices from multiple vendors. No need to say, standardization makes it much easier to manage multi-vendor networks.

Standardization starts with the data model. YANG, for example, is a standardized modelling language possible to use with both NETCONF and REST interfaces. Both configuration data and state data is modeled with YANG, providing a standardized way to describe devices. Northbound interfaces can be automatically rendered from the model ensuring consistency between the device and the management entity.

REST however is not a single, standardized protocol, but an architectural style. So while all REST APIs follow the same principles and guidelines, they are essentially proprietary.

NETCONF is an IETF standard with broad market adoption. Many service providers and network operators even require devices to be manageable using NETCONF and YANG if they are to be installed in their networks.

3 - Do you need robust management that doesn't fail?

I already mention that NETCONF uses transactions for configuration changes, making network management more robust.

Another property if NETCONF and YANG is that you as network manager does not have to keep track of the order in which changes are done to the device. This minimizes the risk of changes being committed in the wrong order, causing a faulty state in the device.

Devices modeled with YANG can also include constraints and data validation rules, making it possible to automate validation. This is important because you can both validate the model itself, and the data you put into it before you push it to a device.

NETCONF is designed around a configuration datastore concept, making rollbacks possible and even automatically applied if the device loses connection with the management entity because of a faulty configuration change.

4 - Do you want to automate?

With more and more network functions being virtualized, the number of devices and their locations are not static. If you would have to manually configure virtualized devices you will lose much of the agility you were looking for in the first place when virtualizing. But automation is important also with physical devices.

When you automate management you bring down opex and add agility. But remember that CLI:s are for humans, not automation. Automation needs an API making the device programmable, and that API can be provided by a YANG model and accessed over NETCONF or a REST API. YANG, because it is a standardized modelling language, makes it possible to manage multi-vendor networks with a high degree of automation.

REST, coming from the cloud end of things, integrates superbly with cloud services, making it a suitable option for integration with orchestration, but not directly from a managed device. Southbound from an EMS/NMS, NETCONF is the better alternative, but northbound, REST is a perfect option.

So what now?

If you want to know more about software for network device management interfaces, you should definitely read this report: Selecting NETCONF/YANG management interface software.