Alla,

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.

Thanks,

Pam Dragosh

ONAP Policy PTL

Control Loop Sub Committee Chair

Hi all,

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)

• 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?

Requirements and input on proposed use cases from Bell: (architecture/modelling subcommittees and affected projects – please pay attention to relevant requirements in the list)

• 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 us:

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.

Best regards,

Alla Goldner

Open Network Division

Amdocs Technology