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
[cid:[email protected]]
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
<https://www.amdocs.com/about/email-disclaimer>
_______________________________________________
ONAP-TSC mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-tsc
