ONAP Cloud Native Journey

Plan and Next Steps

• Align ONAP Community on its role and relationship to the Cloud Native ecosystem
  • TSC Task force initiated to define on ONAP’s CNF strategy including

  #1 What benefits ONAP itself gained by going cloud native

  #2 How we want ONAP to enable CNFs (hybrid, ONAP Lite)

  #3 What ONAP's value proposition is in the overall LFN family (ONAP/CNTT/OPNFV etc.

• Include “ONAP-CNCF” to the CNCF Cloud Native Interactive Landscape.
  • Discussion being kick-off with LF (Arpit Joshipura)
• Promote ONAP’s CNF strategy through LF Events (ONES, DDF etc.) and press release(s)
  • CFP submitted for ONES NA
• First implementation of ONAP CNCF as part of the Guilin Release (Nov 2020?)

OVP / Cloud Native Journey

2/12 (presented by Arpit): VNF-CNF OVP - 2 key slides.pptx

2/27 (updated deck with Ciaran, Ranny, Seshu, Timo, Alla): VNF-CNF OVP - 2 key slides_V3.pptx

2/28: (updated deck - orange box is now generic - was previously missing SDC ): VNF-CNF OVP - 2 key slides_V4

3/3: (updated with CNF Task Force): VNF-CNF OVP - 2 key slides_V5

Role of ONAP

Role of ONAP (which is a central automation platform) across multiple Clouds & Edges.

1. Distributed Applications: Telco world is known to have requirement to support ‘network services’ whose components (VNFs today) spread across multiple computing regions (Openstack based regions).  Hence, the need for central orchestrator that orchestrates various VNFs of the network service in multiple openstack based computing regions.  With edge-computing,  even normal applications are becoming distributed, where a few microservices of the application are deployed across multiple edges & a few in network edges and public clouds. Essentially, applications are becoming more like network services.
2. Convergence of applications and network functions due to Edges : Edge world can’t afford to have two computing environments – One for normal applications and another one for network functions. This is due to resource constraints. Since many edge-computing efforts in Industry adopted K8s, it is natural to think about supporting network functions and use same K8s cluster for both. It appears that a few MEC applications even require some network functions to be deployed along with them (Example include MEC applications with network security functions).
3. Network function deployments and life cycle management are more complex than the applications due to need for supporting multiple interfaces, provider networks,  service function chaining. ONAP is solving many of these challenges.
4. Support for Multiple Cloud technologies :  Supporting legacy Openstack deployments with greenfield  K8s deployments are needed.  ONAP solves these multi-cloud challenges.
5. Support for Telco infrastructure such as OSS/BSS – ONAP is already in the path to support various MEF standards on its north side to support standardization between OSS/BSS and Orchestrators.
6. Support for monitoring of distributed applications and closed loops :  Monitoring distributed applications that are deployed across multiple edges/clouds is complex.  There is need for showing the comprehensive status at the application level instead of at each resource level.  ONAP monitors the services/distributed-apps and not only provides simpler view of the status, but also can run through various analytics engines and even act on the actionable insights.

Note:  ONAP4K8s is a profile of ONAP for Enterprise/IOT (Including Private-5G/LTE)  market that have requirement of deploying CNFs/VNFs along with normal applications in multiple K8s based clusters.

In addition, we believe that ONAP can provide additional values as follows:

#1 NF Control Loop

#2 NF Common Inventory

#3 NF Data collection and analytics

#4 Support of PNFs

#5 Cover the design of services as well as the orchestration of services, design of control loops

#6 Play a role in terms of standardizations (TMForum, ETSI ZSM, MEC etc.) through our ONAP Technical Coordinators

To recap, we can provide significant automation values to handle applications on top of the K8S environment.

Areas of Focus

#1 ONAP 'Light" Weight - Review our current ONAP projects (see Lifecycle review led by Jason/Chaker)

#2 ONAP4K8S, Containerization 

#3 Identify ONAP Requirements +  to support CNFs for Guilin

#4 E2E Integration (OVP)

#5 VNFREQS => CNFSREQS - Certification CNF requirements - need to align with the ONAP Architcture + ONAP SECCOM regarding Cloud Native.

Features/Capabilities - How We complement each other to support CNF?

Features/Capabilities	K8S Environment	CNTT/Arch Ref.2	ONAP (Today)	ONAP CNCF	Comments
CNF Scalability	From an Orchestration perspective: Cluster Autoscaler, HPA and VPA Handling within its own cluster From an Automation, Control Loop (CL) perspective		OOF, SO, Multi-Cloud CL (DCAE, Policy, CLAMP + Triggered Action)	Adding value: Handling multiple K8S, Clusters See "SO enhancements to support CNF" presentation (3/17)	Not ONAP Scalability itself otherwise MUSIC, OOM (Container Orchestration)
CNF Resiliency	From an Orchestration perspective: K8S Services From an Automation, Control Loop (CL) perspective		OOF, MSO, Multi-Cloud CL (DCAE, Policy, CLAMP + Triggered Action)	See "SO enhancements to support CNF" presentation (3/17)	Not ONAP Resiliency itself otherwise MUSIC, OOM (Container Orchestration)
CNF Availability	Public Cloud is currently offering <99.999			Opportunity for ONAP	Not ONAP availability itself otherwise 99.9999+ built inside ONAP
Onboarding/Provisioning  Design Time			SDC/VID/CDS	SDC/CDS	ONAP Portal/UUI to be re-assessed
Secured service-to-service communication	Additional SW to be uploaded on top of K8S: Linkerd, ISTIO,		AAF (VNFs only)	Integrate our ONAP Apps to Service Mesh  while keeping AAF as optional Service Mesh between ONAP/CNFs	Do we provide any certificate or shall we rely on a Certification Manager?
Logging	Stackdriver Logging Elasticsearch Fluentd		Logging/Pomba EELF/ELK		Centralization of Logging - ONAP feature or external system to ONAP?
Dashboard			OOM - Consul
Observability Events, Alarms, Analytics	Prometheus - https://prometheus.io/ Open-source systems monitoring and alerting toolkit Jaeger - https://www.jaegertracing.io/ As on-the-ground microservice practitioners are quickly realizing, the majority of operational problems that arise when moving to a distributed architecture are ultimately grounded in two areas: networking and observability. It is simply an orders of magnitude larger problem to network and debug a set of intertwined distributed services versus a single monolithic application. based on grafana technologies (UI part)		DCAE	Specific VES Integration with Promotheus and Grafana technologies (UI) as POC by AT&T	-Check the CNF Conformance to understand what are the requirements -Shall we integrate one of the open sources to DCAE (like we did with PNDA) or shall we create DCAE CNCF version?
Inventory CNFs Storage	Secured mechanism to store/inject CNF images (Extension to Artifactory - Separate virtual repos)		AAI	CNF Inventory A&AI could also be used for Control Loop (future feature candidate?)	Under investigation
Security	K8S Airbag, kubectl		SECCOM	CNF Security Requirements  Ingress Controllers	How to address Networking back to provider network Expansion of Container Security for K8S (out of scope from SECCOM?)
Tracing	OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from your application. You can analyze them using Prometheus, Jaeger, and other observability tools. - https://opentelemetry.io/		DCAE	DCAE - Telemetry under assessment	CNF Compliance: The CNF supports OpenTelemetry-compatible tracing – Does the CNF generate Open Telemetry compliant data? – Is there traffic to Jaeger?
Performance
Network Interfaces	Dual Stack Network:  IPv4 K8s cluster with IPv4 pods and services   IPv6		SDNC/APPC/CCSDK (CDS)	Re-use K8S & existing infra	We need to understand what role does ONAP play for CNF networking. Is it exposed to CNI plugin choice? Multiple interface containers? etc. DPDK SRIOV
Adapt our CI/CD - Toolchain				E2E Testing - Working jointly under OVP PH2 (OPNFV, CNTT, VTP, ONAP/VVP/VNFSDK)

Where are we on the CNCF Trail Journey?

CNF Deployment 

#1 Workload Considerations - POD and Host Strategies

• Separate POD 
• Shared POD
• Shared Host (with VNFs)

#2 HW Requirements

• Persistency
• Performance Optimization (Compute, Storage) - Generic or Special HW?
• Multi-Tenancy @Storage, Networking, Resource maangement
• Security - check with SECCOM

#3 Testing Considerations

• Canary Testing - Rolling upgrades
• Chaos Monkey Testing
• Performance

Pre-requisite(s)

• Is there any available CNF that we could use to prototype/test with "ONAP CNCF"?
• Check this link about CNF Testbed-https://github.com/cncf/cnf-testbed
• Check with OPNFV - if any investigation in this area

Requirements 

We need to identify non functional reqs for ONAP Itself and for ONAP to orchestrate CNFS 
(Rework the below reqs into these two categories)

#1 Need to deploy ONAP/ONAP CNCF on component basis not as a whole
#2 Move to Service Mesh
#3 Optimization of DB - leverage some storage, DB capabilities offered by existing Cloud solution
#4 Scalability, Reliability based on K8S services (?). 
   Not replacing K8S but built on top of K8S.
#5 API between components

Later on, how our "ONAP CNCF" will look like to support CNFs

First Use Case(s) for Guilin (Initial proposals)

• CNF ClearWater IMS image (available from OPNFV) - https://gerrit.opnfv.org/gerrit/c/functest-kubernetes/+/69775
• cFW Bin Yang - POC in progress -
  • https://gerrit.onap.org/r/gitweb?p=multicloud/k8s.git;a=tree;f=starlingx/demo;h=44ab83ca5c5c9f01082695b1aa9a6e71fdaeec20;hb=HEAD
  • https://wiki.onap.org/download/attachments/8227952/cFWv1.pptx?version=1&modificationDate=1583849314000&api=v2
  • https://wiki.onap.org/download/attachments/8227952/How-ONAP-Orchestrates-CNF-to-WRCP-v1.2.pdf?version=1&modificationDate=1583849342000&api=v2
    
• ETSI CNF path (Verizon and Ericsson)
• Consider some key CNF Security requirements as part of our initial use case(s)

Links

https://github.com/kubernetes-sigs/kubefed -- K8S across multiple clusters

https://pivotal.io/cloud-native 
https://techbeacon.com/app-dev-testing/5-critical-elements-building-next-generation-cloud-native-apps
https://medium.com/faun/15-best-practices-to-design-cloud-native-modern-applications-a2aa9f19cda0
https://hackernoon.com/writing-sky-high-applications-a-guide-to-cloud-native-development-9f3c1c020471

https://codilime.com/vnfs-in-cnfs/

https://www.cisco.com/c/en/us/solutions/service-provider/industry/cable/cloud-native-network-functions.html#~introduction

https://wiki.lfnetworking.org/display/LN/OVP+2.0+Boot+Strap