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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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