Track: E2E Network Slicing Session 1
Presenters/Moderators: LIN MENG
Content: Slides are available here and here.
- E2E Network Slicing overview
- Work done in Frankfurt, ONAP component impacts
- Demo of Frankfurt scenarios
- Overview of Guilin content
Presentation Slides are available here and here.
Recording is available here.
- Transport NSSMF interface on Southbound to be shown to avoid confusion. Currently the slides only shows RAN and Core NF Simulators. Transport NSSMF will interact with a Optical Domain Controller (or simulator) on SB.
- Stretch goals to be indicated - for e.g., Control Loop using CLAMP, etc.
- For Core, Closed Loop part to be discussed offline due to introduction of CNFs.
- Session covering Core, RAN and Transport Slicing functionality to be realized in Guilin (due to time constraint, Transport Slicing part moved to Session 3 - see below)
Presentation Slides are available here (Core), here (RAN) and here (Transport).
Recording is available here.
Track: E2E Network Slicing Session 3
Presenters/Moderators: LIN MENG Swaminathan Seetharaman
- Session covering KPI Monitoring, Closed Loop and Intelligent Slicing. The session started with Transport Slicing which was carried over from Session 2.
Presentation Slides are available here (KPI Monitoring), here (Closed Loop) and here (Intelligent Slicing).
Recording is available here.
Track: 5G OOF SON use case: Overview & Demo
@N. K. Shankaranarayanan
- Session providing a brief overview of 5G OOF SON use case followed by a demo which provided the highlights of the use case, and the work done in Frankfurt release.
Presentation Slides are available here.
Recording is available here.
Presenters/Moderators: Sofia Wallin, Jessica Wagantall
- Discussions about deprecating the submodules in the docs repo
Track: Documentation guide
Preseenters/Moderators: Sofia Wallin/Eric Debeau
Track: Documentation improvement plan for the Guilin release
Presenters/Moderators: Amar Kapadia
Track: Architecture Component Views in Readthedocs
Presenters/Moderators: Ciaran Johnston, Tony Finnerty, Jeff Van Dam, Sofia Wallin
Great improvements from moving content from Confluence (onap wiki) to ReadTheDoc
Track: Release Note Content
Presenters/Moderators: Sofia Wallin
- Agreement that the content of the release note will be limited to the scope of what we are delivering. Content of the previous release note will remain available.
|Track: Reference CNF development journey and outcomes|
Presenters/Moderators: Victor Morales
- A journey of building an LTE core (GW tester) Network function as a CNF. It serves as a good reference because it uses several, segregated networks.
- Required steps include preparing the Docker image, Using K8S to orchestrate, creating overlay networks using Flannel(many challenges related to multiple interfaces) and packaging using Helm
- Two solutions for CNI plugins - DANM and Multus
- Helm charts are available in the CNCF TUG Testbed
- Follow-up with the ONAP CNF Modeling/Inventory task force
|OPNFV Track|| Key Points||Challenges||Next Steps/Action Items|
Cloud Software Validation - Part of OPNFV CIRV project Sridhar Rao
- Work moving fast since June -2 Interns Joined! Ashwin and Parth.
- Demo shows how validation works, run on Intel Pod 10.
Form of UI and exposure of results: many possibilities (REST, cache in X-testing, others)
PDF is a "big" PDF, includes many aspects beyond OPNFV PDF.
Today, checking Airship deployment and debug with logs (find root cause). Other deployments ??
Security Checks: Some tools in Functest, Ansible Security Hardening has possibilities, Cedric will have a look in Openstack.
By early August, should have Airship Manifest complete.
Results API will expand storage beyond current local storage, to X-testing, Test-API, etc.
|K8s: Multi-Interface Container Network Benchmarking in VSPERF Sridhar Rao|
Background information in Slides from April Event (links in the slides), Thanks to K8s Networking Experts! This is Mostly a Hands-on DEMO!
- Automated Cluster Setup complete, Using Intel Pod 12, Multus, Centos (dpdk-app-centos), T-rex Traffic Generator. Autoamtion handles the deployment of the cluser and CNI, AND the tooling can be used on existing clusters.
- VSPERF tool provides the basic configuration capability, starting with OVS-DPDK, on Worker Node (DUT).
- A second instance of VSPERF runs the Traffic Generator-Only, for Benchmarking search control and Results collection.
- Results for OVS-DPDK show very low Throughput, we can see the bottleneck is a virtual port.
- Next, test with SR-IOV: one virtual function (VF) per vNIC
- Finally, test with VPP: Issue with support of vhost-user, had to use memif (interface or bridge modes are OK). Problem with xconnect mode, l2fwd works ok.
Pod must be running DPDK, or other performance enhancing technology.
Still exploring CPU configurations (optimization).
Currently need to add flows in vSwitch manually.
Need Expert Help! Queue configuration on Virtual Ports! Also Hugepage configuration.
Using Ixia HW Traffic generator in very near future.
Will be running more comparison tests when satisfied with configurations.
Jeff Hartley offered to help!
OVP 2.0 Cloud Native Operator Panel
Moderator: Marc Price
- Very Interactive panel Q&A: The Recording is the Canonical Source of Information!
- Need CNTT specifications for infrastructure to line-up with CN workload needs: Integration tools to manage operate and maintain are needed
- Opinion: CNF deployment is highly dependent on success in 2 areas: performance and operations.
- CNF Testbed is a showcase for how different CN elements can work together and offer services.
- Different levels of Services: Examples include Self-Healing, OAM: CNF Conformance requires construction according to Cloud-Native Principles. Quality of Service should be included.
- What value can OVP 2.0 provide to Operators? And what can we learn from previous OVP efforts?
- Need to certify that Operator's Infrastructure is good enough to run CN functions/workloads. Need to understand the demarcation between Infrastructure, Operations, and CNFs. Reduce Integration testing and the time involved.
- Need more than a "standard", only a piece of paper! Also, CN-principles emphasize automation of operations so that systems don't have to be watched 24x7 (babysitting).
- Can OVP reduce Integration and Conformance testing by 10%? - then that is sufficient value to use it. Operators have turned into integrators to use multiple vendor products.
- How does OVP 2.0 align with other projects?
- CNTT for requirements, Also ETSI NFV
- OPNFV for benchmarking/performance
- CNCF for workload cloud-native-ness
- ONAP for alignment on service creation with CNFs
- TIP using CNTT specifications for deployment
- It's more and more difficult to find the right forum - too many! Fragmentation will slow-us down.
- Value of OVP is the Meaning of the Badge! UL (Underwriter's Laboratories) is a an example - you won't get shocked when you plug an electrical appliance into the wall.
- Most CNCF projects are about Rigorous Testing, also Project Graduation provides assurance. Long legacy of best practices for application development. May use other Communites: FD.io does it all day, for VPP... Others have a wider view (See previous OPNFV K8s Benchmarking Session).
- Look into more for the badging program
- We get out of it what we put into it, and recognize that each operator will still need to do their own testing! Cover LCF and common functions and let operators do the rest.
- Are there usecases that badging is NOT covering? bring them in!
Joint Topic: OPNFV and CNTT: OPNFV Release Process 2.0 JOINT with CNTT David McBride
- Integration-Test is a community role, ask community projects to implement verification tests for CI, then it is done.
- Integration-Test is covered by the CI and Jenkins -
- Leverage current gating
- Integration Test is different from normal CI and Jenkins checks, This form of Gating is a dependent on CNTT requirements
- CNTT must put developers into the process now, to implement the requirements, there may be difficulties when dealing with a single requirement at a time.
- Some feel that the Requirements Sub-committee is too much overhead.
- Others feel the Requirements SC provides the necessary Triage to reduce overhead on the Project teams.
- Need more CNTT input, if possible.
Requirements Vetting Process
|Finding more time to close on this discussion: Proposal is to re-allocate time from Thursday's Agenda, Joint Topic Right after the 30 minute Break!|
What Artifacts are we Releasing?
- Tool Documentation (always)
- Integrated test automation for Conformance, Functional and other Requirements
| Next Steps/Action Items|
|ODL transportPCE Magnesium Retrospective|
This retrospective presented a quick overview of TransportPCE new functionalities introduced in Magnesium. It was followed by a status on the developments done and some feedbacks on the features introduced by OpenROADM and the community ( OpenROADM OTN support, SpotBugs / checkstyle enforcement and doppelgangers, netconf notifications )
|OTN support hardened for Aluminium|
|involve more reviewers and commiters|
rationalization of project features for OTN
|ODL BGPCEP Reliability & Scale|
- Tejas Nevrekar When working on the redesign to use a pipeline be mindful of ensuring pipeline stages are mutually exclusive
- Tejas Nevrekar Upload missing bugs and patches to upstream
- Robert Varga share details of how config only replication shards maybe configured
|ODL Usability Review|
A quick usability review of the OpenDaylight Usability was covered in this session including what works well, what does not (development & deployment challenges). This was followed up with suggestions for improvements - from a low hanging fruit to bigger architecture improvements like a more loosely coupled platform.
|ODL Project Status|
The discussion concentrated around how to get more developers on boarded. There were many suggestions including having a dedicated public face for helping new developers. A key point that was made was:
- Need more clear messaging to the users (companies) that if you are consuming ODL, to please contribute upstream X hours per day or week to help resolve the technical debt.
|CNTT Track||Key Points||Challenges||Next Steps/Action Items|
|Edge Deep Dive|
- we need to be careful not to assign a "location" aspect to CNTT profile. (the plan is not to)
|Clarify the term profile in relation to hardware profile or workload profile|
|Networking Focus Group|
- How to make sure we don't duplicate what ETSI is doing.
- Get full alignment with ETSI and make sure we laverage their work in CNTT.
|OVP Phase 2.0 Panel|
- Marc Price moderated OVP session and there has been many discussions around it's relation to CNTT.