Deployment Model

Edge using certain ONAP management workload functions as an Offload

Note: In this context, Offload is the process of moving certain functions from central to edge locations to address various requirements such a WAN bandwidth constraint, higher resiliency, real-time service assurance etc.

Edge and Central Provider are same

• Allows ONAP Central Controller function to install ONAP SW components (purely ONAP mgmt. based or 3rd party integrated with ONAP mgmt.).
• This also supports ONAP specific K8S cluster installation.

Priority - ?

Rationale:

• Analytics and closed loop offloads are key edge use cases.

Note: Analytics is currently addressed by a Distributed DCAE Orchestrator based on Cloudify.

Participant Operator Priority

• AT&T - High; To distribute DCAE services (Analytics, collectors etc.) and other ONAP components for resiliency.
• Verizon - Medium; Primarily distributed DCAE collectors and data mediation
• Vodafone - High; Distribute both DCAE and ONAP components

Edge and Central Providers are different

Note: In this case, Central provider is still managing the management functionality running at the edge, but using another operators infrastructure.

• Use Existing VPCs (VPC creation out of scope for ONAP)
• Rest - Same as above.

Note: A Virtual Private Cloud (VPC) provides a dedicated pool of compute/network/storage resources using a infrastructure as a service approach.

Same as above.

Vodafone (question): should this model be at a lower priority? For a first phase it's sufficient to enable the case where edge and central providers are the same.

Existing infrastructure that is available in ONAP •Use SDC for onboarding management applications if they are independent of VNF Or make management app also part of VNF if it needs to be dynamic •Use SO to bring up the management app like any other VNF •Leverage MC for talking to various cloud-regions of different technologies (Management App as VM or container or public cloud entity) •Leverage OOF to make placement decisions (such as HPA, affinity, anti-affinity)

Using Existing DCAE orchestration to deploy and manage lifecycle for all management application (central and edge)

DCAE orchestration supports deployments of Ms (collectors, and analytics services); primary orchestrator is cloudify. The current orchestration can be extended for supporting deployment of helm charts and Tosca_blueprints to deploy wide ranges of managed applications/services at multiple sites.

Cloud Native K8S Ecosystem - https://landscape.cncf.io/

ONAP OOM Project - Prescriptive Helm Charts for various ONAP management plane components

Yes

(Using SDC. SDC allows to define it as VNF with multiple management applications as VNFCs. SDC allows multiple VNFs in a service and there could be multiple services)

Yes

(SDC now supports Helm, based description. It is possible to introduce dependency via initContainers and helm hooks)

Yes

(SDC has a way to provide licensing information)

Partially

(SO has ability to select the cloud-region while deploying the VNF and hence same is applicable for management applications. But there is no bulk deployment by selecting multiple cloud regions.It require enhancements. But we believe this requirement is needed for NFs too)

Yes

(Complete control at the SO. One can terminate the management application bundle at any time)

Ability to deploy management applications in selected cloud regions that are not owned by ONAP operator, but has business relationship

(Examples: Public Clouds or Edge Clouds owned by some other organization)

Yes

(Multi-Cloud has ability to deploy workloads in any cloud-region - whether owned by operators or even public clouds as long as right credentials are used)

Existing OOM functionality.

Cloud regions are defined in onap-central as kube configs. Kube configs already contain credentials for communicating with any cloud region - public, private and regardless of ownership model.

Yes

(SO provides API at various granularity)

Yes

(SDC/SO with their bundling approaches - management app can be added as VFC in a VNF or as a VNF in a service)

There are 2 options.

1. The management applications that are directly related to instantiation and termination of a Service (VNFs) are an extension of the Service. Therefore it makes sense that the management applications (Helm Charts) under this scenario should remain as part of the Service Orchestration flow.
   
   
2. Alternatively, the Cloud Native approach would be to deploy all needed management applications to the cloud region but with a replicaCount=0. Only the specifications for the management applications are stored (etcd). No other resources are consumed until its replicaCount becomes > 0. This would happen in response to a monitored metric that is set (or increases) when a VNF is deployed. Likewise the management application would free all consumed resources and return to its dormant state (replicaCount=0) once the monitored metric clears (or reduces) after VNF is terminated. Horizontal scalability and the Custom Metric APIs, are existing Kubernetes capabilities.

Yes

(SDC supports adding default Day0 configuration of workloads)

Yes

(SDC supports multiple Day0 profles - either through customization or as artifacts in case of K8S)

Yes

(Supported through Policy/DCAE)

Yes

(SO can talk to OOF to get the right flavor for workloads in a VFM)

Yes

(Work is going on in K8S plugin to ensure that Day 2 configuration is also supported as Helm charts as Day0 configuration. This is made possible due to microservices supporting K8S operators for their configurations)

Yes

(APPC support for Day2 configuration. Also Day2 configuration support in K8S plugin - Ongoing. One can select cloud-region, instance while applying Day2 configuration)

Yes

(In case of K8S world, as long as day2 configuration is also supported via K8S resources, it is possible. K8s Plugin does support this)

The Cloud Native approach would be to deploy all needed management applications to the cloud region but with a replicaCount=0. Only the specifications for the management applications are stored (etcd). No other resources are consumed until its replicaCount becomes > 0. This would happen in response to a monitored metric that is set (or increases) when a VNF is deployed. Likewise the management application would free all consumed resources and return to its dormant state (replicaCount=0) once the monitored metric clears (or reduces) after VNF is terminated. Horizontal scalability and the Custom Metric APIs, are existing Kubernetes capabilities.

Yes

(Using SSL/TLS)

N/A

This is an application requirement and not a requirement of the Platform Orchestrator.

Application needs to support SSL/TLS.

Yes

(No restriction. it is based on management application)

N/A

This is an application requirement and not a requirement of the Platform Orchestrator.

Partial

(Same monitoring schemes as available for VNFs, but suggest that all management components acts prometheus target)

Yes

(but testing is required with a use case to ensure that there are no gaps)

(This work is slated for Release E - configuration of ISTIO for L7 workloads and NSM for L2/L3/L4 workloads)

Even though K8S can bring up more instances, traffic distribution is expected to be configure properly)

Yes

(relies on k8s)

Yes

((but testing is required with a use case to ensure that there are no gaps)

(This work is slated for Release E - configuration of ISTIO for L7 workloads and NSM for L3/L3/L4 workloads)

Loss of functionality requires careful configuration of traffic rules of ISTIO or NSM)

Yes

(relies on k8s)

Yes

(It is part of K8S)

Yes

(relies on k8s)

Support for ONAP-compliant third party management applications that provide similar functionality as ONAP management applications.

• Some of the key aspects of ONAP-compliance include but are not limited to the following - API compatibility, Cloud Native Packaging in ONAP Helm chart format etc.

Yes

(As long as third party management applications are described using Helm)

Yes

(helm chart deployment will be supported via new helm plugin contributed for Dublin (the policy reconfiguration will require complying to onboarding req#1)

Yes

(Using K8S plugin)

Yes

(Using K8S plugin)