Overview

ONAP Policy will support CDS as an actor so that the controlloop usecases can make use of it to take any type of action by executing the CBA. We would like to use the vFW usecase to demonstrate the integration between Policy and CDS.

Problem statement

Current implementation using APPC ModifyConfig

Today, Policy allows the Control Loop Designer to specify the payload for APPC API calls through CLAMP. Policy copies the entire payload of the operation that APPC has to execute against the VNF during closed loop into the APPC LCM request.

Define ModifyConfig action in CDS for Post-Instantiation

Create CDS package (CBA: controller blueprint archive) that defines this ModifyConfig action. The inputs that we envision are service-instance-id, generic-vnf-id (so that CDS is able to resolve the IP address of the vPKG at VNF level for the vFW usecase), payload (from CLAMP). The authentication will be defined as a DSL in the CBA.
Since, the latest vPKG support RESTCONF interface, the package designer will define the ModifyConfig action in a data-dictionary by leveraging the source-rest endpoint and providing payload (JSON restconf payload) along with a mapping file defining what values to resolve.

Note:

1. Optionally, one could also use NETCONF instead of RESTCONF to push the payload to the device. An example of deploying configuration to a NETCONF server using CDS can be found here: https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/blueprint-model/test-blueprint/golden/Scripts/python/ConfigDeploy.py
2. Access CDS recording to help build the CBA at: Presentation#ONSNA2019

Resolving VNF configuration using CDS

ModifyConfig action including the parameters and their resolution will be defined in CDS as described above. We will implement CDS API model implementation and actor implementation in policy so that we can either directly invoke CDS to push the payload to the vPacketGen VNF using RESTCONF/NETCONF (as defined in the CBA) or invoke APPC to execute ModifyConfig against the traffic generator VNF.

For example, as described above: a user can define ModifyConfig parameters in CDS using DD and specify the parameter resolution. During closed loop, Policy will just tell CDS to execute ModifyConfig action against a specific VNF. CDS will then look at the VNF template (built with CDS) to retrieve the ModifyConfig parameters and use DD for their resolution. If DD will not be available, then ModifyConfig parameters could be defined in CLAMP and pushed to Policy during closed loop creation. Policy will then pass these parameters to build the payload and push it to the target during closed loop execution either using RESTCONF/NETCONF as defined in the CBA.

Migration to APPC LCM API (Future)

Mark to deprecate the old API for ModifyConfig and leverage CDS GRPC enabled Self Service API to enable LCM actions such as configModify and other lcm action for xNF.

Participating Companies

Bell, AT&T, Ericsson, Huawei 

Artifacts

vLB CSAR Service with CDS Package

vFW CSAR Service with CDS Package

vFW Clamp and CDS integration use case.pptx

CBA: vFW_CDS_CBA.zip

Data dictionary: dd UPDATES IN cds ui with processor-db.json

Payload to CDS from Policy (rest), gRPC will entail same parameters

Another possibility to make the payload to be JSON format:

 {
   "commonHeader": {
     "originatorId": "Policy",
     "requestId": "1234", # From the Onset event
     "subRequestId": "5678" # From the ControlLoopOperation object
   },
   "actionIdentifiers": {
     "blueprintName": "test", # Embedded into operational policy YAML payload
     "blueprintVersion": "1.0.0", # Embedded into operational policy YAML payload
     "actionName": "config-deploy", # Embedded into operational policy YAML payload
     "mode": "async"
   },
   "payload": {
     "config-deploy-request": { # Key generation pattern: $actionName-request
       "resolution-key" : "UUID,
       "aai-properties":{
          "$aai.params": "$aai.params" # Enriched AAI attributes in node.attribute format
          .....
        },
       "configpolicy-deploy-propertiespayload": { # FReeFree form JSON from CLAMP embedded into operational policy YAML payload.
         "$data": {
           "mapInfo": {
             "key": "val"
           },
           "arrayInfo": [
             "one",
             "two"
           ],
           "paramInfo": "val"
         }
       }
     }
   }
 }

Sample matching operational policy YAML (El-Alto): To be aligned with changes per Control Loop Policy Type Design Proposal #1: Simple upgrade of legacy policy types to TOSCA and TOSCA Compliant Policy Types)

tosca_definitions_version: tosca_simple_yaml_1_0_0
topology_template:
  policies:
    -
      operational.modifyconfig:
        type: onap.policies.controlloop.Operational
        version: 1.0.0
        metadata:
          policy-id: operational.modifyconfig
        properties:
          controlLoop:
            version: 2.0.0
            controlLoopName: ControlLoop-vFirewall-__ResourceID__
            trigger_policy: unique-policy-id-1-modifyConfig
            timeout: 1200
            abatement: false
          policies:
            - id: unique-policy-id-1-modifyConfig
              name: modify_packet_gen_config
              description:
              actor: CDS # Choice of CDS as the actor
              recipe: config-deploy # Blueprint action-name
              target:
                resourceID: __ResourceID__
                type: VNF
              payload:
                artifact_name: vfw-cds # Blueprint name
                artifact_version: 1.0.0 # Blueprint version
                mode: async # Blueprint mode type
                data: '{"mapInfo":{"key":"val"},"arrayInfo":["one","two"],"paramInfo":"val"}' # Free-form json supplied by CLAMP
              retry: 0
              timeout: 300
              success: final_success
              failure: final_failure
              failure_timeout: final_failure_timeout
              failure_retries: final_failure_retries
              failure_exception: final_failure_exception
              failure_guard: final_failure_guard

TBD: To be tracked as a separate functional requirement

CLAMP rendering possible actions supported by CDS + rendering of the input fields from CBA. Below options available from CDS (Yuriy to add more details)
- Open API generated from the protobuf.
- Ingest the TOSCA yaml from CDS

Follow-up from Controlloop subcommittee item "Discussion on the type of spec CDS needs to create for CLAMP to use: OPEN-API or grpc specification": 2019-09-04 Control Loop Sub Committee Weekly Meeting

1. @Yuriy to add the CBA CSAR to the wiki: DONE
2. CDS team @Yuriy to think of the notion of classification in CDS to identify the level at which the action/resolution must be acted upon. We do have this representation in Policy.
3. What is the standard way to to expose actor capabilities via CLAM? @Martial to get back with feedback for @Yuriy about the preferred way of their choice of spec to ingest the CDS models: Open-API/gRPC. Investigate expressing the model in TOSCA (SDC CSAR).

Goals

1. To bring in integration of CDS into policy as another actor and demonstrate this integration using the vFirewall end-to-end closeloop usecase (design-time + runtime: instantiation and closeloop)