Core differentiator between SDN controllers

Although the SDN concept is still young and it is still within the hype, as you realized there are multiple SDN controllers and platforms available on the market. The available solutions in the market have different features and capabilities, which you need to understand before deciding on which controller or platform to choose and build your network on it. There are also products that use the marketing buzz words of SDN and try to pitch a legacy solution, which you need to be careful while evaluating them.

I have collected some key differentiators of SDN platforms and will take you through each as follows:

• Fabric or overlay: This is one of the most important attributes to look at and make the decision. Overlays are also considered as key drivers for network virtualization. Overlays are not dependent on underlay networks, meaning an overlay SDN can build an overlay SDN on top of a mesh IP underlay. Looking at SDN products in the market, some of them are basically an overlay, such as VMware NSX and Juniper Contrail. On the other hand the SDN fabric products are a full SDN aware underlay, which means that the SDN controller can communicate with all SDN switches in the network and control and program their flow and CAM tables. Solutions such as Cisco ACI and OpenDaylight are examples of a full fabric SDN platform.
• Open source versus proprietary: This attribute should only be important if you are considering extending the controller or have proprietary modifications specific to your business. In general and based on our studies, service providers are more interested in open source solutions as they use their tools and resources to productize and provide an SDN as a service to their customers. AT&T and NTT are good examples of service providers who took OpenDaylight and build their offerings based on that.

On the other hand, enterprises are interested in commercial and business supported products with specific SLA and support levels. Enterprises use SDN to run their business better. They are not interested to downgrade their network from a legacy L2/L3 to an SDN platform with no business case. Based on our studies, many enterprises have looked at and adopted Cisco ACI, VMWare NSX, and Big Switch Big Cloud Fabric, which are good commercial SDN platforms. When looking at commercial products, you need to always be careful about the vendor lock-in and find a solution that lets you scale and expand or even change your controller without impacting the switches in the network.

Openness in the SDN platform doesn't mean that you will be supported by the community. Commercial SDN controllers are based on OpenDaylight and are supported by companies such as Brocade and they are all open source as well as commercially supported.

• Application ecosystem and maturity of northbound APIs: SDN don't forget that an SDN platform doesn't work without SDN applications. SDN controller is a platform to run SDN applications. Without SDN applications the network doesn't forward any packet. A very basic SDN application is L2 switching, where you need to load and run the L2 application on a controller in order to have the very basic L2 switching (MAC learning) on your network. This may seem funny for some readers that the SDN has no built-in features; however, you should think that SDN is a methodology; it's a platform that allows you to build network applications and decide how you want the network to forward, route, or drop the packets.

Going back to our topic, while looking for an SDN solution you should consider choosing a SDN controller that provides a rich, complete, and developer friendly application environment. Many SDN platforms support Yet Another Next Generation (YANG) language, which is used for data modeling and also it is used as payload for NETCONF protocol.

• Where to deploy: You should consider your main use cases and compare against the capabilities and features of the SDN controllers in the market. For example, a controller designed for a campus network is not a good fit for a data center application. Or an SDN platform that doesn't have any plugin or capability to integrate with OpenStack is not a good fit for deploying in a OpenStack environment.

You should take into consideration your business use cases to find the best fit platform and controller for your business.

• Compatibility, reliability, and maturity of the platform: Although the SDN platform is a game changer in networking world, but it is still in its early stages and it's hard to find a solution that is deployed and worked for couple to years or find strong case studies. This is one of the key show stoppers for many enterprises trying to find a SDN solution that has a proven track record and has been deployed with multiple clients. CIOs and procurement look for proven solutions that have been used or certified.

Even standard protocols such as OpenFlow or OVSDB have different implementation between vendors and they might not be compatible with each other (for example, an OpenFlow switch from vendor A may not be compatible with an SDN controller from vendor B). These are challenges that require your attention prior to deciding which SDN platform you are going to live with.

• Smoothness of integration into orchestration platforms: Almost every commercial controller and many open source controllers provide OpenStack support in the data center. If you have a data center deployment and have picked a specific cloud management or orchestration platform (OpenStack, VMware vRealize, CloudStack, or others), check with the vendor or evaluate the open source distribution to ensure seamless integration into your orchestration environment.
• Integration with cloud and orchestration platforms: Nowadays almost every private cloud platform is built on VMware or some flavor of OpenStack or CloudStack. The SDN platform in data centers needs to integrate with OpenStack of VMware vSphere, and you need to check and ensure the level of integration and capabilities of the SDN solution with your choice of orchestration platform. Normally in data center environments, the SDN platforms provide direct integration with VMware vSphere and the SDN solution becomes part of the VMware virtual network and virtual distributed switches. The same applies to OpenStack and SDN solutions that will integrate with OpenStack via some kind of plugin (such as ML2 or other kinds of integrations).

If you are planning your SDN platform for a campus topology you need to check with your orchestration and policy tool about the integration with the SDN platform. Many SDN platforms provide such orchestration and tools along with their products; however, if you are using a specific orchestration tool you need to ensure how it is going to integrate with your SDN platform.

• Open APIs: Regardless of being open source of a proprietary closed source solution, you need to ensure that the SDN platform provides some kind of open APIs for integration with other tools. Other tools such as monitoring, orchestration tools, billing, abstract UIs, compute and storage tools, and so on. Normally APIs are not considered as a critical factor to make decisions and normally there is no day zero requirements for APIs, however, after deployment of the SDN platform slowly you will realize the requirement for integration with other systems. A very basic example is the cloud providers, where they need to have a single web interface for customers in order to create their tenant networks, subnets, and service insertion.
• A customer should be able to use the web interface of the platform to design and build his virtual network, add virtual routers, firewalls, and load balancers in their network while it is isolated and doesn't disturb other tenants or user traffic.

You should understand that the SDN market is still in its early stages. OpenDaylight has helped to change the landscape and also other open source projects such as ONOS OpenContrail and Calico which are mainly driving use cases is service provider networks.

You need to find the real need for going the SDN way and understand the capabilities of each SDN platform to make the correct decision. Remember in order to move to SDN you don't need to migrate everything and throw away your whole legacy network, No, you can build a SDN network for a POD (in a data center) or a building (in a campus) or a path (in a service provider).