Edge Automation through ONAP WG Driving External/Internal Visibility & Recognition WG Co-chairs: Ramki Krishnan, Raghu Ranganathan TSC Sponsor: Srini Addepalli  

Genesis, Progress & Participation The Edge Automation through ONAP effort started as a working group in May 2018 as part of the use case subcommittee and is targeting concrete deliverables impacting multiple ONAP projects and driving the ONAP edge requirements & architecture for Casablanca and beyond. Link: Edge Automation through ONAP Progress & Observations The working group has been run with its own meetings and maintaining set of wiki pages. As part of Casablanca, multiple initiatives have been taken such as supporting Kubernetes based edges, Aggregation of metrics and Cloud-agnostics way of utilizing cloud/edge site features. Work has contributed to other sub-committees besides use case subcommittee Participation 25+ participants   Strong and consistent interest from the community in terms of attendance and contributions

Potential Deliverables across Upcoming Releases Contributions towards Architecture (closely interface with architecture subcommittee) Multi-tenant Edge Cloud Domain  ONAP <-> Multi-tenant Edge Cloud Domain  Contributions towards Security (closely interface with security subcommittee) Distributed Edge Clouds introduce unique security challenges as described in detail in the infrastructure profiles Contributions towards Modelling (closely interface with modelling subcommittee) Distributed Edge Clouds needs new cloud infrastructure modelling – there is substantial work that happened in this area in Beijing/Casablanca time frame Contributions towards Functional Requirements per Release (closely interface with use case subcommittee) ONAP <-> Multi-tenant Edge Cloud Domain IaaS/PaaS Intent-based APIs and Context (e.g. summarized telemetry information) APIs Contributions towards Functional Requirement realization (closely interface with all ONAP projects) Working closely with other key edge related open source/open standard initiatives Joint Architectural (APIs etc.) discussions Joint demo planning for conferences Edge work has direct impact on all ONAP sub committees and all Edge related Open source & Open standards initiatives

Need for External/Internal Visibility & Recognition Distributed Edge Cloud is a key area of focus for operators and vendors towards 5G transformation, local breakout, ultra-low-latency MEC applications and bandwidth-intensive IoT applications  Collaboration with other key edge related open source/standards initiatives O- RAN Alliance, Linux Foundation (Akraino, EdgeX Foundry, IoTvity etc.), Kubernetes (Edge Working Group, Network Service Mesh, Multus, OVN etc.), ETSI MEC etc. The work needs substantial discussions and engagement with external open source initiatives to make concrete ONAP architecture recommendations while avoiding overlap and reuse other work – this is very different from other functional & non-functional requirement group which are ONAP specific Making Edge a formal arm under TSC with targeted focus provides substantial visibility and can enable better ONAP internal and ONAP external participation

Next Steps – Option 1 “Edge” Sub Committee under TSC Pros: Cons: Wiki: In sync with ONAP sub-committee creation policies Commensurate internal/external recognition Cons: Sub-committee sprawl Wiki: Moves directly under TSC - currently under use case subcommittee External open source/standards page co-ordination is updated with link to “Edge” sub- committee wiki for edge related activities Modus Operandi (same in both options): Internal: Closely work with other sub-committees to develop a POV and then approach TSC External open source/standards: Direct

Next Steps – Option 2 “Edge” TBD (Coordinators?) under TSC Pros: Cons: Commensurate internal/external recognition Cons: New operational model Wiki: Current wiki stays under use case subcommittee “Edge” TSC wiki has summary information on “Edge” TBD (Coordinators?) and points to current wiki External open source/standards page co-ordination is updated with link to “Edge” TSC wiki for edge related activities Option 2 Variant Create task force and wiki under different subcommittees Modus Operandi (same in both options): Internal: Closely work with other sub-committees to develop a POV and then approach TSC External open source/standards: Direct

Our Analysis Creating a new Sub-committee is simpler Modus Operandi stays the same in Option 1) or 2) Need TSC Opinion on next steps