Re: [Onap-arc] Casablanca use cases: Feedback received from EUAG (Service Providers) so far
For the Verizon request “Fine grained RBAC for deployment dashboardz’. The Policy Framework project can support this request via the use of the XACML PDP engine. What I request is that Verizon provide resources to the project to help facilitate this work for Casablanca.
In response to the hard coding of control loops, all these gaps and hardcoding was pointed out in Paris last year and a call for help was given. No one responded. If folks could contribute resources to Control Loop Sub Committee to help define and scope how to fix the gaps in control loops, then the community can help work towards getting this resolved.
ONAP Policy PTL
Control Loop Sub Committee Chair
From: <onap-arc-bounces@...> on behalf of Alla Goldner <Alla.Goldner@...>
For your information, please see below feedback on priorities of use cases/requirements received from Service Providers so far.
We will discuss these and additional requirements from Service Providers, attending the call.
Requirements from Verizon, in the order of priority: (architecture/modelling subcommittees and affected projects – please pay attention to relevant requirements in the list)
And the corresponding questions:
Requirements and input on proposed use cases from Bell: (architecture/modelling subcommittees and affected projects – please pay attention to relevant requirements in the list)
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 us:
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.
Open Network Division
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer