Versions Compared

Old Version 90

changes.mady.by.user Ranny Haiby

Saved on

compared with

New Version Current

changes.mady.by.user Yan Yang

Saved on

Key

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

Meeting Minutes 

Table of Contents
maxLevel2

Jan 4th, 2022 at 2pm UTC 

...

...

Meeting Minutes 

Table of Contents
maxLevel2

Jan 4th, 2022 at 2pm UTC 

...

...

...

  • Clarify the benefits of ASD  over the ETSI-NFV SOL001
    • There was a  meeting on feb-14th on the modeling subcommittee  - no consensus reached - Modeling Subcommittee 2022-02-14
    • Decision was to escalate the decision to the TSC. The request from the TSC is to enforce adherence to the modeling subcommittee procedure. Andy Mayer - CLEAN state is a result of a subcommittee decision, based on rough consensus. The poll is just an input to the rough consensus. Xu Yang - "rough consensus" means there are no un-addressed objections. Marian Darula - the objection cannot technically be resolved.
    • Xu Yang -  Based on input from ETSI experts, it may be possible to unify the models.
    • Zu Qiang - Why is there an attempt to create a single model/package?  Xu Yang - There is no such limitation to have one model. The ASD model is referencing ETSI models.  Therefore it seems that it should be possible to find a unified model. For example, the ASD may become part of the ETSI-NFV NSD. Thinh Nguyenphu (Unlicensed) -  ASD is not "built around" ETSI models. It may reference ETSI, just like it may reference any other SDO. It may be a good idea to aspire for more alignment, but it  is inappropriate to block progress on the ASD initiative. Requests to follow the letter of the governing document (Approved ONAP Model Governance), and decide based on the poll.
    • Byung-Woo Jun - The ASD PoC is NOT using elements from ETSI (e.g., SOL005, SOL003, NFVO, VNFM), so it cannot reconcile, as it will require major changes in the ETSI specifications. The "ONAP Native" orchestration approach is planning to adopt ASD,  and is also not using ETSI specs. Why not use the same approach for the ASD and allow it to exist as an alternative?  Xu Yang - The ONAP Native approach was approved because there was no reference to ETSI and it seemed like a stand alone approach.
    • Xu Yang - Expectation from the TSC - Decide whether the current ASD proposal is technically mature enough, or does it need more work for reconciliation with ETSI?
    • Timo Perala -  Is there an estimated expected time line for the potential ETSI NFV - ASD aligned solution? For all I know it may easily take until 2023 to get there.
    • cl664y@att.com - What if ETSI endorses the ASD? Byung-Woo Jun - It  will require major changes in the ETSI MANO  architecture, may take time as stated above.
    • Xu Yang The ASD IM does make references to ETSI.  There are references to Virtual Links for example.
    • Zu Qiang - ASD Information model does not make a reference to ETSI. It may use identical attribute  names, but that can be changed to avoid confusion.
    • Thinh Nguyenphu (Unlicensed) -  TF (Catherine), ONAP MODCOM (Xu), ONAP-NFV Contact (Thinh) Bridge info: TBD Document depository: TBD (my recommendation is CNF TF wiki page) Tentative Agenda (information sharing and no decision making):
  • Prepare for Joint workshop with ETSI-NFV regarding ASD

Feb 22nd, 2022 at 2pm UTC

Mar 1st, 2022 at 2pm UTC

  • Prepare for LFN CNF workshop on Mar 13/14 - https://wiki.lfnetworking.org/display/LN/2022+LFN+DTF+Workshop+Topics
    • cl664y@att.com will work with EMCO (Bob Monkman) to prepare an integration proposal. Lukasz RajewskiRanny Haiby  will take part in the discussion

    • The goal is to have a clear roles and responsibilities definition for cases like the 5G super blueprint

  • ASD Model approval - Can we come up with a compromise proposal that will put everyone's mind at ease?
    • Focus on the technical aspects, not the procedural and vision aspects .
    • Keep the momentum going and avoid future re-work.
    • Path to move forward:
      • Work on 'definition" problem raised by Fernando Oliveira , Zu Qiang , Marian Darula  + Thinh Nguyenphu
      • Position ASD Model as an alternative to current ETSI Standard proposal to move forward with "Cloud Native Architecture"
        • ASD implemented as plug & play (you choose onboarding ASD / ETSI / others)
        • Known Impacts: SO e.g. CNF O (particular Camunda) + SDC /AAI (to be determined by POC work) + particular VES Collector - Byung-Woo Jun to review this part 
      • Work with the Modeling Team cl664y@att.com 
      • Continue to share to ETSI what we do Thin, Byung-Woo Jun  - increase visibility

...

  • ASD PoC Status update - Byung-Woo Jun 
    • SO and SDC teams from Ericsson are working on the PoC
    • SDC team is working on the resource VF. working on TOSCA parser. Map ASD into VF, Wrap in CSAR and distribute.
    • SO team working on LCM swagger definition for northbound API. Waiting for creation of PoC branch. Focusing on calls from BPMN to CNFM.
    • Lukasz Rajewski - Will the ASD LCM API be integrated with the rest of the LCM API? 
    • The PoC handles onboarding and instantiation with variables.
    • Slide deck - Byung-Woo Jun , ASD-PoC-Status-20220329.pdf
    • Vishal Sharma - ETSI is expected to come up with SOL003 specifications, is there work planned to support it? Byung-Woo Jun , Fernando Oliveira - There is definition work ongoing for the ETSI approach, but actual development has not yet started.
    • Target for PoC - Initially was Jakarta, but now it is clear some functionality will slide into Kohn

Apr 5th, 2022 at 1pm UTC 

  • Updates from ETSI workshop - @Thinh
  • Attendance in today's meeting is lower than usual and we are missing some key people. Should we re-visit the meeting time? Ranny Haiby will follow-up on the mailing list.

Apr 12th, 2022 at 1pm UTC 

  • Low attendance. New meeting time? Poll - https://doodle.com/meeting/participate/id/axkGzYqe
  • Update from the requirements workgroup - Ranny Haiby 
  • Question - How does EMCO fit the picture with ASD? What can ONAP delegate to EMCO? What will be mapped to EMCO's "composite application"?
  • Byung-Woo Jun - It should be possible to create an adapter from CNFO to EMCO, but more details are required, expecting to learn from Seshu Kumar Mudiganti's experimenting with EMCO.
  • some update from Catherine: Raghu from aarna will be on the enterprise meeting tomorrow to update us about ONAP/Magma integration.
  • Project Nephio - To be announced this week. 
  • Updates from ETSI workshop - @Thinh
    • The last workshop was about handling the Q&A from previous meeting. No action items
    • The ETSI-NFV folks understand the rationale behind ASD. 
    • Future collaboration will probably take place through our modeling subcommittee.
    • Current modeling work is focused on the ETSI-alignment path. 

...

Apr 19th, 2022 at 1pm UTC 

...

  • Update from Seshu Kumar Mudiganti on SO EMCO integration.
  • Nephio update - The project TSC meetings are tentatively scheduled to start on the week of May 9th. ONAP project members are welcome to join and ask questions. Once an official invite is sent, Ranny Haiby will share it on the CNF Taskforce mailing list.
  • Reach out to Seshu Kumar Mudiganti over email to figure out best time for him to attend (AI Ranny Haiby )

May 3rd, 2022 at 1pm UTC 

  • ?

...

  • Follow-up on DTF sessions, if necessary
    • No open action items
  • Review roadmap from Jakarta. It would be great that we reviewed what we defined in our roadmap for Jakarta. What has been done and what it is left.image2022-1-18_15-54-1.png (1166×618) (onap.org) (cl664y@att.com )
    • Move to next week

  • For CNFO there is CNF Upgrade work to be completed in Kohn. (Lukasz Rajewski )

    • On track to deliver in Kohn

  • For other more heavy topics we need to discuss further on ONAP/EMCO, especially when Nephio came to the picture. I believe  Nephio will become more a requirement for deployment of specific CNFs and it must be firstly adopted by CNF vendors, but ONAP will have to integrate with it at some point. Also, due to the fact the Nephio opts against orchestration of helm packages we should think on consequences of this approach in a long term as helm is used in CNFO, ASD and EMCO. (Lukasz Rajewski )

    • Wait until after the Nephio summit. Follow up next week.

  • I would like to discuss further about the plans of ASD integration into ONAP, beyond the PoC phase.  (Lukasz Rajewski )

    • Concern about the separate flows/APIs for CNF orchestration using ASD. 
    • Need input from Ericsson about the effort to merge the flows.

  • Drafting the ONAP CNF requirements for CNF conformance and verification badges. Understand if we are mature enough to start with a first iteration of a “ONAP compliance CNF” verification/badge?   Yan Yang  (Olivier Smith ). Anuket Assured Program (AAP) - we were discussing on how to draft and establish the basic requirements for CNF conformance and validation badging using ONAP. So I would like to bring this to your notice to discuss further on it. (Former user (Deleted) )

    • Olivier Smith  Yan Yang presented the different certification types of Anuket Assured, present and future. AAP2022 Planning and VNFCNF badging Requirements for ONAP.pdf
    • For the CNF workload, there could be three different certifications - (1) Compliance with Cloud Native best practices. (2) Compliance with Anuket infra (3) Compliance with ONAP orchestration (or EMCO, Nephio)
    • It is up to the ONAP community to determine the best practices, requirements and test cases for the certification
    • Lukasz Rajewski presented the current set of best practices for designing and packaging CNFs for ONAP orchestration. These could be turned into requirements, and test cases.
    • We need to have a discussion in the ONAP community on how to create the tests and how it will be resourced. We will follow up with the Anuke Assured team in a couple of weeks.

  • Nephio vs. MANO (no ETSI NFVO, no VNFM/CNFM, may not CNFO) and pushes down CNF management to Kubernetes; i.e., Kubernetes-based Cloud automation. They are using CRDs (for Infrastructure, Workload and configuration). I expect significant changes around the way of helm chart-based CNF management if Nephio is applied. We will see… (Byung-Woo Jun )

    • Wait until after the Nephio summit. Follow up next week.

...

  • Nephio/ONAP/EMCO integration

    • What did we learn at the Nephio summit?

      • Not attempting to compete with ONAP
      • Focusing on Infra, K8S and workload, as well as configuration
      • It is clear that Google is not in favor of Helm charts. They try to push the KPT packaging.
      • TSC and four SIGs were formed. SIG1 (Architecture) is expected to be led by a service provider.
      • Blog post by Aarna with some details - https://www.aarnanetworks.com/post/what-is-the-linux-foundation-nephio-project
      • Where is this discussion going to continue? TSC according to Google.
  • XGVela
    • Started using OKD
    • Topology management will be in the first release. Configuration is a stretch goal.
    • Seshu Kumar Mudiganti is working on a PoC integrating ONAP and XGVela. Will share a demo soon.
  • Anuket Assured program 
    • Follow up on last week's presentation by the Anuket team - What do we want to include in the certification? Resources? - Discuss in TSC.

July 7th, 2022 at 1pm UTC

tbd

July 14th, 2022 at 1pm UTC

  • Plans of ASD integration into ONAP, beyond the PoC phase.

    • Concern about the separate flows/APIs for CNF orchestration using ASD. 
    • Need input from Ericsson about the effort to merge the flows.TSC.


July 7th, 2022 at 1pm UTC

  • Nephio summit recording are now available - https://drive.google.com/drive/folders/1o_VwSifi1_Ksy5YaCixCHKjACvksztQB
    • Recommended session - Day1 recording, starting at 3:06:20 (pdf slide deck starting at slide #48) (Brian Grant). The two sessions after that by Stephen and John from Google are also not bad.
  • SO/EMCO integration - planned to be merged soon, hopefully during August.
  • We had a short meeting due to the light agenda, and no recording because Ranny Haiby forgot to click the button.

July 14th, 2022 at 1pm UTC

July 21st, 2022 at 1pm UTC

  • (Reminder - record the meeting)
  • Follow up questions related to the ASD PoC presentation from July 14th
    • Is the PoC using the service instance API? Byung-Woo Jun - not yet. Building block implemented, but no macro.Lukasz Rajewski recommends using the API for better integration with other workflows. That will enable orchestrating CNFs together with other parts of the Network Service.
    • Marian Darula - There is a need to model a distributed service, which is deployed in multiple edge locations. ETSI-NSD concept is one option for that. EMCO seems to have support for a similar concept and may be an option, too.
    • Byung-Woo Jun - The CNFM functionality is separated in the SO, and it may use multicloud, or call EMCO in the future. The motivation was to minimize changes on existing ONAP modules. The only difference between ASD orchestration and other orchestration flows is the interface to the "ASD repository" and "Helm Artifact Repository". CNFO does not interact with the "Image Artifact Repository", this is done directly from the K8S cluster. Parameterization is done by SO providing the overridable parameters (based on user input) to the CNFM. The CNFM uses these parameters to crate the instance level Helm chart. (Referring to slide #9 in last week's presentation ASD-PoC-Update-Plans-2022-07-14-v3.pptx
    • Lukasz Rajewski - The existing orchestration macro is very close in its functionality to what was done in the ASD PoC. Recommends the ASD PoC be merged with the CNFO approach.
    • Question about whether K8S API is used directly or through kubectl? currently kubectl is used.
    • Lukasz Rajewski - The SO integration with EMCO was done in a different way than depicted in the ASD PoC diagram. 

July 28th, 2022 at 1pm UTC


August 4th, 2022 at 1pm UTC

  • (Reminder - record the meeting)
  • Byung-Woo Jun provided a sneak preview of proposed work for ASD considerations for NSD, where NSD may consist of ETSI VNF/CNF and ASD CNF.
    • Proposed architecture keeps the ASD CNFM as a separate module, with an API that can be called by the SO CNFO.
    • The ASD CNFO will not rely on multi-cloud. 
    • Will be presented in future meeting when the Ericsson team is ready to present. Byung-Woo Jun will add to the agenda when ready.
    • The team working on CNFO may have a slightly different view - prefer having the ASD CNFM integrated inside the SO BPMN infra, not as a separate module. 


August 11th, 2022 at 1pm UTC

  • This meeting is cancelled due to summer vacations


August 18th, 2022 at 1pm UTC


August 25th, 2022 at 1pm UTC

  • (Reminder - record the meeting)
  • No topics to discuss - should the meeting be cancelled?

September 1st, 2022 at 1pm UTC

  • (Reminder - record the meeting)
  • What do we want to do next on our meetings?




Action Item(s) (In Progress)

  •  (CNF Task Force): What do we need to ask to CNF Vendors to be onboarded on the ONAP Platform? These reqs could be shared with Anuket Assurance for the CNF badging

...