Soni Jiandani is one of Cisco's serial entrepreneurs, having been a key member of the teams that developed everything from the Nexus 5000 to Cisco's Unified Computing System (which in five years has leapt to the top of the x86 blade server market in North America, according to IDC). Today Jiandani is Senior Vice President of Cisco's Insieme business unit, the group pushing the company's Software Defined Networking vision. Network World Editor in Chief John Dix caught with Jiandani to get her take on how SDN plays out.
NW: Why does the world need ACI?
SJ: What customers care about most are the apps that drive their businesses, and IT infrastructure today is doing a poor job of supporting those applications. With ACI we're meeting the needs of applications that require dynamic, agile, fast, secure, scalable, reliable infrastructure that can respond to automation.
NW: Since you folks built the majority of networks out there, is it a failing on Cisco's part to need to head off in this new direction? Why do we need to overhaul all these networks?
SJ: We don't view this as an overhauling. I think that's a perception the competition is driving. We have articulated crisply to customers, as recently as Cisco Live, that our strategy with ACI is to migrate them towards a more application-centric, policy-oriented environment that allows them not only to embrace the design principals and the benefits of SDN, but to go beyond that.
The evolution to the cloud, for example, is a natural part of our strategy. People see the cloud as a way to gain agility and flexibility. They don't want to worry about applications physically tethered to the infrastructure, to an IP network. They want abstraction and the ability to define a policy model, whether it is through the lens of the networking person in terms of subnets and VLANs and quality of service and security capabilities, through the lens of a cloud architect looking to deliver a service-oriented model to various organizations, or through the lens of an application team that wants to submit requirements to the underlying infrastructure. So the goal focuses on agility and flexibility without compromising security and reliability and openness. I think this is a natural progression our customers would expect from Cisco.
We are also taking an extremely proactive role in driving standardization and open source efforts through various contributions. For example the group policy model in OpenDaylight is going to offer the industry a new northbound API that is identical to our ACI policy model. A number of vendors, including Hewlett-Packard, IBM, Barracuda, Plexxi, Red Hat, are contributing to that effort. So we are extremely excited to see this develop into a broad multivendor ecosystem around our policy-driven approach.
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.
The issue with the imperative model is, what happens if the controller fails? If the controller fails, your devices are going to fall apart. The analogy we use is an air traffic controller. The air traffic controller says where planes go, and yet pilots fly the planes. So even if an air controller were to fail, the pilot would still be able to navigate the plane safely.
NW: How do you decide how much intelligence to distribute where?
SJ: We are not the ones to say what intelligence should be in a load balancer or application delivery controller. We leave that to the experts in those markets. We just have to make sure the models we are putting forth have the ability to deliver the services at scale in a secure and highly automated manner.
NW: Let's turn to the competition you're seeing from VMware. How would you classify the differences between ACI and NSX?
SJ: We have taken a holistic approach, thinking about the requirements not just for the network and its automation, but also the requirements of the applications. And where I think we have a clear advantage is we provide real time telemetry and visibility with a common operation model for your physical networks and your virtual networks, whereas in the case of NSX they require gateways, they require shim layers on third-party switches, they require separate operational silos for the physical world and the virtual world.
The minute you start to impose this level of complexity you're going to increase OpEx because the customer will need to operationalize a physical network and a virtual network separately and will have to manage the gateways that span the physical and the virtual.
Another area where we have a unique approach is a single pane of glass for third-party Layer 4-7 service vendors and automation and ecosystem integration, whereas NSX would require multiple consoles for third-party Layer 4-7 services automation because they themselves sell security services and compete with their ecosystem.
And last but not least, we have a far more superior total cost of ownership. We do not have a per virtual machine tax ranging from $10 per virtual machine per month to upwards of $15 or $20 per virtual machine per month. That, I think, is going to be a very expensive proposition for customers who are getting called upon to do that.
NW: Many people say the network overlay approach VMware advocates is easier to get going. Doesn't that give them a market opportunity, while your migration will take longer?
SJ: I believe that NSX's software overlay approach is going to be adding another layer of complexity without solving the holistic problem of how the customers will be able to more rapidly and cost-effectively deploy applications. It's easier said than done trying to overlay a network on top of an existing physical network. The operational challenges and complexity is far greater than meets the eye. And if this approach is such a big window of opportunity, then why hasn't NSX achieved any customer traction with seven years of existence? Where are the large production-worthy deployments of NSX? I haven't seen any.
NW: I don't know what you classify as big, but I talked to an NSX customer recently, WestJet, that was impressed by the technology.
SJ: Right. But for a product out there for seven years, I would expect more.
NW: Speaking of timeframes, how do you expect customers to adopt this stuff? How does it ramp?
SJ: We are already seeing a rapid adoption of the Nexus 9K and, with ACI products shipping at the end of this quarter, we have enabled both the standalone and ACI modes within the 9K. The underlying fabric and the hardware building blocks are identical. When you combine that with a growing ecosystem, it's going to make for a cohesive evolution for customers as they embrace it at their own pace.
So we are not going in and telling a customer, "By embracing the 9K you have ACI inserted into your data center." Quite the contrary. The 9K is enabling successful adoption of 10-Gig and 40-Gig in existing data centers. When customers are ready to adopt the ACI policy model on their investment they made with us five years ago, seven years ago, we will be able to push those policies out by merely upgrading their Nexus 9300 and deploying application-centric virtual switches in their hypervisor-centric environments.
NW: A lot of the SDN discussion has been around data center networks, but we're starting to hear more about wide area software-defined networks. What is your impression about how that will evolve?
SJ: I think that the next stop would be that, because customers expect this to be one network. The vision is to have a common application-centric policy model that delivers significant advantages across all parts of the network. After all, these policies are portable. You can ensure the same application behavior in any network can happen in a consistent manner by copying those application profiles. You can centrally manage these policies which eases auditing and compliance, so your compliance teams are coming to one place for auditing, to understand the state of the network. And you also make your IT resources more efficient when you achieve dynamic control driven by policies rather than hard-core reconfigurations.
NW: Are there any potential stumbling points for adoption?
SJ: It's all going to be in the execution. We have to keep an eye on the ball, stay close to customers and deliver kick-ass products for the wide market we serve.