...
ONAP high level design requirements
Key Contacts - Alessandro D'Alessandro, ceciliamaria.corbi@telecomitalia.it
Executive Summary – Today new emerging infrastructures based on kubernetes are becoming very popular. ONAP components shall support CNAs/CNFs artifacts, cloud native service models and relevant distribution/management. Given the fact that K8s has its own orchestration capabilities that partially overlap with ONAP capabilities, it is expected that ONAP development focuses first on aspects not covered by K8s. The envisioned scenario is based on both CNFs and PNFs. Moreover kubernetes provide a declarative approach to the orchestration of many aspects such as resource provisioning, resource scaling and resiliency and can be enhanced with many add-ons that seamlessly provide other features such as application control, communication robustness etc (e.g service mesh by Istio). ONAP provides a good level of flexibility in service orchestration (e.g. a la carte, Macro and E2E orchestration approaches) but the framework requires specialized skills to implement unforeseen orchestration patterns that may slow down new service design and deployment. It is therefore required that ONAP functional module adopts a declarative approach and native support for CNAs artifacts to avoid time to market bottlenecks. Link 20200512.ONAP.relG.TIM.functional.requirements.pptx
Business Impact – Today, many ONAP components (e.g. SDC, SO and AAI) are not able to manage CNA/CNF artifact/service models in a native way that bring to unnecessary complexity in service orchestration. It is expected that ONAP modeling and LCM support be future proof. ONAP developments shall focus first on LCM aspects not covered by K8s (e.g. on service orchestration rather than resource orchestration, on resource splitting among different k8s clusters rather than on single k8s cluster, on PNFs LCM aspects , etc.). Moreover it is required that ONAP be designed in a way that it can be easily be customized with general programming skill personel.
...