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
From: <onap-arc-boun...@lists.onap.org> on behalf of Alla Goldner
<alla.gold...@amdocs.com>
Date: Monday, April 30, 2018 at 3:29 AM
To: "onap-usecase...@lists.onap.org" <onap-usecase...@lists.onap.org>
Cc: "onap-...@lists.onap.org" <onap-...@lists.onap.org>,
"onap-disc...@lists.onap.org" <onap-disc...@lists.onap.org>,
"onap-tsc@lists.onap.org" <onap-tsc@lists.onap.org>
Subject: [Onap-arc] Casablanca use cases: Feedback received from EUAG (Service
Providers) so far
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@01D3E06E.5FEBCE30]
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=jwTiArcEj6aUX0HjV0M3dT12gUtk7rC07xpgpVZkS_4&m=wVgZlZvN21ZgRnCFl1LhPwEsYlCZSUFPN7DsSHshJVQ&s=jNvbd7zDmyi8u1X24W46WkUo4_zo9gCvh3744388fPk&e=>
_______________________________________________
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc
