OpenConfig - a standardized approach to configuring network equipment

We would like to share with you a free translation of an article from the Packet Pushers website about the difficulties in configuring multi-vendor networks. First of all, they are faced by telecom operators. As a provider develops (including absorbing other operators), its network grows and turns into a complex ecosystem of various equipment. In small networks, this problem is usually not so acute. That, however, is due to it - companies are trying, without good reason, not to buy iron from different manufacturers into their network. The complexity of setting up here makes for mono-venomousness.

Operator dilemma
')
One of the problems of network automation is that we do not have standardized interfaces for configuring network equipment from different manufacturers. In other words, it is difficult to configure a multi-vendor network using software tools when this process is different on each device.

When managing through the command line (Command Line Interface - CLI), network operators face significant differences in its syntax on hardware from different manufacturers. For example, commands that configure BGP on a Cisco device running the IOS operating system will not work for the same task on a Juniper device running JUNOS. Switching from the command line to hardware configuration via application programming interfaces (API) does not solve the problem. The interfaces offered by the manufacturers of network equipment differ in their implementation and functionality from each other no less than CLI. This is partly due to the specifics of network operating systems. Not all network operating systems provided the opportunity to use the API, and it can be difficult for manufacturers to integrate their support into their products.

Configuration models

One of the options for implementing software configuration of network equipment - configuration models. The data model defines the structure, syntax and semantics of the data that we load onto network equipment. When they are transmitted, a protocol is used in conjunction with the data model that determines their coding and the transfer mechanism to the device. In other words, the model determines the rules by which we set the configuration parameters of network equipment. And the transport protocol transfers this data to the equipment. The configuration model can be compared with the SNMP protocol, which was originally designed to manage network devices, but for a number of reasons is mainly used for monitoring. - approx. ed.

For us, accustomed to consider every network device, based on the interface of its command line, the “model” is represented as configuration lines. For example, “interface gigabitethernet 0/1” or “router bgp 65432” opens up a Cisco IOS user with configuration mode for the Ethernet interface or the BGP routing process. And transport in this case is the SSH protocol.

Many people understand that the future of configuring network devices remains behind the application programming interfaces. But moving away from the command line, we didn’t get away from the main problem: the unification of the equipment configuration is now hampered not by the command line syntax, but by data models for protocols like NETCONF , created on the basis of descriptive modeling languages. These models are often written based on the YANG language and, like the command line syntax, they vary greatly from manufacturer to manufacturer. As a result, users remain with the same problem: on different hardware, the process of performing the same task is still different.

Diversity is not a highlight.

The industry is facing a problem: we want to automate the process of configuring the network, but we cannot predict which models and interfaces will be needed for this. Sounds very familiar. Recall the SNMP protocol. SNMP is a common standard. All network devices support some of the elements of the MIB database. However, the most important parameters are unique for each equipment manufacturer and require the use of specific MIB databases.

Will we be able to alleviate this configuration nightmare by moving from CLI and SNMP to NETCONF (or any other configuration transfer method) with YANG models?

Manufacturers, of course, will defend the uniqueness of their decisions, as well as the absolute need to use models that match their specific capabilities. And they can be understood. It would be unfair to criticize manufacturers for their desire to differ from competitors.

In turn, network operators have the same right to defend the idea that networks are networks. BGP is BGP, ISIS is ISIS, OSPF is OSPF, and the Ethernet interface (for the most part) is the Ethernet interface, etc. And what's the difference, we configure the hardware Cisco, Juniper, Brocade or something else. If on each of them you need to configure the same function, it is easy to guess that we would like it to be configured the same everywhere! How can you automate network configuration, when we just turn away, how do you need to tweak the script somewhere, add a module, wait for the automation tool to get a patch from the manufacturer, or do you need some more tambourine dances?

OpenConfig and IETF come to standard network models

This situation worries not only the author. The IETF has several projects of varying degrees of completeness aimed at developing standard network models based on YANG. For example: the model for managing network interfaces RFC7223 , the model for inventory and management RFC7317 , the model for configuring the SNMP protocol RFC7407 , and the model for configuring the OSPF protocol . But for someone, the work of the IETF is moving too slowly, and for some, the models they offer are simply not suitable.

In this regard, several large companies decided to bring the transition to the standard network models closer by organizing the OpenConfig project . On the main page, OpenConfig writes about itself like this:

“OpenConfig is an informal working group of network operators united by a common goal - to transfer networks to a more dynamic programmable infrastructure by implementing the principles of software-defined networks, such as declarative configuration and model-based management. The main focus of our work is the development of uniform data models for configuration and management, the support of which is initially built into the software and hardware platforms of various equipment manufacturers. ”

Who are these companies? As of January 2016, participants on the OpenConfig page were: Google, AT & T, British Telecom, Microsoft, Facebook, Comcast, Verizon, Level3, Cox Communications, Yahoo !, Apple, Jive Communications, Deutsche Telekom / TeraStream, and Bell Canada. In other words, LARGE service providers with huge networks and data centers that need to maintain constant growth and ensure dynamic changes in their networks, preferably with minimization of various obstacles in their work.

In the early days of its activities, the OpenConfig “informal working group” worked very productively, creating models for BGP, MPLS and interface management. Now there are different models in access (for example, a model for network telemetry ). All of them are published on Github , and evolve quickly, because it was for the rapid evolution that OpenConfig was created. On the FAQ page, OpenConfig writes: “At the moment, the project has no formal guidance. We rely on the fact that the participants here have common goals and vision, their actions are transparent and on common issues they try to maintain agreement. ”

Of course, if you start thinking about a project like OpenConfig, you will find two main reasons for concern:

1. Will network hardware vendors support OpenConfig?
2. Does OpenConfig ignore IETF standards?

Consider the first - the support of manufacturers. For network equipment manufacturers, the main question here is how difficult it will be for them to adapt existing network operating systems to model-based work. For example, for Juniper, support for the IETF and OpenConfig models is easy. JUNOS is, in essence, driven by models. In addition, Juniper hints (unfortunately, the author does not provide references to these hints - approx. Ed.) That OpenConfig support will be in the next versions of JUNOS (possibly even in 16.1). Cisco announced OpenConfig support for IOS-XR (NCS, ASR, CRS, XR) back in November 2015 (support for two OpenConfig models is already available - BGP and Route Policy - editor's note).

Will other manufacturers add support for OpenConfig models? Time will tell. But there are strong suspicions that this will happen. Remember who is behind this initiative. Money in the network industry has the right to vote. The consumer who can pay, as a rule, gets what he wants.

How is the IETF? Is OpenConfig on its way? Yes and no. Everything is somewhat more complicated. The OpenConfig project began in part as a reaction to the poorly ordered and unhurried work of the IETF. However, OpenConfig works with the IETF to help them develop various standards. The 2015 OpenConfig Annual Report page below lists the projects created by the OpenConfig working group for the IETF. So, although OpenConfig does not want to wait until the IETF deals with its models, it recognizes the importance of the IETF and even makes its own contribution to their work.

What can OpenConfig give?

The basic idea is that OpenConfig focuses only on the model, paying less attention to the complete API, which includes both the model and the transport (for more details, see the article by Jason Edelman). After all, our main goal is to achieve the integrity and predictability of the model on all network devices. The tools (transport) with which we load models onto equipment are important, but in their case the problem of choice and unification is not as urgent as with the presentation and modeling of data. By and large, we do not care how the data was loaded. But it is very important that they are presented in the format we need - so that we can understand them, that is, so that our tools can easily analyze and work with them.

As standard network models become ubiquitous, the world will open to develop tools, orchestration platforms, monitoring software and SDN controllers, and excellent configuration and reporting tools will appear on the market. Software manufacturers will no longer need to focus on the most common vendors, deciding whose equipment to support, because the whole world of networks will be the market for them.

Ethan Banks, January 2016


The question of the availability of standard approaches for configuring network equipment from different manufacturers arose long ago. The same SNMP protocol was one of the attempts to solve it. He remained unresolved for so long that everything seemed to be even used to the situation. The emergence of software-defined networks lifted him to the surface once again. The idea of ​​connecting to the controller of any network equipment assumes the existence of standard means of communication between the controller and the device. In parallel with this, there was a need for tools to ensure the automation of network configuration - their programmability. If earlier, to configure network equipment, the command line and the Web interface were used most often, now many manufacturers are actively adding support for various application programming interfaces (OpenFlow, OpenStack, JSON, XML, NETCONF / YANG, etc.). And even within the framework of one vendor we are offered a whole bunch of such tools. In this regard, the idea of ​​OpenConfig is quite sensible and relevant in terms of time of appearance.

The article turned out, in our opinion, a bit utopian due to the huge desire of manufacturers of network equipment to be unique. By agreeing to full standardization, they risk turning their devices into faceless boxes. Most likely, OpenConfig support is limited to programming certain functions. As usual, time will put everything in its place.