Another contribution we're making to the industry is around a southbound API called OpFlex. This protocol is going to play a key role in ACI architecture and we have recently proposed it to the IETF as a standard way to distribute declarative policies in a scalable way across any infrastructure. I don't know if you read a paper submitted on SDNCentral by Google where they talk about their policy model, but we are very pleased it's not just us that has seen the value of the declarative model.
NW: Can you spell out the difference between OpFlex and OpenFlow, OpenFlow being the widely embraced southbound API today.
SJ: OpFlex is going to enable us to push policies to the underlying infrastructure, whether that infrastructure is virtual, physical or Layer 4-7 devices. OpenFlow is basically an agent-driven technology that allows you to manage specific elements with an OpenFlow controller. It would not necessarily allow for a distributed policy approach because there is no policy language.
If you look at most production-worthy SDN controllers in the marketplace, they have gone above and beyond utilization of OpenFlow. They don't just allow for the two or three use cases OpenFlow supports. They go beyond that to add value. So our intent with OpFlex is to drive an industry-wide southbound interface so there is a standard way to distribute policy in a scalable manner across any infrastructure using a declarative policy model.
It is not a case of OpenFlow versus OpFlex. We support OpenFlow agents on our switches. We have been shipping those on our Nexus product portfolio for a long time. It is really driven by the use cases. So again, if I am a customer and perfectly satisfied with the one or two use cases OpenFlow supports, I may just stick with that.
NW: With the declarative model the controller declares what should happen but doesn't dictate what the network should do, is that right?
SJ: That's correct. It is not an imperative model. The declarative model assumes the controller is not the centralized brain of the entire system. It assumes the centralized policy manager will help you in the definition of policy, then push out the intelligence to the edges of the network and within the infrastructure so you can continue to innovate at the endpoint.
Let's take an example. If I am an F5 or a Citrix or a Palo Alto Networks or a hypervisor company, I want to continue to add value. I don't want a centralized controller to limit innovation at the endpoint. So a declarative model basically says that, using a centralized policy controller, you can define the policy centrally and push it out and the endpoint will have the intelligence to abide by that policy. They don't become dumb devices that stop functioning the normal way because the intelligence solely resides in the controller.
Sign up for CIO Asia eNewsletters.