Casablanca goals

Owned by Ranny Haiby
Last updated: Jul 05, 2018
8 min read

Diagram from ad-hoc use case subcommittee meeting on March 28th 2018





Legend:

  • Modularity - ETSI NFV compliancy, External API (MEF/TMF alignment), OOM enhancements, ONAP and ETSI converged architecture

  • Technical Debt - S3P updated goals, External Controllers support, PNF full support, Cloud native VNFs, VNF Certification, Scaling/HPA/Change Management leftovers

  • 5G Fundamentals - Optimizations/Network slicing/Edge computing - define what is realistic for support in Casablanca time frame

    Note: There are P2 areas (e.g. some of Modularity described functionalities also fall under Technical debt etc.).





EUAG input

This is input provided by the Service Providers serving on the ONAP End User Advisory Group:

AT&T :

Balance is important.  We should not focus exclusively on either functional or non-functional requirements – or exclusively on near-term vs. long-term items.  I think the current mix of Use Cases shared does a good job of balancing the focus. 

Centralized Representation and Consistent Identification of Cloud Regions In ONAP addresses a near-term issue while the Change Management Enhancements and VNF Scaling use cases add valuable E2E capabilities for operators using ONAP to manage VNFs today.  On the other hand, the 5G and Edge Automation use cases lay the ground work for capabilities needed to support services of the future.  I believe this balance is good.

And, to the point that was made by a couple respondents, I also agree that we need to continue to work on platform maturity/hardening/non-functional requirements.  To highlight a couple of the suggestions below, I’d echo the value of supporting fine grained auth and consistent integration with AAF across components as well as multi-site/geo-redundant ONAP platform deployment support.



Verizon, in the order of priority: 



  • Standards compliant on-boarding / orchestration interfaces

  •  

    • SOL001 for Onboarding ( preferred )

    • SOL003 for Or-Vnfm ( preferred )

    • VNF Package certification & labelling

  • Declarative model based orchestration

  •  

    • TOSCA based orchestration of network services, along with Yang/Netconf/VES for automated configuration ( preferred )

    • Model driven workflow orchestration for LCM

    • Custom workflows via Apache Aria plugins ( preferred ) for Closed Loop & SA.

  • Fine grained RBAC for deployment dashboard

  •  

    • Ability to derive custom SDC & VID roles with fine grained attributes

  •  

    •  

      • Eg : Designer A cannot design services tagged to Designer B etc.

  • Ability to deploy Geo-Redundant Highly available Network services

  •  

    • GR part of network design requirement in SDC.

    • Ability to orchestrate network services between multi-site / multi-region VIMs

  • Geo-Redundant Highly available ONAP deployment

  •  

    • Shared runtime catalogues across multi ONAP instances

    •  

      • Eg : ONAP B should be able to deploy NS designed by ONAP A etc.

 

And the corresponding questions:

  • How many of the above requirements can be made available by readily tweaking existing code, with minimum efforts?

  • How many would / can be scoped for future releases? if so, tentative timeline if any?

  • Where & how can we help contributing to ONAP w.r.t above requirements?



Bell: 

 ONAP needs a more robust/generic implementation of functionality leveraged by existing use cases:

For example, there is still hard-coded logic just to make simple use cases work (such as Firewall closed loop)

-          A provider-specific closed-loop implementation is not possible at this time, as the hard-coded use case logic should be implemented generically.

-          We are going through that with a real use case - it can't be leveraged right now without significant code changes to APPC, SDNC, Policy and DCAE.

  • Basic ONAP features which should be working reliably can be either incomplete, have been hardcoded or are still broken

Examples of such features:

-          SDC support for distribution of models/artifacts to multiple ONAP environments (development, testing, QA, production, etc.)

-          MultiVIM/Cloud's role is to abstract the VIM, currently SO does not leverage it, and no abstraction is built into it (it exposes directly the OpenStack model).

-          APPC's handling of events / actions from Policy is pretty much hardcoded for the use cases.

-          AAF is not or very lightly leveraged within the platform

There are much more – but in overall ONAP would benefit from improving existing features before building new, but partially working features.

  • VNF Configuration support is quite important for pretty much every use cases – and isn’t well supported right now (aside initial/boot up configuration).

-          It is often the next operational need, right after any lifecycle management implementation

-          A model-driven approach to this leveraging standards-based / abstract configuration models, and the framework to derive device-specific configuration, as well as interpret (read) them is required.

-          With configuration comes the need for supporting resource assignment, resource availability, etc.



With regards to the specific use-cases for Casablanca, in order of interest for Bell:

1. Centralized Representation and Consistent Identification of Cloud Regions In ONAP

  • This could quickly become a potential issue with ONAP, as providers start to use it or scale beyond a single cloud region implementation.

   

2. Change Management Extensions

  • An important feature as soon as VNFs gets deployed in a production environment.

  • Not natively supported in ONAP - any upgrade of VNF software is 100% a custom implementation.

  • It is related to general VNF Configuration management - which is an overall ONAP need.



3. Edge Automation through ONAP

  • Slightly related to item 1 - required when scaling / distributing ONAP components.

  • Potential heavy involvement of OOM in this one in order to deploy distributed ONAP components at the Edge.



4. OpenSource Access Manager

  • Interesting use case, but also a very large / ambitious initiative.

  • In order to be implemented, it depends on several ONAP components and their features to work reliably.

  • For service providers, this is a major undertaking - so slightly less of a short-term, immediate need.



5. 5G Use case Items

  • PNF support primarily from our point of view, although ONAP partially supports this - it should definitely be improved.

  • 5G is less of an immediate need than the other use cases, given ONAP could benefit from several improvements to existing functionality.



Additional input from Bell:



We should focus on completing the existing feature set rather than starting something new like 5g - making the features work for real so that more operators can actually start using the platform. Then 5g or other are just use cases.



We should put a very little percentage in adding use cases, especially if we are hard coding policies and other parameters just so that he use case is working at the end of a release. Fix vFW, fix vCPE, fix VoLTE, do not add. The ultimate goal is to have a platform on which any use case can be deployed.



Vodafone: 

We should continue working on platform quality (including declarative model, service layer abstraction, modularity, S3P etc), dedicating it 2/3 of the development time (comparing to platform's functional enrichment.



Orange:

Improve deployability first

  • Get a stable version and improve the integration process for the change code.

  • Provide additional tooling to operate the platform:  backup&restore, ONAP software upgrade, log vizualisation, tools to manage credentials, RBAC.

  • Get UI tools to help writing the VNF package.

  • Get more tools to validate the workflow, directed graphs, micro-services, policy rules. Capability to manage versions and how to minimize impact with VNF new configuration models

  • Provide more guidelines how to use the components, how to start with ONAP, to learn ONAP.

  • Avoid every hardcoded code to run the use-cases

Improve functional level

  • Keep the best modularity level

  • Manage mass VNF configuration: eg upgrade of a large number of same VNF type (eg entreprise FW in various OpenStack) and provide audit tools to check the VNF configuration.

  • While most services will require PNF integration, include PNF management.

  • Improve consistency between underlying infrastructure and AAI typically in configuration with multiple VIM

  • Include license management (SDC includes some modeling, but there is no code associated with it)

  • Cloud-native VNF to be deployed on Kubernetes.

Improve sharing

Better share all the PoC/deployments realized with ONAP

Other

Clarify the global VNF certification to be integrated with ONAP.

China Mobile:

it is really important to make ONAP as a generic platform to run all the use cases.

 For R3 use cases, the balance is important and I believe it was already take into consideration well, 5G and edge is also planing to deploy in the following 2-3 years. What I really worried is whether the new use cases can be supported by the generic platform capabilities, or I am afraid, the subsystem we made now cannot make an smooth evolution to support these new use cases.



Swisscom: 

- Regarding the platform, it is important to continue working on S3P requirements for Casablanca to increase platform quality.
- Documentation and information sharing is key for end user adoption. We see scattered documentation between readthedocs and the wiki. Meeting recordings and minutes, contributions and project description are not always up-to-date, making it difficult to keep track of discussions.
- On use cases for Casablanca, our initial priority would be OSAM, 5G and edge automation. Specifically, working towards supporting the deployment of fixed access services composed of both PNFs and VNFs, improving PNF onboarding and management capabilities, and defining a lightweight ONAP that can sit at the central office and how central ONAP interacts with it.



Turk Telecom:

  •  Platform should be more generic and we should work on quality(documentation, modularity,stability, model driven, generic APIs etc.)  As an example, even in a very simple usecase trial, we can struggle with inputs of functions and needs detailed documentation of each spec

  • For the VNFs we should have standardizied processes for onboarding and service function chaining. We should wait a more standardized templating in VNF deploys, making VNF’s more similar to each other at deploy phase.  

  • We should aim for ease of use and the minimization of customization. When implementing our requested cases, we needed to make minor-average code changes at core code; if that should be done, we should do it on gerrit avoding to build different ONAP clones with minor changes. That our requested  minimization of customization can make our open source product dependent from vendor spec; but duty here goes on to VNF providers to be reliable to some predefined -stronger- standards, what we mentioned at previous subject



Our main usecase and requirement orientation will be towards (from highest to lower):



  • Compliance with ETSI

  • OSAM

  • 5G



Issues from our developers,



  • Licensing: How to use the licensing models and its effects are not well documented. How do we check license violations and how to raise alarms?

  • Testing: Even testing the simplest use case requires lots of efforts. How do we check the integrity of ONAP deployment if all the pieces are working properly or not? Need automated integration testing after deployment. An initial set can be determined within any usecase or demo

  • Multiple VIM Support: We should be able to register at least two VIMs, one for the testing lab and another for deployment. We suppose it’s supported in Amsterdam but lack of documentation. May be some webinar; it is told that is talked before that some webinar will be done in future

  • Log management: Log management should be central. Infrastructure for central log management is ready in ONAP but not sure if all the projects in ONAP use the same logging mechanisms.

  • Health Check: OOM currently supports health checking of ONAP components. However, OOM deployment is not the only option. How can we health check in ONAP if heat deployment is used?

  • System Outages: When a system outage occurs, we experienced configuration loss and needed to re-configure some docker components and even needed to re-install VIM.”



TELUS:



  • Geo-Redundant Highly available Network services/ONAP deployment 

  • Light weight/easy to install ONAP Platform

  • ONAP  Compliance with ETSI

-       SOL001 for Onboarding

-       SOL003 for Or-VNFM

  • Roles Based Access RBAC for deployment dashboard

-       Roles based access with fine grained attributes to support TELUS cross-function teams/security needs

  • Strong support for near-term VNF Onboarding use-cases

-       License key management, Template design + validation, VNF testing

  • VNF Day 2+ Configuration support (Modules architecture, Code Readiness)

  • Resource Orchestration visibility & control on cloud capacity



China Telecom:

Cloud connectivity is important (connection between the customer and the cloud service using VPN service. vCPE use case need to be extended and Enterprise vCPE use case need to be supported.