<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-teas-actn-vn-yang-29" number="9731" category="std" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.9.0 -->
  <!-- Generated by id2xml 1.5.0 on 2019-10-29T05:04:27Z --> version="3" consensus="true">

  <front>
    <title abbrev="VN YANG Data Model">A YANG Data Model for Virtual Network (VN) Operations</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-teas-actn-vn-yang-29"/> name="RFC" value="9731"/>
    <author fullname="Young Lee" initials="Y" surname="Lee" role="editor">
      <organization>Samsung Electronics</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>
    <author initials="D" surname="Dhody" fullname="Dhruv Dhody" role="editor">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>India</country>
        </postal>
        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Daniele Ceccarelli" initials="D" surname="Ceccarelli">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street></street>
          <street></street>
        </postal>
        <email>daniele.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Igor Bryskin" initials="I" surname="Bryskin">
      <organization>Individual</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>i_bryskin@yahoo.com</email>
      </address>
    </author>
    <author fullname="Bin Yeong Yoon" initials="B" surname="Yoon">
      <organization>ETRI</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>byyun@etri.re.kr</email>
      </address>
    </author>
    <date year="2024"/>
    <workgroup>TEAS Working Group</workgroup> year="2025" month="February"/>
    <area>RTG</area>
    <workgroup>teas</workgroup>

    <abstract>
      <t>
      A Virtual Network (VN) is a network provided by a service provider to a
      customer for the customer to use in any way it wants as though it was were a
      physical network.  This document provides a YANG data model generally
      applicable to any mode of VN operations. This includes VN operations as
      per the Abstraction and Control of TE Networks (ACTN) framework.</t> framework (see RFC 8453).</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
            <t>
   Abstraction and Control of Traffic Engineered (TE) TE Networks (ACTN)
   describes a set of management and control functions used to operate
   one or more TE Traffic Engineered (TE) networks to construct a Virtual Network (VN). A VN
   is represented to customers and is built from the abstractions of the
   underlying TE networks <xref target="RFC8453" format="default"/>. This document provides a YANG data model <xref target="RFC7950" format="default"/> data model generally applicable to any
   mode of VN operation. ACTN is the primary example of the usage of the VN YANG model data model, but VN is not limited to it.</t>

      <t>
   The VN model defined in this document is applicable in a generic sense
   as an independent model in and of itself. The VN model defined in
   this document  It can also work together with other customer service models such as the Layer Three Virtual Private Network L3VPN Service Model (L3SM) <xref target="RFC8299" format="default"/>, the Layer Two Virtual Private Network L2VPN Service Model (L2SM) <xref target="RFC8466" format="default"/> format="default"/>, and the Layer One L1 Connectivity Service Model (L1CSM) <xref target="I-D.ietf-ccamp-l1csm-yang" format="default"/> to
   provide a complete life-cycle service management and operations.</t>
      <t>
   The YANG data model discussed in this document basically provides the
   following:</t>
      <ul spacing="normal">
        <li>Characteristics of Access Points (APs) that describe customer's
      endpoint characteristics;</li>
        <li>Characteristics of Virtual Network Access Points (VNAP) (VNAPs) that
      describe how an AP is partitioned for multiple VNs sharing the AP
      and its reference to a Link Termination Point (LTP) of the
      Provider Edge (PE) Node;</li> node;</li>
        <li>Characteristics of Virtual Networks (VNs) VNs that describe the
      customer's VN in terms of multiple VN Members members comprising a VN, multi-source and/or multi-destination characteristics of the VN Member, member, the
      VN's reference to TE-topology's Abstract Node;</li> abstract node.</li>
      </ul>
      <t>An abstract TE topology is a topology that contains abstract topological elements (nodes, links) created and customised customized based on customer's customer preference <xref target="RFC8795" format="default"/>.
   The actual VN instantiation and computation is performed with
   Connectivity Matrices
   connectivity matrices of the TE-Topology Model TE Topology model <xref target="RFC8795" format="default"/> format="default"/>,
   which provides a TE network topology abstraction and management
   operation. As per <xref target="RFC8795" format="default"/>, a TE node connectivity matrix is the TE node's switching limitations in the form of valid switching combinations of the TE node's LTPs and potential TE paths. The VN representation relies on a single abstract TE node with a connectivity matrix. The VN can be abstracted as a set of edge-to-edge links (a Type 1 VN).  Each link is the VN member that is mapped to the connectivity matrix entry (<xref target="sect-2.1"/>). The VN can also be abstracted as a topology of virtual nodes
and virtual links (a Type 2 VN). Alongside the mapping of VN members to a connectivity matrix entry, an underlay path can also be specified (<xref target="sect-2.2"/>).
</t>
   <t>Once the TE-topology Model TE Topology model is used in triggering VN
   instantiation over the networks, the TE-tunnel TE model <xref target="I-D.ietf-teas-yang-te" format="default"/> Model will
   inevitably interact with the TE-Topology TE Topology model for when setting up actual
   tunnels and LSPs Label Switched Paths (LSPs) under the tunnels.</t>

      <t>
   Sections 2 <xref target="sect-2" format="counter"/> and 3 <xref target="sect-3" format="counter"/> provide a discussion of how the VN YANG data model is
   applicable to the ACTN context where a Virtual Network Service (VNS)
   operation is implemented for the interface of the Customer Network Controller (CNC)- (CNC) and the
   Multi-Domain Service Coordinator (MDSC) interface (CMI).</t> (MDSC).</t>
      <t>
   The YANG data model on for the CMI CNC-MDSC Interface (CMI) is also known as the customer "customer service model model" in
   <xref target="RFC8309" format="default"/>. The YANG data model discussed in this document is used to
   operate customer-driven VNs during the VN instantiation, VN
   computation, instantiation and computation as well as its life-cycle service management and operations.</t>
      <t>
   The VN operational state is included in the same tree as the
   configuration consistent with Network Management Datastore
   Architecture (NMDA) <xref target="RFC8342" format="default"/>. <!--The origin of the data is indicated
   as per the origin metadata annotation.--></t>

      </t>
      <section anchor="sect-1.1" numbered="true" toc="default">
        <name>Terminology</name>
        <!--><t>
   Refer to <xref target="RFC8453" format="default"/>, <xref target="RFC7926" format="default"/>,
        <name>Terminology and <xref target="RFC8309" format="default"/> for the key terms used
   in this document.</t>--> Conventions</name>

   <t>This document borrows the following terms abbreviations from <xref target="RFC8453" format="default"/> and/or <xref target="RFC8795" format="default"/>:</t>
   <ul spacing="normal">
   <li>VN: Virtual Network</li>
   <li>AP: Access Point</li>
   <li>VNAP: VN
   <dl spacing="normal" newline="false">
     <dt>VN:</dt> <dd>Virtual Network</dd>
     <dt>AP:</dt> <dd>Access Point</dd>
     <dt>VNAP:</dt> <dd>VN Access Point</li>
   <li>ACTN: Abstraction Point</dd>
     <dt>ACTN:</dt> <dd>Abstraction and Control of TE Networks</li>
   <li>CNC: Customer Networks</dd>
     <dt>CNC:</dt> <dd>Customer Network Controller</li>
   <li>MDSC: Multi-Domain Controller</dd>
     <dt>MDSC:</dt> <dd>Multi-Domain Service Coordinator</li>
   <li>CMI: CNC-MDSC Interface</li>
   </ul>
   <t>This document borrows the following terms from <xref target="RFC8795" format="default"/>:</t>
   <ul spacing="normal">
   <li>LTP: Link Coordinator</dd>
     <dt>CMI:</dt> <dd>CNC-MDSC Interface</dd>
     <dt>LTP:</dt> <dd>Link Termination Point</li>
   <li>Connectivity Matrix</li>
   </ul> Point</dd>
   </dl>

   <t>This document borrows the terminology in Section 1.1 of <xref target="RFC7926" format="default"/>.</t>
   <t>This document uses sectionFormat="of" section="1.1"/>, the term 'Service Model' as described in "Service Model" from <xref target="RFC8309" format="default"/>.</t>

        <!--<section toc="default" numbered="true">
          <name>Requirements Language</name>
          <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", format="default"/>, and "OPTIONAL" the term "Connectivity Matrix" from <xref target="RFC8795" format="default"/>.</t>

   <t>Various examples in this document are to contain long lines that may be interpreted folded, as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
      appear in all capitals, as shown here.</t>
        </section>--> target="RFC8792" format="default"/>.</t>

      </section>

      <section anchor="sect-1.2" numbered="true" toc="default">

        <name>Tree Diagram</name>
        <t>
   A simplified graphical representation of the data model is used in
   Section 5
   <xref target="sect-5"/> of this document.  The meaning of the symbols in
   these diagrams is defined in <xref target="RFC8340" format="default"/>.</t>
      </section>
      <section anchor="sect-1.3" numbered="true" toc="default">
        <name>Prefixes in Data Node Names</name>
        <t>
   In this document, the names of data nodes and other data model objects
   are prefixed using the standard prefix associated with the
   corresponding YANG imported modules, modules as shown in Table 1.</t> <xref target="tab-prefixes-and-corresponding-yang-modules"/>.</t>
        <table anchor="tab-prefixes-and-corresponding-yang-modules" align="center">
          <name>Prefixes and corresponding Corresponding YANG modules</name> Modules</name>
          <thead>
            <tr>
              <th align="left"> Prefix</th> align="left">Prefix</th>
              <th align="left"> YANG module</th> align="left">YANG Module</th>
              <th align="left"> Reference</th> align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">vn</td>
              <td align="left">ietf-vn</td>
              <td align="left">[RFCXXXX]</td> align="left">RFC 9731</td>
            </tr>
            <tr>
              <td align="left">yang</td>
              <td align="left">ietf-yang-types</td>
              <td align="left">
                <xref target="RFC6991" format="default"/></td>
            </tr>
            <tr>
              <td align="left">nw</td>
              <td align="left">ietf-network</td>
              <td align="left">
                <xref target="RFC8345" format="default"/></td>
            </tr>
            <tr>
              <td align="left">nt</td>
              <td align="left">ietf-network-topology</td>
              <td align="left">
                <xref target="RFC8345" format="default"/></td>
            </tr>
            <tr>
              <td align="left">te-types</td>
              <td align="left">ietf-te-types</td>
              <td align="left">
                <xref target="RFC8776" format="default"/></td>
            </tr>
            <tr>
              <td align="left">tet</td>
              <td align="left">ietf-te-topology</td>
              <td align="left">
                <xref target="RFC8795" format="default"/></td>
            </tr>
          </tbody>
        </table>
        <t>
   Note: The RFC Editor will replace XXXX with the number assigned to
   the RFC once this draft becomes an RFC.</t>
      </section>
    </section>
    <section anchor="sect-2" numbered="true" toc="default">
      <name>Use-case
      <name>Use Case of VN YANG Data Model in the ACTN context</name> Context</name>
      <t>
   In this section, ACTN is being used to illustrate the general usage
   of the VN YANG data model. The model presented in this section has the
   following ACTN context.</t>

      <figure anchor="ure-actn-cmi">
        <name>ACTN CMI</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
       +-------+
       |  CNC  |
       +-------+
           |
           |    VN YANG + TE-topology YANG TE Topology
           |
+-----------------------+
|         MDSC          |
                   +-----------------------+
]]></artwork>
+-----------------------+]]></artwork>
      </figure>

      <t>
   Both ACTN VN YANG and TE-topology TE Topology YANG data models are used over the CMI to
   establish a VN over TE networks networks, as shown in <xref target="ure-actn-cmi"/>.</t>
      <!--<t>
   In the context of 5G transport application, 5G Traffic Provisioning
   Manager (TPM) that provides slicing requirements to the transport
   networks (i.e., MDSC) can be considered as a type of CNC. The ACTN
   CMI provides the necessary interface functions between 5G and
   transport networks in order to facilitate dynamic VN creation and
   its lifecycle management with proper feedback loop for monitoring.</t>-->

	<section anchor="sect-2.1" numbered="true" toc="default">
          <name>Type 1 VN</name>
        <t>
   As defined in <xref target="RFC8453" format="default"/>, a Virtual Network VN is a customer view of the
   TE network.  To recapitulate VN types from <xref target="RFC8453" format="default"/>, a Type 1 VN is
   defined as follows:</t>
   <blockquote>

        <t>
   The VN can be seen as a set of edge-to-edge abstract links (a Type 1
   VN).  Each abstract link is referred to as a VN member and is formed
   as an end-to-end tunnel across the underlying networks. Such tunnels
   may be constructed by recursive slicing or abstraction of paths in
   the underlying networks and can encompass edge points of the
   customer's network, access links, intra-domain paths, and inter-domain links.</t></blockquote>
        <dl newline="true" spacing="normal" indent="1">
          <dt>If links.</t>

   <t>If we were to create a VN where we have four VN-members VN members as follows:</dt>
          <dd/>
        </dl> follows:</t>
   <figure>
     <name>VN Members (Type 1 VN)</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
               VN-member
VN member 1       L1-L4
               VN-member
VN member 2       L1-L7
               VN-member
VN member 3       L2-L4
               VN-member
VN member 4       L3-L8
]]></artwork>
        <dl newline="false" spacing="normal" indent="7">
          <dt/>
          <dd>
          Where       L3-L8]]>
	</artwork>
   </figure>

        <t>Where L1, L2, L3, L4, L7, and L8 correspond to a Customer
          End-Point
          Endpoint (or AP).</dd>
        </dl>
        <t>
   This AP).</t>

        <t>This VN can be modelled modeled as one abstract node representation as
        follows in Figure 2:</t> <xref target="ure-abstract-node-one-node-topology"/>:</t>

        <figure anchor="ure-abstract-node-one-node-topology">
          <name>Abstract Node (One node topology)</name> (Type 1 Topology)</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
       +----------------------------------------------+
       |                                              |
 L1----|..............................................|------L4
       |   .                                       .  |
       |    .                AN1                  .   |
       |     .                                   .    |
       |      ..................................*.....|------L7
       |                                       .      |
L2-----|.......................................       |
       |                                              |
L3-----|..............................................|------L8
       |                                              |
           +----------------------------------------------+

]]></artwork>
       +----------------------------------------------+]]></artwork>
        </figure>

        <t>
   Modelling
   Modeling a VN as one abstract node is the easiest way for customers
   to express their end-to-end connectivity as shown in <xref target="ure-abstract-node-one-node-topology"/>.<!--; however, customers are not
   limited to express their VN only with one abstract node. In some
   cases, more than one abstract nodes can be employed to express their
   VN.--> target="ure-abstract-node-one-node-topology"/>.
        </t>
      </section>
      <section anchor="sect-2.2" numbered="true" toc="default">
        <name>Type 2 VN</name>

        <t>
   For some VN members, the customers are allowed to configure
   the intended path. To achieve this, alongside the single
   node abstract topology, an underlay topology is also needed.
   The underlay topology could be native TE topology or
   an abstract TE topology. The intended path is set based on
   the nodes and links of the underlay topology. A Type 1 VN
   can be seen viewed as a higher higher-level abstraction of a Type 2 VN (which along with VN, which represents a single node abstract topology, an topology over the underlay topology and the includes a mechanism to specify intended path is specified). paths.  These topologies
   could be mutually agreed upon between the CNC and the MDSC
   prior to VN creation or it they could be created as part of VN
   instantiation. <!--Type 2 VN is always built on top of a Type 1 VN.--></t>
   instantiation.</t>

        <t>
   If a Type 2 VN is desired for some or all of the VN members of a Type 1
   VN (see the example in <xref target="sect-2.1" format="default"/>), the TE-topology TE Topology model can provide the following abstract topologies (a single node topology AN1 and an underlay topology (with nodes S1 to S11 and corresponding links)).</t>
        <figure anchor="ure-type-2-topology">
          <name>Type 2 topology</name> Topology</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
       +----------------------------------------------+
       |             S1               S2              |
       |              O...............O               |
       |     ......... .......         .              |
       |    .                 .         .             |
       |S3 .                   . S4      . S5         |
 L1----|.O......................O.........O...........|------L4
       |   .                     .         .          |
       |    .                     .         .         |
       |     . S6                  . S7      . S8     |
       |      O     ................O.........O.......|------L7
       |     . .   .                 .   .....        |
       |S9  .   . .S10                . .             |
L2-----|...O.....O.....................O..............|------L8
       |  .                          S11              |
L3-----|..                                            |
       |                                          AN1 |
           +----------------------------------------------+
]]></artwork>
       +----------------------------------------------+]]></artwork>
        </figure>
        <t>
   As shown in <xref target="ure-type-2-topology"/>, the abstract node is AN1 and an underlay topology is depicted with nodes and links (S1 to S11).</t>
        <t>
   As an example, if VN-member VN member 1 (L1-L4) is chosen to configure its own
   path over Type 2 topology, it can select, say, a path that consists
   of the explicit abstract path {S3,S4,S5} based on the underlay topology and its service
   requirement.  This capability is enacted via TE-topology
   configuration by the customer.</t>
      </section>
    </section>
    <section anchor="sect-3" numbered="true" toc="default">
      <name>High-Level Control Flows with Examples</name>
      <section anchor="sect-3.1" numbered="true" toc="default">
        <name>Type 1 VN Illustration</name>

        <t>
   If this VN is Type 1, the following diagram shows the message flow
   between CNC and MDSC to instantiate this VN using VN and TE-Topology
   Models.</t> TE Topology
   YANG data models.</t>
   <figure anchor="type1">
          <name>Type 1 VN Illustration</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
            +--------+                        +--------+
            |  CNC   |                        |  MDSC  |
            +--------+                        +--------+
                 |                                 |
                 |                                 |
CNC POST TE-topo TE Topo |  POST /nw:networks/nw:network/  |
model(with
model (w/ Conn.  |  nw:node/te-node-id/            |
Matrix on one    |  tet:connectivity-matrices/     |
Abstract node
abstract node)   |  tet:connectivity-matrix        |
                 |-------------------------------->|
                 |                   HTTP 200      |
                 |<--------------------------------|
                 |                                 |
CNC POST the     |  POST /virtual-network          |
VN identifying   |-------------------------------->| If there is
AP, VNAP VNAP, and VN- VN |                                 | multi-src/dest
Members multi-src/dest,
members and maps |                                 | then MDSC
to the TE-topo TE Topo   |                 HTTP 200        | selects a an
model            |<--------------------------------| src or dest
                 |                                 | and updates
                 |                                 | VN YANG
CNC GET the      |  GET /virtual-network           |
VN YANG status   |-------------------------------->|
                 |                                 |
                 |  HTTP 200 (VN with status:      |
                 |  selected VN-members VN members            |
                 |  in case of multi-s-d) multi-s/d)          |
                 |<--------------------------------|
                 |                                 |
]]></artwork></figure>                                 |]]></artwork>
   </figure>

      </section>
      <section anchor="sect-3.2" numbered="true" toc="default">
        <name>Type 2 VN Illustration</name>
        <t>
   For some VN members, the customer may want to "configure" an explicit
   path that connects its two end-points. endpoints. Let us
   consider the following example.</t>
        <ul empty="true" spacing="normal">
          <li>
            <dl newline="false" spacing="normal" indent="1">
              <dt>VN-member 1</dt>
              <dd>
                <t> example:</t>

   <figure>
     <name>VN Members (Type 2 VN)</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
VN member 1	L1-L4 (via S3, S4, and S5)
                </t>
                <t/>
              </dd>
              <dt>VN-member 2</dt>
              <dd>
                <t>
VN member 2	L1-L7 (via S3, S4, S7 S7, and S8)
                </t>
                <t/>
              </dd>
              <dt>VN-member 3</dt>
              <dd>
                <t>
VN member 3	L2-L7 (via S9, S10, and S11)
                </t>
                <t/>
              </dd>
              <dt>VN-member 4</dt>
              <dd>
                <t>
VN member 4	L3-L8 (via S9, S10 S10, and S11)
                </t>
                <t/>
              </dd>
            </dl>
          </li>
        </ul> S11)]]></artwork>
      </figure>

   <t>There are two options depending on whether CNC or MDSC creates the
   single abstract node topology.</t>
        <t>
   Case

   <t>Case 1:</t>
        <t>
   If the CNC creates the single-abstract-node single abstract node topology, the following
   diagram shows the message flow between the CNC and MDSC to instantiate
   this VN using a VN and TE-Topology Model.</t> TE Topology YANG data model would be as shown in the following diagram:</t>
   <figure anchor="type2_case1">
          <name>Type 2 VN Illustration, Illustration: Case 1</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
            +--------+                                +--------+
            |  CNC   |                                |  MDSC  |
            +--------+                                +--------+
                 |                                         |
                 |                                         |
CNC POST TE-topo TE Topo |  POST /nw:networks/nw:network/          |
model(with
model (w/ Conn.  |  nw:node/te-node-id/tet:connectivity-   |
Matrix on one    |  matrices/tet:connectivity-matrix       |
Abstract
abstract node and|---------------------------------------->|
Explicit
explicit paths in|                                         |
the conn. matrix)| Conn. Matrix)|                       HTTP 200          |
                 |<----------------------------------------|
                 |                                         |
CNC POST the     |  POST /virtual-network                  |
VN identifying   |---------------------------------------->|
AP, VNAP VNAP, and VN- VN |                                         |
Members
members and maps |                                         |
to the TE-topo TE Topo   |                         HTTP 200        |
model            |<----------------------------------------|
                 |                                         |
                 |                                         |
CNC GET the      |  GET /virtual-network                   |
VN YANG status   |---------------------------------------->|
                 |                                         |
                 |  HTTP 200 (VN with status)              |
                 |<----------------------------------------|
                 |                                         |

]]></artwork></figure>                                         |]]></artwork>
</figure>

<t>Case 2:</t>
        <t>
   On the other hand, if MDSC create the single-abstract-node single abstract node topology
   based on VN YANG posted by the CNC, the following diagram shows the
   message flow between CNC and MDSC to instantiate this VN using VN
   and TE-Topology Models.</t> TE Topology YANG data models.</t>
      <figure anchor="type2_case2">
          <name>Type 2 VN Illustration, Illustration: Case 2</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
            +--------+                        +--------+
            |  CNC   |                        |  MDSC  |
            +--------+                        +--------+
                 |                                 |
                 |                                 |
CNC POST VN      |                                 |
Identifying
identifying AP,  |                                 |
VNAP and VN- VN      |  POST /virtual-network          | MDSC populates
Members
members          |-------------------------------->| a single Abst. abst.
                 |                 HTTP 200        | node topology
                 |<--------------------------------| by itself
                 |                                 |
CNC GET VN &     |  GET /virtual-network  &        |
POST TE-Topo TE Topo     |  POST /nw:networks/nw:network/  |
Models (with
models (w/       |  nw:node/te-node-id/tet:        |
Conn. Matrix     |  connectivity-matrices/         |
on the           |  tet:connectivity-matrix        |
Abstract Node
abstract node    |-------------------------------->|
and explicit     |                                 |
paths in the     |                                 |
conn. matrix)
Conn. Matrix)    |                                 |
                 |                 HTTP 200        |
                 |<--------------------------------|
                 |                                 |
                 |                                 |
CNC GET the      |  GET /virtual-network           |
VN YANG status   |-------------------------------->|
                 |                                 |
                 |  HTTP 200 (VN with status)      |
                 |<--------------------------------|
                 |                                 |
]]></artwork></figure>                                 |]]></artwork>
</figure>

<t>Note that the underlay topology (which is referred to by the single-abstract-node single abstract node topology) could be a Native/White topology or a Grey topology (<xref target="RFC8453" format="default"/>) that is further customised customized based on the requirements of the customer and configured at the MDSC.</t>
        <t>
   <xref target="sect-7" format="default"/> provides JSON examples for both the VN model and TE-topology the TE Topology
   Connectivity Matrix sub-model to illustrate how a VN can be created
   by the CNC making use of the VN module model as well as the TE-topology TE Topology
   Connectivity Matrix module.</t>
        <section anchor="sect-3.3" numbered="true" toc="default">
          <name>VN and AP Usage</name>
          <t>The customer access information may be known at the time of VN creation. A shared logical AP identifier is used between the customer and the operator to identify the access link between Customer Edge (CE) and Provider Edge (PE). This is described in Section 6 of <xref target="RFC8453" format="default"/>.</t> sectionFormat="of" section="6"/>.</t>

<t>In some VN operations, the customer access may not be known at the initial VN creation. The VN operation allows the creation of a VN with only a PE identifier as well. identifier. The customer access information could be added later.</t>

          <t>To achieve this, the 'ap' container has a leaf for the 'pe' node that allows the AP to be created with PE information. The vn-member VN member (and vn) VN) could use APs that initially only have PE information initially.</t> information.</t>
        </section>
      </section>
    </section>
    <section anchor="sect-4" numbered="true" toc="default">
      <name>VN YANG Data Model Usage</name>
      <section anchor="sect-4.1" numbered="true" toc="default">
        <name>Customer view View of VN</name>
        <t>
   The VN-YANG VN YANG data model allows to define the definition of a customer view, view and allows the
   customer to communicate using the VN constructs as described in the
   <xref target="RFC8454" format="default"/>. It allows the grouping of edge-to-edge links
   (i.e., VN members) under a common umbrella of VN. This allows the
   customer to instantiate and view the VN as one entity, making it
   easier for some customers to work on VN without worrying about the
   details of the provider-based YANG data models.</t>
        <t>
   This is similar to the benefits offered by a separate YANG data model for
   the
   customer services as described in <xref target="RFC8309" format="default"/>, which states that
   service models do not make any assumption assumptions about how a service is
   actually engineered and delivered for a customer.</t>
      </section>
      <section anchor="sect-4.2" numbered="true" toc="default">
        <name>Auto-creation of VN by MDSC</name>
        <t>
   The VN could be configured at the MDSC explicitly by the CNC using
   the VN YANG data model. In some other cases, the VN is not explicitly
   configured,
   configured but is instead created automatically by the MDSC based on the
   customer service model and local policy, policy; even in these cases, the VN
   YANG data model can be used by the CNC to learn details of the underlying
   VN, created to meet the requirements of the customer service model.</t>
      </section>
      <section anchor="sect-4.3" numbered="true" toc="default">
        <name>Innovative Services</name>
        <section anchor="sect-4.3.1" numbered="true" toc="default">
          <name>VN Compute</name>
    <t>
   The VN Model model supports VN compute (pre-instantiation mode) to view the
   full VN as a single entity before instantiation. Achieving instantiation; achieving this via
   path computation or "compute only" "compute-only" tunnel setup (<xref target="I-D.ietf-teas-yang-te"/>) does not provide the
   same functionality.</t>
      <figure anchor="VN_Compute1">
          <name>VN Compute</name> Compute with Reference to TE Toplogy YANG Data Model</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
            +--------+                                +--------+
            |  CNC   |                                |  MDSC  |
            +--------+                                +--------+
                 |                                         |
                 |                                         |
CNC POST TE-topo TE Topo |  POST /nw:networks/nw:network/          |
model(with
model (w/ Conn.  |  nw:node/te-node-id/tet:connectivity-   |
Matrix on one    |  matrices/tet:connectivity-matrix       |
Abstract
abstract node and|---------------------------------------->|
constraints in   |                                         |
the conn. matrix)|                       HTTP 200          |
                 |<----------------------------------------|
                 |                                         |
                 |                                         |
CNC calls RPC to |  RPC /vn-compute /vn compute                        |
compute the VN   |---------------------------------------->|
as per the       |                                         |
refered TE-Topo  |                                         |
                 |                                         |
                 |           HTTP 200 (Computed VN)        |
                 |<----------------------------------------|
                 |                                         |

]]></artwork></figure>                                         |]]></artwork>
      </figure>

          <t>The VN compute RPC allows you to optionally include the optional inclusion of the constraints and the optimization criteria at the VN as well as at the individual VN-member level. Thus, the RPC can be used independently to get the computed VN result
   without creating an abstract topology first.</t>
         <figure anchor="VN_Compute2">
          <name>VN Compute</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
            +--------+                                +--------+
            |  CNC   |                                |  MDSC  |
            +--------+                                +--------+
                 |                                         |
                 |                                         |
CNC calls RPC to |  RPC /vn-compute /vn compute                        |
compute the VN   |---------------------------------------->|
as per the       |                                         |
constraints and  |                                         |
VN-members
VN members       |                                         |
                 |           HTTP 200 (Computed VN)        |
                 |<----------------------------------------|
                 |                                         |

]]></artwork></figure>
          <t>In either case                                         |]]></artwork>
	 </figure>

          <t>Regardless of whether the TE Topology model is referenced, the RPC output includes a reference to the single node
  abstract topology with each VN-member VN member including a
  reference to the connectivity-matrix-id where the
  path properties could be found. </t>
          <t>To achieve this this, the VN-compute VN compute RPC reuses the following common groupings:
          </t>
          <ul spacing="normal">

            <li>te-types:generic-path-constraints: This is used optionally in the RPC input at the VN VN-level and/or VN-member level. The VN-member level overrides the VN-level data. This also overrides data including any constraints in the referenced abstract node in the TE topology.</li>
            <li>te-types:generic-path-optimization: This is used optionally in the RPC input at the VN VN-level and/or VN-member level. The VN-member level overrides the VN-level data. This also overrides data including any optimization in the referenced abstract node in the TE topology.</li>
            <li>vn-member: This
            <li>vn member: identifies the VN member in both RPC input and output.</li>
            <li>vn-policy: This is used optionally in the RPC input to apply any VN level VN-level policies.</li>
          </ul>
          <t>When MDSC receives this RPC RPC, it computes the VN based on the input provided in the RPC call. RPC. This computation does not create a VN or reserve any resources in the system, it simply computes the resulting VN based on information at the MDSC or in coordination with the CNC. A single-node-abstract single node abstract topology is used to convey the result of each VN member as a reference to the connectivity-matrix-id. In case of an error, the error information is included.</t>
          <artwork

          <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="yangtree"><![CDATA[
rpcs:
  +---x vn-compute
     +---w input
     |  +---w te-topology-identifier
     |  |  +---w provider-id?   te-global-id
     |  |  +---w client-id?     te-global-id
     |  |  +---w topology-id?   te-topology-id
     |  +---w abstract-node?
     |  |       -> /nw:networks/network/node/tet:te-node-id
     |  +---w path-constraints
     |  |  +---w te-bandwidth
     |  |  |  +---w (technology)?
     |  |  |        ...
     |  |  +---w link-protection?          identityref
     |  |  +---w setup-priority?           uint8
     |  |  +---w hold-priority?            uint8
     |  |  +---w signaling-type?           identityref
     |  |  +---w path-metric-bounds
     |  |  |  +---w path-metric-bound* [metric-type]
     |  |  |        ...
     |  |  +---w path-affinities-values
     |  |  |  +---w path-affinities-value* [usage]
     |  |  |        ...
     |  |  +---w path-affinity-names
     |  |  |  +---w path-affinity-name* [usage]
     |  |  |        ...
     |  |  +---w path-srlgs-lists
     |  |  |  +---w path-srlgs-list* [usage]
     |  |  |        ...
     |  |  +---w path-srlgs-names
     |  |  |  +---w path-srlgs-name* [usage]
     |  |  |        ...
     |  |  +---w disjointness?             te-path-disjointness
     |  +---w cos?                      te-types:te-ds-class
     |  +---w optimizations
     |  |  +---w (algorithm)?
     |  |     +--:(metric) {path-optimization-metric}?
     |  |     |     ...
     |  |     +--:(objective-function)
     |  |              {path-optimization-objective-function}?
     |  |           ...
     |  +---w vn-member-list* [id]
     |  |  +---w id                        vnm-id
     |  |  +---w src
     |  |  |  +---w ap?          -> /access-point/ap/id
     |  |  |  +---w vn-ap-id?
     |  |  |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/vn-ap/\
 id
     |  |  |  +---w multi-src?   boolean {multi-src-dest}?
     |  |  +---w dest
     |  |  |  +---w ap?           -> /access-point/ap/id
     |  |  |  +---w vn-ap-id?
     |  |  |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/vn-ap/\
id
     |  |  |  +---w multi-dest?   boolean {multi-src-dest}?
     |  |  +---w connectivity-matrix-id?   leafref
     |  |  +---w underlay
     |  |  +---w path-constraints
     |  |  |  +---w te-bandwidth
     |  |  |  |     ...
     |  |  |  +---w link-protection?          identityref
     |  |  |  +---w setup-priority?           uint8
     |  |  |  +---w hold-priority?            uint8
     |  |  |  +---w signaling-type?           identityref
     |  |  |  +---w path-metric-bounds
     |  |  |  |     ...
     |  |  |  +---w path-affinities-values
     |  |  |  |     ...
     |  |  |  +---w path-affinity-names
     |  |  |  |     ...
     |  |  |  +---w path-srlgs-lists
     |  |  |  |     ...
     |  |  |  +---w path-srlgs-names
     |  |  |  |     ...
     |  |  |  +---w disjointness?             te-path-disjointness
     |  |  +---w cos?                      te-types:te-ds-class
     |  |  +---w optimizations
     |  |     +---w (algorithm)?
     |  |           ...
     |  +---w vn-level-diversity?       te-types:te-path-disjointness       te-types:te-path-\
disjointness
     +--ro output
        +--ro te-topology-identifier
        |  +--ro provider-id?   te-global-id
        |  +--ro client-id?     te-global-id
        |  +--ro topology-id?   te-topology-id
        +--ro abstract-node?
        |       -> /nw:networks/network/node/tet:te-node-id
        +--ro vn-member-list* [id]
           +--ro id                        vnm-id
           +--ro src
           |  +--ro ap?          -> /access-point/ap/id
           |  +--ro vn-ap-id?
           |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/vn-ap/\
id
           |  +--ro multi-src?   boolean {multi-src-dest}?
           +--ro dest
           |  +--ro ap?           -> /access-point/ap/id
           |  +--ro vn-ap-id?
           |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/vn-ap/\
id
           |  +--ro multi-dest?   boolean {multi-src-dest}?
           +--ro connectivity-matrix-id?   leafref
           +--ro underlay
           +--ro if-selected?              boolean {multi-src-dest}?
           +--ro compute-status?           vn-compute-status
           +--ro error-info
              +--ro error-description?   string
              +--ro error-timestamp?     yang:date-and-time
              +--ro error-reason?        identityref

]]></artwork>        identityref]]></sourcecode>

        </section>
        <section anchor="sect-4.3.2" numbered="true" toc="default">
          <name>Multi-sources
          <name>Multiple Sources and Multi-destinations</name> Multiple Destinations</name>
          <t>
   In creating a virtual network, VN, the list of sources or destinations
   or both may not be pre-determined predetermined by the customer. For instance, for
   a given source, there may be a list of multiple-destinations multiple destinations to
   which the optimal destination may be chosen depending on the network
   resource situations. Likewise, for a given destination, there may
   also be multiple-sources multiple sources from which the optimal source may be
   chosen. In some cases, there may be a pool of multiple sources and
   destinations from which the optimal source-destination may be
   chosen. The following YANG tree shows
   how to model multi-sources multiple sources and multi-destinations.</t>
          <artwork multiple destinations.</t>

          <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="yangtree"><![CDATA[
module: ietf-vn
  +--rw virtual-network
     +--rw vn* [id]
        +--rw id                        vn-id
        +--rw te-topology-identifier
        |  +--rw provider-id?   te-global-id
        |  +--rw client-id?     te-global-id
        |  +--rw topology-id?   te-topology-id
        +--rw abstract-node?
        |       -> /nw:networks/network/node/tet:te-node-id
        +--rw vn-member* [id]
        |  +--rw id                        vnm-id
        |  +--rw src
        |  |  +--rw ap?          -> /access-point/ap/id
        |  |  +--rw vn-ap-id?
        |  |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/vn-ap/\
id
        |  |  +--rw multi-src?   boolean {multi-src-dest}?
        |  +--rw dest
        |  |  +--rw ap?           -> /access-point/ap/id
        |  |  +--rw vn-ap-id?
        |  |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/vn-ap/\
id
        |  |  +--rw multi-dest?   boolean {multi-src-dest}?
        |  +--rw connectivity-matrix-id?   leafref
        |  +--rw underlay
        |  +--ro oper-status?              te-types:te-oper-status
        |  +--ro if-selected?              boolean {multi-src-dest}?
        +--rw admin-status?             te-types:te-admin-status
        +--ro oper-status?              te-types:te-oper-status
        +--rw vn-level-diversity?       te-types:te-path-disjointness

]]></artwork>       te-types:te-path-disjointness]]></sourcecode>

        </section>
        </section>
        <section anchor="sect-4.4" numbered="true" toc="default">
          <name>Others</name>
          <t>
   The VN YANG data model can be easily be augmented to support the mapping of
   VN to the Services services such as L3SM and L2SM as described in <xref target="I-D.ietf-teas-te-service-mapping-yang" format="default"/>.</t>
          <t>
   The VN YANG data model can be extended to support telemetry, performance
   monitoring
	  monitoring, and network autonomics as described in <xref target="I-D.ietf-teas-actn-pm-telemetry-autonomics" format="default"/>.</t>

          <t>Note that the VN YANG data model is tightly coupled with the TE Topology model <xref target="RFC8795" format="default"/>. Any underlay technology not supported by the TE Topology model in <xref target="RFC8795" format="default"/> is also not supported by this the VN model. The However, the VN model does include an empty container called "underlay" that can be augmented. For example example, the Segment Routing (SR) Policy <xref target="RFC9256"/> information can be augmented for the SR underlay by a future model.</t>

        <t>Apart from the te-types:generic-path-constraints and te-types:generic-path-optimization, an additional leaf cos called "cos" for the class of service <xref target="RFC4124"/> is added to represent the  Class-Type of traffic <xref target="RFC4124" format="default"/> to be used as one of the path constraints.</t>
        </section>
        <section anchor="sect-4.5" numbered="true" toc="default">
          <name>Summary</name>
          <t>
   This section summarizes the features of the VN
   YANG.</t>
   YANG data model.</t>
          <ul spacing="normal">
            <li>Maintenance of AP APs and VNAP VNAPs along with the VN</li>
            <li>VN construct to group of edge-to-edge links</li>
            <li>
              <t>Ability
            <li><t>Ability to support various VN and VNS Types
              </t> types</t>
              <ul spacing="normal">
                <li>VN Type 1: Customer configures the VN as a set of VN
             Members.
                members.  No other details need to be set by the customer,
                making for a simplified operation for the customer.</li>
                <li>VN
                <li><t>VN Type 2: Along with VN Members, members, the customer could
                also provide an abstract topology, this topology is provided
                by the Abstract TE Topology YANG Model.</li> data model.</t>
		<ul spacing="normal">
		  <li>Note that the VN Type type is not explicitly identified in
		  the VN Yang YANG data model, as the VN Model YANG data model is exactly the same for
		  both VN Type 1 and VN Type 2. The VN type can be implicitly known
		  based on the referenced TE topology and whether the
		  connectivity matrix includes the underlay path (Type 2) or
		  not (Type 1).</li>
		</ul>
		</li>
              </ul>
            </li>
            <li>VN Compute (pre-instantiate)</li>
            <li>Multi-Source / Multi-Destination</li>

          </ul>
        </section>
      </section>

    <section anchor="sect-5" numbered="true" toc="default">
      <name>VN YANG Data Model (Tree Structure)</name>
      <artwork

      <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="yangtree"><![CDATA[
module: ietf-vn
  +--rw access-point
  |  +--rw ap* [id]
  |     +--rw id               ap-id
  |     +--rw pe?
  |     |       -> /nw:networks/network/node/tet:te-node-id
  |     +--rw max-bandwidth?   te-types:te-bandwidth
  |     +--rw avl-bandwidth?   te-types:te-bandwidth
  |     +--rw vn-ap* [id]
  |        +--rw id               ap-id
  |        +--rw vn?              -> /virtual-network/vn/id
  |        +--rw abstract-node?   -> /nw:networks/network/node/node-id /nw:networks/network/node/\
node-id
  |        +--rw ltp?             leafref
  |        +--ro max-bandwidth?   te-types:te-bandwidth
  +--rw virtual-network
     +--rw vn* [id]
        +--rw id                        vn-id
        +--rw te-topology-identifier
        |  +--rw provider-id?   te-global-id
        |  +--rw client-id?     te-global-id
        |  +--rw topology-id?   te-topology-id
        +--rw abstract-node?
        |       -> /nw:networks/network/node/tet:te-node-id
        +--rw vn-member* [id]
        |  +--rw id                        vnm-id
        |  +--rw src
        |  |  +--rw ap?          -> /access-point/ap/id
        |  |  +--rw vn-ap-id?
        |  |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/\
vn-ap/id
        |  |  +--rw multi-src?   boolean {multi-src-dest}?
        |  +--rw dest
        |  |  +--rw ap?           -> /access-point/ap/id
        |  |  +--rw vn-ap-id?
        |  |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/\
vn-ap/id
        |  |  +--rw multi-dest?   boolean {multi-src-dest}?
        |  +--rw connectivity-matrix-id?   leafref
        |  +--rw underlay
        |  +--ro oper-status?              te-types:te-oper-status
        |  +--ro if-selected?              boolean {multi-src-dest}?
        +--rw admin-status?             te-types:te-admin-status
        +--ro oper-status?              te-types:te-oper-status
        +--rw vn-level-diversity?       te-types:te-path-disjointness

  rpcs:
    +---x vn-compute
       +---w input
       |  +---w te-topology-identifier
       |  |  +---w provider-id?   te-global-id
       |  |  +---w client-id?     te-global-id
       |  |  +---w topology-id?   te-topology-id
       |  +---w abstract-node?
       |  |       -> /nw:networks/network/node/tet:te-node-id
       |  +---w path-constraints
       |  |  +---w te-bandwidth
       |  |  |  +---w (technology)?
       |  |  |        ...
       |  |  +---w link-protection?          identityref
       |  |  +---w setup-priority?           uint8
       |  |  +---w hold-priority?            uint8
       |  |  +---w signaling-type?           identityref
       |  |  +---w path-metric-bounds
       |  |  |  +---w path-metric-bound* [metric-type]
       |  |  |        ...
       |  |  +---w path-affinities-values
       |  |  |  +---w path-affinities-value* [usage]
       |  |  |        ...
       |  |  +---w path-affinity-names
       |  |  |  +---w path-affinity-name* [usage]
       |  |  |        ...
       |  |  +---w path-srlgs-lists
       |  |  |  +---w path-srlgs-list* [usage]
       |  |  |        ...
       |  |  +---w path-srlgs-names
       |  |  |  +---w path-srlgs-name* [usage]
       |  |  |        ...
       |  |  +---w disjointness?             te-path-disjointness
       |  +---w cos?                      te-types:te-ds-class
       |  +---w optimizations
       |  |  +---w (algorithm)?
       |  |     +--:(metric) {path-optimization-metric}?
       |  |     |     ...
       |  |     +--:(objective-function)
       |  |              {path-optimization-objective-function}?
       |  |           ...
       |  +---w vn-member-list* [id]
       |  |  +---w id                        vnm-id
       |  |  +---w src
       |  |  |  +---w ap?          -> /access-point/ap/id
       |  |  |  +---w vn-ap-id?
       |  |  |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/\
vn-ap/id
       |  |  |  +---w multi-src?   boolean {multi-src-dest}?
       |  |  +---w dest
       |  |  |  +---w ap?           -> /access-point/ap/id
       |  |  |  +---w vn-ap-id?
       |  |  |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/\
vn-ap/id
       |  |  |  +---w multi-dest?   boolean {multi-src-dest}?
       |  |  +---w connectivity-matrix-id?   leafref
       |  |  +---w underlay
       |  |  +---w path-constraints
       |  |  |  +---w te-bandwidth
       |  |  |  |     ...
       |  |  |  +---w link-protection?          identityref
       |  |  |  +---w setup-priority?           uint8
       |  |  |  +---w hold-priority?            uint8
       |  |  |  +---w signaling-type?           identityref
       |  |  |  +---w path-metric-bounds
       |  |  |  |     ...
       |  |  |  +---w path-affinities-values
       |  |  |  |     ...
       |  |  |  +---w path-affinity-names
       |  |  |  |     ...
       |  |  |  +---w path-srlgs-lists
       |  |  |  |     ...
       |  |  |  +---w path-srlgs-names
       |  |  |  |     ...
       |  |  |  +---w disjointness?             te-path-disjointness
       |  |  +---w cos?                      te-types:te-ds-class
       |  |  +---w optimizations
       |  |     +---w (algorithm)?
       |  |           ...
       |  +---w vn-level-diversity?       te-types:te-path-disjointness       te-types:te-path-\
disjointness
       +--ro output
          +--ro te-topology-identifier
          |  +--ro provider-id?   te-global-id
          |  +--ro client-id?     te-global-id
          |  +--ro topology-id?   te-topology-id
          +--ro abstract-node?
          |       -> /nw:networks/network/node/tet:te-node-id
          +--ro vn-member-list* [id]
             +--ro id                        vnm-id
             +--ro src
             |  +--ro ap?          -> /access-point/ap/id
             |  +--ro vn-ap-id?
             |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/\
vn-ap/id
             |  +--ro multi-src?   boolean {multi-src-dest}?
             +--ro dest
             |  +--ro ap?           -> /access-point/ap/id
             |  +--ro vn-ap-id?
             |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id /access-point/ap[id=current()/../ap]/\
vn-ap/id
             |  +--ro multi-dest?   boolean {multi-src-dest}?
             +--ro connectivity-matrix-id?   leafref
             +--ro underlay
             +--ro if-selected?              boolean {multi-src-dest}? {multi-src-\
dest}?
             +--ro compute-status?           vn-compute-status
             +--ro error-info
                +--ro error-description?   string
                +--ro error-timestamp?     yang:date-and-time
                +--ro error-reason?        identityref

]]></artwork>        identityref]]></sourcecode>

    </section>
    <section anchor="sect-6" numbered="true" toc="default">
      <name>VN YANG Data Model</name>
      <t>
   The

      <t>The VN YANG data model is as follows:</t>
      <sourcecode name="ietf-vn@2024-06-22.yang" type="" name="ietf-vn@2025-01-27.yang" type="yang" markers="true"><![CDATA[
module ietf-vn {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
  prefix vn;

  /* Import common YANG types */

  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types";
  }

  /* Import network */

  import ietf-network {
    prefix nw;
    reference
      "RFC 8345: A YANG Data Model for Network Topologies";
  }

  /* Import network topology */

  import ietf-network-topology {
    prefix nt;
    reference
      "RFC 8345: A YANG Data Model for Network Topologies";
  }

  /* Import TE Common types */

  import ietf-te-types {
    prefix te-types;
    reference
      "RFC 8776: Common YANG Data Types for Traffic Engineering";
  }

  /* Import TE Topology */

  import ietf-te-topology {
    prefix tet;
    reference
      "RFC 8795: YANG Data Model for Traffic Engineering (TE)
                 Topologies";
  }

  organization
    "IETF Traffic Engineering Architecture and Signaling (TEAS)
     Working Group";
  contact
    "WG Web:  <https://datatracker.ietf.org/wg/teas/>
     WG List:  <mailto:teas@ietf.org>

     Editor:  Young Lee <younglee.tx@gmail.com>
           :
     Editor:  Dhruv Dhody <dhruv.ietf@gmail.com>";
  description
    "This module contains a YANG module for the Virtual Network (VN).
     It describes a VN operation module that can take place
     in the context of the Customer Network Controller (CNC)- (CNC) -
     Multi-Domain Service Coordinator (MDSC) interface (CMI) of
     the Abstraction and Control of Traffic Engineered (TE) TE Networks (ACTN)
     architecture where the CNC is the actor of a VN Instantiation/modification/deletion
     instantiation/modification/deletion as per RFC 8453.

     This module uses following abbreviations:
     - VN: Virtual Network
     - AP: Access Point
     - VNAP: Virtual Network Access Point
     - LTP: Link Termination Point
     - PE: Provider Edge
     - COS: Class of Service

     Further, 'src' and 'dest' is used for source and destination
     respectively.

     Copyright (c) 2024 2025 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; 9731; see the
     RFC itself for full legal notices.";

  revision 2024-06-22 2025-01-27 {
    description
      "The initial version.";
    reference
      "RFC XXXX: 9731: A YANG Data Model for Virtual Network (VN)
                 Operations";
  }

  /* Features */

  feature multi-src-dest {
    description
      "Support for selection of one src source or destination
       among multiple.";
    reference
      "RFC 8453: Framework for Abstraction and Control of TE
                 Networks (ACTN)";
  }

  /* Typedef */

  typedef vn-id {
    type string {
      length "1..max";
    }
    description
      "A type definition for Virtual Network (VN) a VN identifier.";
  }

  typedef ap-id {
    type string {
      length "1..max";
    }
    description
      "A type definition for an Access Point (AP) identifier.";
  }

  typedef vnm-id {
    type string {
      length "1..max";
    }
    description
      "A type definition for VN member a VN-member identifier.";
  }

  typedef vn-compute-status {
    type te-types:te-common-status;
    description
      "A type definition for representing the VN compute status.
       Note that all statuses apart from up and down are considered as
       to be unknown.";
  }

  /* identities */

  identity vn-computation-error-reason {
    description
      "Base identity for VN computation error reasons.";
  }

  identity vn-computation-error-not-ready {
    base vn-computation-error-reason;
    description
      "VN computation has failed because the MDSC is not
       ready.";
  }

  identity vn-computation-error-no-cnc {
    base vn-computation-error-reason;
    description
      "VN computation has failed because one or more dependent
       CNC
       CNCs are unavailable.";
  }

  identity vn-computation-error-no-resource {
    base vn-computation-error-reason;
    description
      "VN computation has failed because there is no
       available resource in one or more domains.";
  }

  identity vn-computation-error-path-not-found {
    base vn-computation-error-reason;
    description
      "VN computation failed as no path found.";
  }

  identity vn-computation-ap-unknown {
    base vn-computation-error-reason;
    description
      "VN computation failed as the source or destination Access
       Point (AP) not known.";
  }

  /* Groupings */

  grouping vn-member {
    description
      "The vn-member is described by this grouping.";
    leaf id {
      type vnm-id;
      description
        "A vn-member identifier.";
    }
    container src {
      description
        "The source of VN Member."; member.";
      leaf ap {
        type leafref {
          path "/access-point/ap/id";
        }
        description
          "A reference to the source AP.";
      }
      leaf vn-ap-id {
        type leafref {
          path "/access-point/ap[id=current()/../ap]/vn-ap"
             + "/id";
        }
        description
          "A reference to the source VNAP.";
      }
      leaf multi-src {
        if-feature "multi-src-dest";
        type boolean;
        default "false";
        description
          "Is the source part of a multi-source, where
           only one of the sources is enabled."; enabled?";
      }
    }
    container dest {
      description
        "the
        "The destination of the VN Member."; member.";
      leaf ap {
        type leafref {
          path "/access-point/ap/id";
        }
        description
          "A reference to the destination AP.";
      }
      leaf vn-ap-id {
        type leafref {
          path "/access-point/ap[id=current()/../ap]/"
             + "vn-ap/id";
        }
        description
          "A reference to dest the destination VNAP.";
      }
      leaf multi-dest {
        if-feature "multi-src-dest";
        type boolean;
        default "false";
        description
          "Is the destination part of a multi-destination,
           where only one of the destinations is enabled.";
      }
    }
    leaf connectivity-matrix-id {
      type leafref {
        path "/nw:networks/nw:network/nw:node/tet:te/"
           + "tet:te-node-attributes/"
           + "tet:connectivity-matrices/"
           + "tet:connectivity-matrix/tet:id";
      }
      description
        "A reference to the connectivity-matrix.";
      reference
        "RFC 8795: YANG Data Model for Traffic Engineering (TE)
                   Topologies";
    }
    container underlay {
      description
        "An empty container that can be augmented with underlay
         technology information not supported by RFC 8795 (for
         example -
         example, Segment Routing (SR).";
    }
    reference
      "RFC 8454: Information Model for Abstraction and Control of TE
                 Networks (ACTN)";

      "RFC 8795: YANG Data Model for Traffic Engineering (TE)
                 Topologies";
  }

  grouping vn-policy {
    description
      "policy for VN-level diversity";
    leaf vn-level-diversity {
      type te-types:te-path-disjointness;
      description
        "The type of disjointness on the VN level (i.e., across all
         VN members).";
    }
  }

  /* Configuration data nodes */

  container access-point {
    description
      "AP configurations"; configurations.";
    list ap {
      key "id";
      description
        "access-point
        "The access-point identifier.";
      leaf id {
        type ap-id;
        description
          "An AP identifier unique within the scope of the entity
           that controls the VN.";
      }
      leaf pe {
        type leafref {
          path "/nw:networks/nw:network/nw:node/tet:te-node-id";
        }
        description
          "A reference to the PE node in the native TE Topology.";
      }
      leaf max-bandwidth {
        type te-types:te-bandwidth;
        description
          "The max bandwidth of the AP.";
      }
      leaf avl-bandwidth {
        type te-types:te-bandwidth;
        description
          "The available bandwidth of the AP.";
      }
      list vn-ap {
        key "id";
        leaf id {
          type ap-id;
          description
            "A unique identifier for the VNAP.";
        }
        leaf vn {
          type leafref {
            path "/virtual-network/vn/id";
          }
          description
            "A reference to the VN.";
        }
        leaf abstract-node {
          type leafref {
            path "/nw:networks/nw:network/nw:node/nw:node-id";
          }
          must '/nw:networks/nw:network/nw:node[nw:node-id='
             + 'current()/../abstract-node]/tet:te-node-id' {
            description
              "The associated network for the abstract-node
               must be TE enabled.";
          }
          description
            "A reference to the abstract node that represent represents
             the VN.";
        }
        leaf ltp {
          type leafref {
            path "/nw:networks/nw:network/nw:node[nw:node-id="
               + "current()/../abstract-node]/nt:termination-point/"
               + "tet:te-tp-id";
          }
          description
            "A reference to the Link Termination Point (LTP)
             in the
             abstract-node i.e. abstract-node, i.e., the LTP should be in
             the abstract
             layer, layer and not the underlying layer.";
          reference
            "RFC 8795: YANG Data Model for Traffic Engineering (TE)
                       Topologies";
        }
        leaf max-bandwidth {
          type te-types:te-bandwidth;
          config false;
          description
            "The max bandwidth of the VNAP.";
        }
        description
          "List of VNAP VNAPs in this AP.";
      }
    }
    reference
      "RFC 8453: Framework for Abstraction and Control of TE
                 Networks (ACTN), Section 6";
  }
  container virtual-network {
    description
      "VN configurations.";
    list vn {
      key "id";
      description
        "A virtual network VN is identified by a vn-id.";
      leaf id {
        type vn-id;
        description
          "An identifier unique within the scope of the entity
           that controls the VN.";
      }
      uses te-types:te-topology-identifier;
      leaf abstract-node {
        type leafref {
          path "/nw:networks/nw:network/nw:node/tet:te-node-id";
        }
        description
          "A reference to the abstract node in TE Topology.";
      }
      list vn-member {
        key "id";
        description
          "List of vn-members in a VN.";
        uses vn-member;
        leaf oper-status {
          type te-types:te-oper-status;
          config false;
          description
            "The vn-member operational state.";
        }
        leaf if-selected {
          if-feature "multi-src-dest";
          type boolean;
          default "false";
          config false;
          description
            "Is the vn-member selected among the multi-src/dest
             options."; multi-source
             or multi-destination options?";
        }
      }
      leaf admin-status {
        type te-types:te-admin-status;
        default "up";
        description
          "VN administrative state.";
      }
      leaf oper-status {
        type te-types:te-oper-status;
        config false;
        description
          "VN operational state.";
      }
      uses vn-policy;
    }
    reference
      "RFC 8453: Framework for Abstraction and Control of TE
       Networks (ACTN)";
  }

  /* RPC */

  rpc vn-compute {
    description
      "The VN computation without actual instantiation.  This is
       used by the CNC to get the VN results without actually
       creating it in the network.

       The input could include a reference to the single-node
       -abstract single node
       abstract topology.  It could optionally also include
       constraints and optimization criteria.  The computation
       is done based on the list of VN-members. VN members.

       The output includes a reference to the single-node
       -abstract single node
       abstract topology with each VN-member VN member including a
       reference to the connectivity-matrix-id where the
       path properties could be found.  Error information is
       also included.";
    input {
      uses te-types:te-topology-identifier;
      leaf abstract-node {
        type leafref {
          path "/nw:networks/nw:network/nw:node/tet:te-node-id";
        }
        description
          "A reference to the abstract node in TE Topology.";
      }
      uses te-types:generic-path-constraints;
      leaf cos {
        type te-types:te-ds-class;
        description
          "The class of service (COS).";
      }
      uses te-types:generic-path-optimization;
      list vn-member-list {
        key "id";
        description
          "List of VN-members VN members in a VN.";
        uses vn-member;
        uses te-types:generic-path-constraints;
        leaf cos {
          type te-types:te-ds-class;
          description
            "The class of service.";
          reference
            "RFC 4124: Protocol Extensions for Support of
             Diffserv-aware MPLS Traffic Engineering,
             Section 4.3.1";
        }
        uses te-types:generic-path-optimization;
      }
      uses vn-policy;
    }
    output {
      uses te-types:te-topology-identifier;
      leaf abstract-node {
        type leafref {
          path "/nw:networks/nw:network/nw:node/tet:te-node-id";
        }
        description
          "A reference to the abstract node in TE Topology.";
      }
      list vn-member-list {
        key "id";
        description
          "List of VN-members VN members in a VN.";
        uses vn-member;
        leaf if-selected {
          if-feature "multi-src-dest";
          type boolean;
          default "false";
          description
            "Is the vn-member selected among the multi-src/dest
             options."; multi-source or
             multi-destination options?";
          reference
            "RFC 8453: Framework for Abstraction and Control of TE
                       Networks (ACTN), Section 7";
        }
        leaf compute-status {
          type vn-compute-status;
          description
            "The VN-member compute state.";
        }
        container error-info {
          description
            "Error information related to the VN member.";
          leaf error-description {
            type string {
              length "1..max";
            }
            description
              "Textual representation of the error that occurred
               during VN compute.";
          }
          leaf error-timestamp {
            type yang:date-and-time;
            description
              "Timestamp of the attempt.";
          }
          leaf error-reason {
            type identityref {
              base vn-computation-error-reason;
            }
            description
              "Reason for the VN computation error.";
          }
        }
      }
    }
  }
}
]]></sourcecode>

    </section>
    <section anchor="sect-8" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
<!--Begin DNE-->

      The YANG module specified in this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF <xref target="RFC6241" format="default"/> or RESTCONF <xref target="RFC8040" format="default"/>.
   The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH)
   <xref target="RFC6242" format="default"/>.  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS <xref target="RFC8446" format="default"/>.</t>
      <t>
   The NETCONF access control model Network Configuration Access Control Model (NACM) <xref target="RFC8341" format="default"/> provides the means to
   restrict access for particular NETCONF or RESTCONF users to a
   preconfigured subset of all available NETCONF or RESTCONF protocol
      operations and content.</t>

<!--End DNE-->
      <t>
   The model presented in this document is used in the interface
   between the CNC and MDSC, which is referred to as CNC-MDSC
   Interface (CMI). Security risks risks, such as malicious
   attack and rogue elements attempting to connect to the various ACTN
   components
   components, are possible.  Furthermore, some ACTN components (e.g., MDSC)
   represent a single point of failure and threat vector. Also, there is a need to
   manage policy conflicts and eavesdropping of on communication between
   different ACTN components.</t>
   <t>
<!--Begin DNE-->

   There are a number of data nodes defined in this YANG module that are
   writable/creatable/deletable (i.e., "config true", which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., edit-config)
   to these data nodes without proper protection can have a negative
   effect on network operations.  These are the subtrees and data nodes
   and their sensitivity/vulnerability:</t>

<!--End DNE -->
      <ul spacing="normal">
        <li>
          <t>ap: This list includes a set of sensitive data that influences how the access points APs in the VN service are attached. By accessing the following data nodes, an attacker may be able to manipulate the VN.</t>
          <ul spacing="normal">
            <li>id</li>
            <li>pe</li>
            <li>max-bandwidth</li>
            <li>avl-bandwidth</li>
          </ul>
        </li>
        <li>
          <t>vn-ap: This list includes a set of sensitive data that influences how the VN service is delivered. By accessing the following data nodes, an attacker may be able
          to manipulate the VN.</t>
          <ul spacing="normal">
            <li>id</li>
            <li>vn</li>
            <li>abstract-node</li>
            <li>ltp</li>
            <li>max-bandwidth</li>
          </ul>
        </li>
        <li>
          <t>vn: This list includes a set of sensitive data that influences how the VN service is delivered. By accessing the following data nodes, an attacker may be able
          to manipulate the VN.</t>
          <ul spacing="normal">
            <li>id</li>
            <li>te-topology-identifier</li>
            <li>abstract-node</li>
          </ul>
        </li>
        <li>
          <t>vn-member: This list includes a set of sensitive data that influences how the VN member in the VN service is delivered. By accessing the following data nodes, an attacker may be able to manipulate the VN member.</t>
          <ul spacing="normal">
            <li>id</li>
            <li>src/ap</li>
            <li>src/vn-ap-id</li>
            <li>dest/ap</li>
            <li>dest/vn-ap-id</li>
            <li>connectivity-matrix-id</li>
          </ul>
        </li>
      </ul>
<!--Begin DNE-->

      <t>Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  These are the subtrees and data
      nodes and their sensitivity/vulnerability:</t>

<!--End DNE -->
   <ul spacing="normal">
        <li>oper-status: This leaf can reveal the current operational state of the VN.</li>
        <li>if-selected: This leaf can reveal which vn-member is selected among the various multi-src/dest multi-source / multi-destination options.</li>
   </ul>

<!--Begin DNE -->
          <t>Some of the RPC operations in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control access to these operations.  These are the
	  operations and their sensitivity/vulnerability:</t>
<!--End DNE -->

   <ul spacing="normal">
        <li>vn-compute: This RPC triggers the VN computation at the MDSC MDSC, which can reveal the VN information.
        </li>
        </ul>
    </section>
    <section anchor="sect-9" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   IANA is requested to make

      <t>IANA has made the following allocation for the URIs a URI in
      the "ns" subregistry registry within the "IETF XML Registry" registry group <xref
      target="RFC3688" format="default"/>:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
URI: urn:ietf:params:xml:ns:yang:ietf-vn
Registrant Contact: The IESG.
XML: N/A,
   <dl spacing="compact" newline="false">
     <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-vn</dd>
     <dt>Registrant Contact:</dt> <dd>The IESG.</dd>
     <dt>XML:</dt> <dd>N/A, the requested URI is an XML namespace.

]]></artwork>
      <t>
    IANA is requested to make namespace.</dd>
   </dl>

      <t>IANA has made the following allocation for the VN YANG module
      data model (see <xref target="sect-5" format="default"/> in the "YANG Module Names" registry <xref target="RFC6020"
      format="default"/>:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
name:         ietf-vn
namespace:    urn:ietf:params:xml:ns:yang:ietf-vn
prefix:       vn
reference:    RFC XXXX

]]></artwork>
    </section>
    <section anchor="sect-10" numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>
   The authors would like to thank Xufeng Liu, Adrian Farrel, Tom Petch, Mohamed Boucadair, Italo Busi, Bo Wu and Daniel King for their helpful comments and valuable suggestions.</t>
      <t>Thanks to Andy Bierman for YANGDIR review. Thanks to Darren Dukes for RTGDIR review. Thanks to Behcet Sarikaya for GENART review. Thanks to Bo Wu for OPSDIR review. Thanks to Shivan Sahib for SECDIR review. Thanks to Susan Hares for RTGDIR review.</t>
      <t>Thanks to Deb Cooley, Francesca Palombini, Gunter Van de Velde, and Mahesh Jethanandani for IESG review.</t>
   <dl spacing="compact" newline="false">
     <dt>name:</dt> <dd>ietf-vn</dd>
     <dt>namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-vn</dd>
     <dt>prefix:</dt> <dd>vn</dd>
     <dt>reference:</dt> <dd>RFC 9731</dd>
   </dl>

    </section>

  </middle>
  <back>
    <displayreference target="I-D.ietf-teas-te-service-mapping-yang" to="TE-SERVICE-MAPPING"/>
    <displayreference target="I-D.ietf-teas-actn-pm-telemetry-autonomics" to="TEAS-ACTN-PM"/>
    <displayreference target="I-D.ietf-ccamp-l1csm-yang" to="L1CSM-YANG"/>
    <displayreference target="I-D.ietf-teas-yang-te" to="YANG-TE"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4124.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4124.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8776.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8776.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
        <!--<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>--> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8795.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8795.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7926.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7926.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8454.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8454.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
	        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/>

<!--[I-D.ietf-teas-te-service-mapping-yang] IESG state: I-D Exists as of 10/03/24-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-te-service-mapping-yang.xml"/>

<!--[I-D.ietf-teas-actn-pm-telemetry-autonomics] IESG state: I-D Exists as of 10/03/24-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-actn-pm-telemetry-autonomics.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ccamp-l1csm-yang.xml"/>

<!--[I-D.ietf-ccamp-l1csm-yang] IESG state: RFC Ed Queue (MISSREF) as of 10/03/24: (C502); used the long-form reference to fix Oscar's name. -->

<reference anchor="I-D.ietf-ccamp-l1csm-yang" target="https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-l1csm-yang-26">
   <front>
      <title>A YANG Data Model for L1 Connectivity Service Model (L1CSM)</title>
      <author initials="Y." surname="Lee" fullname="Young Lee">
         <organization>Samsung</organization>
      </author>
      <author initials="K." surname="Lee" fullname="Kwang-koog Lee">
         <organization>Korea Telecom</organization>
      </author>
      <author initials="H." surname="Zheng" fullname="Haomian Zheng">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez de Dios">
         <organization>Telefonica</organization>
      </author>
      <author initials="D." surname="Ceccarelli" fullname="Daniele Ceccarelli">
         <organization>Cisco</organization>
      </author>
      <date month="April" day="11" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-ccamp-l1csm-yang-26" />

</reference>

<!-- [I-D.ietf-teas-yang-te] IESG state: I-D Exists as of 1/24/25-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-yang-te.xml"/>
      </references>
    </references>
    <section anchor="sect-constraints" numbered="true" toc="default">
      <name>Performance Constraints</name>

      <t>At the time of creation of a VN, it is natural to provide VN level VN-level constraints and optimization criteria. It should be noted that this the VN YANG module data model described in this document relies on the TE-Topology Model TE Topology model in <xref target="RFC8795" format="default"/> by using a reference to an abstract node to achieve this. provide VN-level constraints and optimization criteria.  Further, the connectivity-matrix structure is used to assign the constraints and optimization criteria including delay, jitter jitter, etc. <xref target="RFC8776" format="default"/> defines some of the metric-types already and metric-types; future documents are meant to augment it.</t>
      <t>Note that the VN compute allows the inclusion of the constraints and the optimization criteria directly in the RPC to allow it to be used independently.</t>
    </section>
    <section anchor="sect-7" numbered="true" toc="default">
      <name>JSON Example</name>
      <section anchor="sect-7-1" numbered="true" toc="default">
        <name>VN JSON</name>
 <t>
   This section provides JSON examples of how the VN YANG
   data model and TE topology Topology YANG data model are used together to instantiate a VN.</t>
      <t>
   The example in this section includes the following VN</t> VNs:</t>
      <ul spacing="normal">
        <li>VN1 (Type 1): Which This VN maps to the single node topology abstract1
      and consist consists of VN Members members 104 (L1 to L4), 107 (L1 to
      L7), 204 (L2 to L4), 308 (L3 to L8) L8), and 108 (L1 to L8).</li>
        <li>VN2 (Type 2): Which This VN maps to the single node topology abstract2, abstract2;
        this topology has an underlay topology (called underlay).
        This VN has a single VN member 105 (L1 to
      L5) and an underlay path (S4 and S7) has been set in the
      connectivity matrix of the abstract2 topology;</li>
        <li>VN3 (Type 1): This VN has a multi-source and multi-destination
      feature enabled. VN Member member 106 (L1 to L6) and 107 (L1 to L7)
      showcase multi-dest and VN Member member 108 (L1 to L8) and 308 (L3 to L8) showcase the multi-src feature. The selected VN-member VN member is known via the field "if-selected" and the corresponding connectivity-matrix-id.</li>
      </ul>

      <figure>
	<name>Example</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
L1---104---L4             L1---105---L5             L1---106---L6(md)
L1---107---L7             Underlay Path:            L1---107---L7(md)
L2---204---L4                (S4 and S7)            L1---108---L8(ms)
L3---308---L8                                       L3---308---L8(ms)
L1---108---L8

     ---                       ---                       ---
     VN1                       VN2                       VN3
     ---                       ---                       ---
      ]]></artwork>                       ---]]></artwork>
</figure>

      <t>
   Note that the VN YANG data model also includes the AP and VNAP VNAP, which shows
   various VN VNs using the same AP.</t>
        <artwork

       <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="json"><![CDATA[
{
  "ietf-vn:access-point": {
    "ap": [
      {
        "id": "101",
        "vn-ap": [
          {
            "id": "10101",
            "vn": "1",
            "abstract-node": "192.0.2.1",
            "ltp": "203.0.113.11"
          },
          {
            "id": "10102",
            "vn": "2",
            "abstract-node": "192.0.2.2",
            "ltp": "203.0.113.12"
          },
          {
            "id": "10103",
            "vn": "3",
            "abstract-node": "192.0.2.3",
            "ltp": "203.0.113.13"
          }
        ]
      },
      {
        "id": "202",
        "vn-ap": [
          {
            "id": "20201",
            "vn": "1",
            "abstract-node": "192.0.2.1",
            "ltp": "203.0.113.21"
          }
        ]
      },
      {
        "id": "303",
        "vn-ap": [
          {
            "id": "30301",
            "vn": "1",
            "abstract-node": "192.0.2.1",
            "ltp": "203.0.113.31"
          },
          {
            "id": "30303",
            "vn": "3",
            "abstract-node": "192.0.2.3",
            "ltp": "203.0.113.33"
          }
        ]
      },
      {
        "id": "404",
        "vn-ap": [
          {
            "id": "40401",
            "vn": "1",
            "abstract-node": "192.0.2.1",
            "ltp": "203.0.113.41"
          }
        ]
      },
      {
        "id": "505",
        "vn-ap": [
          {
            "id": "50502",
            "vn": "2",
            "abstract-node": "192.0.2.2",
            "ltp": "203.0.113.52"
          }
        ]
      },
      {
        "id": "606",
        "vn-ap": [
          {
            "id": "60603",
            "vn": "3",
            "abstract-node": "192.0.2.3",
            "ltp": "203.0.113.63"
          }
        ]
      },
      {
        "id": "707",
        "vn-ap": [
          {
            "id": "70701",
            "vn": "1",
            "abstract-node": "192.0.2.1",
            "ltp": "203.0.113.71"
          },
          {
            "id": "70703",
            "vn": "3",
            "abstract-node": "192.0.2.3",
            "ltp": "203.0.113.73"
          }
        ]
      },
      {
        "id": "808",
        "vn-ap": [
          {
            "id": "80801",
            "vn": "1",
            "abstract-node": "192.0.2.1",
            "ltp": "203.0.113.81"
          },
          {
            "id": "80803",
            "vn": "3",
            "abstract-node": "192.0.2.3",
            "ltp": "203.0.113.83"
          }
        ]
      }
    ]
  },
  "ietf-vn:virtual-network": {
    "vn": [
      {
        "id": "1",
        "te-topology-identifier": {
          "topology-id": "abstract1"
        },
        "abstract-node": "192.0.2.1",
        "vn-member": [
          {
            "id": "104",
            "src": {
              "ap": "101",
              "vn-ap-id": "10101"
            },
            "dest": {
              "ap": "404",
              "vn-ap-id": "40401"
            },
            "connectivity-matrix-id": 10104
          },
          {
            "id": "107",
            "src": {
              "ap": "101",
              "vn-ap-id": "10101"
            },
            "dest": {
              "ap": "707",
              "vn-ap-id": "70701"
            },
            "connectivity-matrix-id": 10107
          },
          {
            "id": "204",
            "src": {
              "ap": "202",
              "vn-ap-id": "20201"
            },
            "dest": {
              "ap": "404",
              "vn-ap-id": "40401"
            },
            "connectivity-matrix-id": 10204
          },
          {
            "id": "308",
            "src": {
              "ap": "303",
              "vn-ap-id": "30301"
            },
            "dest": {
              "ap": "808",
              "vn-ap-id": "80801"
            },
            "connectivity-matrix-id": 10308
          },
          {
            "id": "108",
            "src": {
              "ap": "101",
              "vn-ap-id": "10101"
            },
            "dest": {
              "ap": "808",
              "vn-ap-id": "80801"
            },
            "connectivity-matrix-id": 10108
          }
        ]
      },
      {
        "id": "2",
        "te-topology-identifier": {
          "topology-id": "abstract2"
        },
        "abstract-node": "192.0.2.2",
        "vn-member": [
          {
            "id": "105",
            "src": {
              "ap": "101",
              "vn-ap-id": "10102"
            },
            "dest": {
              "ap": "505",
              "vn-ap-id": "50502"
            },
            "connectivity-matrix-id": 20105
          }
        ]
      },
      {
        "id": "3",
        "te-topology-identifier": {
          "topology-id": "abstract3"
        },
        "abstract-node": "192.0.2.3",
        "vn-member": [
          {
            "id": "106",
            "src": {
              "ap": "101",
              "vn-ap-id": "10103"
            },
            "dest": {
              "ap": "606",
              "vn-ap-id": "60603",
              "multi-dest": true
            },
            "connectivity-matrix-id": 30106,
            "if-selected": false
          },
          {
            "id": "107",
            "src": {
              "ap": "101",
              "vn-ap-id": "10103"
            },
            "dest": {
              "ap": "707",
              "vn-ap-id": "70703",
              "multi-dest": true
            },
            "connectivity-matrix-id": 30107,
            "if-selected": true
          },
          {
            "id": "108",
            "src": {
              "ap": "101",
              "vn-ap-id": "10103",
              "multi-src": true
            },
            "dest": {
              "ap": "808",
              "vn-ap-id": "80803",
            },
            "connectivity-matrix-id": 30108,
            "if-selected": false
          },
          {
            "id": "308",
            "src": {
              "ap": "303",
              "vn-ap-id": "30303",
              "multi-src": true
            },
            "dest": {
              "ap": "808",
              "vn-ap-id": "80803"
            },
            "connectivity-matrix-id": 30308,
            "if-selected": true
          }
        ]
      }
    ]
  }
}
]]></artwork>
}]]></sourcecode>

      </section>
      <section anchor="sect-7-2" numbered="true" toc="default">
        <name>TE-topology
        <name>TE Topology JSON</name>
<t>
   This section provides JSON examples of the various TE topology instances.</t>
      <t>
   The example in this section includes the following TE Topologies</t> Topologies:</t>
      <ul spacing="normal">
        <li>abstract1: a single node TE topology referenced by VN1.  We also
      show how disjointness (node, link, Shared Risk Link Group (SRLG)) is supported in the example on the connectivity matrices.</li>
        <li>abstract2: a single node TE topology referenced by VN2 with an underlay path.</li>
        <li>underlay: the topology with multiple nodes (in the underlay path of abstract2). For brevity, the example includes only the node and node: other parameters are not included.</li>
        <li>abstract3: a single node TE topology referenced by VN3.</li>
      </ul>
        <artwork

        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="json"><![CDATA[
{
  "ietf-network:networks": {
    "network": [
      {
        "network-types": {
          "ietf-te-topology:te-topology": {}
        },
        "network-id": "example:abstract1",
        "ietf-te-topology:te-topology-identifier": {
          "provider-id": 0,
          "client-id": 0,
          "topology-id": "example:abstract1"
        },
        "node": [
          {
            "node-id": "example:192.0.2.1",
            "ietf-network-topology:termination-point": [
              {
                "tp-id": "example:1-0-1",
                "ietf-te-topology:te-tp-id": "203.0.113.11"
              },
              {
                "tp-id": "example:1-0-2",
                "ietf-te-topology:te-tp-id": "203.0.113.21"
              },
              {
                "tp-id": "example:1-0-3",
                "ietf-te-topology:te-tp-id": "203.0.113.31"
              },
              {
                "tp-id": "example:1-0-4",
                "ietf-te-topology:te-tp-id": "203.0.113.41"
              },
              {
                "tp-id": "example:1-0-7",
                "ietf-te-topology:te-tp-id": "203.0.113.71"
              },
              {
                "tp-id": "example:1-0-8",
                "ietf-te-topology:te-tp-id": "203.0.113.81"
              }
            ],
            "ietf-te-topology:te-node-id": "192.0.2.1",
            "ietf-te-topology:te": {
              "te-node-attributes": {
                "domain-id": 1,
                "is-abstract": [
                  null
                ],
                "connectivity-matrices": {
                  "is-allowed": true,
                  "path-constraints": {
                    "te-bandwidth": {
                      "generic": "0x1p10"
                    },
                    "disjointness": "node link srlg"
                  },
                  "connectivity-matrix": [
                    {
                      "id": 10104,
                      "from": {
                        "tp-ref": "example:1-0-1"
                      },
                      "to": {
                        "tp-ref": "example:1-0-4"
                      }
                    },
                    {
                      "id": 10107,
                      "from": {
                        "tp-ref": "example:1-0-1"
                      },
                      "to": {
                        "tp-ref": "example:1-0-7"
                      }
                    },
                    {
                      "id": 10204,
                      "from": {
                        "tp-ref": "example:1-0-2"
                      },
                      "to": {
                        "tp-ref": "example:1-0-4"
                      }
                    },
                    {
                      "id": 10308,
                      "from": {
                        "tp-ref": "example:1-0-3"
                      },
                      "to": {
                        "tp-ref": "example:1-0-8"
                      }
                    },
                    {
                      "id": 10108,
                      "from": {
                        "tp-ref": "example:1-0-1"
                      },
                      "to": {
                        "tp-ref": "example:1-0-8"
                      }
                    }
                  ]
                }
              }
            }
          }
        ]
      },
      {
        "network-types": {
          "ietf-te-topology:te-topology": {}
        },
        "network-id": "example:abstract2",
        "ietf-te-topology:te-topology-identifier": {
          "provider-id": 0,
          "client-id": 0,
          "topology-id": "example:abstract2"
        },
        "node": [
          {
            "node-id": "example:192.0.2.2",
            "ietf-network-topology:termination-point": [
              {
                "tp-id": "example:2-0-1",
                "ietf-te-topology:te-tp-id": "203.0.113.12"
              },
              {
                "tp-id": "example:2-0-5",
                "ietf-te-topology:te-tp-id": "203.0.113.52"
              }
            ],
            "ietf-te-topology:te-node-id": "192.0.2.2",
            "ietf-te-topology:te": {
              "te-node-attributes": {
                "domain-id": 1,
                "is-abstract": [
                  null
                ],
                "connectivity-matrices": {
                  "is-allowed": true,
                  "underlay": {
                    "enabled": true
                  },
                  "path-constraints": {
                    "te-bandwidth": {
                      "generic": "0x1p10"
                    }
                  },
                  "optimizations": {
                    "objective-function": {
                      "objective-function-type":
                       "ietf-te-types:of-maximize-residual-bandwidth"
                    }
                  },
                  "ietf-te-topology:connectivity-matrix": [
                    {
                      "id": 20105,
                      "from": {
                        "tp-ref": "example:2-0-1"
                      },
                      "to": {
                        "tp-ref": "example:2-0-5"
                      },
                      "underlay": {
                        "enabled": true,
                        "primary-path": {
                          "network-ref": "example:underlay",
                          "path-element": [
                            {
                              "path-element-id": 1,
                              "numbered-node-hop": {
                                "node-id": "198.51.100.44",
                                "hop-type": "strict"
                              }
                            },
                            {
                              "path-element-id": 2,
                              "numbered-node-hop": {
                                "node-id": "198.51.100.77",
                                "hop-type": "strict"
                              }
                            }
                          ]
                        }
                      }
                    }
                  ]
                }
              }
            }
          }
        ]
      },
      {
        "network-types": {
          "ietf-te-topology:te-topology": {}
        },
        "network-id": "example:underlay",
        "ietf-te-topology:te-topology-identifier": {
          "provider-id": 0,
          "client-id": 0,
          "topology-id": "example:underlay"
        },
        "node": [
          {
            "node-id": "example:198.51.100.11",
            "ietf-te-topology:te-node-id": "198.51.100.11"
          },
          {
            "node-id": "example:198.51.100.22",
            "ietf-te-topology:te-node-id": "198.51.100.22"
          },
          {
            "node-id": "example:198.51.100.33",
            "ietf-te-topology:te-node-id": "198.51.100.33"
          },
          {
            "node-id": "example:198.51.100.44",
            "ietf-te-topology:te-node-id": "198.51.100.44"
          },
          {
            "node-id": "example:198.51.100.55",
            "ietf-te-topology:te-node-id": "198.51.100.55"
          },
          {
            "node-id": "example:198.51.100.66",
            "ietf-te-topology:te-node-id": "198.51.100.66"
          },
          {
            "node-id": "example:198.51.100.77",
            "ietf-te-topology:te-node-id": "198.51.100.77"
          },
          {
            "node-id": "example:198.51.100.88",
            "ietf-te-topology:te-node-id": "198.51.100.88"
          },
          {
            "node-id": "example:198.51.100.99",
            "ietf-te-topology:te-node-id": "198.51.100.99"
          }
        ]
      },
      {
        "network-types": {
          "ietf-te-topology:te-topology": {}
        },
        "network-id": "example:abstract3",
        "ietf-te-topology:te-topology-identifier": {
          "provider-id": 0,
          "client-id": 0,
          "topology-id": "example:abstract3"
        },
        "node": [
          {
            "node-id": "example:192.0.2.3",
            "ietf-network-topology:termination-point": [
              {
                "tp-id": "example:3-0-1",
                "ietf-te-topology:te-tp-id": "203.0.113.13"
              },
              {
                "tp-id": "example:3-0-3",
                "ietf-te-topology:te-tp-id": "203.0.113.33"
              },
              {
                "tp-id": "example:3-0-6",
                "ietf-te-topology:te-tp-id": "203.0.113.63"
              },
              {
                "tp-id": "example:3-0-7",
                "ietf-te-topology:te-tp-id": "203.0.113.73"
              },
              {
                "tp-id": "example:3-0-8",
                "ietf-te-topology:te-tp-id": "203.0.113.83"
              }
            ],
            "ietf-te-topology:te-node-id": "192.0.2.3",
            "ietf-te-topology:te": {
              "te-node-attributes": {
                "domain-id": 3,
                "is-abstract": [
                  null
                ],
                "connectivity-matrices": {
                  "is-allowed": true,
                  "path-constraints": {
                    "te-bandwidth": {
                      "generic": "0x1p10"
                    }
                  },
                  "connectivity-matrix": [
                    {
                      "id": 30107,
                      "from": {
                        "tp-ref": "example:3-0-1"
                      },
                      "to": {
                        "tp-ref": "example:3-0-7"
                      }
                    },
                    {
                      "id": 30106,
                      "from": {
                        "tp-ref": "example:3-0-1"
                      },
                      "to": {
                        "tp-ref": "example:3-0-6"
                      }
                    },
                    {
                      "id": 30108,
                      "from": {
                        "tp-ref": "example:3-0-1"
                      },
                      "to": {
                        "tp-ref": "example:3-0-8"
                      }
                    },
                    {
                      "id": 30308,
                      "from": {
                        "tp-ref": "example:3-0-3"
                      },
                      "to": {
                        "tp-ref": "example:3-0-8"
                      }
                    }
                  ]
                }
              }
            }
          }
        ]
      }
    ]
  }
}
]]></artwork>
}]]></sourcecode>

      </section>
    </section>

    <section anchor="sect-10" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank <contact fullname="Xufeng Liu"/>,
      <contact fullname="Adrian Farrel"/>, <contact fullname="Tom Petch"/>,
      <contact fullname="Mohamed Boucadair"/>, <contact fullname="Italo
      Busi"/>, <contact fullname="Bo Wu"/>, and <contact fullname="Daniel
      King"/> for their helpful comments and valuable suggestions.</t>

      <t>Thanks to:</t>
      <ul spacing="compact">
	<li><t><contact fullname="Andy Bierman"/> for the YANGDIR
	review.</t></li>
	<li><t><contact fullname="Darren Dukes"/> and <contact fullname="Susan Hares"/> for the RTGDIR
	review.</t></li>
	<li><t><contact fullname="Behcet Sarikaya"/> for the GENART
	review.</t></li>
	<li><t><contact fullname="Bo Wu"/> for the OPSDIR review.</t></li>
	<li><t><contact fullname="Shivan Sahib"/> for the SECDIR review.</t></li>
	<li><t><contact fullname="Deb Cooley"/>, <contact
      fullname="Francesca Palombini"/>, <contact fullname="Gunter Van de
      Velde"/>, and <contact fullname="Mahesh Jethanandani"/> for the IESG
	review.</t></li>
      </ul>
    </section>

    <section anchor="sect-contributors" numbered="true" numbered="false" toc="default">
      <name>Contributors
      <name>Contributors' Addresses</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
Qin Wu
Huawei Technologies
Email: bill.wu@huawei.com

Peter Park
KT
Email: peter.park@kt.com

Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com

Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com

Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com

Takuya Miyasaka
KDDI
Email: ta-miyasaka@kddi.com

Kenichi Ogaki
KDDI
Email: ke-oogaki@kddi.com
]]></artwork>

      <contact fullname="Qin Wu">
      <organization>Huawei Technologies</organization>
      <address>
        <email>bill.wu@huawei.com</email>
      </address>
      </contact>

      <contact fullname="Peter Park">
      <organization>KT</organization>
      <address>
        <email>peter.park@kt.com</email>
      </address>
      </contact>

      <contact fullname="Haomian Zheng">
      <organization>Huawei Technologies</organization>
      <address>
        <email>zhenghaomian@huawei.com</email>
      </address>
      </contact>

      <contact fullname="Xian Zhang">
      <organization>Huawei Technologies</organization>
      <address>
        <email>zhang.xian@huawei.com</email>
      </address>
      </contact>

      <contact fullname="Sergio Belotti">
      <organization>Nokia</organization>
      <address>
        <email>sergio.belotti@nokia.com</email>
      </address>
      </contact>

      <contact fullname="Takuya Miyasaka">
      <organization>KDDI</organization>      <address>
        <email>ta-miyasaka@kddi.com</email>
      </address>
      </contact>

      <contact fullname="Kenichi Ogaki">
      <organization>KDDI</organization>
      <address>
        <email>ke-oogaki@kddi.com</email>
      </address>
      </contact>

    </section>
  </back>
</rfc>