Architectural Deployment Scenarios to consider:

Management Workloads

Deployment Model	ONAP Central	Edge using certain ONAP management workload functions as an Offload
		Description	Architecture Near-term Priority
Edge and Central Provider are same	Yes for all cases	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 - High? 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 - ? Reliance Jio - ? Verizon - ? Vodafone - ?
Edge and Central Providers are different	Yes for all cases	Use Existing VPCs (VPC creation out of scope for ONAP) Rest - Same as above.	Priority - High? Rationale - Same as above. Participant Operator Priority AT&T - ? Reliance Jio - ? Verizon - ? Vodafone - ?

Managed Workloads

Deploy-ment Model	ONAP Central	Edge using certain ONAP management workload functions as an Offload			*Edge not* using ONAP Orchestration** Clarification Notes: This assumes at least a two level hierarchy for orchestration - ONAP Central Orchestrator and 3rd party Edge Orchestrator. This is specific to Service (VNF/App) Orchestration and not Cloud infrastructure orchestration. Interfacing to cloud infrastructure is already covered through ONAP multi-cloud.
		Description	Architecture Near-term Priority for VNFs	Architecture Near-term Priority for Apps	Description	Architecture Near-term Priority for VNF Orchestration	Architecture Near-term Priority for App Orchestration
Edge and Central Provider are same	Yes for all cases	Managed workloads are always instantiated by ONAP components In case the ONAP Mgmt. Offload to Edge is Analytics or Closed Loop components ONAP Central SO uses ONAP Central Multi-Cloud APIs to instantiate workloads In case the ONAP Mgmt. Offload to Edge is Orchestration components ONAP Central SO uses ONAP Edge SO APIs to instantiate workloads	Priority - High? Rationale: Analytics and closed loop offloads are key edge use cases Participant Operator Priority AT&T - ? Reliance Jio - ? Verizon - ? Vodafone - ?	Priority - Medium? Rationale: ONAP's primary focus is NFV Orch. Participant Operator Priority AT&T - ? Reliance Jio - ? Verizon - ? Vodafone - ?	ONAP Edge orchestrator should be registered in ONAP central with the service specific capabilities it can offer. This step should happen before service instantiation.	Priority - Medium? Rationale: This is more of a standardization exercise given that different NFV orchestrators typically have different APIs Participant Operator Priority AT&T - ? Reliance Jio - ? Verizon - ? Vodafone - ?	Priority - Medium? Rationale: ONAP's primary focus is NFV Orch. This is more of a standardization exercise given that different NFV orchestrators typically have different APIs Participant Operator Priority AT&T - ? Reliance Jio - ? Verizon - ? Vodafone - ?
Edge and Central Providers are different	Yes for all cases	Use Existing VPCs (VPC creation out of scope for ONAP)	Priority - High? Rationale: Same as above. Participant Operator Priority AT&T - ? Reliance Jio - ? Verizon - ? Vodafone - ?	Priority - Medium? Rationale: Same as above. Participant Operator Priority AT&T - ? Reliance Jio - ? Verizon - ? Vodafone - ?	Use Existing VPCs (VPC creation out of scope for ONAP)	Priority - Medium? Rationale: Same as above. Participant Operator Priority AT&T - ? Reliance Jio - ? Verizon - ? Vodafone - ?	Priority - Medium? Rationale: Same as above. Participant Operator Priority AT&T - ? Reliance Jio - ? Verizon - ? Vodafone - ?

Work in progress Activities

Architectural Deployment Scenarios to consider:

Management Workloads

Managed Workloads