Myth: SDN is OpenFlow

Despite the fact that the Software Defined Networking paradigm has been around for a while now, the belief that SDN is OpenFlow is still often heard in the networking industry. This belief also often leads to the impression that the prevailing business case behind SDN is reduction of hardware spending because white box switches are cheaper than investing into purpose built network devices and switches from vendor X. While the business case is valid, it is not the only business case behind SDN. In fact, at the time of writing, it may not even be the prevailing business case in the market.

The Software Defined Networking paradigm spun up several subset paradigms like Software Defined Data Centre, Software Defined WAN, Software Defined LAN and others. These subset paradigms seemed to have moved away from the original white box switch business case. Instead, they seem to have asked the question about what the actual challanges with today’s networks were, picked one and solved it using the four out of five tenants of SDN:

  1. SDx should be directly programmable through APIs
  2. SDx should be agile, meaning that if the underlying network topology or devices change, the system behaviour should not change
  3. Centrally managed
  4. Programmatically configured, meaning that all the configuration changes are done automatically, without the need for a network admin to reconfigure the devices
  5. Open standards and vendor neutral — meaning the system should support swapping devices from one vendor for another one.

Tenant number 5 seems to be the problematic one. For example, some of the more successful Software Defined Data Centre solutions currently in the market, like Cisco APIC or VMware NSX, seem to have steered away from OpenFlow altogether and are using their own protocols instead. So much for white box switches and multi-vendor deployments. Instead of reducing capital investments in hardware, these solutions focus on something else instead. For example, the challenge with large Data Centre networks is that VLAN management is a complex and a tedious task. A SD-DC solution takes this pain away and does it for you.

Another example is traffic engineering across several WAN links. Having to manually configure devices in the path every time a traffic pattern or topology changes is an unimaginable task. So an SD-WAN solution takes away this pain and does it for you.

The third example is SD-LAN, which covers both LAN and wireless LAN. Having to handle traffic paths in case of failures or RF environment changes, segment user traffic and define traffic policy rules for each port a user can connect to can present quite a challenge. Traditionally, these issues were partially addressed by centralising traffic flows, leading to a single touch point. This also led to bottle necks and required constant investment to improve the central infrastrcuture. SD-LAN solution takes this pain away and does it for you at the edge of the network.

There is obviously more to SDN than OpenFlow and white box switches. Sure, in an ideal world the open networking paradigm would immediately replace the way we do networking today and open standards would replace proprietary solutions. OpenFlow and whitebox switches are a possible way down that path, but it means we would immediately need to replace the whole networking infrastructure to support it. Until the time when OpenFlow protocol evolves and becomes one of the standard features supported by all network devices, the market will probably keep adopting the SDN subsets like SD-WAN, SD-LAN, SD-DC and others. Why? Because they are solving real-life problems now and not supporting open standards and being vendor neutral is a small price to pay.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.