What I learned at the ONAP & OPNFV Event in Paris-Saclay

By | Blog

By Phil Robb, VP of Operations, Networking & Orchestraion, Linux Foundation

The ONAP and OPNFV projects kicked off 2019 with a combined developer event at the Nokia Paris-Saclay facility in France earlier this year.  A few more than 200 developers from those combined communities came together to discuss their next respective releases, plan longer-range strategic priorities, and for the first time ever met together to explore further collaboration between the two groups.

As always, I get energized by taking part in these discussions and planning sessions feeding off of the enthusiasm, and passion for excellence that everyone in these communities exude.  This event had approximately 150 sessions spread across four days as well as an OPNFV Plugfest and 2 demonstrations set up by our Nokia hosts. I want to thank Nokia for hosting this event.  They have always been an incredibly supportive participant in these communities and an outstanding Platinum member of the Linux Foundation Networking (LFN) fund.

A full report is now available, but I wanted to drop a quick blog post though to capture what I personally found interesting throughout the week.  The session slides and recordings are posted to this LFN Wiki Page.

LFN End User Advisory Group

The first thing that I would like to mention is that I (re)kicked off the LFN End User Advisory Group (EUAG) at the beginning of the week, and I’ve had a lot of interest both in email and while at the event on it.  We are planning on our first meeting at the end of the January and if you are an end user interesting in any of the projects within LFN I strongly encourage you to fill out the Membership Application and participate.  The EUAG is a great way to both provide feedback to the technical communities as well as learn from your peers on how best to leverage the current capabilities of the LFN project releases.  I am expecting a very active EUAG this year, in particular with the ONAP and OPNFV workstreams within that group, based on what I heard at the event.

The OPNFV Verified Program (OVP)

Throughout 2018 the work done by the Dovetail-OVP project within OPNFV was expanded to include VNF verification as well as NFV Infrastructure.  A natural benefactor and collaborator for the VNF verification work is the ONAP project, in particular the VNF-requirements project and the VNF SDK project.  These groups have been working together over the past several months and this event gave them the chance to sit together several times throughout the week as well as explain to the broader OPNFV and ONAP communities what they are up to and how others can get involved.  If you want to learn more or are interested in helping to shape the foundational requirements to onboard and run VNFs within an ONAP environment follow one of the links above to get more information.

Leveraging Test Tools and Infrastructure Between OPNFV and ONAP

There were several sessions at the event discussing how ONAP can leverage the years of test tool and system-under-test configuration and deployment that the OPNFV group has developed.  In addition, community members from Orange provided further details on their OpenLab and tooling that they’ve created for systematically layering and testing varying cloud and NFVI components underneath ONAP, then installing and testing the ONAP environment, then finally layering on the VNFs they wish to test in that particular environment.  They also have different “Flavors” of implementation from Core, Small, Medium, and Full allowing test teams to only deploy portions of ONAP needed for the particular VNF/Environment testing. Orange has recently open-sourced these tools and provided them on Github until a home is found for them within an LFN project.

I had an epiphany during these sessions regarding the pairwise integration and system testing needs of ONAP.  Normally, for an open source project that delivers one or a relatively small set of coupled executables, the integration testing is relatively straightforward to stand up the interacting components and test new or modified interactions.  Projects that have the end goal of performing integration testing on distributions, ie large, complex systems with hundreds or even thousands of components all on different release schedules spend nearly all of their effort on building tooling to wrangle the consistent, repeatable deployment, and configuration of such systems so that they can successfully perform tests on them to produce consistent and meaningful results.  The most common distributions in the open source ecosystem are those for the Linux operating system and the thousands of programs/packages that accompany it such as the Debian, Red Hat, or Ubuntu distributions. OPNFV however, builds tooling to deploy, configure, and test open source distributions capable of running NFV workloads. It is actually a superset of a typical Linux distribution.

The epiphany came for me as the recognition of the significant complexity that a full ONAP implementation entails.  While the project creates its own set of executable, it also relies on thousands of other open source components including OpenStack, OpenDaylight, Ceph, and Hadoop (all of which are significant in size on their own).  The result of this complexity is a difficulty in producing, deploying, and configuring an environment that allows for reliable pairwise integration testing which in turn slows down system testing. ONAP will benefit greatly by incorporating and collaborating with the OPNFV testing projects as well as the team from Orange and their latest tools that sit on top.  This dialog started in earnest in Paris and I’m excited to see where it goes from there.

ONAP Interoperability With Other Orchestrators

A session was provided by some of the ONAP community members that initially was meant to explore potential interoperability opportunities with the Open Source Mano (OSM) project.  As the discussion evolved though in instead focused on what ONAP needs to do to support other orchestrators in general. I have heard from operators over the past 18 months that there are a variety of deployment scenarios they would like to explore for ONAP in different parts of their network engaging with legacy components, some of which are existing orchestrators,   The discussion in Paris concluded with those in the room feeling as though adding the capability to convert ETSI NFV-ISG defined SOL-006 YANG models to SOL-001 TOSCA models in the NFV-SDK project would allow for generic interoperability between orchestrators that had chosen those different paths within the ETSI NFV-ISG set of specifications. Furthermore, to properly interact with other orchestrators in an East-West fashion, the group in the room felt that continuing the work to support SOL-005 was an important endeavor.  Participants from this discussion took the action to present these suggestions to the ONAP Technical Steering Committee (TSC) for further consideration by the community. The exploration of deeper interactions between ONAP and other orchestrators is always a possibility as well. If there is community interest in pursuing such work, I encourage those interested to contact the TSC for further discussion.

ONAP Subcommittee Meetings in the days leading up to ONS

The next time members of the ONAP community have an opportunity for a face to face meeting will be just prior to the Open Source Networking Summit (ONS) in San Jose, California.  I am targeting the Monday and Tuesday of that week, April 1st and 2nd but plans are not yet finalized. The meeting will be limited to TSC and TSC subcommittee discussions in order to prepare for the launch of the upcoming El Alto development cycle that will start after the Dublin version of ONAP is released in May.  

During our time in Paris, we had the opportunity to plan for a potential joint meeting between ONAP and ETSI working group focused on Zero-Touch Network & Service Management (ZSM).  There are several community members within ONAP that are also working in the ZSM effort and the time seems to be right for these two groups to meet, share their work and plans thus far, and explore ways to collaborate.  Plans for this are still evolving as well, but the hope is to have a 3 or 4 hour workshop sometime during the week of ONS in order for this introduction to take place.

All in all we had a great week in France, and ONAP and OPNFV are off to an excellent year of collaboration in 2019.  More details about what we learned are available in the full report:

Hope to see you at ONS in April!

Enea NFV Core Receives OPNFV Verification Program Badge

By | Blog

By Ciprian Barbu, Technical Team Leader, Enea

How do you make sure that an open source-based product meets all interoperability, stability and functionality requirements when the underlying open source project is complex and deployments need carrier-grade reliability?

Verifying a solution can be a tedious task that slows down market adoption of a product and creates a hurdle for fast deployment. That is why the OPNFV Verification Program (OVP) is so important for OPNFV and OPNFV-based products like Enea NFV Core.

Enea’s long-lasting experience in providing world-class software and services for communication-intensive applications has always driven us to reach new heights and explore new possibilities. Our mission to develop the software foundation for the connected society naturally enabled us to expand our product portfolio with Enea NFV Core, a carrier-grade virtualization software platform built on OPNFV and OpenStack.

With an increasing number of applications being deployed in test labs and real life situations, Network Functions Virtualization (NFV) is now more reality than a possibility. However, realizing the vision of virtualizing networking applications and benefiting from the scalability, predictability and flexibility required by tomorrow’s connected society can only be possible through collaboration and standardization, which is what the Open Platform for Network Functions Virtualization (OPNFV) primarily is about.

Enea has been a member of OPNFV from the early stages, is very active in the Fuel Installer, and a leading contributor to the OPNFV Project overall

A consistent part of Enea’s contributions was directed to the OPNFV testing projects, with the purpose of ensuring true architecture independence and freedom of choice, but also out of the box functionality and reliable operation.

This is one of the key principles of OPNFV—for contributors to work together in order to create a reference platform which is open, functional, and feature rich; but at the same time is verified against open source testing frameworks, using dedicated, community-owned or private testing laboratories, in a CI/CD fashion.

This idea eventually led to the OPNFV Verification Program launched in early 2018, which is all about facilitating the development and evolution of NFV components across various open source ecosystems through integration, deployment, and testing.

Today we are glad to announce that Enea NFV Core has received the badge for completing the latest requirements of the OPNFV Verification Program and is now listed in the OPNFV Verified Products Directory (

Enea NFV Core has now closed a symbolic life cycle centered on the OPNFV community. The base of the product is the reference platform itself, the very same Danube Fuel Release is the core of the product, which has then been advanced to incorporate the Openstack Ocata baseline. During the past two years Enea NFV Core has been optimized and hardened, tested on more extensive testing scenarios, used as a platform for onboarding proprietary VNFs, and extended with new functionality needed in the industry.

With the successful completion of OVP, Enea NFV Core returns to the source and acknowledges its origin: OPNFV.


OPNFV Intern Spotlight: Sofia Enriquez

By | Blog

About Sofia (in her own words):
I am from Buenos Aires and am currently pursuing my engineering degree at the National Technology University of Argentina. I spent a lot of my childhood playing with computers, taking them apart and putting them back together. That, and my siblings support, got me interested in the area early on and is what made me decide to pursue an engineering degree.


How did you hear about OPNFV and what got you interested in this internship?
It all started after one of my mentors recommended that I look into internships in open source. I first interned at OpenStack where I designed and developed a feature inside Ceph drive. When my internship ended, I attended the OpenStack Summit in Barcelona, where I discovered the OPNFV internship.

Can you talk about your experience working on an open source project? Any previous experiences you can share or key learnings from working on OPNFV so far?
My main goal while interning at OPNFV was to containerize VNFs running in Kubernetes and provide the applications to the community. It was a very different experience for me interning for OPNFV because my team was based in China. I’ve never had to work with a team in a different time zone. I learned a lot from the experience and it has taught me a great deal about effective communication. I can say hands down, working as an OPNFV intern was one of the coolest things that has happened to me.

What’s the best thing you’ve learned from your internship?
The best thing I learned as an intern is more effective communication despite the barriers of location and time zones.

Who is your mentor and what’s the experience been like?
My mentors are Xuan Xia and Ruijing Guo. They are amazing mentors who are passionate about their work. They taught me a great deal and were so helpful. My managers, David and Ray were amazing as well and very kind. Additionally, I’ve met some awesome people at the third OPNFV Plugfest.

What do you want to do next?
Since my internship I have worked on a paper about the benefits of VNFs and cloud computing (in Spanish) that was selected for CoNallsi 2018 (Argentine Congress of Engineering). In addition, I am now an associate software engineer for OpenStack at Red Hat, and look forward to attending more summits and learning more about open source.

Nokia proudly presents: OPNFV Gambia Plugfest and ONAP Dublin Developer Forum

By | Blog

By Timo Perälä, Nokia

The new year will see more than 200 engineers from all over the world gather at our Paris-Saclay site for a Nokia hosted open source event – the jointly held OPNFV Gambia release Plugfest and ONAP Dublin release Developer Forum.

As a founder and active participant in both projects, Nokia is committed to their success and I’m looking forward to an event where the focus is on openness and collaboration. Based on the experience of hosting the ONAP Developer event little more than a year ago at the same site, I’m confident the event will be a success!

For ONAP, the Dublin release Developer Forum is a critical step in defining and agreeing the contents of the Dublin release, to be ready in mid-2019. Nokia has been a major contributor to ONAP, being especially active in expanding ONAP’s ability to manage and orchestrate not only virtualized but also physical network functions. Together with colleagues, we plan to continue this journey for the ONAP Dublin release and beyond.

The OPNFV Plugfest focuses on the Gambia release, allowing developers to fine tune it for different hardware variants, while also providing an opportunity for OPNFV project members to meet and discuss their plans for the Hunter release.

Holding the OPNFV Plugfest concurrently with ONAP helps lay the foundation for future VNF verification and certification activities, a major aspect of ONAP from the very beginning.

In addition to compliance and verification, the OPNFV and ONAP cross-project collaboration topics include automated testing, CI/CD, Lab-as-a-Service and infrastructure, all the way to documentation.

Such cross-project collaboration is a proof of the synergy benefits between the open source projects hosted by Linux Foundation. This was the aim of Nokia and other member companies when creating the Linux Foundation Networking fund, an umbrella organization within Linux Foundation to bring various networking open source projects closer together and coordinate their activities.

In addition to hosting and contributing to the co-located event, Nokia will have demonstrations of our lightning fast 5G networks and cutting-edge open hardware for the network edge.

The event is an excellent opportunity to witness the latest developments in open source networking projects, so I really hope you can come along. In addition to in-person participation, remote access to sessions will also be provided.

Please note that prior registration is required – please register as soon as possible at

The agenda for the event, currently being finalized, is here:

Share your thoughts on this topic by joining the Twitter discussion with @nokia and @nokianetworks using #OPNFV #ONAP #NFV #cloud

See the original post on the Nokia Blog here.

OPNFV Gambia — Doing what we do best while advancing cloud native

By | Blog

Author: Tim Irnich, former TSC Chair

Today, the OPNFV community is pleased to announce the availability of Gambia, our seventh platform release! I am extremely proud of the way the community rallied together to make this happen and provide the industry with another integrated reference platform for accelerating their NFV deployments.

At a high level, Gambia represents our first step towards continuous delivery (CD) and deepens our work in cloud native, while also advancing our core capabilities in testing and integration, and the development of carrier-grade features by working upstream. As an open source pioneer in NFV, it’s amazing to see the evolution of the project to meet the needs of a quickly changing technology landscape.

Here are a few Gambia highlights I’d like to share:

Cloud Native & Continuous Deployment (CD)

A key topic at the recent ONS Europe, cloud native is quickly becoming increasingly relevant for the networking industry. The Gambia release builds up the cloud native progress made in Fraser, with seven more projects supporting containers (a 77% increase), and new scenarios integrating cloud native features such as Virtlet, Kata containers, VPP and OVS-DPDK. Deployment and lifecycle management of OpenStack became easier with two OPNFV installers now supporting a containerized OpenStack control plane. As containers continue to bring tangible benefits to developers and end users in the networking space, we’ll continue to explore this exciting space.

Continuing the momentum first started in 2016 with the Cross-Community Continuous Integration (XCI) initiative, we’re introducing a CD process that allows OPNFV to continuously publish scenario and feature project artifacts that contain the latest upstream code. In fact, 17 OPNFV projects are now participating in XCI, and we’re seeing increased adoption of CD by upstreams like OpenDaylight, OpenStack, and FD,io, which also increases the code quality on the master branch. We’re also integrating Spinnaker via the OPNFV Clover project, providing a new mechanism for upgrading VNFs in a production. Devs can access the CD process by integrating with the XCI initiative, or  via the TripleO installer from the APEX project.

Testing, Carrier-Grade Features, and Working Upstream

Testing projects have always been at the heart of OPNFV, and Gambia advances testing sophistication further with additional test cases, additional test support for K8s-based scenarios, and new features. Functest is now able to run on a production-deployed NFVI/VIM instead of just dev/test, providing real-life functional testing data critical to users. On the performance side, Yardstick adds 6 new network services and the Bottlenecks project now supports k8s. This additional flexibility and availability of new features covers a broader range of testing environments and provides more options and insights to users. Another core concept of OPNFV is “Upstream First” and OPNFV Gambia integrates the latest stable releases from our upstream communities — OpenStack Queens, OpenDaylight Oxygen/Fluorine and Kubernetes 1.7.0 to 1.12.2 — into a platform that’s ready for downloading and testing in lab environments.  

What’s Ahead

For those attending KubeCon CloundNativeCon North America in Seattle, December 10-13, we welcome you to join us for an LF Networking reception onsite [insert time / location] as we look to build bridges with the CNCF community and look for areas of collaboration. There will be light food, beer & wine, and lighting talks from the LFN projects. Also look for the LFN booth.

Coming off the co-located OPNFV Fraser plugfest with ETSI in June (read the report here), OPNFV will co-locating with the ONAP for the ONAP DDF & OPNFV Plugfest [insert link], January 8-11, 2019, at the Nokia in Nozay, France. Come test on OPNFV Gambia and work side by side with the ONAP community on the many integration areas between projects. Stay tuned for the OPNFV Casablanca release in a couple weeks with news on the OPNFV Verification Program.

At ONS Europe, the OPNFV community performed a live keynote demo of a virtual central office highlighting the ability highlighting the ability to deliver mobile services based on 5G network infrastructure. This generated significant interest in the community and planning for next version (VCO Demo 3.0) is now underway. If you’d like to be part of these discussions, please join the mailing list.

Signing Off

After a year on duty I’ve now finished my term as the OPNFV TSC Chair. This has been a tremendously rewarding experience and I’m proud off all we were able to accomplish. I’d like to sincerely thank the old and new TSC members, the Linux Foundation staff and the entire OPNFV community for their support. Congratulations to the new TSC Chair, Bin Hu from AT&T who has been a part of OPNFV from the start and is a tremendous asset to the community. So, I’m leaving you in good hands and will continue to be an active community participant. Onward to Hunter!

Cross-Project Collaboration a Focus as Fifth OPNFV Plugfest Co-locates with Third ETSI Plugtest Event to Learn, Test and Integrate OPNFV Fraser

By | Blog

By: Pierre Lynch, Lead Technologist at Ixia Solutions Group, Keysight Technologies

The OPNFV Plugfest was held the first week of June in conjunction for the first time with the two-week-long ETSI Plugtests, May 27-June 8, with both events collocated at the ETSI campus in Sophia Antipolis, France. Bringing OPNFV and ETSI together for joint events provided an opportunity for 105 representatives from 55 participating vendor and open source community member organizations to perform end-to-end network service testing, integrate with the OPNFV Fraser release, and foster collaboration between the OPNFV and ETSI NFV industry specification group (ISG) communities around the ETSI NFV TST working group activities and more.

The event provided a venue for OPNFV and ETSI NFV communities to collaborate on MANO API testing, Open Source MANO (OSM) project integration, service function chaining (SFC) testing, review of upcoming TST009 (NFVI network benchmarking) and TST010 (MANO API conformance testing) ETSI specifications, and running OPNFV Dovetail project tests against four commercial NFVI/VIM offerings. The TST009 work item, which was iteratively developed together between ETSI NFV and OPNFV, is the best example yet of an important project developed in collaboration between a standards body and a Linux Foundation community.

In addition to the joint efforts with ETSI NFV, the OPNFV Plugfest provided an opportunity for the  community to facilitate long duration soak, benchmark repeatability and performance testing tool comparisons as well as NFVBench testing. We also hosted introductory sessions covering test projects, the OPNFV Verified Program (OVP), Barometer, installers, XCI, and the new Lab-as-a-Service (LaaS) offering as well as hosting a hackfest where community members collaborated on their respective projects, with sessions spanning edge computing, MANO integration, individual project planning, and community-focused discussions.

The Plugfest also continued with highly popular hands-on sharing sessions featured at the last event, with installer demos and introductory sessions proving especially valuable for many ETSI Plugtest attendees still new to OPNFV.

The joint event proved successful, helping drive progress within the community of ETSI and LFN members around shared objectives. Exemplifying the ideals of open source for driving collaboration, rapid development, and increased interoperability, we saw output greater than what we’ve previously experienced. For more details on outcomes from the joint event, I encourage you to read the ETSI NFV Plugtests and OPNFV Plugfest Joint Report.

The community is now hard at work on the next OPNFV release, Gambia, due out soon. In tandem, we are also gearing up for the next OPNFV+ONAP Plugfest, which will be hosted by Nokia, near Paris, January 8-11, 2019. Mark your calendars now and stay tuned for more details!

The (OPNFV) Doctor Is In

By | Blog

By Tomi Juvonen,  Technical Lead at Nokia and Doctor Project PTL

This post was originally published on Nokia’s blog and has been republished here with permission.

Long ago, networks comprised discrete elements with dedicated hardware running software that performed a function. Only one application ran on a single piece of hardware, namely the network element itself. The application had perfect knowledge of the hardware environment on which it was running.

Then along came cloud computing. Now, an application no longer needs to care about or manage the hardware it runs on, which is great.

When a fault occurs, telco applications have some very good mechanisms to deal with hardware and software failures, with redundant functional units jumping in to take over from one that has failed. Speed is vital here – it needs to happen lightning fast to keep continuous services, such as voice calls, running without interruption.

But how do we alert the telco application when something is happening with the underlying hardware? So far this has been a missing piece of the puzzle.

The OPNFV Doctor project has been working on creating just that kind of mechanism under OpenStack. Doctor is one of the first projects in Open Platform for NFV, as well as one of the first to graduate. The project was initiated by Docomo, which has been driving it forward strongly ever since.

Doctor has really been taken on board by OpenStack, which featured it heavily in the keynote session at the OpenStack Summit in Barcelona in 2016.

The journey has not been easy – particular challenges are the rolling infrastructure maintenance and upgrades in interaction with the virtual network functions manager (VNFM).

Current focus points include trying to perfect it so that it will work with any kind of payload, hybrid clouds and with no need for additional hardware. Even the application itself can be upgraded at the same time, as it knows how to take advantage of the new capabilities that come with the infrastructure upgrade.

The upgrade caused a buzz at the OpenStack Sydney Summit in November 2017 and the industry is now desperate for this feature to allow it to cloudify operations.

Want to contribute? Join us at OpenStack Summit


As the new Project Technical Leader (PTL) for Doctor, I have worked on bringing in seamless upgrades and maintenance of the underlying platform, without risking dropped calls or IP packets.

The concept is now quite mature, but still needs people around it to make it happen upstream. I will run a presentation and forum session about this in the coming OpenStack Summit in Vancouver on 23 May 2018.

Let’s work together to take the cloud maintenance and upgrade to the next level and ensure we can meet our industry’s requirements.

Share your thoughts on this topic by joining the Twitter discussion with @nokia and @nokianetworks using #NFV #openstack.


OPNFV Fraser: Maturity and Cloud Native Integration for Developers and End Users Alike

By | Blog

By Tim Irnich, Chair, OPNFV Technical Steering Committee and Program Manager, Cloud, Open Source & Ecosystem at Ericsson

Today, the Fraser release goes live. It’s an important milestone for OPNFV, and I would like to sincerely thank all contributors, PTLs and working group facilitators, TSC members, Linux Foundation staff and all other supporters for the tremendous effort, creativity, enthusiasm and skill that went into the release.

Fraser Highlights

OPNFV is a large and diverse project and it is impossible to list all achievements in one blog post. But just to mention a few highlights, Fraser provides a significant step towards more mature cloud native support, higher platform maturity by enhancing features like telemetry and high availability, more robust networking capabilities and various forms of data plane acceleration, and also significantly advanced–and in some cases introduced–entirely new test methodologies and tools. As with previous OPNFV releases, Fraser integrates and verifies lots of updated and upgraded upstream components like OpenStack Pike, ODL Oxygen, release 18.01, and Kubernetes 1.9, only to mention a few. We have also made significant progress with our range of artifacts and services targeting developers by providing easily deployable, flexibly composable, and up-to-date platforms that can be used as comprehensive yet accessible development and testing environments.

The adoption of cloud native in OPNFV, in terms of creating reference stacks based on Kubernetes and integrating them with other related components, as well as the related enhancements to our CI and testing infrastructure, started some time ago. The Fraser release denotes a significant step forward in this effort. For example, we now have 8 different deployment scenarios across various installers that integrate Kubernetes and related components and tools, and Kubernetes support has been added to both Functest and Yardstick test frameworks.

Advances in testing include increased test coverage; for example in the areas of high availability and long term stability, better usability through lower execution times and additional traffic generators,  and better consumability through separating generic framework components from OPNFV-specific code. Based on the observation that the OPNFV test frameworks and the underlying infrastructure for test data collection and analytics is a useful asset also for other projects, the Functest team has introduced a clean separation between test framework and the related packaging mechanisms on the one side and OPNFV test cases on the other side. This allows cross-community testing where the Functest test framework, test results API and database backend, and visualization dashboards can be used by other projects within LFN and beyond. This has seen immediate adoption in ONAP with the interesting side effect that a 100MB container could replace the 1GB VM that was used previously, and reusing  the remaining OPNFV CI pipeline becomes very simple. Another noteworthy enhancement is that VSPERF added new tests to measure data plane performance in “noisy neighbor” situations–an effect known to cause significant performance degradations in suboptimally configured systems.

Further enhancements highlighting the growing maturity of the OPNFV reference platform are infrastructure maintenance and upgrade with zero VNF downtime, new and updated collectd plugins data collection plugins including DPDK and OVS stats & events, an SNMP agent,  IPMI events and many more. The Calipso project provides networking discovery, visualization, monitoring and analysis in Kubernetes and has added support for Contiv/VPP and Flannel in Fraser. The SDNVPN project has added support for Equal Cost Multipath routing (ECMP) in order to overcome the bottleneck of using a single VxLAN tunnel between datacenter edge and fabric.

Developers Tools

Our Cross-community CI (XCI) initiative is becoming more mature and has seen a boost in adoption by other projects during the Fraser release. It now supports multiple scenarios and a number of OPNFV features like BGPVPN, Service Function Chaining and Kubernetes have been integrated. We have also seen other installer toolchains like Apex adopting the XCI concept.  

We have launched our Lab-as-a-Service offering (available at, which takes this concept behind XCI to the next level by providing free access to hardware resources and pre-provisioned stacks, saving community developers of OPNFV and other projects significant time and effort and enabling them to dedicate significantly more time to things that actually matter to them. We are continuing to work on this and will have even more information to share in the coming months.

Moreover, with Fraser, the vision towards dynamic continuous integration (CI) got a boost with the introduction of Scenario Descriptor File (SDF), Pod Descriptor File (PDF), and Installer Descriptor File (IDF) specifications, which contain machine readable information to enable OPNFV installers to deploy any OPNFV scenario to any Pharos lab. With these descriptor files, CI jobs can dynamically run on any available hardware as long as the SDF and IDF requirements match PDF capabilities. The concept will roll out in several phases over the summer.

Looking Ahead

We’ll put the Fraser release to the test in June at the Fraser Plugfest co-located with ETSI at their facilities in Sophia Antipolis, France and are already several milestones into Gambia where we will add a CD-based release process. Cloud native and edge computing will further advance through collaboration with upstream components in CNCF, updated lab specifications in Pharos suitable for edge computing along with new projects requirements, upstream development, and end-to-end testing and integration.

At 3 ½ years in, OPNFV is certainly growing more and more mature in its core deliverables whole at the same time looking ahead and addressing new use cases like Cloud Native and Edge Computing. Participation and adoption by end users like China Mobile and Orange further defines the important role OPNFV is playing in the industry. I hope you’ll join us!

Solving Problems Collaboratively at 4th OPNFV Plugfest for Euphrates and Beyond

By | Blog

By Ray Paik, OPNFV Senior Program Manager, The Linux Foundation

The fourth OPNFV Plugfest, hosted by Intel at their Jones Farm Campus outside of Portland, OR was held on December 4-8, 2017. Intel has been a key contributor to OPNFV since the project launch and their hospitality was certainly appreciated by everyone attending the event. It was also great to see Intel’s Pharos PODs up close as they have been a great resource for the OPNFV community. There were 104 attendees (up 20% from last time), from 30 organizations that included 6 end-users and 6 non-member companies.

There were a lot of OPNFV deployment/testing of the latest Euphrates release on a variety of hardware platforms (3 on-site + 7 remote), finding/fixing bugs, VNF Onboarding, cross-community CI (XCI), SFC, the testing projects, and more. There were also many parallel sessions as the community continues their work on the upcoming OPNFV Fraser release and discussions on improvement areas for OPNFV such as documentation, release process, user support, etc.

With each Plugfest, I continue to be impressed with community’s dedication, passion, and collaborative culture. The presence of multiple project technical leads (PTLs) and key

stakeholders helped accelerate progress significantly and I was amazed at what the community accomplished in 5 days. The next Plugfest will be a co-located event with ETSI at their campus in Sophia Antipolis, France on June 4-8, 2018. Stay tuned for more details!

For more details on outcomes from the OPNFV Euphrates Plugfest, I encourage you to read the Plugfest Report.

Crossing a New Milestone in NFV: Open Source Verification of Commercial Products

By | Blog

By Chris Donley, Sr Director, Open Source Ecosystems, Huawei; Chair, OPNFV Certification & Compliance Committee

As we kick off 2018, the OPNFV Compliance & Certification committee—the members driven body within OPNFV that defines recommendations to the Board for policies and oversight for compliance and certification—is pleased to announce the launch of the OPNFV Verified Program (OVP). The program is designed to simplify adoption of NFV in commercial products by establishing an industry threshold based on OPNFV releases. The fact we are using an open source platform as referent to measure compliance of commercial products—not necessarily based on its source code—is a new and innovative step for the industry.

The OPNFV Verified Program facilitates both vendor self-testing and third-party lab testing using the Dovetail test suite. In our initial version, we will be testing NFV infrastructure components: NFVI and VIM. In the future, we may expand the program to cover VNFs and other components, as well. In December, just ahead of the launch, we conducted a “beta program” with several vendors: Huawei, Nokia, Wind River, and ZTE. These companies provided valuable feedback while we refined and finalized the program. They also represent the first cohort to received the privilege of using the OPNFV Verified mark and logo. Congratulations to these companies and we welcome additional members of the open NFV ecosystem to join us!

OPNFV Verified Program is designed to help operators establish entry criteria for their trials and RFPs. We have worked closely with end user advisor operators to establish a framework and an initial bar to support their requirements. The program will also reduce operator testing load by identifying a set of common tests and executing them just once under the auspices of the OPNFV Verified Program, rather than many times in many labs. As OPNFV and the industry at large continue to mature, we will steadily raise the bar in future versions as to what becomes verified. We expect two OPNFV Verified versions per year, denoted with the month and the year to make it easy to identify the compliance level of submitted products.

Under the auspices of The Linux Foundation, we are well positioned to expand the program to support other projects in the future. Prior to the official launch, we initiated discussions with related projects on leveraging the program to support the wider open source community. OPNFV’s C&C, the group responsible for chartering the OPNFV Verified Program, is also exploring additional operator use cases that can be incorporated into the compliance test suite.

I am excited about the launch of the OPNFV Verified Program and I hope you will join us in 2018! To operators, I invite you to share your use cases and functional requirements, and please consider incorporating OPNFV Verified into your RFP process or lab trials. To vendors, I hope you’ll download the Dovetail tool and test your commercial offerings. If you’re looking for assistance, several third-party labs are eager to help. Learn more about the OPNFV Verified Program and get started today!

Please direct any questions you may have to