SDN and OpenFlow are not Interchangeable

I think it merits repeating that SDN has a 'whole bag of tricks', utilizing multiple southbound APIs all at the same time. It's actually the blending and layering of many technologies all at once that makes SDN applications such a compelling goal. It's about the integration.. As you mention so well.. OpenFlow is just one of the possible southbound APIs. iControl is one of them too... when needed. The important part is the stress SDN has made on the networking world to fix their management and control planes. It will force the vendors who want to provide complex network behaviours to work on their APIs to meet the applications demands. Haven't seen a networking vendor being accused of having a great northbound API yet. Even our beloved iControl (I'll wager the best in the ADC market) provides only object based methods, lacks search and filtering syntax, and doesn't represent the full breath of f5 modules. All things we are working on with iControl ReST and BIG-IQ. Would we be working so hard if they world had not stated that the API to our management plane was 'good enough'? Thank the SDN push for that.

 

 

As an example of the power of SDN, the default OpenStack OVS plugin, in response to cloud management platform messages, uses ovsdb agents to configure the switches (with overlay tunnelling your network topology changes everytime a tenant adds a network and plugs in a guest VM port to a network) and then OpenFlow agents are used to inject flows (at both network creation time and every time a guest VM is created on a compute node) which form a creative mesh of MAC based security rules and forwarding flows eventually pushing the frames into a more standard dynamic MAC learning bridge adjacent to the guest VM. There is no flood to controller once the provisioning is done, because the controller is a 'canned application' in the core OVS plugin. Make no mistake.. it's SDN to the core!

 

 

For the above example, SDN builds the ports, SDN builds the security flow rules, and then SDN forwards frames to standard flooding based Ethernet switching which we know works with the guests. None of these stages has to be "all things to all networks", but when they are "flowed" together, we have a ton of functionality and scale. SDN allows you to layer your design for the specific application needs (in this case OpenStack L2 tenant defined networks). Vertically integrated network stacks hide all the layers and you live with the limitations of the weakest link. The virtually integrated stack states..."you'll accept the networking you get and like it"... the SDN controller says "I'll layer your a solution across network functions to scales and responds the way your application needs it." Granted 'what you get' from the virtually integrated network devices has been flexible enough to get us here, but now it is time to let the application designers work through the networking models they need.

 

 

With this layered based SDN approach, the silicon based wonders in the network can still be used for what they do best, using their management protocol, and then further nuanced based flows, when required, get pushed to clusters of the "monsters of compute" we call servers (or VIPRIONs!!). That's why SDN is mentioned a ton with NVF. The magic is the SDN application looks like a vertical network stack from the deployed application's perspective, but one that does exactly what it wants.

 

 

Just a point of clarity... OpenFlow supports L4 tp_src and tc_dst matching with masks to push/pop flows to the next hop. The real limitation of OpenFlow is it is point-to-point.. as it is supposed to be. You might cripple the capacity of a current generation merchant silicon TOR switch by using matching rules for fields deeper in the frame, but that's the fun you push out and do on the clustered server side. We need to recognize that the switch silicon is rising to meet the market too.. at a price. So too is the server's network silicon getting smarter. All the core networking gear has to do is pass out the flows with the best data it can for an application. For most of that work, you can priori inject a base set of flows policies which are as good if not better than what we were doing with flooding in Ethernet switches today.