2022 LFN Workshop - EMCO and ONAP On-boarding and use case alignment

Owned by Casey Cain
Last updated: May 17, 2022 by LJ Illuzzi
4 min read

Topic Leader(s)

  • @Ranny Haiby

Topic Description

75m, @Ranny Haiby

  • EMCO/ONAP Architecture alignment Deep Dive

Topic Overview

Slides & Recording



Agenda



  • EMCO/ONAP Architecture alignment Deep Dive

    • Part 1: On-boarding: Alignment across ONAP and EMCO, taking into account the role played by k8s.

      • Infrastructure → Applications>Onboarding>MANO>Infrastructure (end-to-end)

    • Appropriate use cases for EMCO and ONAP, when to use them separately and or together

    • The teams have identified two fundamental configurations, each ideally suited for different high level use cases

    •  

      • ONAP is the centralized Service Orchestrator, Service Assurance and Automation Framework, with EMCO fulfilling specific roles as a component (multi cluster support, etc)

      • EMCO is the distributed edge focused Service Orchestrator, with select ONAP Service Assurance components configured as needed.

    • We can draw from the following examples and other supporting material during this session to describe the rationale

    • Review of the EMCO_ONAP Alignment Proposal PPT.

    • Lessons learned from:

    • EMCO team overviews the rationale for, deploying an app/service such as Magma as the primary SO

    • Given the different configurations , how can the 5G SBP program demonstrate and delineate the rationale for the two configurations?

Minutes

Presentation: LFN DTF_EMCO_ONAP Alignment Proposal_V3b.pdf

  • Presentation walk-thru

    • Two "variations" for the integration

      • Variation/profile 1 - "SDO inspired" - leveraging ONAP's SO, DCAE based close loop automation, centralized inventory for PNF/VNF/CNF. EMCO as CNFM. Future enhancements (later phase): ONAP CDS for runtime configuration, OOF for optimization - supporting Intent Based Networking (IBN). 

      • Variation/profile 2- "Model free" - EMCO for orchestration and service configuration. ONAP DCAE for closed loop automation. Using Temporal, not Camunda for workflow. Focus is cloud-native, using Helm charts

    • @cl664y@att.com presenting variation 1

      • Next level of details would be breaking down each interface shown in the diagrams and specifying the API used, parameters, model.

      • ONAP SO is adding Intent Based Orchestration in addition to the Model DrivenOrchestration.

      • EMCO has also been working on intent based orchestration and so this is a key area for coordination. @Seshu Kumar Mudiganti  works within ONAP and EMCO and raised this point. matchmaking opportunity

      • expose intent-based capabilities to NB interface is a goal

      • Catherine proposes that @Srinivasa Addepalli, @Seshu Kumar Mudiganti Seshu, others interested in this subject can drive a discussion on this in the communities

    • @Srinivasa Addepalligives an overview of 2nd profile

      • Primarily a cloud native design from the ground up. Not model driven- using helm charts exclusively

      • Pluggable workflow engines, adding Temporal currently

      • Intended for use case where lightweight orchestration is a key driver

      • Intent based orchestration here includes intent -based placement of workloads

      • also placement constraints, which edge location is chosen for example, capability awareness or latency awareness for example 

      • Service Mesh connectivity can be across k8s clusters and EMCO can automate this configuration

      • Can customize the resource constraints for the same app/service depending on the edge location

      • The GitOps approach for syncing resources was added to support compatibility with MS Azure and Google Anthos

      • @Lukasz Rajewskinotes that this Configuration #2 is indeed very lightweight and it is important to consider the Service Assurance capabilities of ONAP

      • @Lukasz Rajewski - In order to use DCAE closed loop automation, A&AI needs to be integrated as well.

      • @Seshu Kumar Mudiganti - Is Temporal the only supported workflow engine? @Srinivasa Addepalli - There are other workflow engines supported. Temporal is not mandatory. The workflow is considered part of the "EMCO Ecosystem", not "EMCO Base". @cl664y@att.com Concerned about confusing the end users by the use of two different workflow engine.

      • Temporal was added due to its fundamental cloud native architecture, becoming very popular in the enterprise world. 

      • @cl664y@att.com , @Beth Cohen - Operations teams need simple tools. They are not software developers. New workflow engines should be easy to use by this type of users. During deployment time ("day 1") information has to be pulled from an external source (customer orders) automatically. @Srinivasa Addepalli - This is exactly what the EMCO ecosystem is there for, to support these external integrations.

      • @Bob Monkman (Deactivated) - There should be a default workflow option, as well as a pluggable option.

      • @Chaker Al-Hakim - There are functional differences between Camunda and Temporal, where the latter includes a state machine.

      • Pankaj Goyal (Microsoft) to Everyone (5:55 AM)
        is it really true that central inventory is not required?
        Srini Addepalli (Intel) to Everyone (6:17 AM)
        @Pankaj, inventory is required and maintained by EMCO. It is distributed, but common API is provided to get hold of inventory (both static and dynamic).

    • Role Alignment

      • @Chaker Al-Hakim - Proposes to analyze the 5G Super blueprint as a use case.

      • The "role alignment" slide in the slide deck is aspirational, showing longer term converged solution.

      • @Ranny Haiby We should avoid two discrete architectures that are mutually exclusive.

      • @Chaker Al-Hakim - The implementation details should not be visible to the end user.

    • Use cases

      • Use cases to analyze:

        • 5G Super blueprint - two flavors

        • Equinix use case - Enterprise Edge use case

      • @Louis - Documenting 5G super blueprint could be a starting point

      • @Heather Kirksey - Can we focus on one use case under the 5G super blueprint? 

      • @Beth Cohen - Proposed looking at a FWA (Fixed Wireless Access) as a simple use-case that may be popular with CSPs.

      • @Seshu Kumar Mudiganti - Moving forward on a use case, any use case, requires resource investment. Where will this resources come from?

      • @Neil Hoff - FWA is the first use case of Magma. Other use cases in the slide deck may use features that do not yet exist in Magma

      • @Louis, @Heather Kirksey - In order to document requirements there is a need for end-user input.

Action Items

@LJ Illuzzi  - Invite this group to the newly formed 5G Super blueprint requirements workgroup. @Ranny Haiby volunteers to join the workgroup
@Bob Monkman (Deactivated)  @Ranny Haiby  - Work with the EMCO TSC on better communication with the EMCO community. How to avoid re-creating and do more leveraging for DCAE Closed-loop automation