Merge "[VNFRQTS] updated allowed_address_pair req"

2 files changed, 347 insertions, 575 deletions

diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Contrail Resource Parameters.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Contrail Resource Parameters.rst
index a9929ce..36c4628 100644
--- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Contrail Resource Parameters.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Contrail Resource Parameters.rst
@@ -3,20 +3,20 @@
 .. Copyright 2017 AT&T Intellectual Property.  All rights reserved.
 
 Contrail Resource Parameters
-----------------------------------------------------------------------
+----------------------------
 
 ONAP requires the parameter names of certain Contrail Resources to
 follow specific naming conventions. This section provides these
 requirements.
 
 Contrail Network Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Contrail based resources may require references to a Contrail network
 using the network FQDN.
 
 External Networks
-~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~
 
 .. req::
     :id: R-02164
@@ -82,7 +82,7 @@ virtual_network_refs references a contrail network FQDN.
         - get_param: fw_sec_grp_id
 
 Interface Route Table Prefixes for Contrail InterfaceRoute Table
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. req::
     :id: R-28222
@@ -179,7 +179,7 @@ supports IP addresses in the format:
 
 
 Resource OS::ContrailV2::InstanceIp
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The Contrail resource ``OS::ContrailV2::InstanceIp`` has two properties
 that parameters **MUST** follow an explicit naming convention.  The
@@ -823,7 +823,7 @@ fw for firewall.
 
 
 Resource OS::ContrailV2::InstanceIp Property subnet_uuid
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A VNF's Heat Orchestration Templates resource ``OS::ContrailV2::InstanceIp``
 property ``subnet_uuid`` parameter
@@ -1122,17 +1122,23 @@ represent an oam protected network and the ``{vm-type}`` has been defined as
 OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-
 A VNF's Heat Orchestration Templates resource
 ``OS::ContrailV2::VirtualMachineInterface`` map property,
-``virtual_machine_interface_allowed_address_pairs,
-virtual_machine_interface_allowed_address_pairs_allowed_address_pair,
-virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,
-virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+
+``virtual_machine_interface_allowed_address_pairs``,
+
+``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
+
+``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
+
+``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+
 parameter **MUST** follow the same requirements that apply to the
 resource ``OS::Neutron::Port`` property
 ``allowed_address_pairs``, map property ``ip_address`` parameter.
 
+External Networks
+~~~~~~~~~~~~~~~~~
 
 .. req::
     :id: R-100280
@@ -1141,38 +1147,23 @@ resource ``OS::Neutron::Port`` property
     :target: VNF
     :introduced: dublin
 
-    If a VNF requires ONAP to assign a Virtual IP (VIP) Address to a
+    If a VNF's Heat Orchestration Template's resource
     ``OS::ContrailV2::VirtualMachineInterface``
-    connected an external network, the port
-    **MUST NOT** have more than one IPv4 VIP address.
-
-
-.. req::
-    :id: R-100290
-    :keyword: MUST NOT
-    :validation_mode: static
-    :target: VNF
-    :introduced: dublin
+    is attaching to an external network (per the
+    ONAP definition, see Requirement R-57424), the
+    map property
 
-    If a VNF requires ONAP to assign a Virtual IP (VIP) Address to a
-    ``OS::ContrailV2::VirtualMachineInterface``
-    connected an external network, the port
-    **MUST NOT** have more than one IPv6 VIP address.
+    ``virtual_machine_interface_allowed_address_pairs``,
 
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
 
-.. req::
-    :id: R-100300
-    :keyword: MUST
-    :validation_mode: static
-    :target: VNF
-    :introduced: dublin
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
 
-    If a VNF has two or more ``OS::ContrailV2::VirtualMachineInterface`` that
-    attach to an external network that require a Virtual IP Address (VIP),
-    and the VNF requires ONAP automation to assign the IP address,
-    all the Virtual Machines using the VIP address **MUST**
-    be instantiated in the same Base Module Heat Orchestration Template
-    or in the same Incremental Module Heat Orchestration Template.
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+    
+    parameter
+    **MUST NOT** be enumerated in the
+    VNF's Heat Orchestration Template's Environment File.
 
 
 .. req::
@@ -1182,53 +1173,35 @@ resource ``OS::Neutron::Port`` property
     :target: VNF
     :introduced: dublin
 
-    When the VNF's Heat Orchestration Template's Resource
+    When the VNF's Heat Orchestration Template's resource
     ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an external
     network (per the
     ONAP definition, see Requirement R-57424),
     and an IPv4 Virtual IP (VIP)
-    address is assigned via ONAP automation
-    using the map property,
-    ``virtual_machine_interface_allowed_address_pairs,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
-    , the parameter name **MUST** follow the
-    naming convention
+    is required to be supported by the ONAP data model,
+    the map property
 
-      * ``{vm-type}_{network-role}_floating_ip``
+    ``virtual_machine_interface_allowed_address_pairs``,
 
-    where
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
 
-      * ``{vm-type}`` is the {vm-type} associated with the
-        OS::Nova::Server
-      * ``{network-role}`` is the {network-role} of the external
-        network
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
 
-    And the parameter **MUST** be declared as type ``string``.
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+    
+    parameter name **MUST** follow the naming convention
 
+    * ``{vm-type}_{network-role}_floating_ip``
 
+    where
 
-.. req::
-    :id: R-100320
-    :keyword: MUST NOT
-    :validation_mode: static
-    :target: VNF
-    :introduced: dublin
+    * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
+    * ``{network-role}`` is the {network-role} of the external network
 
-    The VNF's Heat Orchestration Template's Resource
-    ``OS::ContrailV2::VirtualMachineInterface``
-    map property,
-    ``virtual_machine_interface_allowed_address_pairs,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
-    parameter
+    And the parameter **MUST** be declared as type ``string``.
 
-    * ``{vm-type}_{network-role}_floating_ip``
+    The ONAP data model can only support one IPv4 VIP address.
 
-    **MUST NOT** be enumerated in the
-    VNF's Heat Orchestration Template's Environment File.
 
 *Example Parameter Definition*
 
@@ -1241,7 +1214,6 @@ resource ``OS::Neutron::Port`` property
       description: IPv4 VIP for {vm-type} VMs on the {network-role} network
 
 
-
 .. req::
     :id: R-100330
     :keyword: MUST
@@ -1249,53 +1221,35 @@ resource ``OS::Neutron::Port`` property
     :target: VNF
     :introduced: dublin
 
-    When the VNF's Heat Orchestration Template's Resource
+    When the VNF's Heat Orchestration Template's resource
     ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an external
     network (per the
     ONAP definition, see Requirement R-57424),
     and an IPv6 Virtual IP (VIP)
-    address is assigned via ONAP automation
-    using the
-    map property,
-    ``virtual_machine_interface_allowed_address_pairs,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
-    , the parameter name **MUST** follow the
-    naming convention
+    is required to be supported by the ONAP data model,
+    the map property
 
-      * ``{vm-type}_{network-role}_floating_v6_ip``
+    ``virtual_machine_interface_allowed_address_pairs``,
 
-    where
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
 
-      * ``{vm-type}`` is the {vm-type} associated with the
-        OS::Nova::Server
-      * ``{network-role}`` is the {network-role} of the external
-        network
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
 
-    And the parameter **MUST** be declared as type ``string``.
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+   
+    parameter name **MUST** follow the naming convention
 
+    * ``{vm-type}_{network-role}_floating_v6_ip``
 
-.. req::
-    :id: R-100340
-    :keyword: MUST NOT
-    :validation_mode: static
-    :target: VNF
-    :introduced: dublin
+    where
 
-    The VNF's Heat Orchestration Template's Resource
-    ``OS::ContrailV2::VirtualMachineInterface``
-    map property,
-    ``virtual_machine_interface_allowed_address_pairs,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
-    parameter
+    * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
+    * ``{network-role}`` is the {network-role} of the external network
 
-    * ``{vm-type}_{network-role}_floating_v6_ip``
+    And the parameter **MUST** be declared as type ``string``.
+
+    The ONAP data model can only support one IPv6 VIP address.
 
-    **MUST NOT** be enumerated in the
-    VNF's Heat Orchestration Template's Environment File.
 
 *Example Parameter Definition*
 
@@ -1305,7 +1259,7 @@ resource ``OS::Neutron::Port`` property
 
     {vm-type}_{network-role}_floating_v6_ip:
       type: string
-      description: VIP for {vm-type} VMs on the {network-role} network
+      description: IPv6 VIP for {vm-type} VMs on the {network-role} network
 
 .. req::
     :id: R-100350
@@ -1314,21 +1268,46 @@ resource ``OS::Neutron::Port`` property
     :validation_mode: static
     :target: VNF
 
-    When the VNF's Heat Orchestration Template's Resource
-    ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an external
-    network (per the
-    ONAP definition, see Requirement R-57424),
-    and an IPv4 and/or IPv6 Virtual IP (VIP)
-    address is assigned via ONAP automation
-    using the
-    map property,
-    ``virtual_machine_interface_allowed_address_pairs,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,
-    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
-    parameter
-    **MUST NOT** be declared as ``type: comma_deliited_list``.
+    When the VNF's Heat Orchestration Template's resource
+    ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an
+    external network
+    (per the ONAP definition, see Requirement R-57424),
+    and the IPv4 VIP address and/or IPv6 VIP address
+    is **not** supported by the ONAP data model,
+    the map property
+
+    ``virtual_machine_interface_allowed_address_pairs``,
 
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+
+    * Parameter name **MAY** use any naming convention.  That is, there is no
+      ONAP mandatory parameter naming convention.
+    * Parameter **MAY** be declared as type ``string`` or type
+    ``comma_delimited_list``.
+
+    And the ``OS::ContrailV2::VirtualMachineInterface`` resource
+    **MUST** contain resource-level ``metadata`` (not property-level).
+
+    And the ``metadata`` format **MUST**  must contain the
+    key value ``aap_exempt`` with a list of all map property
+
+    ``virtual_machine_interface_allowed_address_pairs``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+
+    parameters **not** supported by the ONAP data model.
+
+
+Internal Networks
+~~~~~~~~~~~~~~~~~
 
 .. req::
     :id: R-100360
@@ -1431,6 +1410,9 @@ resource ``OS::Neutron::Port`` property
     and **MUST** be enumerated in the environment file.
 
 
+Example
+~~~~~~~
+
 
 *Example OS::ContrailV2::VirtualMachineInterface*
 
diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst
index eb02322..cfd6052 100644
--- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst
@@ -3,7 +3,7 @@
 .. Copyright 2017 AT&T Intellectual Property.  All rights reserved.
 
 Resource: OS::Neutron::Port - Parameters
--------------------------------------------------
+----------------------------------------
 
 The resource OS::Neutron::Port is for managing Neutron ports.
 
@@ -38,11 +38,8 @@ comma_delimited_list are supported in addition to String.
   <resource ID>:
     type: OS::Neutron::Port
     properties:
-      allowed_address_pairs: [{"ip_address": String, "mac_address": String},
-      {"ip_address": String, "mac_address": String}, ...]
-      fixed_ips: [{"ip_address": String, "subnet_id": String, "subnet":
-      String}, {"ip_address": String, "subnet_id": String, "subnet": String},
-      ...]
+      allowed_address_pairs: [{"ip_address": String, "mac_address": String}, {"ip_address": String, "mac_address": String}, ...]
+      fixed_ips: [{"ip_address": String, "subnet": String}, {"ip_address": String, "subnet": String}, ...]
       network: String
 
 The values associated with these properties may reference an external
@@ -60,16 +57,16 @@ function ``get_param``, ``get_resource``, or ``get_attr``.
 This will be described in the forth coming sections.
 
 Items to Note
-~~~~~~~~~~~~~~
+~~~~~~~~~~~~~
 
 A VNF **MAY** have one or more ports connected to a unique
 external network. All VNF ports connected to the unique external
-network **MUST** have cloud assigned IP Addresses
+network **MUST** have cloud assigned IP addresses
 or **MUST** have ONAP SDN-C assigned IP addresses.
 
 A VNF **MAY** have one or more ports connected to a unique
 internal network. All VNF ports connected to the unique internal
-network **MUST** have cloud assigned IP Addresses
+network **MUST** have cloud assigned IP addresses
 or **MUST** have statically assigned IP addresses.
 
 .. req::
@@ -94,9 +91,9 @@ or **MUST** have statically assigned IP addresses.
     :updated: casablanca
 
     If the VNF's ports connected to a unique external network
-    and the port's IP addresses are ONAP SDN-C assigned IP Addresses,
-    the IPv4 Addresses **MAY** be from different subnets and the IPv6
-    Addresses **MAY** be from different subnets.
+    and the port's IP addresses are ONAP SDN-C assigned IP addresses,
+    the IPv4 addresses **MAY** be from different subnets and the IPv6
+    addresses **MAY** be from different subnets.
 
 .. req::
     :id: R-48880
@@ -120,9 +117,9 @@ or **MUST** have statically assigned IP addresses.
     :updated: casablanca
 
     If the VNF's ports connected to a unique internal network
-    and the port's IP addresses are statically assigned IP Addresses,
-    the IPv4 Addresses **MAY** be from different subnets and the
-    IPv6 Addresses **MAY** be from different subnets.
+    and the port's IP addresses are statically assigned IP addresses,
+    the IPv4 addresses **MAY** be from different subnets and the
+    IPv6 addresses **MAY** be from different subnets.
 
 .. req::
     :id: R-70964
@@ -162,7 +159,7 @@ or **MUST** have statically assigned IP addresses.
     **MUST** contain the identical ``{network-role}``.
 
 Property: network
-^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^
 
 The Resource ``OS::Neutron::Port`` property ``network`` determines what network
 the port is attached to.
@@ -294,7 +291,7 @@ at orchestration time.
       description: Neutron name for the internal int_{network-role} network
 
 Property: fixed_ips, Map Property: ip_address
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The resource ``OS::Neutron::Port`` property ``fixed_ips``
 map property ``ip_address``
@@ -356,7 +353,7 @@ IPv4 and/or IPv6 addresses.
     **MUST NOT** be enumerated in the
     VNF's Heat Orchestration Template's Environment File.
 
-ONAP's SDN-Controller assigns the IP Address and ONAP provides
+ONAP's SDN-Controller assigns the IP address and ONAP provides
 the value at orchestration to the Heat Orchestration Template.
 
 *Example External Network IPv4 Address string Parameter Definition*
@@ -409,7 +406,7 @@ the value at orchestration to the Heat Orchestration Template.
     **MUST NOT** be enumerated in the
     VNF's Heat Orchestration Template's Environment File.
 
-ONAP's SDN-Controller assigns the IP Address and ONAP provides
+ONAP's SDN-Controller assigns the IP address and ONAP provides
 the value at orchestration to the Heat Orchestration Template.
 
 *Example External Network IPv4 Address comma_delimited_list
@@ -464,7 +461,7 @@ Parameter Definition*
     **MUST NOT** be enumerated in the
     VNF's Heat Orchestration Template's Environment File.
 
-ONAP's SDN-Controller assigns the IP Address and ONAP provides
+ONAP's SDN-Controller assigns the IP address and ONAP provides
 the value at orchestration to the Heat Orchestration Template.
 
 *Example External Network IPv6 Address string Parameter Definition*
@@ -517,7 +514,7 @@ the value at orchestration to the Heat Orchestration Template.
     **MUST NOT** be enumerated in the
     VNF's Heat Orchestration Template's Environment File.
 
-ONAP's SDN-Controller assigns the IP Address and ONAP provides
+ONAP's SDN-Controller assigns the IP address and ONAP provides
 the value at orchestration to the Heat Orchestration Template.
 
 *Example External Network IPv6 Address comma_delimited_list Parameter
@@ -804,7 +801,7 @@ Heat Orchestration Template's Environment File.
     assigned.
 
 Summary Table
-~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~
 
 .. csv-table:: **Table 4 OS::Neutron::Port Property fixed_ips map property ip_address Parameter Naming Convention**
    :header: Resource,Property,Map Property,Network Type,IP Address,Parameter Type,Parameter Name, Environment File
@@ -822,7 +819,7 @@ Summary Table
 
 
 Examples
-~~~~~~~~~~~~~~
+~~~~~~~~
 
 *Example: comma_delimited_list parameters for IPv4 and IPv6 Address
 Assignments to an external network*
@@ -1120,7 +1117,7 @@ that has two or more IPv4 subnets*
 
 In this example, the ``{network-role}`` has been defined as ``oam`` to
 represent an oam network and the ``{vm-type}`` has been defined as ``lb``
-for load balancer. The cloud assigned IP Address uses the OpenStack
+for load balancer. The cloud assigned IP address uses the OpenStack
 DHCP service to assign IP addresses.
 
 .. code-block:: yaml
@@ -1279,10 +1276,10 @@ input parameter.
       description: Neutron subnet UUID for the int_{network-role} network
 
 Property: allowed\_address\_pairs, Map Property: ip\_address
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The property ``allowed_address_pairs`` in the resource ``OS::Neutron::Port``
-allows the user to specify a mac_address and/or ip_address that will
+allows the user to specify a ``mac_address`` and/or ``ip_address`` that will
 pass through a port regardless of subnet. This enables the use of
 protocols, such as VRRP, which allow for a Virtual IP (VIP) address
 to be shared among two or more ports, with one designated as the master
@@ -1290,67 +1287,78 @@ and the others as backups. In case the master fails,
 the Virtual IP address is mapped to a backup's IP address and
 the backup becomes the master.
 
-Note that the management of the VIP IP addresses (i.e. transferring
+Note that the IP address assigned to the ``allowed_address_pairs`` property
+will be referred to as a Virtual IP or VIP or VIP address.
+
+The management of the VIP addresses (i.e. transferring
 ownership between active and standby VMs) is the responsibility of
 the VNF application.
 
-
-If a VNF has two or more ports that require a Virtual IP Address (VIP),
-a VNF's Heat Orchestration Template's Resource
+If a VNF requires a Virtual IP address,
+a VNF's Heat Orchestration Template's resource
 ``OS::Neutron::Port`` property ``allowed_address_pairs``
-map property ``ip_address`` parameter
-must be used.
+map property ``ip_address`` parameter must be used.
 
 The ``allowed_address_pairs`` is an optional property. It is not required.
 
-ONAP automation supports the assignment of VIP addresses
-for external networks.  ONAP support the assignment of one IPv4 VIP address
-and/or one IPv6 VIP address to a set of ports associated with a
-``{vm-type}`` and ``{network-role}``.
+The ONAP data model only supports the assignment of
 
-If a VNF requires more than one IPv4 VIP address
-and/or more than one IPv6 VIP address to a set of ports associated with a
-``{vm-type}`` and ``{network-role}``, there are "manual" work-around
-procedures that can be utilized.
+* One IPv4 Virtual IP address and/or
+* One IPv6 Virtual IP address
 
-VIP Assignment, External Networks, Supported by Automation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+for a set of ports associated with a ``{vm-type}`` and ``{network-role}``.
 
-.. req::
-    :id: R-91810
-    :target: VNF
-    :keyword: MUST NOT
-    :validation_mode: static
-    :updated: casablanca
+The ONAP data model that supports VIPs includes the
 
-    If a VNF requires ONAP to assign a Virtual IP (VIP) Address to
-    ports connected an external network, the port
-    **MUST NOT** have more than one IPv4 VIP address.
+* SDC TOSCA model
+* SDN-C MD-SAL structure
+* AAI VNF-C object
 
-.. req::
-    :id: R-41956
-    :target: VNF
-    :keyword: MUST NOT
-    :validation_mode: static
-    :updated: casablanca
+However, it is possible to assign additional VIP addresses to a port.
+These additional VIP addresses will not be represented in the
+SDC TOSCA model and AAI VNF-C object and will be represented differently
+in the MD-SAL structure.
+
+All VIP addresses will be inventoried in the
+A&AI vserver object.  This assumes the mechanism to populate
+allowed_address_pair IP addresses in the AAI vserver object has been
+implemented.
+
+In order for the VIP address to be supported by the ONAP data model,
+the parameter associated with the ``OS::Neutron::Port`` property
+``allowed_address_pairs`` map property ``ip_address`` must follow
+an explicit naming convention.
+As expected, the naming convention only supports one IPv4 VIP address
+and one IPv6 VIP address.
+
+It is recommended that the first IPv4 VIP address and first
+IPv6 VIP address assigned follow the explicit naming convention.
+If additional VIP addresses are required, the naming
+convention is at the discretion of the user.  However,
+``OS::Neutron::Port`` resource-level ``metadata`` (not property-level) must be
+included in the resource definition.
 
-    If a VNF requires ONAP to assign a Virtual IP (VIP) Address to
-    ports connected an external network, the port
-    **MUST NOT** have more than one IPv6 VIP address.
+The detailed requirements follow in the sections below.
+
+
+
+VIP Assignment, External Networks
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. req::
-    :id: R-10754
+    :id: R-83412
     :target: VNF
-    :keyword: MUST
+    :keyword: MUST NOT
     :validation_mode: static
-    :updated: casablanca
+    :updated: dublin
 
-    If a VNF has two or more ports that
-    attach to an external network that require a Virtual IP Address (VIP),
-    and the VNF requires ONAP automation to assign the IP address,
-    all the Virtual Machines using the VIP address **MUST**
-    be instantiated in the same Base Module Heat Orchestration Template
-    or in the same Incremental Module Heat Orchestration Template.
+    If a VNF's Heat Orchestration Template's resource
+    ``OS::Neutron::Port`` is attaching to an external network (per the
+    ONAP definition, see Requirement R-57424), the
+    property ``allowed_address_pairs``
+    map property ``ip_address`` parameter(s)
+    **MUST NOT** be enumerated in the
+    VNF's Heat Orchestration Template's Environment File.
 
 
 .. req::
@@ -1358,42 +1366,27 @@ VIP Assignment, External Networks, Supported by Automation
     :target: VNF
     :keyword: MUST
     :validation_mode: static
-    :updated: casablanca
+    :updated: dublin
 
-    When the VNF's Heat Orchestration Template's Resource
-    ``OS::Neutron::Port`` is attaching to an external network (per the
-    ONAP definition, see Requirement R-57424),
-    and an IPv4 Virtual IP (VIP)
-    address is assigned via ONAP automation
-    using the property ``allowed_address_pairs``
-    map property ``ip_address`` and
-    the parameter name **MUST** follow the
-    naming convention
+    When the VNF's Heat Orchestration Template's resource
+    ``OS::Neutron::Port`` is attaching to an external network
+    (per the ONAP definition, see Requirement R-57424),
+    and the IPv4 VIP is required to be supported by the ONAP data model,
+    the property ``allowed_address_pairs`` map property ``ip_address``
+    parameter name **MUST** follow the naming convention
 
-      * ``{vm-type}_{network-role}_floating_ip``
+    * ``{vm-type}_{network-role}_floating_ip``
 
     where
 
-      * ``{vm-type}`` is the {vm-type} associated with the
-        OS::Nova::Server
-      * ``{network-role}`` is the {network-role} of the external
-        network
+    * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
+    * ``{network-role}`` is the {network-role} of the external network
 
     And the parameter **MUST** be declared as type ``string``.
 
-.. req::
-    :id: R-83412
-    :target: VNF
-    :keyword: MUST NOT
-    :validation_mode: static
-    :updated: casablanca
+    As noted in the introduction to this section, the ONAP data model
+    can only support one IPv4 VIP address.
 
-    The VNF's Heat Orchestration Template's Resource
-    ``OS::Neutron::Port`` property ``allowed_address_pairs``
-    map property ``ip_address`` parameter
-    ``{vm-type}_{network-role}_floating_ip``
-    **MUST NOT** be enumerated in the
-    VNF's Heat Orchestration Template's Environment File.
 
 *Example Parameter Definition*
 
@@ -1405,47 +1398,33 @@ VIP Assignment, External Networks, Supported by Automation
       type: string
       description: IPv4 VIP for {vm-type} VMs on the {network-role} network
 
+
 .. req::
     :id: R-35735
     :target: VNF
     :keyword: MUST
     :validation_mode: static
-    :updated: casablanca
+    :updated: dublin
 
-    When the VNF's Heat Orchestration Template's Resource
-    ``OS::Neutron::Port`` is attaching to an external network (per the
-    ONAP definition, see Requirement R-57424),
-    and an IPv6 Virtual IP (VIP)
-    address is assigned via ONAP automation
-    using the property ``allowed_address_pairs``
-    map property ``ip_address``,
-    the parameter name **MUST** follow the
-    naming convention
+    When the VNF's Heat Orchestration Template's resource
+    ``OS::Neutron::Port`` is attaching to an external network
+    (per the ONAP definition, see Requirement R-57424),
+    and the IPv6 VIP is required to be supported by the ONAP data model,
+    the property ``allowed_address_pairs`` map property ``ip_address``
+    parameter name **MUST** follow the naming convention
 
-      * ``{vm-type}_{network-role}_floating_v6_ip``
+    * ``{vm-type}_{network-role}_floating_v6_ip``
 
     where
 
-      * ``{vm-type}`` is the {vm-type} associated with the
-        OS::Nova::Server
-      * ``{network-role}`` is the {network-role} of the external
-        network
+    * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
+    * ``{network-role}`` is the {network-role} of the external network
 
     And the parameter **MUST** be declared as type ``string``.
 
-.. req::
-    :id: R-83418
-    :target: VNF
-    :keyword: MUST NOT
-    :validation_mode: static
-    :updated: casablanca
+    As noted in the introduction to this section, the ONAP data model
+    can only support one IPv6 VIP address.
 
-    The VNF's Heat Orchestration Template's Resource
-    ``OS::Neutron::Port`` property ``allowed_address_pairs``
-    map property ``ip_address`` parameter
-    ``{vm-type}_{network-role}_floating_v6_ip``
-    **MUST NOT** be enumerated in the
-    VNF's Heat Orchestration Template's Environment File.
 
 *Example Parameter Definition*
 
@@ -1455,120 +1434,80 @@ VIP Assignment, External Networks, Supported by Automation
 
     {vm-type}_{network-role}_floating_v6_ip:
       type: string
-      description: VIP for {vm-type} VMs on the {network-role} network
-
-.. req::
-    :id: R-159016
-    :keyword: MUST NOT
-    :updated: dublin
-    :validation_mode: static
-    :target: VNF
-
-    When the VNF's Heat Orchestration Template's Resource
-    ``OS::Neutron::Port`` is attaching to an external network (per the
-    ONAP definition, see Requirement R-57424),
-    and an IPv4 and/or IPv6 Virtual IP (VIP)
-    address is assigned via ONAP automation
-    using the property ``allowed_address_pairs``
-    map property ``ip_address``, the
-    parameter **MUST NOT** be declared as ``type: comma_deliited_list``.
-
+      description: IPv6 VIP for {vm-type} VMs on the {network-role} network
 
 
 .. req::
-    :id: R-717227
-    :keyword: MUST
-    :updated: dublin
-    :validation_mode: static
+    :id: R-41493
     :target: VNF
-
-    When the VNF's Heat Orchestration Template's Resource
-    ``OS::Neutron::Port`` is attaching to an internal network (per the
-    ONAP definition, see Requirements R-52425 and R-46461),
-    and an IPv4 Virtual IP (VIP)
-    address is assigned using the property ``allowed_address_pairs``
-    map property ``ip_address``,
-    the parameter name **MUST** follow the
-    naming convention
-
-      * ``{vm-type}_int_{network-role}_floating_ip``
-
-    where
-
-      * ``{vm-type}`` is the {vm-type} associated with the
-        OS::Nova::Server
-      * ``{network-role}`` is the {network-role} of the external
-        network
-
-    And the parameter **MUST** be declared as ``type: string``
-    and **MUST** be enumerated in the environment file.
-
-    OR
-
-    the parameter name **MUST** follow the
-    naming convention
-
-      * ``{vm-type}_int_{network-role}_floating_ips``
-
-    where
-
-      * ``{vm-type}`` is the {vm-type} associated with the
-        OS::Nova::Server
-      * ``{network-role}`` is the {network-role} of the external
-        network
-
-    And the parameter **MUST** be declared as ``type: comma_delimited_list``
-    and **MUST** be enumerated in the environment file.
-
-
-.. req::
-    :id: R-805572
     :keyword: MUST
-    :updated: dublin
     :validation_mode: static
-    :target: VNF
+    :introduced: dublin
+
+    When the VNF's Heat Orchestration Template's resource
+    ``OS::Neutron::Port`` is attaching to an external network
+    (per the ONAP definition, see Requirement R-57424),
+    and the IPv4 VIP address and/or IPv6 VIP address
+    is **not** supported by the ONAP data model,
+    the property ``allowed_address_pairs`` map property ``ip_address``
+
+    * Parameter name **MAY** use any naming convention.  That is, there is no
+      ONAP mandatory parameter naming convention.
+    * Parameter **MAY** be declared as type ``string`` or type
+    ``comma_delimited_list``.
 
-    When the VNF's Heat Orchestration Template's Resource
-    ``OS::Neutron::Port`` is attaching to an internal network (per the
-    ONAP definition, see Requirements R-52425 and R-46461),
-    and an IPv6 Virtual IP (VIP)
-    address is assigned
-    using the property ``allowed_address_pairs``
-    map property ``ip_address``,
-    the parameter name **MUST** follow the
-    naming convention
+    And the ``OS::Neutron::Port`` resource **MUST** contain
+    resource-level ``metadata`` (not property-level).
 
-      * ``{vm-type}_int_{network-role}_floating_v6_ip``
+    And the ``metadata`` format **MUST**  must contain the
+    key value ``aap_exempt`` with a list of all
+    ``allowed_address_pairs`` map property ``ip_address`` parameters
+    **not** supported by the ONAP data model.
 
-    where
 
-      * ``{vm-type}`` is the {vm-type} associated with the
-        OS::Nova::Server
-      * ``{network-role}`` is the {network-role} of the external
-        network
+*Example*
 
-    And the parameter **MUST** be declared as ``type: string``
-    and **MUST** be enumerated in the environment file
+In the example below, the ``OS::Neutron::Port`` property
+``allowed_address_pairs`` map property ``ip_address`` has two parameters,
+``param1`` and ``param2``, that are not supported by the ONAP data model.
 
-    OR
+.. code-block:: yaml
 
-    the parameter name **MUST** follow the
-    naming convention
+  db_0_oam_port_0:
+    type: OS::Neutron::Port
+    properties:
+      network: { get_param: oam_net_id }
+      fixed_ips: [ { "ip_address": {get_param: db_oam_ip_0 }}]
+      allowed_address_pairs: [ { "ip_address": {get_param: param1 }}, { "ip_address": {get_param: param2 }}]
+    metadata:
+      aap_exempt:
+        - param1
+        - param2
 
-      * ``{vm-type}_int_{network-role}_floating_v6_ips``
 
-    where
+*Example*
 
-      * ``{vm-type}`` is the {vm-type} associated with the
-        OS::Nova::Server
-      * ``{network-role}`` is the {network-role} of the external
-        network
+In the example below, the ``OS::Neutron::Port`` property
+``allowed_address_pairs`` map property ``ip_address`` has two parameters,
+``db_oam_ip_0``, which is supported by the ONAP data model, and param1,
+which is not supported by the ONAP data model.
 
-    And the parameter **MUST** be declared as ``type: comma_delimited_list``
-    and **MUST** be enumerated in the environment file.
+.. code-block:: yaml
+
+  db_0_oam_port_0:
+    type: OS::Neutron::Port
+    properties:
+      network: { get_param: oam_net_id }
+      fixed_ips: [ { "ip_address": {get_param: db_oam_ip_0 }}]
+      allowed_address_pairs: [ { "ip_address": {get_param: db_oam_floating_ip }}, { "ip_address": {get_param: param1 }} ]
+    metadata:
+      aap_exempt:
+        - param1
 
 
-Note that these parameters are **not** intended to represent an OpenStack
+Note that the parameters associated with the resource
+``OS::Neutron::Port`` property ``allowed_address_pairs``
+map property ``ip_address``  are **not** intended to represent an OpenStack
 "Floating IP", for which OpenStack manages a pool of public IP
 addresses that are mapped to specific VM ports. In that case, the
 individual VMs are not even aware of the public IPs, and all assignment
@@ -1599,20 +1538,20 @@ and ``OS::Neutron::FloatingIPAssociation``.
     contain the Resource ``OS::Neutron::FloatingIPAssociation``.
 
 The Floating IP functions as a NAT.  They are allocated within
-Openstack, and always "terminate" within the Openstack infrastructure.
-When Openstack receives packets on a Floating IP, the packets will
+OpenStack, and always "terminate" within the OpenStack infrastructure.
+When OpenStack receives packets on a Floating IP, the packets will
 be forwarded to the
 Port that has been mapped to the Floating IP, using the private address of the
-port.  The VM never sees or knows about the Openstack Floating IP.
+port.  The VM never sees or knows about the OpenStack Floating IP.
 The process to use is:
 
-  - User allocates a floating IP from the Openstack pool.
+  - User allocates a floating IP from the OpenStack pool.
   - User ‘attaches’ that floating IP to one of the VM ports.
 
 If there is a high-availability VNF that wants to "float" the IP to a
-different VM, it requires a Neutron command to request Openstack to ‘attach’
+different VM, it requires a Neutron command to request OpenStack to ‘attach’
 the floating IP to a different VM port.
-The pool of such addresses is managed by Openstack infrastructure.
+The pool of such addresses is managed by OpenStack infrastructure.
 Users cannot create new ones, they can only choose from those in the pool.
 The pool is typically global (i.e. any user/tenant can grab them).
 
@@ -1631,8 +1570,8 @@ additional IPs.
 
 Floating IPs are not used in ONAP due to the NAT-ting nature of the IPs,
 the inability to reserve such IPs for specific use, the need to manage them
-via Openstack commands (i.e. a HA VNF would require direct access to
-Openstack to ‘float’ such an IP from one VM to another).
+via OpenStack commands (i.e. a HA VNF would require direct access to
+OpenStack to ‘float’ such an IP from one VM to another).
 
 *Example:*
 
@@ -1656,273 +1595,121 @@ an oam network and the {vm-type} has been defined as db for database.
       type: OS::Neutron::Port
       properties:
         network: { get_param: oam_net_id }
-        fixed_ips: [ { "ip_address": {get_param: [db_oam_ips,0] }}]
-        allowed_address_pairs: [ { "ip_address": {get_param:
-        db_oam_floating_ip}}]
+        fixed_ips: [ { "ip_address": {get_param: [db_oam_ips, 0] }}]
+        allowed_address_pairs: [ { "ip_address": {get_param: db_oam_floating_ip}}]
     db_1_oam_port_0:
       type: OS::Neutron::Port
         properties:
           network: { get_param: oam_net_id }
-          fixed_ips: [ { "ip_address": {get_param: [db_oam_ips,1] }}]
-          allowed_address_pairs: [ { "ip_address": {get_param:
-          db_oam_floating_ip}}]
-
-VIP Assignment, External Networks, Additional Options
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The parameter ``{vm-type}_{network-role}_floating_ip`` allows for only one
-allowed address pair IPv4 address per ``{vm-type}`` and ``{network-role}``
-combination.
-
-The parameter ``{vm-type}_{network-role}_floating_v6_ip`` allows for only one
-allowed address pair IPv6 address per ``{vm-type}`` and ``{network-role}``
-combination.
-
-If there is a need for multiple allowed address pair IPs for a given
-{vm-type} and {network-role} combination within a VNF, there are two
-options.
-
-**Option One**
-
-If there is a need for multiple allowed address pair IPs for a given
-``{vm-type}`` and ``{network-role}`` combination within a VNF, then the
-parameter names defined for the Property ``fixed_ips`` Map Property
-``ip_address`` should be used or the Property ``allowed_address_pairs``
-Map Property ``ip_address``. The
-parameter names are provided in the table below.
-
-.. csv-table:: **Table 5 OS::Neutron::Port Property allowed_address_pairs map property ip_address Parameter Naming Convention**
-   :header: IP Address,Parameter Type,Parameter Name
-   :align: center
-   :widths: auto
-
-   IPv4, string, {vm-type}_{network-role}_ip_{index}
-   IPv4, comma_delimited_list, {vm-type}_{network-role}_ips
-   IPv6, string, {vm-type}_{network-role}_v6_ip_{index}
-   IPv6, comma_delimited_list, {vm-type}_{network-role}_v6_ips
-
-The examples below illustrate this concept.
-
-*Example: A VNF has four load balancers. Each pair has a unique VIP.*
-
-In this example, there are two administrative VM pairs. Each pair has
-one VIP. The {network-role} has been defined as oam to represent an oam
-network and the {vm-type} has been defined as admin for an
-administrative VM.
-
-Pair 1: Resources admin_0_port_0 and admin_1_port_0 share a unique VIP,
-[admin_oam_ips,2]
-
-Pair 2: Resources admin_2_port_0 and admin_3_port_0 share a unique VIP,
-[admin_oam_ips,5]
-
-.. code-block:: yaml
-
-  parameters:
-    oam_net_id:
-      type: string
-      description: Neutron UUID for the oam network
-    admin_oam_ips:
-      type: comma_delimited_list
-      description: Fixed IP assignments for admin VMs on the oam network
-
-  resources:
-    admin_0_oam_port_0:
-      type: OS::Neutron::Port
-      properties:
-        network: { get_param: oam_net_id }
-        fixed_ips: [ { "ip_address": {get_param: [admin_oam_ips,0] }}]
-        allowed_address_pairs: [{ "ip_address": {get_param: [admin_oam_ips,2]
-        }}]
-    admin_1_oam_port_0:
-      type: OS::Neutron::Port
-      properties:
-        network: { get_param: oam_net_id }
-        fixed_ips: [ { "ip_address": {get_param: [admin_oam_ips,1] }}]
-        allowed_address_pairs: [{ "ip_address": {get_param: [admin_oam_ips,2]
-      }}]
-    admin_2_oam_port_0:
-      type: OS::Neutron::Port
-      properties:
-        network: { get_param: oam_net_id }
-        fixed_ips: [ { "ip_address": {get_param: [admin_oam_ips,3] }}]
-        allowed_address_pairs: [{ "ip_address": {get_param: [admin_oam_ips,5]
-        }}]
-    admin_3_oam_port_0:
-      type: OS::Neutron::Port
-      properties:
-        network: { get_param: oam_net_id }
-        fixed_ips: [ { "ip_address": {get_param: [admin_oam_ips,4] }}]
-        allowed_address_pairs: [{ "ip_address": {get_param: [admin_oam_ips,5]
-        }}]
-
-*Example: A VNF has two load balancers. The pair of load balancers share
-two VIPs.*
-
-In this example, there is one load balancer pairs. The pair has two
-VIPs. The {network-role} has been defined as oam to represent an oam
-network and the {vm-type} has been defined as lb for a load balancer VM.
-
-.. code-block:: yaml
-
-  resources:
-    lb_0_oam_port_0:
-      type: OS::Neutron::Port
-      properties:
-        network: { get_param: oam_net_id }
-        fixed_ips: [ { "ip_address": {get_param: [lb_oam_ips,0] }}]
-        allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2] },
-        {get_param: [lb_oam_ips,3] }}]
-    lb_1_oam_port_0:
-      type: OS::Neutron::Port
-      properties:
-        network: { get_param: oam_net_id }
-        fixed_ips: [ { "ip_address": {get_param: [lb_oam_ips,1] }}]
-        allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2] },
-        {get_param: [lb_oam_ips,3] }}]
-
-As a general rule, provide the fixed IPs for the VMs indexed first in
-the CDL and then the VIPs as shown in the examples above.
-
-**Option Two**
-
-If there is a need for multiple allowed address pair IPs for a given
-``{vm-type}`` and ``{network-role}`` combination within a VNF, then the
-parameter names defined for the table below can be used.
-
-**Resource OS::Neutron::Port**
-
-Table 6: Multiple allowed_address_pairs Option 2A
-
-.. csv-table:: **Table 6 OS::Neutron::Port Property allowed_address_pairs map property ip_address Parameter Naming Convention**
-   :header: IP Address,Parameter Type,Parameter Name
-   :align: center
-   :widths: auto
-
-   IPv4, string, {vm-type}_{network-role}_vip_{index}
-   IPv4, comma_delimited_list, {vm-type}_{network-role}_vips
-   IPv6, string, {vm-type}_{network-role}_v6_vip_{index}
-   IPv6, comma_delimited_list, {vm-type}_{network-role}_v6_vips
-
-
-If there is a need for multiple allowed address pair IPs for a given
-``{vm-type}`` and ``{network-role}`` combination within a VNF and the need to
-differentiate the VIPs for different traffic types (e.g., 911 VIP,
-fail-over VIP), then the parameter names defined for the table below can
-be used.
-
-**Resource OS::Neutron::Port**
-
-Table 7: Multiple allowed_address_pairs Option 2B
+          fixed_ips: [ { "ip_address": {get_param: [db_oam_ips, 1] }}]
+          allowed_address_pairs: [ { "ip_address": {get_param: db_oam_floating_ip}}]
 
-.. csv-table:: **Table 7 OS::Neutron::Port Property allowed_address_pairs map property ip_address Parameter Naming Convention**
-   :header: IP Address,Parameter Type,Parameter Name
-   :align: center
-   :widths: auto
 
-   IPv4, string, {vm-type}_{network-role}_{vip_type}_vip
-   IPv4, comma_delimited_list, {vm-type}_{network-role}_{vip_type}_vips
-   IPv6, string, {vm-type}_{network-role}_{vip_type}_v6_vip
-   IPv6, comma_delimited_list, {vm-type}_{network-role}_{vip_type}_v6_vips
 
-Internal Networks
-~~~~~~~~~~~~~~~~~~~~~~~
 
-ONAP defines an internal network in relation to
-the VNF and not with regard to the cloud site. Internal
-networks may also be referred to as "intra-VNF" networks or "private"
-networks. An internal network only connects VMs in a single VNF. It
-must not connect to other VNFs or an external (to the cloud) gateway or an
-external (to the cloud) router.
 
-ONAP internal networks should be created in the base module.
+VIP Assignment, Internal Networks
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-As previously mentioned, ports that connect to an internal network are assigned
-IP addresses via one of two methods
+.. req::
+    :id: R-717227
+    :keyword: MUST
+    :updated: dublin
+    :validation_mode: static
+    :target: VNF
 
- * Method 1: Cloud assigned by OpenStack's DHCP Service
- * Method 2: Statically assigned.  That is, predetermined by the VNF designer
-   and are specified in the VNF's Heat Orchestration Template's
-   Environment File
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461),
+    and an IPv4 Virtual IP (VIP)
+    address is assigned using the property ``allowed_address_pairs``
+    map property ``ip_address``,
+    the parameter name **MUST** follow the
+    naming convention
 
-If cloud assigned IP addressing is being used, output statements
-are created in the base module.
+      * ``{vm-type}_int_{network-role}_floating_ip``
 
-If static assigned IP addressing is being used, the  IP addresses
-are defined in the environment file.
+    where
 
+      * ``{vm-type}`` is the {vm-type} associated with the
+        OS::Nova::Server
+      * ``{network-role}`` is the {network-role} of the external
+        network
 
-  * ``{vm-type}_int_{network-role}_floating_ip``
-  * ``{vm-type}_int_{network-role}_floating_v6_ip``
+    And the parameter **MUST** be declared as ``type: string``
+    and **MUST** be enumerated in the environment file.
 
-  * ``{vm-type}_int_{network-role}_vip_{index}``
-  * ``{vm-type}_int_{network-role}_vips``
-  * ``{vm-type}_int_{network-role}_v6_vip_{index}``
-  * ``{vm-type}_int_{network-role}_v6_vips``
+    OR
 
+    the parameter name **MUST** follow the
+    naming convention
 
-  * ``{vm-type}_int_{network-role}_{vip_type}_vip``
-  * ``{vm-type}_int_{network-role}_{vip_type}_vips``
-  * ``{vm-type}_int_{network-role}_{vip_type}_v6_vip``
-  * ``{vm-type}_int_{network-role}_{vip_type}_v6_vips``
+      * ``{vm-type}_int_{network-role}_floating_ips``
 
+    where
 
+      * ``{vm-type}`` is the {vm-type} associated with the
+        OS::Nova::Server
+      * ``{network-role}`` is the {network-role} of the external
+        network
 
-*Example Parameter Definition*
+    And the parameter **MUST** be declared as ``type: comma_delimited_list``
+    and **MUST** be enumerated in the environment file.
 
-.. code-block:: yaml
 
-  parameters:
-    {vm-type}_int_{network-role}_floating_ip:
-      type: string
-      description: VIP for {vm-type} VMs on the int_{network-role} network
+.. req::
+    :id: R-805572
+    :keyword: MUST
+    :updated: dublin
+    :validation_mode: static
+    :target: VNF
 
-    {vm-type}_int_{network-role}_floating_v6_ip:
-      type: string
-      description: VIP for {vm-type} VMs on the int_{network-role} network
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461),
+    and an IPv6 Virtual IP (VIP)
+    address is assigned
+    using the property ``allowed_address_pairs``
+    map property ``ip_address``,
+    the parameter name **MUST** follow the
+    naming convention
 
+      * ``{vm-type}_int_{network-role}_floating_v6_ip``
 
+    where
 
-allowed_address_pair IP Addresses Required in more than one module
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+      * ``{vm-type}`` is the {vm-type} associated with the
+        OS::Nova::Server
+      * ``{network-role}`` is the {network-role} of the external
+        network
 
-If the IP address ``{vm-type}_{network-role}_floating_ip`` and/or
-``{vm-type}_{network-role}_floating_v6_ip`` must be used in more than module
-in the
-VNF, the parameter values must be defined as output values in the base module
-with
-output names: ``{vm-type}_{network-role}_shared_vip`` or
-``{vm-type}_{network-role}_v6_shared_vip``.
+    And the parameter **MUST** be declared as ``type: string``
+    and **MUST** be enumerated in the environment file
 
+    OR
 
-.. code-block:: yaml
+    the parameter name **MUST** follow the
+    naming convention
 
-  outputs:
-    {vm-type}_{network-role}_shared_vip:
-      description:
-      value: { get_param: {vm-type}_{network-role}_floating_ip }
+      * ``{vm-type}_int_{network-role}_floating_v6_ips``
 
-    {vm-type}_{network-role}_v6_shared_vip:
-      description:
-      value: { get_param: {vm-type}_{network-role}_v6_floating_ip }
+    where
 
-The output parameters must be defined as input parameter in the
-incremental modules that require the IP addresses. When defining the
-``allowed_address_pairs`` in the ``OS::Neutron::Port``, it should be as
-follows:
+      * ``{vm-type}`` is the {vm-type} associated with the
+        OS::Nova::Server
+      * ``{network-role}`` is the {network-role} of the external
+        network
 
-.. code-block:: yaml
+    And the parameter **MUST** be declared as ``type: comma_delimited_list``
+    and **MUST** be enumerated in the environment file.
 
-  allowed_address_pairs: [ { "ip_address": {get_param:
-  {vm-type}_{network-role}_shared_vip }}, { "ip_address": {get_param:
-  {vm-type}_{network-role}_v6_shared_vip }}]
 
 Reserve Port Concept
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~
 
 A "Reserve Port" is an ``OS::Neutron::Port`` that ``fixed_ips``, ip_address
 property is assigned one or more IP addresses that are used as Virtual
-IP (VIP) Addresses (i.e., allowed_address_pairs) on other ports.
+IP (VIP) addresses (i.e., allowed_address_pairs) on other ports.
 
 A "Reserve Port" is never attached to a Virtual Machine
 (``OS::Nova::Server``). The reserve port ensures that the intended
@@ -1933,7 +1720,7 @@ thus causing routing issues.
 A VNF may have one or more "Reserve Ports". A reserve port maybe created
 in the base module or an incremental module. If created in the base
 module, parameters may be defined in the outputs: section of the base
-template so the IP Address assigned to the reserve port maybe assigned
+template so the IP address assigned to the reserve port maybe assigned
 to the allowed_address_pair property of an ``OS::Neutron::Port`` in one or
 more incremental modules.
 
@@ -1994,3 +1781,6 @@ configured on a port*
       network: { get_param: {network-role}_net_id }
       fixed_ips:
         - ip_address : { get_param: {vm-type}_{network-role}_floating_v6_ip }
+
+Note that the use of a Reserve Port may prevent the VIP address from being
+inventoried in the AAI VNF-C object.
\ No newline at end of file