Isn’t SNMP just great? I love monitoring my network using an unreliable transport mechanism and an impenetrable and inconsistent data structure. Configuring my devices using automation is equally fun, where NETCONF has been subverted into something so ridiculously vendor-specific (and again, inconsistent), that each new device type (even from a single vendor) can mean starting again from scratch. Is there any hope for change? OpenConfig says yes.

Monitoring The Network

Love it or hate it (hate it), SNMP remains the de facto standard for alerting and monitoring. I think we cling on to SNMP as an industry because we’re scared that any replacement will end up being just as clunky, and we’d simple be putting expensive lipstick on a particularly ugly pig. If we want to get rid of SNMP, whatever comes next will need to bring significant benefits.

Configuring the Network

If you’re dedicated to making changes manually, it’s likely you don’t care much about the mechanisms currently available to automate configuration changes. However, I can assure you that writing scripts to make changes to network device configurations is a frustrating activity, especially in a multi-vendor environment. I should add that I consider automating CLI commands and screen-scraping the response a valid method of configuring devices, but correctly trapping for errors is a task that can rapidly spiral out of control.

At the moment there isn’t even a way that I can connect to every device in order to find out what that device is. If I accept that I have to implement the same change in different ways depending on the vendor or the model of the configuration target, discovering the model, software version and available control mechanisms is something that happens, well, after you have already used one of those control mechanisms to request that information. SNMP, ironically, gets closest to this, but is implemented so inconsistently that parsing the results again becomes a nightmare.

NETCONF

I like NETCONF conceptually, and it can easily be used for monitoring as well as configuration tasks. However, NETCONF is really just a transport for message, and the implementation of the message structure has been left to the vendors which as usual means it’s a disaster area.

OpenConfig

I am not sure how I had missed OpenConfig before the presentation at Data Field Day Roundtable in November, but I have been very glad to have been introduced to it and I’m excited for the possibilities it opens up for the future – assuming that the hardware vendors play ball and stick to the common core model. Despite its name, OpenConfig is not just for configuration, but rather it attempts to address both configuration and monitoring.

Here’s the brief introduction to OpenConfig from their website (they put it so much better than I could):

OpenConfig is an informal working group of network operators sharing the goal of moving our networks toward a more dynamic, programmable infrastructure by adopting software-defined networking principles such as declarative configuration and model-driven management and operations. The initial focus of the effort is on the development of vendor-neutral data models for configuration and management that will be supported natively on networking hardware and software platforms.

The key, in my eyes, is the goal to develop “vendor-neutral data models for configuration and management.” Wouldn’t it be nice if the command to enable a switch port was fundamentally the same regardless of the switch model? How about if checking the current status of a switch port was also the same for every vendor? What if – and I’m pushing the boat way out now – the basic command structure for both was the same, but one with a flag indicating that you are setting the status, and one indicating that you wish to read the status? This way instead of having a MIB for reading the status and a NETCONF XML RPC command to set the status, you have one “interface status” command, and it’s easy to switch between configuring and reading?

Maybe life isn’t quite that simple, but OpenConfig aims to get pretty darned close. Here’s a sample structure similar to what Google’s Anees Shaikh showed us at DFDR1:

Hopefully the diagram makes sense and demonstrates that by using a read/write (rw) tree and a readonly (ro) tree within the interface object, the same elements (e.g mtu, name, description and so forth) can either be queried or set. Elements that can’t be set (e.g. interface counters) reside only in the ‘ro’ tree. Every vendor can support a common version of this, right?

Transport, Events and Traps

OpenConfig communicates using HTTP/2 because of its fast connection speed and ability to support multiple asynchronous queries and responses. This one protocol needs to support the needs of configuration tools and network management tools, plus it needs to be able to send event-based traps. The main difference therefore is that connections for all these use cases are initiated to the device; the device does not initiate communications outbound like a SNMP trap does today.

Configuration

An HTTP/2 session is initiated as necessary to implement the configuration and validation commands necessary for network automation. The session is closed once tasks are complete.

Telemetry (Monitoring)

An HTTP/2 session is initiated to the network device and a request is sent to subscribe to a telemetry stream. The session is kept open, and rather than waiting for the network management server to request the periodic data, the network device can automatically send it over the open connection at the specified interval. The parameters for this monitoring would be specified in the request, and multiple subscriptions could be requested to meet varying needs, all within the one HTTP/2 channel.

Events

An HTTP/2 session is initiated to the network device and a request is sent to subscribe to an event stream. It may be that the request format could allow the event stream to be filtered so that, say, only security events would be requested by a security management product.

Vendor Support

OpenConfig isn’t going anywhere without vendor support, and thankfully the project seems to have it. Some vendors apparently are maintaining stealth at this point, but others – including Cisco and Juniper – have publicly announced their involvement and given demos. If Cisco and Juniper both adopt OpenConfig and make it available in their products, it seems to me that it would vastly improve the chances and rate of adoption in the marketplace.

Target Market

It’s worth noting that OpenConfig describes itself as “an informal working group of network operators,” which means at least initially the focus is on things that will benefit those players. The list of OpenConfig participants published on the OpenConfig web site is comprised mainly of traditional Service Providers, but with Apple, Facebook, Google and Microsoft as interesting additions to the mix.

Learning More

I suspect you have many questions, not least to explain how vendors can allow their proprietary elements to be managed through this common model, and how OpenConfig might coexist with legacy SNMP-only devices and SNMP-only NMS tools. The best place to start is with the video of Anees Shaikh presenting at Data Field Day Roundtable 1 where he answers those questions and more:

The OpenConfig presentation was one of a number of presentations at DFDR1, a very interesting event which was sponsored by Cisco and held in their offices. I’ll be watching OpenConfig with some interest going forward.

A quick summary of OpenConfig activities can be read in their 2015 Year End Summary.

 

Disclosures
I attended the OpenConfig presentation as an invited delegate to Data Field Day Roundtable 1, sponsored by Cisco. The sponsor pays money to present to delegates, and in turn that money funds my transport, accommodation and comestibles while I am there. That said, I don’t get paid anything to be there, and I’m under no obligation to write so much as a sausage about any of the presenters, let alone write anything nice about them. So if I do so, you can rest assured that I’m saying what I want to say, and I’m writing it because I want to, not because I have to.

You can read more here if you would like.