As Senior Director of Technical Marketing and Solutions Engineering at Cisco, Frank D\u2019Agostino leads the development and technical go-to-market strategy for Cisco\u2019s Application Centric Infrastructure (ACI), the company\u2019s portfolio of Software Defined Networking tools. Network World Editor in Chief John Dix recently spoke with D\u2019Agostino about what the company is learning as customers adopt SDN. (D\u2019Agostino was formerly VP of WW Technical Operations for Nicira Networks, the company VMware bought to drive its SDN strategy.)\n\n\nIs there a profile emerging of what a typical ACI customer looks like in terms of the types of challenges they\u2019re trying to address?\n\n \n\nFrank D\u2019Agostino, Senior Director of Technical Marketing and Solutions Engineering at Cisco\n\n\n\nClearly 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.\n\n\nI think a lot of it has to do with, one, we\u2019re a better network, two, we can be application relevant, and three, we\u2019re allowing integration in an open way without limiting innovation. We\u2019re actually allowing vendors that might be competitors in certain market segments to integrate into the operations model, and really it\u2019s a win-win for customers as well as vendors and I think that is why we\u2019re seeing such wide adoption.\n\n\nPeople just want a better network that is automated, that has visibility and delivers all the \u201city\u201d 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:\n\n\nAutomating network connectivity, whether it\u2019s a virtual NIC on a VM, whether it\u2019s a physical port on a bare metal device or a switch, or a VLAN interface that we\u2019ve carved out to be logically independent or secured off for one customer. Automating that basic connectivity is step one.\nNext 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\u2019s from devices to profiles immediately enables the agility and allows the security profile to move wherever you enable the workload or service chain.\nApplication service chains can be complex and there are a number of physical and virtual devices that have implications for security and policy. Policy isn\u2019t all within one device. It\u2019s actually relevant everywhere the application is enabled, and Layer 4 \u2013 7 services can be enabled anywhere in the fabric. This means that security doesn\u2019t 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.\nAnd the last one is in an SDN context, where you\u2019re 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.\n\n\nMost 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\u2019m basically telling customers is don\u2019t 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.\n\n\n\nSo we see both enterprise customers as well as cloud providers pursuing a crawl, walk, run model, automating existing use cases and then moving on.\n\n\nIs there one use case that jumps out as being particularly sensible?\n\n\nThe 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.\n\n\nDoes the adoption of container technologies complicate the picture at all?\n\n\nNo, I think it expands ACI\u2019s value. Consistent policies can be applied across the board, further simplifying infrastructure and accelerating a customer\u2019s 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.\n\n\nLeveraging 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.\n\n\nThis 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.\n\n\nAre you seeing customers shifting to containers?\n\n\nAbsolutely. In fact, that\u2019s one of the largest shifts that I see, and we have whole cloud deployments that are going in with no x86 virtualization whatsoever. It\u2019s all container based.\n\n\nWhat kind of change have you seen early adopters make based on ACI capabilities?\n\n\nThere 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 \u2013 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.\n\n\nEverything in the chain is an application delivery point, in some sense. So whether it\u2019s 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\u2019s where the majority of the gains are. That\u2019s 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.\n\n\nIn terms of the crawl aspect, where are customers starting, with a particular application or a certain domain or what?\n\n\nIt 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.\n\n\nIn 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.\n\n\nDo you see companies making any organizational changes when they adopt ACI?\n\n\nWe\u2019ve been used to a cadence of software delivery measured in multiple months, whether it\u2019s three months or six months.\u00a0\u00a0 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.\n\n\n\nCustomers 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\u2019s 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.\n\n\nCustomers are demanding a move to automated models connecting multiple functions from multiple vendors, but doing it in a way where they\u2019re 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.\n\n\nHow have you had to tweak ACI as you started to gain real world experience?\n\n\nAll products evolve over time. All of the architecture elements we\u2019ve 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\u2019s the maturation of an architecture driving functions based on wide-scale customer production deployments driving features, timelines, and scale requirements.\n\n\nCan you quantify the acceptance of OpFlex at all? \n\n\nThere are more than 35 ecosystem partners driving OpFlex, so there\u2019s 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\u2019s totally open and published. The benefit to everybody that\u2019s participating is OpFlex is it is a declarative southbound protocol, and that basically means we\u2019re 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\u2019t say you have to be blue, red or green.\n\n\nAs an example, John, you might be able to bench press 1,000 pounds and I can bench press 500. Well, if I\u2019m the controller you shouldn\u2019t be limited to benching 500 because that\u2019s my limit. I should be able to say to you, \u201cJohn, lift the maximum weight you can.\u201d That\u2019s what we\u2019ve done with OpFlex and that\u2019s what\u2019s really driving this declarative model. It gives all of the vendors a tremendous advantage.\n\n\nIn fact, as you look across the vendors that are part of the ecosystem, you\u2019ll see we have competitors that realize the value of being part of the model. Shame on Cisco if we can\u2019t win every market segment we\u2019re 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\u2019re looking for.\n\n\nSpeaking of competitors, you mentioned that security is a compelling use case, and VMware is finding that too. Does that surprise you at all?\n\n\nVMware prefaces conversations about security with \u201c\u2026 in an all virtual environment.\u201d 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.\n\n\nWhile 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\u2019s driven through centralized policy and automation, whether the endpoints are physical or virtual, and that is something VMware is not addressing.\n\n\nVMware 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\u2019re 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.\n\n\nHow is competition with NSX going?\n\n\nKeep 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\u2019s for SDN. ACI supports NSX as an application better than any other network in the industry, so it\u2019s not an either\/or. NSX doesn\u2019t provide SDN for all interfaces, even on their own hypervisor, so we can show customers why they don\u2019t necessarily need it, but it is the customer choice and we enable customers, not limit them.\n\n\nThere are also some marketing charades going on relative to what is open and what isn\u2019t. 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\u2019s 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.\n\n\nIt 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.\n\n\nLooking 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.\n\n\nThis 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.\n\n\nThe largest customers that have deployed SDN are moving to this model and away from the first generation lock-in of SDN LAN emulation controllers.\n\n\nIsn\u2019t it easier for VMware to get SDN going, though?\n\n\nNSX 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\u2019s 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\u2019s 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, \u201cWhy am I doing this in the hypervisor in the first place?\u201d\n\n\nHow would you classify where we are in terms of SDN acceptance at this point? Obviously it\u2019s still the early stages, but what does the acceptance curve look like?\n\n\nI think the vendor wars are still causing confusion for customers and, being a vendor, we\u2019re part of that, of course. However, I will tell you that based on the number of RFPs and the exchanges I\u2019m having with customers, everyone wants automation, SDN security and visibility. And you can tell by some of the growth numbers we\u2019ve been reporting that the uptake is significant. I wouldn\u2019t say it\u2019s a slow start. I think it\u2019s the way all networks are going to be built moving forward and I think Cisco obviously is looking at a clear leadership position.\n\n\nSo RFPs are coming in that require the basic control of SDN, but when would you expect SDN to really hit its stride? \n\n\nWe\u2019re squarely in the middle of it now. You\u2019ve seen the revenue we\u2019ve 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.\n\n\nIt\u2019s not another segment or a certain part of the market or a trend. It\u2019s just a basic feature or functions of all networks moving forward. That\u2019s 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\u2019s another reason why you see vendors like VMware moving beyond a basic value prop and trying to tell a different story.\n\n\nThe last question here, what changes with SDN going forward?\n\n\nI 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.\n\n\nWe\u2019re seeing an open environment accelerating around SDN. Common group-based policy models extend from controllers inside a data center to multiple domains, whether it\u2019s 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\u2019s under a common controller architecture or a federated controller architecture, that\u2019s where I see the big shift moving forward.