Versions Compared

Old Version 80

changes.mady.by.user Ranny Haiby

Saved on

compared with

New Version 81

changes.mady.by.user Lukasz Rajewski

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • ONAP/OVP - Inputs from/to ONAP/OVP Community in addition to what was discussed on 2/16. What are the other functionalities, test coverage are available with OVP today? What other communities (in addition to Anuket, CNCF, ONAP) collaborate with OVP?
    • Update from Olivier Smith - Change of chair in the OVP program. OVP 2.0 is being rebranded as "Anuket Assured". First badge will be released this summer, aligned with Anuket RA2. Working with the CNCF on cloud-native behavior for network functions. That will take some time to mature. OVP 2.0 is not writing  requirements. It is coordinating the tests and requirements between the various communities. Expectations from ONAP is to  have well-defined CNF modeling and a set of tests for verification. Validation tests in ONAP may exist in VVP or VNFSDK. No preference from the "Anuket Assured" side.
    • Update from user-67d6f - During Frankfurt, The "CNF Conformance" tool from the CNCF was integrated into VNFSDK. Based on the CNF modeling approach chosen by ONAP, VNFSDK may need to be updated. This was part of the CNTP effort. REQ335- REQ338 . https://wiki.onap.org/display/DW/Guilin+Release+Requirements
    • user-67d6f may continue serving as the main ONAP contact point, representing the VNFSDK.
    • VVP contact point -  steven stark
    • What kind of validation should ONAP require for CNFs? Packaging and on-boarding only?
      • On-boarding=SDC. SDC can now ingest and distribute Helm charts. In future releases it will also be validated. In Honolulu there is work to support ETSI packaging (SOL004).
    • Do we want to cover more (E.g. the application layer functionality of the CNF)?
      • We should probably not go into the application layer. This means we will follow the same approach we used for VNFs.
    • There will probably be different badges for different levels of conformance.
  • ETSI Event - April 21st - https://www.etsi.org/events/upcoming-events/1892-nfvevolution

March 18th, 2021 at

...

1pm UTC

  • Satoshi Fujii - proposal update from Fujitsu: k8s network design and config draft rev2.pptx
    • Proposal deals with the challenge of migrating workloads between K8S clusters
    • The approach is separating network design and CNI configuration
    • According to the proposal the user will create virtual networks and ONAP will generate the CNI configuration and inject it into the Helm charts at deployment time.
    • The proposal leverages EMCO (from OpenNESS). There were questions of the exact functionality provided by ONAP.
    • AI for Satoshi Fujii - prepare a follow-up presentation about the use of EMCO and the value it brings.
  • Update from Thinh Nguyenphuon ETSI event
    • There are only 15 minutes for the entire presentation
    • There is a need to submit an abstract by 3/22
  • user-67d6f - ONAP CNF compliance badging
    • VTP enhancements to support CNFs
    • VTP needs to get the requirements for CNF packaging from ONAP
    • user-67d6f - Are there ETSI SOL004 specifications? Fernando Oliveira - This is work in progress in Honolulu
    • VTP test development is planned for the Istanbul release. Need to have the requirements table ready by the start of the release. Fernando Oliveira volunteered to work on that.
    • Catherine Lefevre - Some of the VNF requirements might be applicable for CNFs
    • The VNF requirements are at VNF TOSCA Requirements . Catherine Lefevre suggested Taskforce members take a look and provide feedback.

March 25th, 2021 at

...

1pm UTC

  • Thinh Nguyenphu  - Share an alternative Common CNF Packaging - We will wait for Thinh Nguyenphu to indicate his readiness to present
  • Quick review of VNF TOSCA Requirements and VNF HEAT Requirements  indicate that they are very VNF and OpenStack specific
    • We need to look at the ONAP CNF artifact specifications (Helm charts, etc.), and try to derive the requirements. 
    • Marian Darula - AFAIK the draft for CNF artifacts has been presented by Fernando Oliveira , but not approved and accepted.
    • Olivier Smith - There is no intention to rush the ONAP project to provide requirements if they are not ready yet.

April 1st, 2021 at

...

1pm UTC

April 8th, 2021 at

...

1pm UTC

  • Lukasz Rajewski and Seshu Kumar Mudiganti will share the plans for Istanbul. May be in WIP state. 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyREQ-627
     - no updates yet.
    • No architectural changes expected. 
    • Marian Darula - Are Helm charts alone sufficient for modeling CNFs, or is there a need for external modeling. Lukasz Rajewski - Multi cluster is still a challenge.
    • Byung-Woo Jun & Marian Darula  - There is a need for an additional descriptor. The ETSI approach of a TOSCA descriptor on top of Helm could be a good approach. Lukasz Rajewski  - The multi-cluster network connectivity is an example of a modeling aspect that needs to be handled outside the Helm charts. The Nokia proposal may hold the solution for this issue.

  • From user-67d6f : I have created the place holder for supporting the CNF badging from ONAP perspective here https://wiki.onap.org/display/DW/Anuket+Assured+-+ONAP+CNF+Compliance+Badge 
    In order to plan the same for next release, would like to get filled following items asap from CNF Task Force and Modelling team. Could you please help to identify the owners for the below items. Thank you

...

Only existing CNF is the vFW, but it is not optimal as a "CNF reference". Other "Reference CNF" proposed by Samsung is not yet on-boarded to ONAP. Catherine Lefevre - the 5G-Super-Blueprint is working on on-boarding Magma (https://wiki.lfnetworking.org/display/LN/LFN+Demo%3A+5G+Super+Blueprint)

April 15th, 2021 at

...

1pm UTC

  • All: 5G-Super-Blueprint - which CNF features we should utilize in this use case - impact on future requirements
    • How to integrate with the Magma Orchestrator/controller
    • Can ONAP treat the Magma Orchestrator as a CNF? We are assuming it is.
    • The LTE version of Magma uses VNFs. The newly released 5G-SA version may be more CNF oriented.
    • We need more information from the Magma side. Next ONAP-Enterprise call is planned for April 28th.
  • Lukasz Rajewski presented the Honolulu CNF capabilities (
    Jira
    serverONAP JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyREQ-458
    ) - PLACEHOLDER - Lukasz Rajewski will upload the slides.
    • CDS Day 1/2 operations
    • K8S Plugin Day2
    • Zu Qiang (Ericsson) - Q: How is CNF package distributed? A: Same as VNF. Q: How is configuration done - how is CDS triggered? Is it through SDNC? A:No. SO triggers the CDS directly. CDS and SDNC are both part of CCSDK.
  • Lukasz Rajewski and Seshu Kumar Mudiganti will share the plans for Istanbul. May be in WIP state. 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyREQ-627
    • SDC Changes - Helm validation. Alignment with ETSI CNF Package (when ready)
    • A&AI - Bring information about the deployed resources from K8S and make them appear in A&AI. Requires discussion with the modeling subcommittee. Lukasz Rajewski will work with Andy Mayer on modeling changes for Istanbul.
    • SO - Distribute Helm package using CNFs-adapter. CNF-adapter health check.
    • K8S plugin - Switch to Helm 3.5
    • New Use case - Possibly Free5GC, based on some work done by Orange.
    • General comment - Plan is not finalized because there are still no confirmed resources for some of the planned functionality.
    • Catherine Lefevre  - recommends review of the Istanbul plan by the A&AI and SDC PTLs.

April 22nd, 2021 at

...

1pm UTC

  • Invite CNF vendors to provide feedback on the CNF onboarding based on their experience with their CNFs.

...