Versions Compared

Old Version 24

changes.mady.by.user Ranny Haiby

Saved on

compared with

New Version Current

changes.mady.by.user Ranny Haiby

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.).



EUAG input

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. 

...

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

...

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

...

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:

Improve deployability first

...

Clarify the global VNF certification to be integrated with ONAP.

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

...

  • 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

...

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


China Telecom:

Cloud connectivity is important (connection between the customer and the cloud service using VPN service. vCPE use case need to be extended and Enterprise vCPE use case need to be supported.