Update vnfLcmOpOcc and vnfLcmOpOccs json schemas

                  "resourceId"

                ],

                "type": "object",

                "description": "This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the\n          VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource \n          provider and can be used as information that complements the ResourceHandle. When the container\n          infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n          correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n          PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the \n          following way:\n          - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n          per resource type.\n          - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n          i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n          Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n          manifest.\n          - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n          the 'metadata.name' field in Kubernetes® manifest.\n",

                "description": "This type represents the information that allows addressing a virtualised resource or Network MCIO that is used by a VNF instance. Information about the resource is available from the VIM or the CISM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the\n          VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource \n          provider and can be used as information that complements the ResourceHandle. When the container\n          infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n          correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n          PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the \n          following way:\n          - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n          per resource type.\n          - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n          i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n          Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n          manifest.\n          - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n          the 'metadata.name' field in Kubernetes® manifest.\n",

                "properties": {

                  "vimConnectionId": {

                    "description": "An identifier with the intention of being globally unique.\n",

                  "resourceId"

                ],

                "type": "object",

                "description": "This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the\n          VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource \n          provider and can be used as information that complements the ResourceHandle. When the container\n          infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n          correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n          PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the \n          following way:\n          - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n          per resource type.\n          - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n          i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n          Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n          manifest.\n          - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n          the 'metadata.name' field in Kubernetes® manifest.\n",

                "description": "This type represents the information that allows addressing a virtualised resource or Storage MCIO that is used by a VNF instance. Information about the resource is available from the VIM or the CISM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the\n          VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource \n          provider and can be used as information that complements the ResourceHandle. When the container\n          infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n          correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n          PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the \n          following way:\n          - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n          per resource type.\n          - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n          i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n          Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n          manifest.\n          - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n          the 'metadata.name' field in Kubernetes® manifest.\n",

                "properties": {

                  "vimConnectionId": {

                    "description": "An identifier with the intention of being globally unique.\n",

                  "description": "Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3 and 4.\n",

                  "type": "object",

                  "additionalProperties": {

                    "description": "This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP:\n  1.  In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n      external VL.\n  2.  In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n      to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP\n          instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n          1) Void.\n          2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n          representing a subport that is to be created, or an external CP instance that is to be created by creating the\n          corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n          external CP instance that is to be re-configured or added to a particular external virtual link.\n          3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n          4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n          precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n          pre-configured address information for the connection point from the resource representing the link port.\n          5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n          cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes ΓÇ£netAttDefResourceIdΓÇ¥ and ΓÇ£cpProtocolDataΓÇ¥ for an external CP\n          instance connected or to be connected to a secondary container cluster network:\n          1) The \"netAttDefResourceId\" and \"cpProtocolData\" attributes shall both be absent for the deletion of an\n          existing external CP instance addressed by cpInstanceId.\n          2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n          a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n          definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n          redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n          to the same namespace as defined by the corresponding \"netAttDefResourceNamespace\" attribute in the\n          \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n",

                    "description": "This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP:\n  1.  In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n      external VL.\n  2.  In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n      to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP\n          instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n          1) Void.\n          2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n          representing a subport that is to be created, or an external CP instance that is to be created by creating the\n          corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n          external CP instance that is to be re-configured or added to a particular external virtual link.\n          3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n          4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n          precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n          pre-configured address information for the connection point from the resource representing the link port.\n          5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n          cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes ΓÇ£netAttDefResourceIdΓÇ¥ and ΓÇ£cpProtocolDataΓÇ¥ for an external CP\n          instance connected or to be connected to a secondary container cluster network:\n          1) Void.\n          2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n          a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n          definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n          redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n          to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the\n          \"resourceHandle\" attribute in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n",

                    "anyOf": [

                      {

                        "required": [

                              }

                            },

                            "virtualCpAddress": {

                              "description": "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an  NS VL.\n* NOTE 1: If the container cluster is set up to be able to configure an external load balancer this address will be used,\n          otherwise it will be ignored by the CISM.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container\n          cluster will assign an IP address.\n",

                              "description": "This type represents network address data for a virtual CP.\n* NOTE 1: If the container cluster is set up to be able to configure an external load balancer this address will be used,\n          otherwise it will be ignored by the CISM.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container\n          cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp and the addressPoolName attributes shall not be present at the same time.\n",

                              "type": "object",

                              "required": [

                                "type"

                                  "description": "An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n",

                                  "type": "string",

                                  "format": "IP"

                                },

                                "addressPoolName": {

                                  "description": "Name of an address pool from which an IP address is assigned to the virtual CP.\n",

                                  "type": "string"

                                }

                              }

                            }