Commit ba9e5edd authored by Eisha Ayaz's avatar Eisha Ayaz Committed by Giacomo Bernini
Browse files

[datamodel-upd][SOL003][VNF-OP-GRANT][ v5.2.1][7.3.2.x.x Test-IDs] Change...

[datamodel-upd][SOL003][VNF-OP-GRANT][ v5.2.1][7.3.2.x.x Test-IDs] Change description and cardinality for attribute "extCps"  of type : ExtVirtualLinkData
parent f558e841
Loading
Loading
Loading
Loading
+2 −3
Original line number Diff line number Diff line
@@ -565,8 +565,7 @@
        "type": "object",
        "required": [
          "id",
          "resourceId",
          "extCps"
          "resourceId"
        ],
        "properties": {
          "id": {
@@ -586,7 +585,7 @@
            "type": "string"
          },
          "extCps": {
            "description": "External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity.\n",
            "description": "External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity. See note 3\n",
            "type": "array",
            "items": {
              "description": "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n            from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n            connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n            \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n            a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n            all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n            connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n            by a particular key value from the map, i.e. for the disconnection of an existing external\n            CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n            virtual link, and deletion of that instance in case it represents a subport. Deleting the\n            last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n            its parent data structure.\n* NOTE 4:   If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n            \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n            map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n            \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n            different than the one that has used it before the operation, or by no external CP instance at all.\n            Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n            \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5:   Subports need not be used for containerized VNFCs. The application container can send and receive IP \n            packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n            network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n            trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6:   In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n            containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n            required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n            cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n            document version.\n",