After the initial explosion of OpenFlow/SDN hype, a number of people made claims that OpenFlow is not the tool one can use to make SDN work, and NETCONF is commonly mentioned as an alternative (not surprisingly, considering that both Cisco IOS and Junos support it). Unfortunately, considering today’s state of NETCONF, nothing can be further from the truth.

What is NETCONF?

NETCONF (RFC 6421) is an XML-based protocol used to manage the configuration of networking equipment. It allows the management console (“manager”) to issue commands and change configuration of networking devices (“NETCONF agents”). In this respect, it’s somewhat similar to SNMP, but since it uses XML, provides a much richer set of functionality than the simple key/value pairs of SNMP.

For more details, I would strongly suggest you listen to the NETCONF Packet Pushers podcast.

What’s wrong with NETCONF?

Greg Ferro made a great analogy in the above-mentioned podcast: NETCONF is like SNMPv2/v3 (the transport protocol) and Yang (the language used to describe valid NETCONF messages) is like ASN.1 (the syntax describing SNMP variables). However, there’s a third component in the SNMP framework: a large set of standardized MIBs that are implemented by almost all networking vendors.

It’s thus possible to write a network management application using a standard MIB that would work with equipment from all vendors that decided to implement that MIB. For example, should the Hadoop developers decide to use LLDP to auto-discover the topology of the Hadoop clusters, they could rely on LLDP MIB being available in switches from most data center networking vendors.

Apart from few basic aspects of session management, no such standardized data structure exists in the NETCONF world. For example, there’s no standardized command (specified in an RFC) that you could use to get the list of interfaces, shut down an interface, or configure an IP address on an interface. The drafts are being written by the NETMOD working group, but it will take a while before they make it to the RFC status and get implemented by major vendors.

Every single vendor that graced us with a NETCONF implementation thus uses its own proprietary format within the NETCONF’s XML envelope. In most cases, the vendor-specific part of the message maps directly into existing CLI commands (in Junos case, the commands are XML-formatted because Junos uses XML internally). Could I thus write a NETCONF application that would work with Cisco IOS and Junos? Sure I could … if I’d implement a vendor-specific module for every device family I plan to support in my application.

Why would you use NETCONF?

Let’s consider the alternatives: decades ago we configured network devices over Telnet sessions using expect scripts – simple automation scripts that would specify what one needs to send to the device, and what response one should expect. You could implement the scripts with the original expect tool, or with a scripting language like Tcl or Perl.

Using a standard protocol that provides clear message delineation (expect scripts were mainly guesswork and could break with every software upgrade done on the networking devices) and error reporting (another guesswork part of the expect scripts) is evidently a much more robust solution, but it’s still too little and delivered way too slowly. What we need is a standard mechanism of configuring a multi-vendor environment, not a better wrapper around existing CLI (although the better wrapper does come handy).