Team:

Lead: 

ramki krishnan

Team:

ramki krishnan , Srinivasa Addepalli, Vimal Begwani, Mike Elliott, Vijay Venkatesh Kumar , Avi Chapnick , Borislav Glozman , Fernando Oliveira , Tal Liron , Margaret Chiosi , ravi rao , Raghu Ranganathan

Others – please add yourself if you are interested

Meetings:

Every week as part of Edge Automation WG – Edge Automation through ONAP

Status: 

Draft.

Plan to be finalized in Arch. sub committee meeting on 01/15/2018.

References:

1. ONAP Dublin Architecture Requirements: https://wiki.lfnetworking.org/display/LN/OPNFV-ONAP+January+2019+Session+Proposals?preview=/8257582/10551784/2019-01%20Dublin%20Architecture%20Requirements-pa1.pptx
2. DCAE Platform Requirements: https://wiki.onap.org/download/attachments/28379482/DCAE%20Platform%20Requirements.pptx?api=v2

Activity Description:

Starting with Analytics, describe the options and recommendations for distributing management (ONAP etc.) functions.

Problem Statement:

• Management Workloads
  • Currently, Multiple Orchestrators for Management Workloads (SDC, SO, OOF etc.)
    • ONAP Central Management   – OOM
    • Analytics Central/Distributed Management   – DCAE (ONAP, SP internal, Third Party)
  • There is an opportunity to get some alignment across multiple orchestrators which will be greatly beneficial especially in Distributed Edge environment
• Managed Workloads
  • Fully Support for containerized network functions (work in progress)
  • Support for non-network functions (VM and Container based), e.g. vProbe, Automation Apps

Solution Direction:

• Leverage existing capabilities, and select what; or motivate new approaches
• Management Workload:
  • Align on a single orchestrator solution for all management workloads
• Managed Workload:
  • Enhance SDC, SO, A&AI, MC etc. to support containerized functions
  • Leverage ONAP for deploying and managing non-network functions
• Longer-term: 
  • Explore feasibility for orchestration alignment between managed workload and management workload
• Cloud-Native-foundation: 
  • Leverage K8S (Operators, Custom Resource Definitions etc.) for Distributed Systems Management
    • Image management – at scale rolling upgrade

    • Policy/Configuration change – notify only deltas

  • Leverage Istio Service Mesh (Distributed Tracing etc.) for Component Performance Management

Distributed Management application Requirements / Considerations 

Architectural Scenarios to consider:

ONAP components can run in Central and/or Edge Clouds

Scenario 1: Different services providers for Central & Edge Clouds

Scenario 2: Single service provider for Central & Edge Clouds 

Bring up for VIM each Edge Cloud - Out of scope for ONAPPreparatory Steps – Edge Cloud Bring up & Connectivity 

• Communication between Central Cloud, where ONAP Central runs on K8S, and Edge Cloud
• 1) Different services providers for Central Cloud & Edge
• Setup a private VPN - In scope for ONAP
  
  • for management network connectivity, any networking
• 2) Single service provider for Central Cloud & Edge
• Private connectivity to Edge Cloud may already be available; If not, setup a private VPN

Definition of done:

• This activity is closed when there is a:
  • Description of alternative concepts for distributing the ONAP functionality.
  • A recommendation for which alternatives to pursue (and when). 

Expected Timeframe:

 This activity is expected to conclude at/before the start of April, 2019 by the ONAP Architecture meeting at ONS.

Input Requirements: 

• DCAE Platform Requirements: https://wiki.onap.org/download/attachments/28379482/DCAE%20Platform%20Requirements.pptx?api=v2

Definitions:

Architectural Options:

Conclusion: 

Other Deliverables:

LF blog and Architecture white paper during ONS time frame.