Would SDN, by any other name, still smell as sweet?
Perhaps I’m in the minority that is still frustrated by this, but as a marketing person who is tasked with explaining technology and solutions to customers and prospects, I feel hamstrung by a lack of a widely agreed upon definition of what is and is not “SDN” still. This usually comes up in discussions about our new Application Centric Infrastructure (ACI), and how it compares to traditional SDN concepts, as well as alternative approaches, such as overlay networks advocated by VMware.
The topic came up again this with a NetworkWorld article in which the head of VMware’s network virtualization business is now saying, “SDN will never happen” (our rebuttal). Well, what is happening, if it’s not SDN? Or just because the technology has evolved, do we need to create a new term just because some early assumptions the industry made have changed? As we start out a new year, I thought it a good time to try and reframe the definition, and look at how the trends in SDN may be shaping up to extend the concept into new areas.
Why do customers need SDN?
By early 2012, there was so much hype and expectations around Software Defined Networking, focused on the ability to “program” the network, that real customer use cases and the killer SDN app was lost in the conversation. But what slowly emerged, that is driving all the investment, pilots and product designs is a much better way to manage the data center and cloud network, and to automate IT tasks so that the infrastructure could respond dynamically to rapidly changing business conditions and requirements. The “intelligence” to make all that happen is moving from the network devices and device management consoles, to centralized policy-management platforms, orchestration tools and cloud-managers.
What’s caused the biggest evolution in SDN is the realization that very few organizations really have the desire, skills and incentives to write a new class of applications to a published API to program the network. These users are outlying use cases compared to the vast majority of organizations just looking to automate IT tasks, accelerate application deployment, make their cloud networks more flexible, and better align their IT infrastructure with business requirements. The focus has shifted from SDN being an open API/controller platform, to a platform capable of hosting a myriad of orchestration and IT workflow automation solutions that drive customers to their end goal. To that end, ACI is meeting all those objectives, and in more advanced and innovative ways than earlier SDN approaches.
Read More »
Tags: ACI, Cisco ONE, Open Daylight, Open Network Environment, OpenFlow, OpenStack, SDN, software defined networking, XNC
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