It’s been a few weeks since the Spring 2012 OpenStack Conference took place in San Francisco. The semi-annual event allows developers to get together and plan for the upcoming OpenStack release. It also allows for OpenStack users to show how they deploy the software in production. Given that a year ago was when Quantum, the networking component of OpenStack, was born, I thought it was a good time to reflect back on Cisco’s contribution to the 2012 OpenStack Summit. Cisco was a very active participatant at the event, both in the Design Summit as well as the conference. The OpenStack Foundations 19 members were announced just prior to the event, and Cisco is a Gold level contributor.

In the Design Summit, Cisco OpenStack Engineers made the following contributions:

• Debo Dutta lead sessions on Quantum System Test as well as Scaling OpenStack. The session on scaling was particularly interesting, as it highlighted the gap in understanding what the current scaling limits of OpenStack really are. It also was a forum for some organizations to discuss how far they are scaling OpenStack in production, and for the developers to try and come to an agreement on what scale to shoot for in the Folsom timeframe.
• Edgar Magana Perdomo lead a track on L2 & L3 Network Services Insertion. The key takeaway from this session is that Edgar was not proposing adding new APIs at this point in time, but rather allowing for a CLI to assist with stitching in network services.
• Sumit Naiksatam lead a track on L3 topics. The session was called “IPAM/L3-fwding/NAT/Floating IPs II“, and given the name, was a continuing session on discussing how Quantum can provide L3 services. Getting everyone on the same page was the key for both of these sessions.
• Soren Hansen was responsible for organizing all sessions in the Nova hypervisors track. Soren is a long time OpenStack contributor who recently joined Cisco’s OpenStack team.
• On top of actively leading the above sessions, Cisco’s OpenStack engineering team were active participants in all of the Quantum related sessions, as well as sessions around scaling OpenStack and Horizon integration with Quantum.

As OpenStack continues to mature, the interest in Quantum providing the correct network abstractions is very real. An entire track on day 2 was dedicated to Quantum in fact, and all of the sessions had a large number of attendees. The goal for Quantum in the Folsom timeframe is to hit parity with the existing nova-networking, such that Quantum can become the standard networking environment when people deploy OpenStack.

During the conference Cisco participated in the following ways:

• Lew Tucker, Cisco’s CTO of Cloud and the face of Cisco’s OpenStack participation, gave a keynote at the conference portion of the event. Lew’s slides are available on slideshare here.
• As a Gold Level sponsor, Cisco had a booth in the main exhibit area not far from the conference entrance. We distributed t-shirts with the “OpenStack@Cisco” logo on them. We were able to engage with fellow OpenStack developers, partners, and customers the entire week.
• Cisco was a sponsor of both the conference and the summit.

The key take away from the event was around the production deployments of OpenStack announced around the conference timeframe. OpenStack continues to have a lot of momentum going forward, and the announcements by places like Rackspace show the technology is already being deployed at scale in production.  Cisco is actively working with the OpenStack community to help shape the development of Quantum, Nova, Horizon, and other parts of OpenStack. If you are interested in joining the OpenStack@Cisco team, the team is hiring. Please contact Murali Raju (murraju at cisco dot com) for more information about joining the team!

Tags: OpenStack

We’ve held our annual Cisco Open Source event this week, on May 1st in San Jose. I’m very impressed to see the large turnout and the ultra positive feedback after the keynote and 5 tracks on Linux, SDN, Big Data, Emerging Technologies and Community Development. Wonderful to see Irving Wladawsky-Berger from IBM, Jim Zemlin from the Linux Foundation, Simon Crosby from Bromium and the great discussions that ensued. Next time we’ll have to open this event up to more than just one afternoon, there is just so much open collaboration that is taking place. My thanks to our track leads, Michael Hein who helped me put together the Linux track, Jan Medved and Dave Ward on SDN, Mark Voelker and Ed Warnicke on Big Data, Fabio Maino and Flavio Bonomi on Emerging Technologies, and Peter Saint-Andre for the Community Management and Tools — these guys have already left their mark on timeless and enduring open standards, but it’s amazing to see how good they are in open source!  We’ll have to post the key takeaways in these next blog entries, for now to all those of you who came, contributed and enjoyed this event, we salute you! Open at Cisco is a vibrant and growing community.

Tags: Big Data, Cisco, Linux, open source, SDN

As the oVirt project continues to move forward, a new workshop has been setup in Beijing on March 21st. The workshop page has all the details. If you are in the Asia-Pacific region and are looking to learn more about oVirt, this is a fabulous place to do just that. Interact with developers on the oVirt project, learn about the development process, and get involved. If the oVirt Kickoff Workshop from last fall was any indication, this workshop will be another great event for the oVirt Community. Cisco, as a board member of the oVirt project, is excited to see this community and technology continue to advance forward.

Since the announcement of VXLAN last summer, there has been interest in the Open Source community for an open implementation of this. With the increasing number of  Open Source cloud and virtualization technologies out there, where does VXLAN fit into this picture? I think one logical place for it to exist is inside OpenStack Quantum. As a service providing network connectivity between interface devices, this is a logical place for it to exist, especially as it pertains to disparite plugins.

But before I explain how VXLAN could plug into Quantum, some background may be good. Omar Sultan posted a great 3 part blog series on VXLAN (Part 1, Part 2, and Part 3). Reading this will give you a good, relevant background on VXLAN.

An Open Source implementation of VXLAN would require 2 pieces: A data path piece, to implement the protocol and framing format. And a control path piece, to handle orchestration of segment IDs and multicast addresses. For the data path piece, patches were posted to the Open vSwitch mailing list in October 2011, but so far have not been merged into either the Open vSwitch project’s git tree, nor the upstream Open vSwitch kernel code in the Linux tree. Once these patches make it into a public git repository, the data path portion of the equation is complete.

But what about the control path piece? One logical landing spot would be in OpenStack Quantum. Looking at version 1.0 of the Quantum API guide, we can begin to see how to add VXLAN support into Quantum. Quantum networks are created agnostic of their underlying segmentation technology. Currently, VLANs are used. Adding in VXLAN support would be as simple as adding in a type to “Create Network” call. Specifying VXLAN would allow Quantum to provision a Segment ID, and allocate a block of multicast addresses to use. Multiple hosts could still be added to multiple networks with a type of VXLAN. Quantum would work great for handling these types of tasks.

The place where this really begins to shine, however, is in the plugin architecture of Quantum. With Quantum handling the tasks of segment ID allocation, the plugins will have to handle the VXLAN protocol implementation for a network with type VXLAN. Vendors can now implement VXLAN in their plugins, and this buys end users the ability to have a heterogenous VXLAN environment out of the box.

I have previously written about oVirt on this blog, but today, the official press release went out. You can read it in full here, but I’d like to quote a bit from the release:

The oVirt project today announced that Canonical, Cisco, IBM, Intel, NetApp, Red Hat and SUSE have joined together to help create a new open source community for the development of open virtualization platforms, including virtual management tools to manage the Kernel-based Virtual Machine (KVM) hypervisor. With the oVirt project, the industry gains an open source, openly governed virtualization stack.

The key piece to note above is the community aspect. oVirt as a community will develop and create an ecosystem in which customers, developers, and vendors can all thrive. Since the workshop, the community has been working towards the first release of oVirt for public consumption. Cisco, being on the oVirt board, is proud to be a part of the oVirt community as this community drives towards the initial release of oVirt.

Tags: community, open source, oVirt

Let me tell you a reason why open source and open communities are great: information sharing.

Let me explain…

I am Cisco’s representative to the Open MPI project, a middleware implementation of the Message Passing Interface (MPI) standard that facilitates big number crunching and parallel programming.  It’s a fairly large, complex code base: Ohloh says that there are 0ver 674,000 lines of code.  Open MPI is portable to a wide variety of platforms and network types.

However, supporting all the things that MPI is suppose to support and providing the same experience on every platform and network can be quite challenging.  For example, a user posted a problem to our mailing list the other day about a specific feature not working properly on OS X.

Read More »

Tags: HPC, mpi, MPICH2, Open MPI, open source

As we approach Thanksgiving here in the US, we are reminded of things we are thankful for. I thought it poignant to reflect on Open Source projects I am thankful for. These are in no particular order, but represent everything from infrastructure projects to compilers to source control tools. These are some of the most popular and used software in the world today, and taking a moment to say thanks to all the developers, testers, and users is time well spent:

1. Linux
2. OpenStack
3. oVirt
4. Apache
5. gcc
6. Firefox
7. OpenWRT
8. git
9. Hadoop
10. Puppet

In my previous post, I talked about how networking was a large part of the discussion at the oVirt Kickoff Workshop. Increasingly, the network is elevating itself to be a first-class citizen in large open source infrastructure and cloud projects, including open source projects like OpenStack and now oVirt. In OpenStack, the Quantum project is the result of these discussions. Newborn community projects such as oVirt are starting to look at elevating the network to provide advanced functionality as well. It was no surprise a large portion of the last day of the workshop was spent on networking, with an early focus on Quantum.

The last day of the workshop started out the morning with an overview of SDNs and Quantum by Lew Tucker, CTO of Cloud at Cisco. Lew drew a nice overview of cloud networking on the white board, presenting an app-centric view of cloud and virtual networking. In the cloud network model, apps care only about  connectivity to the network, not how that connectivity happens, thus the focus on apps as the center of this world.

Lew Tucker Diagraming Quantum Networking

After Lew was done, Dan Wendlandt, project lead for Quantum, presented his Quantum slides. This was helpful to level-set everyone at oVirt with regards to Quantum and OpenStack. One of the main pain points with looking at  how Quantum can be shared from OpenStack into oVirt has been the difference in the networking models. OpenStack presents a very cloud-centric view of networking, whereas oVirt wants a more datacenter-centric model. Quantum was designed to generally be agnostic to the deployment model, so using it in oVirt should be a matter of fitting it into the architecture.

Ram Durairaj from Cisco, Chris Wright from Red Hat, and Dan Wendlandt from Nicira

After Dan was done giving a broad Quantum overview, Ram Durairaj from the Cisco OpenStack team presented on Quantum L3 Services. Currently, Quantum is designed to address the L2 abstraction of the network. Quantum L3 Services are meant to expose L3 concepts such as subnets and gateways into Quantum and the plugins. It would also allow for routing between tenant domains.

Ram Durairaj talking L3 Services

Now that the oVirt Kickoff Workshop is over, watching how the networking story with oVirt evolves will be interesting. The success of oVirt will be the result of the community around it, and the ecosystem for third party vendors it creates. With regards to networking in oVirt, the interactions between the Quantum community and the oVirt community have only just begun, and the future looks like a very collaborative affair between the two projects.

Tags: open source, oVirt, quantum, SDN

The formation of a new community in the Open Source world is an exciting time. We at Cisco were lucky enough to participate in the formation of one such community while hosting the oVirt Kickoff Workshop at our San Jose headquarters. In making the decision to Open Source their RHEV-M product, Red Hat also decided to create a community, and ultimately an ecosystem around oVirt. The workshop filled up early after being announced, and the presentations and discussions have given the new community a look at the assets Red Hat is placing under the oVirt umbrella.

One area generating a significant amount of discussion was the network. The discussion revolved around elevating the network as an equal to other components of oVirt. If this sounds familiar, it is because the exact same discussion was recently undertaken in the OpenStack project, the result of which is the Quantum project. Quantum is an attempt to create a standalone network service, capable of provisioning virtual and physical networks. In OpenStack, it works with Nova to create networks and bring up interfaces, attaching them to those networks. Given Quantum was created to be standalone, looking into how it could integrate with oVirt seems logical. Quantum has the potential to become a clear way to consolidate the handling of network topologies and overlays, both hardware and software, for OpenStack and oVirt. With it’s plug-in architecture, vendors can provide value with their hardware or software plug-ins, writing a single plug-in to enable their network technologies to work on both OpenStack and oVirt.

With one day left of the Workshop, the workshop will shift to BoF sessions, as well as roadmap and release scheduling. Cisco is excited to not only be a part of this community, but also to be a strategic partner with a board seat. Going forward, we hope the excitement level demonstrated at the workshop will carry over as the community drives to the initial release of oVirt.

Tags: OpenStack, oVirt, quantum

What if your mobile device allowed you the freedom to seamlessly roam across any network in the world, regardless of location or operator and with all the attributes you would expect, security or privacy…  With LISPmob, we may have gotten a giant step closer as we open sourced a network stack for network mobility on Linux platforms, an implementation of basic LISP mobile node functionalities.

This is the Locator Identifier Separation Protocol, which supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme based on an IETF open standard.

We hope this will be a project and a community many will find not just interesting and vibrant, but necessary and fun to engage, collaborate and contribute.

How will this help your plans to deal with all these amazing possibilities of mobile access to an ever-growing Internet?

Tags: github, ietf, ipv4, ipv4 address exhaustion, IPv6, Linux, LISP, LISPmob, open source, open standards

I’ve been watching the ongoing schema.org battles over Microformats vs RDFa with some interest, not only because the underlying subject is interesting, but also because of some of the excellent quality of the discourse around how open communities function (or don’t as the case may be) that surround it.

Henri Sivonen has an excellent post on the Microformats vs RDFa… which also includes rather a lot of wise commentary about communities. One of the many things that jumped out at me was his description of the response to asking #whatwg for a proper spec for Microformats (so that he could write a validator):

The answer at the time was basically that if you want a proper spec, you should be the one doing the heavy lifting of writing one.
This attitude makes sense in a way. If you want to defend the community against detractors, you shouldn’t allow situations where a random commenter says something that’s cheap to the commenter to say but expensive for the community to address. Making the commenter put his money where his mouth is an effective way to weed out commenters who aren’t serious.

On the face of it, this would seem to be a very elementary observation. After all, it’s simply the age old formula of measuring how much something is valued by peoples willingness to sacrifice for it. In our normal cash-based economy, we do it all the time by trading our hard earned dollars for the effort of other people. But time and again, I see people missing this point. Coming into an open community and asking for something, without offering any sacrifice to re-enforce that interest.

Big companies are particularly bad about this, acustomed as they are to their simple expression of interest being seen as a precursor to business. But open communities aren’t in business in the traditional sense. There’s no good mechanism to directly express your interest to the community in dollars… that’s just not how it’s done (and honestly, that’s part of why the outcomes often work out so well, because you can’t simply buy them).

But *all* human interaction has it’s currency, and in the absence of dollars, often in open communities that currency is participation: contributing in kind what that community needs. In open standards communities, it can be working on a formal spec as in the example above. In an open source community it is most often contributing code, but can also be contributing other needful things (documentation, testing, etc).

So patch the change you want to see in the world… that’s the currency of Open

What change in an open community would you like to see, and what do you think you could contribute to encourage that change?

Ultimately, the health of an open source project is measured by the production of useful code, and the broad adoption of that code.  This is easy to spot in many examples, projects like the Linux Kernel, Apache Tomcat, Samba, GNU gcc, etc are so useful, and have become so broadly adopted that they are literally the milieu in which the modern world is embedded.

It’s easy to spot the successes.  And it’s also easy to notice that there are thriving communities collaborating around such successes.  It’s much more interesting to ask what contributes to successful open source communities.

I would maintain, that successful open source communities lower the barriers to useful participation.  They lower the activation energy for innovative activity.  Some of the ways they do this are rather obvious, and some are less so.

Technical Barriers to participation:

• Is it easy to figure out where to get the source code?
• Is the code easily understandable to someone likely to be capable of contributing?
• Is it clear how to build the code?
• Can someone qualified to contribute easily figure out how to usefully modify the code?
• Is it clear and straightforward to contribute changes back upstream?
• And are all of these true even if you aren’t already part of the ‘in crowd’ for the project?

Social Barriers to participation:

• Is the community open to communication and participation from outsiders?
• Is it clear and obvious how to become part of the conversation around the development of the software?  Is it easy?
• Can consumers get reasonable access to and attention from developers?

Legal Barriers to participation:

• Are you using a standard license ((L)GPL, Apache, BSD, etc)?
• Is your entire code base licensed under that license?
• Is it clear to contributors what license they must contribute under?
• Is it clear to consumers what license they are consuming under, and what they have to do to comply?

Evaluating Community Health:

The higher the barriers to collaboration a community raises, the harder it is for it to become successful.  When starting an open source project, or evaluating whether to consume or contribute to one, it can be helpful to consider the barriers to participation, as early indicators of whether or not the project is likely to become or remain successful.

What other barriers to participation do you feel are important to be kept low for open source success?

Along with several key industry players we announced the formation of and participation in ONF, the Open Networking Foundation with the purpose of promoting a new approach to networking, called software defined networking, open standards based of course, and implicitly open source since all compute loads (or clouds) need and want both, as we are continuously reminded.

Tags: cloud, ONF, Open, Open Networking Foundation, open source, open standards, OpenFlow

Every time I think about the relationship between Open Standards and Open Source I am reminded of a fascinating talk by Paul Saltman, a biochemist from Caltech, invited to speak to a Chinese forum years ago, about national food policy for China, later published in Caltech’s Engineering & Science, titled The Yang of Nutrition…The Yin of Food.

I am not a nutritionist, or biochemist, or expert on food -- though in more than one occasion I’ve been known to venture in the art - but I do know a little about open standards and open source - let’s just say enough to be sentient of the wholeness and synergy in which these opposites attract and coexist, perhaps not unlike The Cathedral and the Bazaar.

By the very nature of our industry, open standards are not just important, they are indispensable, the foundation upon which every internetworking protocol is based, the pre-requisite of interoperability, so naturally we take open standards seriously, the yang side, as it were.  But what is often overlooked, just as the case with the yin of food in Saltman’s parallel, is the yin of open source, some of which is in fact the implementation, the other side, or yin as it were, of these open standards and more, with things like jabber or tigerstripe just to name a few.  We’d like to tell you more about what we’re doing with these and other open projects, soon to be covered in this blog.

Tags: internetworking, ip, jabber, Open, Open at Cisco, open source, open standards, tigerstripe, yang, yin

Welcome to Open at Cisco, a place where we would like to keep you aware of things related to open source, open standards, open technologies and open developments in general.  I’ve been at Cisco for several years now, involved in open source; when I started I did not realize how much Cisco has contributed since its inception.  I think the BGP story and how it all started a while back exemplifies the collaborative spirit and nature of our contributions, granted some of them in open standards and some in other open endeavors, nevertheless, open standards and open source, particularly in our industry, go hand in hand, or as the IETF tenet goes, we do believe in rough consensus and running code.

Some of those examples have been listed on our website and as our pace of collaboration and contribution increases and diversifies, we’d like to share it with you.  As we do, we would like to take the time to point out not just the typical contributions we’ve made to important and established things such as the Linux Kernel, Apache projects, Eclipse, or open standards such  as SCTP, but to newer communities as well, such as the Open Stack collaboration mentioned last week, so be sure to check our website and of course, this blog.  We really encourage you to join the conversation by commenting on this blog.

Tags: open development, open source, open standards, open technologies