Skip to end of metadata
Go to start of metadata

LFN Event Survey:

Day 1 - April 21, 2020

TrackKey PointsChallengesNext Steps / AIs

Guilin Planning - Requirements

Moderator: Alla Goldner

Reviewed the following requirements: 

1. NFV Testing Automatic Platform Requirements.pptx

2. E2E Network Slicing-Requirement SubC session V1.0.pptx

3. ONAP rel. G TIM requirements.pptx

4. Guilin ETSI-Alignmentv1.pdf

5. 5G Svc CPS POB CMPv2

6. Support xNF Software Upgrade in association to schema updates

7. Harmonization

Input from EUAG on Guilin priorities is needed

The presented requirements are already endorsed by the Requirements subcommittee

We will review the remaining endorsed ones on Thursday and review new ones during our next meeting on Monday, April 27th

Guilin Planning - Architecture

Moderator: Chaker Al-Hakim

Great collaboration between the Subcommittees !

OOM Daily gating:

Wiki link

  •  Wiki, RTD, ONAPDocs - a lot of information about ONAP from different sources

#1 Request to the ONAP Community to review the different templates:

#2 Define the scope/role of all the Documentation tools and potential synergy i.e. integrate this “ONAP directory” in readthedocs or, not as a separate landing site

ETSI/CNF - Container Modeling

Moderators: Andy MayerHui Deng

#1 ETSI NFV Container Architecture and ModelingUlrich Kleber

VNF can use VM-s or containers. 

CNF is a _Cloud Native_ NF what is a VNF built with the Cloud Native principles in mind

ETSI-based CNF support is compliant to IFA029&IFA040 (publication expected in May)

Additional information shared by Thinh NguyenphuONAP-ETSI Alignment Workshop (IFA040)

#2 CNTT RA2 Tom KivlinGergely Csatari

Possibility to run NF on top of what it is defined in RA2 / K8S 

No conflict/overlap between what ETSI CNF defined and CNTT RA2 (K8S)

CNTT Roadmap

#3 CNCF TUG (Lei Wang)

#1 ETSI approach seems to generalize the capabilities of the container infrastructure layer and may limit the use of the full capabilities of Kubernetes - no recommendation in IFA029.

#2 How to refer CNI in the descriptor?

Normally no need to have CNI reference in the pod manifest - K8S should evolve to support it but there is currently no solution.

#3 Different approaches for CNF Modeling - no conclusion yet from CNCF about the best approach 

#4 How can we stay align between ETSI, CNTT, ONAP, CNCF, OVP PH2, etc?

#1 Get Helm Chart sample from ETSI

#2 Upload Lei Wang's presentation (done)

Day 2 - April 22, 2020

TrackKey PointsChallengesNext Steps / AIs
Guilin Planning

Guilin Planning  - Control loop sub committee - Guilin requirements


Pamela Dragosh

 Reviewed and discussed requirements for Control loop in G release :

Control Loop Sub Committee Guilin Release Planning


ETSI/CNF - ETSI NFV modeling and API 

Moderator: Hui Deng

#1 Latest ETSI NFV modeling and API progress Thinh Nguyenphu

#2 ETSI NFV model impact on R7 Xu Yang

Speaker: Bin Yang

  •  cFW - POC in progress based on ONAP MultiCloud project - Source code available here
  • What API is used in VID? VNF API or GR API? Does it make any difference? What about that override.yaml - is there an example available? VNF/VF API to instantiate the deploymen
  • No development yet related to fault and performance monitoring of the CNFs. Targeted for Guilin.
  •  Dummy heat template is temporary for now as we did not want to make any major changes to SDC and SO.  In R7, we intend to make Helm as first class citizen.  Until R6, Helm charts are hidden as artifacts under Dummy HEAT template.

Speaker: Fernando OliveiraByung-Woo Jun

  •  Discussions have started with SDC for ETSI alignment for the onboarding
  •  SVNFM/NFVO are coming from 3rd party vendors

ETSI/CNF - CNF Task Force -Review Multi Site Orchestration with ONAP4K8s (ONAP for K8s)

Moderators: Catherine LefevreSeshu Kumar M

 Speaker: Srinivasa Addepalli

  • How to handle different VNF types i.e. Openstack based, Helm Chart based, Heat based etc? It should work based on the current ONAP4K8S
  •  How will the plugin with its own HPA placement logic interact with the rest of ONAP which also uses placement controller (OOF)?

#1 Upload Sandeep Sharma presentation

 Speaker: Rajendra Mishra

#1 Upload Sandeep Sharma presentation

E2E Network Slicing- Session 1


LIN MENG Swaminathan Seetharaman

  1. The overall requirements for E2E Network Slicing use case in Guilin release was presented. This covered:
  • New slice lifecycle operations to be supported. eg: slice modification, slice termination
  • Expansion in scope of E2E network slice to include RAN and Transport
  • Realization of NSSMF (Core/RAN/Transport) within ONAP, ONAP should also support NF set up and NF configurations under this condition
  • ONAP as NSMF connecting to external RAN NSSMF and Core NSSMF
  • KPI Monitoring, Closed Loop and Intelligent Slicing
  • Improvements to Frankfurt content

 2. User Operation Guidance for E2E Network Slicing Use case for Frankfurt release was presented. This covered:

(a)    ONAP components required for the use case, and the setup

(b)    How to create the associated design artifacts

(c)     UUI actions

 3. Questions asked:

  • How is Core NSSMF intended to be realized within ONAP?
  • How will a service be orchestrated by ONAP wherein part of the service only is within ONAP scope, whereas NSSMF within ONAP may be controlling the associated slice sub-net.
  • Details of modeling aspects and enhancements.
  • Are external domain controllers foreseen to be used for the domain-level actions?


Action Items

  1. Elaborate the modeling requirements and take it to the Modeling Sub-committee.
  2. Prepare further details, and illustrative flows showing interactions & APIs, including interaction with external domain controllers
 Joint Session


Day 3 - April 23, 2020

TrackKey PointsChallengesNext Steps / AIs
Policy Framework Frankfurt features and demos
Now that we have most of the framework components built and stable. We are going to schedule couple of demo sessions per area to deep dive, describe the features & how to use them . Probably an hour every Friday for couple of weeks. Will be sending the invite soon.
 Joint Session - Cloud Native OVP
 #1 Finalize OVP PH2 Roadmap by end of May 2020

Requirements subcommittee meeting continuation

Moderator: Alla Goldner

We reviewed the following remained submitted Guilin proposed requirements:

8. PM Control and A1 adapter extension

9. OOF SON requirements

10. ONAP - Multi-tenancy

 Input from EUAG on Guilin priorities is neededThe presented requirements are already endorsed by the Requirements subcommittee

We will review the remaining endorsed ones on Thursday and review new ones during our next meeting on Monday, April 27th

Security - Third party dependency upgrade strategy

Moderators: Krzysztof OpasiakPawel Pawlak

 Speaker:  Amy Zwarico

MTTU: Median Time to Upgrade

  • Project team resource constraints
Work with integration team to investigate the inclusion of container scan results such as database versions.

Guilin Planning - OOM Proposal

Moderator: Eric Debeau

Speaker: Sylvain Desbureaux

Review of OOM Guilin Release proposal 

Some proposals with help of projects:

  • All logs to STDOUT
  • Certificates
  • Crash well when Issue (and not "wait for I don't know" or exit with status 0)
  • AAF integration must be settable to off
  • MSB integration must be settable to off

Tentative / PoC

  • Make Ingress default deployment
  • Make Deployment with storage class default deployment
  • check storage asked for PVC is consistent with actual deployments
  • Service Mesh PoC continuation
  • All pods have requests/limits
  • request/limits bad values hunting: use only 10 vCPU while 92 vCPU are required, RAM may be divided by 3

#1 Assess the impact of upgrading to the version suggested by SECCOM? Does it require any architecture change or is it transparent for the component (only Helm Chart modifs)?

Guilin Planning - Integration priorities

Moderator: Eric Debeau

Speaker: Morgan Richomme

  • ONAP cross-project system integration
  • CI/CD

Morgan Richomme also requesting PTL to realease as soon as possible. Do not wait R4 to update OOM when new image is available


  • Maintain java11

  • create python3.8 baseline image


  • Adopt the approach to create a repo for new use cases / simulators

  • Add linters to all the new repositories

  • Add new linters (tobot, bashate, rst)

  • How to get a consistent view on all the repositories, shall we tag all the repositories,..

  • update xtesting repo and put in place the build chain in ONAP (move from to ONAP)

  • update jave/python3.8 in ONAP (move from to ONAP)

Robot pod

  • Adopt micro-service approach introduced by Daniel (propto in F)

  • move the helm chart back to OOM

Use case support

  • Write an documentation 'Use case guideline"

  • Test creation of an override.yaml per use case to be able to deploy adhoc environment in windriver


  • update the tests

  • harden the simulators/emulators (no more in xfail lists)

  • clean? are all the tests still maintained?

  • archive CIST? => projects can bring back their tests in their repository but jenkins CSIT not needed anymore

  • move some of the CIST tests in Daily CI

  • introduction of python_sdk for new tests (deprecate onap-tests)

  • improve security tests (Integration and Built Tests For Releases)

  • How to measure the test coverage?

  • How to get better healthcheck tests and "force" project to update them when they provide a new version of their code

  • Support OOM on a use case for Core on F→ G migration


  • include endpoint supervizion page? (cachet?)

  • Ops guideline (Zabbix/Prometheus/...) ?


  • improve CI chains and CI testing gate

  • new smoke use case

    • vFW CL

    • CDS

    • ...

  • integration of Portal GUI tests

  • finalize windriver/ pipelines

  • introduce a weekly CI chain including robustness tests

#1 Modify CSIT tests

#2 Provide use-case overrides

#3 Include new Gating for additional components: SO ? Requrse more resources

#1 What will be the oParent requirements for Guilin? Pawel PawlakAmy Zwarico

E2E Network Slicing- Session 2


Swaminathan SeetharamanLIN MENG

  1. "RAN and Transport Slicing" proposal and scope for Guilin release was presented. This covered:
  • Overview of RAN Slicing, scope and assumptions for Guilin release
  • RAN NSSMF within ONAP, as well ONAP acting as NSSMF interacting with an external RAN NSSMF
  • Overview of Transport Slicing, based on TSCi (IETF), scope for Guilin
  • TSCi information modelz
  • Interaction between RAN and Transport Slicing, different deployment scenarios

2. "KPI Monitoring, Intelligent Slicing and Closed loop" proposal and scope for Guilin release was presented. This covered:

  • KPI monitoring by slice tenant/operator (via portal)
  • Three SON scenarios for Closed Loop Automation and Intelligent Slicing namely:
  1. Slice resource optimization: Guilin: simple close loop for single NSI scenario; Beyond Guilin: Cross- Slice Scenario
  2. KPI adherence optimization (KPI Guarantee): (Guilin: simple close loop by introducing AI model. Beyond Guilin: cross-interaction with (1) also)
  3. Service experience optimization (SLA Guarantee, QoE based) (Beyond Guilin)

3. Questions asked:

  • Are the data models taken from IETF drafts? (Data model details are work-in-progress in IETF, we are closely tracking the developments)
  • Will a new SO adaptor be developed for connecting to external TN NSSMF in future, or can existing adaptor be extended? (Intention is to reuse existing one, however, it is under discussion)
  • Are we aligning to O-RAN? (Yes, we are having regular interactions with the O-RAN team, intention is to align with O-RAN as much as possible, starting with Guilin release itself).
  • Are we considering data from all network segments? (Under discussion)

  1. Elaborate the details of Guilin scope with respect to the modeling and interface aspects.
  2. Prepare flows for RAN <-> Transport interaction, and details of alignment with O-RAN.
  3. Elaborate details of data collection and analysis to be done.
  • No labels