rfc9731.original.xml   rfc9731.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
raft-ietf-teas-actn-vn-yang-29" category="std" ipr="trust200902" obsoletes="" up raft-ietf-teas-actn-vn-yang-29" number="9731" category="std" ipr="trust200902" o
dates="" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version= bsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="
"3"> true" version="3" consensus="true">
<!-- xml2rfc v2v3 conversion 3.9.0 -->
<!-- Generated by id2xml 1.5.0 on 2019-10-29T05:04:27Z --> <front>
<front> <title abbrev="VN YANG Data Model">A YANG Data Model for Virtual Network (VN
<title abbrev="VN YANG Model">A YANG Data Model for Virtual Network (VN) Ope ) Operations</title>
rations</title> <seriesInfo name="RFC" value="9731"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-actn-vn-yang-29"/>
<author fullname="Young Lee" initials="Y" surname="Lee" role="editor"> <author fullname="Young Lee" initials="Y" surname="Lee" role="editor">
<organization>Samsung Electronics</organization> <organization>Samsung Electronics</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>younglee.tx@gmail.com</email> <email>younglee.tx@gmail.com</email>
</address> </address>
</author> </author>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody" role="editor"> <author initials="D" surname="Dhody" fullname="Dhruv Dhody" role="editor">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>dhruv.ietf@gmail.com</email> <email>dhruv.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Daniele Ceccarelli" initials="D" surname="Ceccarelli"> <author fullname="Daniele Ceccarelli" initials="D" surname="Ceccarelli">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal>
<street></street>
<street></street>
</postal>
<email>daniele.ietf@gmail.com</email> <email>daniele.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Igor Bryskin" initials="I" surname="Bryskin"> <author fullname="Igor Bryskin" initials="I" surname="Bryskin">
<organization>Individual</organization> <organization>Individual</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>i_bryskin@yahoo.com</email> <email>i_bryskin@yahoo.com</email>
</address> </address>
</author> </author>
<author fullname="Bin Yeong Yoon" initials="B" surname="Yoon"> <author fullname="Bin Yeong Yoon" initials="B" surname="Yoon">
<organization>ETRI</organization> <organization>ETRI</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>byyun@etri.re.kr</email> <email>byyun@etri.re.kr</email>
</address> </address>
</author> </author>
<date year="2024"/> <date year="2025" month="January"/>
<workgroup>TEAS Working Group</workgroup> <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> <abstract>
<t> <t>
A Virtual Network (VN) is a network provided by a service A Virtual Network (VN) is a network provided by a service provider to a
provider to a customer for the customer to use in any way it wants customer for the customer to use in any way it wants as though it were a
as though it was a physical network. physical network. This document provides a YANG data model generally
This document provides a YANG data model generally applicable to any applicable to any mode of VN operations. This includes VN operations as
mode of VN operations. This includes VN operations as per the Abstraction and per the Abstraction and Control of TE Networks (ACTN) framework.</t>
Control of TE Networks (ACTN) framework.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" numbered="true" toc="default"> <section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) Abstraction and Control of TE Networks (ACTN)
describes a set of management and control functions used to operate describes a set of management and control functions used to operate
one or more TE networks to construct a Virtual Network (VN). A VN one or more Traffic Engineered (TE) networks to construct a Virtual Network ( VN). A VN
is represented to customers and is built from the abstractions of the is represented to customers and is built from the abstractions of the
underlying TE networks <xref target="RFC8453" format="default"/>. This docume underlying TE networks <xref target="RFC8453" format="default"/>. This docume
nt provides a YANG <xref target="RFC7950" format="default"/> data model generall nt provides a YANG data model <xref target="RFC7950" format="default"/> generall
y applicable to any y applicable to any
mode of VN operation. ACTN is the primary example of the usage of the VN YANG mode of VN operation. ACTN is the primary example of the usage of the VN YANG
model but not limited to it.</t> model, but VN is not limited to it.</t>
<t> <t>
The VN model defined in this document is applicable in a generic sense 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 as an independent model in and of itself. It can also work together with oth
this document can also work together with other customer service models such er customer service models such as the L3VPN Service Model (L3SM) <xref target="
as the Layer Three Virtual Private Network Service Model (L3SM) <xref target="RF RFC8299" format="default"/>, the L2VPN Service Model (L2SM) <xref target="RFC846
C8299" format="default"/>, the Layer Two Virtual Private Network Service Model ( 6" format="default"/>, and the L1 Connectivity Service Model (L1CSM) <xref targe
L2SM) <xref target="RFC8466" format="default"/> and the Layer One Connectivity S t="I-D.ietf-ccamp-l1csm-yang" format="default"/> to
ervice Model (L1CSM) <xref target="I-D.ietf-ccamp-l1csm-yang" format="default"/> provide complete life-cycle service management and operations.</t>
to
provide a complete life-cycle service management and operations.</t>
<t> <t>
The YANG model discussed in this document basically provides the The YANG model discussed in this document basically provides the
following:</t> following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Characteristics of Access Points (APs) that describe customer's <li>Characteristics of Access Points (APs) that describe customer's
endpoint characteristics;</li> endpoint characteristics;</li>
<li>Characteristics of Virtual Network Access Points (VNAP) that <li>Characteristics of Virtual Network Access Points (VNAPs) that
describe how an AP is partitioned for multiple VNs sharing the AP describe how an AP is partitioned for multiple VNs sharing the AP
and its reference to a Link Termination Point (LTP) of the and its reference to a Link Termination Point (LTP) of the
Provider Edge (PE) Node;</li> Provider Edge (PE) node;</li>
<li>Characteristics of Virtual Networks (VNs) that describe the <li>Characteristics of Virtual Networks (VNs) that describe the
customer's VN in terms of multiple VN Members comprising a VN, multi-sourc e and/or multi-destination characteristics of the VN Member, the customer's VN in terms of multiple VN Members comprising a VN, multi-sourc e and/or multi-destination characteristics of the VN Member, the
VN's reference to TE-topology's Abstract Node;</li> VN's reference to TE-topology's Abstract Node;</li>
</ul> </ul>
<t>An abstract TE topology is a topology that contains abstract topologica l elements (nodes, links) created and customised based on customer's preference <xref target="RFC8795" format="default"/>. <t>An abstract TE topology is a topology that contains abstract topologica l elements (nodes, links) created and customized based on customer preference <x ref target="RFC8795" format="default"/>.
The actual VN instantiation and computation is performed with The actual VN instantiation and computation is performed with
Connectivity Matrices of the TE-Topology Model <xref target="RFC8795" format= "default"/> Connectivity Matrices of the TE-Topology Model <xref target="RFC8795" format= "default"/>,
which provides a TE network topology abstraction and management which provides a TE network topology abstraction and management
operation. As per <xref target="RFC8795" format="default"/>, a TE node connec tivity matrix is the TE node's switching limitations in the form of valid switch ing combinations of the TE node's LTPs and potential TE paths. The VN representa tion 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 operation. As per <xref target="RFC8795" format="default"/>, a TE node connec tivity matrix is the TE node's switching limitations in the form of valid switch ing combinations of the TE node's LTPs and potential TE paths. The VN representa tion 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 connecti vity matrix entry, an underlay path can also be specified (<xref target="sect-2. 2"/>). and virtual links (a Type 2 VN). Alongside the mapping of VN members to a connec tivity matrix entry, an underlay path can also be specified (<xref target="sect- 2.2"/>).
</t> </t>
<t>Once the TE-topology Model is used in triggering VN <t>Once the TE-topology Model is used in triggering VN
instantiation over the networks, the TE-tunnel <xref target="I-D.ietf-teas-ya instantiation over the networks, the TE-tunnel Model <xref target="I-D.ietf-t
ng-te" format="default"/> Model will eas-yang-te" format="default"/> will
inevitably interact with the TE-Topology model for setting up actual inevitably interact with the TE-Topology model when setting up actual
tunnels and LSPs under the tunnels.</t> tunnels and Label Switched Paths (LSPs) under the tunnels.</t>
<t> <t>
Sections 2 and 3 provide a discussion of how the VN YANG model is Sections <xref target="sect-2" format="counter"/> and <xref target="sect-3" f
applicable to the ACTN context where Virtual Network Service (VNS) ormat="counter"/> provide a discussion of how the VN YANG model is
operation is implemented for the Customer Network Controller (CNC)- applicable to the ACTN context where a Virtual Network Service (VNS)
Multi-Domain Service Coordinator (MDSC) interface (CMI).</t> operation is implemented for the interface of the Customer Network Controller
(CNC) and the
Multi-Domain Service Coordinator (MDSC).</t>
<t> <t>
The YANG model on the CMI is also known as the customer service model in The YANG model for the CNC-MDSC Interface (CMI) is also known as the "custome r service model" in
<xref target="RFC8309" format="default"/>. The YANG model discussed in this d ocument is used to <xref target="RFC8309" format="default"/>. The YANG model discussed in this d ocument is used to
operate customer-driven VNs during the VN instantiation, VN operate customer-driven VNs during the VN instantiation and computation as we
computation, and its life-cycle service management and operations.</t> ll as its life-cycle service management and operations.</t>
<t> <t>
The VN operational state is included in the same tree as the The VN operational state is included in the same tree as the
configuration consistent with Network Management Datastore configuration consistent with Network Management Datastore
Architecture (NMDA) <xref target="RFC8342" format="default"/>. <!--The origin Architecture (NMDA) <xref target="RFC8342" format="default"/>.
of the data is indicated
as per the origin metadata annotation.--></t> <!--[auth] The origin of the data is indicated
as per the origin metadata 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"> <section anchor="sect-1.1" numbered="true" toc="default">
<name>Terminology</name> <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" fo rmat="default"/>, and <xref target="RFC8309" format="default"/> for the key term s used Refer to <xref target="RFC8453" format="default"/>, <xref target="RFC7926" fo rmat="default"/>, and <xref target="RFC8309" format="default"/> for the key term s used
in this document.</t>--> in this document.</t>-->
<t>This document borrows the following terms from <xref target="RFC8453" form at="default"/>:</t> <t>This document borrows the following terms from <xref target="RFC8453" form at="default"/>:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li>VN: Virtual Network</li> <dt>VN:</dt> <dd>Virtual Network</dd>
<li>AP: Access Point</li> <dt>AP:</dt> <dd>Access Point</dd>
<li>VNAP: VN Access Point</li> <dt>VNAP:</dt> <dd>VN Access Point</dd>
<li>ACTN: Abstraction and Control of TE Networks</li> <dt>ACTN:</dt> <dd>Abstraction and Control of TE Networks</dd>
<li>CNC: Customer Network Controller</li> <dt>CNC:</dt> <dd>Customer Network Controller</dd>
<li>MDSC: Multi-Domain Service Coordinator</li> <dt>MDSC:</dt> <dd>Multi-Domain Service Coordinator</dd>
<li>CMI: CNC-MDSC Interface</li> <dt>CMI:</dt> <dd>CNC-MDSC Interface</dd>
</ul> </dl>
<t>This document borrows the following terms from <xref target="RFC8795" form at="default"/>:</t> <t>This document borrows the following terms from <xref target="RFC8795" form at="default"/>:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li>LTP: Link Termination Point</li> <dt>LTP:</dt> <dd>Link Termination Point</dd>
<li>Connectivity Matrix</li> <dt>Connectivity Matrix</dt> <dd></dd>
</ul> </dl>
<t>This document borrows the terminology in Section 1.1 of <xref target="RFC7
926" format="default"/>.</t> <t>This document borrows the terminology in <xref target="RFC7926" sectionFor
mat="of" section="1.1"/>.</t>
<t>This document uses the term 'Service Model' as described in <xref target=" RFC8309" format="default"/>.</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>
<section anchor="sect-1.2" numbered="true" toc="default"> <section anchor="sect-1.2" numbered="true" toc="default">
<name>Tree Diagram</name> <name>Tree Diagram</name>
<t> <t>
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
Section 5 of this document. The meaning of the symbols in <xref target="sect-5"/> of this document. The meaning of the symbols in
these diagrams is defined in <xref target="RFC8340" format="default"/>.</t> these diagrams is defined in <xref target="RFC8340" format="default"/>.</t>
</section> </section>
<section anchor="sect-1.3" numbered="true" toc="default"> <section anchor="sect-1.3" numbered="true" toc="default">
<name>Prefixes in Data Node Names</name> <name>Prefixes in Data Node Names</name>
<t> <t>
In this document, the names of data nodes and other data model objects In this document, the names of data nodes and other data model objects
are prefixed using the standard prefix associated with the are prefixed using the standard prefix associated with the
corresponding YANG imported modules, as shown in Table 1.</t> corresponding YANG imported modules as shown in <xref target="tab-prefixes-an d-corresponding-yang-modules"/>.</t>
<table anchor="tab-prefixes-and-corresponding-yang-modules" align="cente r"> <table anchor="tab-prefixes-and-corresponding-yang-modules" align="cente r">
<name>Prefixes and corresponding YANG modules</name> <name>Prefixes and Corresponding YANG Modules</name>
<thead> <thead>
<tr> <tr>
<th align="left"> Prefix</th> <th align="left"> Prefix</th>
<th align="left"> YANG module</th> <th align="left"> YANG Module</th>
<th align="left"> Reference</th> <th align="left"> Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">vn</td> <td align="left">vn</td>
<td align="left">ietf-vn</td> <td align="left">ietf-vn</td>
<td align="left">[RFCXXXX]</td> <td align="left">RFC 9731</td>
</tr> </tr>
<tr> <tr>
<td align="left">yang</td> <td align="left">yang</td>
<td align="left">ietf-yang-types</td> <td align="left">ietf-yang-types</td>
<td align="left"> <td align="left">
<xref target="RFC6991" format="default"/></td> <xref target="RFC6991" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">nw</td> <td align="left">nw</td>
<td align="left">ietf-network</td> <td align="left">ietf-network</td>
skipping to change at line 237 skipping to change at line 296
<xref target="RFC8776" format="default"/></td> <xref target="RFC8776" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">tet</td> <td align="left">tet</td>
<td align="left">ietf-te-topology</td> <td align="left">ietf-te-topology</td>
<td align="left"> <td align="left">
<xref target="RFC8795" format="default"/></td> <xref target="RFC8795" format="default"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </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> </section>
<section anchor="sect-2" numbered="true" toc="default"> <section anchor="sect-2" numbered="true" toc="default">
<name>Use-case of VN YANG Model in the ACTN context</name> <name>Use Case of VN YANG Model in the ACTN Context</name>
<t> <t>
In this section, ACTN is being used to illustrate the general usage 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 of the VN YANG model. The model presented in this section has the
following ACTN context.</t> following ACTN context.</t>
<figure anchor="ure-actn-cmi"> <figure anchor="ure-actn-cmi">
<name>ACTN CMI</name> <name>ACTN CMI</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-------+ +-------+
| CNC | | CNC |
+-------+ +-------+
| |
| VN YANG + TE-topology YANG | VN YANG + TE-topology YANG
| |
+-----------------------+ +-----------------------+
| MDSC | | MDSC |
+-----------------------+ +-----------------------+]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
Both ACTN VN YANG and TE-topology models are used over the CMI to Both ACTN VN YANG and TE-topology models are used over the CMI to
establish a VN over TE networks as shown in <xref target="ure-actn-cmi"/>.</t establish a VN over TE networks, as shown in <xref target="ure-actn-cmi"/>.</
> t>
<!--<t> <!--[auth]<t>
In the context of 5G transport application, 5G Traffic Provisioning In the context of 5G transport application, 5G Traffic Provisioning
Manager (TPM) that provides slicing requirements to the transport Manager (TPM) that provides slicing requirements to the transport
networks (i.e., MDSC) can be considered as a type of CNC. The ACTN networks (i.e., MDSC) can be considered as a type of CNC. The ACTN
CMI provides the necessary interface functions between 5G and CMI provides the necessary interface functions between 5G and
transport networks in order to facilitate dynamic VN creation and transport networks in order to facilitate dynamic VN creation and
its lifecycle management with proper feedback loop for monitoring.</t>--> its lifecycle management with proper feedback loop for monitoring.</t>-->
<section anchor="sect-2.1" numbered="true" toc="default"> <section anchor="sect-2.1" numbered="true" toc="default">
<name>Type 1 VN</name> <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> <t>
As defined in <xref target="RFC8453" format="default"/>, a Virtual Network is a customer view of the 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="def ault"/>, Type 1 VN is TE network. To recapitulate VN types from <xref target="RFC8453" format="def ault"/>, a Type 1 VN is
defined as follows:</t> defined as follows:</t>
<blockquote> <blockquote>
<t> <t>
The VN can be seen as a set of edge-to-edge abstract links (a Type 1 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 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 as an end-to-end tunnel across the underlying networks. Such tunnels
may be constructed by recursive slicing or abstraction of paths in may be constructed by recursive slicing or abstraction of paths in
the underlying networks and can encompass edge points of the the underlying networks and can encompass edge points of the
customer's network, access links, intra-domain paths, and inter-domain links. </t></blockquote> customer's network, access links, intra-domain paths, and inter-domain links. </t></blockquote>
<dl newline="true" spacing="normal" indent="1">
<dt>If we were to create a VN where we have four VN-members as follows <t>If we were to create a VN where we have four VN-members as follows:</t>
:</dt> <figure>
<dd/>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
VN-member 1 L1-L4 VN-member 1 L1-L4
VN-member 2 L1-L7 VN-member 2 L1-L7
VN-member 3 L2-L4 VN-member 3 L2-L4
VN-member 4 L3-L8 VN-member 4 L3-L8]]>
]]></artwork> </artwork>
<dl newline="false" spacing="normal" indent="7"> </figure>
<dt/>
<dd>
Where L1, L2, L3, L4, L7, and L8 correspond to a Customer
End-Point (or AP).</dd>
</dl>
<t>
This VN can be modelled as one abstract node representation as
follows in Figure 2:</t>
<figure anchor="ure-abstract-node-one-node-topology">
<name>Abstract Node (One node topology)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+----------------------------------------------+ <t>Where L1, L2, L3, L4, L7, and L8 correspond to a Customer
| | Endpoint (or AP).</t>
L1----|..............................................|------L4
| . . |
| . AN1 . |
| . . |
| ..................................*.....|------L7
| . |
L2-----|....................................... |
| |
L3-----|..............................................|------L8
| |
+----------------------------------------------+
]]></artwork> <t>This VN can be modeled as one abstract node representation as
follows in <xref target="ure-abstract-node-one-node-topology"/>:</t>
<figure anchor="ure-abstract-node-one-node-topology">
<name>Abstract Node (One Node Topology)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+----------------------------------------------+
| |
L1----|..............................................|------L4
| . . |
| . AN1 . |
| . . |
| ..................................*.....|------L7
| . |
L2-----|....................................... |
| |
L3-----|..............................................|------L8
| |
+----------------------------------------------+]]></artwork>
</figure> </figure>
<t> <t>
Modelling a VN as one abstract node is the easiest way for customers Modeling a VN as one abstract node is the easiest way for customers
to express their end-to-end connectivity as shown in <xref target="ure-abstra to express their end-to-end connectivity as shown in <xref target="ure-abstra
ct-node-one-node-topology"/>.<!--; however, customers are not ct-node-one-node-topology"/>.<!--[auth]; however, customers are not
limited to express their VN only with one abstract node. In some limited to express their VN only with one abstract node. In some
cases, more than one abstract nodes can be employed to express their cases, more than one abstract nodes can be employed to express their
VN.--> VN.-->
</t> </t>
</section> </section>
<section anchor="sect-2.2" numbered="true" toc="default"> <section anchor="sect-2.2" numbered="true" toc="default">
<name>Type 2 VN</name> <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> <t>
For some VN members, the customers are allowed to configure For some VN members, the customers are allowed to configure
the intended path. To achieve this, alongside the single the intended path. To achieve this, alongside the single
node abstract topology, an underlay topology is also needed. node abstract topology, an underlay topology is also needed.
The underlay topology could be native TE topology or The underlay topology could be native TE topology or
an abstract TE topology. The intended path is set based on an abstract TE topology. The intended path is set based on
the nodes and links of the underlay topology. Type 1 VN 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 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 single node abstract topology, an underlay topology and the intended path are
specified). These topologies specified). These topologies
could be mutually agreed between CNC and MDSC could be mutually agreed upon between the CNC and the MDSC
prior to VN creation or it could be created as part of VN prior to VN creation or they could be created as part of VN
instantiation. <!--Type 2 VN is always built on top of a Type 1 VN.--></t> instantiation.
<!--[auth]Type 2 VN is always built on top of a Type 1 VN.--></t>
<t> <t>
If a Type 2 VN is desired for some or all of the VN members of a Type 1 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-to pology model can provide the following abstract topologies (a single node topolo gy AN1 and an underlay topology (with nodes S1 to S11 and corresponding links)). </t> VN (see the example in <xref target="sect-2.1" format="default"/>), the TE-to pology model can provide the following abstract topologies (a single node topolo gy AN1 and an underlay topology (with nodes S1 to S11 and corresponding links)). </t>
<figure anchor="ure-type-2-topology"> <figure anchor="ure-type-2-topology">
<name>Type 2 topology</name> <name>Type 2 Topology</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+----------------------------------------------+ +----------------------------------------------+
| S1 S2 | | S1 S2 |
| O...............O | | O...............O |
| ......... ....... . | | ......... ....... . |
| . . . | | . . . |
|S3 . . S4 . S5 | |S3 . . S4 . S5 |
L1----|.O......................O.........O...........|------L4 L1----|.O......................O.........O...........|------L4
| . . . | | . . . |
| . . . | | . . . |
| . S6 . S7 . S8 | | . S6 . S7 . S8 |
| O ................O.........O.......|------L7 | O ................O.........O.......|------L7
| . . . . ..... | | . . . . ..... |
|S9 . . .S10 . . | |S9 . . .S10 . . |
L2-----|...O.....O.....................O..............|------L8 L2-----|...O.....O.....................O..............|------L8
| . S11 | | . S11 |
L3-----|.. | L3-----|.. |
| AN1 | | AN1 |
+----------------------------------------------+ +----------------------------------------------+]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
As shown in <xref target="ure-type-2-topology"/>, the abstract node is AN1 an d an underlay topology is depicted with nodes and links (S1 to S11).</t> As shown in <xref target="ure-type-2-topology"/>, the abstract node is AN1 an d an underlay topology is depicted with nodes and links (S1 to S11).</t>
<t> <t>
As an example, if VN-member 1 (L1-L4) is chosen to configure its own 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 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 i ts service of the explicit abstract path {S3,S4,S5} based on the underlay topology and i ts service
requirement. This capability is enacted via TE-topology requirement. This capability is enacted via TE-topology
configuration by the customer.</t> configuration by the customer.</t>
</section> </section>
skipping to change at line 402 skipping to change at line 500
Models.</t> Models.</t>
<figure anchor="type1"> <figure anchor="type1">
<name>Type 1 VN Illustration</name> <name>Type 1 VN Illustration</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST TE-topo | POST /nw:networks/nw:network/ | CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/ | model (with Conn.| nw:node/te-node-id/ |
Matrix on one | tet:connectivity-matrices/ | Matrix on one | tet:connectivity-matrices/ |
Abstract node | tet:connectivity-matrix | Abstract node) | tet:connectivity-matrix |
|-------------------------------->| |-------------------------------->|
| HTTP 200 | | HTTP 200 |
|<--------------------------------| |<--------------------------------|
| | | |
CNC POST the | POST /virtual-network | CNC POST the | POST /virtual-network |
VN identifying |-------------------------------->| If there is VN identifying |-------------------------------->| If there is
AP, VNAP and VN- | | multi-src/dest AP, VNAP, and VN-| | multi-src/dest,
Members and maps | | then MDSC Members and maps | | then MDSC
to the TE-topo | HTTP 200 | selects a to the TE-topo | HTTP 200 | selects an
|<--------------------------------| src or dest |<--------------------------------| src or dest
| | and updates | | and updates
| | VN YANG | | VN YANG
CNC GET the | GET /virtual-network | CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->| VN YANG status |-------------------------------->|
| | | |
| HTTP 200 (VN with status: | | HTTP 200 (VN with status: |
| selected VN-members | | selected VN-members |
| in case of multi-s-d) | | in case of multi-s-d) |
|<--------------------------------| |<--------------------------------|
| | | |]]></artwork>
]]></artwork></figure> </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>
<section anchor="sect-3.2" numbered="true" toc="default"> <section anchor="sect-3.2" numbered="true" toc="default">
<name>Type 2 VN Illustration</name> <name>Type 2 VN Illustration</name>
<t> <t>
For some VN members, the customer may want to "configure" explicit For some VN members, the customer may want to "configure" an explicit
path that connects its two end-points. Let us path that connects its two endpoints. Let us
consider the following example.</t> consider the following example:</t>
<ul empty="true" spacing="normal">
<li> <figure>
<dl newline="false" spacing="normal" indent="1"> <artwork name="" type="" align="left" alt=""><![CDATA[
<dt>VN-member 1</dt> VN-member 1 L1-L4 (via S3, S4, and S5)
<dd> VN-member 2 L1-L7 (via S3, S4, S7, and S8)
<t> VN-member 3 L2-L7 (via S9, S10, and S11)
L1-L4 (via S3, S4, and S5) VN-member 4 L3-L8 (via S9, S10, and S11)]]></artwork>
</t> </figure>
<t/>
</dd>
<dt>VN-member 2</dt>
<dd>
<t>
L1-L7 (via S3, S4, S7 and S8)
</t>
<t/>
</dd>
<dt>VN-member 3</dt>
<dd>
<t>
L2-L7 (via S9, S10, and S11)
</t>
<t/>
</dd>
<dt>VN-member 4</dt>
<dd>
<t>
L3-L8 (via S9, S10 and S11)
</t>
<t/>
</dd>
</dl>
</li>
</ul>
<t>There are two options depending on whether CNC or MDSC creates the <t>There are two options depending on whether CNC or MDSC creates the
single abstract node topology.</t> single abstract node topology.</t>
<t>Case 1:</t>
<t> <t>
Case 1:</t> If the CNC creates the single-abstract-node topology, the message flow betwee
<t> n the CNC and MDSC to instantiate
If CNC creates the single-abstract-node topology, the following this VN using a VN and TE-Topology Model would be as shown in the following d
diagram shows the message flow between CNC and MDSC to instantiate iagram:</t>
this VN using VN and TE-Topology Model.</t>
<figure anchor="type2_case1"> <figure anchor="type2_case1">
<name>Type 2 VN Illustration, Case 1</name> <name>Type 2 VN Illustration: Case 1</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST TE-topo | POST /nw:networks/nw:network/ | CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/tet:connectivity- | model (with Conn.| nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix | Matrix on one | matrices/tet:connectivity-matrix |
Abstract node and|---------------------------------------->| Abstract node and|---------------------------------------->|
Explicit paths in| | explicit paths in| |
the conn. matrix)| HTTP 200 | the Conn. Matrix)| HTTP 200 |
|<----------------------------------------| |<----------------------------------------|
| | | |
CNC POST the | POST /virtual-network | CNC POST the | POST /virtual-network |
VN identifying |---------------------------------------->| VN identifying |---------------------------------------->|
AP, VNAP and VN- | | AP, VNAP, and VN-| |
Members and maps | | Members and maps | |
to the TE-topo | HTTP 200 | to the TE-topo | HTTP 200 |
|<----------------------------------------| |<----------------------------------------|
| | | |
| | | |
CNC GET the | GET /virtual-network | CNC GET the | GET /virtual-network |
VN YANG status |---------------------------------------->| VN YANG status |---------------------------------------->|
| | | |
| HTTP 200 (VN with status) | | HTTP 200 (VN with status) |
|<----------------------------------------| |<----------------------------------------|
| | | |]]></artwork>
</figure>
]]></artwork></figure>
<t>Case 2:</t> <t>Case 2:</t>
<t> <t>
On the other hand, if MDSC create the single-abstract-node topology 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 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 message flow between CNC and MDSC to instantiate this VN using VN
and TE-Topology Models.</t> and TE-Topology Models.</t>
<figure anchor="type2_case2"> <figure anchor="type2_case2">
<name>Type 2 VN Illustration, Case 2</name> <name>Type 2 VN Illustration: Case 2</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST VN | | CNC POST VN | |
Identifying AP, | | identifying AP, | |
VNAP and VN- | POST /virtual-network | MDSC populates VNAP and VN- | POST /virtual-network | MDSC populates
Members |-------------------------------->| a single Abst. Members |-------------------------------->| a single Abst.
| HTTP 200 | node topology | HTTP 200 | node topology
|<--------------------------------| by itself |<--------------------------------| by itself
| | | |
CNC GET VN & | GET /virtual-network & | CNC GET VN & | GET /virtual-network & |
POST TE-Topo | POST /nw:networks/nw:network/ | POST TE-topo | POST /nw:networks/nw:network/ |
Models (with | nw:node/te-node-id/tet: | models (with | nw:node/te-node-id/tet: |
Conn. Matrix | connectivity-matrices/ | Conn. Matrix | connectivity-matrices/ |
on the | tet:connectivity-matrix | on the | tet:connectivity-matrix |
Abstract Node |-------------------------------->| Abstract node |-------------------------------->|
and explicit | | and explicit | |
paths in the | | paths in the | |
conn. matrix) | | Conn. Matrix) | |
| HTTP 200 | | HTTP 200 |
|<--------------------------------| |<--------------------------------|
| | | |
| | | |
CNC GET the | GET /virtual-network | CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->| VN YANG status |-------------------------------->|
| | | |
| HTTP 200 (VN with status) | | HTTP 200 (VN with status) |
|<--------------------------------| |<--------------------------------|
| | | |]]></artwork>
]]></artwork></figure> </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 <t>Note that the underlay topology (which is referred to by the single-abstract-
="RFC8453" format="default"/>) that is further customised based on the requireme node topology) could be a Native/White topology or a Grey topology (<xref target
nts of the customer and configured at MDSC.</t> ="RFC8453" format="default"/>) that is further customized based on the requireme
nts of the customer and configured at the MDSC.</t>
<t> <t>
<xref target="sect-7" format="default"/> provides JSON examples for both VN m odel and TE-topology <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 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 by the CNC making use of the VN module as well as the TE-topology
Connectivity Matrix module.</t> Connectivity Matrix module.</t>
<section anchor="sect-3.3" numbered="true" toc="default"> <section anchor="sect-3.3" numbered="true" toc="default">
<name>VN and AP Usage</name> <name>VN and AP Usage</name>
<t>The customer access information may be known at the time of VN crea <t>The customer access information may be known at the time of VN crea
tion. A shared logical AP identifier is used between the customer and the operat tion. A shared logical AP identifier is used between the customer and the operat
or to identify the access link between Customer Edge (CE) and Provider Edge (PE) or to identify the access link between Customer Edge (CE) and Provider Edge (PE)
. This is described in Section 6 of <xref target="RFC8453" format="default"/>.</ . This is described in <xref target="RFC8453" sectionFormat="of" section="6"/>.<
t> /t>
<t>In some VN operations, the customer access may not be known at the
initial VN creation. The VN operation allows the creation of a VN with only a PE <!--[rfced] This sentence may trip up some readers; particularly, how
identifier as well. The customer access information could be added later.</t> does "only" apply to the sentence (especially considering the use
<t>To achieve this, the 'ap' container has a leaf for 'pe' node that a of "as well")? Please consider a rephrase.
llows AP to be created with PE information. The vn-member (and vn) could use APs
that only have PE information initially.</t> 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 identifie
r as well. The customer access information could be added later.</t>
<!--[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 information initially.
-->
<t>To achieve this, the 'ap' container has a leaf for the 'pe' node th
at 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>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default"> <section anchor="sect-4" numbered="true" toc="default">
<name>VN Model Usage</name> <name>VN Model Usage</name>
<section anchor="sect-4.1" numbered="true" toc="default"> <section anchor="sect-4.1" numbered="true" toc="default">
<name>Customer view of VN</name> <name>Customer View of VN</name>
<t> <t>
The VN-YANG model allows to define a customer view, and allows the The VN-YANG model allows the definition of a customer view and allows the
customer to communicate using the VN constructs as described in the customer to communicate using the VN constructs as described in
<xref target="RFC8454" format="default"/>. It allows the grouping of edge-to- edge links <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 (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 customer to instantiate and view the VN as one entity, making it
easier for some customers to work on VN without worrying about the easier for some customers to work on VN without worrying about the
details of the provider-based YANG models.</t> details of the provider-based YANG models.</t>
<t> <t>
This is similar to the benefits offered by a separate YANG model for This is similar to the benefits offered by a separate YANG model for
the customer services as described in <xref target="RFC8309" format="default" customer services described in <xref target="RFC8309" format="default"/>, whi
/>, which states that ch states that
service models do not make any assumption about how a service is service models do not make any assumptions about how a service is
actually engineered and delivered for a customer.</t> actually engineered and delivered for a customer.</t>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default"> <section anchor="sect-4.2" numbered="true" toc="default">
<name>Auto-creation of VN by MDSC</name> <name>Auto-creation of VN by MDSC</name>
<t> <t>
The VN could be configured at the MDSC explicitly by the CNC using 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 explicitly the VN YANG model. In some other cases, the VN is not explicitly
configured, but created automatically by the MDSC based on the configured but is instead created automatically by the MDSC based on the
customer service model and local policy, even in these cases, the VN customer service model and local policy; even in these cases, the VN
YANG model can be used by the CNC to learn details of the underlying 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> VN, created to meet the requirements of the customer service model.</t>
</section> </section>
<section anchor="sect-4.3" numbered="true" toc="default"> <section anchor="sect-4.3" numbered="true" toc="default">
<name>Innovative Services</name> <name>Innovative Services</name>
<section anchor="sect-4.3.1" numbered="true" toc="default"> <section anchor="sect-4.3.1" numbered="true" toc="default">
<name>VN Compute</name> <name>VN Compute</name>
<t> <t>
VN Model supports VN compute (pre-instantiation mode) to view the The VN Model supports VN compute (pre-instantiation mode) to view the
full VN as a single entity before instantiation. Achieving this via full VN as a single entity before instantiation; achieving this via
path computation or "compute only" tunnel setup (<xref target="I-D.ietf-teas- yang-te"/>) does not provide the path computation or "compute only" tunnel setup (<xref target="I-D.ietf-teas- yang-te"/>) does not provide the
same functionality.</t> same functionality.</t>
<figure anchor="VN_Compute1"> <figure anchor="VN_Compute1">
<name>VN Compute</name> <name>VN Compute</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
skipping to change at line 625 skipping to change at line 723
|<----------------------------------------| |<----------------------------------------|
| | | |
| | | |
CNC calls RPC to | RPC /vn-compute | CNC calls RPC to | RPC /vn-compute |
compute the VN |---------------------------------------->| compute the VN |---------------------------------------->|
as per the | | as per the | |
refered TE-Topo | | refered TE-Topo | |
| | | |
| HTTP 200 (Computed VN) | | HTTP 200 (Computed VN) |
|<----------------------------------------| |<----------------------------------------|
| | | |]]></artwork>
</figure>
]]></artwork></figure> <t>The VN compute RPC allows the optional inclusion of the constraints
<t>The VN compute RPC allows you to optionally include the constraints and the optimization criteria at the VN as well as at the individual VN-member
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
level. Thus, the RPC can be used independently to get the computed VN result
without creating an abstract topology first.</t> without creating an abstract topology first.</t>
<figure anchor="VN_Compute2"> <figure anchor="VN_Compute2">
<name>VN Compute</name> <name>VN Compute</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC calls RPC to | RPC /vn-compute | CNC calls RPC to | RPC /vn-compute |
compute the VN |---------------------------------------->| compute the VN |---------------------------------------->|
as per the | | as per the | |
constraints and | | constraints and | |
VN-members | | VN-members | |
| HTTP 200 (Computed VN) | | HTTP 200 (Computed VN) |
|<----------------------------------------| |<----------------------------------------|
| | | |]]></artwork>
</figure>
]]></artwork></figure> <t>In either case, the output includes a reference to the single node
<t>In either case the output includes a reference to the single node
abstract topology with each VN-member including a abstract topology with each VN-member including a
reference to the connectivity-matrix-id where the reference to the connectivity-matrix-id where the
path properties could be found. </t> path properties could be found. </t>
<t>To achieve this the VN-compute RPC reuses the following common grou pings: <t>To achieve this, the VN-compute RPC reuses the following common gro upings:
</t> </t>
<ul spacing="normal"> <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 th e 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 no de in the TE topology.</li> <li>te-types:generic-path-constraints: This is used optionally in th e 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 no de in the TE topology.</li>
<li>te-types:generic-path-optimization: This is used optionally in t he 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>te-types:generic-path-optimization: This is used optionally in t he 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 o utput.</li> <li>vn-member: This identifies the VN member in both RPC input and o utput.</li>
<li>vn-policy: This is used optionally in the RPC input to apply any VN level policies.</li> <li>vn-policy: This is used optionally in the RPC input to apply any VN-level policies.</li>
</ul> </ul>
<t>When MDSC receives this RPC it computes the VN based on the input p <t>When MDSC receives this RPC, it computes the VN based on the input
rovided in the RPC call. This computation does not create a VN or reserve any re provided in the RPC. This computation does not create a VN or reserve any resour
sources in the system, it simply computes the resulting VN based on information ces in the system, it simply computes the resulting VN based on information at t
at the MDSC or in coordination with the CNC. A single-node-abstract topology is he MDSC or in coordination with the CNC. A single-node-abstract topology is used
used to convey the result of each VN member as a reference to the connectivity-m to convey the result of each VN member as a reference to the connectivity-matri
atrix-id. In case of an error, the error information is included.</t> x-id. In case of an error, the error information is included.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
rpcs: <sourcecode name="" type=""><![CDATA[
+---x vn-compute rpcs:
+---w input +---x vn-compute
| +---w te-topology-identifier +---w input
| | +---w provider-id? te-global-id | +---w te-topology-identifier
| | +---w client-id? te-global-id | | +---w provider-id? te-global-id
| | +---w topology-id? te-topology-id | | +---w client-id? te-global-id
| +---w abstract-node? | | +---w topology-id? te-topology-id
| | -> /nw:networks/network/node/tet:te-node-id | +---w abstract-node?
| +---w path-constraints | | -> /nw:networks/network/node/tet:te-node-id
| | +---w te-bandwidth | +---w path-constraints
| | | +---w (technology)? | | +---w te-bandwidth
| | | ... | | | +---w (technology)?
| | +---w link-protection? identityref | | | ...
| | +---w setup-priority? uint8 | | +---w link-protection? identityref
| | +---w hold-priority? uint8 | | +---w setup-priority? uint8
| | +---w signaling-type? identityref | | +---w hold-priority? uint8
| | +---w path-metric-bounds | | +---w signaling-type? identityref
| | | +---w path-metric-bound* [metric-type] | | +---w path-metric-bounds
| | | ... | | | +---w path-metric-bound* [metric-type]
| | +---w path-affinities-values | | | ...
| | | +---w path-affinities-value* [usage] | | +---w path-affinities-values
| | | ... | | | +---w path-affinities-value* [usage]
| | +---w path-affinity-names | | | ...
| | | +---w path-affinity-name* [usage] | | +---w path-affinity-names
| | | ... | | | +---w path-affinity-name* [usage]
| | +---w path-srlgs-lists | | | ...
| | | +---w path-srlgs-list* [usage] | | +---w path-srlgs-lists
| | | ... | | | +---w path-srlgs-list* [usage]
| | +---w path-srlgs-names | | | ...
| | | +---w path-srlgs-name* [usage] | | +---w path-srlgs-names
| | | ... | | | +---w path-srlgs-name* [usage]
| | +---w disjointness? te-path-disjointness | | | ...
| +---w cos? te-types:te-ds-class | | +---w disjointness? te-path-disjointness
| +---w optimizations | +---w cos? te-types:te-ds-class
| | +---w (algorithm)? | +---w optimizations
| | +--:(metric) {path-optimization-metric}? | | +---w (algorithm)?
| | | ... | | +--:(metric) {path-optimization-metric}?
| | +--:(objective-function) | | | ...
| | {path-optimization-objective-function}? | | +--:(objective-function)
| | ... | | {path-optimization-objective-function}?
| +---w vn-member-list* [id] | | ...
| | +---w id vnm-id | +---w vn-member-list* [id]
| | +---w src | | +---w id vnm-id
| | | +---w ap? -> /access-point/ap/id | | +---w src
| | | +---w vn-ap-id? | | | +---w ap? -> /access-point/ap/id
| | | | -> /access-point/ap[id=current()/../ap]/vn-ap/id | | | +---w vn-ap-id?
| | | +---w multi-src? boolean {multi-src-dest}? | | | | -> /access-point/ap[id=current()/../ap]/vn-ap/id
| | +---w dest | | | +---w multi-src? boolean {multi-src-dest}?
| | | +---w ap? -> /access-point/ap/id | | +---w dest
| | | +---w vn-ap-id? | | | +---w ap? -> /access-point/ap/id
| | | | -> /access-point/ap[id=current()/../ap]/vn-ap/id | | | +---w vn-ap-id?
| | | +---w multi-dest? boolean {multi-src-dest}? | | | | -> /access-point/ap[id=current()/../ap]/vn-ap/id
| | +---w connectivity-matrix-id? leafref | | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w underlay | | +---w connectivity-matrix-id? leafref
| | +---w path-constraints | | +---w underlay
| | | +---w te-bandwidth | | +---w path-constraints
| | | | ... | | | +---w te-bandwidth
| | | +---w link-protection? identityref | | | | ...
| | | +---w setup-priority? uint8 | | | +---w link-protection? identityref
| | | +---w hold-priority? uint8 | | | +---w setup-priority? uint8
| | | +---w signaling-type? identityref | | | +---w hold-priority? uint8
| | | +---w path-metric-bounds | | | +---w signaling-type? identityref
| | | | ... | | | +---w path-metric-bounds
| | | +---w path-affinities-values | | | | ...
| | | | ... | | | +---w path-affinities-values
| | | +---w path-affinity-names | | | | ...
| | | | ... | | | +---w path-affinity-names
| | | +---w path-srlgs-lists | | | | ...
| | | | ... | | | +---w path-srlgs-lists
| | | +---w path-srlgs-names | | | | ...
| | | | ... | | | +---w path-srlgs-names
| | | +---w disjointness? te-path-disjointness | | | | ...
| | +---w cos? te-types:te-ds-class | | | +---w disjointness? te-path-disjointness
| | +---w optimizations | | +---w cos? te-types:te-ds-class
| | +---w (algorithm)? | | +---w optimizations
| | ... | | +---w (algorithm)?
| +---w vn-level-diversity? te-types:te-path-disjointness | | ...
+--ro output | +---w vn-level-diversity? te-types:te-path-disjointness
+--ro te-topology-identifier +--ro output
| +--ro provider-id? te-global-id +--ro te-topology-identifier
| +--ro client-id? te-global-id | +--ro provider-id? te-global-id
| +--ro topology-id? te-topology-id | +--ro client-id? te-global-id
+--ro abstract-node? | +--ro topology-id? te-topology-id
| -> /nw:networks/network/node/tet:te-node-id +--ro abstract-node?
+--ro vn-member-list* [id] | -> /nw:networks/network/node/tet:te-node-id
+--ro id vnm-id +--ro vn-member-list* [id]
+--ro src +--ro id vnm-id
| +--ro ap? -> /access-point/ap/id +--ro src
| +--ro vn-ap-id? | +--ro ap? -> /access-point/ap/id
| | -> /access-point/ap[id=current()/../ap]/vn-ap/id | +--ro vn-ap-id?
| +--ro multi-src? boolean {multi-src-dest}? | | -> /access-point/ap[id=current()/../ap]/vn-ap/id
+--ro dest | +--ro multi-src? boolean {multi-src-dest}?
| +--ro ap? -> /access-point/ap/id +--ro dest
| +--ro vn-ap-id? | +--ro ap? -> /access-point/ap/id
| | -> /access-point/ap[id=current()/../ap]/vn-ap/id | +--ro vn-ap-id?
| +--ro multi-dest? boolean {multi-src-dest}? | | -> /access-point/ap[id=current()/../ap]/vn-ap/id
+--ro connectivity-matrix-id? leafref | +--ro multi-dest? boolean {multi-src-dest}?
+--ro underlay +--ro connectivity-matrix-id? leafref
+--ro if-selected? boolean {multi-src-dest}? +--ro underlay
+--ro compute-status? vn-compute-status +--ro if-selected? boolean {multi-src-dest}?
+--ro error-info +--ro compute-status? vn-compute-status
+--ro error-description? string +--ro error-info
+--ro error-timestamp? yang:date-and-time +--ro error-description? string
+--ro error-reason? identityref +--ro error-timestamp? yang:date-and-time
+--ro error-reason? identityref]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="sect-4.3.2" numbered="true" toc="default"> <section anchor="sect-4.3.2" numbered="true" toc="default">
<name>Multi-sources and Multi-destinations</name> <name>Multiple Sources and Multiple Destinations</name>
<t> <t>
In creating a virtual network, the list of sources or destinations In creating a virtual network, the list of sources or destinations
or both may not be pre-determined by the customer. For instance, for or both may not be predetermined by the customer. For instance, for
a given source, there may be a list of multiple-destinations to a given source, there may be a list of multiple destinations to
which the optimal destination may be chosen depending on the network which the optimal destination may be chosen depending on the network
resource situations. Likewise, for a given destination, there may resource situations. Likewise, for a given destination, there may
also be multiple-sources from which the optimal source may be also be multiple sources from which the optimal source may be
chosen. In some cases, there may be a pool of multiple sources and chosen. In some cases, there may be a pool of multiple sources and
destinations from which the optimal source-destination may be destinations from which the optimal source-destination may be
chosen. The following YANG tree shows chosen. The following YANG tree shows
how to model multi-sources and multi-destinations.</t> how to model multiple sources and multiple destinations.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode name="" type="yangtree"><![CDATA[
module: ietf-vn module: ietf-vn
+--rw virtual-network +--rw virtual-network
+--rw vn* [id] +--rw vn* [id]
+--rw id vn-id +--rw id vn-id
+--rw te-topology-identifier +--rw te-topology-identifier
| +--rw provider-id? te-global-id | +--rw provider-id? te-global-id
| +--rw client-id? te-global-id | +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id | +--rw topology-id? te-topology-id
+--rw abstract-node? +--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id | -> /nw:networks/network/node/tet:te-node-id
skipping to change at line 814 skipping to change at line 939
| | +--rw ap? -> /access-point/ap/id | | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id? | | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/vn-ap/id | | | -> /access-point/ap[id=current()/../ap]/vn-ap/id
| | +--rw multi-dest? boolean {multi-src-dest}? | | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref | +--rw connectivity-matrix-id? leafref
| +--rw underlay | +--rw underlay
| +--ro oper-status? te-types:te-oper-status | +--ro oper-status? te-types:te-oper-status
| +--ro if-selected? boolean {multi-src-dest}? | +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? te-types:te-admin-status +--rw admin-status? te-types:te-admin-status
+--ro oper-status? te-types:te-oper-status +--ro oper-status? te-types:te-oper-status
+--rw vn-level-diversity? te-types:te-path-disjointness +--rw vn-level-diversity? te-types:te-path-disjointness]]></source code>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="sect-4.4" numbered="true" toc="default"> <section anchor="sect-4.4" numbered="true" toc="default">
<name>Others</name> <name>Others</name>
<t> <t>
The VN YANG model can be easily augmented to support the mapping of The VN YANG model can easily be augmented to support the mapping of
VN to the Services such as L3SM and L2SM as described in <xref target="I-D.ie VN to the services such as L3SM and L2SM as described in <xref target="I-D.ie
tf-teas-te-service-mapping-yang" format="default"/>.</t> tf-teas-te-service-mapping-yang" format="default"/>.</t>
<t> <t>
The VN YANG model can be extended to support telemetry, performance The VN YANG model can be extended to support telemetry, performance
monitoring and network autonomics as described in <xref target="I-D.ietf-teas monitoring, and network autonomics as described in <xref target="I-D.ie
-actn-pm-telemetry-autonomics" format="default"/>.</t> tf-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 mo del <xref target="RFC8795" format="default"/>. Any underlay technology not suppo rted 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 a ugmented. For example the Segment Routing (SR) Policy <xref target="RFC9256"/> i nformation can be augmented for the SR underlay by a future model.</t> <t>Note that the YANG model is tightly coupled with the TE Topology mo del <xref target="RFC8795" format="default"/>. Any underlay technology not suppo rted 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 a ugmented. For example the Segment Routing (SR) Policy <xref target="RFC9256"/> i nformation can be augmented for the SR underlay by a future model.</t>
<t>Apart from the te-types:generic-path-constraints and te-types:generic <!--[rfced] RFC 4124 does not use the term "cos" or "class of
-path-optimization, an additional leaf cos for the class of service <xref target service". Is this citation in the right place in the sentence?
="RFC4124"/> is added to represent the Class-Type of traffic to be used as one
of the path constraints.</t> 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 leaf called "cos" for the class of service <xr
ef target="RFC4124"/> is added to represent the Class-Type of traffic to be use
d as one of the path constraints.</t>
</section> </section>
<section anchor="sect-4.5" numbered="true" toc="default"> <section anchor="sect-4.5" numbered="true" toc="default">
<name>Summary</name> <name>Summary</name>
<t> <t>
This section summarizes the features of the VN This section summarizes the features of the VN
YANG.</t> YANG model.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Maintenance of AP and VNAP along with VN</li> <li>Maintenance of APs and VNAPs along with the VN</li>
<li>VN construct to group of edge-to-edge links</li> <li>VN construct to group of edge-to-edge links</li>
<li> <li><t>Ability to support various VN and VNS Types</t>
<t>Ability to support various VN and VNS Types
</t>
<ul spacing="normal"> <ul spacing="normal">
<li>VN Type 1: Customer configures the VN as a set of VN <li>VN Type 1: Customer configures the VN as a set of VN
Members. Members. No other details need to be set by the customer,
No other details need to be set by the customer, making for a making for a simplified operation for the customer.</li>
simplified operation for the customer.</li> <li><t>VN Type 2: Along with VN Members, the customer could
<li>VN Type 2: Along with VN Members, the customer could also also provide an abstract topology, this topology is provided
provide an abstract topology, this topology is provided by by the Abstract TE Topology YANG Model.</t>
the Abstract TE Topology YANG Model.</li> <ul spacing="normal">
<li>Note that the VN Type is not explicitly identified in the VN Yan <li>Note that the VN Type is not explicitly identified in
g model, as the VN Model is exactly the same for both VN Type 1 and 2. The VN ty the VN Yang model, as the VN Model is exactly the same for
pe can be implicitly known based on the referenced TE topology and whether the c both VN Type 1 and VN Type 2. The VN type can be implicitly kno
onnectivity matrix includes the underlay path (Type 2) or not (Type 1).</li> wn
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> </ul>
</li> </li>
<li>VN Compute (pre-instantiate)</li> <li>VN Compute (pre-instantiate)</li>
<li>Multi-Source / Multi-Destination</li> <li>Multi-Source / Multi-Destination</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default"> <section anchor="sect-5" numbered="true" toc="default">
<name>VN YANG Model (Tree Structure)</name> <name>VN YANG Model (Tree Structure)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode name="" type="yangtree"><![CDATA[
module: ietf-vn module: ietf-vn
+--rw access-point +--rw access-point
| +--rw ap* [id] | +--rw ap* [id]
| +--rw id ap-id | +--rw id ap-id
| +--rw pe? | +--rw pe?
| | -> /nw:networks/network/node/tet:te-node-id | | -> /nw:networks/network/node/tet:te-node-id
| +--rw max-bandwidth? te-types:te-bandwidth | +--rw max-bandwidth? te-types:te-bandwidth
| +--rw avl-bandwidth? te-types:te-bandwidth | +--rw avl-bandwidth? te-types:te-bandwidth
| +--rw vn-ap* [id] | +--rw vn-ap* [id]
| +--rw id ap-id | +--rw id ap-id
skipping to change at line 1010 skipping to change at line 1178
| +--ro vn-ap-id? | +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/vn-ap/id | | -> /access-point/ap[id=current()/../ap]/vn-ap/id
| +--ro multi-dest? boolean {multi-src-dest}? | +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref +--ro connectivity-matrix-id? leafref
+--ro underlay +--ro underlay
+--ro if-selected? boolean {multi-src-dest}? +--ro if-selected? boolean {multi-src-dest}?
+--ro compute-status? vn-compute-status +--ro compute-status? vn-compute-status
+--ro error-info +--ro error-info
+--ro error-description? string +--ro error-description? string
+--ro error-timestamp? yang:date-and-time +--ro error-timestamp? yang:date-and-time
+--ro error-reason? identityref +--ro error-reason? identityref]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default"> <section anchor="sect-6" numbered="true" toc="default">
<name>VN YANG Model</name> <name>VN YANG Model</name>
<t>
The YANG model is as follows:</t> <!--[rfced] We had the following questions about the YANG module in
<sourcecode name="ietf-vn@2024-06-22.yang" type="" markers="true"><![CDATA 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>
<sourcecode name="ietf-vn@2025-01-27.yang" type="" markers="true"><![CDATA
[
module ietf-vn { module ietf-vn {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn"; namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix vn; prefix vn;
/* Import common YANG types */ /* Import common YANG types */
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
skipping to change at line 1071 skipping to change at line 1312
"RFC 8795: YANG Data Model for Traffic Engineering (TE) "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies"; Topologies";
} }
organization organization
"IETF Traffic Engineering Architecture and Signaling (TEAS) "IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group"; Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/teas/> "WG Web: <https://datatracker.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org> WG List: <mailto:teas@ietf.org>
Editor: Young Lee <younglee.tx@gmail.com>
: Dhruv Dhody <dhruv.ietf@gmail.com>"; Editor: Young Lee <younglee.tx@gmail.com>
Editor: Dhruv Dhody <dhruv.ietf@gmail.com>";
description description
"This module contains a YANG module for the Virtual Network "This module contains a YANG module for the Virtual Network
(VN). It describes a VN operation module that can take place (VN). It describes a VN operation module that can take place
in the context of the Customer Network Controller (CNC)- in the context of the Customer Network Controller (CNC) -
Multi-Domain Service Coordinator (MDSC) interface (CMI) of Multi-Domain Service Coordinator (MDSC) interface (CMI) of
the Abstraction and Control of Traffic Engineered (TE) the Abstraction and Control of TE Networks (ACTN)
Networks (ACTN) architecture where the CNC is the actor of architecture where the CNC is the actor of a VN
a VN Instantiation/modification/deletion as per RFC 8453. instantiation/modification/deletion as per RFC 8453.
This module uses following abbreviations: This module uses the following abbreviations:
- VN: Virtual Network - VN: Virtual Network
- AP: Access Point - AP: Access Point
- VNAP: Virtual Network Access Point - VNAP: Virtual Network Access Point
- LTP: Link Termination Point - LTP: Link Termination Point
- PE: Provider Edge - PE: Provider Edge
- COS: Class of Service - COS: Class of Service
Further, 'src' and 'dest' is used for source and destination Further, src and dest are used for source and
respectively. destination, respectively.
Copyright (c) 2024 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9731; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2024-06-22 { revision 2025-01-27 {
description description
"The initial version."; "The initial version.";
reference reference
"RFC XXXX: A YANG Data Model for Virtual Network (VN) "RFC 9731: A YANG Data Model for Virtual Network (VN)
Operations"; Operations";
} }
/* Features */ /* Features */
feature multi-src-dest { feature multi-src-dest {
description description
"Support for selection of one src or destination "Support for selection of one src or dest
among multiple."; among multiple.";
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)"; Networks (ACTN)";
} }
/* Typedef */ /* Typedef */
typedef vn-id { typedef vn-id {
type string { type string {
length "1..max"; length "1..max";
} }
description description
"A type definition for Virtual Network (VN) "A type definition for a Virtual Network (VN)
identifier."; identifier.";
} }
typedef ap-id { typedef ap-id {
type string { type string {
length "1..max"; length "1..max";
} }
description description
"A type definition for Access Point (AP) identifier."; "A type definition for an Access Point (AP) identifier.";
} }
typedef vnm-id { typedef vnm-id {
type string { type string {
length "1..max"; length "1..max";
} }
description description
"A type definition for VN member identifier."; "A type definition for a VN member identifier.";
} }
typedef vn-compute-status { typedef vn-compute-status {
type te-types:te-common-status; type te-types:te-common-status;
description description
"A type definition for representing the VN compute status. Note "A type definition for representing the VN compute status.
that all statuses apart from up and down are considered as Note that all statuses apart from up and down are considered
unknown."; to be unknown.";
} }
/* identities */ /* identities */
identity vn-computation-error-reason { identity vn-computation-error-reason {
description description
"Base identity for VN computation error reasons."; "Base identity for VN computation error reasons.";
} }
identity vn-computation-error-not-ready { identity vn-computation-error-not-ready {
base vn-computation-error-reason; base vn-computation-error-reason;
description description
"VN computation has failed because the MDSC is not "VN computation has failed because the MDSC is not
ready."; ready.";
} }
identity vn-computation-error-no-cnc { identity vn-computation-error-no-cnc {
base vn-computation-error-reason; base vn-computation-error-reason;
description description
"VN computation has failed because one or more dependent "VN computation has failed because one or more dependent
CNC are unavailable."; CNCs are unavailable.";
} }
identity vn-computation-error-no-resource { identity vn-computation-error-no-resource {
base vn-computation-error-reason; base vn-computation-error-reason;
description description
"VN computation has failed because there is no "VN computation has failed because there is no
available resource in one or more domains."; available resource in one or more domains.";
} }
identity vn-computation-error-path-not-found { identity vn-computation-error-path-not-found {
skipping to change at line 1219 skipping to change at line 1461
"A vn-member identifier."; "A vn-member identifier.";
} }
container src { container src {
description description
"The source of VN Member."; "The source of VN Member.";
leaf ap { leaf ap {
type leafref { type leafref {
path "/access-point/ap/id"; path "/access-point/ap/id";
} }
description description
"A reference to source AP."; "A reference to the source AP.";
} }
leaf vn-ap-id { leaf vn-ap-id {
type leafref { type leafref {
path "/access-point/ap[id=current()/../ap]/vn-ap" path "/access-point/ap[id=current()/../ap]/vn-ap"
+ "/id"; + "/id";
} }
description description
"A reference to source VNAP."; "A reference to the source VNAP.";
} }
leaf multi-src { leaf multi-src {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
default "false"; default "false";
description description
"Is the source part of multi-source, where "Is the source part of a multi-source, where
only one of the sources is enabled."; only one of the sources is enabled?";
} }
} }
container dest { container dest {
description description
"the destination of VN Member."; "The destination of the VN Member.";
leaf ap { leaf ap {
type leafref { type leafref {
path "/access-point/ap/id"; path "/access-point/ap/id";
} }
description description
"A reference to destination AP."; "A reference to the destination AP.";
} }
leaf vn-ap-id { leaf vn-ap-id {
type leafref { type leafref {
path "/access-point/ap[id=current()/../ap]/" path "/access-point/ap[id=current()/../ap]/"
+ "vn-ap/id"; + "vn-ap/id";
} }
description description
"A reference to dest VNAP."; "A reference to the dest VNAP.";
} }
leaf multi-dest { leaf multi-dest {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
default "false"; default "false";
description description
"Is destination part of multi-destination, where only one "Is the destination part of a multi-destination,
of the destinations is enabled."; where only one of the destinations is enabled.";
} }
} }
leaf connectivity-matrix-id { leaf connectivity-matrix-id {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te/" path "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/" + "tet:te-node-attributes/"
+ "tet:connectivity-matrices/" + "tet:connectivity-matrices/"
+ "tet:connectivity-matrix/tet:id"; + "tet:connectivity-matrix/tet:id";
} }
description description
"A reference to connectivity-matrix."; "A reference to the connectivity-matrix.";
reference reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE) "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies"; Topologies";
} }
container underlay { container underlay {
description description
"An empty container that can be augmented with underlay "An empty container that can be augmented with underlay
technology information not supported by RFC 8795 (for technology information not supported by RFC 8795 (for
example - Segment Routing (SR)."; example - Segment Routing (SR).";
} }
skipping to change at line 1304 skipping to change at line 1546
description description
"The type of disjointness on the VN level (i.e., across all "The type of disjointness on the VN level (i.e., across all
VN members)."; VN members).";
} }
} }
/* Configuration data nodes */ /* Configuration data nodes */
container access-point { container access-point {
description description
"AP configurations"; "AP configurations.";
list ap { list ap {
key "id"; key "id";
description description
"access-point identifier."; "The access-point identifier.";
leaf id { leaf id {
type ap-id; type ap-id;
description description
"An AP identifier unique within the scope of the entity "An AP identifier unique within the scope of the entity
that controls the VN."; that controls the VN.";
} }
leaf pe { leaf pe {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
} }
skipping to change at line 1357 skipping to change at line 1599
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/nw:node-id"; path "/nw:networks/nw:network/nw:node/nw:node-id";
} }
must '/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' { + 'current()/../abstract-node]/tet:te-node-id' {
description description
"The associated network for the abstract-node "The associated network for the abstract-node
must be TE enabled."; must be TE enabled.";
} }
description description
"A reference to the abstract node that represent "A reference to the abstract node that represents
the VN."; the VN.";
} }
leaf ltp { leaf ltp {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node[nw:node-id=" path "/nw:networks/nw:network/nw:node[nw:node-id="
+ "current()/../abstract-node]/nt:termination-point/" + "current()/../abstract-node]/nt:termination-point/"
+ "tet:te-tp-id"; + "tet:te-tp-id";
} }
description description
"A reference to Link Termination Point (LTP) in the "A reference to the Link Termination Point (LTP)
abstract-node i.e. the LTP should be in the abstract in the abstract-node, i.e., the LTP should be in
layer, and not the underlying layer."; the abstract layer and not the underlying layer.";
reference reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE) "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies"; Topologies";
} }
leaf max-bandwidth { leaf max-bandwidth {
type te-types:te-bandwidth; type te-types:te-bandwidth;
config false; config false;
description description
"The max bandwidth of the VNAP."; "The max bandwidth of the VNAP.";
} }
description description
"List of VNAP in this AP."; "List of VNAPs in this AP.";
} }
} }
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 6"; Networks (ACTN), Section 6";
} }
container virtual-network { container virtual-network {
description description
"VN configurations."; "VN configurations.";
list vn { list vn {
skipping to change at line 1426 skipping to change at line 1668
config false; config false;
description description
"The vn-member operational state."; "The vn-member operational state.";
} }
leaf if-selected { leaf if-selected {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
default "false"; default "false";
config false; config false;
description description
"Is the vn-member selected among the multi-src/dest "Is the vn-member selected among the multi-src
options."; or multi-dest options?";
} }
} }
leaf admin-status { leaf admin-status {
type te-types:te-admin-status; type te-types:te-admin-status;
default "up"; default "up";
description description
"VN administrative state."; "VN administrative state.";
} }
leaf oper-status { leaf oper-status {
type te-types:te-oper-status; type te-types:te-oper-status;
skipping to change at line 1453 skipping to change at line 1695
} }
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)"; Networks (ACTN)";
} }
/* RPC */ /* RPC */
rpc vn-compute { rpc vn-compute {
description description
"The VN computation without actual instantiation. This is "The VN computation without actual instantiation. This is
used by the CNC to get the VN results without actually used by the CNC to get the VN results without actually
creating it in the network. creating it in the network.
The input could include a reference to the single-node The input could include a reference to the single-node
-abstract topology. It could optionally also include -abstract topology. It could optionally also include
constraints and optimization criteria. The computation constraints and optimization criteria. The computation
is done based on the list of VN-members. is done based on the list of VN-members.
The output includes a reference to the single-node The output includes a reference to the single-node
-abstract topology with each VN-member including a -abstract topology with each VN-member including a
reference to the connectivity-matrix-id where the reference to the connectivity-matrix-id where the
path properties could be found. Error information is path properties could be found. Error information is
also included."; also included.";
input { input {
uses te-types:te-topology-identifier; uses te-types:te-topology-identifier;
leaf abstract-node { leaf abstract-node {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
} }
description description
"A reference to the abstract node in TE Topology."; "A reference to the abstract node in TE Topology.";
} }
skipping to change at line 1521 skipping to change at line 1763
list vn-member-list { list vn-member-list {
key "id"; key "id";
description description
"List of VN-members in a VN."; "List of VN-members in a VN.";
uses vn-member; uses vn-member;
leaf if-selected { leaf if-selected {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
default "false"; default "false";
description description
"Is the vn-member selected among the multi-src/dest "Is the vn-member selected among the multi-src or
options."; multi-dest options?";
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 7"; Networks (ACTN), Section 7";
} }
leaf compute-status { leaf compute-status {
type vn-compute-status; type vn-compute-status;
description description
"The VN-member compute state."; "The VN-member compute state.";
} }
container error-info { container error-info {
description description
"Error information related to the VN member."; "Error information related to the VN member.";
leaf error-description { leaf error-description {
type string { type string {
length "1..max"; length "1..max";
} }
description description
"Textual representation of the error occurred during "Textual representation of the error that occurred
VN compute."; during VN compute.";
} }
leaf error-timestamp { leaf error-timestamp {
type yang:date-and-time; type yang:date-and-time;
description description
"Timestamp of the attempt."; "Timestamp of the attempt.";
} }
leaf error-reason { leaf error-reason {
type identityref { type identityref {
base vn-computation-error-reason; base vn-computation-error-reason;
} }
skipping to change at line 1560 skipping to change at line 1802
base vn-computation-error-reason; base vn-computation-error-reason;
} }
description description
"Reason for the VN computation error."; "Reason for the VN computation error.";
} }
} }
} }
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="sect-8" numbered="true" toc="default"> <section anchor="sect-8" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
<!--Begin DNE-->
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such 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"/>. as NETCONF <xref target="RFC6241" format="default"/> or RESTCONF <xref target ="RFC8040" format="default"/>.
The lowest NETCONF layer The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) transport is Secure Shell (SSH)
<xref target="RFC6242" format="default"/>. The lowest RESTCONF layer <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> is HTTPS, and the mandatory-to-implement secure transport is TLS <xref target ="RFC8446" format="default"/>.</t>
<t> <t>
The NETCONF access control model <xref target="RFC8341" format="default"/> pr ovides the means to The Network Configuration Access Control Model (NACM) <xref target="RFC8341" format="default"/> provides the means to
restrict access for particular NETCONF or RESTCONF users to a restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.</t> operations and content.</t>
<!--End DNE-->
<t> <t>
The model presented in this document is used in the interface The model presented in this document is used in the interface
between the CNC and MDSC, which is referred to as CNC-MDSC between the CNC and MDSC, which is referred to as CNC-MDSC
Interface (CMI). Security risks such as malicious Interface (CMI). Security risks, such as malicious
attack and rogue elements attempting to connect to the various ACTN attack and rogue elements attempting to connect to the various ACTN
components are possible. Furthermore, some ACTN components (e.g., MDSC) components, are possible. Furthermore, some ACTN components (e.g., MDSC)
represent a single point of failure and threat vector. Also, there is a need to represent a single point of failure and threat vector. Also, there is a need to
manage policy conflicts and eavesdropping of communication between manage policy conflicts and eavesdropping on communication between
different ACTN components.</t> different ACTN components.</t>
<t> <t>
<!--Begin DNE-->
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., "config true", which is the writable/creatable/deletable (i.e., "config true", which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:</t> and their sensitivity/vulnerability:</t>
<!--End DNE -->
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>ap: This list includes a set of sensitive data that influences how the access points in the VN service are attached. By accessing the following dat a nodes, an attacker may be able to manipulate the VN.</t> <t>ap: This list includes a set of sensitive data that influences how the APs in the VN service are attached. By accessing the following data nodes, a n attacker may be able to manipulate the VN.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>id</li> <li>id</li>
<li>pe</li> <li>pe</li>
<li>max-bandwidth</li> <li>max-bandwidth</li>
<li>avl-bandwidth</li> <li>avl-bandwidth</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>vn-ap: This list includes a set of sensitive data that influences h ow the VN service is delivered. By accessing the following data nodes, an attack er may be able <t>vn-ap: This list includes a set of sensitive data that influences h ow the VN service is delivered. By accessing the following data nodes, an attack er may be able
to manipulate the VN.</t> to manipulate the VN.</t>
skipping to change at line 1638 skipping to change at line 1888
<ul spacing="normal"> <ul spacing="normal">
<li>id</li> <li>id</li>
<li>src/ap</li> <li>src/ap</li>
<li>src/vn-ap-id</li> <li>src/vn-ap-id</li>
<li>dest/ap</li> <li>dest/ap</li>
<li>dest/vn-ap-id</li> <li>dest/vn-ap-id</li>
<li>connectivity-matrix-id</li> <li>connectivity-matrix-id</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<!--Begin DNE-->
<t>Some of the readable data nodes in this YANG module may be considered <t>Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:</t> nodes and their sensitivity/vulnerability:</t>
<!--End DNE -->
<ul spacing="normal"> <ul spacing="normal">
<li>oper-status: This leaf can reveal the current operational state of t he VN.</li> <li>oper-status: This leaf can reveal the current operational state of t he VN.</li>
<li>if-selected: This leaf can reveal which vn-member is selected among the various multi-src/dest options.</li> <li>if-selected: This leaf can reveal which vn-member is selected among the various multi-src/dest options.</li>
</ul> </ul>
<!--Begin DNE -->
<t>Some of the RPC operations in this YANG module may be considered <t>Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the important to control access to these operations. These are the
operations and their sensitivity/vulnerability:</t> operations and their sensitivity/vulnerability:</t>
<!--End DNE -->
<ul spacing="normal"> <ul spacing="normal">
<li>vn-compute: This RPC triggers the VN computation at the MDSC which c an reveal the VN information. <li>vn-compute: This RPC triggers the VN computation at the MDSC, which can reveal the VN information.
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="sect-9" numbered="true" toc="default"> <section anchor="sect-9" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>
IANA is requested to make the following allocation for the URIs in the "ns" s
ubregistry
within the "IETF XML Registry" <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, the requested URI is an XML namespace.
]]></artwork> <t>IANA has made the following allocation for a URI in
<t> the "ns" registry within the "IETF XML Registry" registry group <xref
IANA is requested to make the following allocation for the YANG module in th target="RFC3688" format="default"/>:</t>
e "YANG Module Names" <dl spacing="compact" newline="false">
registry <xref target="RFC6020" format="default"/>:</t> <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-vn</dd>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dt>Registrant Contact:</dt> <dd>The IESG.</dd>
name: ietf-vn <dt>XML:</dt> <dd>N/A, the requested URI is an XML namespace.</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-vn </dl>
prefix: vn
reference: RFC XXXX <!--[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 [RFC6020]:
Perhaps:
IANA has made the following allocation for the YANG module in the
"YANG Module Names" registry ([RFC6020] and [RFC8407]):
-->
<t>IANA has made the following allocation for the VN YANG
module (see <xref target="sect-5" format="default"/>in the "YANG Module Na
mes" 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>
]]></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 val
uable suggestions.</t>
<t>Thanks to Andy Bierman for YANGDIR review. Thanks to Darren Dukes for R
TGDIR review. Thanks to Behcet Sarikaya for GENART review. Thanks to Bo Wu for O
PSDIR review. Thanks to Shivan Sahib for SECDIR review. Thanks to Susan Hares fo
r RTGDIR review.</t>
<t>Thanks to Deb Cooley, Francesca Palombini, Gunter Van de Velde, and Mah
esh Jethanandani for IESG review.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-teas-te-service-mapping-yang" to="TE-SERV
ICE-MAPPING"/>
<displayreference target="I-D.ietf-teas-actn-pm-telemetry-autonomics" to="TE
AS-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> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
FC.3688.xml"/> 688.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4124.xml"/> 124.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.6020.xml"/> 020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.6241.xml"/> 241.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.6242.xml"/> 242.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8040.xml"/> 040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8340.xml"/> 340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8341.xml"/> 341.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8342.xml"/> 342.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8446.xml"/> 446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8345.xml"/> 345.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8776.xml"/> 776.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.7950.xml"/> 950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.6991.xml"/> 991.xml"/>
<!--<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ce.RFC.2119.xml"/> 795.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8795.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.7926.xml"/> 926.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8453.xml"/> 453.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8454.xml"/> 454.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R 466.xml"/>
FC.8466.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R 299.xml"/>
FC.8299.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R 309.xml"/>
FC.8309.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R 256.xml"/>
FC.9256.xml"/>
<!--[I-D.ietf-teas-te-service-mapping-yang] IESG state: I-D Exists as of 10/03/2 4-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-te as-te-service-mapping-yang.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-te as-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-te as-actn-pm-telemetry-autonomics.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-te as-actn-pm-telemetry-autonomics.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-cc
amp-l1csm-yang.xml"/> <!--[I-D.ietf-ccamp-l1csm-yang] IESG state: RFC Ed Queue (MISSREF) as of 10/03/2
4: (C502); used the long-form reference to fix Oscar's name. -->
<reference anchor="I-D.ietf-ccamp-l1csm-yang" target="https://datatracker.ietf.o
rg/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-te as-yang-te.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-te as-yang-te.xml"/>
</references> </references>
</references> </references>
<section anchor="sect-constraints" numbered="true" toc="default"> <section anchor="sect-constraints" numbered="true" toc="default">
<name>Performance Constraints</name> <name>Performance Constraints</name>
<t>At the time of creation of VN, it is natural to provide VN level constr
aints and optimization criteria. It should be noted that this YANG module relies <!--[rfced] Replacing "this" with its antecedent may help the reader
on the TE-Topology Model <xref target="RFC8795" format="default"/> by using a r with clarity.
eference to an abstract node to achieve this. Further, the connectivity-matrix s
tructure is used to assign the constraints and optimization criteria including d Original:
elay, jitter etc. <xref target="RFC8776" format="default"/> defines some of the It should be noted that this YANG module relies on the TE-Topology
metric-types already and future documents are meant to augment it.</t> 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 the creation of a VN, it is natural to provide VN-level constraints
and optimization criteria. It should be noted that the VN YANG module described
in this document relies on the TE-Topology Model in <xref target="RFC8795" forma
t="default"/> by using a reference to an abstract node to achieve this. Further,
the connectivity-matrix structure is used to assign the constraints and optimiz
ation criteria including delay, jitter, etc. <xref target="RFC8776" format="defa
ult"/> defines some of the metric-types; future documents are meant to augment i
t.</t>
<t>Note that the VN compute allows the inclusion of the constraints and th e optimization criteria directly in the RPC to allow it to be used independently .</t> <t>Note that the VN compute allows the inclusion of the constraints and th e optimization criteria directly in the RPC to allow it to be used independently .</t>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default"> <section anchor="sect-7" numbered="true" toc="default">
<name>JSON Example</name> <name>JSON Example</name>
<section anchor="sect-7-1" numbered="true" toc="default"> <section anchor="sect-7-1" numbered="true" toc="default">
<name>VN JSON</name> <name>VN JSON</name>
<t> <t>
This section provides JSON examples of how VN YANG This section provides JSON examples of how the VN YANG
model and TE topology model are used together to instantiate VN.</t> model and TE topology model are used together to instantiate a VN.</t>
<t> <t>
The example in this section includes the following VN</t> The example in this section includes the following VNs:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>VN1 (Type 1): Which maps to the single node topology abstract1 <li>VN1 (Type 1): This VN maps to the single node topology abstract1
and consist of VN Members 104 (L1 to L4), 107 (L1 to and consists of VN Members 104 (L1 to L4), 107 (L1 to
L7), 204 (L2 to L4), 308 (L3 to L8) and 108 (L1 to L8).</li> L7), 204 (L2 to L4), 308 (L3 to L8), and 108 (L1 to L8).</li>
<li>VN2 (Type 2): Which maps to the single node topology abstract2, <li>VN2 (Type 2): This VN maps to the single node topology abstract2;
this topology has an underlay topology (called underlay). this topology has an underlay topology (called underlay).
This VN has a single VN member 105 (L1 to This VN has a single VN member 105 (L1 to
L5) and an underlay path (S4 and S7) has been set in the L5) and an underlay path (S4 and S7) has been set in the
connectivity matrix of abstract2 topology;</li> connectivity matrix of the abstract2 topology;</li>
<li>VN3 (Type 1): This VN has a multi-source and multi-destination <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) 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) showca se multi-src feature. The selected VN-member is known via the field "if-selected " and the corresponding connectivity-matrix-id.</li> showcase multi-dest and VN Member 108 (L1 to L8) and 308 (L3 to L8) showca se the multi-src feature. The selected VN-member is known via the field "if-sele cted" and the corresponding connectivity-matrix-id.</li>
</ul> </ul>
<figure>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
L1---104---L4 L1---105---L5 L1---106---L6(md) L1---104---L4 L1---105---L5 L1---106---L6(md)
L1---107---L7 Underlay Path: L1---107---L7(md) L1---107---L7 Underlay Path: L1---107---L7(md)
L2---204---L4 (S4 and S7) L1---108---L8(ms) L2---204---L4 (S4 and S7) L1---108---L8(ms)
L3---308---L8 L3---308---L8(ms) L3---308---L8 L3---308---L8(ms)
L1---108---L8 L1---108---L8
--- --- ---
VN1 VN2 VN3
--- --- ---]]></artwork>
</figure>
--- --- ---
VN1 VN2 VN3
--- --- ---
]]></artwork>
<t> <t>
Note that the VN YANG model also includes the AP and VNAP which shows Note that the VN YANG model also includes the AP and VNAP, which shows
various VN using the same AP.</t> various VNs using the same AP.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode name="" type=""><![CDATA[
{ {
"ietf-vn:access-point": { "ietf-vn:access-point": {
"ap": [ "ap": [
{ {
"id": "101", "id": "101",
"vn-ap": [ "vn-ap": [
{ {
"id": "10101", "id": "10101",
"vn": "1", "vn": "1",
"abstract-node": "192.0.2.1", "abstract-node": "192.0.2.1",
skipping to change at line 2051 skipping to change at line 2382
"ap": "808", "ap": "808",
"vn-ap-id": "80803" "vn-ap-id": "80803"
}, },
"connectivity-matrix-id": 30308, "connectivity-matrix-id": 30308,
"if-selected": true "if-selected": true
} }
] ]
} }
] ]
} }
} }]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="sect-7-2" numbered="true" toc="default"> <section anchor="sect-7-2" numbered="true" toc="default">
<name>TE-topology JSON</name> <name>TE-Topology JSON</name>
<t> <t>
This section provides JSON examples of the various TE topology instances.</t> This section provides JSON examples of the various TE topology instances.</t>
<t> <t>
The example in this section includes the following TE Topologies</t> The example in this section includes the following TE Topologies:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>abstract1: a single node TE topology referenced by VN1. We also <li>abstract1: a single node TE topology referenced by VN1. We also
show how disjointness (node, link, Shared Risk Link Group (SRLG)) is suppo rted in the example on the connectivity matrices.</li> show how disjointness (node, link, Shared Risk Link Group (SRLG)) is suppo rted in the example on the connectivity matrices.</li>
<li>abstract2: a single node TE topology referenced by VN2 with underlay <li>abstract2: a single node TE topology referenced by VN2 with an under
path.</li> lay path.</li>
<li>underlay: the topology with multiple nodes (in the underlay path of <li>underlay: the topology with multiple nodes (in the underlay path of
abstract2). For brevity, the example includes only the node and other parameters abstract2). For brevity, the example includes only the node: other parameters ar
are not included.</li> e not included.</li>
<li>abstract3: a single node TE topology referenced by VN3.</li> <li>abstract3: a single node TE topology referenced by VN3.</li>
</ul> </ul>
<artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode name="" type=""><![CDATA[
{ {
"ietf-network:networks": { "ietf-network:networks": {
"network": [ "network": [
{ {
"network-types": { "network-types": {
"ietf-te-topology:te-topology": {} "ietf-te-topology:te-topology": {}
}, },
"network-id": "example:abstract1", "network-id": "example:abstract1",
"ietf-te-topology:te-topology-identifier": { "ietf-te-topology:te-topology-identifier": {
"provider-id": 0, "provider-id": 0,
skipping to change at line 2408 skipping to change at line 2739
} }
] ]
} }
} }
} }
} }
] ]
} }
] ]
} }
} }]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="sect-contributors" numbered="true" toc="default">
<name>Contributors Addresses</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Qin Wu
Huawei Technologies
Email: bill.wu@huawei.com
Peter Park <section anchor="sect-10" numbered="false" toc="default">
KT <name>Acknowledgments</name>
Email: peter.park@kt.com <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>
Haomian Zheng <t>Thanks to:</t>
Huawei Technologies <ul spacing="compact">
Email: zhenghaomian@huawei.com <li><t><contact fullname="Andy Bierman"/> for the YANGDIR
review.</t></li>
<li><t><contact fullname="Darren Dukes"/> and <contact fullname="Susan Ha
res"/> 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>
Xian Zhang <section anchor="sect-contributors" numbered="false" toc="default">
Huawei Technologies <name>Contributors' Addresses</name>
Email: zhang.xian@huawei.com
Sergio Belotti <contact fullname="Qin Wu">
Nokia <organization>Huawei Technologies</organization>
Email: sergio.belotti@nokia.com <address>
<email>bill.wu@huawei.com</email>
</address>
</contact>
Takuya Miyasaka <contact fullname="Peter Park">
KDDI <organization>KT</organization>
Email: ta-miyasaka@kddi.com <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>
Kenichi Ogaki
KDDI
Email: ke-oogaki@kddi.com
]]></artwork>
</section> </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> </back>
</rfc> </rfc>
 End of changes. 194 change blocks. 
658 lines changed or deleted 1208 lines changed or added

This html diff was produced by rfcdiff 1.48.