ONAP Bulk PM collection using IPv 4 IPv

ONAP Bulk. PM collection using IPv 4/ IPv 6 Dual-Stack Damian Nowak (Nokia) (support: Krzysztof Kosewski, Ben Cheung)

Agenda Perf monitoring data collection - Bulk. PM using IPv 6 • Motivation & problem statement • Technical alternatives & selected solution • Demo • Current progress – and evolution

Motivation Majority of 5 G RAN networks globally are running using IPv 6. • Including transport and OAM interfaces • In all three – physical, virtualized and containerized environments • Typical requirement of Tel. Co operators (not that common in enterprise space) ONAP (before Guilin release) was not really deployed in IPv 6. • We`ve seen questions around that in the community, but no examples, and no references • If ONAP is expected to serve as reference ORAN SMO, it must support IPv 6 (as other elements).

Problem statement – ONAP Bulk. PM use-case POST https: //[IPv 6_address]: 30471/event. Listener/v 7 REST over IPv 6 "event": { "notification. Fields": { "location": "sftp: //admin: admin@[IPv 6_address]: 22/pm. xml. gz", } } VES 1 IPv 6 ORAN BTS DMaa. P MR 2 DFC Kubernetes Platform (RKE in ONAP) Today (before Guilin) IPv 4 only sftp admin@[IPv 6_address]: 22 S/FTP over IPv 6 sftp> get pm. xml. gz Fetching /pm. xml. gz sftp> exit • • Network connections over IPv 6 Messages contain references to IPv 6 locations (S/FTP server)

Problem statement ONAP framework platform overview • ONAP platform configuration based on IPv 4 only • No known examples of IPv 6 configurations • ONAP using Rancher Kubernetes Engine distribution • No documented IPv 6 configuration scenarios • Certain relevant parts of the configuration covered with Rancher automation scripts • Within ONAP/Frankfurt, Kubernetes 1. 15 used • Initial IPv 6 features introduced in Kubernetes 1. 9 • Very little information on IPv 6 within Kubernetes <= 1. 15 • Most IPv 6 and IPv 4/IPv 6 dual stack configuration descriptions in Kubernetes 1. 16+ • Many IPv 6 features still in alpha status @Kubernetes (esp. IPv 4 / IPv 6 dual stack)

Problem statement: Requirement Core requirement: Bring IPv 6 support at least on external ONAP <-> ORAN interfaces ONAP backlog requirement (REQ-385): IPv 4/IPv 6 dual stack support in ONAP

Technical solution alternatives • Deploy an IPv 4/IPv 6 NAT between ORAN BTS and ONAP • Deploy ONAP in Kubernetes (K 8 S) IPv 6 -only environment • Deploy ONAP in Kubernetes IPv 4/IPv 6 dual stack environment • Deploy ONAP`s DCAE platform in a dedicated IPv 4/IPv 6 K 8 S Cluster (and keep other components in Central K 8 S Cluster running on IPv 4)

Technical solution alternatives – discussion (NAT) • Deploy an IPv 4/IPv 6 NAT between ORAN BTS and ONAP OAM NW Pros: • Fairly easy to implement • No ONAP modifications • No ORAN BTS modifications Bulk. PM: { File. Ready: „sftp: //<<IPv 6>>… } „sftp: //<<IPv 6>>… …. Error: „No route to host” ORAN BTS DMaa. P MR DFC K 8 S 1. 15/RKE IPv 6 -> IPv 4 NAT IPv 6 network VES ONAP on Kubernetes IPv 4 network We decided not to continue. Although this approach will work for simple use-cases, like VES events, more complex use-cases using call-backs will not really work. Cons: • Additional solution module needed • No support for protocols, which contain network service locations, e. g. callbacks

Technical solution alternatives Discussion (IPv 6 -only) • Deploy ONAP in Kubernetes (K 8 S) IPv 6 -only environment K 8 S control plane K 8 S user plane IPv 6 external K 8 S-controller-0 K 8 S-controller-1 VES Port: 8443 K 8 S-controller-2 DMaa. P Port: 8443 K 8 S-worker-0 VES DFC (Client) K 8 S-worker-1 DFC IPv 6 external We decided not to continue on this approach. Result: Vid-Maria-Galera, Cassandra, AAF, CFY-Manager not compatible. Components using AAF/CADI not compatible (AAF dependency). Pros: • A native future-proof solution • Relatively easy configuration • Relatively mature solution (compared to dual stack) Cons: • Many modifications across different ONAP modules • No support for IPv 6 -only in ONAP`s recommended RKE

Technical solution alternatives Discussion (IPv 4/IPv 6 DS) • Deploy ONAP in Kubernetes (K 8 S) IPv 4/IPv 6 dual stack environment K 8 S control plane K 8 S user plane IPv 4 internal IPv 6 interrnal K 8 S-controller-0 K 8 S-controller-1 VES Port: 8443 K 8 S-controller-2 DMaa. P Port: 8443 K 8 S-worker-0 DFC (Client) K 8 S-worker-1 VES DFC IPv 6 external IPv 4 external We decided to leverage this approach (using K 8 S 1. 18). Default traffic on IPv 4, selected external traffic on IPv 6. Result: Majority of ONAP components working properly. Still issues with SDN-R/Elastic and some Cassandra DBs. Pros: • Works with majority of ONAP • Allows for stepwise migration • Better dual stack support in newer K 8 S versions (1. 18/1. 19) Cons: • Configuration more complex, than IPv 6 only • Limited networking plugin support (Calico only) • IPv 4/IPv 6 dual stack still in alpha status @K 8 S 1. 18

Technical solution alternatives Discussion (Remote DCAE) • Deploy ONAP`s DCAE platform in a dedicated IPv 4/IPv 6 K 8 S Cluster ONAP Central SDNR SO Pros: • Only selected ONAP components must support IPv 6 • Prepares ONAP for deployments at scale Policy Kubernetes platform (IPv 4) ONAP DCAE (remote) DMaa. P VES ORAN BTS DFC Kubernetes platform (IPv 6/IPv 4) We decided to drop this approach (IPv 4/IPv 6 dual stack approach was good enough) Cons: • Fairly complex configuration • Potential issues accessing centralized components • Limited experience in dedicated DCAE sites set-up

Technical solution alternatives Selected approach ü Deploy ONAP in Kubernetes (K 8 S) IPv 4/IPv 6 dual stack environment K 8 S control plane K 8 S user plane 2 3 IPv 4 internal IPv 6 interrnal VES K 8 S-controller-0 K 8 S-controller-1 Port: 8443 K 8 S-controller-2 IPv 4 external Port: 8443 K 8 S-worker-0 VES IPv 6 external DMaa. P 1 DFC (Client) Work done: • Migrated ONAP OOM components to support K 8 S 1. 16+ • Updated ONAP DCAE to work with K 8 S 1. 16+ • Co-work with ONAP SDN-R team • Prepared custom K 8 S environment w/DS support K 8 S-worker-1 DFC 4 ORAN BTS

Demo ü ONAP DCAE collecting Bulk. PM data using IPv 6 networking

Current progress & evolution ü ONAP Guilin release ü Foundation built by adapting OOM and DCAE project to support K 8 S 1. 16+ ü Built custom Dual-stack K 8 S 1. 18 cluster ü Verified Bulk. PM collection in IPv 6 external network ATTENTION: ONAP/GUILIN STILL UNDER DEVELOPMENT (GA Nov 2020) q ONAP Honolulu release and beyond q q q Identify ONAP components, which still have issues on IPv 4/IPv 6 (e. g. Cassandra) Update deployment scripts/move to public 3 rd party images/ use common DB instances Test SDN-C/SDN-R component (as a client to ORAN BTS) Update the standard K 8 S installation in ONAP CI/Gating environment Decide on the future K 8 S distro recommended to run ONAP (if RKE won`t offer IPv 6) (or create manual installation procedure)

Lessons learnt / Best practice ü Avoid using custom 3 rd party app images ü We mainly found issues with custom-built images for Cassandra, Maria. DB, and other 3 rd parties ü Usually “released” Docker images are prepared to run in different environments (IPv 4/v 6/…) ü Observe Kubernetes landscape ü Quite a lot of development happening around IPv 6 and dual-stack networking ü Kubernetes 1. 19 coming with certain improvements ü Select stepwise approaches ü Allow for flexibility and re-prioritization ü Avoid big-bang integrations ü Bring new value with each contribution, and not only after all contributions are completed.

Questions? Answers!

Thank you