We’ve been getting a lot of great questions about ACI since our launch as people try and better understand the value of an application-oriented approach. I got the following questions on my blog post about the Application Virtual Switch that probed on some of the thinking behind an application-aware architecture, and why now was the right time to release it (after all, John Chambers called it the most disruptive Cisco innovation in a decade!). Anyway, on to the Q&A:
I’d like to know more about the path that Cisco pursued to evolve towards an “application aware” architecture. This back-story (how Cisco arrived at this juncture) would be very helpful to industry analysts, customers and institutional investors. Here’s some of the key questions on my mind.
- What were the primary roadblocks that inhibited the adoption of this innovative approach in the past?
I would say that the Application Centric Infrastructure (ACI) was a combination of a Eureka! moment, that people just never thought of it before, and that it was also an insightful evolution from early SDN technology. So, it might be fair to say that SDN had to come along, and then we realized, here might be a better way to program the network (with an application-oriented model, rather than a network-centric model).
That might be another way of saying that the lack of SDN as a precursor to ACI was a roadblock. But I think of it as networks were just built on hardware that were optimized to pass packets and other very specific tasks. And the limitations of historical networking protocols and traditional network designs, coupled with very limited ways in which you could manage a network and tell it what to do, all served as roadblocks to implementing anything like ACI. So the roadblocks that had to be cleared included the ability to program switches through software interfaces, and to centrally manage the software applications or controllers to orchestrate the broader network, not an individual device. Those are some of the things SDN brought along.
Read More »
Tags: ACI, APIC, application centric infrastructure, Cisco ONE, nexus, onePK, OpenFlow, SDN, XNC Controller
Despite all the buzz about software-defined networking (SDN), many organizations don’t yet have a clear idea of how it will benefit them. In this blog, I’ll tackle the what and why of SDN, and explain the different approaches you can consider.
What: A Disruptive Approach to Network Control
For the last quarter century, network devices have performed two types of processing:
- The data plane looks at a routing table to decide where to forward packets. This processing takes place in dedicated hardware ASICs.
- The control plane takes care of everything else, such as spanning tree, AAA, exporting NetFlow statistics, SNMP, and more. The control plane is implemented in software, and you can think of it as the brains of the network element.
So, if your network includes 200, 2000, or 20,000 network devices, that means you’re managing 200, 2000, or 20,000 control planes and keeping all of them up to date. Read More »
Tags: Cisco ONE, Open Network Environment, OpenFlow, OpenStack, SDN, software defined network, virtual network overlay
Network programmability means democracy, means freedom, freedom to program across all layers and entities, software or hardware – depending on your needs. Is SDN required to have network programmability? Not at all. Does the SDN architecture leverage network programmability? Yes, of course. So, why do many people equate network programmability and SDN? Read More »
Tags: API, Cisco ONE, Cisco ONE Architecture, onePK, OpenFlow, programmability, SDN, SDN architecture
I admit it. I’ve grown weary of the debate about whether SDN includes network programmability or whether or not SDN can only be accomplished through NfV, or the relative merits of control plane / dataplane separation. I will leave those debates to others more focused on the technology itself. Personally, I have been more fascinated with what I see as the new business opportunities emerging around SDN.
Certainly there is a raft of opportunities for start-up companies in the controller space or in the virtualization of various networking functions. Many innovative new companies are re-examining existing network functions within the SDN paradigm; that will lead to some potentially new and useful approaches that may be cheaper/easier/faster than current designs. No doubt many customers will see value in these new ways of doing things, and everybody will benefit.
But that’s not what I find fascinating about SDN. What I am starting to see are ideas that are completely out of the box, and would likely not be thought of by typical network technologists working alone. Let me discuss a few categories of things I have seen possible with the emerging technologies.
The Network as a Compute Resource
It turns out Read More »
Tags: API, cloud, NFV, ONE, onePK, opendaylight, OpenFlow, SDN
Cisco Live is here! It’s a great opportunity for you to discover some really exciting technology solutions at our Cisco ONE: Cisco Intelligent Programmable Network booth featuring a few of our latest innovations.
Onsite you will be able to see and ask your questions at live demos featuring applications and services developed with One Programmable Kit (onePK), Openflow and the eXtensible Network Controller. In addition, we have demos devoted to IPv6, routing, service discovery and network design simulation -- all things meant to make your network simpler and smarter.
There are also some great partner demos including our friends from SAP, Citrix, Glue Networks, Pramacom, Radware, and Starview who are showing some really cool apps that use the Cisco ONE APIs. Read More »
Tags: Cisco APIs, cisco live, Cisco ONE, Cisco onePK, EIGRP, onePK, OpenFlow, programmable networks, SDN