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