NFV Specs/Open Source

The Platform's Not Burning

There was a period of several years where almost every article you'd read about the telecom industry felt like a version of the famous internal Nokia "burning platform" missive: Pay-TV on the decline!; Google and Facebook getting all the revenues!; Net neutrality!; Landline voice revenue gone!; Wireless revenue flattening!

Most of these could be summed up by two statements: Operators were making the wrong big bets on the services they were offering; and their services took too long to roll out and become relevant.

On the network infrastructure front, the industry has responded with SDN/NFV: Make the network more software-driven, more elastic, and less reliant on an ever-growing set of specialized physical boxes that make provisioning complex and brittle. Apply the lessons of the web giants and cloud services companies to try new things, fail faster and experiment more.

Supporting that technical transformation, telecom operators and vendors alike are moving to adopt open source software and participate in the organizations where it is created. Engaging in these projects is a sea-change for the industry, one that is as much cultural as technical.

A few words about what open source means (and what it doesn't) before I go further. People often mistake open source as a business model. They focus on the F in FOSS (free and open source software), and while that's tempting, "free" is an awfully distracting concept.

Open source is, in fact, an R&D model. It's one that acknowledges that working together to solve the hardest foundational problems enables everyone in the ecosystem to put more of their valuable internal resources on interesting and differentiating projects.

When viewed this way, open source really is the next logical step in the way the industry works together, and although it can feel very different, it can be viewed as an evolutionary change rather than a revolutionary one.

Traditionally, we've collaborated externally as an industry. We've always relied on standards bodies to innovate collectively, and we still do. The ETSI NFV Industry Specifications Group (ISG) has done important work conceptualizing an NFV architecture, and it is currently enumerating a number of important requirements and testing needs (some of which are already making it into OPNFV via our Yardstick test project). New standard protocols such as VxLAN, OpenFlow and NSH (Network Services Headers) and existing ones such as YANG, Netconf, BGP, and so on, are crucial to how NFV and SDN will function.

Open source goes one step further and begins to consider the actual implementation of these standards as collaborative work. The premise behind open source is that rather than sending all the vendors off to go build these stacks and components separately -- replicating essentially similar development projects inside every company -- the vendors collaborate on a common platform that is developed, tested, and fixed more quickly.

For example, in OPNFV Arno release, we found a number of difficult bugs close to our release date, caused by several different inter-related issues. It was a stressful few weeks working through them, but imagine replicating that troubleshooting in every single vendor's shop, multiplied by every single operator environment. We compressed months of effort into weeks.

Open source isn't magic -- we didn't compress the work into nanoseconds. On the other hand, the combined effect of months being compressed into weeks over and over and over again… starts to become significant. This gives our industry the ability to move more quickly, to compete more effectively, and to waste fewer resources.

Collaboration at this level requires work. It also requires influencing differently -- developers respond to inspiration far better than dictation, and they're far more likely to trust those who also code. The traditional methods of carrier influence need to evolve to acknowledge this new reality and I've seen examples that give me hope. Blueprints coming out of our Doctor project focused on fault management have already been incorporated into OpenStack Liberty code, and other blueprints from this project are currently making their way toward incorporation as well.

I've spent most of my career working on the problem of effective cross-company collaboration; in addition to standards and open source, I've also done partner marketing and business development. The thing all these roles have had in common is reaching across boundaries to make something bigger and better than I could have on my own. It's often been frustrating, but seeing the discontinuous progress it's enabled has made it worth it.

If you're interested in exploring how open source and industry-level collaboration can make our industry more competitive and more agile, join the conversation at the OPNFV's inaugural summit in Burlingame, Calif., this week. We'd love to have you come help us make open source NFV a reality.

— Heather Kirksey, Director, OPNFV

COMMENTS Add Comment
DanPitt 11/11/2015 | 7:54:27 PM
Re: Open source and Standard Many fine points, Heather. The model has already been proven in the computing world so it should be extendable to the networking world. Steve Saunders is correct that the cultural differences (between the traditional open-source community and the telecom service providers) are not trivial but I think it's inevitable that both communities evolve (including becoming more diverse, by the way, as we have been aware in ONF). As for the mistaken notion that open source is free, I like to think of it as being as free as a "free" puppy.
Steve Saunders 11/11/2015 | 5:09:18 PM
Re: Open source and Standard thanks Robin!
Robin Mersh 11/11/2015 | 2:03:34 PM
Re: Open source and Standard Steve,

There are some cultural differences between service providers and the open source community, and there are process and methodology differences between the open source community and standards organizations.

However, we need to overcome these differences. And your right, it needs efforts on both sides, speaking a common language and with common goals. Driving consensus on network requirements is as important as ever.

The Broadband Forum, for one, is making every effort to align ourselves with our partners and the wider community in regards to both common goals and compatible methodology. In this way we as an industry will deliver the necessary tools, platforms and services in a way that is useful for as many people as possible.

We believe the key to achieving all of this is to develop a vision that brings benefits for all players. Service providers need to be heard loud and clear, and so too do the vendors. All the other parts of the value chain need to be partners in this exercise, which includes the developers of new services, content providers and the consumer, of course.

The broadband 'cake' needs to grow, so that all players can benefit. We generally find that when you offer a slice of that cake rather than crumbs, then all contributors feel motivated to deliver.

As Heather, my good friend notes, the Platform is not burning! The new broadband platform will bring new value to all players, service providers, vendors, content providers and broadband users.

If you want to see more on the Broadband Forum's approach check out our LR Webinar from November 9 - High-Value Services for Broadband Enabled by NFV and SDN.

DHagar 11/10/2015 | 8:45:34 PM
Re: Open source and Standard dugerdil, agreed - Heather has outlined a beneficial map to true collaboration. 

I believe that the resulting product, the partners, and the true synergy that comes from this is superior, as Heather points out.  I further believe that the ability to collaborate and build effective platforms, ecosystems, etc., will become the architecture of the future.

Sorry I could not attend your event.  Will carefully follow your info.  They have the right person heading up this effort.
Steve Saunders 11/10/2015 | 2:12:36 PM
Re: Open source and Standard Hi Heather, 

Great artcile - really useful. 

Do you think there is a kind of cultural dissonance in play between carriers and service providers and the open source community? 

That's how it feels to me. 

You say that developers respond better to other coders, and that's true/nice, but a lot of LR's service provider readers either don't trust what the open source community is doing, don't understand it, or don't see that it is working. 

In re: "The traditional methods of carrier influence need to evolve to acknowledge this new reality." Yes, but isn't it equally important for the open source community to remember who they are actually developing for!?

If carriers feel like they are being ignored or not included, and the open source community just sits around telling them what to do, without factoring in their cultural heredity, then you risk ending up with the opposite effect to the one you're looking for. 

Anyway, just a thought. Keep up the good work.  


dugerdil 11/10/2015 | 9:33:22 AM
Open source and Standard Thanks Heather for your article i am in line wih you, open source Is the step following standard with thé same spirit and the same collaborative work, both are complementary Bernard Dugerdil
Sign In