An Operator’s Dilemma
From an operator’s perspective, one challenge with network automation is the lack of standard interfaces. In other words, it’s hard to configure a network programmatically if the details vary from device to device. Today, most operators know these differences in the form of CLI syntax. For example, the commands required to configure BGP on a Cisco device running IOS differ from the commands required to accomplish the same task on a Juniper device running Junos.
Network operators who are moving away from the CLI and towards programmatic configuration have very much the same problem. The programmatic interfaces available from networking vendors vary quite widely in form and function. This is due in part to the capabilities of the underlying network operating systems. Not all NOS’s support programmatic interfaces easily, placing a considerable burden on the vendor to create.
This leads us to an interim concern — that of network modeling. For a network operator who is used to thinking of a network device in terms of its CLI, the “model” comes in the form of configuration paragraphs. For example, “interface gigabitethernet0/1” or “router bgp 65432” takes an IOS CLI user into a configuration stanza for an Ethernet interface or BGP routing.
As the future of configuration shifts from the CLI to programmatic interfaces, the modeling problem shifts from syntax to descriptive language models that a protocol such as NETCONF can access. Like CLI syntax, these models, often described in YANG, vary from vendor to vendor, leaving end users with the same operational problem we’ve had for a very long time: processes vary from box to box, even though we’re trying to perform an identical task.
Variety: Not The Spice Of Operations
As an industry then, we have a problem: we want to automate network configuration, but the models and interfaces to do so are unpredictable. This sounds horribly familiar. SNMP is a standard, and some parts of the MIB tree are commonly supported by all network devices. However, the OIDs that matter the most for a given device end up hidden away deep inside the vendor-specific areas of the MIB tree.
Are we destined to relive this configuration nightmare as we move away from the CLI and SNMP, and towards NETCONF (or whatever configuration transport works for us) and YANG models?
Maybe. Vendors will naturally argue about the uniqueness (unicorn-ness?) of their magic solution, and the need to have models that address their special capabilities. And that has merit. It would be unfair of me to criticize vendors for wanting to differentiate from their competitors.
Maybe not. Despite the previous point, I argue that networking is, by and large, networking. BGP is BGP, ISIS is ISIS, OSPF is OSPF, and (for the most part) an Ethernet interface is an Ethernet interface, etc. And I don’t care if I’m configuring a box from Cisco or Juniper or HP or Brocade or whomever…if I’m configuring the same bleeding feature from box to box, guess what? I want to configure it in the same way! Unicorn-ness be damned. By Thor’s hammer, how am I going to automate my network’s configuration if every time I turn around I’ve got to tweak a script, add a module, wait for a vendor to patch my automation tool, or otherwise screw around with my operational processes to accommodate a new platform?
OpenConfig And The IETF Define Standard Network Models
I’m far from the only one to be upset by this issue. There are several IETF projects in various states to define standard network models in YANG, for example RFC7223, RFC7317, RFC7407, and drafts such as this one on OSPF. That said, IETF progress has been too slow for some. And for others, the IETF models haven’t quite met their needs.
Several mighty customers desiring to move towards standard network models have banded together to form the OpenConfig project. On its home page, OpenConfig describes itself thusly.
“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.”
And who are these mighty customers? The OpenConfig participants page lists Google, AT&T, British Telecom, Microsoft, Facebook, Comcast, Verizon, Level3, Cox Communications, Yahoo!, Apple, Jive Communications, Deutsche Telekom / TeraStream, and Bell Canada as of January 2016. In other words, service providers — BIG service providers with big networks and data centers facing their customers that need to support rapid growth and dynamic change with a minimum of operational obstruction.
In its early days, OpenConfig’s “informal working group” has been rather productive, creating models for BGP, MPLS, and interfaces. There is also a model for network telemetry as well as other models in the routing space. These models — published on Github — are evolving rapidly, rapid evolution being a trait OpenConfig is streamlined for. From their FAQ page, OpenConfig states that, “There is no formal governance at present — we depend on participants having shared vision and goals, behaving transparently, and supporting rough consensus.”
Of course, there are two major concerns that arise when considering a project like OpenConfig.
- Vendor support. Will vendors support OpenConfig?
- Existing IETF efforts. Is OpenConfig flouting the IETF?
Let’s consider the first issue — vendor support. The challenge for vendors seems to be how easily they can adapt their network operating systems to a model-driven process. For a vendor like Juniper, supporting IETF models, OpenConfig models, or both is not a big concern. Junos is model-driven under the hood anyway. Even the Junos CLI — reportedly only about 2K lines of code — is merely an abstraction referencing their established data model. And Juniper suggests that OpenConfig support is coming in the release of Junos 16.1 as an upgrade to the current wrapper-based support already offered.
Cisco, too, announced OpenConfig support for IOS-XR back in November 2015, citing in their press release, “Predictable network programmability through data-model-driven APIs (YANG/OpenConfig).”
Will other vendors add support for OpenConfig models? Time will tell, but I strongly suspect that they will. Consider once again who’s behind this effort — the aforementioned mighty customers. Dollars speak loudly in the networking industry. If you spend a lot, you very often get what you want.
But what about the IETF issue? Is OpenConfig flying a middle finger to the incumbent standards body? Well, yes. And no. It’s complicated. In my understanding, OpenConfig was, in part, started as a reaction to the cat-herding and slow-moving processes of the IETF — not to mention the politics. However, OpenConfig is also engaged with the IETF to help move their work into the various standards tracks. For example, at the bottom of the OpenConfig 2015 year-in-review page, several IETF drafts submitted by OpenConfig are listed. So while OpenConfig might not want to wait around for the IETF to sort out their own models, they recognize the importance of the IETF and contribute their work to the body.
What Does OpenConfig Mean For Operators?
For operators, I believe the key takeaway is the emphasis OpenConfig places on models as opposed to APIs. Application programmatic interfaces are important, but as Jason Edelman points out in his article on OpenConfig (well worth reading), there is “less importance on the underlying transport (I don’t care how you get me the data), and more importance on how the data is represented or modeled (The data needs to be in THIS format, so I can understand it, i.e. my tools can easily parse and work with the data).”
Therefore, don’t be looking for APIs from OpenConfig, at least not initially. A consistent, predictable model across network devices is where the real magic is. The tools used to extract that consistent, predictable data are important, but less immediately impactful to the problem at hand.
As an operator, I think it’s wise to monitor OpenConfig closely, keep up with what they are doing, observe the intersection with the IETF, and demand support from your vendor if you like what you see.
When standard network models become ubiquitous, a world opens up to tool makers, orchestration platforms, monitoring software, and SDN controllers to bring brilliant configuration and reporting tools to market. No longer will a software company have to choose which vendor’s hardware to support, betting on the most widely deployed to help ensure success. Instead, the networked world at large will be their marketplace. That’s a world of innovation I’m looking forward to.
My special thanks to Pallavi Mahajan, a 12 year Juniper veteran, for sharing her perspective with me on OpenConfig.