There have been some recent discussions around the role of OpenFlow in the larger movement of Software-Defined Networking (SDN). Personally, I strongly believe OpenFlow plays a critical role in SDN – I don’t think it can be replaced by existing protocols/technologies. Over my next few posts, I’ll consider various technologies that are proposed as alternatives for use in SDN and see how well they stack up with OpenFlow. In this first post, I’ll briefly review the role of the OpenFlow protocol in an SDN architecture; cover some of the challenges of using the device command-line interface (CLI) as the basis for higher layer software systems; and finally close with some of OpenFlow’s advantages.

OpenFlow and Software-Defined Networking

First, recall how software-defined networking has a three-tier architecture with a packet forwarding/data plane tier at the bottom, a controller tier in the middle, and applications built on top of the controller’s abstractions and APIs. OpenFlow as a protocol is positioned between the data plane and the controller.

sdn-using-cli

Given this, it’s easy to box OpenFlow in and call it “just” a protocol between network devices and outside entities. And if you think of it just that way, then you start to consider a whole bunch of other ways that we have to talk to network devices. What about management methods like the CLI, SNMP, and/or netconf (take a look at Jim Duffy’s recent article on SDN with or without OpenFlow)? What about using VLANs, MPLS, and/or BGP?

So let’s first consider the CLI: can we use the command-line interface of individual devices to replace OpenFlow in the SDN architecture above?

Flashback to 1994: getconfig.exp, config parsing, and a central model

The first time I used the CLI as the building block of a network software system was in the early 90′s at NETSYS Technologies, where we all became experts at expect-based CLI parsing. We parsed Cisco router/switch config files and show commands, and our expect scripts (the main one being getconfig.exp) were so good that Cisco TAC was giving them away to customers. We built a centralized network model from those device configs (sound familiar?); told the administrators where the network was misconfigured; provided the ability to simulate/model changes and fixes; and eventually pushed “configlets” back down onto the routers and switches.

Our customers were happy enough for Cisco to acquire NETSYS in 1996. Here are the lessons from my NETSYS experience that appeared most relevant to this CLI-as-a-device-API discussion:

(1) The CLI is primarily meant to be used by people to configure network devices. The CLI was not designed for layers of software above it to program the network. I think we’d all agree that if we were to put our software hats on and design such a programming API, we would not come up with a CLI!

(2) Screen-scraping/parsing CLI is brittle and difficult. We had to work extremely closely with Cisco to understand how the configuration was affecting the actual forwarding on the routers (becoming IOS version/bug-compatible in several cases). It was difficult to keep our centralized model up-to-date because the network was such a mish-mash of constantly changing versions and devices. We also always had to worry about someone else logging into the system and changing the configurations behind the scenes. Occasionally, we’d run into the multi-thousand-line access-lists, and that was challenging to model correctly and at scale. Finally, now imagine handling just one other device vendor (not even true multi-vendor) – essentially you have to duplicate a huge portion of your development. We had actually started all the work of parsing Wellfleet router configurations before Cisco took us off market.

(3)The CLI doesn’t always have the functionality you need. Many times, you want the network to do something that can’t be done with existing protocols. The CLI does not expose the underlying capabilities of the switch in a flexible fashion. We often see network designers trying to contort and mash together one protocol with another, trying to make the network do what they want it to do. It’s especially frustrating when you know the underlying TCAMs can do it, but you just don’t have access to them!

There are whole protocols, companies, orchestration systems, libraries, etc. that try to work around the brittleness and difficulty with varying degrees of success and adoption. Systems built on SNMP and Netconf try to make it better, but they have the some of the same fundamental problems as CLI (especially #3). Ivan Pepeljnak said it very well in his recent post about OpenFlow enterprise use cases:

“Remember how many times you badly needed some functionality … that required a hodgepodge of expect scripts (or XML/Netconf requests if you’re Junos automation fan) that you have to modify every time you deploy a different device type or a different software release.”

Coming back to OpenFlow…

Now let’s take a look at OpenFlow with the context of the above limitations of the CLI:

- OpenFlow is a open, standards-based control protocol that effectively gives us that programming API on top of the network devices (addressing #1 and #2).

- Further addressing #2 above, OpenFlow by design separates the data plane from the control plane and has explicit provisions for keeping the control/data planes in sync. This means I can write software that has a centralized model of the network much more easily. As a developer, I can write apps that will work across multiple types of network devices and thus be deployable to a larger market of customers.

- Finally, OpenFlow provides the low-level access to the underlying switch capabilities. Do you want to write a system that controls multi-path forwarding by hashing across certain fields of the packet? Go ahead and do it the way you see fit, and don’t be limited by specific implementation (or availability) of ECMP, LAG, or whatever protocol on the underlying switch. There’s really no other standard out there that gives you this access except for OpenFlow (later post!).

In summary, CLI has been the bread and butter of network administrators for the last 20 years, and brand new networking products are still coming out with it as the primary interface for people exactly because it is so familiar. Many people over the years have built expertise and systems using it because that’s the main interface we’ve been given. However, should we use CLI as the basis for software-defined networking going forward – where layers of software need a device-level programming API? That’s not the way to unleash innovation and build out whole new ecosystems in the industry … I know there are many software developers out there who have experience scripting on top of CLI to build systems and to just get stuff done. Do you agree that we should be able to create a programming API that is better than device CLI?