<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <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> <seriesInfoname="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> <dateyear="2024"/> <workgroup>TEAS Working Group</workgroup>year="2025" month="January"/> <area>RTG</area> <workgroup>teas</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <!--[rfced] Is the final sentence of the Abstract pointing to another document (RFC 8453)? Or is this a general mention of the concept? Original: This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework. Perhaps: This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework described in RFC 8453. --> <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 itwaswere 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> </abstract> </front> <middle> <section anchor="sect-1" numbered="true" toc="default"> <name>Introduction</name> <t> Abstraction and Control ofTraffic Engineered (TE)TE Networks (ACTN) describes a set of management and control functions used to operate one or moreTETraffic 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 modelgenerally applicable to any mode of VN operation. ACTN is the primary example of the usage of the VN YANGmodelmodel, 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 documentIt can also work together with other customer service models such as theLayer Three Virtual Private NetworkL3VPN Service Model (L3SM) <xref target="RFC8299" format="default"/>, theLayer Two Virtual Private NetworkL2VPN Service Model (L2SM) <xref target="RFC8466"format="default"/>format="default"/>, and theLayer OneL1 Connectivity Service Model (L1CSM) <xref target="I-D.ietf-ccamp-l1csm-yang" format="default"/> to provideacomplete life-cycle service management and operations.</t> <t> The YANG 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) that describe the customer's VN in terms of multiple VN Members comprising a VN, multi-source and/or multi-destination characteristics of the VN Member, the VN's reference to TE-topology's Abstract Node;</li> </ul> <t>An abstract TE topology is a topology that contains abstract topological elements (nodes, links) created andcustomisedcustomized based oncustomer'scustomer preference <xref target="RFC8795" format="default"/>. The actual VN instantiation and computation is performed with Connectivity Matrices of the 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 is used in triggering VN instantiation over the networks, the TE-tunnel Model <xref target="I-D.ietf-teas-yang-te" format="default"/>Modelwill inevitably interact with the TE-Topology modelforwhen setting up actual tunnels andLSPsLabel Switched Paths (LSPs) under the tunnels.</t> <t> Sections2<xref target="sect-2" format="counter"/> and3<xref target="sect-3" format="counter"/> provide a discussion of how the VN YANG 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 modelonfor theCMICNC-MDSC Interface (CMI) is also known as thecustomer"customer servicemodelmodel" in <xref target="RFC8309" format="default"/>. The YANG model discussed in this document is used to operate customer-driven VNs during the VNinstantiation, 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<!--[auth] The origin of the data is indicated as per the origin metadataannotation.--></t>annotation.--> <!-- [rfced] FYI, the authors' comments in the XML file have been marked with [auth]. Please let us know if any updates are needed based on those comments; if not, they will be removed. --> </t> <section anchor="sect-1.1" numbered="true" toc="default"> <name>Terminology</name><!--><t><!--[rfced] Might the following update to the Terminology section be helpful to the reader? It reduces redundancy, groups the abbreviations in one list, and makes the treatment of the terms more similar. Otherwise, we have "Connectivity Matrix" without any descriptor in the original... Original: 1.1. Terminology This document borrows the following terms from [RFC8453]: VN: Virtual Network AP: Access Point VNAP: VN Access Point ACTN: Abstraction and Control of TE Networks CNC: Customer Network Controller MDSC: Multi-Domain Service Coordinator CMI: CNC-MDSC Interface This document borrows the following terms from [RFC8795]: LTP: Link Termination Point Connectivity Matrix This document borrows the terminology in Section 1.1 of [RFC7926]. This document uses the term 'Service Model' as described in [RFC8309]. Perhaps: 1.1. Terminology This document borrows the following abbreviations from [RFC8453] and/or [RFC8795]: VN: Virtual Network AP: Access Point VNAP: VN Access Point ACTN: Abstraction and Control of TE Networks CNC: Customer Network Controller MDSC: Multi-Domain Service Coordinator CMI: CNC-MDSC Interface LTP: Link Termination Point This document borrows the terminology in Section 1.1 of [RFC7926], the term "Service Model" from [RFC8309], and the term "Connectivity Matrix" from [RFC8795]. --> <!--[auth] <t> Refer to <xref target="RFC8453" format="default"/>, <xref target="RFC7926" format="default"/>, and <xref target="RFC8309" format="default"/> for the key terms used in this document.</t>--> <t>This document borrows the following terms from <xref target="RFC8453" 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 AccessPoint</li> <li>ACTN: AbstractionPoint</dd> <dt>ACTN:</dt> <dd>Abstraction and Control of TENetworks</li> <li>CNC: CustomerNetworks</dd> <dt>CNC:</dt> <dd>Customer NetworkController</li> <li>MDSC: Multi-DomainController</dd> <dt>MDSC:</dt> <dd>Multi-Domain ServiceCoordinator</li> <li>CMI: CNC-MDSC Interface</li> </ul>Coordinator</dd> <dt>CMI:</dt> <dd>CNC-MDSC Interface</dd> </dl> <t>This document borrows the following terms from <xref target="RFC8795" format="default"/>:</t><ul spacing="normal"> <li>LTP: Link<dl spacing="normal" newline="false"> <dt>LTP:</dt> <dd>Link TerminationPoint</li> <li>Connectivity Matrix</li> </ul>Point</dd> <dt>Connectivity Matrix</dt> <dd></dd> </dl> <t>This document borrows the terminology inSection 1.1 of<xref target="RFC7926"format="default"/>.</t>sectionFormat="of" section="1.1"/>.</t> <t>This document uses the term 'Service Model' as described in <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", and "OPTIONAL" in this document are to be interpreted 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>--></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 inSection 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 importedmodules,modules as shown inTable 1.</t><xref target="tab-prefixes-and-corresponding-yang-modules"/>.</t> <table anchor="tab-prefixes-and-corresponding-yang-modules" align="center"> <name>Prefixes andcorrespondingCorresponding YANGmodules</name>Modules</name> <thead> <tr> <th align="left"> Prefix</th> <th align="left"> YANGmodule</th>Module</th> <th align="left"> Reference</th> </tr> </thead> <tbody> <tr> <td align="left">vn</td> <td align="left">ietf-vn</td> <tdalign="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 Model in the ACTNcontext</name>Context</name> <t> In this section, ACTN is being used to illustrate the general usage of the VN YANG 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 | +-----------------------+ | MDSC |+-----------------------+ ]]></artwork>+-----------------------+]]></artwork> </figure> <t> Both ACTN VN YANG and TE-topology models are used over the CMI to establish a VN over TEnetworksnetworks, as shown in <xref target="ure-actn-cmi"/>.</t><!--<t><!--[auth]<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> <!--[rfced] The use of the blockquote element with this text may be confusing to readers. If this is simply a paraphrase instead of a direct quote from RFC 8543 (which it appears to be), we suggest removing the blockquote element. Original: As defined in [RFC8453], a Virtual Network is a customer view of the TE network. To recapitulate VN types from [RFC8453], Type 1 VN is defined as follows: | 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. Perhaps: As defined in [RFC8453], a Virtual Network is a customer view of the TE network. To recapitulate VN types from [RFC8453], Type 1 VN is defined as follows: 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> As defined in <xref target="RFC8453" format="default"/>, a Virtual Network 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<t>If we were to create a VN where we have four VN-members asfollows:</dt> <dd/> </dl>follows:</t> <figure> <artwork name="" type="" align="left" alt=""><![CDATA[ VN-member 1 L1-L4 VN-member 2 L1-L7 VN-member 3 L2-L4 VN-member 4L3-L8 ]]></artwork> <dl newline="false" spacing="normal" indent="7"> <dt/> <dd> WhereL3-L8]]> </artwork> </figure> <t>Where L1, L2, L3, L4, L7, and L8 correspond to a CustomerEnd-PointEndpoint (orAP).</dd> </dl> <t> ThisAP).</t> <t>This VN can bemodelledmodeled as one abstract node representation as follows inFigure 2:</t><xref target="ure-abstract-node-one-node-topology"/>:</t> <figure anchor="ure-abstract-node-one-node-topology"> <name>Abstract Node (Onenode topology)</name>Node Topology)</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +----------------------------------------------+ | | L1----|..............................................|------L4 | . . | | . AN1 . | | . . | | ..................................*.....|------L7 | . | L2-----|....................................... | | | L3-----|..............................................|------L8 | |+----------------------------------------------+ ]]></artwork>+----------------------------------------------+]]></artwork> </figure> <t>ModellingModeling a VN as one abstract node is the easiest way for customers to express their end-to-end connectivity as shown in <xreftarget="ure-abstract-node-one-node-topology"/>.<!--;target="ure-abstract-node-one-node-topology"/>.<!--[auth]; 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.--> </t> </section> <section anchor="sect-2.2" numbered="true" toc="default"> <name>Type 2 VN</name> <!--[rfced] We are unsure of how to parse the list below beginning with "which". Please rephrase. Original: Type 1 VN can be seen as a higher abstraction of a Type 2 VN (which along with a single node abstract topology, an underlay topology and the intended path is specified). --> <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 as a higher abstraction of a Type 2 VN (which along with a single node abstract topology, an underlay topology and the intended pathisare specified). These topologies could be mutually agreed upon between the CNC and the MDSC prior to VN creation oritthey could be created as part of VN instantiation.<!--Type<!--[auth]Type 2 VN is always built on top of a Type 1 VN.--></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 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 2topology</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 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> <figure anchor="type1"> <name>Type 1 VN Illustration</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +--------+ +--------+ | CNC | | MDSC | +--------+ +--------+ | | | | CNC POST TE-topo | POST /nw:networks/nw:network/ |model(with Conn. |model (with Conn.| nw:node/te-node-id/ | Matrix on one | tet:connectivity-matrices/ | Abstractnodenode) | tet:connectivity-matrix | |-------------------------------->| | HTTP 200 | |<--------------------------------| | | CNC POST the | POST /virtual-network | VN identifying |-------------------------------->| If there is AP,VNAPVNAP, andVN- |VN-| |multi-src/destmulti-src/dest, Members and maps | | then MDSC to the TE-topo | HTTP 200 | selectsaan |<--------------------------------| src or dest | | and updates | | VN YANG CNC GET the | GET /virtual-network | VN YANG status |-------------------------------->| | | | HTTP 200 (VN with status: | | selected VN-members | | in case of multi-s-d) | |<--------------------------------| || ]]></artwork></figure>|]]></artwork> </figure> <!--[rfced] In the "Type 1 VN Illustration" figure (Figure 5), should "multi-s-d" instead read as "multi-s/d" to more closely mirror the text to the right of the 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 twoend-points.endpoints. Let us consider the followingexample.</t> <ul empty="true" spacing="normal"> <li> <dl newline="false" spacing="normal" indent="1"> <dt>VN-member 1</dt> <dd> <t>example:</t> <figure> <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,S7S7, 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,S10S10, andS11) </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 topology, thefollowing diagram shows themessage flow between the CNC and MDSC to instantiate this VN using a VN and TE-TopologyModel.</t>Model would be as shown in the following diagram:</t> <figure anchor="type2_case1"> <name>Type 2 VNIllustration,Illustration: Case 1</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +--------+ +--------+ | CNC | | MDSC | +--------+ +--------+ | | | | CNC POST TE-topo | POST /nw:networks/nw:network/ |model(with Conn. |model (with Conn.| nw:node/te-node-id/tet:connectivity- | Matrix on one | matrices/tet:connectivity-matrix | Abstract node and|---------------------------------------->|Explicitexplicit paths in| | theconn. matrix)|Conn. Matrix)| HTTP 200 | |<----------------------------------------| | | CNC POST the | POST /virtual-network | VN identifying |---------------------------------------->| AP,VNAPVNAP, andVN- |VN-| | Members and maps | | to the TE-topo | HTTP 200 | |<----------------------------------------| | | | | 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 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> <figure anchor="type2_case2"> <name>Type 2 VNIllustration,Illustration: Case 2</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +--------+ +--------+ | CNC | | MDSC | +--------+ +--------+ | | | | CNC POST VN | |Identifyingidentifying AP, | | VNAP and VN- | POST /virtual-network | MDSC populates Members |-------------------------------->| a single Abst. | HTTP 200 | node topology |<--------------------------------| by itself | | CNC GET VN & | GET /virtual-network & | POSTTE-TopoTE-topo | POST /nw:networks/nw:network/ |Modelsmodels (with | nw:node/te-node-id/tet: | Conn. Matrix | connectivity-matrices/ | on the | tet:connectivity-matrix | AbstractNodenode |-------------------------------->| 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 topology) could be a Native/White topology or a Grey topology (<xref target="RFC8453" format="default"/>) that is furthercustomisedcustomized 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 the TE-topology Connectivity Matrix sub-model to illustrate how a VN can be created by the CNC making use of the VN module as well as the 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 inSection 6 of<xref target="RFC8453"format="default"/>.</t>sectionFormat="of" section="6"/>.</t> <!--[rfced] This sentence may trip up some readers; particularly, how does "only" apply to the sentence (especially considering the use of "as well")? Please consider a rephrase. Original: The VN operation allows the creation of a VN with only a PE identifier as well. --> <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. The customer access information could be added later.</t><t>To<!--[rfced] Please review the use of lowercase "vn" in this sentence. Is this the abbreviation for Virtual Network? Or is this the Prefix defined in Section 1.3? Original: To achieve this, the 'ap' container has a leaf for 'pe' node that allows AP to be created with PE information. The vn-member (and vn) could use APs that only have PE informationinitially.</t>initially. --> <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 (and vn) could use APs that initially only have PE information.</t> </section> </section> </section> <section anchor="sect-4" numbered="true" toc="default"> <name>VN Model Usage</name> <section anchor="sect-4.1" numbered="true" toc="default"> <name>CustomerviewView of VN</name> <t> The VN-YANG model allowsto definethe definition of a customerview,view and allows the customer to communicate using the VN constructs as described inthe<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 models.</t> <t> This is similar to the benefits offered by a separate YANG model forthecustomer servicesasdescribed in <xref target="RFC8309" format="default"/>, which states that service models do not make anyassumptionassumptions 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 model. In some other cases, the VN is not explicitlyconfigured,configured but is instead created automatically by the MDSC based on the customer service model and localpolicy,policy; even in these cases, the VN YANG 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 supports VN compute (pre-instantiation mode) to view the full VN as a single entity beforeinstantiation. Achievinginstantiation; achieving this via path computation or "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> <artwork name="" type="" align="left" alt=""><![CDATA[ +--------+ +--------+ | CNC | | MDSC | +--------+ +--------+ | | | | CNC POST TE-topo | POST /nw:networks/nw:network/ | model(with Conn. | nw:node/te-node-id/tet:connectivity- | Matrix on one | matrices/tet:connectivity-matrix | Abstract node and|---------------------------------------->| constraints in | | the conn. matrix)| HTTP 200 | |<----------------------------------------| | | | | CNC calls RPC to | RPC /vn-compute | compute the VN |---------------------------------------->| as per the | | refered TE-Topo | | | | | HTTP 200 (Computed VN) | |<----------------------------------------| || ]]></artwork></figure>|]]></artwork> </figure> <t>The VN compute RPC allowsyou to optionally includethe 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 | compute the VN |---------------------------------------->| as per the | | constraints and | | VN-members | | | HTTP 200 (Computed VN) | |<----------------------------------------| || ]]></artwork></figure>|]]></artwork> </figure> <t>In eithercasecase, the output includes a reference to the single node abstract topology with each VN-member including a reference to the connectivity-matrix-id where the path properties could be found. </t> <t>To achievethisthis, the VN-compute RPC reuses the following common groupings: </t> <ul spacing="normal"> <!--[rfced] We had a few questions about the bulleted list following Figure 10: a) May we replace "This" with its antecedent for clarity? Note that this text occurs twice (in the first two bullets of the list): Original: This also overrides any constraints in the referenced abstract node in the TE topology. Pephaps: The VN-member level also overrides any constraints in the referenced abstract node in the TE topology. b) In the following, is the meaning "at the VN level and/or VN-member level"? Note that this text also occurs twice in the first two bullet points of this list. Original: This is used optionally in the RPC input at the VN and/or VN-member level. Perhaps: This is used optionally in the RPC input at the VN level and/or the VN-member level. --> <li>te-types:generic-path-constraints: This is used optionally in the RPC input at the VN and/or VN-member level. The VN-member level overrides the VN-level data. This also overrides 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 and/or VN-member level. The VN-member level overrides the VN-level data. This also overrides any optimization in the referenced abstract node in the TE topology.</li> <li>vn-member: This identifies the VN member in both RPC input and output.</li> <li>vn-policy: This is used optionally in the RPC input to apply anyVN levelVN-level policies.</li> </ul> <t>When MDSC receives thisRPCRPC, it computes the VN based on the input provided in theRPC 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 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=""><![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 | | | +---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 | | | +---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 +--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 | +--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 | +--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 andMulti-destinations</name>Multiple Destinations</name> <t> In creating a virtual network, the list of sources or destinations or both may not bepre-determinedpredetermined by the customer. For instance, for a given source, there may be a list ofmultiple-destinationsmultiple destinations to which the optimal destination may be chosen depending on the network resource situations. Likewise, for a given destination, there may also bemultiple-sourcesmultiple 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 modelmulti-sourcesmultiple sources andmulti-destinations.</t> <artworkmultiple 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 | | +--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 | | +--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 model canbeeasily be augmented to support the mapping of VN to theServicesservices 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 model can be extended to support telemetry, performancemonitoringmonitoring, and network autonomics as described in <xref target="I-D.ietf-teas-actn-pm-telemetry-autonomics" format="default"/>.</t> <!--[rfced] We would suggest making the following updates for clarity as two YANG models are being discussed in close proximity. Original: Note that the YANG model is tightly coupled with the TE Topology model [RFC8795]. Any underlay technology not supported by [RFC8795] is also not supported by this model. The model does include an empty container called "underlay" that can be augmented. For example the Segment Routing (SR) Policy [RFC9256] information can be augmented for the SR underlay by a future model. Perhaps: Note that the VN YANG model is tightly coupled with the TE Topology model [RFC8795]. Any underlay technology not supported by the TE Topology model in [RFC8795] is also not supported by the VN YANG model. However, the VN YANG model does include an empty container called "underlay" that can be augmented. For example, the Segment Routing (SR) Policy [RFC9256] information can be augmented for the SR underlay by a future model. --> <t>Note that the YANG model is tightly coupled with the TE Topology model <xref target="RFC8795" format="default"/>. Any underlay technology not supported by <xref target="RFC8795" format="default"/> is also not supported by this model. The model does include an empty container called "underlay" that can be augmented. For example the Segment Routing (SR) Policy <xref target="RFC9256"/> information can be augmented for the SR underlay by a future model.</t> <!--[rfced] RFC 4124 does not use the term "cos" or "class of service". Is this citation in the right place in the sentence? Original: Apart from the te-types:generic-path-constraints and te- types:generic-path-optimization, an additional leaf cos for the class of service [RFC4124] is added to represent the Class-Type of traffic to be used as one of the path constraints. Perhaps: Apart from the te-types:generic-path-constraints and te- types:generic-path-optimization, an additional leaf cos for the class of service is added to represent the Class-Type of traffic [RFC4124] to be used as one of the path constraints. --> <t>Apart from the te-types:generic-path-constraints and te-types:generic-path-optimization, an additional leafcoscalled "cos" for the class of service <xref target="RFC4124"/> is added to represent the Class-Type of traffic 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 VNYANG.</t>YANG model.</t> <ul spacing="normal"> <li>Maintenance ofAPAPs andVNAPVNAPs 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 VNSTypes </t>Types</t> <ul spacing="normal"> <li>VN Type 1: Customer configures the VN as a set of VN 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, the customer could also provide an abstract topology, this topology is provided by the Abstract TE Topology YANGModel.</li>Model.</t> <ul spacing="normal"> <li>Note that the VN Type is not explicitly identified in the VN Yang model, as the VN 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 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 | +--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 | | +--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 | | +--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 | | | +---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 | | | +---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 +--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 | +--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 | +--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-6" numbered="true" toc="default"> <name>VN YANG Model</name><t><!--[rfced] We had the following questions about the YANG module in Section 6: a) Is "This module contains a YANG module" correct? Original: This module contains a YANG module for the Virtual Network (VN). Perhaps: This YANG module is for the Virtual Network (VN). b) The beginning of the module lists abbreviations, but they are expanded on first use in the module anyway. May we cut these first expansions? c) Same for src and dest: they are introduced, but not used in descriptions consistently. Please let us know if updates should be made. d) FYI - We will update the expansion of CMI to match the version used in the Terminology section (i.e., CNC-MDSC Interface) as follows (if you decide to keep the abbreviations list we mentioned above - if not, we will simply update in the running text): Original: It describes a VN operation module that can take place in the context of the Customer Network Controller (CNC)- Multi-Domain Service Coordinator (MDSC) interface (CMI) of the Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) architecture where the CNC is the actor of a VN 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 Perhaps: It describes a VN operation module that can take place in the context of the Customer Network Controller (CNC) Multi-Domain Service Coordinator (MDSC) interface of the Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) architecture where the CNC is the actor of a VN 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 - CMI: CNC-MDSC Interface e) Because this description clause mentions RFC 8795, should a reference to it be added as well? container underlay { description "An empty container that can be augmented with underlay technology information not supported by RFC 8795 (for example - Segment Routing (SR)."; } reference "RFC 8454: Information Model for Abstraction and Control of TE Networks (ACTN)"; f) Note that the YANG module has been updated per the formatting option of pyang. Please let us know any concerns. --> <t>The VN YANG model is as follows:</t> <sourcecodename="ietf-vn@2024-06-22.yang"name="ietf-vn@2025-01-27.yang" type="" 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 ofTraffic Engineered (TE)TE Networks (ACTN) architecture where the CNC is the actor of a VNInstantiation/modification/deletioninstantiation/modification/deletion as per RFC 8453. This module uses the 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'src and'dest' isdest are used for source anddestinationdestination, respectively. Copyright (c)20242025 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 RFCXXXX;9731; see the RFC itself for full legal notices."; revision2024-06-222025-01-27 { description "The initial version."; reference "RFCXXXX:9731: A YANG Data Model for Virtual Network (VN) Operations"; } /* Features */ feature multi-src-dest { description "Support for selection of one src ordestinationdest 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 a Virtual Network (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 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 consideredasto 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 dependentCNCCNCs 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."; 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 isenabled.";enabled?"; } } container dest { description"the"The destination of the VN 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 the dest 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 - Segment Routing (SR)."; } reference "RFC 8454: Information Model for Abstraction and Control of TE Networks (ACTN)"; } 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 "APconfigurations";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 thatrepresentrepresents 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 theabstract-node i.e.abstract-node, i.e., the LTP should be in the abstractlayer,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 ofVNAPVNAPs 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 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 themulti-src/dest options.";multi-src or multi-dest 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 topology. It could optionally also include constraints and optimization criteria. The computation is done based on the list of VN-members. The output includes a reference to the single-node -abstract topology with each 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 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 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 themulti-src/dest options.";multi-src or multi-dest 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> TheNETCONF access control modelNetwork 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). Securityrisksrisks, such as malicious attack and rogue elements attempting to connect to the various ACTNcomponentscomponents, 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 eavesdroppingofon 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 theaccess pointsAPs 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 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 theMDSCMDSC, 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 forthe URIsa URI in the "ns"subregistryregistry 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 XMLnamespace. ]]></artwork> <t>namespace.</dd> </dl> <!--[rfced] We note that IANA lists both RFCs 6020 and 8407 as references for the "YANG Module Names" registry. Should this text be updated to add RFC 8407 (and an entry added to the Informative References section)? Original: IANA is requested to make the following allocation for the YANG module 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[RFC6020]: Perhaps: IANA has made the following allocation forRTGDIR review.</t> <t>Thanks to Deb Cooley, Francesca Palombini, Gunter Van de Velde,the YANG module in the "YANG Module Names" registry ([RFC6020] andMahesh Jethanandani[RFC8407]): --> <t>IANA has made the following allocation forIESG review.</t>the VN YANG module (see <xref target="sect-5" format="default"/>in the "YANG Module Names" registry <xref target="RFC6020" format="default"/>:</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:includehref="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:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4124.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8776.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8776.xml"/> <xi:includehref="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:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>-->href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:includehref="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:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7926.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7926.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8454.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8454.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.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" /> <abstract> <t> This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. This YANG model is in compliance of Network Management Datastore Architecture (NMDA). </t> </abstract> </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> <!--[rfced] Replacing "this" with its antecedent may help the reader with clarity. Original: It should be noted that this YANG module relies on the TE-Topology Model [RFC8795] by using a reference to an abstract node to achieve this. Perhaps: It should be noted that the VN YANG module described in this document relies on the TE-Topology Model in [RFC8795] by using a reference to an abstract node to provide VN-level constraints and optimization criteria. --> <t>At thetime ofcreation of a VN, it is natural to provideVN levelVN-level constraints and optimization criteria. It should be noted thatthisthe VN YANG module described in this document relies on the TE-Topology Model in <xref target="RFC8795" format="default"/> by using a reference to an abstract node to achieve this. Further, the connectivity-matrix structure is used to assign the constraints and optimization criteria including delay,jitterjitter, etc. <xref target="RFC8776" format="default"/> defines some of themetric-types already andmetric-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 model and TE topology model are used together to instantiate a VN.</t> <t> The example in this section includes the followingVN</t>VNs:</t> <ul spacing="normal"> <li>VN1 (Type 1):WhichThis VN maps to the single node topology abstract1 andconsistconsists of VN Members 104 (L1 to L4), 107 (L1 to L7), 204 (L2 to L4), 308 (L3 toL8)L8), and 108 (L1 to L8).</li> <li>VN2 (Type 2):WhichThis VN maps to the single node topologyabstract2,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 106 (L1 to L6) and 107 (L1 to L7) showcase multi-dest and VN Member 108 (L1 to L8) and 308 (L3 to L8) showcase the multi-src feature. The selected VN-member is known via the field "if-selected" and the corresponding connectivity-matrix-id.</li> </ul> <figure> <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 model also includes the AP andVNAPVNAP, which shows variousVNVNs using the same AP.</t><artwork<sourcecode name=""type="" align="left" alt=""><![CDATA[type=""><![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 TETopologies</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 thenode andnode: 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=""><![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> <!--[rfced] We have received guidance from Benoit Claise and the YANG Doctors that "YANG module" and "YANG data model" are preferred. a) We will update to use the above forms unless we hear objection. b) Note that we have already updated the short/running title of the document from "VN YANG Model" to "VN YANG Data Model". Please let us know any objections. c) Please let us know if any uses of "VN model" (particularly in the Introduction) should also be updated with the above guidance in mind. We see the following inconsistent use of that term. Please also let us know any updates to the capitalization scheme of this term. VN model vs. VN Model VN module VN-YANG model vs. VN YANG model vs. VN Yang model d) Please review the way that the module from RFC 8795 is referred to and let us know if/how this may be made uniform: TE-Topology Model vs. TE-topology Model vs. TE-Topology model vs. TE-topology model vs. TE Topology model and TE-Topo Model vs. TE-topo model and TE-topology YANG TE-topo e) We also see "TE-tunnel Model" (with Model capped). Please review and advise on if Model should be used for these names of YANG modules. --> <!-- [rfced] We had a few comments/questions regarding sourcecode and artwork elements: a) FYI - We updated <artwork> to <sourcecode> in Sections 4.3.1, 4.3.2, 5, and 6 and in Appendix B.1 and B.2. Please confirm that this is correct. b) Please consider whether the "type" attribute of any sourcecode element should be set and/or has been set correctly. The current list of preferred values for "type" is available at <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. c) FYI - We updated the list in Section 3.2 to <artwork> to match the artwork in Section 2.1 and Appendix B.1. Please confirm that this is correct. d) We note that the tree structures represented in Sections 4.3.1, 4.3.2, and 5 all have line lengths over the 72-character limit. RFC 8792 defines the use of the backslash character for breaking these lines. We will update to use backslashes where necessary and add an informative reference to RFC 8792 unless we hear objection. --> <!--[rfced] We had the following questions related to figure titles in this document: a) We note that Figures 2, 6, and 11 do not have titles while the other figures in the document do. Please let us know what, if any, titles you would like to add. b) We note that Figures 9 and 10 have the same titles. Please let us know if these figures can be differentiated in some way. We also feel doing so might lead to an updated of this text, in which "In either case" might be able to become more easily understandable to the reader: Original: In either case the output includes a reference to the single node abstract topology with each VN-member including a reference to the connectivity-matrix-id where the path properties could be found. c) We see the title of Figure 3 includes "One Node Topology" while the title of Figure 4 is "Type 2 Topology". Should these be made more similar? That is, is Figure 3 actually "Type 1 Topology"? --> <!--[rfced] We had the following questions/comments regarding abbreviation use in this document: a) To match the guidance at https://www.rfc-editor.org/styleguide/part2/#exp_abbrev, we will remove the expansions from abbreviations that have already been expanded (excluding repeats in the YANG). Examples as follows: VN PE b) We have expanded these abbreviations on first use as follows. Please let us know any objections: LSP - Label Switched Path RPC - Remote Procedure Call c) To reduce redundancy, we cut repeated words from following an abbreviation. Please let us know any objections. RPC call d) We note that the document uses both "cos" and "COS" as relates to Class of Service. Please review if this capitalization variance should be made uniform and if so, which form is preferred. --> <!--[rfced] The following terminology appears to have been used inconsistently throughout the document. Please review each use carefully and let us know if/how they may be updated. Note: it may be easier for authors to directly update our edited XML, which they are welcome to do. a) Please review the mixed use of capitalization, hyphenation, and word order in the instances of the following. Please let us know if/how to update. VN Members vs. VN members vs. VN-members vs. vn-member VN Type vs. VN type abstract node vs. Abstract Node vs. Abstract node vs. node abstract single-node-abstract topology vs. single node abstract topology vs. single node topology abstract1 TE topology vs. TE Topology vs. TE-topology vs. TE network topology vs. TE-topo Connectivity Matrices vs. connectivity matrix and Conn. Matrix vs. conn. matrix vn-compute vs. VN compute vs. Computed VNs vs. computed VN vs. VN computation explicit path vs. explicit abstract path vs. Explicit path b) Please review the use of multi-source vs. multi-src and multi-destination vs. multi-dest and let us know if updates are desired. c) May we update to use hyphenation with VN-level when in attributive position throughout? d) We note that this document uses "compute only" while draft-ietf-teas-yang-te-36 uses "compute-only". Please let us know how you would like to update for consistency. --> <!--[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, our script pointed out: native TE topology / native TE Topology Native/White topology With the use of "Gray topology", we assume "Native/White topology" is related. Please advise. --> </back> </rfc>