Cisco Blogs


Cisco Blog > Data Center and Cloud

Follow-up Q&A on ACI Methodology and the Pursuit of an Application-Aware Architecture

November 15, 2013 at 7:00 am PST

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: , , , , , , , ,

MegaTrends: Network Programming and Cisco ONE in Enterprise Networks

How do we evolve the IT architecture to enable an ever-increasing set of services while multiple MegaTrends are rapidly transforming the environment? How do you deliver the best possible experience to your users and applications while maintaining agility and keeping cost under control?

Today, in my first blog after the summer break, I’d like to start exploring a topic which is critical to building this new architecture supporting current and upcoming Megatrends – and which can be seen as a Megatrend itself as well: Software Defined Networking (SDN) and the Cisco Open Network Environment (ONE) strategy and architecture.

Bruno Klauser, Consulting Engineer in my team has been focusing on Network Programmability and network-embedded automation for some time – and is currently working with many of the early adopters across EMEAR.

Q: Bruno, with Software Defined Networking  being an increasingly  popular discussion topic we’re hearing a lot of of comments -- from “nothing new at all” to “complete revolution of IT” – what, if anything, is different from how we built solutions in the past? Read More »

Tags: , , ,

Cisco’s onePK Part 2: Reaching out to a Network Element

Exordium

In the previous installment of the onePK series, you received a crash course on Cisco’s onePK. In this article, you’ll take the next step with a fun little exposé on onePK’s C API. You will learn how to write a simple program to reach out and connect to a network element. This is staple onePK functionality and is the foundation upon which most onePK applications are built.

Preambling Details

The following short program “ophw” (onePK Hello World), is a fully functional onePK application that will connect to a network element, query its system description, and then disconnect. It doesn’t do anything beyond that, but it does highlight some lynchpin onePK code: network element connection and session handle instantiation. This is the foundational stuff every onePK application needs before useful work can get done. Read More »

Tags: , , , , , , , , , , ,

Why I Chose the Open Source Model I did for OpenDaylight

Now that OpenDaylight has arrived, it’s time to explain why I made the Open Source choices eventually embraced by its Founders and the community at large.  One doesn’t often see such leaders as Cisco, IBM, Intel, HP, Juniper, RedHat, VMWare, NEC, Microsoft and others agree, share and collaborate on such key technologies, let alone the latter engaging in a Linux Foundation based community (some thought hell will freeze over before that would ever happen, though it got pretty cold at times last Spring).

For those of you not familiar with OpenDaylight (see “Meet Me On The Equinox”, not a homage to Death Cab for Cutie or my Transylvanian homeland), IBM and Cisco have actually started this with an amazing set of partners, nearly that ephemeral Equinox this year (~11am, March 20th) though we couldn’t quite brag about it until all our partners saw the daylight, which by now, we’re hoping everyone does.  It was hard not to talk about all this as we saw those half baked, speculative stories before the Equinox – amazing how information flew, distorted as it were, but it did; I wish source code would be that “rapid”, we’d all be so much better for it…

The Open Source model for OpenDaylight is simple, it has only two parts: the community is hosted in the Linux Foundation and the license is Eclipse.  The details are neatly captured in a white paper we wrote and published in the Linux Foundation.  Dan Frye, my friend and fellow counterpart at IBM and I came up with the main points after two short meetings.  It would have been one, but when you work for such giants as our parent companies and soon to be OpenDaylight partners, one has to spend a little more time getting everyone to see the daylight.  It boils down to two things, which I am convinced are the quintessential elements of any successful open source project.

1) Community.  Why?  Because it trumps everything: code, money and everything else.  A poor community with great code equals failure (plenty of examples of that).  A great community with poor (or any) code equals success (plenty of examples of that too).  Why? Because open source equals collaboration, of the highest kind: I share with you, and you with me, whatever I have, I contribute my time, my energy, my intellectual property, my reputation, etc.. And ultimately it becomes “ours”.  And the next generation’s.  Open Source is not a technology; it’s a development model.  With more than 10 million open source developers world wide, it happens to be based on collaboration on a scale and diversity that humanity has never experienced before.  Just think about what made this possible and the role some of the OpenDaylight partners have already played in it since the dawn of the Internet.  Dan Frye and I agreed that the Linux Kernel community is the best in the world and so we picked the closest thing to it to model and support ours, the Linux Foundation.

2) Fragmentation, or anti-fragmentation, actually.  Why?  The biggest challenge of any open source project is how to avoid fragmentation (the opposite of collaboration).  Just ask Andy Rubin and the Android guys what they fear the most.  Just ask any open source project’s contributors, copyright holders, or high priests, how much they appreciate an open source parasite that won’t give back.  Though we would have liked to go deeper, we settled on Eclipse, largely because of the actual language and technology we dealt with in the OpenDaylight Controller: most, if not all the initial code is Java, and though some are worried about that, I’m sure Jim Gosling is proud (btw, I’m not sure the Controller has to stay that way, I actually agree with Amin Vahdat), but we had to start somewhere.  Plus having a more friendly language NB (northbound, as in the applications run on top of the Controller) is such a cool thing, we think that the #1 open source (Eclipse) and the #1 commercial (Microsoft) IDE’s are going to be very good to it, so why not?  There are more reasons that pointed in the Eclipse direction, and other reasons for such wonderful alternatives (as APL or MPL, perhaps the subject of another post, some day).  But when it comes to understanding the virtues of them all, no one understands them better than the amazing founders of these license models, most of them from IBM, of course (I wish they did that when I was there).

What happened between the Equinox and Solstice is a fascinating saga within the OpenDaylight community which I think played its course in the spirit of total and complete openness, inclusion, diversity, respect of the individual and the community, and most of all, that code rules – we do believe in running code and community consensus.  I tip my hat to all my fellow colleagues that learned these two things along the way, the enormous talent at the Eclipse and Linux Foundation that helped us launch, and even the analysts who tried (and did incredibly well at times) to speculate the secret reasons why these partners came up with the model we did: there is no secret at all, my friends, we’re simply creating a community that is truly open, diverse, inclusive, and never fragmented.  Just like a big, happy family.  Welcome to OpenDaylight, we hope you’ll stay!

Tags: , , , , , , , , , , , , , , , ,

Securing the Open Network Environment

With all of the focus on Software Defined Networking, open networking, API’s, you name it, I do often wonder how, with all of this ‘openness’, does an Enterprise keep their network secure? After years of security teams working  tirelessly to protect their business critical infrastructure does this paradigm shift where anyone can write an application to control, get the intelligence from, and manipulate the network become the reason for many a sleepless night for security experts around the world? And on the other hand, can this new way to manage the network help in threat detection and prevention?

If you, like me, are wondering the same thing, I invite you to register here for the 5th session of the Cisco Open Network Environment Webcast Series titled “Securing the Open Network Environment” broadcasting on July 30th at 9 a.m. PST.

Jon Oltsik, ESG, Security, Mike Nielsen, Bret Hartman, ONE, SDN

Join Mike Nielsen and Bret Hartman from Cisco as well as Jon Oltsik from Enterprise Strategy Group (ESG) for a great discussion featuring live Q&A throughout the session.

If you have missed any of our previous sessions featuring introductions to OpenFlow, OpenStack, Cisco’s onePK, and Using Open Source in Networked Environments, please visit www.cisco.com/go/onewebcasts.

Tags: , , , , , ,