Skip to end of metadata
Go to start of metadata

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

Casablanca Focus



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



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. 

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:

Improve deployability first

  • Get a stable version and improve the integration process for the change code.
  • Provide additional tooling to operate the platform:  backup&restore, ONAP software upgrade, log vizualisation, tools to manage credentials, RBAC.
  • Get UI tools to help writing the VNF package.
  • Get more tools to validate the workflow, directed graphs, micro-services, policy rules. Capability to manage versions and how to minimize impact with VNF new configuration models
  • Provide more guidelines how to use the components, how to start with ONAP, to learn ONAP.
  • Avoid every hardcoded code to run the use-cases

Improve functional level

  • Keep the best modularity level
  • Manage mass VNF configuration: eg upgrade of a large number of same VNF type (eg entreprise FW in various OpenStack) and provide audit tools to check the VNF configuration.
  • While most services will require PNF integration, include PNF management.
  • Improve consistency between underlying infrastructure and AAI typically in configuration with multiple VIM
  • Include license management (SDC includes some modeling, but there is no code associated with it)
  • Cloud-native VNF to be deployed on Kubernetes.

Improve sharing

Better share all the PoC/deployments realized with ONAP

Other

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


Our main usecase and requirement orientation will be towards (from highest to lower):


  • Compliance with ETSI
  • OSAM
  • 5G


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


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. 

19 Comments

  1. Alla GoldnerRanny Haiby, mazin gilbert, et al,

    The original Venn diagram had three collections - new features, continuous improvement, and ONAP fundamental/"must have" features... 

    New features were about 5G, continuous improvement was about S3P and modularity, and "must have" features were about things we have to have. While we had P1 and P2 features, we also had P3 features that were inside the non-intersecting parts of the collections... The diagram was meant to be a general tool we could use on on-going basis, not just for Casablanca...

    Best regards,


    Alex Vul

    Intel Corporation




    release-planning-venn-diagram

    1. Thanks for providing, Alex!

      If we try to generalize process for the next releases as well, we should also provide a Legend here e.g. clearly distinguish what is difference between "Fundamental Must-Have features" (and, in general I have difficulty with this definition, as, if it a must, while it was not implemented earlier?...or how was it defined as a "Must" etc.) and "New Features". 

      1. Sometimes it takes multiple releases to get a "Must-have" feature done. In one release it will be a new feature, but then my question is for the next release does it then move into the Technical Debt bucket? Or is it still a new feature that just isn't done yet.

        1. Pam, this is why I think it is very difficult to generalize in all these cases and distinguish, as a result. 

          We, probably, should move Release by Release with its goals, as we have started for Casablanca with the related diagram above.

        2. Pamela Dragosh That is a difficult question to answer and I think at the end it does not matter, the work has to be done.

          I am OK to call it "New features" until it is implemented (over multiple releases), but then later you may want to improve it (by let's say moving from mysql to a more friendly Db) and then you will call it "Technical Debt".

          Hope this helps.

  2. Based on Chris Donley's response to my question about architecture alignment in the TSC meeting on March 29th, I added the "ETSI and ONAP converged architecture" proposal to the legend, under "Modularity" .

    1. The API alignment was internal, how do we get the ONAP Components to align their API to meet ONAP standards. I didn't think that had to do with MEF/TMF, aren't those standards? Chris Donley - is that a correct? Maybe I misunderstood.

      1. Pamela Dragosh: Modularity is both about ONAP Components' API alignment with ONAP standards and supporting external standards, where applicable, e.g. ETSI NFV interfaces/MEF/TMF by the corresponding relevant modules.

    2. Ranny Haiby - I think link you've provided doesn't work.

      1. Fixed now. Thanks.

  3. We also should keep in mind to improve the previous release and to solve remaining Beijing issues.

    I am confused with Technical Debt topic. Technical debt here concerns new features while Technical debt is more about redesigning a feature using more efficient techniques https://en.wikipedia.org/wiki/Technical_debt

    1. Eric Debeau: If you look into the list of what I included under technical debt, it is mostly about improving the previous Release (Beijing) and solving its issues: 

      • S3P updated goals, PNF full support, Scaling/HPA/Change Management leftovers

      Some of it, however, is also about designing new or extended concepts e.g. External Controllers support, cloud native VNFs support, VNF certification.


      Any more successful definition is welcomed!

    2. Eric Debeau: To complement what Alla wrote. I don't think we checked wikipedia (or any other source) for definition of the terms used in the diagram. We just came up with terms that seemed to represent the focus areas for Casablanca.

      "Technical debt" was understood (or at least I understood it) to be those topics we had agreed for previous release(s) but for one reason or another were not able to complete fully yet. "Backlog" or "leftovers" as Alla lists. But since it was felt there likely are other topics too, e.g. individual projects developing their "endogenious" concepts , too, it was felt another term was felt to be appropriate.

      Improvement of the terms definitely welcome.

  4. When I first saw the "Technical Debt" term used in R3, I thought it was more related to the maturity metrics.

    There is actually an industry standards to measure the Technical Debt http://it-cisq.org/standards/technical-debt/  (CISQ under the OMG umbrella). A "debt" is usually accumulated due to short cuts or lack of resources/knowledge to implement something correctly/with optimum design that resulted in more efforts required to maintain them.

    Given we are doing model driven (the core software methodology from the OMG), with supporting software measurements.  I would encourage that we use this industry understood term but look into further in terms of how to apply the concept  in the context of ONAP and are there any CISQ measurements that we can use.

    my $0.02

  5. Agree with Jenny. Many of the items under technical debt (cloud native VNF support, external controllers etc.) are indeed "platform enablement".

    1. ramki krishnan: This is exactly what I said above (smile) "Some of it, however, is also about designing new or extended concepts e.g. External Controllers support, cloud native VNFs support, VNF certification."

      I don't think, though, that "Platform enablement" is a good terminology as well (sad) - the reason is that Modularity is also "Platform enablement".


  6. If the objective of this discussion thread is to develop a common process/methodology for all releases,  perhaps the terminologies of those 3 bubbles are:

    Capability, Modularity & Cohesion

    • Capability:  Described from business/CxO view points -  What does ONAP do for me?
      • Each capability can have many levels of details, but hopefully overtime this will become a communication and planning tool for the entire ONAP ecosystem (i.e. within and outside the ONAP development community)
      •  We can then use Capability Maps and Maturity Models to guide the development from A to B  (there are IT best practices/templates that we can leverage)
      • e.g. R3 Capability focuses are "5G Deployability"... 
      • Capability underpins the Modularity and Cohesion considerations
    • Modularity and Cohesion are ONAP architecture artifacts to realize the capability envisioned,  this may include new or refined/extended concepts 

    I think Technical Debt is another dimension to these 3 bubbles,  and essential to develop and manage ONAP maturity metrics and to inform the priorities of each release.

    For example, I will see VNF/PNF onboarding are sub-capabilities of 5G deployment,  and standards alignments are execution strategies for certain capabilities.  We seem to mixing things a little on the current bucket list.

    Is this topic being discussed in the UC subcommittee?  sorry I have not been able to join the calls in the past. Most of the calls are too early for west coast.


    1. Hi Jenny,

      The initial objective of this discussion was to build initial objectives for Casablanca, still subject to prioritization input. 

      This was firstly discussed in Los Angeles. However, now we also discuss terminology here, as we attempt to generalize the approach for future releases. I would say, 


      1.We need to proceed with objectives for Casablanca as a first priority now (and may, of course, fix groups' definitions, if we find a better definition)

      2. We may try to generalize the process of the groups definition, for the future releases - we haven't discussed it yet by any meeting, let's try to converge here and then we will be able to present it during TSC meeting


  7. Alla GoldnerTimo Perala I agree with Jenny Huang. I also think Technical Debt "is another dimension to these 3 bubbles,  and essential to develop and manage ONAP maturity metrics and to inform the priorities of each release."

    I agree we need to define the process to prioritize Casablanca and take the Beijng experience and identify the good and wrong.