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:image001.png@01D3E06B.3B567280] 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-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss