Driver Fred.

2019-10-08.

Byuong presented the frankfurt requirements for ETSI ONAP alignment in the following presentation: https://wiki.onap.org/download/attachments/50202249/ETSI-Alignment%20Task%20Force%20Update-2019-10-08.pptx?api=v2

This proposed support in the VNFM SOL003 (fromSO) evolution and NFVO SOL005 support scenarios.  Ald that the EM can trigger via a SOL002 adapter.

There is a discussion about having the ONAP ETSI catalogue manager as a common component, however that is not a proposal at the moment.   It will be part of SO, or a common service (FFS).

The hetrogenious service is possible, but not for frankfurt.  It can be done one-by-one approach.  There is no use case.  Its there in the structure but not in the execution.

A few open issues:

• should SDC allow o enright the NSD and VNFD
• authentication - AAF/ external servier
• OFF enahncements for VNF-level request
• sclaing for VNF vs VF-module

Even with the open issues, the was considered as very good work and architecture approved

 

 

 

2019-08-13 ArchCom.

Fred Presented:...https://wiki.onap.org/download/attachments/50202249/OrchestrationScenariosUpdate.pptx?api=v2

• Some work has been done in Casablanca and Dublin.  Further work for Frankfurt expected.
• SOL00(1,2,3,4,5)
• ETSI aligned application configuration (languishing)
• GNF-C: Unified SDN-C, APP-C, with CDS model based processing (languishing).
  • The touch point is the LCM capabilities, and the proposal to use the SOL3, SOL2 to provide some of the configuration.

Going forward.

• Focus on ETSI alignment support effort.
• seek support for continue on ETSI aligned application configuratino
• seek support for continuing on GNF-C work.

There is a suggestion to re-define the task force to ETSI-Alignment, there seemed to be support for this.

There was a question about the API fabric due to the SOL interfaces being disucssed, need to ensure that there is not overlap.

 

Note: Freds meeting will move 1 hour earlier (8am EST, Monday)

 

2019-04-02 ArchCom F2F part 2:   Fred presented: https://wiki.onap.org/download/attachments/53248195/ApplicationConfigElAlto.pdf?version=2&modificationDate=1554239478418&api=v2

Proposes that:

• VNF package contains information about the parameters that can be configured
• Have SOL003 Modify VNF come from the SDNC/APPC to configure VNFs as an option

 

There were questions related to the relationship to CDS.  The response is the valid consideration.

Proposing to do a PoC in Release E

There was a question about whether this was the full SOL003 or only the Modify_VNF_Info, but was hinting to open up to more for other LCM events

 

Propose to continue in the Orchestration scenarios.

 

 

2019-04-02 ArchCom F2F

Three speaksers; Eric, Lignli, Fred.

Eric: :

• There are 4 orchestration paths.
• Promotes that there should be indepeance between the design time and the orchestration choices in the run-time.
  • A single VNFD for differentn paths
  • No hard value of hard-coded value in VNFD (VNF requirement)
  • Service definition
    • all execution paths options should only be valued during the run-time and no more in design-time.  SDC/SO impact?
  • Artifact/Catallg distributin to 3rd party VNFM/NFVA - > UUI/SO?
• There was comments that pushing the VNFM address to design time.  The reply was that ok, but to avoid it as onboarding time, maybe additional capability at design time.

Lingli:

• - walked through the orchestration scenarios for VNF LCM (5 examples of what is ongoing or done)
• There was some clarifications on the scenarios for application configuration.
• There were also FM/PM options.
• Proposed some focus for 5G for the next release
  • CNF provisioning support
  • Nested service provissining support
  • VFN/CNF configuration support
  • Service configuration support
  • Unifired Package Management suppor

Fred:

-  Walked through some examples.

• Also he commented the state of what has been done and what is expected to be done.
• Catherine indicated to get feedback on the proposals from the PTLs about the status.  The challenge was that there are lots of options, can we generalize.

Next Steps.

• Allow 2-3 weeks to capture more input and consolidate and bring back to AchCom.  Also include the JIRAs in the Rel El Alto reqs work

 

 

 

 

 

In the architecture F2F, in order to move forweard with the internal modelling, it was decided that we needed to quickly describe the orchestration scenarios that we see.

2019-01-15

Fred walked through: https://wiki.onap.org/display/DW/Orchestration+Scenarios 

Fred expect most of these requirements for post dublin.  The following were discussed.

1a. ONAP needs to ingest and save (without modification) a SOL004 CSAR package for later consumption by a SOL003 compliant VNF Manager (VNFSDK, SDC)

1b. ONAP needs to ingest and interpret a SOL001 compliant VNF descriptor inr oder to desang and ONAP service (VNFSDK, SDC).

• Clarification, it can be extended internally

1c 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)

• There was a question is the confirm the VIM resources is done at onboarding time or instantiation time.  Fred was indicating the thinking was at instantiation time.  There was a question about what to validate at onboarding.

 1d. ONAP needs to have a SOL003 compliant SBI (SOL003 Adapter, APP-C, VF-C, GNF-C, SO))

• Fred clarified he doesn't state which component should have the SB interface.  We need to describe the options and recomendations.

1e 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)

• It was pointed out that this is not a VNFM specific solution, a there is also simular problems with finding the right controller for other equipment.

1f 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)

Summary of 1.  There was general acceptance for the requirements and some requests for clarification.  There is still more work to do on some of the solution parts.

 

 

2. External NFVO scenarios (ONAP acting as an OSS or hierarchical Service Orchestrator):

2a ONAP needs to ingest and save (without modification) a SOL004 CSAR package for later consumption by a SOL005 compliant NFVO (VNFSDK, SDC)

• Same as 1a
• It was commented that the instance of the VNFM for scenario 1 could be the same as is used in scenario 2; but it is not expected for the same service type

2b ONAP needs to ingest and interpret a SOL001 compliant VNF Descriptor in order to design an ONAP Service (VNFSDK, SDC)

 

2c 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
2. VF-C "internal SOL005" interface
3. ONAP Service NBI
4. Open Source Mano (OSM) NBI

• Comment: there is still work to do on the configuration part.
• Comment: There was a request for clarity about the difference between if the "child" ONAP is in the same operator or a different operator.
• To generalize, reword to indicate an external service interface.

 

2d ONAP needs to be able to convert an ONAP Service into a SOL001 compliant Network Service Descriptor (SOL005 Adapter)

• comment: subsetof 2ci
• comment: instead of converting, maybe its about "generating". Further discussion required depending on the discussion about the internal representation of the NSD.

2e ONAP needs a mechanism for specifying that a service should be runtime managed by an external NFVO (SDC, SO, A&AI)

2f 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)

2g ONAP neeeds a way to ingest and save (without modification) a SOL007 Network Service Package) (VNFSDK, SDC)

• comment:  It was mentioned that this would be a future requirement.  It was motivated due to the scanario where a packet core or a subset of packet core comes packaged together and represented by the SOL007 NSD.

2h ONAP needs to ingest and interpret a SOL001 compliant Network Service Descriptor (SDC, SO)

1. Possibly translating it into an ONAP Service

2i 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)

Conclusion: there seems to be large acceptance in general, though it is noted that there is still further discussion to clarify some aspects of the requirements.

 

2018-12-04

Fred presented around the wiki page .

• There has been a few metings.
• Consider a late US /Early china meeting time in addition
• The focus has been on ONAP calling a VNFM and starting to describe the case of ONAP calling a NFVO.
• Invitng more operator support
• Fred has in mind a application configuration proposal into VNFD in ETSI.
• Any requirements on modellig etc to take through modelling sub-committee
• There was a question regarding the use of SDC, and the response was yest that is considered to be used.

2018-11-13 ARC:

------------------

Fred presented around the wiki page .

• Will hold a re-occuring meeting.
• some clarity forming on the scenarios

---

2018-11-06 ARC

-----------------

 Fred introduced some deplloyment scenarios.

There were also lots of questions about the service assurance; and also the the relation to networking, though these were out of scope.

There was a request to split slide 5 into different slides focus on slides