Have 3 participants providing VNFs for testing

• ULAK
• Aarna Networks
• STC

Working on two infrastructures, with 3rd being setup

• 2 OpenStack / ONAP ElAlto
• 1 OpenStack / ONAP Dublin (virtual, being setup)

VNF Images have uploaded to infrastructure

• Getting infrastructure up and ready for testing
• Some issues with ONAP reaching Open Stack API (should be solved by end of today)

• Running conformance test cases 
• Run validation test cases

• Need to align release with main open source communities.
• OPFN, ONAP, OVP.

• cross-community sessions to go through the details.

• Containers technology is evolving technology, how CNTT will adopt such a dynamic environment. 

• Launching/supporting OVP Phase 2.0 taking MVP approach.

CIRV is approved project in OPNFV - this is the delivery of RI and RC for CNTT.

• This is THE project for creating the RI

CI/CD Evolution to solve today's problems

• Writing/fixing Jenkins is hard, need more modern solutions,...
• but which one(s)?
• Projects will have greater responsibilities/More on their own

• propose a transition plan, once we agree / accept the migration pain and real $$ costs

• ← They aren't the same (but certainly possible to evolve to new/better description).

• Hacking! Coordinate time(s) on OPNFV Tech Discuss list

• See Slides and Attendance list (please add your name) at

  Challenge: OPNFV PDF to Airship Manifest Transformation

ONAP Usability

• Unawareness of key documentation
• Unawareness of what has been done i.e. Modularity

• Promote what we have done- bi-weekly news
• Provide guidelines to PTL
• Focus on Core Use Cases/Core components to reduce the complexity - including prioritization 

Are we making progress on platform maturity?

• Performance, Stability - only Integration checks
•  Resiliency, Scalability = OOM?
•  Operability - upgrade build

• During the project lifecycle & Reviews, let's review these potential assumptions with the PTL
•  Platform enrichments vs full E2E use cases
•  CI/CD investments
•  Introduce S3P reqs through the new Requirements subcommittee (formerly Use Case reqs)

Next steps support:

• CNF support
• TOSCA 

• SO proposed architecture key additions:
  • Puccini
  • Artifacts
  • k8s APIs
  • Custom resources
  • Custom controllers

Main requirements for Frankfurt

• Python migration to version3
• Java migration to version 11
• CII badging with better code coverage
• OSJI backlogs
• Remove hardocded passwords
• Get HTTPS for all external ports

How to get all OSJI solved by PTL ? => Need help from TSC to progress

Proposals to remove all Root privileges to containers and to  automatically check in Gating

User management is also a key topic to be addressed. Some experience from ODL could be used.

Main objectives for Frankfurt

• Migrate to Kubernetes 1.16
• Migrate to Helm3
• Ingress controller introduction
• Database consolidation ongoing
• Storage class
• Password management

Creation of template for Helm charts

Discussions on database: do we still need so many DB types ? Impacts on operations (backup/restore)

Discussions on password managementto contuniue with dedicated sessions tomorrow

TOSCA based closed Loop

Extend closed loop from DACE/Policy to other appalications

CLAMP extension

• pre-deployment verification
• app deployment
• CL monitoring
• CL update/delete

• Presenters not on the bridge
• Extended debates 
• Presenters not concluding on time

• Please be connected to the bridge 10 mins before schedule
• Please request follow-up discussions
• Please stick to your scheduled timeslot 

Change Management support

Presented what is done in Frankfurt and what is planned in Guilin

Build and Replace worklfow schould allow to modufy existing instances of the VNFs on the fly.

Lack of VNFC level reconfiguration is one if the missing features on SO/Controller side which is not suppoirted today. We want to solve this issue in the Guilin release

PNF support by ONAP Change Management is the key challenge, planned to extend in Guilin

Schema/VSP Update is a chalange in the Upgrade process in ONAP. We want to addres this issue and to enable update of the schema with adequate modification of the existing instnces of services - for PNFs, VNFs and CNFs

Integration with CDS and K8s workloads as one of the key drivers for improvements of change management porocess in ONAP as K8s provides scaling, upgrades and traffic distribution capabilities by itself. For Frankfurt integration with CDS for CNFs creation is introduces. IN further releases K8s scaling and upgrade capabilities should be introduced.

This presentation focused on:

• Introduction to Transport Slicing in 5G context
• Design of Transport Slicing
• How to extend CCVPN to enable Transport Slicing
• How Transport Slicing fit into E2E Network Slicing
• How to work with SDOs on coordinating aspects of standards

CSMF and NSMF part of ONAP. External NSSMF to be used.

Demo for Frankfurt:

• Transport subnet not in scope
• Simulator RAN and core NSSMF simulator

Challenges on whether this is the only possible implementation or there may be more

Alignment on API  with 3GPP and  ORAN A1

Discussion on communication-service-profile introduced in ONAP

Warning on  templates that are deprecated within 3GPP

Impacts

• No evolution in SDC
• New WF for SO and NSSMFAdaptor
• OOF used for NSI selection
• &AI impact to include new 3GPP concepts (service profile, slice profile...)
• 2 new portals: CSMF and NSMF (under UUI project)

Ingress Controller introduced for Frankfurt as an option deployment

Effort on passing knowledge to ONAP teams on ingress controller and service mesh

 Get the Community Aligned on Network Slicing - AP for Architecture/Requirements subcommittee + Magnus (ONAP TCC)

What are the "baby steps" to build a "Slicing" roadmap

Promote ONAP through #1 use cases that does not require changes in ONAP; #2 POC so Innovation can continue while focus on ONAP Core.