philrobb

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: https://www.opnfv.org/wp-content/uploads/sites/12/2019/03/OPNFV_ONAP_PlugfestReport_v4_ac_Web.pdf

Hope to see you at ONS in April!

Congratulations to the entire ONAP community and extended ecosystem on the availability of ONAP Casablanca, the project’s third release! We have come such a long way since ONAP’s first code release, Amsterdam. With a thriving community of more than 492 developers hailing from 31 organizations, ONAP’s growing global diversity has come together to deliver an even broader set of features and enhancements that make ONAP even more suitable for global deployment.

Read on for more details on what’s in the release, as well as a brief Q&A with ONAP’s new Technical Steering Committee (TSC) Chair, Catherine Lefevre.

New Features & Functionality
Casablanca introduces new functionality with two use cases important to the evolution of networking: 5G and CCVPN (Cross Domain and Cross Layer VPN).

• The 5G blueprint is a multi-release effort, with Casablanca introducing the first set of capabilities around PNF integration, edge automation, real-time analytics, network slicing, data modeling, homing, scaling, and network optimization.
• CCVPN demonstrates how to provide enterprise services across operators with the use of MEF APIs. CCVPN was first introduced onstage during ONS Europe with the help of China Mobile, Vodafone, and Huawei. (You can read about the ONS demo here)

Casablanca also includes new features, architectural changes, deployability enhancements (see the “7 Dimensions of Deployability”) and bug fixes. Some of my favorite highlights include:

• The design time environment includes two new dashboards to simplify design activities.
• The runtime environment includes new lifecycle management functions in both the Service Orchestrator (SO) and its three controllers, expanded hardware platform awareness (HPA) to improve performance, geo-redundancy, support for ETSI NFV-SOL003 for VNFM compatibility, MultiCloud enhancements, and edge cloud onboarding.
• Additionally, the initial integration with the PNDA project, several new collectors, policy engine updates, and enhancements to the Holmes alarm correlation engine, boost ONAP’s service assurance capabilities.

Community Growth
We’re also very excited to see strong growth among the ONAP community. With an expanded community, we’ve been able to develop more features in less time! For comparison’s sake, the number of contributing CSPs, vendors, and other organizations has increased to 31 up from 24, and Casablanca includes contributions from 490 developers, up from 452 compared to the Beijing release. Equally important, the community has expanded beyond technical concerns to collaborate with other open source projects such as OPNFV, CNCF, and PNDA, as well as standards communities such as ETSI, MEF, and TMForum.

We also plan to integrate more closely with OPNFV on the compliance & verification program, which will extend to VNFs following Casablanca. The program will allow VNF vendors to test their products using a standardized test suite and receive a verification badge.

To get more color on how the community came together for this release, I sat down with ONAP TSC Chair, Catherine Lefevre. Here’s what she had to say:

Q&A with Catherine Lefevre, ONAP TSC Chair

Can you share any anecdotes about the release and community coming together? We heard rumblings of a great conversation in the LFN booth at ONS Europe. Please elaborate.
While some of our ONAP members were engaged in talks and demos at the ONS Europe, I took the opportunity to organize several meetings. The purpose was to collect feedback from the community to better understand what their expectations are related to the new ONAP TSC. The number of participants turned out to be larger than anticipated and was really energizing, highlighting improvements in terms of technical leadership, communication, documentation, consistency across the platform, plus much more. This feedback became part of our TSC roadmap. An “ONAP TSC” project was created in JIRA (https://jira.onap.org/projects/TSC/), allowing us to track our TSC action items to drive change and accountability based on the feedback from the community. We wanted to manage TSC in the same way we manage any new ONAP feature.

If you had to summarize the release in 3-5 sentences, how would you describe it?
The goal of Casablanca was to consolidate our projects foundation while evolving to modularity and aligning to industry standards i.e. MEF 3.0, ETSI NFV-SOL003, etc.

On the deployment side, we made great progress in streamlining the ONAP installation using Kubernetes, adding a broader range of physical/virtual storage options, enhancements to backup/restore, etc.

On the design time side, two additional artifacts were added to continue driving the unified design palette to help product managers, VNF owners, and anyone interested to build on ONAP (DCAE Design Studio – control loop workflow & Workflow designer for orchestration workflow)

On the run time side, we increased the service assurance footprint by adding new High Volume VES (Virtual Event Stream) collectors and performed initial integration with the Linux Foundation PNDA project in DCAE (Data Collection Analytics & Events). PNDA containerization, application onboarding, and deployment are currently targeted for Dublin. We also developed new functionalities to support physical network functions (PNFs) and audit capabilities through A&AI (Active & Available Inventory).

On the Security side, we integrated many of the ONAP components with Application Authorization Framework (AAF) and increased the CII badging compliancy.

Casablanca provides blueprint updates to 5G and CCVPN as well as a sneak peek of compliance and verification updates related to VNF testing. Can you explain how this will benefit the ecosystem? Why are these developments significant?

ONAP 5G & Cross Domain Cross Layer VPN (CCVPN) Use cases are definitely the cornerstones of the Casablanca release.

The ONAP CCVPN Use case exercises many aspects of ONAP by building a high-bandwidth, flat and super-speed Optical Transport Network between two carriers and across multiple domains.

The ONAP 5G blueprint starts to address two of 5G challenges: Network optimization and the extension of Zero Touch Orchestration/Automation to Radio Access Networks.

These use cases, 5G and CCVPN, demonstrate the willingness of carriers to work together on common requirements. The ONAP community is a fantastic Software Defined Network platform for academic research, proof of concepts into complex topics, benefiting from a lot of technical expertise and highlighting the desire of the ONAP community to develop a platform that focus on building a future together.

What makes this release unique, and  what is your favorite thing about Casablanca or the way in which the community came together?
The acceleration of the ONAP community diversity highlighted by the rise of VNF and 3rd party vendors contributing to the ONAP Casablanca release.  They also now have a better understand the source code and are able to develop themselves.

The scope of the Casablanca release was substantially larger in comparison to the Beijing release while our testing capacity did not increase respectively. The last 3 weeks were challenging, but we had a great Integration team with a “never give-up” mindset and a group of Project Technical leads who acted as a single team. This is really my favorite part, having a large team coming together, focused on a shared goal, working collaboratively to achieve the impossible –  the power of the team spirit!

Now that Casablanca is out the door, what are you anticipating for ONAP’s next release?
We plan to have a minor release in early February 2019 to address some security and code enhancements.

The scope of our first 2019 major release, Dublin, is not yet finalized; however, the ONAP TSC has identified several guiding principles they would like to put in place:

• Pursue our Continuous integration / Continuous Deployment Journey to ensure development issues are addressed quickly by leveraging more automation

• Security by Design – re-enforcement of security awareness at each milestone of the release; not only at code freeze.
• Document as You Code – dedicated focus on improving the documentation all along the release cycle.

Stay tuned for more to come in the coming weeks …

Join us to help shape the next ONAP release!

Dublin Release Developer Design Forum: The next design forum will be conducted jointly with the OPNFV Gambia Plugfest in Paris, France from January 8-11, 2019. The event, as the name suggests, will focus on Dublin release planning and explore various synergies with OPNFV. Both members and non-members are welcome to attend. More info here: https://events.linuxfoundation.org/events/onap-ddf-opnfv-plugfest/.

As we reflect upon 2017 and the successful launch of Amsterdam, we are proud to announce the winners of the inaugural ONAP Community Awards acknowledging individual and community contributions to the success of the project. We were gratified to see strong participation, with 87 nominations representing 53 individuals and projects, and 571 total votes cast.

The community recognized the winners on December 11at the ONAP Developer Forum in Santa Clara, CA. Details about each award category and its winner appear below. Please join us in congratulating all of our nominees and winners!

Top Achievement Award: Catherine Lefevre, AT&T

The community recognized Catherine Lefevre for her dedication to the project and her pivotal role in the successful merger of multiple code bases and timely delivery of the Amsterdam release. Catherine worked tirelessly across many groups and companies to evangelize ONAP globally, while working closely with the Technical Steering Committee (TSC) to work toward Amsterdam’s release date.

Citizenship Award: Chris Donley, Huawei

Chris Donley provided the most assistance to others outside of his own ONAP project through code reviews, debugging, bug fixes and more, furthering collaboration across the large, distributed ONAP community. His work on the Architecture Committee and TSC and time spent educating and guiding others set the standard for communication across the team.

Marketing Award: Lingli Deng, China Mobile

Lingli Deng provided significant support to the ecosystem teams and championed ONAP across a variety of mediums. She also spoke on behalf of ONAP at events around the world and led the review team for the project’s VoLTE whitepaper. Additionally, Lingli contributed two technical videos in English, three in Chinese, and is a frequent coordinator of Chinese contributions to ecosystem development activities.

Code Contribution Award: Seshu Kumar, Huawei

PTLs, Committers and Contributors selected Seshu Kumar to receive the Code Contribution Award based on the quantity of quality of his code. He played important role in helping the Service Orchestrator (SO) project reach critical milestones and in resolving blocking issues. Seshu is one of the top code contributors to ONAP overall.

Project Achievement Award: The Integration Team

The Integration Team worked together for the first time on Amsterdam, yet they met the tight release deadline.

Innovation Award: The ONAP Operations Manager (OOM) Project Team

The OOM Project Team deployed ONAP on containers to support the Amsterdam release.