Even though the Linux Foundation Open Network Automation Platform (ONAP) is well into its 3rd 6-month release (Casablanca came out in Dec’18), topics such as what ONAP is and how it’s architectured seem to be a subject of confusion. This is true even in sophisticated audiences as evidenced by a recent blog titled, “A Tale of Two Transformations: ONAP versus the Cloud” by Tom Nolle. At a high level, the blog compares ONAP and AWS (from a mindset point of view) and concludes that ONAP is business-as-usual and therefore incompatible with the transformative nature of cloud aka AWS. In my mind, a few key themes emerged from the above blog that are worth discussing.

But before we do that, it is important to consider what functionality ONAP includes. I call ONAP a MANO++, where ONAP includes the NFVO and VNFM layers as described by ETSI, but goes beyond by including service assurance/automation and a unified design tool. ONAP does not include the NFVI/VIM or the NFV cloud layer. In other words, ONAP doesn’t really care whether the NFV cloud is OpenStack, StarlingX, or in future, Kubernetes or Microsoft Azure. Nor does ONAP include VNFs. VNFs come from 3rd party companies or open source projects.

OK end of background. On to the four themes:

MODEL DRIVEN

The ONAP vs. Cloud blog states, “I told the ONAP people that I wasn’t interested in future briefings that didn’t focus on model-driven transformation of the ONAP architecture. Casablanca is the second release that has failed to provide that focus...” I found this statement perplexing. Model-driven is a central tenet of ONAP. In fact if anything, one might complain about there being too much model-driven thinking but not too little! There are models for:

  • VNF descriptor  
  • Network service descriptor  
  • VNF configuration  
  • Closed-loop automation template descriptor  
  • Policy  
  • APP-C/SDN-C directed graphs  
  • Orchestration workflow  
  • The big bang (just kidding)  
  • So on and so forth

The key idea of a model driven approach is to enable non-programmers to change the behavior of the platform with ease. And ONAP embraces this paradigm fully.

DEVICE ORIENTATION

The ONAP vs. Cloud blog continues, “ECOMP [as a precursor to ONAP] is following what I’ve characterized as the “device networking” vision of the future, and not the “cloud-native” vision.” The blog asserts that the lack of a model driven approach means ONAP is relegated to a device-networking approach. This couldn’t be further from the truth either. ONAP goes through great pains of creating a hierarchy and providing the highest level of abstraction to the OSS/BSS layers. The below show a couple of examples.

Service Orchestration & LCM (the left-hand side item feeds into the right-hand side item):

VF ⇛ Module ⇛ VNF  ⇛ Network/SDN service   ⇛ E2E network service ⇛ Product (future) ⇛ Offer (future)

Service Assurance:

Analytics Microservices & Policies ⇛ Closed Loop Templates

With upcoming MEC applications, the million dollar question is, will ONAP orchestrate MEC applications as well? This is to be determined, but if this happens, ONAP will be even further from device-orientation than it already is.

CLOUD NATIVE

The blog further states, “the Casablanca release is replete with comments about VNFs and PNFs, and the wording makes it clear that what ONAP is now focused on is providing the operational layer of NFV. Since NFV isn’t cloud-native, ONAP doesn’t need to be [i.e. isn’t].”

There are three sub-myths in the paragraph that surrounds the above text. First is that VNFs can’t be cloud-native. In fact they can be and ONAP highly encourages, I daresay, insists upon it (see ONAP VNF Development requirements here)? Cloud-native or containerized network functions (CNFs) are just around the corner and they will be fully supported by ONAP (when we say VNF, we include CNFs in that discussion). Second, the argument that ONAP documentation being replete with VNFs and PNFs is a net negative misses the point. ONAP refers to VNFs and PNFs since they constitute higher level services. The argument is tantamount to saying that if AWS uses the words VM or container, they need to be written off as outmoded. Moreover, new services such as 5G are expected to be built out of physical network functions (PNFs) — for performance reasons — and VNFs. Therefore, ONAP anticipates orchestrating and managing the lifecycle of PNFs. Finally, the third assertion is that VNFs not being written in a cloud-native manner is somehow indicative of ONAP being mis-architected. It is true that a large number of VNFs are VNFs-in-name-only (i.e. PNFs that have been virtualized, but not much else); however, this is orthogonal to ONAP. As mentioned above, ONAP does not include VNFs.

LACK OF INNOVATION

The final section of the above-mentioned blog can be summarized as saying that there is a lack of innovation on the ONAP side. The ONAP vs. Cloud blog offers examples such as Amazon Firecracker, Lambda and Outpost as evidence. Let’s take each one:

  • Amazon Firecracker: ONAP can already support unikernels (i.e. ridiculously small VMs) and will support Kata containers when the MultiCloud project fully supports k8s. So I don't see any issue.  
  • Lambda: Here there is some truth, ONAP can’t handle function-as-a-service. For NFV, I am not sure ONAP ever needs to support function-as-a-service. However, if ONAP ends up orchestrating MEC applications, it might have to. But I don’t view this as a showstopper. When the time comes, I’m sure the ONAP community will figure this issue out — it's not that hard of a problem.  
  • Outpost: ONAP and Outpost are different layers of the software. There are two ways they can interoperate. Today, ONAP is containerized and can run on any cloud that supports k8s. I assume Outpost will support k8s, so ONAP can already run on Outpost. Second, if an Outpost adapter is written for the ONAP MultiCloud project, ONAP will be able to orchestrate VNFs onto Outpost. It’s just a small-matter-of-programming :).

In summary, even amongst sophisticated circles there is a lot of confusion about ONAP’s ability to support a model driven, service oriented, cloud native, transformative future. Hopefully this blog clarifies some of those points.

Want to learn more about ONAP? Try Aarna.ml ONAP Distribution 1.0 (ANOD) — Development for free on GCP. Request ONAP Training