I had the opportunity to present at Telecom Council's Comtech Forum on "Mobile Edge, MEC & The Olympics" in Sunnyvale on 6/21/18.

I hypothesized that ONAP will become a dominant automation platform for not just NFV/SDN services but also MEC applications. I speculated that over time, ONAP might include MEAO (mobile edge application orchestrator) and mobile edge platform manager functions. My conjecture is based on the following reason -- the edge cloud NFVI is going to be unified across VNFs and MEC applications. To me, it makes no sense to carve up a small edge environment into custom built servers distinct for different applications. That's the opposite of a cloud architecture going back to the PNF world! To get lower operational and capital costs, and to get high availability, it will be critical to have a single pool of similarly designed servers. Maybe a couple of flavors might work, but it doesn't make sense to have half a dozen hardware flavors. If you accept my argument that the NFVI layer will be generally uniform, then it makes no sense to have two orchestrators vying for the same NFVI resources. For this reason, I feel that an NFV/SDN automation platform such as ONAP and a MEC application orchestrator will have to be unified. Since ONAP is an open source community-driven project, it has a higher probability of being extended as compared to proprietary MANO offerings.

To be fair, I didn't completely cook this up. See China Mobile's presentation from the June OPNFV plugfest for similar thoughts (they didn't explicitly mention ONAP though).

Do you agree/disagree with me? Am I making sense here? I'd love to hear your feedback.

The 2nd release of the Linux Foundation Open Network Automation Platform (ONAP) project, titled Beijing, occurred on 6/12.

The operators and vendors I’ve talked to ask questions such as: “Is ONAP going to make it? … With other proprietary orchestrators further ahead in terms of functionality and VNF support, should I bother with ONAP? ... Is ONAP mature enough?” My answer is simple — remember CloudStack, Eucalyptus, Nimbula? Not many people remember these names. These were competitors to OpenStack up until 2013/2014. Users had similar concerns regarding OpenStack at the time, but OpenStack is the de facto VIM in 2018 (that could change with Kubernetes, but that's a topic for another day). Similarly, with solid community momentum, significant operator participation and a holistic architectural approach, I believe ONAP will end up being the de facto network automation (aka MANO++ aka orchestrator) software stack.

What’s in the release, you ask. First, given the name Beijing I just had to find an appropriate chinese proverb. The proverb 小洞不补，大洞吃苦 apparently means: “If small holes aren't fixed, then big holes will bring hardship”. I think this sums up the Beijing release quite well. A large percentage of the Beijing release comprises work done under the covers (non-functional enhancements) to improve the overall quality of ONAP.

Having said that, I view Beijing enhancements in three buckets:

Non-functional improvements are a major part of the Beijing release. In fact, S3P (Scalability, security, stability and performance) was a major area of focus for each of the 31 ONAP projects.

Additionally, the Beijing release has a number of important functional enhancements. The first enhancement was blueprint enrichment — manually triggered scaling (vDNS, VoLTE blueprints), change management (vCPE blueprint) and policy driven VNF placement (vCPE blueprint). The last item also included hardware platform awareness (HPA) that is critical to achieve the right price/performance characteristic for your network service. Second, ONAP northbound APIs are in the process of being harmonized with MEF Allegro, Legato and Interlude APIs and TMForum 633, 641, 638, 640 and 652 APIs. This API harmonization is very important to have consistent APIs for OSS/BSS. Third, the OOM project, that deploys a containerized version of ONAP using Kubernetes (k8s) and Helm, has been improved such that all ONAP components including DCAE have been containerized can now be installed and configured using k8s.

Lastly, the Beijing release has two new projects. The MUSIC project provides standard services to distribute applications across multiple clouds. The key idea of MUSIC is to help an application get to 5x9s availability with <=3x9s of infra (I'm sure that's music to your ears ;-). The Benchmark project tests the performance of ONAP across functionality, scalability and security with the goal of finding bottlenecks in these areas.

Want to learn more? Join our “What's new in ONAP Beijing Release?” webinar on 7/24 at 9:00AM Pacific Time.

Ready for more formal learning? Check out our training services.

Ready to get your hands dirty? View our products & services.

‍

In the last blog we talked about how to use a public OpenStack cloud such as VEXXHOST as the NFVI/VIM layer for the ONAP vFW blueprint along with a containerized version of ONAP orchestrated by Kubernetes.

As we discussed, in reality, the traffic source and the vFW VNF are unlikely to be in the same cloud.  In this blog, we will briefly discuss how the vFW blueprint can span two different VEXXHOST tenants. This is not quite the same as two different cloud regions, but it is a pretty close simulation.

The two VNFs will be placed as follows:

• vFW_PG (packet generator) on VEXXHOST Tenant1  
• vFW_SINC (compound VNF that consists of the vFW VNF and a sink VNF to receive packets) on VEXXHOST Tenant2

Since ONAP infrastructure is taken care of, here are the steps to connect ONAP to VEXXHOST. Please follow the steps from “Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP” blog, to register both tenants as 2 regions in ONAP. Next:

1. Create an account on VEXXHOST with 2 different tenants.  
2. If Registering the VEXXHOST into A&AI using ESR UI, change the password length to less than 20 characters.  
3. On Tenant1 manually create OAM network, unprotected_private  networks with different subnets than on Tenant2.  
4. On Tenant2, create an OAM network using the VEXXHOST cloud Horizon dashboard.  
5. Add security rules to allow ingress ICMP, SSH &all the required ports along with IPV6 from both the tenants.  
6. Edit the base_vfw.env and base_vpkg.env VNF descriptor files to configure them correctly based on the respective Tenants.  
7. Copy the above parameters into a text editor to use for subsequent A&AI registration, SDN-C preload, and APP-C⇔vFW_PG VNF netconf connection.

Now follow the steps from the vFW wiki that involve:

1. SDC designer role: Create vendor license model  
2. SDC designer/tester role: Onboard and test VNFs (or vendor software product i.e. VSP)  
3. SDC designer role: Design network service  
4. SDC tester role: Test network service  
5. SDC governor role: Approve network service  
6. SDC ops role: Distribute network service  
7. VID: Instantiate network service  
8. VID: Add VNFs to network service  
9. SDN-C preload: Configure runtime parameters (for us design-time & run-time parameters are the same); preload vFW SINC on Tenant2 and vFW PG on Tenant1  
10. VID: Add VFs to network service — this step orchestrates networks and VNFs onto OpenStack

Upon completion of these steps, you should be able to go to the VEXXHOST Horizon GUI and see the VNFs coming up. Give them ~15 minutes to boot and another ~15 minutes to be fully configured. See below screenshots:

Did you try this out? How did it go? We look forward to your feedback. In the meantime if you are looking for ONAP training, professional services or development distros (basically an easy way to try out ONAP < 1 hour), please contact us.

‍

Useful links: ONAP Wiki, vFWCL Wiki, Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP

‍

The Open Network Automation Platform (ONAP) is a Linux Foundation project that provides a way to design network services, manage their lifecycle and perform service assurance using real-time policy driven closed-loop automation (i.e. no human beings are involved, policies directly drive lifecycle management operations).

ONAP can be used to automate just about any SDN or NFV service, but to make things a bit convenient, the ONAP community has created ready-to-use blueprints/demos: virtual firewall (vFW), residential virtual customer premise equipment (vCPE) and voice over LTE (VoLTE). The vFW is the simplest of the three and can be tried out by those new to ONAP in just a couple of days. However, to try out vFW you will require two sets of infrastructure. First you need OpenStack or Kubernetes to run ONAP and then OpenStack to manage the underlying NFV infrastructure (NFVI) layer for the vFW network service. Unfortunately the combined stack is too heavy to run on a laptop. So you have two options to try out vFW. If you have a lab at your beck-and-call, read no further, go to the above wiki link and try out the vFW blueprint in your lab. However, if you are like most mortals and don’t have ready access to idling servers, we have a solution for you.

Here is what we recommend:

• vFW network service NFVI: Use an OpenStack public cloud. In this  blog, we will show you how we used VEXXHOST, a Canadian OpenStack public cloud service, as NFVI. Depending on where you are located, you can also look for other options. Just make sure the OpenStack cloud version is Ocata or Pike.  
• ONAP: We recommend the ONAP Operations Manager (OOM) installer that uses a containerized version of ONAP orchestrated using Kubernetes. This approach results in a significantly lower footprint than an OpenStack virtual machine based deployment of ONAP. OOM can deploy ONAP on just one VM that can be on the same public cloud as the vFW network service (i.e. VEXXHOST in this case) or a different one. In fact, if you want a hassle free approach, use the Aarna.ml ONAP development distro that brings up all of ONAP on one Google Cloud Platform VM in less than 1 hour.

Before we show you how to use VEXXHOST, a quick background on the vFW blueprint. Below is the blueprint (also called demo) architecture:

The vFW network service consists of 3 VNFs that are packaged as two:

• vFW_PG (packet generator)  
• vFW_SINC (compound VNF that consists of the vFW VNF and a sink VNF to receive packets that go through the vFW and display it on a GUI)

Assuming ONAP infrastructure is taken care of, here are the steps to connect ONAP to VEXXHOST:

1. Create an account on VEXXHOST  
2. If Registering the VEXXHOST into A&AI using ESR UI, make sure to change the default VEXXHOST account password so that it is less than 20 characters  
3. Please follow the steps from “Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP” blog, to register VEXXHOST tenant as a SINGLE region in ONAP  
4. Create an OAM network (example CIDR 10.10.10.0/24, GW 10.10.10.1, DHCP Range 10.10.10.2 to 10.10.10.254) using the VEXXHOST cloud Horizon dashboard  
5. Add security rules to allow ingress ICMP, SSH & all the required ports along with IPv6  
6. Edit the base_vfw.env and base_vpkg.env VNF descriptor files to configure them correctly  
7. Copy the above parameters into a text editor to use for subsequent A&AI registration, SDN-C preload, and APP-C⇔vFW_PG VNF netconf connection

Now follow the steps from the vFW wiki that involve:

1. SDC designer role: Create vendor license model  
2. SDC designer/tester role: Onboard and test VNFs (or vendor software product i.e. VSP)  
3. SDC designer role: Design network service  
4. SDC tester role: Test network service  
5. SDC governor role: Approve network service  
6. SDC ops role: Distribute network service  
7. VID: Instantiate network service  
8. VID: Add VNFs to network service  
9. SDN-C preload: Configure runtime parameters (for us design-time & run-time parameters are the same)  
10. VID: Add VFs to network service — this step orchestrates networks and VNFs onto OpenStack

Upon completion of these steps, you should be able to go to the VEXXHOST Horizon GUI and see the VNFs coming up. Give them ~15 minutes to boot and another ~15 minutes for them to be fully configured. See below screenshots:

‍

‍

‍

‍

Did you try this out? How did it go? We look forward to your feedback. In a realistic scenario, vFW_PG and vFW_SINC are unlikely to be in the same cloud. So, in the next blog we will show you how to use two different VEXXHOST tenants to simulate two regions and then how you can spread the vFW service across those two tenants/regions.

In the meantime if you are looking for ONAP training, professional services or development distros (basically an easy way to try out ONAP < 1 hour), please contact us.

See Also: ONAP Wiki, vFWCL Wiki, Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP blog

‍

On May-21, Amar Kapadia & I conducted a webinar on the topic of “Debugging OOM Failures”.

• Webinar video recording  
• Webinar slide deck

We started off by giving some context. Our objective was to develop a lightweight, repeatable lab environment for ONAP training on Google Cloud. We also plan to offer this image to developers that need a sandbox environment. To accomplish this, we used ONAP Amsterdam along with OPNFV Euphrates. ONAP was installed using OOM that uses Kubernetes and Helm. All of this software was installed on one VM on the Google cloud.

For most users, issues that pop up once in a while are OK. However, for us, the deployment process needed to be consistent and repeatable. For this reason, we had to debug every intermittent failure and develop a single-click workaround script.

The webinar next talked about the 7 issues we faced, how we debugged them and what the workarounds were. The issues faced were as follows. Other than failure#7, the other failures were all intermittent:

1. AAI containers failed to transition to Running state  
2. SDC UI is not getting loaded  
3. SDC Service Distribution Error  
4. VID Service Deployment Error  
5. VID ADD VNF Error  
6. SDNC User creation failed  
7. Robot init_robot failed with missing attributes

If you are curious to learn more, check out the slide deck or video links above. Additionally if you have ONAP training, PoC needs, or simply feel like trying out the VM image on GCP, feel free to contact us. We have a whole portfolio of training, services and product offerings.

I was fortunate enough to present ONAP & OPNFV training courses at the Open Source Networking User Group Bay Area Meetup on May-18, 2018. Please see the slide deck that I presented at the meetup. I was able to walk through the 4 courses available (½ day ONAP, ½ day OPNFV, full day ONAP, full day OPNFV) that are delivered online (through Linux Foundation) and in-person (through Aarna.ml). If you have any questions around training, please feel free to contact us.