VSP Compliance Check within SDC (Dublin)

Table of Contents:

Abstract

This proposal is to add dynamic checks within SDC to (1) check compliance with deployment criteria, in order to reduce deployment failures; and (2) check for prior certifications, to eliminate unnecessary tests during onboarding.

Rationale

(1) Currently, metadata values passed by the VSP package can contain values that are not compliant with either general ONAP requirements or specific requirements of the CSP installed deployment environment. That can lead to VNF deployment failure. Reducing the risk of such failure can be achieved by checking the metadata passed by the VSP against criteria in VTP or third-party repositories. Examples of metadata passed by the VSP to be checked for compliance against a specific deployment environment are:

• Compute flavor check as to whether it is supported by underlying NFV Infrastructure.
• SR-IOV PCIe Pass through to a specific Network Interface Card as to whether that is available in the underlying NFV Infrastructure.

This proposal will add dynamic checks within SDC against a registry that contains deployment criteria. Both standard static criteria and specific deployment environment criteria will be configurable.

(2) Industry standard certification program repositories such as the OVP portal or third-party repositories can be checked in order to minimize or even remove the need for local testing.

This proposal will add dynamic checks within SDC against a registry that contains prior certifications.

Other Options Considered

It has been considered that these compliant checks can be carried out offline but this will be restrictive in the following way:

• It is a big overhead to carry out those checks offline especially as VID deployments might vary from one instance of ONAP to another and hence the compliance criteria will change.
• Integrating it into SDC will allow queries to VTP, as well as to third-party repositories, to perform deployment environment checks.
• Integrating it into SDC will allow queries to industry standard certification program repositories such as the OVP portal, as well as to third-party repositories, to perform certification checks.
• Integrating it into SDC will allow for better integration with CI/CD tools and automate the checks, especially when rolling out VNF updates.

Code Structure

ONAP code can be found in: https://git.onap.org/

Will follow soon.

Proposal

From a high-level perspective, the proposal will allow VSP, when uploaded into SDC, to go through a set of checks to make sure it is (1) compliant to the deployment environment and (2) fetch prior certifications. The checks can be done during the VSP validation stage by implementing plug-ins to SDC and introducing a "registry" to be consulted. Figure 1 shows the proposal in a high-level view. 

Figure 1: High-Level proposal.

The validation block sends all passed metadata to the registry and gets the result of checks back. The result of the compliance checks will determine if the VSP needs to be rejected or to be submitted to testing. Figure 2 shows a query to a registry. 

Figure 2: ONAP Component interaction with the proposed registry.

As outlined in the Rationale section above, integrating these checks into SDC will allow queries to VTP and the OVP portal as well as to third-party repositories, so the APIs will be designed to interoperate SDC with that range of end-points. In order to meet the Dublin release schedule for the development of  plug-ins and APIs, a registry is planned to be implemented as a discrete hosted component outside ONAP. Integration to VTP and OVP portal can be performed when those environments are ready. Figure 3 shows the associated overarching LFN CVP vision and Figure 4 shows the vision of checks to VTP and OVP portal.      

      Figure 3: Overarching LFN CVP vision.                                                                                                                         Figure 4: Vision of checks to VTP and to OVP portal.     

Metadata Tags

We need an agreed list of metadata tags plus a list of the values those tags can take in order to effect compliance checks.

Metadata tags should include necessary ETSI NFV SOL1 data items in the VNFD – if ETSI says some of these are optional and we think they should be mandatory then we should identify them.

References

Links to any additional resources referenced in or related to this proposal.