Most SDN OpEx benefits can be realized by automating existing use cases, Cisco says

As Senior Director of Technical Marketing and Solutions Engineering at Cisco, Frank D’Agostino leads the development and technical go-to-market strategy for Cisco’s Application Centric Infrastructure (ACI), the company’s portfolio of Software Defined Networking tools. Network World Editor in Chief John Dix recently spoke with D’Agostino about what the company is learning as customers adopt SDN. (D’Agostino was formerly VP of WW Technical Operations for Nicira Networks, the company VMware bought to drive its SDN strategy.)

Is there a profile emerging of what a typical ACI customer looks like in terms of the types of challenges they’re trying to address?

Clearly ACI is gaining traction and significant visibility in the industry. We have more than 585 companies that have adopted ACI and more than 2,650 are ACI-ready with Nexus 9K deployments. ACI is being adopted across all market segments, which include cloud providers, large enterprises, commercial, and public sector. Customers want cost-effective networks that are open, application relevant, and support all physical and virtual application delivery platforms in an automated model.

I think a lot of it has to do with, one, we’re a better network, two, we can be application relevant, and three, we’re allowing integration in an open way without limiting innovation. We’re actually allowing vendors that might be competitors in certain market segments to integrate into the operations model, and really it’s a win-win for customers as well as vendors and I think that is why we’re seeing such wide adoption.

People just want a better network that is automated, that has visibility and delivers all the “ity” words, if you will — scalability, flexibility and agility. The key thing is to not overthink the rich capabilities of ACI and miss out on the immediate benefits of automation and visibility. About 80% of the operation savings come from enabling four basic functions:

• Automating network connectivity, whether it’s a virtual NIC on a VM, whether it’s a physical port on a bare metal device or a switch, or a VLAN interface that we’ve carved out to be logically independent or secured off for one customer. Automating that basic connectivity is step one.
• Next customers want to remove the access control lists they have on each device and move the rules up into a profile that can be deployed automatically with the APIC controller. We enable at every port a distributed stateless firewall that runs at wire rate depending on the profile configuration. Moving ACL’s from devices to profiles immediately enables the agility and allows the security profile to move wherever you enable the workload or service chain.
• Application service chains can be complex and there are a number of physical and virtual devices that have implications for security and policy. Policy isn’t all within one device. It’s actually relevant everywhere the application is enabled, and Layer 4 – 7 services can be enabled anywhere in the fabric. This means that security doesn’t stop as traffic egresses a hypervisor. Security must be relevant and implemented at every hop as you direct traffic between two application endpoints whether physical or virtual, RedHat, Xen, Microsoft, VMware, Linux container, or whatever.
• And the last one is in an SDN context, where you’re enabling overlays and want to be able to turn on monitoring at every point in the network, so you have a relevant monitoring capability as well as security.

Most customers have about 5% or less of basic connectivity automated. Customers can realize 70%-80% of the OpEx benefits by automating existing use cases as opposed to waiting to get into real deep granular policy. Policy will evolve from automating existing use cases to application models. So what I’m basically telling customers is don’t overthink all the capabilities. Focus on automating existing use cases. Maximize the automation benefits, maximize the visibility and the security, and once you understand what the models are for deploying automation, then move to a more application-driven, cloud-centric, DevOps model.

So we see both enterprise customers as well as cloud providers pursuing a crawl, walk, run model, automating existing use cases and then moving on.

Is there one use case that jumps out as being particularly sensible?

The big one, quite honestly, has to do with security. Everybody is afraid of touching security rules on a device-by-device basis, and that is one of the things limiting agility. VMs come in, or Linux containers come in, or you have a mix of Microsoft and VMware or Red Hat or Xen, and you want repeatability. This is tough given the complexity, so you want to use profiles, you want to get hands out of the operation so there are no keyboard errors, and you want to have security regardless of where the service needs to be turned up and do it automatically.

Does the adoption of container technologies complicate the picture at all?

No, I think it expands ACI’s value. Consistent policies can be applied across the board, further simplifying infrastructure and accelerating a customer’s ability to choose the best application delivery platform without sacrificing automation, policy and visibility. Application services can be chained with any delivery platform, and it shows why a model like ACI is much better than the first-generation SDN LAN emulation controllers.

Leveraging eVPN for VXLAN provides an open standard way of connecting multiple SDN & ACI domains, enabling multiple vendors to drive their own innovations without being limited by the controller of one vendor. Customers use well-known protocols already enabled in networks, like BGP, and connect SDN domains just as they do autonomous systems in the Internet today.

This removes the requirement to conform to a restrictive spec based on an imperative model, like forcing the controller to be in lockstep with the VXLAN Tunnel End Point (VTEP). The future is where application deployments express intent in a declarative model, thus enabling the Linux containers along side Red Hat today, Xen tomorrow, Microsoft the next day, and some combination thereof, including VMware.

Are you seeing customers shifting to containers?

Absolutely. In fact, that’s one of the largest shifts that I see, and we have whole cloud deployments that are going in with no x86 virtualization whatsoever. It’s all container based.

What kind of change have you seen early adopters make based on ACI capabilities?

There are a number of interesting shifts. Network teams realize they are the ones that must securely manage every endpoint of an application service chain. Applications dynamically enabled over multi-pathing in the fabric, with disparate devices supporting different functions, require rich expertise today shared by three teams in the data center – application, security and network. Network teams become more valuable to the organization, to the application teams, when it comes to capacity planning and control and monitoring and troubleshooting.

Everything in the chain is an application delivery point, in some sense. So whether it’s a hypervisor or a VM or a security application or device, operations develop a model to automate delivery of functions horizontally and that one of the larger transitions that happens. And that’s where the majority of the gains are. That’s why crawl, walk, run. Build an automation model that makes sense, simplify security, simplify the repeatable tasks, get the great OpEx benefits and then expand beyond there.

In terms of the crawl aspect, where are customers starting, with a particular application or a certain domain or what?

It varies. Some customers are going all in and building new data centers and supporting this from day one. Other customers are trying to integrate it into the existing infrastructure. If, for example, they have Layer 2 services they want to extend up into a Layer 3 switching or routed point, and then extend the automation and visibility capabilities down into existing domains, they can take their existing VLAN configuration and move that into a Layer 2 bridge domain and then ACI lets them extend profiles and security roles down into those domains.

In other cases we see customers building a pod and moving connectivity over to the pod and then start migrating services. But the ones that seem to be moving the fastest are the ones that are looking at their existing use cases, simplifying security and driving automation.

Do you see companies making any organizational changes when they adopt ACI?

We’ve been used to a cadence of software delivery measured in multiple months, whether it’s three months or six months.   Even in parts of the industry that are claiming to be software only and innovating fast, we still see the three to six month range.

Customers are really getting into the idea of continuous integration. But continuous integration, with code drops every four weeks, new features or functions being brought in, requires very consistent policies and lots of visibility into the network. It’s nothing new. I still turn on a port, I still enable a service, I still connect to a security device or enable a security profile, but the cadence and the frequency are changing, which is forcing the organization to move faster.

Customers are demanding a move to automated models connecting multiple functions from multiple vendors, but doing it in a way where they’re not being limited by one vendor or another. Open choice and automation is really about bringing in any vendor you want, allowing them to maximize their value and not being limited to the lowest common denominator set of features. I think the cadence and how you absorb the complexity and all the change in the application chain is really where the big shift is happening.

How have you had to tweak ACI as you started to gain real world experience?

All products evolve over time. All of the architecture elements we’ve developed and are marketing around ACI — EVPN leaving the platform, all of the group based policy being moved into Open Stack and now being up-streamed into Linux, the publishing of the APIs, making OpFlex completely open to any vendor (including third-party switch vendors) — all of that has evolved. It’s the maturation of an architecture driving functions based on wide-scale customer production deployments driving features, timelines, and scale requirements.

Can you quantify the acceptance of OpFlex at all?

There are more than 35 ecosystem partners driving OpFlex, so there’s been a lot of work going on in that area. You can see why some third-party hardware switch vendors may be hesitant about doing integration, but it’s totally open and published. The benefit to everybody that’s participating is OpFlex is it is a declarative southbound protocol, and that basically means we’re declaring that we want you to do this function. Please turn on something or please do something to the greatest of your capacity. It doesn’t say you have to be blue, red or green.

As an example, John, you might be able to bench press 1,000 pounds and I can bench press 500. Well, if I’m the controller you shouldn’t be limited to benching 500 because that’s my limit. I should be able to say to you, “John, lift the maximum weight you can.” That’s what we’ve done with OpFlex and that’s what’s really driving this declarative model. It gives all of the vendors a tremendous advantage.

In fact, as you look across the vendors that are part of the ecosystem, you’ll see we have competitors that realize the value of being part of the model. Shame on Cisco if we can’t win every market segment we’re in for every customer, but the reality is that happens and if our model allows competitors to innovate, that basically allows the customer to get the benefits of the automation model they’re looking for.

Speaking of competitors, you mentioned that security is a compelling use case, and VMware is finding that too. Does that surprise you at all?

VMware prefaces conversations about security with “… in an all virtual environment.” As everybody knows, in real world environments application service chains contain a mix of heterogeneous devices and lots of different platforms, physical and virtual, from many different vendors in a range of topologies.

While there are a lot of OS instances being virtualized, all packets egress the hypervisor and at that point VMware has zero relevance to security. The thing people need to understand is that security is applied at every place in the network across multiple vendors and it needs to be done in a way that’s driven through centralized policy and automation, whether the endpoints are physical or virtual, and that is something VMware is not addressing.

VMware needed a way to move the conversation beyond basic functions of networking because they struggled to implement and get good traction with our customer base, and so they’re leveraging micro-segmentation and security. VMware is the only hypervisor vendor restricting who has access to their APIs and who can innovate in their platform, an effort to control that part of the market.

How is competition with NSX going?

Keep in mind NSX is an application, not a network. Customers must buy a network for NSX to operate in a network and every customer is buying hardware VTEP’s for SDN. ACI supports NSX as an application better than any other network in the industry, so it’s not an either/or. NSX doesn’t provide SDN for all interfaces, even on their own hypervisor, so we can show customers why they don’t necessarily need it, but it is the customer choice and we enable customers, not limit them.

There are also some marketing charades going on relative to what is open and what isn’t. NSX is an open-by-invitation-only platform, and what I mean by that is, if you have an SDN LAN emulation controller like NSX, they require a tight coupling between the controller application itself and whatever the endpoint is that’s doing the tunnel termination. Customers have long delays waiting for VMware to deliver features as proprietary extensions beyond the limits of OVSDB schema available in the market. VMware requires you to register in their lab, wait for their engineers to work on any development or scale testing, which they prioritize and resource. There is nothing about this that is open.

It really seems like an unlikely stance for VMware given the Nicira roots, which had a lot of contributors, and in fact even built the first Xen DVS and Open vSwitch. OVS is not supported in VMware, at least in the current NSX release.

Looking deeper, VMware restricts which versions of products they support versus others. So they just published vSphere 6 KB and VMware does not support the Nexus 1000V application virtual switch mode in vSphere 6 or any other version. And if you contrast that to what Cisco is doing by fully publishing all of the interfaces and the APIs and allowing anybody to integrate, you start getting some clarity around exactly what VMware is doing relative to creating a closed platform where they try and control the integration.

This is why customers are trying to break this model and move to an environment where you interconnect multiple domains in an open way, leveraging protocols like EVPN as a control plane for VXLAN, and then you can call directly into a master platform. And the nice thing about this for everybody is that if the customer loves NSX or they love Nuage or they love HP or Cisco or anybody else, they can have it, but they no longer have to be locked into these proprietary models.

The largest customers that have deployed SDN are moving to this model and away from the first generation lock-in of SDN LAN emulation controllers.

Isn’t it easier for VMware to get SDN going, though?

NSX obviously has dependencies on hypervisors, and there are a lot of functions a hypervisor can implement. So they have the VMs themselves, and the vNICs, and there’s also a management interface and an interface for IP storage and vMotion and applications, etc. But as customers start deploying these models they realize that the only SDN that’s provided by VMware is for the data interfaces and vNICs. They leave out vMotion, they leave out the management network. And so customers pursuing a VMware SDN find they have one-third of a strategy, but all the rest of the interfaces are left out. And as customers realize these implementation issues, they start asking themselves, “Why am I doing this in the hypervisor in the first place?”

How would you classify where we are in terms of SDN acceptance at this point? Obviously it’s still the early stages, but what does the acceptance curve look like?

I think the vendor wars are still causing confusion for customers and, being a vendor, we’re part of that, of course. However, I will tell you that based on the number of RFPs and the exchanges I’m having with customers, everyone wants automation, SDN security and visibility. And you can tell by some of the growth numbers we’ve been reporting that the uptake is significant. I wouldn’t say it’s a slow start. I think it’s the way all networks are going to be built moving forward and I think Cisco obviously is looking at a clear leadership position.

So RFPs are coming in that require the basic control of SDN, but when would you expect SDN to really hit its stride?

We’re squarely in the middle of it now. You’ve seen the revenue we’ve had over a number of quarters and the growth. All networks from Cisco now are programmable, they expose and completely open the APIs and they allow you to take advantage of things like VXLAN and programmability and automation, so this is just a basic function of all networking from Cisco moving forward.

It’s not another segment or a certain part of the market or a trend. It’s just a basic feature or functions of all networks moving forward. That’s why the industry is moving past the first generation SDN LAN emulation controllers because every merchant silicon ASIC today has 70%-90% of those original use cases built in, and that’s another reason why you see vendors like VMware moving beyond a basic value prop and trying to tell a different story.

The last question here, what changes with SDN going forward?

I think there are a few things. Customers have a large amount of infrastructure in the data center, where we squarely started, but this group-based policy model can extend to all points in the network, including the campus and the wide area and the branch.

We’re seeing an open environment accelerating around SDN. Common group-based policy models extend from controllers inside a data center to multiple domains, whether it’s into the campus, into the wide area or into a branch or virtual branch. Customers are starting to drive SDN across to all endpoints of the infrastructure with an automation model that that’s under a common controller architecture or a federated controller architecture, that’s where I see the big shift moving forward.