2020 October Virtual Technical Meetings Daily Summaries

Session on E2E Network Slicing - Honolulu release Scope and Future Roadmap (Presenters: LIN MENG, Swaminathan Seetharaman, Milind Jalwadi,Henry Yu)

This session covered what functionality has been realized in Guilin, and the proposal for Honolulu and beyond for each of the following tracks of the E2E Network Slicing use case:

• Enhancements in CSMF and NSMF for E2E Network Slice allocation, standards alignment, operator intervention, etc.
• RAN, Core and Transport Slicing related aspects, including alignment with O-RAN (RAN) and ETSI ZSM & IETF (Transport)
• KPI Monitoring, Closed Loop Control & Intelligent Slicing

Feedback from the ONAP community was sought on topics such as Network Slicing in roaming scenarios (i.e., true e2e slicing), interaction of slice management & orchestration functions (NxMF) with the Core NFs such as NSSF and NWDAF, collaboration with C&PS project, etc.

Presentation Slides are available here.

ONAP Multi Tenancy - Demo of Guilin work and Roadmap

 ONAP Demo of O-RAN-SC O1 interface simulator configuration via CDS

 ONAP Control Loop in TOSCA PoC and Rel H evolution

ONAP Orchestration of Free 5G Core CNFs using ONAP4K8s (EMCO)

• Jerma M2 scheduled for Oct 20
  •  Functional freeze - Readiness Review
    • Document significant accomplishments
    • Release Management Tasks sent to for M2
• Goal for Documentation outline in Jerma Release -Agreed
• Revisions to RELREQ-13 on Storage testing requirements and clarifications - Agreed
• OPNFV Input to LFN Governing Board meeting on Project's Priority Activities - Agreed

EUAG and Software Defined Networking by Ahmed El Sawaf

ONAP Requirements Subcommittee - new requirements for Honolulu

#1 ONAP ETSI-Alignment (SOL004, SOL005 v3.3.1)

#2 E2E Network Slicing use case

#3 Smart Operator Intent -based Network & 5G Slicing Support

#4 5G OOF SON use case

ONAP Impact of the current ONAP release- and branching strategy on documentation

Discussed the possible solutions for branching documentation and project / Cross release issues.

Several projects have deprecated repos

Documentation update tracking should be part of release process

should documentation be in a single repo ?

ONAP Security Subcommittee Kanban 

Review Helm, OS, Python/java updates

Update Vulnerable direct depencies (tracking through wiki)

   M1 (TBD) commit resources

   M4 (TBD) complete upgrades

Guilin seccom retrospective : lots of improvements in this release

ONAP Architecture Subcommittee update: Guilin Reviews perspectives and what's new for Honolulu

Technical Community Coordination – Generic Network Management

• ETSI
  • ETSI NFV update – Thinh Nguyenphu
  • ONAP Conformance to ETSI – Byung-Woo Jun
• 3GPP
  • RAN Slicing: 5G NR Resource Configuration Management – Kamel Idir
• TM Forum
  • Digital Transformation World – Magnus Buhrgard
  • Catalysts, rapid-fire proof-of-concept projects – Magnus Buhrgard

ONAP Honolulu - CNF Task Force Requirements

Presentation of REQ-334 (ETSI Alignment-CNF Support)  - SOL004, SOL005 v3.3.1

REQ-341 (CNF Orchestrator)

Call for Developers for the Honolulu Release

If any interest then please contact 

REQ-334: Fernando Oliveira , Byung-Woo Jun

REQ-341: Lukasz Rajewski , Seshu Kumar Mudiganti

ONAP: Hands-on session on ONAP Optimization Framework (OOF)

This session provided an overview of OOF, its modular architecture, capabilities and ease of reuse w.r.to onboarding a new use case or requirement that needs some sort of optimization functionality. It also described the typical realization steps to follow for any use case or requirement needing optimization (provided by OOF). It was followed by a guided walk-through with an example of how the E2E Network Slicing use case realized the optimization needs easily through a lot of reuse of existing functionality with some enhancements.

Comment: Policy team highly appreciated the work done by OOF team for effective usage of the new Policy framework.

Query: A query on how subnet instance's resource occupancy levels and capability of an existing instance to cater to a new request are considered by OOF.

Response: This isn't yet considered by OOF, however, it is proposed to be realized in Honolulu release, with OOF getting the required info on available resources and capacity through an "inventory provider" which for example could be AAI or DCAE, which leverages existing OOF capabilities to a large extent.

Presentation slides are available here.