ONAP Edge Work – Suggested Next Steps

Suggested Next Steps “Edge Coordinator” right under TSC wiki Modus Operandi: Internal: Closely work with other sub-committees to develop a POV and then approach TSC External open source/standards: Direct Wiki Details: Option 1: “Edge Coordinator” TSC wiki has all activities (architecture, use case, external open source/standards coordination etc.) Option 2: “Edge Coordinator” TSC wiki has summary information on “Edge Coordinators” and points to various task force wikis Edge wiki under use case sub committee for functional requirements per release Edge wiki under arch. sub committee for arch. topics especially edge APIs Edge wiki under external open source/standards page co-ordination Need based Wikis under modelling, security or other sub committees

BACKUP

Genesis, Progress & Participation Started as a working group in May 2018 as part of the use case subcommittee 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

ONAP Edge Work role “ONAP Edge is not a single use case” It is a enabler across many use cases in ONAP Edge open source projects Edge Standards Edge Applications Functional Architecture Security Modelling .... Architecture subcommittee Use case Subcommittee Other Subcommittees ONAP Edge Work ONAP TSC Edge Cloud Domain -- e.g. Akraino, MobileEdgeX, StarlingX ONAP <-> Multiple Edge Cloud Domains 

Need for External/Internal Visibility & Recognition Making Edge a formal arm under TSC with targeted focus provides substantial visibility and can enable better ONAP internal and ONAP external participation Distributed Edge Cloud is a key area of focus for operators and vendors Collaboration with other key edge related open source/standards initiatives is key 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

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

BACKUP

Potential Deliverables across Upcoming Releases Contributions towards Architecture (closely interface with architecture subcommittee) Multi-tenant Edge Cloud Domain (e.g. Akraino, MobileEdgeX) ONAP <-> Multiple Edge Cloud Domains 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