SDN expands the realm of possibilities for cloud networking and, per my earlier blog, there are many ways to address current and future network limitations. When considering an SDN solution, you should be clear on what problem you are trying to solve and over which period of time you will roll out your SDN solution. Since this is an emerging market and many players and solutions are first generation, you should also assess the level of risk you and your organization are willing to assume.  Regardless of the use cases you have in mind, I will discuss in my next blogs and this one a few major criteria to consider when defining your SDN strategy and selecting your vendors, with the first of them being going or not with OpenFlow.

Many companies are working together around OpenFlow to standardize SDN but not all these companies are implementing it today.

Some consider OpenFlow not mature enough. Indeed this standard is the most common denominator among the set of features supported by forwarding planes and different vendors. If some vendors want to innovate further than traditional networking features, this could be limiting. An option would be to use OpenFlow extension field where each vendor can exchange information between the forwarding devices and the controller and another option would be to create one’s own protocol as a complement or replacement for OpenFlow. For instance, NEC has opted for the former option; following the OpenFlow standard (OpenFlow v1.0) and leveraging the extension field for unsupported functions like IPv6 (only coming with OpenFlow 1.2 and 1.3 versions). While Cisco seems to be doing the later; OpenFlow enhanced by the proprietary OnePK protocol for functions specific to their forwarding plan.

The table below summarizes the current support for a few selected representative companies. While most incumbents support OpenFlow, start-ups are equally split between OpenFlow and proprietary protocols. As the technology matures and new versions of the OpenFlow standard are released, we should expect more players supporting OpenFlow. Players with the most significant market share (Cisco, Juniper, VMware) are trying to retain control with the promotion of their proprietary protocol in parallel of OpenFlow support.

Vendor specific interfaces may become successful if the associated forwarding plane (switch) or the integrated end-to-end solutions gain enough market share or address the needs of a broad enough installed base. For instance, in Table 1, players leaning towards vendor-specific interfaces are incumbents with a large market share (Cisco, Juniper, VMWare) or players targeting a large installed base (Anuta only supports Juniper, Cisco and VMWare environments) or players offering their own forwarding plane (Plexxi, Midokura) for an integrated solution.

Table 1 – OpenFlow or vendor specific support

 Understanding vendor dynamics and logic around their OpenFlow offering should help you make informed decision for your SDN strategy.

In the long run, OpenFlow support should be in the best interest of customers as:

• It enables multivendor environments. It is always a good thing to keep the option of having several vendors in your network or of switching vendor later down the road if needed.
• It also offers a nice horizontal architecture for your network to evolve separating the hardware platform from the applications.

This said, taking advantage of this flexibility by selecting the best of breed vendors comes with a price. You will have to ensure interoperability between your selected vendors and that may require some integration work for features beyond OpenFlow.

Now if you have (or plan to have) OpenFlow-enabled platforms in your existing network from different vendors and/or have significant software development resources (like Google or Indiana University), the integration investment may very well be worth it and you will end up with a better customized solution and a real competitive differentiator.

If the solution you need today does not support OpenFlow, you should make sure to understand when it is scheduled on the roadmap, and how easily it will be added later on as well as the level of prioritization for your vendor.

In the short term and especially if you are deploying SDN in a greenfield environment or as a new extension of your network (e.g. new data center), you may decide to let go the OpenFlow criteria. Several useful applications have been developed by start-ups without OpenFlow. This was a conscious choice so their R&D resources could focus more on the logic and application above the forwarding plane than keeping up with the different OpenFlow versions.  If you are going down this path:

• There are many solutions available today without OpenFlow. So if you find an SDN solution addressing your main pain point (e.g. VM migration, tapping, simplified network operations, traffic engineering, device management or else) and need it urgently, this is probably the best way to go.
• The deployment should be fast and easy since it is contained and vertically integrated (i.e. same vendor for the physical or virtual switch, controller and even some applications).
• But adding more solutions later on will mean adding different vendors (e.g. for firewall, load balancer, data traffic analysis etc.) and this may not be as straightforward. Since OpenFlow is not supported, you will have to make sure that your vendors will collaborate around integration and interoperability testing.

Finally there are use cases where the OpenFlow criteria is not relevant, for instance,

• When looking at L4-7 network services only comparable to what Embrane offers, or
• When directly integrating at the cloud management layer like Lyatiss, or
• With a Network-As-A-Service subscription like what Pertino offers.

I have tried to summarize my point in this table but keep in mind that this is very generic. It is meant to help your thought process but has to be put in perspective. There are exceptions. For instance, a vendor that integrates with Cisco and VMware proprietary APIs would fit very well for an existing network and would require minimum integration cost without support of OpenFlow.

I will discuss other aspects you should consider in your SDN strategy, but please feel free to share your thoughts with me posting a comment or sending it to info@sdneasy.com