Page Comparison

the "input-parameters" attribute of "service-instance" object described as:

"String capturing request parameters from SO to pass to Closed Loop."

Closed loop scenario:

• SO will create “service-instance” object in AAI
• SO will store “customer-request” string on service-instance object in AAI
• When Closed Loop call recreates the “service-instance”, it will query “service-instance” information first, to get the “customer-request”

References

• reference id AAI-1353-2 in AAI-CCVPN Schema Proposal for Casablanca Release
• AAI discussion on 2018-11-28 ExtAPI Meeting notes

• the "flavor name" attribute of "flavor" object
• the "flavor id" attribute of "flavor" object

• /service-design-and-creation/models
• custom query

scenario:

• SDC distributes models into AAI
• Then VID calls custom query in AAI to get models by distribution status
• Finally VID uses models for its functions (this is the main flow for VID)

References

• https://lists.onap.org/g/onap-discuss/topic/openlab_vid_beijing_how/28275492

• /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}/availability-zones

Scenario:

• Multi-VIM / Cloud collects Availability-Zone capacity data from Clouds into AAI
• OOF retrieves Availability-Zone information of each Cloud Region from AAI
• OOF makes homing / placement decisions for VNFs to support "teaming" use case

References

• F-GPS (Dublin Summary)

• HPA

• "ssl-cacert" attribute on /esr-system-info-list/esr-system-info/{esr-system-info-id}

• vs "certificateUrl"

Question:

• is it just a URL to a certificate file?
• or is it the literal contents of a certificate file?

VID / SO / SDNC / OOF

MultiCloud

CLAMP / DCAE / DMaaP

VID / SO / SDNC / OOF

MultiCloud

CLAMP / DCAE / DMaaP

• /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}
• ‘cloud-region-id’ used in VID/SO/SDNC/OOF

• ‘cloud-owner’ + ’cloud-region-id’ used by AAI and its consumers

• ‘vim-id’ = {‘cloud-owner’}_{‘cloud-region-id’} used by MultiCloud and its consumers

• dcaeLocation used by CLAMP, DCAE and DMaaP

• Centralized Representation and Consistent Identification of Cloud Regions In ONAP
• Consistent ID of a Cloud Region (Dublin)

• SR-IOV NIC from VIM
• sriov-pfs (SR-IOV physical functions, with relation to p-interface)
• sriov-vfs (SR-IOV virtual functions, with relation to l-interface)
• sriov-automation in cloud-region

Scenario

• MultiCloud discovers SR-IOV NIC from VIM and registers it to AAI
• OOF gets cloud region ID, flavor id and physical nic alias from AAI
• OOF sends homing information to VF-C and SO

References

• HPA - SR-IOV NIC design

• Scaling Use Case (Dublin)
• Dummy Incremental VF_Module

Scenario:

• Policy has parameters and references values.
• User manually inserts Dummy Incremental VF_Module into AAI containing the values
• SO retrieves values from AAI
• What happens to the Dummy Incremental VF_Module afterwards?

References:

• https://lists.onap.org/g/onap-usecasesub/topic/scaling_scaling_automation/29434667

[Scaling] Scaling Automation Requirements
From: Scott Blandford
Date: Wed, 23 Jan 2019 16:52:31 UTC

Scaling Team,

Tech Mahindra is bringing some late requirements to the table for the Scaling Use Case.  Fortunately, they are also bringing the resources to accomplish the goals.

 

The goal is to automate some of the manual steps now required in the Scaling Use Case.  The trickiest of these items is to eliminate the need for a Dummy Incremental VF_Module that needs to be inserted into AAI in order to pass the correct references in the Policy to SO API.

• BBS Broadband Service Use Case (Dublin)
• Nomadic ONT scenario

Scenario:

• External PNF manager discovers ONT and enters details into AAI
• DCAE / CLAMP correlate the ONT details to an existing PNF object in AAI and "nomadic ONT scenario" is recognised
• SO effectively moves the PNF / services to the new location

References:

• https://groups.io/g/onap-bbs/topic/29523804