Description of Use Case / Requirement:

Majority of LTE and 5G RAN networks today are running exclusively on IPv6. IPv4/IPv6 dual stack solution for ONAP is needed to enable integration.

It is mainly about a Kubernetes platform, hosting ONAP application containers.
An enabler for IPv4/IPv6 networking would be an upgrade of ONAP OOM Helm charts to K8S 1.16+ APIs.
The support for IPv4/IPv6 dual stack networking is planned to be executed in (at least) two-three steps:

1. Migrate ONAP OOM Helm charts to support Kubernetes 1.17+ interfaces.
   1. Currently (June 2020), the newest K8S platform available as RKE distribution is 1.17.
   2. Newest K8S open-source GA distro is 1.18 (as of July 2020), next vanilla K8S - 1.19 - is planned in August 2020.
2. Alternatively, certain ONAP collectors, which are deployed using non-Helm methods could be placed on a dedicated K8S platform with IPv4/IPv6 support
   1. Within ONAP/Dublin, there was a PoC executed following this approach, see: https://wiki.onap.org/display/DW/Remote+K8s+cluster+deployment+of+DCAE+MS
3. Review alternative K8S platforms, which can get an "ONAP recommended" stamp, and which support IPv4/IPv6 dual stack networking. RKE is not such a platform as of today.

Guilin scope
The 1st (and/or 2nd step) step described is considered as an enabler to execute the 3rd step - target goal of IPv4/IPv6 capable platform.
In ONAP/Guilin release, it is planned to implement the 1st step - migrate from K8S 1.15 --> K8S 1.17, which requires:

• OOM Helm charts migration to use app/v1 API
• DCAE CFY Blueprint plugin update to interact with K8S 1.15 and 1.17 at the same time.

Initial tests targeting ONAP Frankfurt on RKE-K8S 1.17 have been executed, and impact is already understood.
Additionally, K8S 1.17+ upgrade will offer as well additional functionality on the platform side, which can be used for other purposes.
Within ONAP/Guilin project, there is no plan to move away from RKE-K8S platform (just an update to RKE-K8S 1.17/1.18).

Honolulu scope
The target for Honolulu is to update all ONAP components, which do not install/execute properly in IPv4/IPv6 dual stack environment.
As of today, the following components are affected:

• SDN-R Elastic Search module
• Portal MariaDB database
• SDC/AAI Cassandra database
• DCAE - CFY Plugin - support exposing services using IPv6
• This might not be a full, comprehensive list.
  Additionally, we`d like to make sure, that ONAP CI/Gating environment is running RKE-Kubernetes 1.18.x (at least).

Beyond Honolulu
A migration to an alternative platform supporting dual stack K8S networking will be a matter in a future release.

Owners (one of these should be the Assignee - use @ notation): deen1985 demx8as6 kopasiak sdesbure

Link to HLD/LLD (if any):
None

Dependency Relationships with Other Projects:
Main work is planned in the OOM project, which contains Helm charts used to deploy ONAP components.
On top of that, DCAE collectors / service components are deployed using a Cloudify orchestrator, which interacts with K8S API.
As a result we have an impact to DCAE project.

Proposed proceeding related to this requirement (in context of dependencies):

1. Update the Helm charts to support K8S 1.17 API
2. Test the updated Helm charts using K8S 1.15
3. Update the DCAE CFY Blueprint Plugin to support K8S 1.15 and 1.17 APIs
4. Test the DCAE CFY Blueprint Plugin on K8S 1.15 and K8S 1.17
5. Update the basic RKE-K8S platform to use K8S 1.17/1.18 (Helm Charts + CFY DCAE K8S plugin).

Project Impact (Test Only (TO), Code (C)):
OOM (C)
DCAE (C)
Integration (TO)

Support Status for each Affected Project (Supported (S); Partially Supported (P); Not Supported (N)):
Note: for any affected projects labeled 'P' or 'N', please document the resulting gaps.

OOM: P (Partially supported)
We`ve been able to verify, that some Helm charts do not need modifications to run on K8S 1.17 (3 pcs).
Helm charts would have to be updated to integrate with K8S 1.17 APIs.
Nokia contribution: 1-2 people.
Orange contribution: 1 person
Samsung contribution: review support
HighStreet contribution: mainly SDN-R charts

DCAE: P (Partially supported)
DCAE CFY K8S Plugin component will need update to support K8S 1.15 and 1.17 APIs in parallel.
Nokia contribution to support this: 1-2 people.

INTEGRATION: P (Partially supported)
Regression tests to be executed, after initial upgrade to K8S 1.17, across entire ONAP platform.
Nokia contribution: 1 person
HighStreet contribution: 1 person (SDN-R focus)

Integration Leads (use @ notation): dmilaszkiewicz

Company Engagement:

• Nokia
• Orange
• Samsung
• highstreet