Members

Kickoff Materials

VZDeploymentOptions.pptx

Meeting Information

Meetings suspended until March 21

Weekly meeting times for the winter: Mondays at 1200 UTC, 4AM PST, 7AM ET, 1300 CET, 5:30 PM India, 8PM China.

https://zoom.us/j/722438866?pwd=d3VTTFJiK3Bkeml2RlRqVkdhSlhKQT09

One tap mobile: +16699006833,,722438866#  US (San Jose)            +16465588656,,722438866# US (New York)

====================

Agenda for March 21

Agenda for Feb 7

  1. ASD Model/PoC
  2. ETSI v4.3.1 Info Model
  3. Other??

Agenda for Jan 31

  1. Progress report on ASD Model/PoC
  2. Meeting date/time?
  3. Other business??

Recording: video1349381457.mp4

Agenda for Jan 24

  1. Progress report on ASD PoC
  2. Change meeting to Bi-Weekly?
  3. Other business??

Recording: video1403500437.mp4

Agenda for Jan 17

  1. Progress report on ASD PoC
  2. Other business??

Given the vacation schedules, no meetings in December.

Agenda for November 22

  1. Update on ASD IM and PoC

Recording: video1750611279.mp4

Agenda for November 15

  1. Update on ASD IM
  2. Update on ASD PoC
  3. Other??

Recording: zoom_0.mp4

Agenda for November 8 ( No meeting due to DST confusion)

  1. Update on ASD IM
  2. Update on ASD PoC
  3. Other??

Agenda for November 1

  1. Update on ASD IM
  2. Update on ASD PoC

Recording: zoom_0.mp4

Agenda for October 25

  1. Other items??


Agenda for October 18

  1. Update ASD IM model: asdExtCpd, enhanceClusterCapability, O-RAN OAM IE mapping
  2. SOL004 change for ASD support.
  3. Other Items??

Recording: zoom_0.mp4

No meeting on October 11

Agenda for October 4

  1. TSC presentation (ASD, ETSI 4.2.1)
  2. Update on ASD IM/DM
  3. Other Topics??

Recording: zoom_0.mp4

Agenda for September 27

  1. Updated ASD IM/DM (Ericsson/Nokia)
  2. Update on ASD PoC (Byung)
  3. Other??

Recording: zoom_0.mp4

Agenda for September 20

  1. ASD PoC?
  2. Other??

Recording: zoom_0.mp4

Agenda for September 13

  1. ETSI 4.2.1 IM Model Discussion (https://wiki.onap.org/download/attachments/103423188/ONAP%20ETSI-Alignment%20Resource%20IM-v4.2.1.pptx?version=1&modificationDate=1630322466000&api=v2)
  2. ASD Follow-up?
  3. Other??

Recording: zoom_0.mp4

Agenda for August 30

  1. Jakarta ASD Onboarding and Orchestration PoC plan
    1. Helm Processor/Helm functions, roles and interfaces; dry-run scope
    2. Interface between Helm and O-Cloud (O2-DMS-K8S?)
    3. see, ASD Onboarding and Orchestration PoC
  2. Other topics?

Recording: orchestration_scenario-2021-08-30.mp4

Agenda for August 23

  1. Continue discussion on ASD proposal?
  2. Other topics?

No meeting on August 16

Agenda for August 9

  1. Continue discussion on ASD proposal?
  2. Other topics?

Recording: zoom_0.mp4

Agenda for August 2

  1. Continue discussion on ASD proposal?
  2. Other?

Recording: zoom_0.mp4

Agenda for July 26

  1. Continue Discussion on ASD proposal?
  2. Other?

Recording: zoom_0.mp4

No Meeting on July 19

Agenda for July 12

  1. Continue discussion on ASD proposal.
  2. Other??

Recording: zoom_0.mp4

No Meeting on July 5 (US Holiday)

Agenda for June 28

  1. Continue discussion on ASD proposal
  2. Other??

Agenda for June 21

  1. Continue discussion on ASD proposal
  2. Other?


Agenda for June 14

  1. Discuss ASD and ETSI VNFD Proposals.
  2. Discuss the SMO behavior
  3. Other?

Recording: zoom_0.mp4

No meeting on June 7 ( LFN DTF: 7-11 June)

No Meeting on May 31 (US Holiday)

We will be meeting to discuss the Container data model proposals just before this weeks SO call at 1300 UTC, 9am EDT

Agenda for May 24

  1. Continue discussion on the ASD Packaging/Descriptor
  2. CNF presentation for LFN DDF June 2021
  3. Other Topics?

CNF Descriptor Proposals Wiki page: Application Service Descriptor (ASD) and packaging Proposals for CNFs

Recording: zoom_0.mp4

No meeting on May 17

Agenda for May 10

  1. Discuss ASD packaging/Descriptor proposal https://wiki.onap.org/download/attachments/93004634/ONAP_Nokia_Ericsson_K8S_application_descriptor_and_packaging.pdf?version=1&modificationDate=1620314813000&api=v2
  2. Other Topics??

Recording: zoom_0.mp4

No meeting on April 26 or May 3

Agenda for April 19

  1. Any Topics??

Agenda for April 12

  1. ETSI NFV Presentation Update.
  2. Other Topics?

Agenda for April 5, 2021

  1. ETSI NFV Presentation
  2. Other??

Agenda for meeting on March 29, 2021

  1. Honolulu Status
  2. ETSI/NFV Meeting presentation
  3. Other Topics?

Agenda for meeting on March 22, 2021

  1. Honolulu Status
  2. Istanbul Proposed Requirements
    1. SOL001 4.2.1 draft : https://docbox.etsi.org/isg/nfv/open/drafts/SOL001ed421/NFV-SOL001ed421v402.zip
  3. Other?

No Meeting on Mar 15, 2021


Agenda for meeting on Mar 8, 2021

  1. Honolulu Status of ETSI Alignment
  2. Review R9 Proposed Requirements: Istanbul release - functional requirements proposed list
  3. Review R9+ Proposed Data Model:  Proposed R9+ VNF/CNF Data Model Based on ETSI SOL001 v4.2.1
  4. Meeting time for March 14?
  5. Other Topics??


LFN ONAP-ETSI Alignment Architecture & Features for Honolulu+

  • Presentation slide deck PPT on February 2nd, 2021:

  • Presentation slide deck PDF on February 2nd, 2020:


Agenda for meeting on Feb 1, 2021

  1. DDF Presentations.
  2. Other?

Agenda for meeting on January 25, 2021

  1. Discuss LFN Presentations 
  2. Discuss ETSI Contributions
  3. Other Topics

Recording: zoom_0.mp4

No Meeting on January 18, 2021 due to US Holiday.

Agenda for meeting on January 11, 2021

  1. Discuss Architecture Presentation
  2. Honolulu commitment

Recording: zoom_0.mp4

Agenda for meeting on January 4, 2021

  1. Discuss updated ETSI 3.3.1 + Container Support Data Model VNF/CNF Data Model Based on ETSI v3.3.1 SOL001 plus CNF Enhancements
  2. Example VNF-D using above model CSAR Models
  3. Honolulu Progress
  4. Other topics?

No meeting on December 14, 21 or 28

Agenda for meeting on December 7

  1. Data Model Discussion
  2. Example CSAR
  3. Other topics?

Agenda for meeting on November 30

  1. CNF changes to SOL001 and SOL004
    1. multiple helm chart support?
    2. VNFD optional discussion?
    3. data model

Agenda for meeting on November 23

  1. Honolulu requirements and epics
  2. CNF changes to SOL001 and SOL004
  3. SOL004 security changes

Recording: zoom_0.mp4

Agenda for meeting on November 16

  1. Support for SOL004 package with individually signed artifacts
  2. Discuss Prototype SOL004 package with support for CNF
  3. Discuss Prototype SOL001 VNF-D descriptor with CNF support (osContainer & mciopProfile)
  4. Other topics?

Recording: https://zoom.us/rec/share/DrOxPvlCPf2GXjxOhB320NshVYVOfAkaKy90naY9blWSHkWmpxF2q2HJ4qfQcu5z.4a9g4dzDYKgvhnaT

Agenda for meeting on November 9, 2020

  1. Guilin Status
  2. Honolulu Prioritization and task assignment
  3. Onboarding Package specs
  4. SDC AID mapping
  5. Other?

Recording:zoom_0.mp4

Agenda for meeting on November 2, 2020

  1. SOL004 Package and SOL001 VNF-D Spec
  2. SDC AID mapping of 4.1.1 VNF-D
  3. ETSI NS base 5G Slicing
  4. Meeting Time?
  5. Other?

Agenda for meetong on October 26, 2020

  1. Guilin integration
  2. Honolulu Resource IM and mapping to SDC AID DM
  3. Meeting time next week. 13:00 UTC?
  4. Other ??

Recording:zoom_0.mp4


Agenda for meeting on October 19, 2020

  1. Guilin Integration and RC0
  2. ONAP IM changes aligned with IFA011 v4.1.1 (ETSI IFA011 v3.3.1 & v4.1.1 Changes to support OsContainer based VNFs)
  3. Other??

Recording:zoom_0.mp4

Agenda for meeting on October 12

  1. LFN DDF Presentation - 
  2. ETSI IFA Presentation - 
  3. Honolulu Requirements - 
  4. Other??

Agenda for meeting on October 5

  1. SDC AID DM changes for Guilin
  2. ETSI CNF support for Honolulu
    1. ETSI IFA Presentation Oct 14
    2. ETSI 4.1.1 IM
    3. Mapping to SDC AID DM
    4. VNFM that supports CNFs
  3. Other topics?

Agenda for meeting on Sep 21

  1. R7 Requirements
    1. SOL004/SOL004 v3.3.1?
    2. SOL003 v3.3.1?
    3. SOL005 v3.3.1?
    4. Nested NS?
    5. Hierarchical Service→NS
  2. ETSI Aligned Configuration
  3. Other??

Recording:

Topic: Orch Scenarios/ETSI Alignment
Start Time : Sep 21, 2020 11:49

Meeting Recording: https://zoom.us/rec/share/sYFtVx7AUwJIt6BdkmWCI05Rr43jNn9vRnq80cDxInBrjs36wuVwQWOIRVWHSP8N.MIl47Ym7g-X68JTJ?startTime=1600689712000

Access Passcode: 57$RLt6b

ETSI NFV presentation for ONAP ETSI-Alignment on September 15

Agenda for meeting on Sep 14

  1. Review ONES slides
  2. Discussion on Honolulu requirements
  3. Other topics?

Agenda for meeting on Aug 31

  1. Review ONES Slide
  2. Other Topics?

Agenda for meeting on Aug 17

  1. Review changes to support ETSI IFA011 4.1.1 containerized VNF in ONAP IM.
  2. Other topics?

Agenda for meeting on Aug 3

  1. Discussion on changes required to map the ETSI SOL001 VNF model to AID DM
  2. Other

Agenda for meeting on July 27

  1. DIscussion of ETSI CNF modeling
    1. IFA011 v4.1.1 → ONAP IM
    2. ETSI compatible mapping of C/VNF IM to AID DM
  2. Progress on incorporating ETSI 2.7.1 changes (NS & VNF) into  ONAP IM
  3. Other 

Recording: #arc Taskforce 1 (Orch ScenariosETSI Alignment)-20200727 1206-1.mp4

Agenda for meeting on July 20

  1. 2.7.1 Network Service Descriptor and impact on VF-C
  2. Current 2.7.1 Information model changes
  3. Other

Recording:https://zoom.us/rec/share/If_oZq5Nqd_GM0KAE6CoZjBc8EKByXsRlA8qQCQLhTcCdL7iyAUBDisFcGS1XA15.UTsLxm6xsGqXu2yT?startTime=1595246626000

Agenda for meeting on July 13

  1. 2.7.1 modeling updates
  2. Effect on VF-C of 2.7.1 changes
  3. Other

No Meeting on July 6


Agenda for meeting on June 29

  1. Progress of CNF Modeling
  2. Progress on VNF to DM AID modeling


Agenda for meeting on June 8, 2020

  1. Discuss which parts of the 2.7.1 specifications should be targetted for the Guilin release.
  2. Other?

Agenda for meeting on June 1, 2020

  1. Update on Information Model changes in IFA 2.7.1
  2. Other Topics?

Recording: zoom_0.mp4

Agenda for meeting on May 18, 2020

  1. Status update of Frankfurt tasks (SOL003 adapter, SOL003 Adapter, SOL005 Adapter)
  2. Aarna Networks Update
  3. Status updates of proposed requirements Arch reviews
  4. Plan for modeling changes needed to support ETSI SOL001 (v2.7.1) to be converted to AID DM.
  5. Other?

Recording: zoom_0.mp4

Agenda for meeting on May 11, 2020

  1. DIscussion on ETSI CNF modeling presentation
  2. ETSI progress report
  3. Other Topics?

Recording: zoom_0.mp4

Agenda for meeting on May 4, 2020

  1. Discussion of NFVO component
  2. Other Topics?

Recording: zoom_0.mp4

Agenda for meeting on April 27, 2020

  1. Review ofVF2F meeting
  2. Other Topics?

Agenda for meeting on April 20, 2020

  1. Discuss presentation for VF2F meeting
  2. Other Topics?

Meeting recording: OrchestrationScenarios-20200420 1210-1.mp4

Agenda for meeting on April 13, 2020

  1. Other Topics?

Meeting recording: zoom_0.mp4

Agenda for meeting on April 6, 2020

  1. Adapter naming discussion
  2. Common components among the SOL adapters
  3. Continue on SOL001 AID discussion
  4. Other Topics?

Meeting recording:

Agenda for meeting on March 30, 2020

  1. Continue on SOL001 AID DM for VNF & NS discussion
  2. Update on SOL002, SOL003, SOL005 Adapters

March 30 recording: zoom_0.mp4.zip  Had to zip to get the file uploaded.

Agenda for meeting on March 23, 2020

  1. Continue on SOL001 AID DM for VNF & NS discussion
  2. Other Topics?

March 23 recording: zoom_0.mp4

Agenda for meeting on March 16, 2020

  1. SDC Guilin enhancements (Requirements, Epics and User stories) for ETSI package management - Byung (20 minutes)
  2. Meeting time discussion/poll for whether to move this meeting to 1200 UTC/8am ET for the duration of the daylight/summer time.
  3. Start SOL001 AID DM for NS and VNF Discussion
  4. Other topics

March 16 recording: zoom_0.mp4

Agenda for meeting on March 9, 2020

  1. IFA WG presentation on the IFA040 technical overview and others (30 minutes) - IFA WG FEAT17 CNF Presentation
  2. (Postponed) SDC Guilin enhancements (Requirements, Epics and User stories) for ETSI package management - Byung (20 minutes)
  3. other topics

March 9 recording: zoom_0.mp4

Agenda for meeting on March 2, 2020

  1. Presentation for NFV Release 2 Testing; API Conformance Testing Specification (ETSI Robot Test cases for testing SOL002/SOL003/SOL005, and all resources) by Pierre Lynch
    1. the latest draft: https://docbox.etsi.org/ISG/NFV/Open/Drafts/TST010_API_Conformance_Testing/NFV-TST010v241_0013.docx
    2. Robot test cases: https://forge.etsi.org/rep/nfv/api-tests
    3. Presentation slide deck: 
    4. The Plugtest information: https://www.etsi.org/events/1683-nfv-mec-plugtests
  2. SDC Requirement Discussions for Guilin
    1. Guilin release - functional requirements proposed list
  3. SDC-ETSI Catalog Manager direct interface - update

Agenda for meeting on February 24, 2020

  1. Recap ETSI NFV SOL presentation and follow-up actions
  2. Need alternate host for Mar 2
  3. ETSI NFV TST010 robot tests for SOL002/SOL003/005 testsuite:https://docbox.etsi.org/ISG/NFV/Open/Drafts/TST010_API_Conformance_Testing/NFV-TST010v241_0013.docx, https://forge.etsi.org/rep/nfv/api-tests
  4. Review updated Guilin requirements Guilin release - functional requirements proposed list
  5. Other??

Feb 24 recording: zoom_0.mp4

Agenda for meeting on February 17, 2020

  1. ETSI Catalog Manager proposal Byung-Woo Jun
  2. Review presentation for ETSI NFV SOL WG meeting on Feb 18, 2020
  3. SOL005 Adapter Status sambasiva K
  4. SOL003 Adapter Status
  5. Review proposed requirements that Fernando Oliveiraentered for Guilin release - functional requirements proposed list
  6. Any other topics?

Feb 17 recording: zoom_0.mp4

Agenda for meeting on February 3, 2020

  1. ETSI Specification Update - Thinh Nguyenphu
  2. SOL005 Adapter Status - Verizon Team 
  3. SOL002 Adapter Status - Miroslaw Medrek
  4. SOL003 Adapter Status - Byung-Woo Jun  (May not be able to attend)
  5. Discuss ETSI Alignment presentation to ETSI at NFVSOL #128 2/18-2/20

Feb 3 recording: zoom_0.mp4

Agenda for meeting on December 23

  1. Discuss presentation for Prague DDF
  2. SOL003 Adapter in SO discussion

Dec 23 recording: zoom_0.mp4

Agenda for meeting on December 16

  1. Discuss ETSI Alignment presentation for Prague DDF
  2. Status of SOL002 contribution
  3. SOL003 Adapter Plugin for APP-C 

Agenda for Meeting on December 9

  1. Discussion on ETSI Alignment tasks for Guilin Release - Byung-Woo Jun
  2. SOL002 presentation - Miroslaw Medrek

Dec 09 recording:zoom_0.mp4

No Meeting on December 2 due to no agenda items

  1. Please let me know if you have an agenda item for Dec 9

Agenda for Meeting on August 26th 8am ET

  1. Discussion on the ETSI Alignment Architecture, ETSI Alignment Support, and scope for Frankfurt
  2. ETSI Package Management (Onboarding and Distribution), ETSI Package Management
  3. Other Topics

No meeting on September 2 due to US and India holidays

Agenda for Meeting on September 9th 8 am ET

  1. SOL005 Adapter Architecture and Operations for Frankfurt
    1. SOL004/SOL001 NS Onboarding and Distribution
    2. SOL005 Adapter Architecture, Design and Code Review
    3. SOL005 NBI Use cases and Use of API-Fabric for SOL005 NBI
  2. SOL002 Adapter High Level Discussion
  3. SOL004 Package Security - finalize the scope
  4. SOL003 Adapter Operations

Agenda for Meeting on September 16th 8 am ET

  1. ONAP-ETSI Catalog Manager & SO ETSI Catalog Management, ETSI Catalog Management
    1. CMCC will present the ONAP-ETSI Catalog Manager
    2. Team will discuss So ETSI Catalog Management by leveraging the ONAP-ETSI Catalog Manager
  2. ETSI Package Management
    1. SOL007 NS support
    2. SOL004 VNF/PNF support
  3. HPA support in the ETSI-Alignment & Granting with HPA, SOL003 Adapter Granting Section
    1. the presentation plan is under discussion with Intel and Ericsson
    2. VNF Level Homing requests are under discussion
  4. SOL002 Adapter Architecture and Operations for Frankfurt
    1. the presentation plan is under discussion with Samsung

Additional Discussion Topics for next meetings

  1. SOL003/SOL005/SOL002 Adapter Operations, SOL003 Adapter, SOL005 Adapter, SOL002 Adapter
  2. SOL001 VNFD Internal Representation (to SDC AID DM), SOL001 Mapping to SDC AID DM
  3. SOL001 NSD Internal Representation (to SDC Service), SOL001 Mapping to SDC AID DM
    1. Initial input, Internal NSD representation
  4. SOL002 Adapter Deployment Location - APPC?
  5. Communication Security - AAF-based ONAP ETSI Adapters and external SVNFM/NFVO
  6. Vendor VNF Requirements (is ONAP-compliance required? on VES Event support and others)
  7. Application Configuration options via ETSI standards (e.g, through VNFM) or OSS/BSS/EM to VNF
  8. CNF support and Granting impact for Kubernetes-based Resource Management 
  9. Other Topics...

Agenda for Meeting on  August 19 9am ET - Done

  1. Discussion on scope of this task force
  2. Alternate Host for next 4 weeks as Fred will be away.
    1. Byung-Woo Jun (Ericsson) will cover Fred for next 4 weeks
  3. Other Topics?

==============================

Future

Continue review of the requirements for Frankfurt Release

Continue discussion on Application Configuration for ETSI MANO VNFs.

CDS directly to SOL003 instead of APP-C?

Future topics:

  1. Discussion on whether ETSI NFV VNF SOL003 should be a Controller or Adapter.  ONAP_GNF_ControllersSOL003.pptx
  2. Should VNF deploy/scale  (LCM actions)  be GNFC actions?
  3. How would this apply to containers?
  4. Please add any topics that you think should be included.

Assumptions:

  1. Operator has already deployed ETSI SOL003 compliant VNF Manager(s)
  2. Operator has already deployed ETSI SOL005 compliant NFVO(s)
  3. Operator has existing Service Assurance tools that VNF(s) interact with
  4. Operator is currently using proprietary mechanisms to configure NFs
  5. Operator has used above mechanisms to deploy SOL001/SOL004 compliant VNFs
  6. Operator has multiple VIMs; with different HW capabilities and configurations
  7. Operator desires to integrate ONAP into the existing environment

Objectives

  • Examine orchestration scenarios in order to determine if new architectural requirements are necessary
  • Develop recommendations for composition of the ONAP Service DM (How does the ETSI NFV SOL001 Network Service Descriptor supported?)
  • Develop recommendations for interfaces between the orchestration elements (OSS, SO, VF-C, VNFM, NFVO)
  • Develop recommendations for how ONAP controllers work with external orchestration elements (NFVO, VNFM, EMS)
  • Develop recommendations for how external Service Assurance interacts with DCAE and Policy
  • Develop recommendations on breaking ONAP into more modular consumable pieces (Margaret)

To Do's

  • Recommendation on whether an ONAP should support an E2E Service  that is composed of xNFs that are orchestrated by separate orchestrators (SO,  SO + external VNFM, VF-C, external NFVO) for next Arch meeting (Nov 13)
  •  Mapping of SOL005 APIs to ONAP NBI
  • Develop scenarios with stories about how ONAP could be used in near term brownfield  legacy environment Fernando Oliveira
  • Develop scenarios with stories about how a legacy environment could migrate off of a brownfield legacy environment towards a ONAP native model Fernando Oliveira
  • Describe how ONAP DCAE could be integrated with legacy Service Assurance platform Fernando Oliveira
  • Describe how legacy inventory system would interact with ONAP A&AI
  • Develop scenarios for how Application Configuration could be supported with enhanced SOL001 VNF-D using an external SOL003 compliant VNF Manager Fernando Oliveira 

Scope

GeneralDublinFrankfurtGuilin












Implications/Requirements

  1. External VNFM scenarios (ONAP acting as an OSS/NFVO):
    ONAP-SOL003-VNFM
    1. ONAP needs to ingest and save (without modification) a SOL004 CSAR package for later consumption by a SOL003 compliant VNF Manager (VNFSDK, SDC)
      1.  Original CSAR contents need to be preserved since some VNF Managers validate the manifest signatures of each file in the CSAR
    2. ONAP needs to ingest and interpret a SOL001 compliant VNF Descriptor in order to design an ONAP Service (VNFSDK, SDC)
    3. ONAP needs to understand resource requirements in the VNF-D for each deployment and scaling level (SO, A&AI, OOF)
      1. ONAP needs a way to ingest or create a VIM tenant/project space (SO, SOL003 Adapter, Multi-Cloud/VIM)
      2. ONAP needs to inventory  the VIM tenant/project resources and capacity (A&AI, Multi-Cloud/VIM)
      3. ONAP needs to confirm that the VIM resources (vCPU, RAM, Storage, Network, EPA (SR-IOV, GPU, Pinnned CPU, Locked RAM, ..), ...) necessary for the deployment or scale operation are available (SO, A&AI, OOF)
      4. Such resources should be reserved if the VIM has that capability (OOF, Multi-Cloud)
    4. ONAP needs to have a SOL003 compliant SBI (SOL003 Adapter, APP-C, VF-C, GNF-C, SO))
    5. ONAP needs a mechanism for specifying that a VNF instance should be runtime managed by a particular VNFM type (design time)  and instance (run time) (SDC, OOF, SO)
      1. This likely also applies to other external controllers
    6. ONAP needs to have a way to inventory a VNF that was deployed using an external VNFM and which instance of the VNFM (A&AI, SO, SOL003 Adapter, VF-C) 
  2.  External NFVO scenarios (ONAP acting as an OSS or hierarchical Service Orchestrator):
    1. ONAP needs to ingest and save (without modification) a SOL004 CSAR package for later consumption by a SOL005 compliant NFVO (VNFSDK, SDC)
    2. ONAP needs to ingest and interpret a SOL001 compliant VNF Descriptor in order to design an ONAP Service (VNFSDK, SDC)
    3. ONAP needs to have an SBI that can be used to manage external Service(s) (SO, SOL005 Adapter)
      1. ETSI NFV MANO SOL005 Os-Ma-nfvo interface
        1. ONAP needs to be able to convert an ONAP Service into a SOL001 compliant Network Service Descriptor (SOL005 Adapter)
      2. VF-C "internal SOL005" interface
      3. ONAP Service NBI
      4. Open Source Mano (OSM) NBI
    4. ONAP needs a mechanism for specifying that a service should be runtime managed by an external NFVO (SDC, SO, A&AI)
    5. ONAP needs to have a way to inventory a Service that was deployed and managed by an external Service Orchestrator (A&AI, SO, SOL005 Adapter)
    6. ONAP needs a way to ingest and save (without modification) a SOL007 Network Service Package) (VNFSDK, SDC)
    7. ONAP needs to ingest and interpret a SOL001 compliant Network Service Descriptor (SDC, SO)
      1. Possibly translating it into an ONAP Service
    8. ONAP needs to be able to design a hierarchical Service that references zero or more VNFs along with one or more "sub-services" (Alloted Resources??) (SDC, SO)
  3. VNF Application Configuration over SOL003 ModifyVnfInfo interface using an External vendor specific VNF Manager
    1. ONAP needs to ingest and interpret a SOL001 compliant VNF Descriptor that includes ConfigurableProperties (VNFSDK, SDC)
    2. ONAP needs to present these ConfigurableProperties in the design of an ONAP Service (SDC)
    3. Upon Service deployment, ONAP needs to pass the application ConfigurableProperties along with the related values to the external VNFM that was used to deploy the VNF using the SOL003 ModifyVnfInfo interface (SO, APP-C, SOL003 Adapter)
    4. As part of a Change Management operation, ONAP needs to pass the updated ConfigurableProperties and new values to the  external VNFM that was used to deploy the VNF using the SOL003 ModifyVnfInfo interface (SO, APP-C, SOL003 Adapter)
    5. As part of an ONAP recovery operation, ONAP needs to query the VNF to get the current state and values of the ConfigurableProperties using the external VNFM that was used to deploy the VNF using the SOL003 Query interface (SO, APP-C, SOL003 Adapter)

Contributions...

Recording of call 11/12/2018: double_click_to_convert_01.zoom

Recording of call Dec 17, 2018: [Onap-arc] Orchestration Scenarios and implications on modeling weekly-20181217 1404-1.mp4

VZDeploymentOptionLegacy.pptx

Updated with Application configuration and Hierarchical Service (VNF + NS): VZDeploymentOptionLegacy.pptx

https://docbox.etsi.org/ISG/NFV/Open/Other/Tutorials/Tutorials-201810_SDN_NFV_World_Congress-The_Haque/ETSI_NFV_Layer123_VNF%20Configuration-v2_RX15009.pdf

Recording of Dec 20, 2018 call: [Onap-arc] Orchestration Scenarios Discussion on ETSI VNFD ConfigurableProperties-20181220 1806-1.mp4

OrchestrationScenariosDDF.pptx

ONAP_GNF_ControllersSOL003.pptx

ApplicationConfigElAlto.pdf

OrchestrationScenariosEF2F.pdf

Meeting Notes and Recordings

DateNotesRecording
August 12, 2019
  1. Move Meeting time one hour Earlier
None
August 19, 2019
  1. Need coordination between API Fabric work and the ONAP SOL005 NBI Adapter
  2. Need to add APP-C block into the ETSI diagram
  3. Need follow-up on how the SOL003 LCN and Indicator interfaces flow through the SOL003 Adapter
    1. May need to bring detail the GNF-C flows and how that would replace the direct SOL003 Adapter interface from SO
  4. For package security, the SDC will validate the vendor package.  The original package will be saved in the ONAP ETSI catalog and passed to the any external VNFM, VF-C or external NFVO which may also do validate the package independently
  5. Frankfurt scope table added with initial scope proposal

OrchestrationScenariosAug19.mp4

audio_only.m4a

August 26, 2019
  1. Discussion on the ETSI Alignment Architecture, ETSI Alignment Support, and scope for Frankfurt
    1. Went over the meeting topics for the next meetings, as scope discussions
    2. For now, SOL007 package onboarding is out of scope
    3. Use of GNFC for ETSI Alignment is under discussion, most likely out of scope
    4. Verizon will go over the SOL005 Adapter architecture, design and use cases at the next meeting 
    5. CMCC will go over the ONAP-ETSI Catalog Manager at the next meeting
    6. Samsung will present the SOL002 Adapter use cases and design soon
    7. It would be possible that VNFs are not compliant. For that, Connections between the DCAE and VNF through the SOL003 Adapter need to be enhanced. We may need another component which can translate SOL002/SOL003 APIs to VES event. Will discuss it further.
  2. No meeting next Monday due to US and India holidays

OrchestrationScenariosAug26.mp4

September 9, 2019
  1. Verizon presented the SOL005 Adapter architecture and use cases
    1. SOL005 Adapter architecture refactoring was discussed (decouple it from the current SO VFC adapter architecturally)
    2. NS Package handling was discussed.
      1. Support of SOL007 (NS package) was discussed.
      2. Thinh suggested to use SOL007 for NS Package, and SDC PTL will be contacted for SDC SOL007 support in Frankfurt
  2. Samsung presented the SOL002 Adapter use cases
  3. Next week, the team will discuss HPA, HPA-based Granting, VNF-Level Homing, CMCC ONAP-ETSI Catalog Management

OrchestrationScenariosSept9.mp4

September 16, 2019
  1. SOL007 is proposed for NS packages.
    1. SDC needs to be enhanced to handle SOL007 package onboarding and distribution
    2. it would be similar to SOL004 package onboarding and distribution
    3. Some impacts on SO and VFC are discussed
    4. Editing vendor NSDs at SDC was raised. Do we allow this editing and how to distribute the enhanced vendor NSDs?
  2. SOL004 is used for VNF and PNF packages.
    1. SDC already supports SOL004 package onboarding and distribution
    2. Editing vendor VNFD/PNFD at SDC was raised. Do we allow this editing and how to distribute the enhanced vendor VNFDs/PNFDs?
  3. Package Security was discussed
    1. ONAP will handle vendor package security (signature and certificate); SDC does not generate its own signature and certificate for SDC AID DM
    2. This issue will be discussed separately in a future meeting
  4. ONAP-ETSI Catalog Manager use cases and design were presented
    1. SO will invoke the Catalog Manager APIs to initiate NS, VNF and PNF packages by sending the csar id.
    2. The Catalog Manager will get the package files from SDC
    3. The Catalog Manager provides package management APIs for the SOL003/SOL005 Adapters
  5. Samsung presented SOL002 Adapter use cases
  6. HPA and Granting
    1. To centralize HPA, all the granting and allocation decisions should go through OOF
    2. Currently, OOF supports service-level homing request APIs, 
    3. For bottom-up VNF requests (e.g., close loop, scaling/healing requests that are initiated by VNF), the vnf-level homing request APIs should be supported since those requests do not have service association. 
    4. OOF internal graph might need to be enhanced to support reverse search from the VNF.
    5. Use cases were presented to the OOF team, and we will discuss more off-line

OrchestrationScenariosSept16.mp4

  • No labels

25 Comments

  1. Manoj Nair

    Is the scope also includes Network Services provided using multiple administrative domains? (ETSI IFA 028 Section 6) : two constituent nested NSs which build up the composite NS are offered by administrative domains different than the one offering the composite NS itself. A new Or-Or reference point is expected to enable this (between two NFVOs). Is it right to assume that Or-Or is realized at the VFC level ? Few additional requirements captured in Section 6.3 (IFA 028) 

    • Enhancements for the maintenance of the session between NFVOs in different administrative domains are required
    • The NFVO need to play the role of MANO Monitor as described in ETSI GR NFV-IFA 021
    • For the logical interconnection of domains, discovery mechanisms (as presented in ETSI GR NFV-IFA 021) can be required for auto-discovery of NFVOs of the different administrative domains.
    • Support for SLPOC (Single Logical Point of Contact) and MLPOC (Multiple Logical Point of Contact) at NFVO level (Section 5.2.1) for supporting NFVIaaS scenarios. 

    1. Fernando Oliveira

      Manoj,

      I would expect that yes the scope would include NS provided by multiple administrative domains but I hadn't considered using the Or-Or interface.  I expect that ONAP should be able to interface with multiple NFVO using the Os-Ma-nfvo (SOL005) interface.  I would expect to treat VF-C as one of those NFVO and perhaps have the rest of ONAP interface with VF-C over the Os-Ma-nfvo interface.

  2. Ranny Haiby

    Thanks for walking us through the "VZDeploymentOptionLegacy.pptx" presentation. I think it would be useful to add a "motivation" section to each scenario, stating what is the desired goals of using ONAP. Having the goals in front of us while discussing the scenarios will help focus and ensure the deliverd solution addresses the needs.

    Based on what I heard so far, here is what my understanding is:

    Scenario #1: The goal is to design and deploy a composite service, consisting of multi vendor VNFs, in an automated and repeatable way.

    Scenario #2: Have ONAP perform resource orchestration for a scale out use case, handling things like optimal palcement, resource reservation and resource request granting based on well defined policies.

    Scenario #3:  Here I am not sure what the desired goal is. Is it performing orchestration using existing orchestration tiers? I am not sure I understand the motivation for this. Would appreciate some more details.

    1. Fernando Oliveira

      Hi Ranny,  I agree that it would be good to have well defined goals for each of the scenarios.  Some clarifications below.

      Scenario #1: Design and deploy a composite service consisting of multiple vendor VNFs in an automated and repeatable way leveraging vendor provided SOL003 compliant VNF Manager(s) and out of band application configuration.  (Legacy approach)

      Scenario #2: Leverage ONAP policy platform and resource orchestration for a scale out use case leveraging vendor provided SOL003 compliant VNF Manager(s), handling things like optimal placement, resource reservation and resource request granting based on well defined policies.

      Scenario #3: Leverage ONAP VNF onboarding and Service Design capabilities to develop a composite service that can be instantiated and managed by an existing SOL005 compliant orchestrator. (ONAP acting as an OSS)

  3. Srinivasa Addepalli

    Hi Fred,

    It would be fantastic if configuration orchestration scenarios and possible solutions are also discussed in this task force.

    Srini


    1. Fernando Oliveira

      Hi Srini,

      Yes, application configuration scenarios are on my list.  We are using a non standard method today but we have a couple of proposals that we have been pushing with ETSI that I think would be applicable. I will prepare such a scenario description for Dec 10 meeting.

      Another topic on my list is how to incorporate Events, KPI and Policy suggestions into the VNF Descriptor and the NS Descriptor.  The VES model seems to support a lot of what I need but it is OOB and not supported by many of our VNFs.  This is needed to support some of the  5G NF especially with delegation of some of the policy HELM/K8S.

      Regards,

      Fred

  4. Viswanath Kumar Skand Priya

    Hi Fernando Oliveira / All,

    I'm referring to Implications/Requirements section in my following query.

    Isn't 1b, 1c & 1f already happening in ONAP today ? Why does it have to be different for external VNFM scenarios via SOL 003?

    • More specifically, do you expect that AAI should treat the VNFs hosted by S-VNFM & SO ( heat ) differently? If so, why is that? If not, then why do we state this point explicitly here?

    On 2d

    • When you term ONAP should have SOL 005 SBI, I believe you are referring to SO should have SOL 005 SBI - Pls confirm

    On 2e & 2f

    • Same question as of 1f . Why do you think ONAP should distinguish between service managed by internal NFV-O and external NFV-O, given that SO will act as anchor point of SOL 005 and all the service instantiations originating from SO will have an entry in AAI automatically?
    • More specifically - the whole idea of API based interaction is pure plug & play and the introduction of standards will further enhance transparency in datamodels. So if the interface between SO and VF-C ( internal NFV-O for example ) is SOL 005 and if the interface between SO and external NFV-O ( OSM for example ) is still SOL 005, why does ONAP has to care to distinguish between these two ? Isn't it sufficient for ONAP to know that there is a service that is getting orchestrated via SO ?

    1. Fernando Oliveira

      HI Viswa,

      • 1b: Yes, I think that ingestion is already being happening but not sure if the VNF-D is preserved such that it can be provided to the VNFM.
      • 1c: From what I understand ONAP isn't actually tracking the availability of cloud resources to the level that ETSI expects in response to a "Grant" request. OOF and A&AI may need to be enhanced in order maintain this inventory or query the VIM in real-time to get the information.
      • 1f: I think that there may need to be additional info saved such that the VNFM instance that was used to deploy the VNF will be used for subsequent LCM operations.  I expect that this will be different than what is being saved for VNFs launched directly by SO using Heat
      • 2d: In this context, I am treating ONAP as a black box, but yes, I expect that SO would leverage an SOL005 SBI adapter to interface with an external (and perhaps an internal)  NFVO.  I think that it would be a good idea if the interface to VF-C was the same as the interface to an external NFVO.
      • 2e:  I think that ONAP needs an indicator that distinguishes a Service that is managed directly by SO and a Service that is delegated to an internal or external NFVO.  I expect that service delegated to an internal or external NFVO will be treated differently than a service that is handled directly by SO.
      • 2f: Same reasoning as 1f; The same NFVO needs to be used for subsequent LCM on the delegated service so information needs to be maintained about which NFVO was used.

    2. Ranny Haiby

      Another way to understand 2e and 2f is to separate current reality from future goals. Indeed, it is best if in the future, ONAP will be able to orchestrate any service through any combination of NFVO and VNFM, external or internal. In current reality, certain VNFs have some extensions in their VNFD that can only be handled by a certain VNFM, and some services are designed to leverage specific functionality of an NFVO (internal or external). ONAP has to have a way to specify which NFVO and VNFM should be used. In the future, ONAP may include mechanisms to identify the needs of VNFs and services and determine automatically the optimal orchestration. However this does not sound feasible for the short term.

  5. Viswanath Kumar Skand Priya

    Thank you Ranny Haiby & Fernando Oliveira . I agree partly, but I still have following queries.

    • I agree & acknowledge that atleast for a foreseeable future, we would need a way to specify the VNFM / NFVO as part of "Design Decision", which I believe can be reflected as part of VNFD/NSD ( using some special attribute ) or as part of internal Model that SDC might build before distributing the same. SO can then use this hint to select relevant actors. My only question is, why this has to be maintained in AAI which is exclusively for runtime record? All AAI cares about is what is running in the network irrespective of how that got orchestrated. Isn't it ?

    On a broader note, I would like to understand what's the original intent of AAI ( atleast in ECOMP world ) ? Are we simply assuming that, just because AAI has "available inventory" in its name, we are expecting it to keep track of cloud inventory realtime ? Because our entire story ( including the new G-FPS proposal ) is based on this assumption. Can anyone from AAI team or ATT clarify on this ?

    Because AFAIK, AAI neither has the schema to host such available inventory, nor the MC has the pub/sub or polling mechanism ( today ) to refresh the cloud inventory inplace. Ofcourse those can be scoped for further releases, but my original question is, was that the original intent behind AAI or are we now including it in the scope?

  6. Fernando Oliveira

    For the first question: I think that A&AI needs to maintain the VNF instance ↔ VNFM instance and the NS instance ↔ NFVO instance relationship for subsequent life cycle operations, i.e. a scale or heal operation.  The path would be something like Event (VNF Instance, Busy)  → DCAE (policy for VNF instance) → Policy Evaluation (VNF instance, Scale-out)  → SO (VNF instance, Scale-out) → A&AI (find VNFM instance for the VNF instance) → SO (VNF instance, VNFM instance, Scale-out) → SOL003 Adapter (VNFM instance, VNF instance, Scale-out) → VNFM instance (VNF Instance, Scale-out).

    I don't have the background to comment on the other questions.

    1. Viswanath Kumar Skand Priya

      I can see what you telling here. Basically you are looking for something like a NetworkServiceRecord ( NSR ) ( trying to apply my openbaton learnings ) and you want one of the property to hold the corresponding nfvo / vnfm information.

      Quoting from OpenBaton source, NSR has following attributes :

      {
	Set<AutoScalePolicy>,
	Set<ConnectionPoint>,
	Set<monitoring_parameter>,
	NetworkServiceDeploymentFlavour,
	vendor,
	task,
	version,
	Set<VirtualLinkRecord>,
	Set<VirtualNetworkFunctionRecord>,
	Set<VNFRecordDependency>, // This could refer to S-VNFM & NFV-O Dependency
	Set<LifecycleEvent>,
	Set<VNFForwardingGraphRecord>,
	Set<PhysicalNetworkFunctionRecord>,
	Set<FaultManagementPolicy>,
	Set<LifecycleEvent>,
	Status,
	audit_log
   :
}

      I hope we have similar model somewhere either in SO ( as object ) or in AAI . Could anyone please point me in right direction ?

    2. Keong Lim

      As mentioned under "Orchestration Scenarios for VNFs" in 2018-12-13 AAI Developers Meeting :

      As I understand, ESR has "esr-vnfm-list", which has an "esr-vnfm", which has "esr-system-info-list", which has "esr-system-info", which has a "relationship-list" that can contain relationships to "generic-vnf" and other AAI objects.

      The "generic-vnf" object also contains "self-link", "ipv4OamAddress", "ipv4OamGatewayAddress", etc, which links the AAI object back to its "source-of-truth" external-system.

      Is there some new data, new schema or new API that is required on top of this?

      1. Fernando Oliveira

        Apologies for my lack of knowledge, but a few comments:

        1. For the VNF/VF ↔ VNFM case, I think that there needs to be a reference from a VNF/VF instance record to the specific instance of the VNFM that was used to deploy the VNF/VF. If there is already such a reference from the VNF/VF through the ESR to the specific item on the esr-vnfm-list, then I think that would be sufficient. If not, I think that would be a new requirement.
        2. For the Service ↔ NFVO case, Is there an equivalent NFVO/Orchestrator list in the ESR? The esr-nfvo-list would need the same set of info as the VNFM case. If the esr-nfvo-list does exist, I think that there needs to be a reference from the Service Instance record to the specific NFVO instance that deployed the Service. Is there such a reference? If not, I think that would be a new requirement.

        1. Keong Lim

          Bo Lv can comment more on the current ESR capabilities, but I believe there are only 3 kinds of systems so far: EMS, VNFM and third-party SDNC.

          ESR could be extended to handle VNFO as another kind of system.


          1. Bo Lv

            Keong Lim there are four kinds of resouces: ems, sdnc, vim and vnfm. If there is a new kind, this may be added to esr too.

        2. Bo Lv

          1. There is not a reference between vnf/vf and vnfm, esr just registed vnfm to AAI.
          2. Right now, esr does not support regist vnfo. So, there is also not a reference of service and NFVO.

          1. Keong Lim

            Fernando Oliveira please raise a JIRA story to describe this scenario for ESR.

            1. Fernando Oliveira

              I created JIRA stories:  ONAPARC-388 - Getting issue details... STATUS   ONAPARC-389 - Getting issue details... STATUS   ONAPARC-390 - Getting issue details... STATUS  for various parts of the scenario.

              1. Keong Lim

                Hi Fernando Oliveira ,

                Stephen Terrill may prefer to have an JIRA Epic to tie them all together as "Orchestration Scenarios". This will also allow JIRA Stories to be distributed to the various ONAP projects as needed.


  7. Fei Zhang

    Fernando Oliveira

    Just quick questions for SOL002 and SOL003 adaptor in ONAP. Could you help to clarify?

    In the proposal 'VNF Application Configuration over SOL003 ModifyVnfInfo interface using an External vendor specific VNF Manager',  SOL003 adaptor shall support configure/reconfigure VNF via ModifyVnfInfor.

    1. But on SOL003 Adapter, seems such operation is not scoped in Frankfurt, right?
    2. Also, 'VNF Application Configuration Over SOL003' is can be involved during different procedures like deployment, instantiate, run-time re-configuration, updating and so on, right? Or only in deployment and instantiate?


    BestRegards

    Fei

    1. Fernando Oliveira

      Fei Zhang

      1. Correct.  We were not able to commit enough resources to scope the the ModifyVnfInfo into Frankfurt.
      2. Also Correct.  VNF Application Configuration over SOL003" could be involved in many LCM procedures.  The GNF-C proposal (Merging of SDN-C & APP-C) would have added an interface to the  SOL003 Adapter that would be used for Application Configuration as well as VNF Life Cycle Notification (LCN) and VNF Events.  This proposal has also starved from a lack of resources.

      1. Fei Zhang

        Thanks, it is clear for the status now

  8. Thinh Nguyenphu

    Per Feb 3 call, I have an action point on follow-up on ETSI NFV SOL 002/003/005 v2.7.1 OpenAPI release schedule.  At the moment, the plan is March 31, 2020.

  9. Thinh Nguyenphu

    ETSI NFV IFA & SOL Working Group have prepared responses to list of question during ONAP-ETSI Alignment workshop, February 18, 2020. The Q & A is available at https://nfvwiki.etsi.org/index.php?title=ONAP-ETSI_Alignment_Workshop_-_18_February_2020