3 Reasons to Resist the Urge to Abandon OpenFlow
By 2018, the market for software defined networking (SDN) will reach over $3.5 billion, giving communications service providers (CSPs) plenty of opportunities to carve out new revenue streams. There’s only one problem—SDN is currently experiencing an identity crisis.
The dream of SDN stems from a dire need of an industry – centralized real-time control of a multi-vendor network. As it currently stands today, SDN is not being utilized as it was originally promised. What was supposed to deliver a programmable data path and configuration capabilities via a programmatic interface has been ‘downgraded’ to a simpler centralized management architecture. At the heart of this conflict are the protocols that enable such functionality.
The question is, why is the industry so quick to dismiss the OpenFlow model? Realizing the ‘dream’ will require a lot of work from everyone involved: the hardware vendors, the software vendors, the orchestrators and the customers themselves. Why agree in advance to a downgraded version of SDN which will limit functionality and only minimally improve the situation? If we limit ourselves, the situation will improve only marginally and everyone but the customer will benefit.
In ECI’s opinion, OpenFlow comes closest to enabling the realization of SDN in its widest and purest form. In order to realize the true promise of SDN, you should resist the urge to abandon OpenFlow. Here are three main reasons why you shouldn’t give up on OpenFlow:
1. The Clear Value of a Programmable Data Path
Since its proposal in 2009, OpenFlow is currently the only open protocol that enables a programmable data path between the control and forwarding layers of an SDN architecture. The industry might be looking for ways to abandon OpenFlow, but there are external indications that customers want the programmatic interface that the protocol offers.
Even before the Open Networking Foundation established OpenFlow, Cisco released the onePK solution. Essentially, Cisco onePK offered a programmatic interface within a “closed garden” of Cisco infrastructure. This solution took off as customers demanded the programmable data path and customizable network behavior within their Cisco environments.
Cisco later released the Application Centric Infrastructure (ACI) in response to OpenFlow, but the effect remains the same. If customers find value in a closed garden programmatic interface solution, then an open solution with OpenFlow is immensely valuable.
2. Management/Configuration Protocols Don’t Provide Programmatic Interfaces
When evaluating management protocols versus OpenFlow, you must ask, “can you change the behavior of the network even without all devices supporting the required behavior?”
Under the currently preferred more ‘management-centric’ protocols, behavior is determined by the device itself and is not programmable. As a result, all network behavior is limited by the lowest common denominator. If you’re trying to do segment routing, every device in the network must support segment routing or else the end-to-end chain will be compromised.
OpenFlow, on the other hand, functions on a priori data model with a set of predefined features. Even if certain devices aren’t in your network yet, you can create network behavior rules that will ultimately help you break down walled gardens and fulfill SDN openness.
3. OpenFlow’s Reactive Mode Is Essential for Some SDN Use Cases
OpenFlow’s standard reactive mode has been questioned. While the protocol may not be perfect, there are certain use cases that show why the reactive mode is necessary.
One use case where OpenFlow’s reactive mode is essential is NFV fast path offloading. In security and traffic analysis applications relying on deep packet inspection, packets must be analyzed without latency. With reactive mode, specific frames can be sent to the SDN controller where rules are determined and applied. Management protocols don’t offer this kind of flexibility.
Blackholing also exhibits the need for OpenFlow’s reactive mode. When there are configuration mismatches and flow table corruption, frames that don’t have corresponding rules are often dropped by proactive models. In reactive mode, these frames are sent to the SDN controller for definition, reducing the number of frames that timeout. Even in the case of dropped frames, OpenFlow enables engineers to monitor any problems.
Without OpenFlow, these and other issues will not be dealt with properly.
Stay Persistent, Go with OpenFlow
It would be naive to say that OpenFlow is perfect. The industry isn’t completely wrong in some of the issues that have been raised, but in ECI’s opinion, companies are abandoning the protocol much too early. Rather than degrading the definition of SDN, ECI believes, that OpenFlow offers the best chance of effectively delivering the promise of SDN.
If you want to learn more about why you shouldn’t abandon OpenFlow, download our latest free white paper, Don’t Give Up on OpenFlow Just Yet, for more information.