Track | Key Points | Challenges | Next Steps / AIs |
---|
LF Staff | Be respectful of everyone's time | - 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
|
Testing | Have starting running static testing | - ONAP Robot is not able to configure the demo instances in the ONAP El Alto instances.
- Some documentation for running VNF test cases Dovetail is missing online (in the VNF specific guide).
| - Doing testing by hand (i.e. using ONAP portal).
- Working to solve the issues with Robot, so automated tests can be run.
|
CNTT | Targeted 2020 Release Discussions: (Alpha, Beta, General Availability Launch) | - Have 2 organizations who have volunteered to be part of the Friendly (Alpha) release testing. (One with the initials "Red" and "Hat")
| - Start getting feedback from them ASAP on RI/RC and test results to date.
- Get them participating in WS release and RI/RC planning to help shape the onboarding process
|
| OVP 2.0 Launched RI & RC | - More resources needed, more alignment needed
|
|
OPNFV | - Several sessions on progress that was made in CNTT RI and RC, which leverages OPNFV LaaS, Intel pods 10 and 15, and Functest.
- Validation of hardware to support the software testing; Pharos 2.0 discussion; Manifest validation.
- Defining the next release of OPNFV Verified Program.
|
| Marching towards reference! |
RI + RC WS Update: - This is the ONLY RI. All VNF vendors must certify against this deployment (in their own lab or via LFN) in order to get their CNTT badge for VNFs.
- Cookbook intended to be complete instruction set for VNF suppliers to set up environment and run test suites.
- Working on framework and community ratification
- VNF certification is to be run against the RI, but then also against the a NFVI vendor's RC compliant stack.
| - Need to determine test scope - VNF is part of the scope
- Issue that NFVI vendors must be able to Certify their products separately, with reference VNFs
| - Continue iterating on the documentation and cookbook.
- Cookbook Validation and "Golden" VNF Creation. Friendly Trial: Looking for volunteer VNF Vendors to work through the process.
|
Hardware Delivery Validation - Part of CNTT certification is checking the hardware
- This can be considered step 0 of an RC suite: does the hardware meet a bare minimum specification in order to be RC compliant.
| - How to get all this information? (tooling)
- What information do carriers consider to be relevant?
| - Session continued tomorrow at 9:00 in Rm 220
|
OPNFV Release Process Evolution - a series of observations of where we are and what challenges we have
- Operating at installer/feature (scenario) as the release artifact for past 4 years
| - Installer base has dwindled
- Tools (test suites) have become more important
- CNTT is temporary entity to stand up new process/model and hand off to OPNFV
- Moved to part time release management support
| - How does the Heritage of successful and still-active projects continue? Do these projects use independent Release? (TSC questions)
- Independent release will still benefit from Release Marketing by using the project delta(s) from previous OPNFV Release.
- Check ODL precedent for "academic" vs "core" released projects
- This needs to be taken to TSC for a decision (with prior review & demo at weekly Tech Discuss? these two things are usually paired-up).
- Two personalities: 1) the stable RC and 2) the original concept of closing gaps by working upstream and verifying the tip of master
|
OVP 2.0 - Working session to help define mission and scope.
| - What is the scope of OVP Ph2.0?
- Do we need to define "Cloud Native" or just what is being verified? It is for compliance with the documentation from RA - these are the behavioral aspects, and so the question becomes does the implementation match?
| - Define scope of C/VNF testing
- Rabi / Lincoln will issue a call for participants to get the 2.0 work stream kicked off.
|
ETSI NFV Mano and VNF Testing - TST010 MANO api tests - conformance with SOL002, 003, 005
- Specialist task force assigned, funded by ETSI
- Result - document and automated test cases
- First time the test cases were written first and then the document (Test Driven Documentation!)
| - Challenge - doc becomes too big to edit - looking at splitting under ETSI guidelines
- How to automate fault management?
- Subscribe to alarm
- Simulate fault - this is currently a manual step
- Verify notification
| - Moving to gitlab and reduce editing churn
- Looking for ways to get alarms or metrics injected into SUT
- Collaborate with Barometer to see how to inject test metrics
|
Manifest Validation - Setup documents to describe the infrastructure
- Seeks to answer: Can manifest be verified pre-deployment?
- Manifest consumed by installers
- Such manifest is installer specific format
| - Such manifest is installer specific format
- Challenges
- Manual
- Many different formats
| - Need volunteers to work on this
|
ONAP | Change Management support
| Presented what is done in Frankfurt and what is planned in Guilin
| Build and Replace worklfow schould should allow to modufy modify 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.
|
Transport slicing support by ONAP | 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
| - Continue to work with the SDO's to improve and finalize the IETF TEAS working group draft on Transport Slicing
- Finalize the architecture of Networking Slicing on how NFVO should be used
- Should the Transport Slicing solution support CNF Connectivity?
- Should Transport Slicing be considered as a Generic Network Building block?
|
Network slicing (core network) ongoing support by ONAP 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
ONAP components 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)
| Challenges on whether this is the only possible implementation or there may be more Alignment on models and API with 3GPP and ORAN A1 | Next step for G Release: include transport and mronitoring Discussion on communication-service-profile introduced in ONAP Warning on templates that are deprecated within 3GPP |
SECCOM: Password removal | All passwords should be stored only in Kubernetes secrets, users should be allowed to provide their own secrets for the deployment and allow to generate passwords at the deployment time. | Further exchanges with ONAP community on best practice approval and implementation - sessions at the PTLs and TSCs calls. |
SECCOM: Ingress controller Ingress Controller introduced for Frankfurt as an option deployment | Effort on passing knowledge to ONAP teams on ingress controller and service mesh | Sessions at the PTLs calls. |
ONAP SECCOM ISTIO opportunity for common continuation discussion | Coexistance of AAF and Service Mesh in a long term security solution | AAF and ISTIO to be treated as two separate tracks |
Use Case Cross-Carrier 5G |
| 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. |
Use Case Subcommittee - Review of Frankfurt/Guilin Use cases
|
| - Prepare comms about 'use cases' renamed as 'Requirements'
- => Goals & Scope as per TSC vote last year
- Need to review TSC Chart
- Process to review to identify resources prior the M1 release to prepare the work upfront related to new reqs - to identify companies who will provide dev/test to implement them
|
Modeling Subcommittee - Review of the ongoing activities
- Latest feedback from ONAP/TM Forum from Magnus, our TCC representative
- Information Model Documentation
- API Swagger Documentation
|
Align Information Model with external SDO | Alignment with Documentation to include glossary from Modeling team and to improve API Documentation. Communication to PTL to explain the API Swagger reco
|