When Open Networking Foundation claimed ownership of Software-Defined Networking, they defined it as separation of control and data plane:
[SDN is] The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.
Does this definition make sense or is it too limiting? Is there more to SDN? Would a broader scope make more sense?
A bit of a history
It’s worth looking at the founding members of ONF and their interests: most of them are large cloud providers looking for cheapest possible hardware, preferably using a standard API so it can be sourced from multiple suppliers, driving the prices even lower. Most of them are big enough to write their own control plane software (and Google already did).
A separation of control plane (running their own software) and data plane (implemented in a low-cost white-label switches) was exactly what they wanted to see, and the Stanford team working on OpenFlow provided the architectural framework they could use. No wonder ONF pushes this particular definition of SDN.
Meanwhile deep below the cloudy heights
I have yet to meet a customer (academics might be an exception) that would consider writing their own control-plane software; most of my customers aren’t anywhere close to writing an SDN application on top of a controller framework (Open Daylight, Cisco XNC or HP VAN SDN controller).
Buying a shrink-wrapped application bundled with commercial support might be a different story … but then nobody really cares whether such a solution uses OpenFlow or RFC 2549; the protocols and encapsulation mechanisms used within a controller-based network solution are often proprietary and thus hard to troubleshoot anyway.
On the other hand, I keep hearing about common themes:
- The need for faster, more standardized, and automated provisioning;
- The need for programmable network elements and vendor-neutral programming mechanisms (I’m looking at you, netmod working group);
- Centralized policies and decision making based on end-to-end visibility;
- Easier integration of network elements with orchestration and provisioning systems.
Will physical separation of control and forward plane solve any of these? It might, but there are numerous tools out there that can do the same without overhauling everything we’ve been doing in the last 30 years.
We don’t need the physical separation of control plane to solve our problems (although the ability to control individual forwarding entries does help) … and it will probably take a decade before we glimpse the promised savings of whitelabel switches and open-source software (even Greg Ferro stopped believing that).
Does it make sense to accept the definition of SDN that makes sense to ONF founding members but not to your environment? Shall we strive for a different definition of SDN or just move on, declare it as meaningless as the clouds, and focus on solving our problems? Would it be better to talk about NetOps? Share your thoughts in the comments.
Need more real-life skepticism?
The introduction to SDN, OpenFlow and NFV webinar on January 22nd will give you an overview of what SDN, OpenFlow and NFV are all about, and how you might use the three concepts in your next-generation networks (it might even change your mind and persuade you to write your first controller-based application ;).
NEC Corporation of America kindly decided to sponsor the webinar, making it free… but you still have to register to attend the live session.