swagger: "2.0"
info:
  description: |

    [Differences versus the previous schema version](apidocs/aai_swagger_v13.diff)

    Copyright &copy; 2017 AT&amp;T Intellectual Property. All rights reserved.

    Licensed under the Creative Commons License, Attribution 4.0 Intl. (the &quot;License&quot;); you may not use this documentation except in compliance with the License.

    You may obtain a copy of the License at

    (https://creativecommons.org/licenses/by/4.0/)

    Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

    ECOMP and OpenECOMP are trademarks and service marks of AT&amp;T Intellectual Property.

    This document is best viewed with Firefox or Chrome. Nodes can be found by appending /#/definitions/node-type-to-find to the path to this document. Edge definitions can be found with the node definitions.
  version: "v13"
  title: Active and Available Inventory REST API
  license:
    name: Apache 2.0
    url: http://www.apache.org/licenses/LICENSE-2.0.html
  contact:
    name:
    url:
    email:
host:
basePath: /aai/v13
schemes:
  - https
paths:
  /network/logical-links/logical-link/{link-name}:
    patch:
      tags:
        - Network
      summary: update an existing logical-link
      description: |
        Update an existing logical-link
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkLogicalLinksLogicalLink
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: link-name
          in: path
          description: e.g., evc-name, or vnf-nameA_interface-nameA_vnf-nameZ_interface-nameZ
          required: true
          type: string
          example: __LINK-NAME__
        - name: body
          in: body
          description: logical-link object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/logical-link"
  /network/site-pair-sets/site-pair-set/{site-pair-set-id}/routing-instances/routing-instance/{routing-instance-id}/site-pairs/site-pair/{site-pair-id}/classes-of-service/class-of-service/{cos}:
    patch:
      tags:
        - Network
      summary: update an existing class-of-service
      description: |
        Update an existing class-of-service
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkSitePairSetsSitePairSetRoutingInstancesRoutingInstanceSitePairsSitePairClassesOfServiceClassOfService
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: site-pair-set-id
          in: path
          description: Unique id of site pair set.
          required: true
          type: string
          example: __SITE-PAIR-SET-ID__
        - name: routing-instance-id
          in: path
          description: Unique id of routing instance
          required: true
          type: string
          example: __ROUTING-INSTANCE-ID__
        - name: site-pair-id
          in: path
          description: unique identifier of probe
          required: true
          type: string
          example: __SITE-PAIR-ID__
        - name: cos
          in: path
          description: unique identifier of probe
          required: true
          type: string
          example: __COS__
        - name: body
          in: body
          description: class-of-service object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/class-of-service"
  /network/site-pair-sets/site-pair-set/{site-pair-set-id}/routing-instances/routing-instance/{routing-instance-id}/site-pairs/site-pair/{site-pair-id}:
    patch:
      tags:
        - Network
      summary: update an existing site-pair
      description: |
        Update an existing site-pair
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkSitePairSetsSitePairSetRoutingInstancesRoutingInstanceSitePairsSitePair
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: site-pair-set-id
          in: path
          description: Unique id of site pair set.
          required: true
          type: string
          example: __SITE-PAIR-SET-ID__
        - name: routing-instance-id
          in: path
          description: Unique id of routing instance
          required: true
          type: string
          example: __ROUTING-INSTANCE-ID__
        - name: site-pair-id
          in: path
          description: unique identifier of probe
          required: true
          type: string
          example: __SITE-PAIR-ID__
        - name: body
          in: body
          description: site-pair object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/site-pair"
  /network/site-pair-sets/site-pair-set/{site-pair-set-id}/routing-instances/routing-instance/{routing-instance-id}:
    patch:
      tags:
        - Network
      summary: update an existing routing-instance
      description: |
        Update an existing routing-instance
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkSitePairSetsSitePairSetRoutingInstancesRoutingInstance
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: site-pair-set-id
          in: path
          description: Unique id of site pair set.
          required: true
          type: string
          example: __SITE-PAIR-SET-ID__
        - name: routing-instance-id
          in: path
          description: Unique id of routing instance
          required: true
          type: string
          example: __ROUTING-INSTANCE-ID__
        - name: body
          in: body
          description: routing-instance object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/routing-instance"
  /network/site-pair-sets/site-pair-set/{site-pair-set-id}:
    patch:
      tags:
        - Network
      summary: update an existing site-pair-set
      description: |
        Update an existing site-pair-set
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkSitePairSetsSitePairSet
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: site-pair-set-id
          in: path
          description: Unique id of site pair set.
          required: true
          type: string
          example: __SITE-PAIR-SET-ID__
        - name: body
          in: body
          description: site-pair-set object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/site-pair-set"
  /network/vpn-bindings/vpn-binding/{vpn-id}/route-targets/route-target/{global-route-target}/{route-target-role}:
    patch:
      tags:
        - Network
      summary: update an existing route-target
      description: |
        Update an existing route-target
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVpnBindingsVpnBindingRouteTargetsRouteTarget
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vpn-id
          in: path
          description: VPN ID, globally unique within A&AI
          required: true
          type: string
          example: __VPN-ID__
        - name: global-route-target
          in: path
          description: Number used to identify an RT, globally unique in the network
          required: true
          type: string
          example: __GLOBAL-ROUTE-TARGET__
        - name: route-target-role
          in: path
          description: Role assigned to this route target
          required: true
          type: string
          example: __ROUTE-TARGET-ROLE__
        - name: body
          in: body
          description: route-target object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/route-target"
  /network/vpn-bindings/vpn-binding/{vpn-id}:
    patch:
      tags:
        - Network
      summary: update an existing vpn-binding
      description: |
        Update an existing vpn-binding
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVpnBindingsVpnBinding
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vpn-id
          in: path
          description: VPN ID, globally unique within A&AI
          required: true
          type: string
          example: __VPN-ID__
        - name: body
          in: body
          description: vpn-binding object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vpn-binding"
  /network/vpls-pes/vpls-pe/{equipment-name}/p-interfaces/p-interface/{interface-name}/sriov-pfs/sriov-pf/{pf-pci-id}:
    patch:
      tags:
        - Network
      summary: update an existing sriov-pf
      description: |
        Update an existing sriov-pf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPePInterfacesPInterfaceSriovPfsSriovPf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: pf-pci-id
          in: path
          description: Identifier for the sriov-pf
          required: true
          type: string
          example: __PF-PCI-ID__
        - name: body
          in: body
          description: sriov-pf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/sriov-pf"
  /network/vpls-pes/vpls-pe/{equipment-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPePInterfacesPInterfaceLInterfacesLInterfaceVlansVlanL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/vpls-pes/vpls-pe/{equipment-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPePInterfacesPInterfaceLInterfacesLInterfaceVlansVlanL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/vpls-pes/vpls-pe/{equipment-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}:
    patch:
      tags:
        - Network
      summary: update an existing vlan
      description: |
        Update an existing vlan
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPePInterfacesPInterfaceLInterfacesLInterfaceVlansVlan
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: body
          in: body
          description: vlan object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vlan"
  /network/vpls-pes/vpls-pe/{equipment-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/sriov-vfs/sriov-vf/{pci-id}:
    patch:
      tags:
        - Network
      summary: update an existing sriov-vf
      description: |
        Update an existing sriov-vf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPePInterfacesPInterfaceLInterfacesLInterfaceSriovVfsSriovVf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: pci-id
          in: path
          description: PCI ID used to identify the sriov-vf
          required: true
          type: string
          example: __PCI-ID__
        - name: body
          in: body
          description: sriov-vf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/sriov-vf"
  /network/vpls-pes/vpls-pe/{equipment-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPePInterfacesPInterfaceLInterfacesLInterfaceL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/vpls-pes/vpls-pe/{equipment-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPePInterfacesPInterfaceLInterfacesLInterfaceL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/vpls-pes/vpls-pe/{equipment-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing l-interface
      description: |
        Update an existing l-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPePInterfacesPInterfaceLInterfacesLInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: l-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l-interface"
  /network/vpls-pes/vpls-pe/{equipment-name}/p-interfaces/p-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing p-interface
      description: |
        Update an existing p-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPePInterfacesPInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: p-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/p-interface"
  /network/vpls-pes/vpls-pe/{equipment-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPeLagInterfacesLagInterfaceLInterfacesLInterfaceVlansVlanL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/vpls-pes/vpls-pe/{equipment-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPeLagInterfacesLagInterfaceLInterfacesLInterfaceVlansVlanL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/vpls-pes/vpls-pe/{equipment-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}:
    patch:
      tags:
        - Network
      summary: update an existing vlan
      description: |
        Update an existing vlan
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPeLagInterfacesLagInterfaceLInterfacesLInterfaceVlansVlan
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: body
          in: body
          description: vlan object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vlan"
  /network/vpls-pes/vpls-pe/{equipment-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/sriov-vfs/sriov-vf/{pci-id}:
    patch:
      tags:
        - Network
      summary: update an existing sriov-vf
      description: |
        Update an existing sriov-vf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPeLagInterfacesLagInterfaceLInterfacesLInterfaceSriovVfsSriovVf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: pci-id
          in: path
          description: PCI ID used to identify the sriov-vf
          required: true
          type: string
          example: __PCI-ID__
        - name: body
          in: body
          description: sriov-vf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/sriov-vf"
  /network/vpls-pes/vpls-pe/{equipment-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPeLagInterfacesLagInterfaceLInterfacesLInterfaceL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/vpls-pes/vpls-pe/{equipment-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPeLagInterfacesLagInterfaceLInterfacesLInterfaceL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/vpls-pes/vpls-pe/{equipment-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing l-interface
      description: |
        Update an existing l-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPeLagInterfacesLagInterfaceLInterfacesLInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: l-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l-interface"
  /network/vpls-pes/vpls-pe/{equipment-name}/lag-interfaces/lag-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing lag-interface
      description: |
        Update an existing lag-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPeLagInterfacesLagInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: lag-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/lag-interface"
  /network/vpls-pes/vpls-pe/{equipment-name}:
    patch:
      tags:
        - Network
      summary: update an existing vpls-pe
      description: |
        Update an existing vpls-pe
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVplsPesVplsPe
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: equipment-name
          in: path
          required: true
          type: string
          example: __EQUIPMENT-NAME__
        - name: body
          in: body
          description: vpls-pe object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vpls-pe"
  /network/multicast-configurations/multicast-configuration/{multicast-configuration-id}:
    patch:
      tags:
        - Network
      summary: update an existing multicast-configuration
      description: |
        Update an existing multicast-configuration
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkMulticastConfigurationsMulticastConfiguration
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: multicast-configuration-id
          in: path
          description: Unique id of multicast configuration.
          required: true
          type: string
          example: __MULTICAST-CONFIGURATION-ID__
        - name: body
          in: body
          description: multicast-configuration object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/multicast-configuration"
  /network/vces/vce/{vnf-id}/port-groups/port-group/{interface-id}/cvlan-tags/cvlan-tag-entry/{cvlan-tag}:
    patch:
      tags:
        - Network
      summary: update an existing cvlan-tag-entry
      description: |
        Update an existing cvlan-tag-entry
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVcesVcePortGroupsPortGroupCvlanTagsCvlanTagEntry
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-id
          in: path
          description: Unique ID of the interface
          required: true
          type: string
          example: __INTERFACE-ID__
        - name: cvlan-tag
          in: path
          description: See mis-na-virtualization-platform.yang
          required: true
          type: integer
          format: int64
          example: __CVLAN-TAG__
        - name: body
          in: body
          description: cvlan-tag-entry object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/cvlan-tag-entry"
  /network/vces/vce/{vnf-id}/port-groups/port-group/{interface-id}:
    patch:
      tags:
        - Network
      summary: update an existing port-group
      description: |
        Update an existing port-group
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVcesVcePortGroupsPortGroup
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-id
          in: path
          description: Unique ID of the interface
          required: true
          type: string
          example: __INTERFACE-ID__
        - name: body
          in: body
          description: port-group object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/port-group"
  /network/vces/vce/{vnf-id}/licenses/license/{group-uuid}/{resource-uuid}:
    patch:
      tags:
        - Network
      summary: update an existing license
      description: |
        Update an existing license
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVcesVceLicensesLicense
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: group-uuid
          in: path
          description: Unique ID for the license group the resource belongs to, should be uuid.
          required: true
          type: string
          example: __GROUP-UUID__
        - name: resource-uuid
          in: path
          description: Unique ID of a license resource. 
          required: true
          type: string
          example: __RESOURCE-UUID__
        - name: body
          in: body
          description: license object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/license"
  /network/vces/vce/{vnf-id}/entitlements/entitlement/{group-uuid}/{resource-uuid}:
    patch:
      tags:
        - Network
      summary: update an existing entitlement
      description: |
        Update an existing entitlement
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVcesVceEntitlementsEntitlement
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: group-uuid
          in: path
          description: Unique ID for the entitlement group the resource comes from, should be uuid.
          required: true
          type: string
          example: __GROUP-UUID__
        - name: resource-uuid
          in: path
          description: Unique ID of an entitlement resource. 
          required: true
          type: string
          example: __RESOURCE-UUID__
        - name: body
          in: body
          description: entitlement object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/entitlement"
  /network/vces/vce/{vnf-id}:
    patch:
      tags:
        - Network
      summary: update an existing vce
      description: |
        Update an existing vce
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVcesVce
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: body
          in: body
          description: vce object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vce"
  /network/vnfcs/vnfc/{vnfc-name}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVnfcsVnfcL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnfc-name
          in: path
          description: Unique ID of vnfc.
          required: true
          type: string
          example: __VNFC-NAME__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/vnfcs/vnfc/{vnfc-name}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVnfcsVnfcL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnfc-name
          in: path
          description: Unique ID of vnfc.
          required: true
          type: string
          example: __VNFC-NAME__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/vnfcs/vnfc/{vnfc-name}:
    patch:
      tags:
        - Network
      summary: update an existing vnfc
      description: |
        Update an existing vnfc
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkVnfcsVnfc
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnfc-name
          in: path
          description: Unique ID of vnfc.
          required: true
          type: string
          example: __VNFC-NAME__
        - name: body
          in: body
          description: vnfc object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vnfc"
  /network/l3-networks/l3-network/{network-id}/subnets/subnet/{subnet-id}/host-routes/host-route/{host-route-id}:
    patch:
      tags:
        - Network
      summary: update an existing host-route
      description: |
        Update an existing host-route
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkL3NetworksL3NetworkSubnetsSubnetHostRoutesHostRoute
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: network-id
          in: path
          description: Network ID, should be uuid. Unique across A&AI.
          required: true
          type: string
          example: __NETWORK-ID__
        - name: subnet-id
          in: path
          description: Subnet ID, should be UUID.
          required: true
          type: string
          example: __SUBNET-ID__
        - name: host-route-id
          in: path
          description: host-route id
          required: true
          type: string
          example: __HOST-ROUTE-ID__
        - name: body
          in: body
          description: host-route object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/host-route"
  /network/l3-networks/l3-network/{network-id}/subnets/subnet/{subnet-id}:
    patch:
      tags:
        - Network
      summary: update an existing subnet
      description: |
        Update an existing subnet
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkL3NetworksL3NetworkSubnetsSubnet
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: network-id
          in: path
          description: Network ID, should be uuid. Unique across A&AI.
          required: true
          type: string
          example: __NETWORK-ID__
        - name: subnet-id
          in: path
          description: Subnet ID, should be UUID.
          required: true
          type: string
          example: __SUBNET-ID__
        - name: body
          in: body
          description: subnet object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/subnet"
  /network/l3-networks/l3-network/{network-id}/ctag-assignments/ctag-assignment/{vlan-id-inner}:
    patch:
      tags:
        - Network
      summary: update an existing ctag-assignment
      description: |
        Update an existing ctag-assignment
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkL3NetworksL3NetworkCtagAssignmentsCtagAssignment
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: network-id
          in: path
          description: Network ID, should be uuid. Unique across A&AI.
          required: true
          type: string
          example: __NETWORK-ID__
        - name: vlan-id-inner
          in: path
          description: id.
          required: true
          type: integer
          format: int64
          example: __VLAN-ID-INNER__
        - name: body
          in: body
          description: ctag-assignment object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/ctag-assignment"
  /network/l3-networks/l3-network/{network-id}/segmentation-assignments/segmentation-assignment/{segmentation-id}:
    patch:
      tags:
        - Network
      summary: update an existing segmentation-assignment
      description: |
        Update an existing segmentation-assignment
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkL3NetworksL3NetworkSegmentationAssignmentsSegmentationAssignment
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: network-id
          in: path
          description: Network ID, should be uuid. Unique across A&AI.
          required: true
          type: string
          example: __NETWORK-ID__
        - name: segmentation-id
          in: path
          description: Route Table Reference id, UUID assigned to this instance.
          required: true
          type: string
          example: __SEGMENTATION-ID__
        - name: body
          in: body
          description: segmentation-assignment object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/segmentation-assignment"
  /network/l3-networks/l3-network/{network-id}:
    patch:
      tags:
        - Network
      summary: update an existing l3-network
      description: |
        Update an existing l3-network
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkL3NetworksL3Network
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: network-id
          in: path
          description: Network ID, should be uuid. Unique across A&AI.
          required: true
          type: string
          example: __NETWORK-ID__
        - name: body
          in: body
          description: l3-network object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-network"
  /network/network-policies/network-policy/{network-policy-id}:
    patch:
      tags:
        - Network
      summary: update an existing network-policy
      description: |
        Update an existing network-policy
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkNetworkPoliciesNetworkPolicy
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: network-policy-id
          in: path
          description: UUID representing unique key to this instance
          required: true
          type: string
          example: __NETWORK-POLICY-ID__
        - name: body
          in: body
          description: network-policy object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/network-policy"
  /network/generic-vnfs/generic-vnf/{vnf-id}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLInterfacesLInterfaceVlansVlanL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/generic-vnfs/generic-vnf/{vnf-id}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLInterfacesLInterfaceVlansVlanL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/generic-vnfs/generic-vnf/{vnf-id}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}:
    patch:
      tags:
        - Network
      summary: update an existing vlan
      description: |
        Update an existing vlan
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLInterfacesLInterfaceVlansVlan
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: body
          in: body
          description: vlan object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vlan"
  /network/generic-vnfs/generic-vnf/{vnf-id}/l-interfaces/l-interface/{interface-name}/sriov-vfs/sriov-vf/{pci-id}:
    patch:
      tags:
        - Network
      summary: update an existing sriov-vf
      description: |
        Update an existing sriov-vf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLInterfacesLInterfaceSriovVfsSriovVf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: pci-id
          in: path
          description: PCI ID used to identify the sriov-vf
          required: true
          type: string
          example: __PCI-ID__
        - name: body
          in: body
          description: sriov-vf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/sriov-vf"
  /network/generic-vnfs/generic-vnf/{vnf-id}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLInterfacesLInterfaceL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/generic-vnfs/generic-vnf/{vnf-id}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLInterfacesLInterfaceL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/generic-vnfs/generic-vnf/{vnf-id}/l-interfaces/l-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing l-interface
      description: |
        Update an existing l-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLInterfacesLInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: l-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l-interface"
  /network/generic-vnfs/generic-vnf/{vnf-id}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLagInterfacesLagInterfaceLInterfacesLInterfaceVlansVlanL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/generic-vnfs/generic-vnf/{vnf-id}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLagInterfacesLagInterfaceLInterfacesLInterfaceVlansVlanL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/generic-vnfs/generic-vnf/{vnf-id}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}:
    patch:
      tags:
        - Network
      summary: update an existing vlan
      description: |
        Update an existing vlan
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLagInterfacesLagInterfaceLInterfacesLInterfaceVlansVlan
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: body
          in: body
          description: vlan object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vlan"
  /network/generic-vnfs/generic-vnf/{vnf-id}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/sriov-vfs/sriov-vf/{pci-id}:
    patch:
      tags:
        - Network
      summary: update an existing sriov-vf
      description: |
        Update an existing sriov-vf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLagInterfacesLagInterfaceLInterfacesLInterfaceSriovVfsSriovVf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: pci-id
          in: path
          description: PCI ID used to identify the sriov-vf
          required: true
          type: string
          example: __PCI-ID__
        - name: body
          in: body
          description: sriov-vf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/sriov-vf"
  /network/generic-vnfs/generic-vnf/{vnf-id}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLagInterfacesLagInterfaceLInterfacesLInterfaceL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/generic-vnfs/generic-vnf/{vnf-id}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLagInterfacesLagInterfaceLInterfacesLInterfaceL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/generic-vnfs/generic-vnf/{vnf-id}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing l-interface
      description: |
        Update an existing l-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLagInterfacesLagInterfaceLInterfacesLInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: l-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l-interface"
  /network/generic-vnfs/generic-vnf/{vnf-id}/lag-interfaces/lag-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing lag-interface
      description: |
        Update an existing lag-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLagInterfacesLagInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: lag-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/lag-interface"
  /network/generic-vnfs/generic-vnf/{vnf-id}/vf-modules/vf-module/{vf-module-id}:
    patch:
      tags:
        - Network
      summary: update an existing vf-module
      description: |
        Update an existing vf-module
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfVfModulesVfModule
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: vf-module-id
          in: path
          description: Unique ID of vf-module.
          required: true
          type: string
          example: __VF-MODULE-ID__
        - name: body
          in: body
          description: vf-module object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vf-module"
  /network/generic-vnfs/generic-vnf/{vnf-id}/licenses/license/{group-uuid}/{resource-uuid}:
    patch:
      tags:
        - Network
      summary: update an existing license
      description: |
        Update an existing license
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfLicensesLicense
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: group-uuid
          in: path
          description: Unique ID for the license group the resource belongs to, should be uuid.
          required: true
          type: string
          example: __GROUP-UUID__
        - name: resource-uuid
          in: path
          description: Unique ID of a license resource. 
          required: true
          type: string
          example: __RESOURCE-UUID__
        - name: body
          in: body
          description: license object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/license"
  /network/generic-vnfs/generic-vnf/{vnf-id}/entitlements/entitlement/{group-uuid}/{resource-uuid}:
    patch:
      tags:
        - Network
      summary: update an existing entitlement
      description: |
        Update an existing entitlement
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnfEntitlementsEntitlement
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: group-uuid
          in: path
          description: Unique ID for the entitlement group the resource comes from, should be uuid.
          required: true
          type: string
          example: __GROUP-UUID__
        - name: resource-uuid
          in: path
          description: Unique ID of an entitlement resource. 
          required: true
          type: string
          example: __RESOURCE-UUID__
        - name: body
          in: body
          description: entitlement object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/entitlement"
  /network/generic-vnfs/generic-vnf/{vnf-id}:
    patch:
      tags:
        - Network
      summary: update an existing generic-vnf
      description: |
        Update an existing generic-vnf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkGenericVnfsGenericVnf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id
          in: path
          description: Unique id of VNF.  This is unique across the graph.
          required: true
          type: string
          example: __VNF-ID__
        - name: body
          in: body
          description: generic-vnf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/generic-vnf"
  /network/lag-links/lag-link/{link-name}:
    patch:
      tags:
        - Network
      summary: update an existing lag-link
      description: |
        Update an existing lag-link
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkLagLinksLagLink
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: link-name
          in: path
          description: Alphabetical concatenation of lag-interface names
          required: true
          type: string
          example: __LINK-NAME__
        - name: body
          in: body
          description: lag-link object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/lag-link"
  /network/newvces/newvce/{vnf-id2}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkNewvcesNewvceLInterfacesLInterfaceVlansVlanL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id2
          in: path
          description: Unique id of VNF, can't use same attribute name right now until we promote this new object
          required: true
          type: string
          example: __VNF-ID2__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/newvces/newvce/{vnf-id2}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkNewvcesNewvceLInterfacesLInterfaceVlansVlanL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id2
          in: path
          description: Unique id of VNF, can't use same attribute name right now until we promote this new object
          required: true
          type: string
          example: __VNF-ID2__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/newvces/newvce/{vnf-id2}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}:
    patch:
      tags:
        - Network
      summary: update an existing vlan
      description: |
        Update an existing vlan
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkNewvcesNewvceLInterfacesLInterfaceVlansVlan
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id2
          in: path
          description: Unique id of VNF, can't use same attribute name right now until we promote this new object
          required: true
          type: string
          example: __VNF-ID2__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: body
          in: body
          description: vlan object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vlan"
  /network/newvces/newvce/{vnf-id2}/l-interfaces/l-interface/{interface-name}/sriov-vfs/sriov-vf/{pci-id}:
    patch:
      tags:
        - Network
      summary: update an existing sriov-vf
      description: |
        Update an existing sriov-vf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkNewvcesNewvceLInterfacesLInterfaceSriovVfsSriovVf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id2
          in: path
          description: Unique id of VNF, can't use same attribute name right now until we promote this new object
          required: true
          type: string
          example: __VNF-ID2__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: pci-id
          in: path
          description: PCI ID used to identify the sriov-vf
          required: true
          type: string
          example: __PCI-ID__
        - name: body
          in: body
          description: sriov-vf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/sriov-vf"
  /network/newvces/newvce/{vnf-id2}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkNewvcesNewvceLInterfacesLInterfaceL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id2
          in: path
          description: Unique id of VNF, can't use same attribute name right now until we promote this new object
          required: true
          type: string
          example: __VNF-ID2__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/newvces/newvce/{vnf-id2}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkNewvcesNewvceLInterfacesLInterfaceL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id2
          in: path
          description: Unique id of VNF, can't use same attribute name right now until we promote this new object
          required: true
          type: string
          example: __VNF-ID2__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/newvces/newvce/{vnf-id2}/l-interfaces/l-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing l-interface
      description: |
        Update an existing l-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkNewvcesNewvceLInterfacesLInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id2
          in: path
          description: Unique id of VNF, can't use same attribute name right now until we promote this new object
          required: true
          type: string
          example: __VNF-ID2__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: l-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l-interface"
  /network/newvces/newvce/{vnf-id2}:
    patch:
      tags:
        - Network
      summary: update an existing newvce
      description: |
        Update an existing newvce
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkNewvcesNewvce
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: vnf-id2
          in: path
          description: Unique id of VNF, can't use same attribute name right now until we promote this new object
          required: true
          type: string
          example: __VNF-ID2__
        - name: body
          in: body
          description: newvce object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/newvce"
  /network/pnfs/pnf/{pnf-name}/p-interfaces/p-interface/{interface-name}/sriov-pfs/sriov-pf/{pf-pci-id}:
    patch:
      tags:
        - Network
      summary: update an existing sriov-pf
      description: |
        Update an existing sriov-pf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfPInterfacesPInterfaceSriovPfsSriovPf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: pf-pci-id
          in: path
          description: Identifier for the sriov-pf
          required: true
          type: string
          example: __PF-PCI-ID__
        - name: body
          in: body
          description: sriov-pf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/sriov-pf"
  /network/pnfs/pnf/{pnf-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfPInterfacesPInterfaceLInterfacesLInterfaceVlansVlanL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/pnfs/pnf/{pnf-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfPInterfacesPInterfaceLInterfacesLInterfaceVlansVlanL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/pnfs/pnf/{pnf-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}:
    patch:
      tags:
        - Network
      summary: update an existing vlan
      description: |
        Update an existing vlan
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfPInterfacesPInterfaceLInterfacesLInterfaceVlansVlan
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: body
          in: body
          description: vlan object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vlan"
  /network/pnfs/pnf/{pnf-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/sriov-vfs/sriov-vf/{pci-id}:
    patch:
      tags:
        - Network
      summary: update an existing sriov-vf
      description: |
        Update an existing sriov-vf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfPInterfacesPInterfaceLInterfacesLInterfaceSriovVfsSriovVf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: pci-id
          in: path
          description: PCI ID used to identify the sriov-vf
          required: true
          type: string
          example: __PCI-ID__
        - name: body
          in: body
          description: sriov-vf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/sriov-vf"
  /network/pnfs/pnf/{pnf-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfPInterfacesPInterfaceLInterfacesLInterfaceL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/pnfs/pnf/{pnf-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfPInterfacesPInterfaceLInterfacesLInterfaceL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/pnfs/pnf/{pnf-name}/p-interfaces/p-interface/{interface-name}/l-interfaces/l-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing l-interface
      description: |
        Update an existing l-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfPInterfacesPInterfaceLInterfacesLInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: l-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l-interface"
  /network/pnfs/pnf/{pnf-name}/p-interfaces/p-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing p-interface
      description: |
        Update an existing p-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfPInterfacesPInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the physical interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: p-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/p-interface"
  /network/pnfs/pnf/{pnf-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfLagInterfacesLagInterfaceLInterfacesLInterfaceVlansVlanL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/pnfs/pnf/{pnf-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfLagInterfacesLagInterfaceLInterfacesLInterfaceVlansVlanL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/pnfs/pnf/{pnf-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/vlans/vlan/{vlan-interface}:
    patch:
      tags:
        - Network
      summary: update an existing vlan
      description: |
        Update an existing vlan
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfLagInterfacesLagInterfaceLInterfacesLInterfaceVlansVlan
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: vlan-interface
          in: path
          description: String that identifies the interface
          required: true
          type: string
          example: __VLAN-INTERFACE__
        - name: body
          in: body
          description: vlan object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vlan"
  /network/pnfs/pnf/{pnf-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/sriov-vfs/sriov-vf/{pci-id}:
    patch:
      tags:
        - Network
      summary: update an existing sriov-vf
      description: |
        Update an existing sriov-vf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfLagInterfacesLagInterfaceLInterfacesLInterfaceSriovVfsSriovVf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: pci-id
          in: path
          description: PCI ID used to identify the sriov-vf
          required: true
          type: string
          example: __PCI-ID__
        - name: body
          in: body
          description: sriov-vf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/sriov-vf"
  /network/pnfs/pnf/{pnf-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv4-address-list/{l3-interface-ipv4-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv4-address-list
      description: |
        Update an existing l3-interface-ipv4-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfLagInterfacesLagInterfaceLInterfacesLInterfaceL3InterfaceIpv4AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv4-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV4-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv4-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv4-address-list"
  /network/pnfs/pnf/{pnf-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}/l3-interface-ipv6-address-list/{l3-interface-ipv6-address}:
    patch:
      tags:
        - Network
      summary: update an existing l3-interface-ipv6-address-list
      description: |
        Update an existing l3-interface-ipv6-address-list
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfLagInterfacesLagInterfaceLInterfacesLInterfaceL3InterfaceIpv6AddressList
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: l3-interface-ipv6-address
          in: path
          description: IP address
          required: true
          type: string
          example: __L3-INTERFACE-IPV6-ADDRESS__
        - name: body
          in: body
          description: l3-interface-ipv6-address-list object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l3-interface-ipv6-address-list"
  /network/pnfs/pnf/{pnf-name}/lag-interfaces/lag-interface/{interface-name}/l-interfaces/l-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing l-interface
      description: |
        Update an existing l-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfLagInterfacesLagInterfaceLInterfacesLInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: interface-name
          in: path
          description: Name given to the interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: l-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/l-interface"
  /network/pnfs/pnf/{pnf-name}/lag-interfaces/lag-interface/{interface-name}:
    patch:
      tags:
        - Network
      summary: update an existing lag-interface
      description: |
        Update an existing lag-interface
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnfLagInterfacesLagInterface
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: interface-name
          in: path
          description: Name that identifies the link aggregate interface
          required: true
          type: string
          example: __INTERFACE-NAME__
        - name: body
          in: body
          description: lag-interface object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/lag-interface"
  /network/pnfs/pnf/{pnf-name}:
    patch:
      tags:
        - Network
      summary: update an existing pnf
      description: |
        Update an existing pnf
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPnfsPnf
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: pnf-name
          in: path
          description: unique name of Physical Network Function.
          required: true
          type: string
          example: __PNF-NAME__
        - name: body
          in: body
          description: pnf object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/pnf"
  /network/physical-links/physical-link/{link-name}:
    patch:
      tags:
        - Network
      summary: update an existing physical-link
      description: |
        Update an existing physical-link
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkPhysicalLinksPhysicalLink
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: link-name
          in: path
          description: e.g., hostnameA_p-connection_nameA_hostnameZ+p_connection-nameZ
          required: true
          type: string
          example: __LINK-NAME__
        - name: body
          in: body
          description: physical-link object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/physical-link"
  /network/ipsec-configurations/ipsec-configuration/{ipsec-configuration-id}/vig-servers/vig-server/{vig-address-type}:
    patch:
      tags:
        - Network
      summary: update an existing vig-server
      description: |
        Update an existing vig-server
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkIpsecConfigurationsIpsecConfigurationVigServersVigServer
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: ipsec-configuration-id
          in: path
          description: UUID of this configuration
          required: true
          type: string
          example: __IPSEC-CONFIGURATION-ID__
        - name: vig-address-type
          in: path
          description: indicates whether the VIG is for AVPN or INTERNET
          required: true
          type: string
          example: __VIG-ADDRESS-TYPE__
        - name: body
          in: body
          description: vig-server object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/vig-server"
  /network/ipsec-configurations/ipsec-configuration/{ipsec-configuration-id}:
    patch:
      tags:
        - Network
      summary: update an existing ipsec-configuration
      description: |
        Update an existing ipsec-configuration
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkIpsecConfigurationsIpsecConfiguration
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: ipsec-configuration-id
          in: path
          description: UUID of this configuration
          required: true
          type: string
          example: __IPSEC-CONFIGURATION-ID__
        - name: body
          in: body
          description: ipsec-configuration object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/ipsec-configuration"
  /network/route-table-references/route-table-reference/{route-table-reference-id}:
    patch:
      tags:
        - Network
      summary: update an existing route-table-reference
      description: |
        Update an existing route-table-reference
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkRouteTableReferencesRouteTableReference
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: route-table-reference-id
          in: path
          description: Route Table Reference id, UUID assigned to this instance.
          required: true
          type: string
          example: __ROUTE-TABLE-REFERENCE-ID__
        - name: body
          in: body
          description: route-table-reference object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/route-table-reference"
  /network/instance-groups/instance-group/{id}:
    patch:
      tags:
        - Network
      summary: update an existing instance-group
      description: |
        Update an existing instance-group
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkInstanceGroupsInstanceGroup
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: id
          in: path
          description: Instance Group ID, UUID assigned to this instance.
          required: true
          type: string
          example: __ID__
        - name: body
          in: body
          description: instance-group object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/instance-group"
  /network/zones/zone/{zone-id}:
    patch:
      tags:
        - Network
      summary: update an existing zone
      description: |
        Update an existing zone
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkZonesZone
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: zone-id
          in: path
          description: Code assigned by AIC to the zone
          required: true
          type: string
          example: __ZONE-ID__
        - name: body
          in: body
          description: zone object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/zone"
  /network/configurations/configuration/{configuration-id}/metadata/metadatum/{metaname}:
    patch:
      tags:
        - Network
      summary: update an existing metadatum
      description: |
        Update an existing metadatum
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkConfigurationsConfigurationMetadataMetadatum
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: configuration-id
          in: path
          description: UUID assigned to configuration.
          required: true
          type: string
          example: __CONFIGURATION-ID__
        - name: metaname
          in: path
          required: true
          type: string
          example: __METANAME__
        - name: body
          in: body
          description: metadatum object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/metadatum"
  /network/configurations/configuration/{configuration-id}/forwarder-evcs/forwarder-evc/{forwarder-evc-id}:
    patch:
      tags:
        - Network
      summary: update an existing forwarder-evc
      description: |
        Update an existing forwarder-evc
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkConfigurationsConfigurationForwarderEvcsForwarderEvc
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: configuration-id
          in: path
          description: UUID assigned to configuration.
          required: true
          type: string
          example: __CONFIGURATION-ID__
        - name: forwarder-evc-id
          in: path
          description: Key for forwarder-evc object
          required: true
          type: string
          example: __FORWARDER-EVC-ID__
        - name: body
          in: body
          description: forwarder-evc object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/forwarder-evc"
  /network/configurations/configuration/{configuration-id}/evcs/evc/{evc-id}:
    patch:
      tags:
        - Network
      summary: update an existing evc
      description: |
        Update an existing evc
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkConfigurationsConfigurationEvcsEvc
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: configuration-id
          in: path
          description: UUID assigned to configuration.
          required: true
          type: string
          example: __CONFIGURATION-ID__
        - name: evc-id
          in: path
          description: Unique/key field for the evc object
          required: true
          type: string
          example: __EVC-ID__
        - name: body
          in: body
          description: evc object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/evc"
  /network/configurations/configuration/{configuration-id}:
    patch:
      tags:
        - Network
      summary: update an existing configuration
      description: |
        Update an existing configuration
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkConfigurationsConfiguration
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: configuration-id
          in: path
          description: UUID assigned to configuration.
          required: true
          type: string
          example: __CONFIGURATION-ID__
        - name: body
          in: body
          description: configuration object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/configuration"
  /network/forwarding-paths/forwarding-path/{forwarding-path-id}/forwarders/forwarder/{sequence}:
    patch:
      tags:
        - Network
      summary: update an existing forwarder
      description: |
        Update an existing forwarder
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkForwardingPathsForwardingPathForwardersForwarder
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: forwarding-path-id
          in: path
          description: Unique ID of this FP
          required: true
          type: string
          example: __FORWARDING-PATH-ID__
        - name: sequence
          in: path
          description: Unique ID of this segmentation
          required: true
          type: integer
          format: int32
          example: __SEQUENCE__
        - name: body
          in: body
          description: forwarder object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/forwarder"
  /network/forwarding-paths/forwarding-path/{forwarding-path-id}:
    patch:
      tags:
        - Network
      summary: update an existing forwarding-path
      description: |
        Update an existing forwarding-path
        #
        Note:  Endpoints that are not devoted to object relationships support both PUT and PATCH operations.
        The PUT operation will entirely replace an existing object.
        The PATCH operation sends a "description of changes" for an existing object.  The entire set of changes must be applied.  An error result means no change occurs.
        #
        Other differences between PUT and PATCH are:
        #
        - For PATCH, you can send any of the values shown in sample REQUEST body.  There are no required values.
        - For PATCH, resource-id which is a required REQUEST body element for PUT, must not be sent.
        - PATCH cannot be used to update relationship elements; there are dedicated PUT operations for this.
      operationId: UpdateNetworkForwardingPathsForwardingPath
      consumes:
        - application/json
        - application/xml
      produces:
        - application/json
        - application/xml
      responses:
        "default":
          description: Response codes found in [response codes](https://wiki.web.att.com/pages/viewpage.action?pageId=607391054).
      parameters:
        - name: forwarding-path-id
          in: path
          description: Unique ID of this FP
          required: true
          type: string
          example: __FORWARDING-PATH-ID__
        - name: body
          in: body
          description: forwarding-path object that needs to be updated.
          required: true
          schema:
            $ref: "#/definitions/forwarding-path"
definitions:
  class-of-service:
    description: |
      ###### Related Nodes
      - TO site-pair( class-of-service BelongsTo site-pair, MANY2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this CLASS-OF-SERVICE is DELETED also
    required:
    - cos
    properties:
      cos:
        type: string
        description: unique identifier of probe
      probe-id:
        type: string
        description: identifier of probe
      probe-type:
        type: string
        description: type of probe
  classes-of-service:
    description: |
      class-of-service of probe
    properties:
      class-of-service:
        type: array
        items:          
          $ref: "#/definitions/class-of-service"
  configuration:
    description: |
      Generic configuration object.
      ###### Related Nodes
      - TO allotted-resource( configuration Uses allotted-resource, ONE2ONE, will delete target node)(2)
      - TO logical-link( configuration Uses logical-link, ONE2MANY, will delete target node)(2)
      - TO l-interface( configuration AppliesTo l-interface, ONE2MANY, will delete target node)
      - TO pnf( configuration AppliesTo pnf, ONE2MANY, will delete target node)
      - TO configuration( configuration BindsTo configuration, ONE2ONE, will delete target node)
      - TO vpn-binding( configuration Uses vpn-binding, MANY2ONE, will delete target node)
      - TO generic-vnf( configuration PartOf generic-vnf, MANY2ONE, will delete target node)
      - TO vlan( configuration PartOf vlan, ONE2ONE, will delete target node)
      - TO l3-network( configuration PartOf l3-network, ONE2ONE, will delete target node)
      - TO service-instance( configuration BelongsTo service-instance, MANY2ONE, will delete target node)(4)
      - TO pnf( configuration AppliesTo pnf, MANY2MANY, will delete target node)
      - FROM metadatum( metadatum BelongsTo configuration, MANY2ONE, will delete target node)(1)
      - FROM generic-vnf( generic-vnf Uses configuration, ONE2MANY, will delete target node)(3)
      - FROM service-instance( service-instance Uses configuration, ONE2MANY, will delete target node)
      - FROM forwarder( forwarder Uses configuration, ONE2ONE, will delete target node)(3)
      - FROM forwarding-path( forwarding-path Uses configuration, ONE2ONE, will delete target node)(3)
      - FROM evc( evc BelongsTo configuration, ONE2ONE, will delete target node)(1)
      - FROM forwarder-evc( forwarder-evc BelongsTo configuration, ONE2ONE, will delete target node)(1)
      - FROM service-instance( service-instance Uses configuration, MANY2MANY, will delete target node)
      - FROM configuration( configuration BindsTo configuration, ONE2ONE, will delete target node)

      -(1) IF this CONFIGURATION node is deleted, this FROM node is DELETED also
      -(2) IF this CONFIGURATION node is deleted, this TO node is DELETED also
      -(3) IF this FROM node is deleted, this CONFIGURATION is DELETED also
      -(4) IF this TO node is deleted, this CONFIGURATION is DELETED also
    required:
    - configuration-id
    - configuration-type
    - configuration-sub-type
    properties:
      configuration-id:
        type: string
        description: UUID assigned to configuration.
      management-option:
        type: string
        description: Indicates the entity that will manage this feature. Could be an organization or the name of the application as well.
      configuration-name:
        type: string
        description: Name of the configuration.
      configuration-type:
        type: string
        description: port-mirroring-configuration.
      configuration-sub-type:
        type: string
        description: vprobe, pprobe.
      model-invariant-id:
        type: string
        description: the ASDC model id for this resource or service model.
      model-version-id:
        type: string
        description: the ASDC model version for this resource or service model.
      orchestration-status:
        type: string
        description: Orchestration status of the configuration.
      operational-status:
        type: string
        description: Indicator for whether the resource is considered operational.
      configuration-selflink:
        type: string
        description: URL to endpoint where AAI can get more details from SDN-GC.
      model-customization-id:
        type: string
        description: id of  the configuration used to customize the resource
      tunnel-bandwidth:
        type: string
        description: DHV Site Effective Bandwidth
      vendor-allowed-max-bandwidth:
        type: string
        description: Velocloud Nominal Throughput - VNT
  configurations:
    description: |
      Collection of configurations
    properties:
      configuration:
        type: array
        items:          
          $ref: "#/definitions/configuration"
  ctag-assignment:
    description: |
      ###### Related Nodes
      - TO l3-network( ctag-assignment BelongsTo l3-network, MANY2ONE, will delete target node)(4)
      - FROM service-instance( service-instance Uses ctag-assignment, ONE2MANY, will delete target node)

      -(4) IF this TO node is deleted, this CTAG-ASSIGNMENT is DELETED also
    required:
    - vlan-id-inner
    properties:
      vlan-id-inner:
        type: integer
        format: int64
        description: id.
  ctag-assignments:
    properties:
      ctag-assignment:
        type: array
        items:          
          $ref: "#/definitions/ctag-assignment"
  cvlan-tag-entry:
    required:
    - cvlan-tag
    properties:
      cvlan-tag:
        type: integer
        format: int64
        description: See mis-na-virtualization-platform.yang
  cvlan-tags:
    properties:
      cvlan-tag-entry:
        type: array
        items:          
          $ref: "#/definitions/cvlan-tag-entry"
  entitlement:
    description: |
      Metadata for entitlement group.
      ###### Related Nodes
      - TO generic-vnf( entitlement BelongsTo generic-vnf, MANY2ONE, will delete target node)(4)
      - TO vce( entitlement BelongsTo vce, MANY2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this ENTITLEMENT is DELETED also
    required:
    - group-uuid
    - resource-uuid
    properties:
      group-uuid:
        type: string
        description: Unique ID for the entitlement group the resource comes from, should be uuid.
      resource-uuid:
        type: string
        description: Unique ID of an entitlement resource. 
  entitlements:
    description: |
      Entitlements, keyed by group-uuid and resource-uuid, related to license management
    properties:
      entitlement:
        type: array
        items:          
          $ref: "#/definitions/entitlement"
  evc:
    description: |
      evc object is an optional child object of the Configuration object.
      ###### Related Nodes
      - TO configuration( evc BelongsTo configuration, ONE2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this EVC is DELETED also
    required:
    - evc-id
    properties:
      evc-id:
        type: string
        description: Unique/key field for the evc object
      forwarding-path-topology:
        type: string
        description: Point-to-Point, Multi-Point
      cir-value:
        type: string
        description: Commited Information Rate
      cir-units:
        type: string
        description: CIR units
      connection-diversity-group-id:
        type: string
        description: Diversity Group ID
      service-hours:
        type: string
        description: formerly Performance Group
      esp-evc-circuit-id:
        type: string
        description: EVC Circuit ID of ESP EVC
      esp-evc-cir-value:
        type: string
        description: Committed Information Rate (For ESP)
      esp-evc-cir-units:
        type: string
        description: CIR units (For ESP)
      esp-itu-code:
        type: string
        description: Identifies ESP
      collector-pop-clli:
        type: string
        description: Collector POP CLLI (from the hostname of the access pnf)
      inter-connect-type-ingress:
        type: string
        description: Interconnect type on ingress side of EVC.
      tagmode-access-ingress:
        type: string
        description: tagode for collector side of EVC
      tagmode-access-egress:
        type: string
        description: tagMode for network side of EVC
  evcs:
    properties:
      evc:
        type: array
        items:          
          $ref: "#/definitions/evc"
  forwarder:
    description: |
      Entity describing a sequenced segment of forwarding path
      ###### Related Nodes
      - TO forwarding-path( forwarder BelongsTo forwarding-path, MANY2ONE, will delete target node)(4)
      - TO l-interface( forwarder ForwardsTo l-interface, MANY2MANY, will delete target node)
      - TO configuration( forwarder Uses configuration, ONE2ONE, will delete target node)(2)
      - TO lag-interface( forwarder ForwardsTo lag-interface, MANY2MANY, will delete target node)
      - TO p-interface( forwarder ForwardsTo p-interface, MANY2MANY, will delete target node)

      -(2) IF this FORWARDER node is deleted, this TO node is DELETED also
      -(4) IF this TO node is deleted, this FORWARDER is DELETED also
    required:
    - sequence
    properties:
      sequence:
        type: integer
        format: int32
        description: Unique ID of this segmentation
      forwarder-role:
        type: string
        description: ingress, intermediate, egress
  forwarder-evc:
    description: |
      forwarder object is an optional child object of the Configuration object.
      ###### Related Nodes
      - TO configuration( forwarder-evc BelongsTo configuration, ONE2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this FORWARDER-EVC is DELETED also
    required:
    - forwarder-evc-id
    properties:
      forwarder-evc-id:
        type: string
        description: Key for forwarder-evc object
      circuit-id:
        type: string
        description: Circuit ID from customer/ESP/ingress end of EVC, or reference to beater circuit on gateway/network/egress end of EVC
      ivlan:
        type: string
        description: Internal VLAN.
      svlan:
        type: string
        description: SVLAN value for ingress of egress forwarder.
      cvlan:
        type: string
        description: CVLAN value for ingress of egress forwarder.
  forwarder-evcs:
    properties:
      forwarder-evc:
        type: array
        items:          
          $ref: "#/definitions/forwarder-evc"
  forwarders:
    properties:
      forwarder:
        type: array
        items:          
          $ref: "#/definitions/forwarder"
  forwarding-path:
    description: |
      Entity that describes the sequenced forwarding path between interfaces of services or resources
      ###### Related Nodes
      - TO service-instance( forwarding-path AppliesTo service-instance, MANY2ONE, will delete target node)(4)
      - TO configuration( forwarding-path Uses configuration, ONE2ONE, will delete target node)(2)
      - FROM forwarder( forwarder BelongsTo forwarding-path, MANY2ONE, will delete target node)(1)

      -(1) IF this FORWARDING-PATH node is deleted, this FROM node is DELETED also
      -(2) IF this FORWARDING-PATH node is deleted, this TO node is DELETED also
      -(4) IF this TO node is deleted, this FORWARDING-PATH is DELETED also
    required:
    - forwarding-path-id
    - forwarding-path-name
    properties:
      forwarding-path-id:
        type: string
        description: Unique ID of this FP
      forwarding-path-name:
        type: string
        description: Name of the FP
  forwarding-paths:
    properties:
      forwarding-path:
        type: array
        items:          
          $ref: "#/definitions/forwarding-path"
  generic-vnf:
    description: |
      General purpose VNF
      ###### Related Nodes
      - TO availability-zone( generic-vnf Uses availability-zone, MANY2MANY, will delete target node)
      - TO complex( generic-vnf LocatedIn complex, MANY2MANY, will delete target node)
      - TO configuration( generic-vnf Uses configuration, ONE2MANY, will delete target node)(2)
      - TO ctag-pool( generic-vnf Uses ctag-pool, MANY2MANY, will delete target node)
      - TO instance-group( generic-vnf MemberOf instance-group, MANY2MANY, will delete target node)
      - TO ipsec-configuration( generic-vnf Uses ipsec-configuration, MANY2ONE, will delete target node)
      - TO l3-network( generic-vnf Uses l3-network, MANY2MANY, will delete target node)
      - TO pnf( generic-vnf HostedOn pnf, MANY2MANY, will delete target node)
      - TO pserver( generic-vnf HostedOn pserver, MANY2MANY, will delete target node)
      - TO vnf-image( generic-vnf Uses vnf-image, MANY2ONE, will delete target node)
      - TO volume-group( generic-vnf DependsOn volume-group, ONE2MANY, will delete target node)
      - TO vserver( generic-vnf HostedOn vserver, ONE2MANY, will delete target node)
      - TO virtual-data-center( generic-vnf LocatedIn virtual-data-center, MANY2MANY, will delete target node)
      - TO model-ver( generic-vnf IsA model-ver, Many2One, will delete target node)
      - TO nos-server( generic-vnf HostedOn nos-server, MANY2ONE, will delete target node)(4)
      - FROM allotted-resource( allotted-resource PartOf generic-vnf, MANY2MANY, will delete target node)
      - FROM entitlement( entitlement BelongsTo generic-vnf, MANY2ONE, will delete target node)(1)
      - FROM vnfc( vnfc BelongsTo generic-vnf, MANY2ONE, will delete target node)(1)
      - FROM lag-interface( lag-interface BelongsTo generic-vnf, MANY2ONE, will delete target node)(1)
      - FROM license( license BelongsTo generic-vnf, MANY2ONE, will delete target node)(1)
      - FROM l-interface( l-interface BelongsTo generic-vnf, MANY2ONE, will delete target node)(1)
      - FROM network-profile( network-profile AppliesTo generic-vnf, MANY2MANY, will delete target node)
      - FROM service-instance( service-instance ComposedOf generic-vnf, ONE2MANY, will delete target node)
      - FROM site-pair-set( site-pair-set AppliesTo generic-vnf, MANY2MANY, will delete target node)
      - FROM vf-module( vf-module BelongsTo generic-vnf, MANY2ONE, will delete target node)(1)
      - FROM line-of-business( line-of-business Uses generic-vnf, MANY2MANY, will delete target node)
      - FROM logical-link( logical-link BridgedTo generic-vnf, MANY2MANY, will delete target node)
      - FROM platform( platform Uses generic-vnf, MANY2MANY, will delete target node)
      - FROM configuration( configuration PartOf generic-vnf, MANY2ONE, will delete target node)

      -(1) IF this GENERIC-VNF node is deleted, this FROM node is DELETED also
      -(2) IF this GENERIC-VNF node is deleted, this TO node is DELETED also
      -(4) IF this TO node is deleted, this GENERIC-VNF is DELETED also
    required:
    - vnf-id
    - vnf-name
    - vnf-type
    - in-maint
    - is-closed-loop-disabled
    properties:
      vnf-id:
        type: string
        description: Unique id of VNF.  This is unique across the graph.
      vnf-name:
        type: string
        description: Name of VNF.
      vnf-name2:
        type: string
        description: Alternate name of VNF.
      vnf-type:
        type: string
        description: String capturing type of vnf, that was intended to identify the ASDC resource.  This field has been overloaded in service-specific ways and clients should expect changes to occur in the future to this field as ECOMP matures.
      service-id:
        type: string
        description: Unique identifier of service, does not necessarily map to ASDC service models.  SOON TO BE DEPRECATED
      regional-resource-zone:
        type: string
        description: Regional way of organizing pservers, source of truth should define values
      prov-status:
        type: string
        description: Trigger for operational monitoring of this resource by Service Assurance systems.
      operational-status:
        type: string
        description: Indicator for whether the resource is considered operational.  Valid values are in-service-path and out-of-service-path.
      license-key:
        type: string
        description: OBSOLETE -  do not use
      equipment-role:
        type: string
        description: Client should send valid enumerated value
      orchestration-status:
        type: string
        description: Orchestration status of this VNF, used by MSO.
      heat-stack-id:
        type: string
        description: Heat stack id corresponding to this instance, managed by MSO
      mso-catalog-key:
        type: string
        description: Corresponds to the SDN-C catalog id used to configure this VCE
      management-option:
        type: string
        description: identifier of managed by ATT or customer
      ipv4-oam-address:
        type: string
        description: Address tail-f uses to configure generic-vnf, also used for troubleshooting and is IP used for traps generated by generic-vnf.
      ipv4-loopback0-address:
        type: string
        description: v4 Loopback0 address
      nm-lan-v6-address:
        type: string
        description: v6 Loopback address
      management-v6-address:
        type: string
        description: v6 management address
      vcpu:
        type: integer
        format: int64
        description: number of vcpus ordered for this instance of VNF, used for VNFs with no vservers/flavors, to be used only by uCPE
      vcpu-units:
        type: string
        description: units associated with vcpu, used for VNFs with no vservers/flavors, to be used only by uCPE
      vmemory:
        type: integer
        format: int64
        description: number of GB of memory ordered for this instance of VNF, used for VNFs with no vservers/flavors, to be used only by uCPE
      vmemory-units:
        type: string
        description: units associated with vmemory, used for VNFs with no vservers/flavors, to be used only by uCPE
      vdisk:
        type: integer
        format: int64
        description: number of vdisks ordered for this instance of VNF, used for VNFs with no vservers/flavors, to be used only uCPE
      vdisk-units:
        type: string
        description: units associated with vdisk, used for VNFs with no vservers/flavors, to be used only by uCPE
      in-maint:
        type: boolean
        description: used to indicate whether or not this object is in maintenance mode (maintenance mode = true). This field (in conjunction with prov-status) is used to suppress alarms and vSCL on VNFs/VMs.
      is-closed-loop-disabled:
        type: boolean
        description: used to indicate whether closed loop function is enabled on this node
  generic-vnfs:
    description: |
      Collection of VNFs
    properties:
      generic-vnf:
        type: array
        items:          
          $ref: "#/definitions/generic-vnf"
  host-route:
    description: |
      ###### Related Nodes
      - TO subnet( host-route BelongsTo subnet, MANY2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this HOST-ROUTE is DELETED also
    required:
    - host-route-id
    - route-prefix
    - next-hop
    properties:
      host-route-id:
        type: string
        description: host-route id
      route-prefix:
        type: string
        description: subnet prefix
      next-hop:
        type: string
        description: Could be ip-address, hostname, or service-instance
      next-hop-type:
        type: string
        description: Should be ip-address, hostname, or service-instance to match next-hop
  host-routes:
    properties:
      host-route:
        type: array
        items:          
          $ref: "#/definitions/host-route"
  instance-group:
    description: |
      General mechanism for grouping instances
      ###### Related Nodes
      - TO model( instance-group Targets model, MANY2MANY, will delete target node)
      - FROM allotted-resource( allotted-resource MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM generic-vnf( generic-vnf MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM l3-interface-ipv4-address-list( l3-interface-ipv4-address-list MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM l3-interface-ipv6-address-list( l3-interface-ipv6-address-list MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM l3-network( l3-network MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM l-interface( l-interface MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM pnf( pnf MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM service-instance( service-instance MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM vip-ipv4-address-list( vip-ipv4-address-list MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM vip-ipv6-address-list( vip-ipv6-address-list MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM vnfc( vnfc MemberOf instance-group, MANY2MANY, will delete target node)
      - FROM tenant( tenant MemberOf instance-group, ONE2MANY, will delete target node)

    required:
    - id
    - description
    - type
    properties:
      instance-group-role:
        type: string
        description: role of the instance group.
      model-invariant-id:
        type: string
        description: ASDC model id for this resource or service model.
      model-version-id:
        type: string
        description: ASDC model version uid for this resource model.
      id:
        type: string
        description: Instance Group ID, UUID assigned to this instance.
      description:
        type: string
        description: Descriptive text to help identify the usage of this instance-group
      type:
        type: string
        description: Only valid value today is lower case ha for high availability
      sub-type:
        type: string
        description: Valid values for ha type are [geo-activeactive, geo-activestandby, local-activeactive, local-activestandby]
  instance-groups:
    description: |
      Collection of openstack route table references
    properties:
      instance-group:
        type: array
        items:          
          $ref: "#/definitions/instance-group"
  ipsec-configuration:
    description: |
      IPSec configuration node will contain various configuration data for the NMTE VNF. This node will have an edge to the generic-vnf (vnf type = TE). Starting 1607, this data will be populated by SDN-C
      ###### Related Nodes
      - FROM generic-vnf( generic-vnf Uses ipsec-configuration, MANY2ONE, will delete target node)
      - FROM vig-server( vig-server BelongsTo ipsec-configuration, MANY2ONE, will delete target node)(1)

      -(1) IF this IPSEC-CONFIGURATION node is deleted, this FROM node is DELETED also
    required:
    - ipsec-configuration-id
    properties:
      ipsec-configuration-id:
        type: string
        description: UUID of this configuration
      requested-vig-address-type:
        type: string
        description: Indicate the type of VIG server like AVPN, INTERNET, BOTH
      requested-encryption-strength:
        type: string
        description: Encryption values like 3des-cbc, des-cbc, aes-128-cbc, aes-192-cbc, aes-265-cbc
      requested-dmz-type:
        type: string
        description: ATT can offer a shared DMZ or a DMZ specific to a customer
      shared-dmz-network-address:
        type: string
        description: Network address of shared DMZ
      requested-customer-name:
        type: string
        description: If the DMZ is a custom DMZ, this field will indicate the customer information
      ike-version:
        type: string
        description: can be 1 or 2
      ikev1-authentication:
        type: string
        description: Contains values like md5, sha1, sha256, sha384
      ikev1-encryption:
        type: string
        description: Encyption values like 3des-cbc, des-cbc, aes-128-cbc,Â aes-192-cbc, aes-265-cbc
      ikev1-dh-group:
        type: string
        description: Diffie-Hellman group like DH-GROUP2, DH-GROUP5, DH-GROUP14
      ikev1-am-group-id:
        type: string
        description: Group name defined in VIG for clients using aggressive mode
      ikev1-am-password:
        type: string
        description: pre-shared key for the above group name 
      ikev1-sa-lifetime:
        type: string
        description: Lifetime for IKEv1 SA
      ipsec-authentication:
        type: string
        description: md5, sha1, sha256, sha384
      ipsec-encryption:
        type: string
        description: 3des-cbc, des-cbc, aes-128-cbc,Â aes-192-cbc, aes-265-cbc
      ipsec-sa-lifetime:
        type: string
        description: Life time for IPSec SA
      ipsec-pfs:
        type: string
        description: enable PFS or not
      xauth-userid:
        type: string
        description: user ID for xAuth, sm-user,ucpeHostName,nmteHostName
      xauth-user-password:
        type: string
        description: Encrypted using the Juniper $9$ algorithm
      dpd-interval:
        type: string
        description: The time between DPD probe
      dpd-frequency:
        type: string
        description: Maximum number of DPD before claiming the tunnel is down
  ipsec-configurations:
    properties:
      ipsec-configuration:
        type: array
        items:          
          $ref: "#/definitions/ipsec-configuration"
  l-interface:
    description: |
      Logical interfaces, e.g., a vnic.
      ###### Related Nodes
      - TO generic-vnf( l-interface BelongsTo generic-vnf, MANY2ONE, will delete target node)(4)
      - TO lag-interface( l-interface BelongsTo lag-interface, MANY2ONE, will delete target node)(4)
      - TO instance-group( l-interface MemberOf instance-group, MANY2MANY, will delete target node)
      - TO l-interface( l-interface BelongsTo l-interface, MANY2ONE, will delete target node)(4)
      - TO logical-link( l-interface LinksTo logical-link, MANY2MANY, will delete target node)(2)
      - TO newvce( l-interface BelongsTo newvce, MANY2ONE, will delete target node)(4)
      - TO p-interface( l-interface BindsTo p-interface, MANY2ONE, will delete target node)(4)
      - TO vserver( l-interface BindsTo vserver, MANY2ONE, will delete target node)(4)
      - FROM allotted-resource( allotted-resource Uses l-interface, ONE2MANY, will delete target node)
      - FROM lag-interface( lag-interface Uses l-interface, ONE2MANY, will delete target node)
      - FROM l3-interface-ipv4-address-list( l3-interface-ipv4-address-list BelongsTo l-interface, MANY2ONE, will delete target node)(1)
      - FROM l3-interface-ipv6-address-list( l3-interface-ipv6-address-list BelongsTo l-interface, MANY2ONE, will delete target node)(1)
      - FROM logical-link( logical-link Source l-interface, ONE2MANY, will delete target node)(1)
      - FROM logical-link( logical-link Destination l-interface, ONE2MANY, will delete target node)(1)
      - FROM sriov-vf( sriov-vf BelongsTo l-interface, ONE2ONE, will delete target node)(1)
      - FROM vlan( vlan LinksTo l-interface, MANY2ONE, will delete target node)(1)
      - FROM configuration( configuration AppliesTo l-interface, ONE2MANY, will delete target node)
      - FROM forwarder( forwarder ForwardsTo l-interface, MANY2MANY, will delete target node)
      - FROM l-interface( l-interface BelongsTo l-interface, MANY2ONE, will delete target node)(4)

      -(1) IF this L-INTERFACE node is deleted, this FROM node is DELETED also
      -(2) IF this L-INTERFACE node is deleted, this TO node is DELETED also
      -(4) IF this TO node is deleted, this L-INTERFACE is DELETED also
    required:
    - interface-name
    - is-port-mirrored
    - in-maint
    - is-ip-unnumbered
    properties:
      interface-name:
        type: string
        description: Name given to the interface
      interface-role:
        type: string
        description: E.g., CUSTOMER, UPLINK, etc.
      v6-wan-link-ip:
        type: string
        description: Questionably placed - v6 ip addr of this interface (is in vr-lan-interface from Mary B.
      selflink:
        type: string
        description: URL to endpoint where AAI can get more details
      interface-id:
        type: string
        description: ID of interface
      macaddr:
        type: string
        description: MAC address for the interface
      network-name:
        type: string
        description: Name of the network
      management-option:
        type: string
        description: Whether A&AI should be managing this interface of not. Could have value like CUSTOMER
      interface-description:
        type: string
        description: Human friendly text regarding this interface.
      is-port-mirrored:
        type: boolean
        description: boolean indicatating whether or not port is a mirrored.
  l-interfaces:
    description: |
      Collection of logical interfaces.
    properties:
      l-interface:
        type: array
        items:          
          $ref: "#/definitions/l-interface"
  l3-interface-ipv4-address-list:
    description: |
      IPv4 Address Range
      ###### Related Nodes
      - TO instance-group( l3-interface-ipv4-address-list MemberOf instance-group, MANY2MANY, will delete target node)
      - TO l3-network( l3-interface-ipv4-address-list MemberOf l3-network, MANY2MANY, will delete target node)
      - TO subnet( l3-interface-ipv4-address-list MemberOf subnet, MANY2MANY, will delete target node)
      - TO l-interface( l3-interface-ipv4-address-list BelongsTo l-interface, MANY2ONE, will delete target node)(4)
      - TO vlan( l3-interface-ipv4-address-list BelongsTo vlan, MANY2ONE, will delete target node)(4)
      - TO vnfc( l3-interface-ipv4-address-list BelongsTo vnfc, MANY2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this L3-INTERFACE-IPV4-ADDRESS-LIST is DELETED also
    required:
    - l3-interface-ipv4-address
    properties:
      l3-interface-ipv4-address:
        type: string
        description: IP address
      l3-interface-ipv4-prefix-length:
        type: integer
        format: int64
        description: Prefix length, 32 for single address
      vlan-id-inner:
        type: integer
        format: int64
        description: Inner VLAN tag
      vlan-id-outer:
        type: integer
        format: int64
        description: Outer VLAN tag
      is-floating:
        type: boolean
        description: Indicator of fixed or floating address
  l3-interface-ipv6-address-list:
    description: |
      IPv6 Address Range
      ###### Related Nodes
      - TO instance-group( l3-interface-ipv6-address-list MemberOf instance-group, MANY2MANY, will delete target node)
      - TO l3-network( l3-interface-ipv6-address-list MemberOf l3-network, MANY2MANY, will delete target node)
      - TO subnet( l3-interface-ipv6-address-list MemberOf subnet, MANY2MANY, will delete target node)
      - TO l-interface( l3-interface-ipv6-address-list BelongsTo l-interface, MANY2ONE, will delete target node)(4)
      - TO vlan( l3-interface-ipv6-address-list BelongsTo vlan, MANY2ONE, will delete target node)(4)
      - TO vnfc( l3-interface-ipv6-address-list BelongsTo vnfc, MANY2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this L3-INTERFACE-IPV6-ADDRESS-LIST is DELETED also
    required:
    - l3-interface-ipv6-address
    properties:
      l3-interface-ipv6-address:
        type: string
        description: IP address
      l3-interface-ipv6-prefix-length:
        type: integer
        format: int64
        description: Prefix length, 128 for single address
      vlan-id-inner:
        type: integer
        format: int64
        description: Inner VLAN tag
      vlan-id-outer:
        type: integer
        format: int64
        description: Outer VLAN tag
      is-floating:
        type: boolean
        description: Indicator of fixed or floating address
  l3-network:
    description: |
      Generic network definition
      ###### Related Nodes
      - TO instance-group( l3-network MemberOf instance-group, MANY2MANY, will delete target node)
      - TO network-policy( l3-network Uses network-policy, MANY2MANY, will delete target node)
      - TO route-table-reference( l3-network Uses route-table-reference, MANY2MANY, will delete target node)
      - TO vpn-binding( l3-network Uses vpn-binding, MANY2MANY, will delete target node)
      - TO model-ver( l3-network IsA model-ver, Many2One, will delete target node)
      - FROM allotted-resource( allotted-resource PartOf l3-network, MANY2MANY, will delete target node)
      - FROM cloud-region( cloud-region Uses l3-network, MANY2MANY, will delete target node)
      - FROM complex( complex Uses l3-network, MANY2MANY, will delete target node)
      - FROM generic-vnf( generic-vnf Uses l3-network, MANY2MANY, will delete target node)
      - FROM l3-interface-ipv4-address-list( l3-interface-ipv4-address-list MemberOf l3-network, MANY2MANY, will delete target node)
      - FROM l3-interface-ipv6-address-list( l3-interface-ipv6-address-list MemberOf l3-network, MANY2MANY, will delete target node)
      - FROM ctag-assignment( ctag-assignment BelongsTo l3-network, MANY2ONE, will delete target node)(1)
      - FROM segmentation-assignment( segmentation-assignment BelongsTo l3-network, MANY2ONE, will delete target node)(1)
      - FROM service-instance( service-instance ComposedOf l3-network, ONE2MANY, will delete target node)
      - FROM subnet( subnet BelongsTo l3-network, MANY2ONE, will delete target node)(1)
      - FROM tenant( tenant Uses l3-network, MANY2MANY, will delete target node)
      - FROM vf-module( vf-module DependsOn l3-network, MANY2MANY, will delete target node)
      - FROM configuration( configuration PartOf l3-network, ONE2ONE, will delete target node)

      -(1) IF this L3-NETWORK node is deleted, this FROM node is DELETED also
    required:
    - network-id
    - network-name
    - is-bound-to-vpn
    - is-provider-network
    - is-shared-network
    - is-external-network
    properties:
      network-id:
        type: string
        description: Network ID, should be uuid. Unique across A&AI.
      network-name:
        type: string
        description: Name of the network, governed by some naming convention..
      network-type:
        type: string
        description: Type of the network - who defines these values?
      network-role:
        type: string
        description: Role the network plans - who defines these values?
      network-technology:
        type: string
        description: Network technology - who defines these values?
      neutron-network-id:
        type: string
        description: Neutron network id of this Interface
      is-bound-to-vpn:
        type: boolean
        description: Set to true if bound to VPN
      service-id:
        type: string
        description: Unique identifier of service from ASDC.  Does not strictly map to ASDC services.  SOON TO BE DEPRECATED
      network-role-instance:
        type: integer
        format: int64
        description: network role instance
  l3-networks:
    properties:
      l3-network:
        type: array
        items:          
          $ref: "#/definitions/l3-network"
  lag-interface:
    description: |
      Link aggregate interface
      ###### Related Nodes
      - TO generic-vnf( lag-interface BelongsTo generic-vnf, MANY2ONE, will delete target node)(4)
      - TO lag-link( lag-interface LinksTo lag-link, MANY2MANY, will delete target node)(2)
      - TO logical-link( lag-interface Uses logical-link, MANY2MANY, will delete target node)(2)
      - TO p-interface( lag-interface Uses p-interface, MANY2MANY, will delete target node)
      - TO l-interface( lag-interface Uses l-interface, ONE2MANY, will delete target node)
      - TO pnf( lag-interface BindsTo pnf, MANY2ONE, will delete target node)(4)
      - TO pserver( lag-interface BindsTo pserver, MANY2ONE, will delete target node)(4)
      - TO vpls-pe( lag-interface BindsTo vpls-pe, MANY2ONE, will delete target node)(4)
      - FROM l-interface( l-interface BelongsTo lag-interface, MANY2ONE, will delete target node)(1)
      - FROM forwarder( forwarder ForwardsTo lag-interface, MANY2MANY, will delete target node)

      -(1) IF this LAG-INTERFACE node is deleted, this FROM node is DELETED also
      -(2) IF this LAG-INTERFACE node is deleted, this TO node is DELETED also
      -(4) IF this TO node is deleted, this LAG-INTERFACE is DELETED also
    required:
    - interface-name
    - in-maint
    properties:
      interface-name:
        type: string
        description: Name that identifies the link aggregate interface
      interface-description:
        type: string
        description: Human friendly text regarding this interface.
  lag-interfaces:
    description: |
      Collection of link aggregate interfaces.
    properties:
      lag-interface:
        type: array
        items:          
          $ref: "#/definitions/lag-interface"
  lag-link:
    description: |
      LAG links can connect lag-interfaces
      ###### Related Nodes
      - FROM lag-interface( lag-interface LinksTo lag-link, MANY2MANY, will delete target node)(3)
      - FROM logical-link( logical-link Uses lag-link, MANY2MANY, will delete target node)

      -(3) IF this FROM node is deleted, this LAG-LINK is DELETED also
    required:
    - link-name
    properties:
      link-name:
        type: string
        description: Alphabetical concatenation of lag-interface names
  lag-links:
    description: |
      Collection of link aggregation connections
    properties:
      lag-link:
        type: array
        items:          
          $ref: "#/definitions/lag-link"
  license:
    description: |
      Metadata for license group.
      ###### Related Nodes
      - TO generic-vnf( license BelongsTo generic-vnf, MANY2ONE, will delete target node)(4)
      - TO vce( license BelongsTo vce, MANY2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this LICENSE is DELETED also
    required:
    - group-uuid
    - resource-uuid
    properties:
      group-uuid:
        type: string
        description: Unique ID for the license group the resource belongs to, should be uuid.
      resource-uuid:
        type: string
        description: Unique ID of a license resource. 
  licenses:
    description: |
      Licenses to be allocated across resources, keyed by group-uuid and resource-uuid, related to license management
    properties:
      license:
        type: array
        items:          
          $ref: "#/definitions/license"
  logical-link:
    description: |
      Logical links generally connect l-interfaces but are used to express logical connectivity between two points
      ###### Related Nodes
      - TO l-interface( logical-link Source l-interface, ONE2MANY, will delete target node)(4)
      - TO l-interface( logical-link Destination l-interface, ONE2MANY, will delete target node)(4)
      - TO cloud-region( logical-link LocatedIn cloud-region, MANY2MANY, will delete target node)
      - TO generic-vnf( logical-link BridgedTo generic-vnf, MANY2MANY, will delete target node)
      - TO lag-link( logical-link Uses lag-link, MANY2MANY, will delete target node)
      - TO logical-link( logical-link Uses logical-link, MANY2MANY, will delete target node)
      - TO pnf( logical-link BridgedTo pnf, MANY2MANY, will delete target node)
      - TO pserver( logical-link BridgedTo pserver, MANY2MANY, will delete target node)
      - TO vpn-binding( logical-link Uses vpn-binding, MANY2MANY, will delete target node)
      - TO virtual-data-center( logical-link LocatedIn virtual-data-center, MANY2MANY, will delete target node)
      - TO model-ver( logical-link IsA model-ver, Many2One, will delete target node)
      - FROM configuration( configuration Uses logical-link, ONE2MANY, will delete target node)(3)
      - FROM lag-interface( lag-interface Uses logical-link, MANY2MANY, will delete target node)(3)
      - FROM l-interface( l-interface LinksTo logical-link, MANY2MANY, will delete target node)(3)
      - FROM p-interface( p-interface LinksTo logical-link, MANY2ONE, will delete target node)
      - FROM service-instance( service-instance Uses logical-link, ONE2MANY, will delete target node)(3)
      - FROM vlan( vlan Uses logical-link, MANY2MANY, will delete target node)(3)
      - FROM logical-link( logical-link Uses logical-link, MANY2MANY, will delete target node)

      -(3) IF this FROM node is deleted, this LOGICAL-LINK is DELETED also
      -(4) IF this TO node is deleted, this LOGICAL-LINK is DELETED also
    required:
    - link-name
    - in-maint
    - link-type
    properties:
      link-name:
        type: string
        description: e.g., evc-name, or vnf-nameA_interface-nameA_vnf-nameZ_interface-nameZ
      in-maint:
        type: boolean
        description: used to indicate whether or not this object is in maintenance mode (maintenance mode = true). This field (in conjunction with prov-status) is used to suppress alarms and vSCL on VNFs/VMs.
      link-type:
        type: string
        description: Type of logical link, e.g., evc
      speed-value:
        type: string
        description: Captures the numeric part of the speed
      speed-units:
        type: string
        description: Captures the units corresponding to the speed
      ip-version:
        type: string
        description: v4, v6, or ds for dual stack (should be att-ip-version)
      routing-protocol:
        type: string
        description: For example, static or BGP
  logical-links:
    description: |
      Collection of logical connections
    properties:
      logical-link:
        type: array
        items:          
          $ref: "#/definitions/logical-link"
  metadata:
    description: |
      Collection of metadatum (key/value pairs)
    properties:
      metadatum:
        type: array
        items:          
          $ref: "#/definitions/metadatum"
  metadatum:
    description: |
      Key/value pairs
      ###### Related Nodes
      - TO configuration( metadatum BelongsTo configuration, MANY2ONE, will delete target node)(4)
      - TO connector( metadatum BelongsTo connector, MANY2ONE, will delete target node)(4)
      - TO image( metadatum BelongsTo image, MANY2ONE, will delete target node)(4)
      - TO model-ver( metadatum BelongsTo model-ver, MANY2ONE, will delete target node)(4)
      - TO service-instance( metadatum BelongsTo service-instance, MANY2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this METADATUM is DELETED also
    required:
    - metaname
    - metaval
    properties:
      metaname:
        type: string
      metaval:
        type: string
  multicast-configuration:
    description: |
      ###### Related Nodes
      - FROM vlan( vlan Uses multicast-configuration, MANY2MANY, will delete target node)

    required:
    - multicast-configuration-id
    - multicast-protocol
    - rp-type
    properties:
      multicast-configuration-id:
        type: string
        description: Unique id of multicast configuration.
      multicast-protocol:
        type: string
        description: protocol of multicast configuration
      rp-type:
        type: string
        description: rp type of multicast configuration
  multicast-configurations:
    description: |
      multicast configuration of generic-vnf ip-address
    properties:
      multicast-configuration:
        type: array
        items:          
          $ref: "#/definitions/multicast-configuration"
  network:
    description: |
      Namespace for network inventory resources.
    properties:
      logical-links:
        type: array
        items:
          $ref: "#/definitions/logical-link"
      site-pair-sets:
        type: array
        items:
          $ref: "#/definitions/site-pair-set"
      vpn-bindings:
        type: array
        items:
          $ref: "#/definitions/vpn-binding"
      vpls-pes:
        type: array
        items:
          $ref: "#/definitions/vpls-pe"
      multicast-configurations:
        type: array
        items:
          $ref: "#/definitions/multicast-configuration"
      vces:
        type: array
        items:
          $ref: "#/definitions/vce"
      vnfcs:
        type: array
        items:
          $ref: "#/definitions/vnfc"
      l3-networks:
        type: array
        items:
          $ref: "#/definitions/l3-network"
      network-policies:
        type: array
        items:
          $ref: "#/definitions/network-policy"
      generic-vnfs:
        type: array
        items:
          $ref: "#/definitions/generic-vnf"
      lag-links:
        type: array
        items:
          $ref: "#/definitions/lag-link"
      newvces:
        type: array
        items:
          $ref: "#/definitions/newvce"
      pnfs:
        type: array
        items:
          $ref: "#/definitions/pnf"
      physical-links:
        type: array
        items:
          $ref: "#/definitions/physical-link"
      ipsec-configurations:
        type: array
        items:
          $ref: "#/definitions/ipsec-configuration"
      route-table-references:
        type: array
        items:
          $ref: "#/definitions/route-table-reference"
      instance-groups:
        type: array
        items:
          $ref: "#/definitions/instance-group"
      zones:
        type: array
        items:
          $ref: "#/definitions/zone"
      configurations:
        type: array
        items:
          $ref: "#/definitions/configuration"
      forwarding-paths:
        type: array
        items:
          $ref: "#/definitions/forwarding-path"
  network-policies:
    properties:
      network-policy:
        type: array
        items:          
          $ref: "#/definitions/network-policy"
  network-policy:
    description: |
      ###### Related Nodes
      - FROM allotted-resource( allotted-resource Uses network-policy, ONE2ONE, will delete target node)
      - FROM l3-network( l3-network Uses network-policy, MANY2MANY, will delete target node)

    required:
    - network-policy-id
    properties:
      network-policy-id:
        type: string
        description: UUID representing unique key to this instance
      network-policy-fqdn:
        type: string
        description: Contrail FQDN for the policy
      heat-stack-id:
        type: string
        description: ID for the openStack Heat instance
  newvce:
    description: |
      This object fills in the gaps from vce that were incorporated into generic-vnf.  This object will be retired with vce.
      ###### Related Nodes
      - FROM l-interface( l-interface BelongsTo newvce, MANY2ONE, will delete target node)(1)

      -(1) IF this NEWVCE node is deleted, this FROM node is DELETED also
    required:
    - vnf-id2
    - vnf-name
    - vnf-type
    properties:
      vnf-id2:
        type: string
        description: Unique id of VNF, can't use same attribute name right now until we promote this new object
      vnf-name:
        type: string
        description: Name of VNF.
      vnf-name2:
        type: string
        description: Alternate name of VNF.
      vnf-type:
        type: string
        description: String capturing type of vnf, that was intended to identify the ASDC resource.  This field has been overloaded in service-specific ways and clients should expect changes to occur in the future to this field as ECOMP matures.
      prov-status:
        type: string
        description: Trigger for operational monitoring of this VNF by BAU Service Assurance systems.
      operational-status:
        type: string
        description: Indicator for whether the resource is considered operational
      license-key:
        type: string
        description: OBSOLETE -  do not use
      ipv4-oam-address:
        type: string
        description: Address tail-f uses to configure generic-vnf, also used for troubleshooting and is IP used for traps generated by GenericVnf (v4-loopback0-ip-address).
      equipment-role:
        type: string
        description: Client should send valid enumerated value.
  newvces:
    description: |
      This object fills in the gaps from vce that were incorporated into generic-vnf.  This object will be retired with vce.
    properties:
      newvce:
        type: array
        items:          
          $ref: "#/definitions/newvce"
  p-interface:
    description: |
      Physical interface (e.g., nic)
      ###### Related Nodes
      - TO logical-link( p-interface LinksTo logical-link, MANY2ONE, will delete target node)
      - TO physical-link( p-interface LinksTo physical-link, MANY2ONE, will delete target node)(2)
      - TO pnf( p-interface BindsTo pnf, MANY2ONE, will delete target node)(4)
      - TO pserver( p-interface BindsTo pserver, MANY2ONE, will delete target node)(4)
      - TO vpls-pe( p-interface BindsTo vpls-pe, MANY2ONE, will delete target node)(4)
      - FROM lag-interface( lag-interface Uses p-interface, MANY2MANY, will delete target node)
      - FROM l-interface( l-interface BindsTo p-interface, MANY2ONE, will delete target node)(1)
      - FROM sriov-pf( sriov-pf BelongsTo p-interface, ONE2ONE, will delete target node)(1)
      - FROM forwarder( forwarder ForwardsTo p-interface, MANY2MANY, will delete target node)

      -(1) IF this P-INTERFACE node is deleted, this FROM node is DELETED also
      -(2) IF this P-INTERFACE node is deleted, this TO node is DELETED also
      -(4) IF this TO node is deleted, this P-INTERFACE is DELETED also
    required:
    - interface-name
    - in-maint
    properties:
      interface-name:
        type: string
        description: Name that identifies the physical interface
      selflink:
        type: string
        description: URL to endpoint where AAI can get more details.
      speed-value:
        type: string
        description: Captures the numeric part of the speed
      speed-units:
        type: string
        description: Captures the units corresponding to the speed
      port-description:
        type: string
        description: Nature of the services and connectivity on this port.
      equipment-identifier:
        type: string
        description: CLEI or other specification for p-interface hardware.
      interface-role:
        type: string
        description: Role specification for p-interface hardware.
      interface-type:
        type: string
        description: Indicates the physical properties of the interface.
      prov-status:
        type: string
        description: Trigger for operational monitoring of this resource by Service Assurance systems.
  p-interfaces:
    description: |
      Collection of physical interfaces.
    properties:
      p-interface:
        type: array
        items:          
          $ref: "#/definitions/p-interface"
  physical-link:
    description: |
      Collection of physical connections, typically between p-interfaces
      ###### Related Nodes
      - FROM p-interface( p-interface LinksTo physical-link, MANY2ONE, will delete target node)(3)

      -(3) IF this FROM node is deleted, this PHYSICAL-LINK is DELETED also
    required:
    - link-name
    properties:
      link-name:
        type: string
        description: e.g., hostnameA_p-connection_nameA_hostnameZ+p_connection-nameZ
      speed-value:
        type: string
        description: Captures the numeric part of the speed
      speed-units:
        type: string
        description: Captures the units corresponding to the speed
      circuit-id:
        type: string
        description: Circuit it
      dual-mode:
        type: string
        description: Dual access mode (e.g., primary, secondary
      management-option:
        type: string
        description: To provide information on who manages this circuit. A&AI or 3rd party transport provider
      service-provider-name:
        type: string
        description: Name of the service Provider on this link.
      service-provider-bandwidth-up-value:
        type: integer
        format: int32
        description: Upstream Bandwidth value agreed with the service provider
      service-provider-bandwidth-up-units:
        type: string
        description: Units for the upstream BW value
      service-provider-bandwidth-down-value:
        type: integer
        format: int32
        description: Downstream Bandwidth value agreed with the service provider
      service-provider-bandwidth-down-units:
        type: string
        description: Units for downstream BW value
  physical-links:
    description: |
      Collection of physical connections, typically between p-interfaces
    properties:
      physical-link:
        type: array
        items:          
          $ref: "#/definitions/physical-link"
  pnf:
    description: |
      PNF represents a physical network function. typically equipment used in the D1 world. in 1607, this will be populated by SDN-C to represent a premises router that a uCPE connects to. But this can be used to represent any physical device that is not an AIC node or uCPE.
      ###### Related Nodes
      - TO complex( pnf LocatedIn complex, MANY2ONE, will delete target node)
      - TO instance-group( pnf MemberOf instance-group, MANY2MANY, will delete target node)
      - TO zone( pnf LocatedIn zone, MANY2ONE, will delete target node)
      - FROM generic-vnf( generic-vnf HostedOn pnf, MANY2MANY, will delete target node)
      - FROM logical-link( logical-link BridgedTo pnf, MANY2MANY, will delete target node)
      - FROM lag-interface( lag-interface BindsTo pnf, MANY2ONE, will delete target node)(1)
      - FROM p-interface( p-interface BindsTo pnf, MANY2ONE, will delete target node)(1)
      - FROM service-instance( service-instance ComposedOf pnf, ONE2MANY, will delete target node)
      - FROM configuration( configuration AppliesTo pnf, ONE2MANY, will delete target node)
      - FROM configuration( configuration AppliesTo pnf, MANY2MANY, will delete target node)

      -(1) IF this PNF node is deleted, this FROM node is DELETED also
    required:
    - pnf-name
    - in-maint
    properties:
      pnf-name:
        type: string
        description: unique name of Physical Network Function.
      pnf-name2:
        type: string
        description: name of Physical Network Function.
      selflink:
        type: string
        description: URL to endpoint where AAI can get more details.
      pnf-name2-source:
        type: string
        description: source of name2
      pnf-id:
        type: string
        description: id of pnf
      equip-type:
        type: string
        description: Equipment type.  Source of truth should define valid values.
      equip-vendor:
        type: string
        description: Equipment vendor.  Source of truth should define valid values.
      equip-model:
        type: string
        description: Equipment model.  Source of truth should define valid values.
      management-option:
        type: string
        description: identifier of managed by ATT or customer
      ipaddress-v4-oam:
        type: string
        description: ipv4-oam-address with new naming convention for IP addresses
      sw-version:
        type: string
        description: sw-version is the version of SW for the hosted application on the PNF.
      in-maint:
        type: boolean
        description: Used to indicate whether or not this object is in maintenance mode (maintenance mode = true). This field (in conjunction with prov-status) is used to suppress alarms and vSCL on VNFs/VMs.
      frame-id:
        type: string
        description: ID of the physical frame (relay rack) where pnf is installed.
      serial-number:
        type: string
        description: Serial number of the device
      ipaddress-v4-loopback-0:
        type: string
        description: IPV4 Loopback 0 address
      ipaddress-v6-loopback-0:
        type: string
        description: IPV6 Loopback 0 address
      ipaddress-v4-aim:
        type: string
        description: IPV4 AIM address
      ipaddress-v6-aim:
        type: string
        description: IPV6 AIM address
      ipaddress-v6-oam:
        type: string
        description: IPV6 OAM address
      inv-status:
        type: string
        description: CANOPI's inventory status.  Only set with values exactly as defined by CANOPI.
  pnfs:
    description: |
      Collection of Physical Network Functions.
    properties:
      pnf:
        type: array
        items:          
          $ref: "#/definitions/pnf"
  port-group:
    description: |
      Used to capture the network interfaces of this VCE
      ###### Related Nodes
      - TO vce( port-group BelongsTo vce, MANY2ONE, will delete target node)(4)
      - FROM cvlan-tag( cvlan-tag BelongsTo port-group, MANY2ONE, will delete target node)(1)

      -(1) IF this PORT-GROUP node is deleted, this FROM node is DELETED also
      -(4) IF this TO node is deleted, this PORT-GROUP is DELETED also
    required:
    - interface-id
    - orchestration-status
    properties:
      interface-id:
        type: string
        description: Unique ID of the interface
      neutron-network-id:
        type: string
        description: Neutron network id of this Interface
      neutron-network-name:
        type: string
        description: Neutron network name of this Interface
      interface-role:
        type: string
        description: Role assigned to this Interface, should use values as defined in ECOMP Yang models.
  port-groups:
    properties:
      port-group:
        type: array
        items:          
          $ref: "#/definitions/port-group"
  related-to-property:
    properties:
      property-key:
        type: string
        description: Key part of a key/value pair
      property-value:
        type: string
        description: Value part of a key/value pair
  relationship:
    properties:
      related-to:
        type: string
        description: A keyword provided by A&AI to indicate type of node.
      relationship-label:
        type: string
        description: The edge label for this relationship.
      related-link:
        type: string
        description: URL to the object in A&AI.
      relationship-data:
        type: array
        items:          
          $ref: "#/definitions/relationship-data"
      related-to-property:
        type: array
        items:          
          $ref: "#/definitions/related-to-property"
  relationship-data:
    required:
    - relationship-key
    - relationship-value
    properties:
      relationship-key:
        type: string
        description: A keyword provided by A&AI to indicate an attribute.
      relationship-value:
        type: string
        description: Value of the attribute.
  route-table-reference:
    description: |
      Openstack route table reference.
      ###### Related Nodes
      - FROM l3-network( l3-network Uses route-table-reference, MANY2MANY, will delete target node)

    required:
    - route-table-reference-id
    - route-table-reference-fqdn
    properties:
      route-table-reference-id:
        type: string
        description: Route Table Reference id, UUID assigned to this instance.
      route-table-reference-fqdn:
        type: string
        description: FQDN entry in the route table.
  route-table-references:
    description: |
      Collection of openstack route table references
    properties:
      route-table-reference:
        type: array
        items:          
          $ref: "#/definitions/route-table-reference"
  route-target:
    description: |
      Route target information
      ###### Related Nodes
      - TO vpn-binding( route-target BelongsTo vpn-binding, MANY2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this ROUTE-TARGET is DELETED also
    required:
    - global-route-target
    - route-target-role
    properties:
      global-route-target:
        type: string
        description: Number used to identify an RT, globally unique in the network
      route-target-role:
        type: string
        description: Role assigned to this route target
  route-targets:
    description: |
      Collection of route target information
    properties:
      route-target:
        type: array
        items:          
          $ref: "#/definitions/route-target"
  routing-instance:
    description: |
      ###### Related Nodes
      - TO site-pair-set( routing-instance BelongsTo site-pair-set, MANY2ONE, will delete target node)(4)
      - FROM site-pair( site-pair BelongsTo routing-instance, MANY2ONE, will delete target node)(1)

      -(1) IF this ROUTING-INSTANCE node is deleted, this FROM node is DELETED also
      -(4) IF this TO node is deleted, this ROUTING-INSTANCE is DELETED also
    required:
    - routing-instance-id
    properties:
      routing-instance-id:
        type: string
        description: Unique id of routing instance
      rpm-owner:
        type: string
        description: rpm owner
  routing-instances:
    description: |
      set of probes related to generic-vnf routing instance
    properties:
      routing-instance:
        type: array
        items:          
          $ref: "#/definitions/routing-instance"
  segmentation-assignment:
    description: |
      Openstack segmentation assignment.
      ###### Related Nodes
      - TO l3-network( segmentation-assignment BelongsTo l3-network, MANY2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this SEGMENTATION-ASSIGNMENT is DELETED also
    required:
    - segmentation-id
    properties:
      segmentation-id:
        type: string
        description: Route Table Reference id, UUID assigned to this instance.
  segmentation-assignments:
    description: |
      Collection of openstack segmentation assignments
    properties:
      segmentation-assignment:
        type: array
        items:          
          $ref: "#/definitions/segmentation-assignment"
  site-pair:
    description: |
      ###### Related Nodes
      - TO routing-instance( site-pair BelongsTo routing-instance, MANY2ONE, will delete target node)(4)
      - FROM class-of-service( class-of-service BelongsTo site-pair, MANY2ONE, will delete target node)(1)

      -(1) IF this SITE-PAIR node is deleted, this FROM node is DELETED also
      -(4) IF this TO node is deleted, this SITE-PAIR is DELETED also
    required:
    - site-pair-id
    properties:
      site-pair-id:
        type: string
        description: unique identifier of probe
      source-ip:
        type: string
        description: Prefix address
      destination-ip:
        type: string
        description: Prefix address
      ip-version:
        type: string
        description: ip version, v4, v6
      destination-hostname:
        type: string
        description: Hostname of the destination equipment to which SLAs are measured against.
      destination-equip-type:
        type: string
        description: The type of destinatination equipment. Could be Router, UCPE, etc.
  site-pair-set:
    description: |
      Set of instances for probes used to measure service level agreements
      ###### Related Nodes
      - TO generic-vnf( site-pair-set AppliesTo generic-vnf, MANY2MANY, will delete target node)
      - FROM routing-instance( routing-instance BelongsTo site-pair-set, MANY2ONE, will delete target node)(1)

      -(1) IF this SITE-PAIR-SET node is deleted, this FROM node is DELETED also
    required:
    - site-pair-set-id
    properties:
      site-pair-set-id:
        type: string
        description: Unique id of site pair set.
  site-pair-sets:
    description: |
      Collection of sets of instances for probes related to generic-vnf
    properties:
      site-pair-set:
        type: array
        items:          
          $ref: "#/definitions/site-pair-set"
  site-pairs:
    description: |
      probe within a set
    properties:
      site-pair:
        type: array
        items:          
          $ref: "#/definitions/site-pair"
  sriov-pf:
    description: |
      SR-IOV Physical Function
      ###### Related Nodes
      - TO p-interface( sriov-pf BelongsTo p-interface, ONE2ONE, will delete target node)(4)
      - FROM sriov-vf( sriov-vf Uses sriov-pf, MANY2ONE, will delete target node)

      -(4) IF this TO node is deleted, this SRIOV-PF is DELETED also
    required:
    - pf-pci-id
    properties:
      pf-pci-id:
        type: string
        description: Identifier for the sriov-pf
  sriov-pfs:
    description: |
      Collection of SR-IOV Physical Functions.
    properties:
      sriov-pf:
        type: array
        items:          
          $ref: "#/definitions/sriov-pf"
  sriov-vf:
    description: |
      SR-IOV Virtual Function (not to be confused with virtual network function)
      ###### Related Nodes
      - TO l-interface( sriov-vf BelongsTo l-interface, ONE2ONE, will delete target node)(4)
      - TO sriov-pf( sriov-vf Uses sriov-pf, MANY2ONE, will delete target node)

      -(4) IF this TO node is deleted, this SRIOV-VF is DELETED also
    required:
    - pci-id
    properties:
      pci-id:
        type: string
        description: PCI ID used to identify the sriov-vf
      vf-vlan-filter:
        type: string
        description: This metadata provides option to specify list of VLAN filters applied on VF to pass the traffic to VM.
      vf-mac-filter:
        type: string
        description: When MAC filters are specified, VF-agent service configures VFs to do MAC level filtering before the traffic is passed to VM.
      vf-vlan-strip:
        type: boolean
        description: When this field is set to true, VF will configured to strip the outer TAG before the traffic is passed to VM.
      vf-vlan-anti-spoof-check:
        type: boolean
        description: This option ensures anti VLAN spoof checks are done at the VF level to comply with security. The disable check will also be honored per the VNF needs for trusted VMs.
      vf-mac-anti-spoof-check:
        type: boolean
        description: This option ensures anti MAC spoof checks are done at the VF level to comply with security. The disable check will also be honored per the VNF needs for trusted VMs.
      vf-mirrors:
        type: string
        description: This option defines the set of Mirror objects which essentially mirrors the traffic from source to set of collector VNF Ports.
      vf-broadcast-allow:
        type: boolean
        description: This option, if set to true, sets the VF in promiscuous mode and allows all broadcast traffic to reach the VM
      vf-unknown-multicast-allow:
        type: boolean
        description: This option, if set to true, sets the VF in promiscuous mode and allows unknown multicast traffic to reach the VM
      vf-unknown-unicast-allow:
        type: boolean
        description: This option, if set to true, sets the VF in promiscuous mode and allows unknown unicast traffic to reach the VM
      vf-insert-stag:
        type: boolean
        description: This option, if set to true, instructs to insert outer tag after traffic comes out of VM.
      vf-link-status:
        type: string
        description: This option is used to set the link status.  Valid values as of 1607 are on, off, and auto.
  sriov-vfs:
    description: |
      Collection of SR-IOV Virtual Functions.
    properties:
      sriov-vf:
        type: array
        items:          
          $ref: "#/definitions/sriov-vf"
  subnet:
    description: |
      ###### Related Nodes
      - TO l3-network( subnet BelongsTo l3-network, MANY2ONE, will delete target node)(4)
      - FROM l3-interface-ipv4-address-list( l3-interface-ipv4-address-list MemberOf subnet, MANY2MANY, will delete target node)
      - FROM l3-interface-ipv6-address-list( l3-interface-ipv6-address-list MemberOf subnet, MANY2MANY, will delete target node)
      - FROM host-route( host-route BelongsTo subnet, MANY2ONE, will delete target node)(1)
      - FROM vip-ipv4-address-list( vip-ipv4-address-list MemberOf subnet, MANY2MANY, will delete target node)
      - FROM vip-ipv6-address-list( vip-ipv6-address-list MemberOf subnet, MANY2MANY, will delete target node)

      -(1) IF this SUBNET node is deleted, this FROM node is DELETED also
      -(4) IF this TO node is deleted, this SUBNET is DELETED also
      -SUBNET cannot be deleted if related to L3-INTERFACE-IPV4-ADDRESS-LIST,L3-INTERFACE-IPV6-ADDRESS-LIST,VIP-IPV4-ADDRESS-LIST,VIP-IPV6-ADDRESS-LIST

    required:
    - subnet-id
    - dhcp-enabled
    properties:
      subnet-id:
        type: string
        description: Subnet ID, should be UUID.
      subnet-name:
        type: string
        description: Name associated with the subnet.
      neutron-subnet-id:
        type: string
        description: Neutron id of this subnet
      gateway-address:
        type: string
        description: gateway ip address
      network-start-address:
        type: string
        description: network start address
      cidr-mask:
        type: string
        description: cidr mask
      ip-version:
        type: string
        description: ip version
      orchestration-status:
        type: string
        description: Orchestration status of this VNF, mastered by MSO
      dhcp-enabled:
        type: boolean
        description: dhcp enabled
      dhcp-start:
        type: string
        description: the start address reserved for use by dhcp
      dhcp-end:
        type: string
        description: the last address reserved for use by dhcp
      subnet-role:
        type: string
        description: role of the subnet, referenced when assigning IPs
      ip-assignment-direction:
        type: string
        description: ip address assignment direction of the subnet
  subnets:
    properties:
      subnet:
        type: array
        items:          
          $ref: "#/definitions/subnet"
  vce:
    description: |
      Virtual Customer Edge Router, used specifically for Gamma.  This object is deprecated.
      ###### Related Nodes
      - TO availability-zone( vce Uses availability-zone, MANY2MANY, will delete target node)
      - TO complex( vce LocatedIn complex, MANY2MANY, will delete target node)
      - TO vserver( vce HostedOn vserver, ONE2MANY, will delete target node)
      - FROM entitlement( entitlement BelongsTo vce, MANY2ONE, will delete target node)(1)
      - FROM license( license BelongsTo vce, MANY2ONE, will delete target node)(1)
      - FROM port-group( port-group BelongsTo vce, MANY2ONE, will delete target node)(1)
      - FROM service-instance( service-instance ComposedOf vce, ONE2MANY, will delete target node)

      -(1) IF this VCE node is deleted, this FROM node is DELETED also
    required:
    - vnf-id
    - vnf-name
    - vnf-type
    properties:
      vnf-id:
        type: string
        description: Unique id of VNF.  This is unique across the graph.
      vnf-name:
        type: string
        description: Name of VNF.
      vnf-name2:
        type: string
        description: Alternate name of VNF.
      vnf-type:
        type: string
        description: String capturing type of vnf, that was intended to identify the ASDC resource.  This field has been overloaded in service-specific ways and clients should expect changes to occur in the future to this field as ECOMP matures.
      service-id:
        type: string
        description: Unique identifier of service, does not strictly map to ASDC services, SOON TO BE DEPRECATED.
      regional-resource-zone:
        type: string
        description: Regional way of organizing pservers, source of truth should define values
      prov-status:
        type: string
        description: Trigger for operational monitoring of this resource by Service Assurance systems.
      operational-status:
        type: string
        description: Indicator for whether the resource is considered operational
      license-key:
        type: string
        description: OBSOLETE -  do not use
      equipment-role:
        type: string
        description: Network role being played by this VNF
      orchestration-status:
        type: string
        description: Orchestration status of this VNF, mastered by MSO
      heat-stack-id:
        type: string
        description: Heat stack id corresponding to this instance, managed by MSO
      mso-catalog-key:
        type: string
        description: Corresponds to the SDN-C catalog id used to configure this VCE
      vpe-id:
        type: string
        description: Unique ID of VPE connected to this VCE.
      v6-vce-wan-address:
        type: string
        description: Valid v6 IP address for the WAN Link on this router.  Implied length of /64.
      ipv4-oam-address:
        type: string
        description: Address tail-f uses to configure vce, also used for troubleshooting and is IP used for traps generated by VCE.
  vces:
    description: |
      Collection of Virtual Customer Edge Routers, used specifically for Gamma.  This object is deprecated.
    properties:
      vce:
        type: array
        items:          
          $ref: "#/definitions/vce"
  vf-module:
    description: |
      a deployment unit of VNFCs
      ###### Related Nodes
      - TO generic-vnf( vf-module BelongsTo generic-vnf, MANY2ONE, will delete target node)(4)
      - TO l3-network( vf-module DependsOn l3-network, MANY2MANY, will delete target node)
      - TO vnfc( vf-module Uses vnfc, ONE2MANY, will delete target node)
      - TO volume-group( vf-module Uses volume-group, ONE2ONE, will delete target node)
      - TO vserver( vf-module Uses vserver, ONE2MANY, will delete target node)
      - TO model-ver( vf-module IsA model-ver, Many2One, will delete target node)

      -(4) IF this TO node is deleted, this VF-MODULE is DELETED also
      -VF-MODULE cannot be deleted if related to VNFC

    required:
    - vf-module-id
    - is-base-vf-module
    properties:
      vf-module-id:
        type: string
        description: Unique ID of vf-module.
      vf-module-name:
        type: string
        description: Name of vf-module
      heat-stack-id:
        type: string
        description: Heat stack id corresponding to this instance.
      orchestration-status:
        type: string
        description: orchestration status of this vf-module, mastered by MSO
      is-base-vf-module:
        type: boolean
        description: used to indicate whether or not this object is base vf module
  vf-modules:
    description: |
      Collection of vf-modules, a deployment unit of VNFCs
    properties:
      vf-module:
        type: array
        items:          
          $ref: "#/definitions/vf-module"
  vig-server:
    description: |
      vig-server contains information about a vig server used for IPSec-configuration. Populated by SDN-C from 1607
      ###### Related Nodes
      - TO ipsec-configuration( vig-server BelongsTo ipsec-configuration, MANY2ONE, will delete target node)(4)

      -(4) IF this TO node is deleted, this VIG-SERVER is DELETED also
    required:
    - vig-address-type
    properties:
      vig-address-type:
        type: string
        description: indicates whether the VIG is for AVPN or INTERNET
      ipaddress-v4-vig:
        type: string
        description: v4 IP of the vig server
      ipaddress-v6-vig:
        type: string
        description: v6 IP of the vig server
  vig-servers:
    properties:
      vig-server:
        type: array
        items:          
          $ref: "#/definitions/vig-server"
  vlan:
    description: |
      Definition of vlan
      ###### Related Nodes
      - TO l-interface( vlan LinksTo l-interface, MANY2ONE, will delete target node)(4)
      - TO logical-link( vlan Uses logical-link, MANY2MANY, will delete target node)(2)
      - TO multicast-configuration( vlan Uses multicast-configuration, MANY2MANY, will delete target node)
      - FROM allotted-resource( allotted-resource PartOf vlan, MANY2MANY, will delete target node)
      - FROM service-instance( service-instance ComposedOf vlan, ONE2MANY, will delete target node)
      - FROM l3-interface-ipv4-address-list( l3-interface-ipv4-address-list BelongsTo vlan, MANY2ONE, will delete target node)(1)
      - FROM l3-interface-ipv6-address-list( l3-interface-ipv6-address-list BelongsTo vlan, MANY2ONE, will delete target node)(1)
      - FROM configuration( configuration PartOf vlan, ONE2ONE, will delete target node)

      -(1) IF this VLAN node is deleted, this FROM node is DELETED also
      -(2) IF this VLAN node is deleted, this TO node is DELETED also
      -(4) IF this TO node is deleted, this VLAN is DELETED also
    required:
    - vlan-interface
    - in-maint
    - is-ip-unnumbered
    properties:
      vlan-interface:
        type: string
        description: String that identifies the interface
      vlan-id-inner:
        type: integer
        format: int64
        description: Inner VLAN tag
      vlan-id-outer:
        type: integer
        format: int64
        description: Outer VLAN tag
  vlans:
    properties:
      vlan:
        type: array
        items:          
          $ref: "#/definitions/vlan"
  vnfc:
    description: |
      ###### Related Nodes
      - TO generic-vnf( vnfc BelongsTo generic-vnf, MANY2ONE, will delete target node)(4)
      - TO instance-group( vnfc MemberOf instance-group, MANY2MANY, will delete target node)
      - TO vip-ipv4-address-list( vnfc Uses vip-ipv4-address-list, MANY2MANY, will delete target node)
      - TO vip-ipv6-address-list( vnfc Uses vip-ipv6-address-list, MANY2MANY, will delete target node)
      - TO vserver( vnfc HostedOn vserver, ONE2MANY, will delete target node)
      - FROM vf-module( vf-module Uses vnfc, ONE2MANY, will delete target node)
      - FROM l3-interface-ipv4-address-list( l3-interface-ipv4-address-list BelongsTo vnfc, MANY2ONE, will delete target node)(1)
      - FROM l3-interface-ipv6-address-list( l3-interface-ipv6-address-list BelongsTo vnfc, MANY2ONE, will delete target node)(1)

      -(1) IF this VNFC node is deleted, this FROM node is DELETED also
      -(4) IF this TO node is deleted, this VNFC is DELETED also
    required:
    - vnfc-name
    - nfc-naming-code
    - nfc-function
    - in-maint
    - is-closed-loop-disabled
    properties:
      vnfc-name:
        type: string
        description: Unique ID of vnfc.
      nfc-naming-code:
        type: string
        description: Short code that is used in naming instances of the item being modeled
      nfc-function:
        type: string
        description: English description of function that the specific resource deployment is providing. Assigned as part of the customization of a resource in a service
      prov-status:
        type: string
        description: prov status of this vnfc
      orchestration-status:
        type: string
        description: Orchestration status of this VNF, mastered by APP-C
      ipaddress-v4-oam-vip:
        type: string
        description: Oam V4 vip address of this vnfc
      in-maint:
        type: boolean
        description: used to indicate whether or not this object is in maintenance mode (maintenance mode = true)
      is-closed-loop-disabled:
        type: boolean
        description: used to indicate whether closed loop function is enabled on this node
      group-notation:
        type: string
        description: Group notation of VNFC
      model-invariant-id:
        type: string
        description: the ASDC model id for this resource or service model.
      model-version-id:
        type: string
        description: the ASDC model version for this resource or service model.
  vnfcs:
    description: |
      virtual network components associated with a vserver from application controller.
    properties:
      vnfc:
        type: array
        items:          
          $ref: "#/definitions/vnfc"
  vpls-pe:
    description: |
      VPLS Provider Edge routers.
      ###### Related Nodes
      - TO complex( vpls-pe LocatedIn complex, MANY2ONE, will delete target node)
      - TO ctag-pool( vpls-pe Uses ctag-pool, MANY2MANY, will delete target node)
      - FROM lag-interface( lag-interface BindsTo vpls-pe, MANY2ONE, will delete target node)(1)
      - FROM p-interface( p-interface BindsTo vpls-pe, MANY2ONE, will delete target node)(1)

      -(1) IF this VPLS-PE node is deleted, this FROM node is DELETED also
    required:
    - equipment-name
    properties:
      equipment-name:
        type: string
      prov-status:
        type: string
        description: Trigger for operational monitoring of this VNF by BAU Service Assurance systems.
      ipv4-oam-address:
        type: string
        description: Address tail-f uses to configure generic-vnf, also used for troubleshooting and is IP used for traps generated by GenericVnf (v4-loopback0-ip-address).
      equipment-role:
        type: string
        description: Client should send valid enumerated value, e.g., VPLS-PE.
      vlan-id-outer:
        type: integer
        format: int64
        description: Temporary location for stag to get to VCE
  vpls-pes:
    description: |
      Collection of VPLS Provider Edge routers
    properties:
      vpls-pe:
        type: array
        items:          
          $ref: "#/definitions/vpls-pe"
  vpn-binding:
    description: |
      VPN binding
      ###### Related Nodes
      - TO customer( vpn-binding Uses customer, MANY2MANY, will delete target node)
      - FROM allotted-resource( allotted-resource BelongsTo vpn-binding, MANY2MANY, will delete target node)
      - FROM l3-network( l3-network Uses vpn-binding, MANY2MANY, will delete target node)
      - FROM logical-link( logical-link Uses vpn-binding, MANY2MANY, will delete target node)
      - FROM route-target( route-target BelongsTo vpn-binding, MANY2ONE, will delete target node)(1)
      - FROM configuration( configuration Uses vpn-binding, MANY2ONE, will delete target node)
      - FROM service-instance( service-instance Uses vpn-binding, MANY2ONE, will delete target node)

      -(1) IF this VPN-BINDING node is deleted, this FROM node is DELETED also
      -VPN-BINDING cannot be deleted if related to ALLOTTED-RESOURCE,L3-NETWORK,LOGICAL-LINK

    required:
    - vpn-id
    - vpn-name
    properties:
      vpn-id:
        type: string
        description: VPN ID, globally unique within A&AI
      vpn-name:
        type: string
        description: VPN Name
      vpn-platform:
        type: string
        description: the platform associated with the VPN example AVPN, Mobility
      vpn-type:
        type: string
        description: Type of the vpn, should be taken from enumerated/valid values
      vpn-region:
        type: string
        description: region of customer vpn
      customer-vpn-id:
        type: string
        description: id for this customer vpn
      route-distinguisher:
        type: string
        description: Used to distinguish the distinct VPN routes of separate customers who connect to the provider in an MPLS network.
  vpn-bindings:
    properties:
      vpn-binding:
        type: array
        items:          
          $ref: "#/definitions/vpn-binding"
  zone:
    description: |
      A zone is a grouping of assets in a location homing to the same connections into the CBB
      ###### Related Nodes
      - TO complex( zone LocatedIn complex, MANY2ONE, will delete target node)
      - FROM cloud-region( cloud-region LocatedIn zone, MANY2ONE, will delete target node)
      - FROM pnf( pnf LocatedIn zone, MANY2ONE, will delete target node)
      - FROM pserver( pserver LocatedIn zone, MANY2ONE, will delete target node)
      - FROM service-instance( service-instance LocatedIn zone, MANY2ONE, will delete target node)

    required:
    - zone-id
    - zone-name
    - design-type
    - zone-context
    properties:
      zone-id:
        type: string
        description: Code assigned by AIC to the zone
      zone-name:
        type: string
        description: English name associated with the zone
      design-type:
        type: string
        description: Design of zone [Medium/Large…]
      zone-context:
        type: string
        description: Context of zone [production/test]
      status:
        type: string
        description: Status of a zone.
  zones:
    description: |
      Collection of zones
    properties:
      zone:
        type: array
        items:          
          $ref: "#/definitions/zone"
