{"id":68974,"date":"2018-12-14T12:55:21","date_gmt":"2018-12-14T12:55:21","guid":{"rendered":"http:\/\/www.sickgaming.net\/blog\/2018\/12\/14\/onap-myths-debunked\/"},"modified":"2018-12-14T12:55:21","modified_gmt":"2018-12-14T12:55:21","slug":"onap-myths-debunked","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2018\/12\/14\/onap-myths-debunked\/","title":{"rendered":"ONAP Myths Debunked"},"content":{"rendered":"<div><img decoding=\"async\" src=\"http:\/\/www.sickgaming.net\/blog\/wp-content\/uploads\/2018\/12\/onap-myths-debunked.jpg\" class=\"ff-og-image-inserted\" \/><\/div>\n<p>The Linux Foundation\u2019s Open Network Automation Platform (<a href=\"http:\/\/onap.org\/\">ONAP<\/a>) is well into its third 6-month release (Casablanca came out in Dec \u201918), and while the project has evolved since it\u2019s first release, there is still some confusion about what it is and how it\u2019s architected. This blogs takes a closer look at ONAP, under-the-hood, to clarify how it works. \u00a0<\/p>\n<p>To start, 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\u2019t really care whether the NFV cloud is OpenStack, Kubernetes or Microsoft Azure. Nor does ONAP include VNFs. VNFs come from third-party companies or open source projects but have VNF guidelines and onboarding SDKs that ease the deployment. In other words, ONAP is a modular platform for complete Network Automation.<\/p>\n<p>OK, end of background. On to four themes:<\/p>\n<p><strong>MODEL DRIVEN<\/strong><\/p>\n<p>Model-driven is a central tenet of ONAP. If anything, one might complain about there being too much model-driven thinking but not too little! There are models for:<\/p>\n<ul>\n<li>\n<p>VNF descriptor<\/p>\n<\/li>\n<li>\n<p>Network service descriptor<\/p>\n<\/li>\n<li>\n<p>VNF configuration<\/p>\n<\/li>\n<li>\n<p>Closed-loop automation template descriptor<\/p>\n<\/li>\n<li>\n<p>Policy<\/p>\n<\/li>\n<li>\n<p>APP-C\/SDN-C directed graphs<\/p>\n<\/li>\n<li>\n<p>Orchestration workflow<\/p>\n<\/li>\n<li>\n<p>The big bang (just kidding)<\/p>\n<\/li>\n<li>\n<p>So on and so forth<\/p>\n<\/li>\n<\/ul>\n<p>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.<\/p>\n<p><strong>DEVICE ORIENTATION<\/strong><\/p>\n<p>ONAP goes through great pains of creating a hierarchy and providing the highest level of abstraction to the OSS\/BSS layers to support both a cloud-based and device-based networking approach. The below show a couple of examples.<\/p>\n<p>Service Orchestration &amp; LCM (the left-hand side item feeds into the right-hand side item):<\/p>\n<p>VF \u21db Module \u21db VNF \u00a0\u21db Network\/SDN service \u00a0\u00a0\u21db E2E network service \u21db Product (future) \u21db Offer (future)<\/p>\n<p>Service Assurance:<\/p>\n<p>Analytics Microservices &amp; Policies \u21db Closed Loop Templates<\/p>\n<p>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.<\/p>\n<p><strong>CLOUD NATIVE<\/strong><\/p>\n<p>ONAP Casablanca is moving towards an emphasis on cloud native; so what does that mean for virtual network functions (VNFs), \u00a0or ONAP\u2019s ability to provide an operational layer for NFV? To break it down more specifically:<\/p>\n<ul>\n<li>\n<p><em>Can VNFs be cloud native?<\/em> Yes! In fact they can be, and ONAP highly encourages, I daresay, insists upon it (see ONAP VNF Development requirements <a href=\"https:\/\/docs.onap.org\/en\/casablanca\/submodules\/vnfrqts\/requirements.git\/docs\/Chapter4\/index.html\">here<\/a>). 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).<\/p>\n<\/li>\n<li>\n<p><em>ONAP documentation includes references to VNFs and PNFs &#8211; does that mean there is no room for CNFs?<\/em> ONAP refers to VNFs and PNFs since they constitute higher level services. This would be 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) \u2014 for performance reasons \u2014 and VNFs. Therefore, ONAP anticipates orchestrating and managing the lifecycle of PNFs. <\/p>\n<\/li>\n<li>\n<p><em>Is the fact that VNFs are not always written in a cloud-native manner mean that ONAP has been mis-architected?<\/em><em> <\/em>\u00a0It 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.<\/p>\n<\/li>\n<\/ul>\n<p><strong>LACK OF INNOVATION<\/strong><\/p>\n<p>We\u2019ve also heard suggestions that ONAP lacks innovation. For example, there have been questions around the types of clouds supported by ONAP in addition to OpenStack and different NFVI compute instances in addition to virtual machines. In fact, ONAP provides tremendous flexibility in these areas:<\/p>\n<ul>\n<li>\n<p><em>Different clouds <\/em>\u2014\u00a0There are two levels at which we can discuss clouds. First, clouds that ONAP can run on, and second clouds that ONAP can orchestrate VNFs onto. Since ONAP is already containerized and managed using Kubernetes, the first topic is moot. ONAP can already run on any cloud that supports k8s (which is every cloud out there). For the second use case, the ONAP Casablanca release has experimental support for Kubernetes and Microsoft Azure. There is no reason so believe that this new cloud types like AWS Outpost etc. can\u2019t be supported.<\/p>\n<\/li>\n<li>\n<p><em>Different compute types <\/em>\u2014\u00a0Currently, ONAP instantiates VNFs that are packaged as VMs. With this, ONAP already supports unikernels (i.e. ridiculously small VMs) should a VNF vendor choose to package their VNF as a unikernel. Moreover, ONAP is working on\u00a0full K8s support that will allow container and Kata Container based VNFs. The only compute type that I think is not on the roadmap is function-as-a-service (aka serverless). But with an NFV use case I don\u2019t see the need to support this compute type. Maybe if\/when ONAP supports MEC application orchestration, it will need to do so. I don\u2019t view this as a showstopper. When the time comes, I\u2019m sure the ONAP community will figure out how to support function-as-a-service \u2014 it&#8217;s not that hard of a problem.<\/p>\n<\/li>\n<li>\n<p><em>Different controllers <\/em>\u2014\u00a0Through the use of message bus approach, ONAP has a set of controllers optimized for layers of\u00a0SDN\/NFV\u00a0(physical, virtual, application).<\/p>\n<\/li>\n<\/ul>\n<p>In summary,\u00a0it is always important to make sure you are aware\u00a0of ONAP\u2019s ability to support a model driven, service oriented, cloud native, transformative future. Hopefully this blog clarifies some of those points.<\/p>\n<p class=\"font_9\"><em>This article was written by Amar Kapadia and\u00a0was previously published at <a href=\"https:\/\/www.aarnanetworks.com\/single-post\/2018\/12\/13\/Four-ONAP-Myths-Debunked\">Aarna Networks<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>The Linux Foundation\u2019s Open Network Automation Platform (ONAP) is well into its third 6-month release (Casablanca came out in Dec \u201918), and while the project has evolved since it\u2019s first release, there is still some confusion about what it is and how it\u2019s architected. This blogs takes a closer look at ONAP, under-the-hood, to clarify [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":68975,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40],"tags":[],"class_list":["post-68974","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux-freebsd-unix"],"_links":{"self":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/68974","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/comments?post=68974"}],"version-history":[{"count":0,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/68974\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media\/68975"}],"wp:attachment":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media?parent=68974"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/categories?post=68974"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/tags?post=68974"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}