Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Diagram from ad-hoc use case subcommittee meeting on March 28th 2018



Legend:

  • Modularity - ETSI NFV compliancy, External API (MEF/TMF alignment), OOM enhancements, ONAP and ETSI converged architecture
  • Technical Debt - S3P updated goals, External Controllers support, PNF full support, Cloud native VNFs, VNF Certification, Scaling/HPA/Change Management leftovers
  • 5G Fundamentals - Optimizations/Network slicing/Edge computing - define what is realistic for support in Casablanca time frame

    Note: There are P2 areas (e.g. some of Modularity described functionalities also fall under Technical debt etc.).



This is input provided by the Service Providers serving on the ONAP End User Advisory Group:

AT&T :

Balance is important.  We should not focus exclusively on either functional or non-functional requirements – or exclusively on near-term vs. long-term items.  I think the current mix of Use Cases shared does a good job of balancing the focus. 

Centralized Representation and Consistent Identification of Cloud Regions In ONAP addresses a near-term issue while the Change Management Enhancements and VNF Scaling use cases add valuable E2E capabilities for operators using ONAP to manage VNFs today.  On the other hand, the 5G and Edge Automation use cases lay the ground work for capabilities needed to support services of the future.  I believe this balance is good.

And, to the point that was made by a couple respondents, I also agree that we need to continue to work on platform maturity/hardening/non-functional requirements.  To highlight a couple of the suggestions below, I’d echo the value of supporting fine grained auth and consistent integration with AAF across components as well as multi-site/geo-redundant ONAP platform deployment support.


Verizon, in the order of priority: 


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


Bell: 

 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 Bell:

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.


Vodafone: 

We should continue working on platform quality (including declarative model, service layer abstraction, modularity, S3P etc), dedicating it 2/3 of the development time (comparing to platform's functional enrichment.


Orange:

We should continue working on platform quality (including declarative model, service layer abstraction, modularity, S3P etc), dedicating it 2/3 of the development time (comparing to platform's functional enrichment.

Other more detailed requirements will come shortly.


China Mobile:

it is really important to make ONAP as a generic platform to run all the use cases.

 For R3 use cases, the balance is important and I believe it was already take into consideration well, 5G and edge is also planing to deploy in the following 2-3 years. What I really worried is whether the new use cases can be supported by the generic platform capabilities, or I am afraid, the subsystem we made now cannot make an smooth evolution to support these new use cases.


Swisscom: 

- Regarding the platform, it is important to continue working on S3P requirements for Casablanca to increase platform quality.
- Documentation and information sharing is key for end user adoption. We see scattered documentation between readthedocs and the wiki. Meeting recordings and minutes, contributions and project description are not always up-to-date, making it difficult to keep track of discussions.
- On use cases for Casablanca, our initial priority would be OSAM, 5G and edge automation. Specifically, working towards supporting the deployment of fixed access services composed of both PNFs and VNFs, improving PNF onboarding and management capabilities, and defining a lightweight ONAP that can sit at the central office and how central ONAP interacts with it.


Turk Telecom:

  

  • Platform should be more generic and we should work on quality(documentation, modularity,stability, model driven, generic APIs etc.)  As an example, even in a very simple usecase trial, we can struggle with inputs of functions and needs detailed documentation of each spec
  • For the VNFs we should have standardizied processes for onboarding and service function chaining. We should wait a more standardized templating in VNF deploys, making VNF’s more similar to each other at deploy phase.  
  • We should aim for ease of use and the minimization of customization. When implementing our requested cases, we needed to make minor-average code changes at core code; if that should be done, we should do it on gerrit avoding to build different ONAP clones with minor changes. That our requested  minimization of customization can make our open source product dependent from vendor spec; but duty here goes on to VNF providers to be reliable to some predefined -stronger- standards, what we mentioned at previous subject


Issues from our developers,


  • Licensing: How to use the licensing models and its effects are not well documented. How do we check license violations and how to raise alarms?
  • Testing: Even testing the simplest use case requires lots of efforts. How do we check the integrity of ONAP deployment if all the pieces are working properly or not? Need automated integration testing after deployment. An initial set can be determined within any usecase or demo
  • Multiple VIM Support: We should be able to register at least two VIMs, one for the testing lab and another for deployment. We suppose it’s supported in Amsterdam but lack of documentation. May be some webinar; it is told that is talked before that some webinar will be done in future
  • Log management: Log management should be central. Infrastructure for central log management is ready in ONAP but not sure if all the projects in ONAP use the same logging mechanisms.
  • Health Check: OOM currently supports health checking of ONAP components. However, OOM deployment is not the only option. How can we health check in ONAP if heat deployment is used?
  • System Outages: When a system outage occurs, we experienced configuration loss and needed to re-configure some docker components and even needed to re-install VIM.


TELUS:

 

  • Geo-Redundant Highly available Network services/ONAP deployment 
  • Light weight/easy to install ONAP Platform
  • ONAP  Compliance with ETSI

-       SOL001 for Onboarding

-       SOL003 for Or-VNFM

  • Roles Based Access RBAC for deployment dashboard

-       Roles based access with fine grained attributes to support TELUS cross-function teams/security needs

  • Strong support for near-term VNF Onboarding use-cases

-       License key management, Template design + validation, VNF testing

  • VNF Day 2+ Configuration support (Modules architecture, Code Readiness)
  • Resource Orchestration visibility & control on cloud capacity

 

  • No labels