VSP Compliance Check within SDC (Dublin)

Table of Contents:

Abstract

Currently, metadata values passed by the VSP package can contain values that are either not compliant with ONAP standards or not compatible with the installed VID environment that can lead to deployment failures. This proposal proposes to add dynamic checks within SDC to be able to check passed metadata values against a registry that contains the check criteria. the content of the registry can be pre-loaded with standard static criteria, but also can be configured to add custom checks that are related to specific VID deployments.

Rationale

Reducing the risk of VNFs failing to be deployed in a given Virtualization infrastructure deployment can be achieved by checking the metadata passed by the VSP against some defined criteria (both coming as part of a standard, and also configured for a specific environment).

Examples of metadata to be checked:

• Compute flavour that is not supported by underlying VID.
• The requirement for SR-IOV PCIe Pass through to a specific Network Interface Card that might not be available.

Other Options Considered

It has been considered that this 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.
• The potential of integrating it into SDC will allow us to connect to industry standard certification programs repositories such as OVP or third-party repositories to perform extra checks before onboarding which will minimize the local tests required (or even be skipped completely)
• Integrating it into SDC will allow for better integration with CI/CD tools and automate the compliance checks especially when rolling out VNFs 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 compliant to ONAP platform in general and to the deployed VID in specific. Figure 1 below shows the proposal in a high-level view. 

Figure 1: High-Level proposal.

The check itself can be done by intruding a compliance criteria "registry" will be consulted during the VSP validation stage. The validation block sends all passed metadata to the registry and gets the result of compliance 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: ONAP Component interaction with the proposed registry.

Metadata Tags list solution

Ideally, we need an agreed list of the metadata tags, certainly a mandatory set and secondly a list of the values those tags can take. Unless we get both then the whole system is problematic.

Mandatory tags should include the ETSI NFV SOL/IFA data items in the VNFD – if ETSI says some of these are optional and we think they should be mandatory then we should say so. Also the values those tags can take – again as much standardisation as we can get would be good.

Secondly, tags should (as the wiki indicates) provide pertinent details to enable the correct compute environment to be allocated again the tags and possible values should be specified.

I think a third set of tags should also be provided providing some indication of what the VNF is. E.g. if the VNF is part of the mobile network then it should be identified as one (or more) 3GPP functional entities (PDN-GW, UPF, etc., etc.) this would enable the operator to automatically identify what it does and enable the first pass automatic test of the functionality. (so vendor pushes a new MME version to the operator portal, automation sees the new update, identifies the VNF, we know what it is from the tag and what we (as an operator want it to do – we do not necessarily want to use all of the 3GPP functionality), we can then create the correct test environment (what traffic sources and destinations, signalling etc. do we use) and then run through an automated test script covering all the acceptance tests (all the required signalling messages, logging output, traffic etc.) and only if this all passes is the operator alerted that an updated VNF is ready for rollout. Any failure results in a report to the operator and also to the vendor. This process should be fully automated – no personal involvement once it is set up.

References

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