Title Distributed Management ONAP3 rd Party Arch Approach

Title: Distributed Management (ONAP/3 rd Party) Arch Approach Finalization for Frankfurt Source: ONAP Architecture Task Force on Edge Automation - Lead: VMware - Core Team: Amdocs, AT&T, Bell Canada, Intel, Orange, Verizon, VMware, Vodafone - Others: Huawei, Fujitsu, Nokia, Red Hat, Swisscom, Telecom Italia - Date: June 2019 - Link: https: //wiki. onap. org/display/DW/Edge+Automation+through+ONAP+-+Distributed+Management+%28 ONAP+etc. %29+components

Requirement Finalization Recap

Distributed Management (ONAP/3 rd Party) – Near-term Functional Mapping Mgmt. Central Containers (Primary) and VMs (Secondary) on K 8 s Cloud A&AI CLAMP OOF SDC 1. Consolidated View 4, 5. SDC Helm/TOSCA Integration Containers (Primary) and VMs (Secondary) on K 8 s Cloud ONAP Apps 1. Central Consolidated view – mgmt. apps for a given design flow could be in central and/or edge 5. Design Flow Integration (excludes basic ONAP components, e. g. SO) 6. Control Loop Flow Integration 3 rd Party (excludes basic ONAP components. , e. g. SO) – Start small with some mgmt. apps in Central and some in Edge 4. SDC/CLAMP TOSCA (Note 2) Support Mgmt. Edge/Regional 4, 6. CLAMP Helm/TOSCA Integration Near-term Requirements Containers (Primary) and VMs (Secondary) on K 8 s Cloud ONAP Apps 3 rd Party Note 1: In the near-term, different apps may use different config mechanisms – e. g. Consul or K 8 S Config map or K 8 S Secret for config store Note 2: This could be ETSI SOL 001 based. Need to confirm with SDC team. 3 rd Party Operator Feedback: AT&T, Bell Canada, Orange, Swisscom, Verizon, Vodafone, TIM Ref: https: //wiki. onap. org/display/DW/Edge+Automation+through+ONAP+Arch. +Task+Force+-+Distributed+Management+%28 ONAP+etc. %29+components#Edge. Automationthrough. ONAPArch. Task. Force. Distributed. Management(ONAPetc. )components-Requirements. Needing. Operator. Feedback 3

Distributed Management (ONAP/3 rd Party) – Long-term Functional Mapping Mgmt. Central Containers/VMs on Any Cloud (K 8 s, Open. Stack etc. ) A&AI OOF CLAMP SDC 1. Consolidated View 3 rd Party 4, 5. SDC Helm/TOSCA Integration 3. Central/Edge – 2. Central/Edge – Same Config Mechanism – Policy Mechanism & DMaa. P integration Mgmt. Edge/Regional Containers/VMs on Any Cloud (K 8 s, Open. Stack etc. ) ONAP Apps 4, 6. CLAMP Helm/TOSCA Integration Containers/VMs on Any Cloud (K 8 s, Open. Stack etc. ) ONAP Apps Long-term Requirements 1. Central Consolidated view 5. Design Flow Integration 6. Control Loop Flow Integration – Expand to use cases where all mgmt. apps are in edge 4. SDC/CLAMP TOSCA Support 2. Converge on Central/Edge same Config Mechanism a) Helm mgmt. apps b) TOSCA mgmt. apps (Note 3) 3. W. r. t to 2), Policy & DMaa. P integration 8. Non-K 8 S Cloud Support Note 3: Config mechanisms could differ for Helm and TOSCA mgmt. apps 3 rd Party Operator Feedback: AT&T, Bell Canada, Orange, Swisscom, Verizon, Vodafone, TIM Ref: https: //wiki. onap. org/display/DW/Edge+Automation+through+ONAP+Arch. +Task+Force+-+Distributed+Management+%28 ONAP+etc. %29+components#Edge. Automationthrough. ONAPArch. Task. Force. Distributed. Management(ONAPetc. )components-Requirements. Needing. Operator. Feedback 4

Distributed Management (ONAP/3 rd Party) - Others • Out of scope for ONAP - 7. Install Relevant Cloud (K 8 s or other) if not present • Independent deep dive topic • Handling Disconnected Edge • Configuration out of sync etc. • Applies to managed workloads also 5

Frankfurt Plan – Near Term Requirements Are High Priority

Options Overview • Cloud Native K 8 S Ecosystem Only (OOM) - Link: https: //wiki. onap. org/download/attachments/28379482/ONAP%20 Orchestration. pptx? api=v 2 - Highlights: • • Based on extensive usage of Cloud Native Advancements Aligns with the current Cloud Native (K 8 s etc. ) Ecosystem based ONAP deployment Uses Helm, the industry standard Cloud-native Package Manager (CNCF) Leverages native Kubernetes orchestration resulting in highly scalable deployments with minimal footprint and avoiding unnecessary complexity and duplication of layers • Centralized View built on top of k 8 s API and Helm • Extending DCAE Orchestration (Tosca + OOM helm charts ) - Link: https: //wiki. onap. org/download/attachments/28379482/Management%20 Orchestration-DCAEPlatform%20 Extension. pptx? version=1&modification. Date=1561145148631&api=v 2 - Highlights: • • • Leverages Cloud Native Advancements Aligns with the current ONAP DCAE management architecture TOSCA Support (Mix of ETSI NFV TOSCA and Cloudify DSL) All near term and long-term requirements supported except 2 a (Policy/CL integration for Helm based Application) Minimal LOE for realization if consensus to use this solution as ONAP Orchestrator. 7

Scope for Frankfurt • Current orchestration mechanism of OOM and DCAE can co-exist to support Central and Edge use cases Deployment Location Non-DCAE Application Orchestration (A&AI, Policy etc. ) DCAE Application Orchestration (DCAE MS – Collectors/Analytics/Event proc) Central OOM DCAE Edge OOM DCAE • Focus on current gaps/new features from ONAP Edge standpoint and build them using consistent design across ONAP - Implementation may vary for OOM and DCAE deployed components • Defer Controller Alignment discussions beyond Frankfurt 8