Versions Compared

Old Version 235

changes.mady.by.user cl664y@att.com

Saved on

compared with

New Version Current

changes.mady.by.user cl664y@att.com

Saved on

Key

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

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Meeting Minutes 

Table of Contents
maxLevel2

...

  • Review our Calendar - Decision to setup CNF Task Force call every Tuesday at 2pm UTC until Daylight saving time will end in March
  • Review (and refine if necessary) this taskforce goals. Other than the on-going work, what is the next big thing we want to tackle as a taskforce?

...

  • Continue discussion between Aarna and SO team to figure out if some of the Aarna work can be re-used by SO
  • Any topic we want to submit for the February DDF event?
    • What will be ONAP priorities to remain in alignment with Industry/Standards?
    • What would be our ONAP 2021 CNF Task Force priorities (after Honolulu) - brainstorming?
    • Video Guilin CNF?
    • CNF Task Force Office Hours

...

...

  • Review CNF Closed Loop proposal (Satoshi Fujii) with PTLs (SO, AAI, DCAE and Policy)
    View file
    nameDynamic CNF Migration Proposal.pptx
    height250
     
    • Consider EMCO as part of the CNF Closed loop
    • Great Feedback provided by AAI/DCAE/Policy/SO Project Team members (listen to the recording (smile))

...

  •  Thinh Nguyenphu (Unlicensed)  - Share an alternative Common CNF Packaging - postponed to March 9th - work on CNF packaging is running a bit behind schedule.
    • Nokia is exploring on "CNFD", similar to the existing "VNFD" and "PNFD". A CNFD may be treated similarly to a PNFD, which is sort of a black-box, and handed over to another entity like K8S to orchestrate. 
    • Marian Darula commented - introducing a CNFD in addition to a VNFD creates a challenge for xNF vendors. Why not re-use the VNFD? Thinh Nguyenphu (Unlicensed) - CNFD orchestration is based on Helm charts and not TOSCA, hence a VNFD is not very useful for CNF orchestration. 
    • Nokia aims to separate resource orchestration (in the Helm chart) from application orchestration (in the CNFD).
    • Marian Darula - There is urgency in finalizing the packaging - vendors need to deliver CNFs.
  • ESTI Workshop updates -  Thinh Nguyenphu (Unlicensed)  - New dates: April 21st and 22nd, 2021 - Registration link to be shared as soon as available
  • EMCO
  • Update from Victor Morales :  CNF Reference (Core Network) 

...

  • 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 Former user (Deleted) - 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://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Guilin+Release+Requirements
    • Former user (Deleted) 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

...

April 8th, 2021 at 1pm UTC

  • Lukasz Rajewski and Seshu Kumar Mudiganti will share the plans for Istanbul. May be in WIP state. 
    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    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 Former user (Deleted) : I have created the place holder for supporting the CNF badging from ONAP perspective here https://wikilf-onap.onapatlassian.orgnet/wiki/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

...

  • Invite CNF vendors to provide feedback on the CNF onboarding based on their experience with their CNFs.
    • Kamel Idir - volunteered to provide feedback based on his experience
      • Tried both types of packages - ETSI and ONAP
      • Experience is with the Frankfurt release (Heat template wrapper)
      • ONAP VNFD - Under TOSCA There is a namespace. If a vendor uses its own namespace it does not work out of the box. Expect to have a way to change the namespace supported by ONAP. There was a requirement for SDC to support changing the namespace. Workaround - Change the CNF package provided by the vendor to match the ONAP namespace.
      • While designing a service using SDC, ran into an issue with the interfaces as defined by the vendors - use different types than the ones supported by ONAP.
      • ChrisC - There were changes made in Honolulu - https://wikilf-onap.onapatlassian.orgnet/wiki/download/attachments/10089576216469107/SDCMultiModelSupport.pptx?version=1&modificationDate=1618834987000&api=v2&download=true
      • Kamel Idir -  Is there support for SOL007 design? ChrisC - It might be included in the recent changes (Honolulu). There is a way to indicate whether you are using ONAP or ETSI package.In the future it might be possible to translate between the two formats.
      • SDC has a limitation on size of images in the Helm charts. SDC has a 8MB limitation. Kamel Idir indicates it is not sufficient for the CNFs he on-boarded. Workaround - Onboard images to Docker image registry and reference them. Some vendors provide embedded images which will require modification. ChrisC - The solution might not be having SDC handle the images. It is not designed to serve as image storage. Kamel Idir- Manipulating the package provided by a vendor to extract the images might jeopardize package integrity. Zu Qiang - Extracting the images during on-boarding may not impact the integrity. Integrity validation happens before the extraction of the images. Flow is (1) Validate - signature validation (2) Extract (3) Distribute (no signature validation at this stage).

...

    • Additional information can be found on the "ONAP for Enterprise" Task Force Wiki (specially on 4/28)
    • Seshu Kumar Mudiganti - Magma may be treated as a 'resource orchestrator', and SO can have an adapter to control it like other resource controllers.Magma does not have LCM capabilities. Magma LCM requires some more research.
    • cl664y@att.com- SO should remain generic. We need to be consistent from an Architecture's perspective i.e. what's the scope of SO vs SDNC-C? When do we take the decision to create an adapter in SO and when SDNC is used?
    • Deploying the Access GW requires running shell commands as root. This may be improved and better automated with ONAP.
    • Opportunity for ONAP: Automate scaling of Magma GW; automate the "magma services" deploymentice

...

...

    • The Honolulu release has important updates to support cloud native network functions (CNF). The functionality includes configuration of Helm based CNFs and seamless day 1, 2 operations. The Configuration API allows a user to create, modify and delete Kubernetes (K8s) resource templates and their base parameters and the Profile API allows for sophisticated day 0 configuration. The Query API gathers filtered status of the CNF and the HealthCheck API executes dedicated health check jobs to verify the status of a CNF. This new functionality is implemented in the Controller Design Studio (CDS) component using dedicated templates called Controller Blueprint Archives (CBA). 

    • DCAE simplifies microservice deployment via Helm charts and includes a new KPI microservice. The VES-OpenAPI-Manager allows easier validation of new xNF types against supported VES StndDefined domain improving compliance with 3GPP and O-RAN

    • Application Programming Interface (APIs) 

    • Logs are redirected to SDTOUT
    • ONAP Components are containerized and are deployed on virtual, shared and elastic infrastructure.
    • Built based on DevOps Toolchain (CI/CD, Gating, etc.)

Additional separated key messaging: Support ORAN SC SMO + Support Enterprise business (E2E Network Slicing, etc.)

...

...

June 24th, 2021 at 1pm UTC

...

...

...

...

...

October 21st, 2021 at 1pm UTC

...

  • Proposed joint meeting with EMCO technical leaders (Sharad D Mishra (Deactivated) , Srinivasa Addepalli ) to discuss details of future integration - Roles and responsibilities, API calls, Integration points (Multicloud vs. directly from SO), any other open technical questions.
    • Follow-up on analysis done by Orange - EMCO & Ongoing Work in Orange , K8s plugin - Summary and use in ONAP for CNFO
    • Why was EMCO created in the first place? What were the motivations? What ONAP gaps does EMCO address? 
    • A few initial gaps for integration were identified by Lukasz Rajewski 
    • Srinivasa Addepalli - EMCOs goal is to deploy "complex" applications (or CNFs) across multiple K8S clusters. It continues monitoring the deployed applications and provides status. EMCO assumes K8S is the cloud infrastructure, but it supports VMs as well.  It can communicate with public cloud APIs (Azure, GCP). EMCO v1 was integrated with ONAP multicloud, which handles single CNFs. EMCO v2 can handle a network service (multiple CNFs). EMCO does not have a "standard compliant" northbound API (e.g. ETSI VNFM or NFVO)
    • Seshu Kumar Mudiganti - Proposes a Service-Orchestration/Resource-Orchestration approach. EMCO can handle Helm charts deployment (=resource). SO will  handle the service level.
    • Lukasz Rajewski - We should compare the terminology between ONAP/EMCO/ETSI.
    • Srinivasa Addepalli - EMCO handles "composite applications" described by a Helm chart. It provides value by interconnecting  the components of the composite service, e.g. using ISTIO.
    • What will be the demarcation between ONAP and EMCO? Will EMCO handle an entire CNF? Each Helm chart separately? In EMCO, One application may have multiple micro services. ONAP has "services" consisting of "VF"s, That may have "VF modules". Each "VF module" is a Helm chart. 
    • Lukasz Rajewski - The main difference between ONAP and EMCO is that ONAP deploys each "VF module" (=Helm chart) separately, using an API call to multicloud. We need to find a way to preserve this approach, making multiple API calls to EMCO.
    • First step for integration - ONAP will call EMCO for each "VF module".  This will not take full advantage of EMCO's capabilities, but will only serve as a first step toward deeper integration. CNF adapter in SO will be the integration point. Multicloud will not be used for this integration.
    • Future steps for integration - Have EMCO handle an entire VF as one composite application.

...

  • MEETING WAS CANCELED - low attendance
  • Finalize new landing pageDecember 14th, 2021 at 2pm UTC

Action

...

Items (Closed in 2021)

  •  (Thinh Nguyenphu (Unlicensed)) / Marian Darula / Byung-Woo Jun : Nokia and Ericsson share an alternative (Common CNF Packaging) to what was proposed by Fernando Oliveira , Byung-Woo Jun
  •  (All) Try to identify where we are on the CNCF Trail Journey - Needs clarification to comment, need to dig into the details of the actual ask.
  •  (All): Build an ONAP proposition value to collaborate with XGVela Community
  •  (Timo): Ask the Nokia team to present preview material on 1/26
  •  (Catherine): Contact Policy/DCAE/AAI/SO PTLs to attend January 26th CNF Task Force call to review Satoshi FujiiCNF Closed Loop proposal
  •  (Catherine): Send Calendar invite - every Tuesday @2pm UTC
  •  (Catherine): Reconnect with the CNF sub-Task force: Modeling/AAI (Andy Mayer) and ETSI (Byung-Woo Jun and Fernando Oliveira ) to understand their 2021 goals on January 19th 
  •  (Kenny): Follow up with EUAG in order to determine if any particular CNF reqs (or 2021 ONAP requirements including an update to the ONAP TSC)
  •  (Seshu/Lukasz): Invite EMCO representatives
  •  (Olivier): Organise a call with Trevor Lovettand any interested CNF team members to determine how ONAP could contribute to the OVP 2021 activities
  •  (Ranny): Post the topic for the event
  •  (Catherine) Check with Olivier Smithif we can postpone OVP/ONAP discussion to another week so CNF PDN Gateway discussions can be scheduled on  March 2nd, 2021
  •  (Victor Morales/ Ranny Haiby): Setup additional follow-ups about CNF PDN Gateway
  •  (Timo/Catherine): Promote 2021 goals from OVP program and collect any particular requirement through ONAP Requirement and TSC meetings
  •  (Kenny): Contact EUAG about any CNF badging requirement (OVP)
  •  (Seshu): Check if Former user (Deleted) , Lei Huang (Unlicensed) , Yan Yang can join March 9th, 2021 to discuss about OVP/ONAP & VNFSDK
  •  (Thinh): Share the ETSI event link when it will be available
  •  (Seshu): Questions for XGVela

...

  •  cl664y@att.comFollow-up with the Modeling Subcommittee about yan yanrequest
  •  @Thin to upload presentation from May 6th call
  •  Kenny Paul - Reach out to FB to meet us on May 12th, 2021 (ONAP For Enterprise Task Force) - request made to LF PM - just checked no name yet.
  •  cl664y@att.com: Introduce Amy Zwarico to Anuket, CNCF and OVP PH2 Communities and share SECCOM Container Logging specs 
  •  (ALL): Provide feedback regarding Thin's proposal presented on May 6th, 2021
  •  (Andy Mayer , Hui Deng ) Follow up regarding Modeling team about CVC request - Re: Request from CVC 
  •  Kamel Idir - Will repeat onboarding with Honolulu (once he has the lab resources) and will report back 
  •  (Byung-Woo Jun: Bring the discussions to the ONAP Architecture Subcommittee about SO/SDNC role etc (see notes from 4/29)
  •  Ranny Haiby - Create a first draft of the "ONAP cloud-native" messaging slide and share with the Taskforce.
  •  Ranny Haiby , Byung-Woo Jun , Timo Perala , Seshu Kumar Mudiganti  to discuss the enhancement of our ONAP Cloud Native Vision/Roadmap, this with Architecture, Requirement & MAC subcommittees
  •  Brandon Wick- will collect additional information about the ONES event (virtual, F2F present, etc.)
  •  cl664y@att.com: Plan CNF Task Force readout with the ONAP TSC
  •  Lukasz Rajewski - Ask Orange colleagues to present EMCO↔Multicloud comparison
  •  (All) Feel free to provide feedback about ASD packaging (Orchestration Scenarios)
  •  (Modeling/Requirements): Need to determine what ETSI CNF package solution we want to move forward (Fernando Oliveira, Byung-Woo Jun vs Thinh Nguyenphu (Unlicensed))
  •  (Olivier): Check with CNCF if any cross-meeting with ONAP could be scheduled 
  •  (All): Collect feedback about our current CNF onboarding capabilities from 3rd party vendors
  •  Try to locate missing meeting recordings (Sept 30th & Oct 14th, 2021) - cl664y@att.com 
  •  Lukasz Rajewski - Follow up with Seshu to plan EMCO  integration