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



Legend:



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: 


 

And the corresponding questions:


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.

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.

-          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

   

2. Change Management Extensions


3. Edge Automation through ONAP


4. OpenSource Access Manager


5. 5G Use case Items


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

Improve functional level

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:


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



Issues from our developers,



TELUS:


-       SOL001 for Onboarding

-       SOL003 for Or-VNFM

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

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


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.