IP Addresses in AAI

Problem Statement:

How to support Healthcheck request using RESTCONF in the Scale Out Use Case. In order to support Healthcheck using RESTCONF protocol, the “host-ip-address”- (ipv4-oam-address) is required. This is the IP Address of the VM that is running the REST service. During the instantiation of the VNF ie. vDNS in the Scale Out Use Case, the IP address should be PUT in A&AI, so that it can be retrieved by any application later if needed. However, this step does not seem like it is occurring. There was a long term and short term (pretty hack) solution proposed to address the issue

Long Term (Dublin but it is possible if this exists already in ONAP that we could implement sooner in Casablanca):

1. SDC would need to add the attribute, ipv4-oam-address at the VNF level to the model and distribute with the TOSCA. Action Item: Need to verify with Michael Lando if the ipv4-oam-address for the VNF  is part of the model.
2. The model would need to identify which VF-module instance is the managing VF for the VMs and identify the name of the variable that would have the ip address
3. SDN-C would have to make changes to read this model data and associate the named variable to the ipv4-oam-address for this model Action Item: May need to change the UEB Listener to process the variable from the SDC Model
4. SDN-C would need to support updating the ipv4-oam-address in A&AI at the VNF level. Action Item: May need to add a step in the SDNC DG to update the ipv4-oam-address in A&AI at the VNF level
5. A&AI already has an ipv4-oam-address attribute at the VNF level in ECOMP and ONAP. Action Item: Harish will verify if this attribute is being used in ECOMP and which application is updating it
6. SO will query A&AI for the new parameter
7. SO will send the ipv4-oam-address in the Healthcheck payload to the Controller (APPC/SDNC)

Pretty Hack (Casablanca):

1. Modify HeatBridge to add a new argument for the “ipv4-oam-address-variable” that would be used to push the value from that heat parameter from the stack parameter into in the ipv4-oam-address field under the generic-vnf object in A&AI. In the case of Scale Out, the ipv4-oam-address is in the vfw_private_ip_2 variable of the vLB which is in the vFWSNK VNF (vFWSNK/base_vfw.yaml) .
2. [MP]: This is a fun mix of vFW and vLB use cases ? For the vLB, we need vlb_private_ip_1, which is in the base_vlb.yaml Heat template
3. SO would query A&AI for the new parameter.
4. SO will send the ipv4-oam-address in the Healthcheck payload to the Controller (APPC/SDNC)

As an aside and different request: we also discussed that for the ConfigScaleOut request, the config parameters will be part of the Preload. SO will send the config param as part of the ConfigScaleOut payload to the Controller (APPC/SDNC).

[MP]: The value of some ConfigScaleOut params can be resolved using SDNC preload, while other params may have a default/static value assigned, which won’t need to be resolved.