Software Defined Networking: Now, Never, Don’t Know? Part 6

part 6 which vendorHaving covered the pros (part 4) and cons (part 5) of deploying SDN, for those deciding to embrace SDN there are still several obstacles to be overcome.

Which Vendor?

Probably the hardest decision is which vendor to select.  Given that the various SDN options are predominantly not inter-operable, the decision as to which vendor to select is a difficult one.  Given the ongoing battle for market share between the major players (Cisco ACI, VMware NSX, OpenFlow) it would be unfortunate to pick a vendor who loses the battle and whose product atrophies and whose support wanes.  It’s rather like the battle between competing video formats in the 1970s!

Given the proprietary nature of NSX and ACI, selecting either of these products implies vendor lock in whereas OpenFlow should offer broader vendor choices (although inter-vendor compatibility issues could still arise).

In terms of cost, Cisco ACI is the most expensive and has a very restricted set of supported hardware (currently just the Nexus 9000 and 7000) and software requirements (Cisco’s APIC) – this invariably implies an expensive network hardware overhaul as part of the SDN rollout.  VMware NSX is less expensive as is Juniper Contrail.  Solutions based on OpenFlow and Open-Contrail are far cheaper, but offer little support and the lack of enterprise-grade support may make these offerings unpalatable.

Which Architecture?

As discussed, the decision between overlay or underlay SDN is not a trivial one with implications for complexity, virtual / physical network separation, performance and security management, troubleshooting, etc. and obviously vendor.


One of the biggest obstacles to SDN deployment is the lack of maturity of any of the solutions.  Being new technologies, none of them have a proven track record and many enterprises are hesitant to gamble their production networks on such new technologies.  Furthermore the rapid, ongoing evolution of the standards and SDN controllers could require frequent upgrades to production networks which most are reluctant to embrace.  Given the newness of the SDN standards, the flux in the SDN controller market (especially for OpenFlow) most traditional network management vendors have yet to provide meaningful (if any) SDN support.  This is of particular concern for overlay SDN as, when the SDN controller reports that it has correctly configured a network path yet the applications are experiencing sporadic connectivity or performance problems, will network teams have the information they need to pinpoint and resolve the problems in a timely manner?  What are needed are network management systems which understand the physical and virtual infrastructure (including SDN) and can present a holistic end-to-end view.

Whilst immaturity of solutions and tools is an issue, it is a blocker that will dissipate as products mature over time.

SDN Applications

The lack of standardized northbound APIs is leading to the production of controller specific orchestration applications rather than applications decoupled from controller specifics.  Application developers are understandably reluctant to produce applications with multiple adaptors to interface with the many non-standard northbound APIs (for example, with OpenFlow there are many controllers – the most common being: OpenDaylight, OpenStack Neutron, Beacon, Floodlight, IBM PNC, etc.).  To obviate this obstacle the ONF is looking to standardize the northbound API.


There is fear that small scale proof of concepts which perform well might not behave equally well in large scale production deployments.  This is partly due to virtualized network functions running on hypervisors, virtual switches and VMs and being unable to attain the throughput of traditional dedicated hardware with custom ASICs.

Business Case

The lack of compelling business drivers (instead of business ‘nice-to-haves’) makes many of these obstacles show-stoppers, or at the very least, show-delayers!  Should compelling ‘must-have’ business reasons emerge, many of these obstacles could be mitigated, or the risk embraced.

Part seven in the series will cover implications of adopting SDN.



Share This