Every time I write about a simple use case that could benefit from OpenFlow, I invariably get a comment along the lines of “you can do that with NETCONF”. Repeated often enough, such comments might make an outside observer believe you don’t need OpenFlow for Software Defined Networking (SDN), which is simply not true. Here are at least three fundamental reasons why that’s the case.

Control/Data Plane Separation

Whether you need OpenFlow for SDN obviously depends on how you define SDN. The networking components were defined by their software the moment they became smarter than cables connecting individual hosts (around the time IBM launched 3705 in the seventies if not earlier), so you definitely don’t need OpenFlow to implement networking defined by software.

However, lame joking aside, the definition of SDN as promoted by the Open Networking Foundation requires the separation of control and data planes, and you simply can’t do that with NETCONF. If anything, ForCES would be the right tool for the job, but you’ve not heard much about ForCES from your favorite vendor, have you … even though its development has been slowly progressing (or not, depending on your point of view) for the last decade.

Implementing new functionality

NETCONF is a protocol that allows you to modify networking device’s configuration. OpenFlow is a protocol that allows you to modify its forwarding table. If you need to reconfigure a device, NETCONF is the way to go. If you want to implement new functionality (whatever it is) that is not easily configurable within the software your networking device is running, you better be able to modify the forwarding plane directly.

There might be interesting things you could do through network device configuration with NETCONF (installing route maps with policy-based routing, access lists or static MPLS in/out label mappings, for example), but installing the same entries via OpenFlow would be way easier, simpler and (most importantly) device- and vendor-independent.

For example, NETCONF has no standard mechanism you can use today to create and apply an ACL to an interface. You can create an ACL on a Cisco IOS/XR/NX-OS or a Junos switch or router with NETCONF, but the actual contents of the NETCONF message would be vendor-specific. To support devices made by multiple vendors, you’d have to implement vendor-specific functionality in your NETCONF controller. On the contrary, you could install the same forwarding entries (with the DROP action) through OpenFlow into any OpenFlow-enabled switch (the “only” question being whether these entries would be executed in hardware or on the central CPU).

Ephemeral state

NETCONF protocol modifies device configuration. Whatever you configure with NETCONF appears in the device configuration and can be saved from running configuration to permanent (or startup) one when you decide to save the changes. You might not want that to happen if all you want to do is apply a temporary ACL on an interface or create an MPLS-TP-like traffic engineering tunnel (computed externally, not signaled through RSVP).

OpenFlow-created entries in the forwarding table are by definition temporary. They don’t appear in device configuration (and are probably fun to troubleshoot because they only appear in the forwarding table) and are lost on device reload or link loss.

Can we do it without NETCONF?

Given all of the above, can we implement SDN networks without NETCONF? Of course we can assuming we go down the OpenFlow-only route, but not many users or vendors considering OpenFlow are willing to do that (Google being one of the exceptions); most of them would like to retain the field-proven smarts of their networking devices and augment them with additional functionality configured through OpenFlow. In a real-life network, we will thus need both NETCONF to configure the existing software running in networking devices (hopefully through standardized messages in the not-too-distant future), and potentially OpenFlow to add new functionality where needed.