ONAP Use Case Fragmentation resolution Alla Goldner Andrei

ONAP Use Case Fragmentation resolution Alla Goldner, Andrei Kojukhov, Avi Chapnick, Borislav Glozman

Problem statement • ONAP is not mature as a platform • Service Providers would like to promote platform maturity (S 3 P, Security) related features • Service Providers would like to promote generic features that would enable multiple use cases • Some vendors promote integration with their PNF/VNF/Controllers within a specific use case implementation - Vendors that assign people to projects expect their implementation to get in • Specific ONAP projects develop features not necessarily relevant to previous two categories (replace components, configuration etc. ) • Some use cases propose a new architecture while some introduce shortcuts that overlap and sometime contradict existing architecture

Some Examples • DCAE change to PNDA (Integrating PNDA) • SO refactoring near the end of Beijing (documentation? ) • Scaling use case that has some shortcuts, specially where related to OOF (Scaling Use Case Extension)

Proposed solution • Any use case/functional requirement should have two parts, one defines what is required in terms of functionality, the other one proposes implementation - The proposed implementation should strive using existing ONAP architecture/mechanisms as much as possible. If new mechanism/architecture is required, it should allow other ONAP use cases/functional requirements and should be approved by the architecture committee

Proposed solution • Implement features in projects with platform view in mind - Each use case/functional requirement needs to pass Use-Case committee • Preference should be given to functional requirements automatically • Only in case of certain threshold cross SP demand-wise (3 -4? ), new use case should be considered - Then it needs to pass Architecture committee, which needs to evaluate whether the use-case features are relevant to more than one possible use case, or propose how it can be generalized to be used by additional use cases • The implementation part may be modified through this process - Teams (PTLs) need to enforce feature development to be as use-case neutral as possible so that it could be reused in other use-cases - Any shortcuts need to be documented and removed in consecutive release

Solution enforcement • Each Use-Case/functional requirement needs to get endorsement from Use-Case committee • Each technical requirement/development pattern which is suggested as part of a use case/functional requirement development needs to get endorsement from the Architecture committee

Solution enforcement • For each project part of M 0 - M 2 reviews need to make sure that planned features fit more than one use-case/functional requirement and that the development is generic enough to fit other future use-case/functional requirement - Use case/functional requirement owner(s) must participate in these reviews • For each project, before testing, review the developed feature in light of previous point • Upon code review make sure no use-case hard-coded features are merged

Thank You 9