rfc9358xml2.original.xml   rfc9358.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!DOCTYPE rfc [
C.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY zwsp "&#8203;">
C.4655.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY wj "&#8288;">
C.5440.xml">
<!ENTITY RFC5541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5541.xml">
<!ENTITY RFC6805 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6805.xml">
<!ENTITY RFC7470 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7470.xml">
<!ENTITY RFC7942 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7942.xml">
<!ENTITY RFC8051 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8051.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8231.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8253.xml">
<!ENTITY RFC8281 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8281.xml">
<!ENTITY RFC8453 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8453.xml">
<!ENTITY RFC8637 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8637.xml">
<!ENTITY RFC8751 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8751.xml">
<!ENTITY RFC8697 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8697.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8253.xml">
<!ENTITY RFC0020 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.0020.xml">
]> ]>
<rfc submissionType="IETF" docName="draft-ietf-pce-vn-association-11" category=" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
std" ipr="trust200902"> std" consensus="true" docName="draft-ietf-pce-vn-association-11" number="9358" i
<!-- Generated by id2xml 1.5.0 on 2020-01-02T21:47:46Z --> pr="trust200902"
<?rfc strict="yes"?> obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude=
<?rfc compact="yes"?> "true" version="3">
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?> <!-- xml2rfc v2v3 conversion 3.15.1 -->
<?rfc sortrefs="no"?> <!-- Generated by id2xml 1.5.0 on 2020-01-02T21:47:46Z -->
<?rfc text-list-symbols="o*+-"?>
<?rfc toc="yes"?>
<front> <front>
<title abbrev="PCE VN Association"> Path Computation Element Communication P
rotocol (PCEP) extensions for establishing relationships between sets of Label S <title abbrev="PCEP VN Association">Path Computation Element Communication
witched Paths and Virtual Networks</title> Protocol (PCEP) Extensions for Establishing Relationships between Sets of
<author fullname="Young Lee" initials="Y." surname="Lee"> Label Switched Paths and Virtual Networks</title>
<organization>Samsung</organization> <seriesInfo name="RFC" value="9358"/>
<author fullname="Young Lee" initials="Y." surname="Lee">
<organization>Samsung Electronics</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Seoul</city> <city>Seoul</city>
<region></region> <region/>
<code></code> <code/>
<country>South Korea</country> <country>Republic of Korea</country>
</postal> </postal>
<email>younglee.tx@gmail.com</email> <email>younglee.tx@gmail.com</email>
</address> </address>
</author> </author>
<author initials="H." surname="Zheng" fullname="Haomian Zheng">
<author initials="H." surname="Zheng" fullname="Haomian Zheng"> <organization>Huawei Technologies</organization>
<organization>Huawei Technologies</organization> <address>
<address> <postal>
<postal> <street>H1, Huawei Xiliu Beipo Village Songshan Lake</street>
<street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street> <city>Dongguan</city>
<city>Dongguan</city> <region>Guangdong</region>
<region>Guangdong</region> <code>523808</code>
<code>523808</code> <country>China</country>
<country>China</country> </postal>
</postal> <email>zhenghaomian@huawei.com</email>
<email>zhenghaomian@huawei.com</email> </address>
</address> </author>
</author>
<author initials="D." surname="Ceccarelli" fullname="Daniele Ceccarelli"> <author initials="D." surname="Ceccarelli" fullname="Daniele Ceccarelli">
<organization>Ericsson</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>Torshamnsgatan,48</street> <street>Torshamnsgatan,48</street>
<city>Stockholm</city> <city>Stockholm</city>
<region></region> <region/>
<code></code> <code/>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>daniele.ceccarelli@ericsson.com</email> <email>daniele.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date year="2023" month="February"/>
<area>rtg</area>
<workgroup>pce</workgroup>
<date year="2022" month="October" day="24"/>
<workgroup>PCE Working Group</workgroup>
<abstract> <abstract>
<t> This document describes how to extend the Path Computation Element (PCE)
Communication Protocol (PCEP) association mechanism introduced by the PCEP Asso
ciation Group specification, to further associate sets of Label Switched Paths (
LSPs) with a higher-level structure such as a Virtual Network (VN) requested by
a customer or application. This extended association mechanism can be used to fa
cilitate control of virtual network using the PCE architecture.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sect-1">
<t> The Path Computation Element Communication Protocol (PCEP) provides mech
anisms for Path Computation Elements (PCEs) to perform path computations in resp
onse to requests from Path Computation Clients (PCCs) <xref target="RFC5440"/>.
</t>
<t> <xref target="RFC8051"/> describes general considerations for a stateful
PCE deployment and examines its applicability and benefits, as well as its chal
lenges and limitations through a number of use cases. <xref target="RFC8231"/> d
escribes a set of extensions to PCEP to provide stateful control. For its comput
ations, a stateful PCE has access to not only the information carried by the net
work's Interior Gateway Protocol (IGP), but also the set of active paths and the
ir reserved resources. The additional state allows the PCE to compute constrain
ed paths while considering individual Label Switched Paths (LSPs) and their inte
ractions. </t>
<t> <xref target="RFC8281"/> describes the setup, maintenance and teardown o
f PCE-initiated LSPs under the stateful PCE model. </t>
<t> <xref target="RFC8697"/> introduces a generic mechanism to create a grou <t> This document describes how to extend the Path Computation Element
ping of LSPs. This grouping can then be used to define associations between sets Communication Protocol (PCEP) association mechanism introduced by RFC 8697 to
of LSPs or between a set of LSPs and a set of attributes. </t> further associate sets of Label Switched Paths (LSPs) with a higher-level
structure such as a Virtual Network (VN) requested by a customer or
<t> <xref target="RFC8453"/> introduces a framework for Abstraction and Cont application. This extended association mechanism can be used to facilitate
rol of TE Networks (ACTN) and describes various Virtual Network (VN) operations control of a VN using the PCE architecture.</t>
initiated by a customer or application. A VN is a customer view of the TE netwo </abstract>
rk. Depending on the agreement between client and provider, various VN operatio </front>
ns and VN views are possible. </t> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<t> <xref target="RFC8637"/> examines the PCE and ACTN architectures and <name>Introduction</name>
describes how the PCE architecture is applicable to ACTN. <xref target="RFC6805 <t> The Path Computation Element Communication Protocol (PCEP) provides me
"/> and <xref target="RFC8751"/> describes a hierarchy of stateful PCEs with Par chanisms for Path Computation Elements (PCEs) to perform path computations in re
ent PCE coordinating multi-domain path computation function between Child PCEs, sponse to requests from Path Computation Clients (PCCs) <xref target="RFC5440" f
and thus making it the base for PCE applicability for ACTN. As <xref target="RF ormat="default"/>. </t>
C8751"/> explains, in the context of ACTN, the Child PCE is identified with the <t> <xref target="RFC8051" format="default"/> describes general considerat
Provisioning Network Controller (PNC), and the Parent PCE is identified with the ions for a stateful PCE deployment and examines its applicability and benefits a
Multi-domain Service Coordinator (MDSC).</t> s well as its challenges and limitations through a number of use cases. <xref ta
rget="RFC8231" format="default"/> describes a set of extensions to PCEP to provi
<t> In this context, there is a need to associate a set of LSPs with a VN de stateful control. For its computations, a stateful PCE has access to not only
"construct" to facilitate VN operations in the PCE architecture. This associat the information carried by the network's Interior Gateway Protocol (IGP) but al
ion allows a PCE to identify which LSPs belong to a certain VN. The PCE could t so the set of active paths and their reserved resources. The additional state a
hen use this association to optimize all LSPs belonging to the VN at once. The llows the PCE to compute constrained paths while considering individual Label Sw
PCE could further take VN-specific actions on the LSPs, such as relaxation of co itched Paths (LSPs) and their interactions. </t>
nstraints, policy actions, setting default behavior, etc. </t> <t> <xref target="RFC8281" format="default"/> describes the setup, mainten
<t> This document specifies a PCEP extension to associate a set of LSPs b ance, and teardown of PCE-initiated LSPs under the stateful PCE model. </t>
ased on their Virtual Network (VN). </t> <t> <xref target="RFC8697" format="default"/> introduces a generic mechani
sm to create a grouping of LSPs. This grouping can then be used to define associ
ations between sets of LSPs or between a set of LSPs and a set of attributes. </
t>
<t> <xref target="RFC8453" format="default"/> introduces a framework for A
bstraction and Control of TE Networks (ACTN) and describes various VN operations
initiated by a customer or application. A VN is a customer view of the TE netw
ork. Depending on the agreement between client and provider, various VN operati
ons and VN views are possible. </t>
<section title="Requirement Language" anchor="sect-1.1"> <t> <xref target="RFC8637" format="default"/> examines the PCE and ACTN architec
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOU tures and describes how the PCE architecture is applicable to ACTN. <xref targe
LD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in th t="RFC6805" format="default"/> and <xref target="RFC8751" format="default"/> des
is document are to be interpreted as described in BCP 14 <xref target="RFC2119"/ cribe a hierarchy of stateful PCEs with the parent PCE coordinating multi-domain
> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as path computation functions between child PCEs, thus making it the base for PCE
shown here.</t> applicability for ACTN. As <xref target="RFC8751" format="default"/> explains,
</section> in the context of ACTN, the child PCE is identified with the Provisioning Networ
k Controller (PNC), and the parent PCE is identified with the Multi-Domain Servi
ce Coordinator (MDSC).</t>
<t> In this context, there is a need to associate a set of LSPs with a VN
"construct" to facilitate VN operations in the PCE architecture. This associati
on allows a PCE to identify which LSPs belong to a certain VN. The PCE could th
en use this association to optimize all LSPs belonging to the VN at once. The P
CE could further take VN-specific actions on the LSPs, such as relaxing constrai
nts, taking policy actions, setting default behavior, etc. </t>
<t> This document specifies a PCEP extension to associate a set of LSPs ba
sed on their VN. </t>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Terminology</name>
<t>This document uses terminology from <xref target="RFC4655" format="default"/>
, <xref target="RFC5440" format="default"/>, <xref target="RFC6805" format="defa
ult"/>, <xref target="RFC8231" format="default"/>, and <xref target="RFC8453" fo
rmat="default"/>. </t>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
<section title="Terminology" anchor="sect-2">
<t>The terminology is as per <xref target="RFC4655"/>, <xref target="RFC5440
"/>, <xref target="RFC6805"/>, <xref target="RFC8231"/> and <xref target="RFC845
3"/>. </t>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default">
<name>Operation Overview</name>
<t>As per <xref target="RFC8697" format="default"/>, LSPs are associated w
ith other LSPs with which they interact by adding them to a common association g
roup. </t>
<t>An association group based on VN is useful for various optimizations th
at should be applied by considering all the LSPs in the association. This includ
es, but is not limited to, the following:</t>
<dl newline="false" spacing="normal">
<dt>Path Computation:</dt>
<dd>When computing a path for an LSP, it is useful to analyze the
impact of this LSP on the other LSPs belonging to the same VN. The
aim would be to optimize all LSPs belonging to the VN rather than a
single LSP. Also, the optimization criteria (such as minimizing the
load of the most loaded link (MLL) <xref target="RFC5541"
format="default"/>) could be applied for all the LSPs belonging to the
VN identified by the VN association. </dd>
<dt>Path Reoptimization:</dt>
<dd>The PCE would like to use advanced path computation algorithms and
optimization techniques that consider all the LSPs belonging to a VN
and optimize them all together during the path reoptimization. </dd>
</dl>
<t>In this document, we define a new association group called the "VN Asso
ciation Group (VNAG)". This grouping is used to define the association between
a set of LSPs and a VN. </t>
<t> The ASSOCIATION object contains a field to identify the type of associ
ation, and this document defines a new Association Type value of 7 to indicate t
hat the association is a "VN Association". The Association Identifier in the AS
SOCIATION object is the VNAG Identifier and is handled in the same way as the ge
neric Association Identifier defined in <xref target="RFC8697" format="default"/
>. </t>
<t> In this document, "VNAG object" refers to an ASSOCIATION object with
the Association Type set to "VN Association" (7). </t>
<t> Local policies on the PCE define the computational and optimization be
havior for the LSPs in the VN. An LSP <bcp14>MUST NOT</bcp14> belong to more tha
n one VNAG. If an implementation encounters more than one VNAG object in a PCEP
message, it <bcp14>MUST</bcp14> process the first occurrence, and it <bcp14>MUST
</bcp14> ignore the others. </t>
<t> <xref target="RFC8697" format="default"/> specifies the mechanism by w
hich a PCEP speaker can advertise which Association Types it supports. This is
done using the ASSOC-Type-List TLV carried within an OPEN object. A PCEP speake
r <bcp14>MUST</bcp14> include the VN Association Type (7) in the ASSOC-Type-List
TLV before using the VNAG object in a PCEP message. As per <xref target="RFC869
7" format="default"/>, if the implementation does not support the VN Association
Type, it will return a PCErr message with Error-Type=26 (Association Error) and
Error-value=1 (Association Type is not supported). </t>
<section title="Operation Overview" anchor="sect-3"> <t> The Association Identifiers (VNAG IDs) for this Association Type are d
<t>As per <xref target="RFC8697"/>, LSPs are associated with other LSPs with ynamic in nature and created by the parent PCE (MDSC) based on the VN operations
which they interact by adding them to a common association group. </t> for the LSPs belonging to the same VN. Operator configuration of VNAG IDs is n
ot supported, so there is no need for an Operator-configured Association Range t
<t>An association group based on VN is useful for various optimizations that o be set. Thus, the VN Association Type (7) <bcp14>MUST NOT</bcp14> be present
should be applied by considering all the LSPs in the association. This includes in the Operator-configured Association Range TLV if that TLV is present in the O
, but is not limited to - </t> PEN object. If an implementation encounters the VN Association Type (7) in an O
<t> <list style="symbols"> perator-configured Association Range TLV, it <bcp14>MUST</bcp14> ignore the asso
<t> Path Computation: When computing a path for an LSP, it is useful to ciated Start-Assoc-ID and Range values.
analyze the impact of this LSP on the other LSPs belonging to the same VN. The </t>
aim would be to optimize all LSPs belonging to the VN rather than a single LSP. <t>This association is useful in a PCEP session between a parent PCE (MDSC
Also, the optimization criteria (such as minimizing the load of the most loaded ) and a child PCE (PNC). When computing the path, the child PCE (PNC) refers to
link (MLL) <xref target="RFC5541"/>) could be applied for all the LSPs belongin the VN association in the request from the parent PCE (MDSC) and maps the VN to
g to the VN identified by the VN association. </t> the associated LSPs and network resources. From the perspective of the parent PC
<t> Path Re-Optimization: The PCE would like to use advanced path comput E, it receives a VN creation request from its customer, with the VN uniquely ide
ation algorithms and optimization techniques that consider all the LSPs belongin ntified by the association parameters (<xref target="RFC8697" sectionFormat="of"
g to a VN, and optimize them all together during the path re-optimization. </t> section="6.1.4"/>) in the VNAG or the Virtual Network Identifier encoded in the
</list> VIRTUAL-NETWORK-TLV. This VN may comprise multiple LSPs in the network in a sin
</t> gle domain or across multiple domains. The parent PCE sends a PCInitiate messag
<t>In this document we define a new association group called the VN Associat e with this association information in the VNAG object. This in effect binds an
ion Group (VNAG). This grouping is used to define the association between a set LSP that is to be instantiated at the child PCE with the VN. The VN association
of LSPs and a virtual network. </t> information <bcp14>MUST</bcp14> be included as a part of the first PCRpt messag
<t> The Association Object contains a field to identify the type of associat e. <xref target="vn-operations"/> shows an example of a typical VN operation usi
ion, and this document defines a new Association Type value of TBD1 to indicate ng PCEP. It is worth noting that in a multi-domain scenario, the different doma
that the association is a "VN Association". The Association Identifier in the A ins are controlled by different child PCEs. In order to set up the cross-domain
ssociation Object is the VNAG Identifier and is handled in the same way as the g tunnel, multiple segments need to be stitched by the border nodes in each domain
eneric association identifier defined in <xref target="RFC8697"/>. </t> that receive the instruction from their child PCE (PNC).
<t> In this document, "VNAG object" refers to an Association Object with th </t>
e Association type set to "VN Association". </t>
<t> Local polices on the PCE define the computational and optimization behav
ior for the LSPs in the VN. An LSP MUST NOT belong to more than one VNAG. If an
implementation encounters more than one VNAG object in a PCEP message, it MUST p
rocess the first occurrence and it MUST ignore the others. </t>
<t> <xref target="RFC8697"/> specifies the mechanism by which a PCEP speaker
can advertise which association types it supports. This is done using the ASSO
C-Type-List TLV carried within an OPEN object. A PCEP speaker MUST include the
VN Association Type (TBD1) in the ASSOC-Type-List TLV before using the VNAG obje
ct in a PCEP message. As per <xref target="RFC8697"/>, if the implementation doe
s not support the VN Association Type, it will return a PCErr message with Error
-Type 26 "Association Error" and Error-value 1 "Association Type is not supporte
d". </t>
<t> The Association IDs (VNAG IDs) for this Association Type are dynamic in
nature (and created by the Parent PCE (MDSC) based on the VN operations for the
LSPs belonging to the same VN). Operator configuration of VNAG IDs is not suppo
rted, so there is no need for an Operator-Configured Association Range to be set
. Thus, the VN Association Type (TBD1) MUST NOT be present in the Operator-Conf
igured Association Range TLV if that TLV is present in the OPEN object. If an i
mplementation encounters the VN Association Type (TBD1) in an Operator-Configure
d Association Range TLV, it MUST ignore the associated Start-Assoc-ID and Range
values.
</t>
<t>This association is useful in a PCEP session between a parent PCE (MDSC)
and a child PCE (PNC). When computing the path, the child PCE (PNC) refers to th
e VN association in the request from the parent PCE (MDSC) and maps the VN to th
e associated LSPs and network resources. From the perspective of the Parent PCE,
it receives a virtual network creation request by its customer, with the VN uni
quely identified by the Association parameters (section 6.1.4 of <xref target="R
FC8697"/>) in the VNAG or the Virtual Network identifier encoded in the VIRTUAL-
NETWORK-TLV. This VN may comprise multiple LSPs in the network in a single domai
n or across multiple domains. The Parent PCE sends a PCInitiate Message with th
is association information in the VNAG Object. This in effect binds an LSP that
is to be instantiated at the child PCE with the VN. The VN association informat
ion MUST be included as a part of the first PCRpt message. Figure 1 shows an ex
ample of a typical VN operation using PCEP. It is worth noting that in a multi-
domain scenario, the different domains are controlled by different child PCEs. I
n order to set up the cross-domain tunnel, multiple segments need to be stitched
, by the border nodes in each domain who receive the instruction from their chil
d PCE (PNC).
</t>
<figure><artwork><![CDATA[
******
..........*MDSC*..............................
. ****** .. MPI .
. . . PCEP .
. . . PCInitiate LSPx .
. . . with VNAG .
. . . .
. . . .
. . . .
v v v .
****** ****** ****** .
*PNC1* *PNC2* *PNC4* .
****** ****** ****** .
+---------------+ +---------------+ +---------------+ .
| |----| |----| C| .
| | | | | | .
|DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
+---------------+ +---------------+ +---------------+ .
/ .
****** / .
*PNC3*<............/......................
****** /
+---------------+/
| |
| |
|DOMAIN 3 |
+---------------+
MDSC -> Parent PCE
PNC -> Child PCE
MPI -> PCEP
Figure 1: Example of VN operations in H-PCE Architecture <figure anchor="vn-operations">
]]></artwork> <name>Example of VN Operations in H-PCE (Hierarchical PCE) Architecture</
</figure> name>
<t>Whenever changes occur with the instantiated LSP in a domain network, the <artwork name="" type="" align="left" alt=""><![CDATA[
domain child PCE reports the changes using a PCRpt Message in which the VNAG Ob ******
ject indicates the relationship between the LSP and the VN. </t> ..........*MDSC*..............................
<t>Whenever an update occurs with VNs in the Parent PCE (due to the customer . ****** .. MPI .
's request), the parent PCE sends an PCUpd Message to inform each affected child . . . .
PCE of this change. </t> . . . PCInitiate LSPx .
</section> . . . with VNAG .
. . . .
. . . .
. . . .
v v v .
****** ****** ****** .
*PNC1* *PNC2* *PNC4* .
****** ****** ****** .
+---------------+ +---------------+ +---------------+ .
| |----| |----| C| .
| | | | | | .
|DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
+---------------+ +---------------+ +---------------+ .
/ .
****** / .
*PNC3*<............/......................
****** /
+---------------+/
| |
| |
|DOMAIN 3 |
+---------------+
<section title="Extensions to PCEP" anchor="sect-4"> MDSC -> parent PCE
<t>The format of VNAG is as per the ASSOCIATION object <xref target="RFC8697 PNC -> child PCE
"/>. </t> MPI -> PCEP
<t> This document defines one new mandatory TLV "VIRTUAL-NETWORK-TLV". Optio
nally, the new TLV can be jointly used with the existing "VENDOR-INFORMATION-TLV
" specified in <xref target="RFC7470"/> as described below: </t>
<t><list style="symbols">
<t>VIRTUAL-NETWORK-TLV: Used to communicate the Virtual Network Identifie
r.</t>
<t>VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor specific
behavioral information, described in <xref target="RFC7470"/>.</t>
</list>
</t>
<t>The format of VIRTUAL-NETWORK-TLV is as follows. </t>
<figure><artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD2 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Virtual Network Identifier //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The VIRTUAL-NETWORK-TLV formats
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Type (16-bits): TBD2 (to be allocated by IANA) </t> <t>Whenever changes occur with the instantiated LSP in a domain network, t
<t>Length (16-bits): indicates the length of the value portion of the TLV i he domain child PCE reports the changes using a PCRpt message in which the VNAG
n octets and MUST be greater than 0. The TLV MUST be zero-padded so that the TLV object indicates the relationship between the LSP and the VN. </t>
is 4-octet aligned. </t> <t>Whenever an update occurs with VNs in the parent PCE (due to the custom
<t>Virtual Network Identifier (variable): a symbolic name for the VN that un er's request), the parent PCE sends a PCUpd message to inform each affected chil
iquely identifies the VN. It SHOULD be a string of printable ASCII <xref target= d PCE of this change. </t>
"RFC0020"/> characters (i.e., 0x20 to 0x7E), without a NULL terminator. The Virt
ual Network Identifier is a human-readable string that identifies a VN, it can b
e specified with the association information which may be conveyed in a VENDOR-I
NFORMATION-TLV. An implementation uses the Virtual Network Identifier to maintai
n a mapping to the VN association group and the LSPs associated with the VN. The
Virtual Network Identifier MAY be specified by the customer or set via an opera
tor policy or auto-generated by the PCEP speaker. </t>
<t>The VIRTUAL-NETWORK-TLV MUST be included in VNAG object. If a PCEP speak
er receives the VNAG object without the VIRTUAL-NETWORK-TLV, it MUST send a PCEr
r message with Error-Type=6 (mandatory object missing) and Error-Value=TBD3 (VIR
TUAL-NETWORK-TLV missing) and close the session. </t>
<t>The format of VENDOR-INFORMATION-TLV is defined in <xref target="RFC7470"
/>. </t>
<t>If a PCEP speaker receives a VN ASSOCIATION object with a TLV that violat
es the rules specified in this document, the PCEP speaker MUST send a PCErr mess
age with Error-Type = 10 (Reception of an invalid object) and Error-value = 11 (
Malformed object) and MUST close the PCEP session. </t>
</section>
<section title="Implementation Status" anchor="sect-5">
<t> [Note to the RFC Editor - remove this section before publication, as w
ell as remove the reference to RFC 7942.] </t>
<t> This section records the status of known implementations of the proto
col defined by this specification at the time of posting of this Internet-Draft,
and is based on a proposal described in <xref target="RFC7942"/>. The descript
ion of implementations in this section is intended to assist the IETF in its dec
ision processes in progressing drafts to RFCs. Please note that the listing of
any individual implementation here does not imply endorsement by the IETF. Furth
ermore, no effort has been spent to verify the information presented here that w
as supplied by IETF contributors. This is not intended as, and must not be cons
trued to be, a catalog of available
implementations or their features. Readers are advised to note that other im
plementations may exist. </t>
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and
working groups to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. It is up t
o the individual working groups to use this information as they see fit". </t>
<section title="Huawei's Proof of Concept based on ONOS" anchor="sect-6.1">
<t>The PCE function was developed in the ONOS open source platform. This ext
ension was implemented on a private version as a proof of concept to ACTN. </t
>
<t>
<list style="symbols">
<t>Organization: Huawei</t>
<t>Implementation: Huawei's PoC based on ONOS</t>
<t>Description: PCEP as a southbound plugin was added to ONOS. To
support ACTN, this extension in PCEP is used. Refer
https://wiki.onosproject.org/display/ONOS/PCEP+Protocol</t>
<t>Maturity Level: Prototype</t>
<t>Coverage: Full</t>
<t>Contact: satishk@huawei.com</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations" anchor="sect-6">
<t> The security considerations described in <xref target="RFC5440"/>, <xr
ef target="RFC8231"/> and <xref target="RFC8281"/> apply to the extensions defin
ed in this document as well.</t>
<t>One new Association Type (VN Association) for the ASSOCIATION object is i
ntroduced in this document. Additional security
considerations related to LSP associations due to a malicious PCEP speaker ar
e described in <xref target="RFC8697"/> and apply to the VN Association type. H
ence, securing the PCEP session using Transport Layer Security (TLS) <xref targe
t="RFC8253"/> is RECOMMENDED.</t>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
<name>Extensions to PCEP</name>
<section title="IANA Considerations" anchor="sect-7"> <t>The VNAG uses the generic ASSOCIATION object <xref target="RFC8697" for
<section title="Association Object Type Indicator" anchor="sect-7.1"> mat="default"/>. </t>
<t>IANA is requested to make the assignment of a new value in the sub-regist <t> This document defines one new mandatory TLV called the "VIRTUAL-NETWOR
ry "ASSOCIATION Type Field" within the "Path Computation Element Protocol (PCEP) K-TLV". Optionally, the new TLV can be jointly used with the existing VENDOR-INF
Numbers" registry, as follows: </t> ORMATION-TLV specified in <xref target="RFC7470" format="default"/> as describe
<figure><artwork><![CDATA[ d below: </t>
Value Name Reference <dl newline="false" spacing="normal">
<dt>VIRTUAL-NETWORK-TLV:</dt>
TBD1 VN Association Type [This I.D.] <dd>Used to communicate the Virtual Network Identifier.</dd>
]]></artwork> <dt>VENDOR-INFORMATION-TLV:</dt>
</figure> <dd>Used to communicate arbitrary vendor-specific behavioral
</section> information, as described in <xref target="RFC7470"
<section title="PCEP TLV Type Indicator" anchor="sect-7.2"> format="default"/>.</dd>
<t> IANA is requested to make the assignment of a new value for the existing </dl>
"PCEP TLV Type Indicators" sub-registry within the "Path <t>The format of the VIRTUAL-NETWORK-TLV is as follows. </t>
Computation Element Protocol (PCEP) Numbers" registry, as follows:
</t>
<figure><artwork><![CDATA[
Value Name Reference
TBD2 VIRTUAL-NETWORK-TLV [This I.D.] <figure anchor="vn-tlv-formats">
<name>Format of the VIRTUAL-NETWORK-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=65 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Virtual Network Identifier //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section>
<section title="PCEP Error" anchor="sect-7.3">
<t> IANA is requested to allocate new error value within the "PCEP-ERROR Obj
ect Error Types and Values" sub-registry within the "Path
Computation Element Protocol (PCEP) Numbers" registry, as follows:
</t>
<figure><artwork><![CDATA[
Error-Type Meaning
6 Mandatory Object missing <dl newline="false" spacing="normal">
Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This <dt>Type (16 bits):</dt>
I.D.] <dd>65</dd>
]]></artwork> <dt>Length (16 bits):</dt>
</figure> <dd>Indicates the length of the value portion of the TLV in octets and
<bcp14>MUST</bcp14> be greater than 0. The TLV <bcp14>MUST</bcp14> be
zero-padded so that the TLV is 4-octet aligned.</dd>
<dt>Virtual Network Identifier (variable):</dt>
<dd>A symbolic name for the VN that uniquely identifies the VN. It
<bcp14>SHOULD</bcp14> be a string of printable ASCII <xref target="RFC0020"
format="default"/> characters (i.e., 0x20 to 0x7E), without a NULL
terminator. The Virtual Network Identifier is a human-readable string that
identifies a VN. It can be specified with the association information, which
may be conveyed in a VENDOR-INFORMATION-TLV. An implementation uses the
Virtual Network Identifier to maintain a mapping to the VNAG
and the LSPs associated with the VN. The Virtual Network Identifier
<bcp14>MAY</bcp14> be specified by the customer, set via an operator
policy, or auto-generated by the PCEP speaker.</dd></dl>
<t>The VIRTUAL-NETWORK-TLV <bcp14>MUST</bcp14> be included in VNAG object.
If a PCEP speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
<bcp14>MUST</bcp14> send a PCErr message with Error-Type=6 (Mandatory Object mi
ssing) and Error-value=18 (VIRTUAL-NETWORK-TLV missing) and close the session.
</t>
<t>The format of VENDOR-INFORMATION-TLV is defined in <xref target="RFC747
0" format="default"/>. </t>
<t>If a PCEP speaker receives a VNAG object with a TLV that violates the r
ules specified in this document, the PCEP speaker <bcp14>MUST</bcp14> send a PCE
rr message with Error-Type=10 (Reception of an invalid object) and Error-value=1
1 (Malformed object) and <bcp14>MUST</bcp14> close the PCEP session. </t>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security considerations described in <xref target="RFC5440"
format="default"/>, <xref target="RFC8231" format="default"/>, and <xref
target="RFC8281" format="default"/> apply to the extensions defined in
this document as well.</t>
<t>This document introduces the VN Association Type (7) for the ASSOCIATIO
N object. Additional security
considerations related to LSP associations due to a malicious PCEP speaker ar
e described in <xref target="RFC8697" format="default"/> and apply to the VN Ass
ociation Type. Hence, securing the PCEP session using Transport Layer Security
(TLS) <xref target="RFC8253" format="default"/> is <bcp14>RECOMMENDED</bcp14>.</
t>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default">
<section title="Manageability Considerations" anchor="sect-8"> <name>IANA Considerations</name>
<section title="Control of Function and Policy" anchor="sect-8.1"> <section anchor="sect-7.1" numbered="true" toc="default">
<t>An operator MUST be allowed to mark LSPs that belong to the same VN. This <name>ASSOCIATION Object Type Indicator</name>
could also be done automatically based on the VN configuration. <t>IANA has assigned the following new value in the "ASSOCIATION Type Fi
</t> eld" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" r
egistry: </t>
<table align="left">
<name></name>
<thead>
<tr>
<th>Value</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>7</td>
<td>VN Association</td>
<td>RFC 9358</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-7.2" numbered="true" toc="default">
<name>PCEP TLV Type Indicator</name>
<t>IANA has assigned the following new value in the "PCEP TLV Type Indic
ators" subregistry within the "Path
Computation Element Protocol (PCEP) Numbers" registry:
</t>
<table align="left">
<name></name>
<thead>
<tr>
<th>Value</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>65</td>
<td>VIRTUAL-NETWORK-TLV</td>
<td>RFC 9358</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-7.3" numbered="true" toc="default">
<name>PCEP Error</name>
<t> IANA has allocated the following new error value in the "PCEP-ERROR
Object Error Types and Values" subregistry within the "Path
Computation Element Protocol (PCEP) Numbers" registry:
</t>
<table align="left">
<name></name>
<thead>
<tr>
<th>Error-Type</th>
<th>Meaning</th>
<th>Error-value</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>6</td>
<td>Mandatory Object missing</td>
<td>18: VIRTUAL-NETWORK-TLV missing</td>
<td>RFC 9358</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
<section title="Information and Data Models" anchor="sect-8.2"> <section anchor="sect-8" numbered="true" toc="default">
<t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang"/> should suppo <name>Manageability Considerations</name>
rt the association between LSPs including VN association. <section anchor="sect-8.1" numbered="true" toc="default">
</t> <name>Control of Function and Policy</name>
<t>An operator <bcp14>MUST</bcp14> be allowed to mark LSPs that belong t
o the same VN. This could also be done automatically based on the VN configurati
on.
</t>
</section>
<section anchor="sect-8.2" numbered="true" toc="default">
<name>Information and Data Models</name>
<t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang" format="de
fault"/> should support the association between LSPs including VN association.
</t>
</section>
<section anchor="sect-8.3" numbered="true" toc="default">
<name>Liveness Detection and Monitoring</name>
<t> Mechanisms defined in this document do not imply any new liveness de
tection and monitoring requirements in addition to those already listed in <xref
target="RFC5440" format="default"/>.
</t>
</section>
<section anchor="sect-8.4" numbered="true" toc="default">
<name>Verification of Correct Operations</name>
<t>Mechanisms defined in this document do not imply any new operation ve
rification requirements in addition to those already listed in <xref target="RFC
5440" format="default"/>.
</t>
</section>
<section anchor="sect-8.5" numbered="true" toc="default">
<name>Requirements on Other Protocols</name>
<t>Mechanisms defined in this document do not imply any new requirements
on other protocols.
</t>
</section>
<section anchor="sect-8.6" numbered="true" toc="default">
<name>Impact on Network Operations</name>
<t><xref target="RFC8637" format="default"/> describes the network opera
tions when PCE is used for VN operations. <xref target="sect-3" format="default"
/> further specifies the operations when VN associations are used.</t>
</section>
</section> </section>
<section title="Liveness Detection and Monitoring" anchor="sect-8.3"> </middle>
<t> Mechanisms defined in this document do not imply any new liveness detect <back>
ion and monitoring requirements in addition to those already listed in <xref tar
get="RFC5440"/>.
</t>
</section> <displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
<section title="Verify Correct Operations" anchor="sect-8.4">
<t>Mechanisms defined in this document do not imply any new operation verifi
cation requirements in addition to those already listed in <xref target="RFC5440
"/>.
</t>
</section> <references>
<section title="Requirements On Other Protocols" anchor="sect-8.5"> <name>References</name>
<t>Mechanisms defined in this document do not imply any new requirements on <references>
other protocols.
</t>
</section> <name>Normative References</name>
<section title="Impact On Network Operations" anchor="sect-8.6"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
<t><xref target="RFC8637"/> describe the network operations when PCE is used 020.xml"/>
for VN operations. <xref target="sect-3"/> further specifies the operations whe <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
n VN associations are used.</t> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
253.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
281.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
697.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
655.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
805.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
453.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
637.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
541.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
470.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
051.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
751.xml"/>
</section> <!-- [I-D.ietf-pce-pcep-yang] IESG state I-D Exists -->
</section>
</middle> <reference anchor="I-D.ietf-pce-pcep-yang">
<front>
<title>A YANG Data Model for Path Computation Element Communications Protoco
l (PCEP)</title>
<author initials="D." surname="Dhody" fullname="Dhruv Dhody" role="editor">
<organization>Huawei Technologies</organization>
</author>
<author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram">
<organization>Juniper Networks</organization>
</author>
<author initials="J." surname="Hardwick" fullname="Jonathan Hardwick">
<organization></organization>
</author>
<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
<organization>Microsoft</organization>
</author>
<date month="October" day="23" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-20"/>
</reference>
<back> </references>
<references title="Normative References">
&RFC0020;
&RFC2119;
&RFC5440;
&RFC8174;
&RFC8231;
&RFC8253;
&RFC8281;
&RFC8697;
</references>
<references title="Informative References">
&RFC4655;
&RFC6805;
&RFC7942;
&RFC8453;
&RFC8637;
&RFC5541;
&RFC7470;
&RFC8051;
&RFC8751;
<?rfc include="reference.I-D.ietf-pce-pcep-yang"?>
</references> </references>
<section title="Contributors" anchor="sect-10"> <section anchor="sect-10" numbered="false" toc="default">
<figure><artwork><![CDATA[ <name>Contributors</name>
Dhruv Dhody <contact fullname="Dhruv Dhody">
Huawei Technologies <organization>Huawei Technologies</organization>
Divyashree Technopark, Whitefield <address>
Bangalore, Karnataka 560066 <postal>
India <street>Divyashree Technopark, Whitefield</street>
Email: dhruv.ietf@gmail.com <city>Bangalore</city>
<region>Karnataka</region><code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</contact>
Qin Wu <contact fullname="Qin Wu">
Huawei Technologies <organization>Huawei Technologies</organization>
China <address>
Email: bill.wu@huawei.com <postal>
<street></street>
<city></city>
<region></region>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</contact>
Xian Zhang <contact fullname="Xian Zhang">
Huawei Technologies <organization>Huawei Technologies</organization>
China <address>
Email: zhang.xian@huawei.com <postal>
<street></street>
<city></city>
<region></region>
<country>China</country>
</postal>
<email>zhang.xian@huawei.com</email>
</address>
</contact>
Adrian Farrel <contact fullname="Adrian Farrel">
Old Dog Consulting <organization>Old Dog Consulting</organization>
Email: adrian@olddog.co.uk <address>
]]></artwork> <postal>
</figure> <street></street>
</section> <city></city>
<region></region>
<country></country>
</postal>
<email>adrian@olddog.co.uk</email>
</address>
</contact>
</back> </section>
</back>
</rfc> </rfc>
 End of changes. 40 change blocks. 
481 lines changed or deleted 541 lines changed or added

This html diff was produced by rfcdiff 1.48.