NETCONF = Expect on steroids
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).
I think the answer to this conundrum is already taking shape in the form of OpenStack Quantum. A network configuration abstraction layer. What you standardize on is a north bound API, and you let vendors provide their specific "plugins" for carrying out the southbound operations - which could be NETCONF, OpenFlow, expect scripts, whatever.
I agree with you in that Quantum is headed in the right direction architecturally. Specifically, the ability of plugins to define extension APIs is analogous to the enterprise private MIBs we all know and love for pre-standards or proprietary functionality.
However, the currently defined 'core' APIs don't really allow granular access to the configurables on individual devices, the whole point being that the consumers of the NB API shouldn't have to twiddle bits in order to accomplish a provisioning task. So while Quantum is likely to evolve into a great abstraction layer for orchestration and compound provisioning operations, I don't really see it being terribly useful to CLI junkies and power users in the way that Expect scripting and Netconf (with direct mappings to device CLI/SNMP variables) can be.
To my knowledge, I also don't know of anyone using Quantum outside of the Openstack (Nova Compute as the driver of the NB API) ecosystem. This is likely because Quantum is still young and not quite ready to go out on its own; worth keeping an eye on for sure.
(Disclaimer: I work for a vendor that enthusiastically backs Openstack)
A vendor specific "plugins" for Quantum can expose additional vendor specific features and functionality not currently in the 'core' API. If those feature prove useful and commonly required, they can at some point be rolled into the 'core' Quantum API.
Topics such as NETCONF and OpenFlow are usually relevant in discussions about orchestration and network automation. The needs of the human CLI junky has little relevance in automation. In troubleshooting, the human CLI junky will likely bypass and ignore any abstraction layers anyway and just CLI straight to the vendor switch device.
But you're right, there needs to be something like NETMOD.
I mentioned SNMP solely because it has the third component (standard MIBs).
This made it much easier to add NETCONF to JUNOS than IOS* since much transformation needs to be done.
I'll say it again. The current (*hint*) NETCONF implementation in the IOS:es is unfortunately a major hurdle for NETCONF adoption and should be avoided for now.