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:
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:
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.
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.
VF ⇛ Module ⇛ VNF ⇛ Network/SDN service ⇛ E2E network service ⇛ Product (future) ⇛ Offer (future)
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.
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.
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:
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 Networks ONAP Distribution 1.0 (ANOD) — Development for free on GCP. Request ONAP Training
