It’s not that the emerging OpenFlow standard as a foundation for software-defined networking (SDN) isn’t technically viable; it’s just that it’s beside the point.
According to Prashant Gandhi, senior director of product management for the Cisco Server Access Group, that’s essentially the position that Cisco is adopting now that OpenStack, an emerging standard that provides a framework for IT organizations to manage cloud computing environments at a higher level of abstraction, is starting to gain traction.
The company, this week at the OpenStack Summit 2012 conference, released Cisco Edition for OpenStack, a set of tools for automating the deployment of OpenStack-compatible cloud computing frameworks in Cisco networking environments. Gandhi says while companies will compete over who can deliver the best management applications on top of the OpenStack framework, the existence of the framework itself will address most interoperability concerns related to switching. This is because switches based on either proprietary Cisco SDN technology or OpenFlow SDN will support the OpenStack APIs. Customers will be able to manage switches from multiple vendors within the context of an OpenStack management application, says Gandhi.
While supporters of OpenFlow are making a case that OpenFlow makes it easier to replace one switch vendor with another, Gandhi notes that given the fact that most customers only replace their switches once every three to five years, the real issue as far as the customer is concerned is interoperability between switching fabrics. For that reason, Cisco’s primary focus is going to be on an OpenStack framework to provide that interoperability at a higher level of abstraction than OpenFlow, says Gandhi.
Gandhi says Cisco is adamant that developers in particular will want to have access to features that for some time to come are only going to be available via a Cisco proprietary SDN. Nothing against OpenFlow directly, says Gandhi, but it will take an OpenFlow vendor consortium years to match the capabilities that customers have access to in a Cisco SDN. In the meantime, via OpenStack, Cisco will give customers the ability to manipulate just about any hypervisor or virtual switch that they care to use.
The ultimate goal, says Gandhi, is to give developers the ability to override the network control plane to allow applications to invoke specific network routes to customize the network controller. Both Cisco and OpenFlow APIs will allow developers to accomplish that task. The question, says Gandhi, is which approach will provide the richest, simplest way of actually doing that.