Agenda

• Key ONAP challenges and critical gaps

-Issues identified by the broader ONAP user community

• Definitions of key terms
• Architecture principles and approaches as a guide to address challenges
• Refactor ONAP by leveraging common services to the fullest extent possible
• Approach: Focus on one major ONAP component at a time
• Examples: Service Orchestrator and Controller
• Problem Statement
• • ONAP is too complex, too big and hard to make changes.
  • Modules are monolithic (SDN-C, SO) and large, not sharing common utilities
  • Service providers might have a specific module already implemented and would like to integrate that module into ONAP
    -External controllers (e.g. VNFM, SDN Controller), external orchestrators, collectors, analytic microservices

• • Service providers would like to deploy ONAP incrementally, whereas today ONAP supports all-or-nothing approach
    -Core components of ONAP such as SO, SDnC Controllers and A&AI must be deployed

• • Should ONAP modules migrate to cloud-native microservices?

  • Can incorporate additional issues and/or more details if available