Page History

...

• 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
  • Catherine Lefevre 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". Catherine Lefevre 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. 
    • Catherine Lefevre , 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 - 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  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