rfc9689xml2.original.xml   rfc9689.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
C.2119.xml">
<!ENTITY RFC4206 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4206.xml">
<!ENTITY RFC5150 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5150.xml">
<!ENTITY RFC5151 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5151.xml">
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5440.xml">
<!ENTITY RFC5441 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5441.xml">
<!ENTITY RFC5541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5541.xml">
<!ENTITY RFC5376 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5376.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 RFC8281 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8281.xml">
<!ENTITY RFC8283 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8283.xml">
<!ENTITY RFC8355 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8355.xml">
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8402.xml">
<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4364.xml">
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7432.xml">
<!ENTITY RFC3985 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3985.xml">
<!ENTITY RFC7665 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7665.xml">
<!ENTITY RFC8279 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8279.xml">
<!ENTITY RFC8986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8986.xml">
<!ENTITY RFC9168 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9168.xml">
<!ENTITY RFC8821 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8821.xml">
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4655.xml">
<!ENTITY RFC7399 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7399.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8253.xml">
<!ENTITY RFC7491 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7491.xml">
<!ENTITY RFC9256 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9256.xml">
<!ENTITY RFC9012 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9012.xml">
<!ENTITY RFC8300 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8300.xml">
<!ENTITY I-D.chen-pce-bier SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/r
eference.I-D.chen-pce-bier.xml">
<!ENTITY RFC8664 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8664.xml">
<!ENTITY RFC8751 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8751.xml">
<!ENTITY RFC8754 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8754.xml">
<!ENTITY RFC7025 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7025.xml">
<!ENTITY RFC9087 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9087.xml">
<!ENTITY RFC9262 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9262.xml">
<!ENTITY RFC9491 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9491.xml">
<!ENTITY RFC9522 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9522.xml">
<!ENTITY RFC9552 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9552.xml">
<!ENTITY RFC8955 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8955.xml">
<!ENTITY RFC4456 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4456.xml">
<!ENTITY RFC8408 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8408.xml">
<!ENTITY I-D.li-pce-controlled-id-space SYSTEM "https://xml2rfc.ietf.org/public/
rfc/bibxml3/reference.I-D.li-pce-controlled-id-space.xml">
<!ENTITY I-D.ietf-pce-stateful-interdomain SYSTEM "https://xml2rfc.ietf.org/publ
ic/rfc/bibxml3/reference.I-D.ietf-pce-stateful-interdomain.xml">
<!ENTITY RFC9050 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9050.xml">
<!ENTITY I-D.ietf-pce-pcep-extension-pce-controller-sr SYSTEM "https://xml2rfc.i
etf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-extension-pce-controller-
sr.xml">
<!ENTITY I-D.cbrt-pce-stateful-local-protection SYSTEM "https://xml2rfc.ietf.org
/public/rfc/bibxml3/reference.I-D.cbrt-pce-stateful-local-protection.xml">
<!ENTITY I-D.ietf-pce-segment-routing-ipv6 SYSTEM "https://xml2rfc.ietf.org/publ
ic/rfc/bibxml3/reference.I-D.ietf-pce-segment-routing-ipv6.xml">
<!ENTITY I-D.ietf-spring-sr-service-programming SYSTEM "https://xml2rfc.ietf.org
/public/rfc/bibxml3/reference.I-D.ietf-spring-sr-service-programming.xml">
<!ENTITY I-D.ietf-pce-segment-routing-policy-cp SYSTEM "https://xml2rfc.ietf.org
/public/rfc/bibxml3/reference.I-D.ietf-pce-segment-routing-policy-cp.xml">
<!ENTITY I-D.ietf-spring-segment-routing-policy SYSTEM "https://xml2rfc.ietf.org
/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing-policy.xml">
<!ENTITY I-D.ietf-idr-segment-routing-te-policy SYSTEM "https://xml2rfc.ietf.org
/public/rfc/bibxml3/reference.I-D.ietf-idr-segment-routing-te-policy.xml">
<!ENTITY I-D.ietf-pce-binding-label-sid SYSTEM "https://xml2rfc.ietf.org/public
/rfc/bibxml3/reference.I-D.ietf-pce-binding-label-sid.xml">
<!ENTITY I-D.chen-pce-pcep-extension-pce-controller-bier SYSTEM "https://xml2rf
c.ietf.org/public/rfc/bibxml3/reference.I-D.chen-pce-pcep-extension-pce-controll
er-bier.xml">
<!ENTITY I-D.ietf-pce-pcep-extension-native-ip SYSTEM "https://xml2rfc.ietf.org
/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-extension-native-ip.xml">
<!ENTITY I-D.dhody-pce-pcep-extension-pce-controller-srv6 SYSTEM "https://xml2r
fc.ietf.org/public/rfc/bibxml3/reference.I-D.dhody-pce-pcep-extension-pce-contro
ller-srv6.xml">
<!ENTITY I-D.ietf-mpls-seamless-mpls SYSTEM "https://xml2rfc.ietf.org/public/rf
c/bibxml3/reference.I-D.ietf-mpls-seamless-mpls.xml">
<!ENTITY RFC1195 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.1195.xml">
<!ENTITY RFC2328 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2328.xml">
<!ENTITY RFC5340 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5340.xml">
<!ENTITY RFC8735 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8735.xml">
<!ENTITY RFC3209 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3209.xml">
<!ENTITY RFC5036 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5036.xml">
<!ENTITY RFC9262 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.9262.xml">
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<rfc submissionType="IETF" docName="draft-ietf-teas-pcecc-use-cases-18" category
="info" ipr="trust200902"><?rfc compact="yes"?>
<?rfc text-list-symbols="oo*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front>
<title abbrev="PCECC">Use Cases for a PCE as a Central Controller (PCECC)
</title>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
raft-ietf-teas-pcecc-use-cases-18" number="9689" category="info" consensus="true
" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRef
s="true" tocInclude="true" version="3">
<front>
<title abbrev="PCECC">Use Cases for a PCE as a Central Controller (PCECC)</t
itle>
<seriesInfo name="RFC" value="9689"/>
<author fullname="Zhenbin (Robin) Li" initials="Z." surname="Li"> <author fullname="Zhenbin (Robin) Li" initials="Z." surname="Li">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street> <street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<region></region>
<code>100095</code> <code>100095</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>lizhenbin@huawei.com</email> <email>lizhenbin@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <organization>Huawei Technologies</organization>
<organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street></street>
<city></city>
<region></region>
<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 initials="Q" <author initials="Q" surname="Zhao" fullname="Quintin Zhao">
surname="Zhao"
fullname="Quintin Zhao">
<organization>Etheric Networks</organization> <organization>Etheric Networks</organization>
<address> <address>
<postal> <postal>
<street>1009 S CLAREMONT ST</street> <street>1009 S Claremont St.</street>
<city>SAN MATEO</city> <city>San Mateo</city>
<region>CA</region> <region>CA</region>
<code>94402</code> <code>94402</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>qzhao@ethericnetworks.com</email> <email>qzhao@ethericnetworks.com</email>
</address> </address>
</author> </author>
<author fullname="King He" initials="K." surname="He"> <author fullname="King He" initials="K." surname="He">
<organization>Tencent Holdings Ltd.</organization> <organization>Tencent Holdings Ltd.</organization>
<address> <address>
<postal> <postal>
<street></street>
<city>Shenzhen</city> <city>Shenzhen</city>
<region></region>
<country>China</country> <country>China</country>
</postal> </postal>
<email>kinghe@tencent.com</email> <email>kinghe@tencent.com</email>
</address> </address>
</author> </author>
<author fullname="Boris Khasanov" initials="B." surname="Khasanov"> <author fullname="Boris Khasanov" initials="B." surname="Khasanov">
<organization>Yandex LLC</organization> <organization>Yandex LLC</organization>
<address> <address>
<postal> <postal>
<street>Ulitsa Lva Tolstogo 16</street> <street>Ulitsa Lva Tolstogo 16</street>
<city>Moscow</city> <city>Moscow</city>
<region></region> <country>Russian Federation</country>
<code></code>
<country>Russia</country>
</postal> </postal>
<email>bhassanov@yahoo.com</email> <email>bhassanov@yahoo.com</email>
</address> </address>
</author> </author>
<!--<author fullname="Luyuan Fang" initials="L." surname="Fang">
<organization>Expedia, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<country>USA</country>
</postal>
<email>luyuanf@gmail.com</email>
</address>
</author>
<author initials="C"
surname="Zhou"
fullname="Chao Zhou">
<organization>HPE</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>chaozhou_us@yahoo.com</email>
</address>
</author>
<author fullname="Boris Zhang" initials="B." surname="Zhang">
<organization>Telus Communications</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<country></country>
</postal>
<email>Boris.zhang@telus.com</email>
</address>
</author>
<author fullname="Artem Rachitskiy" initials="A." surname="Rachitskiy">
<organization>Mobile TeleSystems JLLC</organization>
<address>
<postal>
<street>Nezavisimosti ave., 95</street>
<city>Minsk</city>
<code>220043</code>
<region></region>
<country>Belarus</country>
</postal>
<email>arachitskiy@mts.by</email>
</address>
</author>
<author fullname="Anton Gulida" initials="A." surname="Gulida">
<organization>LLC "Lifetech"</organization>
<address>
<postal>
<street>Krasnoarmeyskaya str., 24</street>
<city>Minsk</city>
<code>220030</code>
<region></region>
<country>Belarus</country>
</postal>
<email>anton.gulida@life.com.by</email>
</address>
</author> -->
<date/>
<workgroup>TEAS Working Group</workgroup>
<abstract>
<t>The PCE is a core component of
a Software-Defined Networking (SDN) system. It can be used to compute optima
l paths for network traffic and update existing paths to reflect
changes in the network or traffic demands. PCE was developed to
derive traffic-engineered paths in MPLS networks,
which are supplied to the head end of the paths using the Path
Computation Element Communication Protocol (PCEP).</t>
<t>SDN has much broader applicability than signaled MPLS traffic-engineered
(TE) networks, and the PCE may be used to determine paths in a range
of use cases including static LSPs, Segment Routing (SR), Service Function
Chaining (SFC), and most forms of a routed or switched network. It
is, therefore, reasonable to consider PCEP as a control protocol for
use in these environments to allow the PCE to be fully enabled as a
central controller.</t>
<t>A PCE as a Central Controller (PCECC) can simplify the processing of
a distributed control plane by blending it with elements of SDN
without necessarily completely replacing it. This document describes
general considerations for PCECC deployment and examines its
applicability and benefits, as well as its challenges and
limitations, through a number of use cases.
PCEP extensions which are required for the PCECC use cases are
covered in separate documents.</t>
<!--<t>This is a living document to catalog the use cases for PCECC. There is <date month="November" year="2024"/>
currently no intention to publish this work as an RFC. [Update: Chairs are eval <area>RTG</area>
uating if the document should be published instead.]</t>--> <workgroup>teas</workgroup>
<keyword>SDN</keyword>
</abstract>
<!--<note title="Requirements Language">
<t> <abstract>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The PCE is a core component of a Software-Defined Networking (SDN)
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and system. It can be used to compute optimal paths for network traffic and
"OPTIONAL" in this document are to be interpreted as described in BCP update existing paths to reflect changes in the network or traffic
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the demands. The PCE was developed to derive Traffic Engineering (TE) paths in
y appear in all MPLS
capitals, as shown here.</t> networks, which are supplied to the headend of the paths using the Path
</note>--> Computation Element Communication Protocol (PCEP).</t>
<t>SDN has much broader applicability than signalled MPLS
TE networks, and the PCE may be used to determine
paths in a range of use cases including static Label-Switched Paths (LSPs)
, Segment Routing
(SR), Service Function Chaining (SFC), and most forms of a routed or
switched network. Therefore, it is reasonable to consider PCEP as a
control protocol for use in these environments to allow the PCE to be
fully enabled as a central controller.</t>
<t>A PCE as a Central Controller (PCECC) can simplify the processing of
a distributed control plane by blending it with elements of SDN without
necessarily completely replacing it. This document describes general
considerations for PCECC deployment and examines its applicability and
benefits, as well as its challenges and limitations, through a number of
use cases. PCEP extensions, which are required for the PCECC use cases,
are covered in separate documents.</t>
</abstract>
</front> </front>
<middle>
<middle> <section anchor="sect-1" numbered="true" toc="default">
<section title="Introduction" anchor="sect-1"> <name>Introduction</name>
<t>The PCE <xref target="RFC4655"/> was developed to offload <t>The PCE <xref target="RFC4655" format="default"/> was developed to offl
the path computation function from routers in an MPLS traffic-engineered (TE) oad
network. It can compute optimal paths for traffic the path computation function from routers in an MPLS Traffic Engineering (TE
) network. It can compute optimal paths for traffic
across a network and can also update the paths to reflect changes in across a network and can also update the paths to reflect changes in
the network or traffic demands. The role and function of the network or traffic demands. The role and function of
PCE have grown to cover several other uses (such as GMPLS the PCE have grown to cover several other uses (such as GMPLS
<xref target="RFC7025"/> or Multicast), <xref target="RFC7025" format="default"/> or Multicast)
and to allow delegated stateful control <xref target="RFC8231"/> and PCE-init and to allow delegated stateful control <xref target="RFC8231" format="defaul
iated t"/> and PCE-initiated
use of network resources <xref target="RFC8281"/>.</t> use of network resources <xref target="RFC8281" format="default"/>.</t>
<t>According to <xref target="RFC7399" format="default"/>, Software-Define
<t>According to <xref target="RFC7399"/>, Software-Defined Networking (SDN) r d Networking (SDN) refers to a
efers to a
separation between the control elements and the forwarding components separation between the control elements and the forwarding components
so that software running in a centralized system, called a so that software running in a centralized system, called a
controller, can act to program the devices in the network to behave "controller", can act to program the devices in the network to behave
in specific ways. A required element in an SDN architecture is a in specific ways. A required element in an SDN architecture is a
component that plans how the network resources will be used and how component that plans how the network resources will be used and how
the devices will be programmed. It is possible to view this the devices will be programmed. It is possible to view this
component as performing specific computations to place traffic flows component as performing specific computations to place traffic flows
within the network given knowledge of the availability of the network within the network given knowledge of the availability of the network
resources, how other forwarding devices are programmed, and the way resources, how other forwarding devices are programmed, and the way
that other flows are routed. This is the function and purpose of a that other flows are routed. This is the function and purpose of a
PCE, and the way that a PCE integrates into a wider network control PCE, and the way that a PCE integrates into a wider network control
system (including an SDN system) is presented in <xref target="RFC7491"/>.</t system (including an SDN system) is presented in <xref target="RFC7491" fo
> rmat="default"/>.</t>
<t><xref target="RFC8283" format="default"/> outlines the architecture for
<t><xref target="RFC8283"/> introduces the architecture for the PCE as a central the PCE as a central
controller as an extension to the architecture described in <xref target="RFC controller, extending the framework described in <xref target="RFC4655" forma
4655"/> t="default"/>,
and assumes the continued use of PCEP as the protocol used between and demonstrates how PCEP can serve as a general southbound control protocol
the PCE and PCC. <xref target="RFC8283"/> further examines the motivations a between the PCE
nd and Path Computation Client (PCC). <xref target="RFC8283" format="default"/> fur
ther examines the motivations and
applicability of PCEP as a Southbound Interface (SBI) and introduces applicability of PCEP as a Southbound Interface (SBI) and introduces
the implications for the protocol. </t> the implications for the protocol. </t>
<t><xref target="RFC9050" format="default"/> introduces the procedures and
<!--<t> extensions for PCEP to support the PCECC architecture <xref target="RFC8283"
An Architecture for Use of PCE and PCEP <xref target="RFC5440"/> in a Networ format="default"/>.</t>
k with Central <t>
Control <xref target="RFC8283"/> describes a
SDN architecture where the Path Computation Element (PCE) determines
the paths for variety of different usecases, with PCEP as a general southboun
d
communication protocol with all the nodes along the path.</t>-->
<t><xref target="RFC9050"/> introduces the procedures and
extensions for PCEP to support the PCECC architecture <xref target="RFC8283"/
>.</t>
<t>
This document describes the various use cases for the PCECC architecture.</t> This document describes the various use cases for the PCECC architecture.</t>
<!--<t>This is a living document to catalog the use cases for PCECC. There i
s currently no intention to publish this work as an RFC. [Update: Chairs are eva
luating if the document should be published instead.]</t>-->
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Terminology</name>
<t>
The following terminology is used in this document.
</t>
<dl newline="false" spacing="normal" indent="0">
<dt>AS:</dt> <dd>Autonomous System</dd>
<dt>ASBR:</dt> <dd>Autonomous System Border Router</dd>
<dt>BGP-LS:</dt>
<dd>Border Gateway Protocol - Link State <xref target="RFC9552" format="
default"/></dd>
<dt>IGP:</dt>
<dd>Interior Gateway Protocol (in this document, we assume IGP as either
Open Shortest Path First (OSPF) <xref target="RFC2328" format="default"/> <xref
target="RFC5340" format="default"/> or
Intermediate System to Intermediate System (IS-IS) <xref target="RFC1195
" format="default"/>)</dd>
<dt>LSP:</dt>
<dd>Label-Switched Path</dd>
<dt>PCC:</dt>
<dd>Path Computation Client (as per <xref target="RFC4655" format="defau
lt"/>, any client application requesting a path
computation to be performed by a PCE)</dd>
<dt>PCE:</dt>
<dd>Path Computation Element (as per <xref target="RFC4655" format="defa
ult"/>, an entity such as a component, application, or network node that is capa
ble of computing a network path or route based on a
network graph and applying computational constraints)</dd>
<dt>PCECC:</dt>
<dd>PCE as a Central Controller (an extension of a PCE to support SDN fu
nctions as per <xref target="RFC8283" format="default"/>)</dd>
<dt>PST:</dt>
<dd>Path Setup Type <xref target="RFC8408" format="default"/></dd>
<dt>RR:</dt>
<dd>Route Reflector <xref target="RFC4456" format="default"/></dd>
<dt>SID:</dt>
<dd>Segment Identifier <xref target="RFC8402" format="default"/></dd>
<dt>SR:</dt>
<dd>Segment Routing <xref target="RFC8402" format="default"/></dd>
<dt>SRGB:</dt>
<dd>Segment Routing Global Block <xref target="RFC8402" format="default"
/></dd>
<dt>SRLB:</dt>
<dd>Segment Routing Local Block <xref target="RFC8402" format="default"/
></dd>
<dt>TE:</dt>
<dd>Traffic Engineering <xref target="RFC9522" format="default"/></dd>
</dl>
</section>
<section numbered="true" toc="default">
<section title="Terminology" anchor="sect-2"> <name>Use Cases</name>
<t> <t><xref target="RFC8283" format="default"/> describes various use cases f
The following terminology is used in this document. or a PCECC such as:
</t>
<list style="hanging" hangIndent="0"> <ul spacing="normal">
<li>
<t hangText="BGP-LS:"> use of a PCECC to set up static TE LSPs (the PCEP extension for this u
Border Gateway Protocol - Link State <xref target="RFC9552"/>. se case is in <xref target="RFC9050" format="default"/>)
</t> </li>
<li>
<t hangText="LSP:"> use of a PCECC in SR <xref target="RFC8402" format="default"/>
Label Switched Path. </li>
</t> <li>
use of a PCECC to set up Multicast Point-to-Multipoint (P2MP) LSPs
<t hangText="IGP:"> </li>
Interior Gateway Protocol. In the document, we assume either Open Shortes <li>
t Path First (OSPF) <xref target="RFC2328"/><xref target="RFC5340"/> or Intermed use of a PCECC to set up Service Function Chaining (SFC) <xref target=
iate System "RFC7665" format="default"/>
to Intermediate System (IS-IS) <xref target="RFC1195"/> as IGP. </li>
</t> <li>
use of a PCECC in optical networks
<t hangText="PCC:"> </li>
Path Computation Client. As per <xref target="RFC4655"/>, any client appl </ul>
ication requesting a <t><xref target="sect-3" format="default"/> describes the general case of
path computation to be performed by a Path Computation Element. a PCECC being in charge of
</t> managing MPLS label space, which is a prerequisite for further use cas
es.
<t hangText="PCE:"> Further, various use cases (SR, Multicast, etc.) are described in the
Path Computation Element. As per <xref target="RFC4655"/>, an entity (com following sections to showcase scenarios that can benefit from the use of a PCEC
ponent, application, C.
or network node) that is capable of computing a network path or </t>
route based on a network graph and applying computational <t>It is interesting to note that some of the use cases listed can also be
constraints. supported via BGP instead of PCEP. However, within the scope of this document,
</t> the focus is on the use of PCEP.</t>
<section anchor="sect-3" numbered="true" toc="default">
<t hangText="PCECC:"> <name>PCECC for Label Management</name>
PCE as a Central Controller. Extension of PCE to support SDN functions as per <t>As per <xref target="RFC8283" format="default"/>, in some cases, the
<xref target="RFC8283"/>. PCECC can take responsibility for
</t>
<t hangText="PST:">
Path Setup Type <xref target="RFC8408"/>.
</t>
<t hangText="RR:">
Route Reflector <xref target='RFC4456'/>.
</t>
<t hangText="SID:">
Segment Identifier <xref target='RFC8402'/>.
</t>
<t hangText="SR:">
Segment Routing <xref target='RFC8402'/>.
</t>
<t hangText="SRGB:">
Segment Routing Global Block <xref target='RFC8402'/>.
</t>
<t hangText="SRLB:">
Segment Routing Local Block <xref target='RFC8402'/>.
</t>
<t hangText="TE:">
Traffic Engineering <xref target='RFC9522'/>.
</t>
</list></t>
</section>
<section title="Use Cases">
<t><xref target="RFC8283"/> describes various use cases for PCECC such as:
<list style="symbols">
<t>Use of PCECC to set up Static TE LSPs. The PCEP extension for this use ca
se is in <xref target="RFC9050"/>.</t>
<t>Use of PCECC in Segment Routing <xref target="RFC8402"/>.</t>
<t>Use of PCECC to set up Multicast Point-to-Multipoint (P2MP) LSP.</t>
<t>Use of PCECC to set up Service Function Chaining (SFC) <xref target="RFC7
665"/>.</t>
<t>Use of PCECC in Optical Networks.</t>
</list>
</t>
<t><xref target="sect-3"/> describes the general case of PCECC being in charge
of
managing MPLS label space which is a prerequisite for further use case
s.
Further, various use cases (SR, Multicast etc) are described in the fo
llowing sections to showcase scenarios that can benefit from the use of PCECC.
</t>
<t>It is interesting to note that some of the use cases listed can also be suppo
rted via BGP instead of PCEP. However, within the scope of this document, the fo
cus is on the use of PCEP.</t>
<section title="PCECC for Label Management" anchor="sect-3">
<t>As per <xref target="RFC8283"/>, in some cases, the PCE-based controller
can take responsibility for
managing some part of the MPLS label space for each of the routers managing some part of the MPLS label space for each of the routers
that it controls, and it may take wider responsibility for that it controls, and it may take wider responsibility for
partitioning the label space for each router and allocating different partitioning the label space for each router and allocating different
parts for different uses, communicating the ranges to the router parts for different uses, communicating the ranges to the router
using PCEP.</t> using PCEP.</t>
<t><xref target="RFC9050" format="default"/> describes a mode where
LSPs are provisioned as explicit label instructions at each hop on the
end-to-end path. Each router along the path must be told what label
forwarding instructions to program and what resources to reserve. The
controller uses PCEP to communicate with each router along the path of
the end-to-end LSP. For this to work, the PCECC will
take responsibility for managing some part of the MPLS label space for
each of the routers that it controls. An extension to PCEP could be
done to allow a PCC to inform the PCE of such a label space to control
(see <xref target="I-D.ietf-pce-controlled-id-space"
format="default"/> for a possible PCEP extension to support the
advertisement of the MPLS label space for the PCE to control).</t>
<t><xref target="RFC9050"/> describes a mode <t><xref target="RFC8664" format="default"/> specifies extensions to PCE
where LSPs are provisioned as explicit label instructions at each hop P that
on the end-to-end path. Each router along the path must be told what allow a stateful PCE to compute, update, or initiate SR-TE paths.
label forwarding instructions to program and what resources to <xref target="I-D.ietf-pce-pcep-extension-pce-controller-sr" format="default"
reserve. The controller uses PCEP to communicate with each router /> describes the
along the path of the end-to-end LSP. For this to work, the mechanism for a PCECC to allocate and provision the node/prefix/
PCE-based controller will take responsibility for managing some part of adjacency label (Segment Routing Identifier (SID)) via PCEP. To make such an
the MPLS label space for each of the routers that it controls. allocation, the PCE needs to
An extension to PCEP could be done to allow a PCC to
inform the PCE of such a label space to control. (See <xref target="I-D.li-pc
e-controlled-id-space"/> for a possible PCEP extension to support
the advertisement of the MPLS label space to the PCE to control.)</t>
<t><xref target="RFC8664"/> specifies extensions to PCEP that
allow a stateful PCE to compute, update or initiate SR-TE paths.
<xref target="I-D.ietf-pce-pcep-extension-pce-controller-sr"/> describes the
mechanism for PCECC to allocate and provision the node/prefix/
adjacency label (Segment Routing Identifier (SID)) via PCEP. To make such an
allocation PCE needs to
be aware of the label space from the Segment Routing Global Block (SRGB) be aware of the label space from the Segment Routing Global Block (SRGB)
or Segment Routing Local Block (SRLB) or Segment Routing Local Block (SRLB)
<xref target="RFC8402"/> of the node that it controls. A <xref target="RFC8402" format="default"/> of the node that it controls. A
mechanism for a PCC to inform the PCE of such a label space to mechanism for a PCC to inform the PCE of such a label space to
control is needed within the PCEP. The full SRGB/SRLB of a node could be control is needed within the PCEP. The full SRGB/SRLB of a node could be
learned via existing IGP or BGP-LS <xref target="RFC9552"/> mechanisms.</t> learned via existing IGP or BGP-LS <xref target="RFC9552" format="default"/>
mechanisms.</t>
<t>Further, there have been proposals for a global label range in MPLS, the P <t>Further, there have been proposals for a global label range in MPLS a
CECC s well as the use of PCECC
architecture could be used as a means to learn the label space of nodes, and architecture to learn the label space of each node to
could also be used to
determine and provision the global label range.</t> determine and provision the global label range.</t>
<figure anchor="fig_label">
<!--<t> <name>PCECC for MPLS Label Management</name>
This use case is based on network configuration illustrated using <artwork name="" type="" align="left" alt=""><![CDATA[
the following figure:</t>-->
<figure title="PCECC for MPLS Label Management" anchor="fig_label"><artwo
rk><![CDATA[
+------------------------------+ +------------------------------+ +------------------------------+ +------------------------------+
| PCE DOMAIN 1 | | PCE DOMAIN 2 | | PCE DOMAIN 1 | | PCE DOMAIN 2 |
| +--------+ | | +--------+ | | +--------+ | | +--------+ |
| | | | | | | | | | | | | | | |
| | PCECC1 | ---------PCEP---------- | PCECC2 | | | | PCECC1 | ---------PCEP---------- | PCECC2 | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| +--------+ | | +--------+ | | +--------+ | | +--------+ |
| ^ ^ | | ^ ^ | | ^ ^ | | ^ ^ |
| / \ PCEP | | PCEP / \ | | / \ PCEP | | PCEP / \ |
| V V | | V V | | V V | | V V |
| +--------+ +--------+ | | +--------+ +--------+ | | +--------+ +--------+ | | +--------+ +--------+ |
| |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| | | | Node11 | | Node1n | | | | Node21 | | Node2n | |
| | | ...... | | | | | | ...... | | | | | | ...... | | | | | | ...... | | |
| | PCECC | | PCECC | | | | PCECC | |PCECC | | | | PCECC | | PCECC | | | | PCECC | |PCECC | |
| |Enabled | | Enabled| | |Enabled | |Enabled | | | |Enabled | | Enabled| | | |Enabled | |Enabled | |
| +--------+ +--------+ | | +--------+ +--------+ | | +--------+ +--------+ | | +--------+ +--------+ |
| | | | | | | |
+------------------------------+ +------------------------------+ +------------------------------+ +------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="symbols"><t>As shown in <xref target="fig_label"/>, PCC w <t>As shown in <xref target="fig_label"/>:</t>
ill advertise the PCECC capability to the PCE central <ul spacing="normal">
controller (PCECC) <xref target="RFC9050"/>.</t> <li>
<t>The PCC
<t>The PCECC could also learn the label range set aside by the PCC (via < will advertise the PCECC capability to the PCECC <xref target="RFC9
xref target="I-D.li-pce-controlled-id-space"/>). </t> 050" format="default"/>.</t>
<t>Optionally, the PCECC could determine the shared MPLS global label range fo </li>
r the network. <li>
<list style="symbols"> <t>The PCECC could also learn the label range set aside by the PCC
<t>In the case that the shared global label range needs to be (via <xref target="I-D.ietf-pce-controlled-id-space"
negotiated across multiple domains, the central controllers of format="default"/>).</t>
these domains will also need to negotiate a common global </li>
label range across domains.</t> <li>
<t>Optionally, the PCECC could determine the shared MPLS global
<t>The PCECC will need to set the shared global label label range for the network.</t>
range to all PCC nodes in the network.</t> <ul spacing="normal">
</list></t> <li>
<t>In the case that the shared global label range needs to be
</list> negotiated across multiple domains, the central controllers of
</t> these domains will also need to negotiate a common global
<t>As per <xref target="RFC9050"/>, PCECC could also rely on the PCC to make l label range across domains.</t>
abel allocations initially and use PCEP to distribute it to where it is needed.< </li>
/t> <li>
<t>The PCECC will need to set the shared global label range to
</section> all PCC nodes in the network.</t>
</li>
</ul>
</li>
</ul>
<section title="PCECC and Segment Routing" anchor="sect-4"> <t>As per <xref target="RFC9050" format="default"/>, the PCECC could als
<t>Segment Routing (SR) <xref target="RFC8402"/> leverages the source routin o
g paradigm. Using rely on the PCC to make label allocations initially and use PCEP to
SR, a source node steers a packet through a path without relying on distribute it to where it is needed.</t>
hop-by-hop signalling protocols such as LDP <xref target="RFC5036"/> or RSVP- </section>
TE <xref target="RFC3209"/>. Each path is
specified as an ordered list of instructions called "segments". Each
segment is an instruction to route the packet to a specific place in
the network, or to perform a specific service on the packet. A
database of segments can be distributed
through the network using a intra-domain routing protocol (such as IS-IS or
OSPF) or an inter-domain protocol (BGP), or by any other means. PCEP could a
lso be one of other protocols.</t>
<t><xref target="RFC8664"/> specifies the <section anchor="sect-4" numbered="true" toc="default">
SR-specific PCEP extension for SR-MPLS. PCECC may further use PCEP protocol <name>PCECC and SR</name>
for SR SIDs (Segment Identifiers)
distribution to the SR nodes (PCC) with some benefits. If the
PCECC allocates and maintains the SIDs in the network for the nodes and adjac
encies;
and further distributes them to the SR nodes directly via the
PCEP session then it is more advantageous over the configurations on
each SR node and flooding them via IGP, especially in an SDN environment. </t
>
<!--<t> <t>SR <xref target="RFC8402" format="default"/>
For the centralized network, the performance achieved through leverages the source routing paradigm. Using SR, a source node steers
distributed system can not be easy matched if all of the forwarding a packet through a path without relying on hop-by-hop signalling
paths are computed, downloaded and maintained by the centralized protocols such as LDP <xref target="RFC5036" format="default"/> or
controller. The performance can be improved by supporting part of RSVP-TE <xref target="RFC3209" format="default"/>. Each path is
the forwarding path in the PCECC network through the segment routing specified as an ordered list of instructions called "segments". Each
mechanism except that node segment IDs and adjacency segment IDs for segment is an instruction to route the packet to a specific place in
all the network are allocated dynamically and propagated through the the network or to perform a specific service on the packet. A
centralized controller instead of using the IGP extensions.</t>--> database of segments can be distributed through the network using an
intra-domain routing protocol (such as IS-IS or OSPF), an inter-domain
protocol (such as BGP), or by any other means. PCEP could also be one
of other protocols.</t>
<t><xref target="RFC8664" format="default"/> specifies the PCEP
extension specific to SR for SR over MPLS (SR-MPLS). The PCECC may furth
er
use the PCEP for distributing SR Segment Identifiers (SIDs)
to the SR nodes (PCC) with some benefits. If the PCECC allocates and
maintains the SIDs in the network for the nodes and adjacencies, and
further distributes them to the SR nodes directly via the PCEP session,
then it is more advantageous over the configurations on each SR node
and flooding them via IGP, especially in an SDN environment. </t>
<t> <t>
When the PCECC is used for the distribution of the Node-SID When the PCECC is used for the distribution of the Node-SID
and Adj-SID for SR-MPLS, the Node-SID is allocated from the and Adj-SID for SR-MPLS, the Node-SID is allocated from the
SRGB of the node. For the allocation of Adj-SID, the SRGB of the node and the
allocation is from the SRLB of the node as described in <xref target="I-D.iet Adj-SID is allocated from the SRLB of the node as described in <xref target="
f-pce-pcep-extension-pce-controller-sr"/>.</t> I-D.ietf-pce-pcep-extension-pce-controller-sr" format="default"/>.</t>
<t><xref target="RFC8355" format="default"/> identifies various protecti
<t><xref target="RFC8355"/> identifies various protection and resiliency on and resiliency use cases for SR.
usecases for SR.
Path protection lets the ingress node be in charge of the failure Path protection lets the ingress node be in charge of the failure
recovery (used for SR-TE <xref target="RFC8664"/>). Also, protection can be recovery (used for SR-TE <xref target="RFC8664" format="default"/>). Also, pr otection can be
performed by the node adjacent to the failed component, commonly performed by the node adjacent to the failed component, commonly
referred to as local protection techniques or fast-reroute (FRR) techniques. referred to as "local protection techniques" or "fast-reroute (FRR) technique
In the case of PCECC, the protection paths can be pre-computed s".
In the case of the PCECC, the protection paths can be precomputed
and set up by the PCE.</t> and set up by the PCE.</t>
<t>
<t> <xref target="fig_sr" format="default"/> illustrates the use case where the N
The <xref target="fig_sr"/> illustrates the use case where the Node-SID and A ode-SID and Adj-SID are allocated by the PCECC for SR-MPLS.</t>
dj-SID are allocated by the PCECC for SR-MPLS.</t> <figure anchor="fig_sr">
<name>SR Topology</name>
<figure title="SR Topology" anchor="fig_sr"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
192.0.2.1/32 192.0.2.1/32
+----------+ +----------+
| R1(1001) | | R1(1001) |
+----------+ +----------+
| |
+----------+ +----------+
| R2(1002) | 192.0.2.2/32 | R2(1002) | 192.0.2.2/32
+----------+ +----------+
* | * * * | * *
* | * * * | * *
skipping to change at line 553 skipping to change at line 360
* | * * + * | * * +
* | * * + * | * * +
+-----------+ +-----------+ +-----------+ +-----------+
192.0.2.3/32 | R3(1003) | |R6(1006) |192.0.2.6/32 192.0.2.3/32 | R3(1003) | |R6(1006) |192.0.2.6/32
+-----------+ +-----------+ +-----------+ +-----------+
| |
+-----------+ +-----------+
| R8(1008) | 192.0.2.8/32 | R8(1008) | 192.0.2.8/32
+-----------+ +-----------+
]]></artwork> ]]></artwork>
</figure> </figure>
<section title="PCECC SID Allocation for SR-MPLS" anchor="sect-4.1" >
<t>Each node (PCC) is allocated a Node-SID by the PCECC. The PCECC <section anchor="sect-4.1" numbered="true" toc="default">
<name>PCECC SID Allocation for SR-MPLS</name>
<t>Each node (PCC) is allocated a Node-SID by the PCECC. The PCECC
needs to update the label mapping of each node to all needs to update the label mapping of each node to all
the other nodes in the domain. After receiving the label mapping, each node (PCC) uses the local the other nodes in the domain. After receiving the label mapping, each node (PCC) uses the local
routing information to determine the nexthop and download the label routing information to determine the next hop and download the label
forwarding instructions accordingly. The forwarding behaviour and the end res forwarding instructions accordingly. The forwarding behavior and the end resu
ult lt
are the same as IGP shortest-path SR forwarding based on Node-SID. Thus, fro are the same as IGP shortest-path SR forwarding based on Node-SIDs. Thus, fr
m anywhere in the domain, it enforces the om anywhere in the domain, it enforces the
ECMP-aware shortest-path forwarding of the packet towards the related ECMP-aware shortest-path forwarding of the packet towards the related
node.</t> node.</t>
<t>The PCECC can allocate an Adj-SID for each adjacency in the network
<t>For each adjacency in the network, a PCECC can allocate an Adj-SID. The PC . The PCECC sends a PCInitiate message to update the label mapping of each adjac
ECC sends a PCInitiate message to update the label mapping of each adjacency to ency to the
the
corresponding nodes in the domain. Each node (PCC) downloads the corresponding nodes in the domain. Each node (PCC) downloads the
label forwarding instructions accordingly. The forwarding behaviour and the e nd result are similar to IGP-based label forwarding instructions accordingly. The forwarding behavior and the en d result are similar to IGP-based
Adj-SID allocation and usage in SR.</t> Adj-SID allocation and usage in SR.</t>
<t>These mechanisms are described in <xref target="I-D.ietf-pce-pcep-e
<t>These mechanisms are described in <xref target="I-D.ietf-pce-pcep-extensio xtension-pce-controller-sr" format="default"/>.</t>
n-pce-controller-sr"/>.</t> </section>
</section> <section anchor="sect-4.2" numbered="true" toc="default">
<section title="PCECC for SR-MPLS Best Effort (BE) Path" anchor="sect-4.2 <name>PCECC for SR-MPLS Best Effort (BE) Paths</name>
"><t> <t>When using PCECC for SR-MPLS Best Effort (BE) Paths, the PCECC need
In this use case, the PCECC needs to allocate the s to
Node-SID (without calculating the explicit allocate the Node-SID (without calculating the explicit path for the SR path
path for the SR path). The ingress router of the forwarding path needs ). The ingress router of the forwarding path needs
to encapsulate the destination Node-SID on top of the packet. to encapsulate the destination Node-SID on top of the packet.
All the intermediate nodes will forward the packet based on the All the intermediate nodes will forward the packet based on the
destination Node-SID. It is similar to the LDP LSP.</t> destination Node-SID. It is similar to the LDP LSP.</t>
<t>R1 may send a packet to R8 simply by pushing an SR label with
<t>R1 may send a packet to R8 simply by pushing an SR label with segment {1008} (Node-SID for R8). The path will be based on the routing / nex
segment {1008} (Node-SID for R8). The path will be based on the routing/nexth t hop calculation on the routers.</t>
op calculation on the routers.</t> </section>
<section anchor="sect-4.3" numbered="true" toc="default">
</section> <name>PCECC for SR-MPLS TE Paths</name>
<t>
<section title="PCECC for SR-MPLS TE Path" anchor="sect-4.3"> SR-TE paths may not follow an IGP shortest path tree (SPT). Such
paths may be chosen by a PCECC and provisioned on the ingress node
<t>SR-TE paths may not follow an IGP shortest path tree (SPT). S of the SR-TE path. The SR header consists of a list of SIDs (or
uch paths may be chosen by a MPLS labels). The header has all necessary information so that
PCECC and provisioned on the ingress node of the SR-TE path. The SR the packets can be guided from the ingress node to the egress node
header consists of a list of SIDs (or MPLS labels). The header has of the path. Hence, there is no need for any signalling protocol.
all necessary information so that the packets can be guided from the For the case where a strict traffic engineering path is needed,
ingress node to the egress node of the path. Hence, there is no need all the Adj-SIDs are stacked; otherwise, a combination of Node-SIDs
for any signalling protocol. For the case where a strict traffic or Adj-SIDs can be used for the SR-TE paths.</t>
engineering path is needed, all the Adj-SID are stacked, <t>
otherwise, a combination of node-SID or adj-SID can be used for the As shown in <xref target="fig-sr-te" format="default"/>, R1 may
SR-TE paths.</t> send a packet to R8 by pushing an SR header with segment list
{1002, 9001, 1008}, where 1002 and 1008 are the Node-SIDs of R2 and
<t>As shown in <xref target="fig-sr-te"/>, R1 may send a packet to R8 by pushing R8, respectively. 9001 is the Adj-SID for link1. The path should
an SR header with segment be: "R1-R2-link1-R3-R8".</t>
list {1002, 9001, 1008}. Where 1002 and 1008 are the Node-SID of R2 and R8 re <t>
spectively. 9001 is the Adj-SID for link1. The path should be: R1-R2-link1-R3-R8 To achieve this, the PCECC first allocates and distributes SIDs as
.</t> described in <xref target="sect-4.1" format="default"/>. <xref
target="RFC8664" format="default"/> describes the mechanism for a
<t> PCE to compute, update, or initiate SR-MPLS TE paths.
To achieve this, the PCECC first allocates and distributes SIDs as </t>
described in <xref target="sect-4.1"/>. <xref target="RFC8664"/> describes t <figure anchor="fig-sr-te">
he <name>PCECC TE LSP Setup Example</name>
mechanism for a PCE to <artwork name="" type="" align="left" alt=""><![CDATA[
compute, update, or initiate SR-MPLS TE paths. </t>
<figure title="PCECC TE LSP Setup Example" anchor="fig-sr-te"><artwork><!
[CDATA[
192.0.2.1/32 192.0.2.1/32
+----------+ +----------+
| R1 (1001)| | R1 (1001)|
+----------+ +----------+
| | | |
90011 | |90012 90011 | |90012
link1 | |link2 link1 | |link2
+----------+ +----------+
| R2 (1002)| 192.0.2.2/32 | R2 (1002)| 192.0.2.2/32
+----------+ +----------+
skipping to change at line 636 skipping to change at line 444
* | * + * | * +
+-----------+ +-----------+ +-----------+ +-----------+
192.0.2.3/32 | R3 (1003) | |R6 (1006) |192.0.2.6/32 192.0.2.3/32 | R3 (1003) | |R6 (1006) |192.0.2.6/32
+-----------+ +-----------+ +-----------+ +-----------+
| | | |
|link8 | |link8 |
| |----------|link9 | |----------|link9
+-----------+ +-----------+
| R8 (1008) | 192.0.2.8/32 | R8 (1008) | 192.0.2.8/32
+-----------+ +-----------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Refer to <xref target="fig-sr-te"/> for an example of TE topology, where, 1
00x - are Node-SIDs and 900xx - are Adj-SIDs.
<list style="symbols">
<t>The SID allocation and distribution are done by the PCECC with all Node-SIDs
(100x) and all Adj-SIDs (900xx).</t>
<t>Based on path computation request/delegation or PCE initiation, the PCECC
receives a request with constraints and optimization criteria from a PCC. </t>
<t>PCECC will calculate the optimal path according to the given constraints
(e.g. bandwidth). </t>
<t> PCECC will provision SR-MPLS TE LSP (path R1-link1-R2-link6-R3-R8) at the in
gress node: {90011,1002,90026,1003,1008}</t>
<t>For the end-to-end protection, PCECC can provision the secondary path (R1-lin
k2-R2-link4-R5-R8): {90012,1002,90024,1005,1008}.</t>
</list></t> <t>
Refer to <xref target="fig-sr-te" format="default"/> for an
example of TE topology, where 100x are Node-SIDs and 900xx are Adj-SI
Ds.
</t>
<section title="PCECC for SR Policy" anchor="sect-4.4"> <ul spacing="normal">
<li>
<t>The SID allocation and distribution are done by the PCECC with
all Node-SIDs (100x) and all Adj-SIDs (900xx).</t>
</li>
<li>
<t>Based on path computation request/delegation or PCE
initiation, the PCECC receives a request with constraints and
optimization criteria from a PCC.</t>
</li>
<li>
<t>The PCECC will calculate the optimal path according to the give
n
constraints (e.g., bandwidth (BW)).</t>
</li>
<li>
<t>The PCECC will provision the SR-MPLS TE LSP path ("R1-link1-R2-
link6-R3-R8") at the ingress node: {90011, 1002, 90026, 1003, 1008}</t>
</li>
<li>
<t>For the end-to-end protection, the PCECC can provision the seco
ndary path ("R1-link2-R2-link4-R5-R8"): {90012, 1002, 90024, 1005, 1008}.</t>
</li>
</ul>
<t><xref target="RFC8402"/> defines Segment Routing architecture, which uses an <section anchor="sect-4.4" numbered="true" toc="default">
SR Policy <name>PCECC for SR Policy</name>
to steer packets from a node through an ordered list of segments. The SR Poli
cy could be
configured on the headend or instantiated by an SR controller.
The SR architecture does not restrict how the controller programs the
network. In this case, the focus is on PCEP as the protocol for SR Policy del
ivery from PCE to PCC. </t>
<t>An SR Policy architecture is described in <xref target="RFC9256"/>. An SR <t><xref target="RFC8402" format="default"/> defines SR
Policy is a framework that enables the architecture, which uses an SR Policy to steer packets
instantiation of an ordered list of segments on a node for from a node through an ordered list of segments. The SR Policy
implementing a source routing policy for the steering of traffic for a could be configured on the headend or instantiated by an SR
specific purpose (e.g. for a specific SLA) from that node.</t> controller. The SR architecture does not restrict how the
controller programs the network. In this case, the focus is on
PCEP as the protocol for SR Policy delivery from the PCE to PCC. </t
>
<t>An SR Policy is identified through the tuple &lt;headend, color, <t>An SR Policy architecture is described in <xref
endpoint&gt;. </t> target="RFC9256" format="default"/>. An SR Policy is a framework
that enables the instantiation of an ordered list of segments on a
node for implementing a source routing policy for the steering of
traffic for a specific purpose (e.g., for a specific Service Level A
greement (SLA)) from that
node.</t>
<t><xref target="fig-sr-te"/> is used as an example of PCECC application for S <t>An SR Policy is identified through the tuple &lt;headend,
R Policy instantiation for SR-MPLS, where, 100x - are Node-SIDs and 900xx - are color, endpoint&gt;.</t>
Adj-SIDs.</t>
<t>Let's assume that R1 needs to have two disjoint SR Policies towards R8 bas <t><xref target="fig-sr-te" format="default"/> is used as an
ed on different bandwidths, the possible paths are: example of PCECC application for SR Policy instantiation for
<list> SR-MPLS, where the Node-SIDs are 100x and the Adj-SIDs are 900xx.</t>
<t>POL1: {Headend R1, color 100, Endpoint R8; Candidate Path1: Segment List 1
: {90011,1002,90023,1004,1003,1008}}</t>
<t>POL2: {Headend R1, color 200, Endpoint R8; Candidate Path1: Segment List 1
: {90012,1002,90024,1005,1006,1008}}</t>
</list></t>
<t>Each SR Policy (including candidate path and segment list) will be signall
ed to a headend (R1) via PCEP <xref target="I-D.ietf-pce-segment-routing-policy
-cp"/> with the addition of an ASSOCIATION object.
Binding SID (BSID) <xref target="RFC8402"/> can be used for traffic steering
of labelled traffic into SR Policy, BSID can be provisioned from PCECC also via
PCEP <xref target="I-D.ietf-pce-binding-label-sid"/>.
For non-labelled traffic steering into the SR Policy POL1 or POL2, a per-dest
ination traffic steering will be used by means of the BGP Color extended communi
ty <xref target="RFC9012"/> </t>
<t> The procedure: <list> <t>Let's assume that R1 needs to have two disjoint SR Policies
<t> PCECC allocates Node-SIDs and Adj-SIDs using the mechanism described in < towards R8 based on different BWs. This means the possible paths
xref target="sect-4.1"/> for all nodes and links. </t> are:</t>
<t> PCECC will calculate disjoint paths for POL1 and POL2 and create Segment
Lists for them:{90011,1002,90023,1004,1003,1008};{90012,1002,90024,1005,1006,100
8}.</t>
<t> PCECC will form both SR Policies POL1 and POL2.</t>
<t> PCECC will send both POL1 and POl2 to R1 via PCEP. </t>
<t> PCECC optionally can allocate BSIDs for the SR Policies.</t>
<t>The traffic from R1 to R8 which fits to color 100 will be steered to POL1 <ul>
and follows the path: R1-link1-R2-link3-R4-R3-R8. The traffic from R1 to R8 whic <li>
h fits color 200 POL1: {Headend R1, color 100, Endpoint R8; Candidate Path1: Segm
will be steered to POL2 and follows the path: R1-link2-R2-link4-R5-R6-R8. Due ent List 1: {90011, 1002, 90023, 1004, 1003, 1008}}
to the possibility of having many Segment Lists in the same Candidate Path of e </li>
ach POL1/POL2, <li>
PCECC could provision more paths towards R8 and traffic will be balanced eith POL2: {Headend R1, color 200, Endpoint R8; Candidate Path1: Segm
er as ECMP or as w/ECMP. This is the advantage of SR Policy architecture. </t> ent List 1: {90012, 1002, 90024, 1005, 1006, 1008}}
</list></t> </li>
</ul>
<t>Note that an SR Policy can be associated with multiple candidate paths. A <t>Each SR Policy (including the candidate path and segment list) wi
candidate path is selected when it is valid and it is determined to be the best ll
path of the SR Policy as described in <xref target="RFC9256"/>.</t> be signalled to a headend (R1) via PCEP <xref
target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/>
with the addition of an ASSOCIATION object. A Binding SID (BSID)
<xref target="RFC8402" format="default"/> can be used for traffic
steering of labelled traffic into an SR Policy; a BSID can be
provisioned from the PCECC also via PCEP <xref target="RFC9604"
format="default"/>. For non-labelled traffic steering into the SR
Policy POL1 or POL2, a per-destination traffic steering will be
used by means of the BGP Color Extended Community <xref
target="RFC9012" format="default"/>.</t>
</section> <t>The procedure is as follows:</t>
</section> <ul>
<section title="PCECC for SRv6" anchor="sect-8"> <li>
<t>As per <xref target="RFC8402"/>, with Segment Routing (SR), The PCECC allocates Node-SIDs and Adj-SIDs using the mechanism d
a node steers a packet through an ordered list of instructions, escribed in <xref target="sect-4.1" format="default"/> for all nodes and links.
called segments. Segment Routing </li>
can be applied to the IPv6 architecture with the Segment Routing <li>
Header (SRH) <xref target="RFC8754"/>. A segment is The PCECC calculates disjoint paths for POL1 and POL2 and create
encoded as an IPv6 address. An ordered list of segments is encoded segment lists for them: {90011, 1002, 90023, 1004, 1003, 1008};{90012, 1002, 90
as an ordered list of IPv6 addresses in the routing header. The 024, 1005, 1006, 1008}.
active segment is indicated by the Destination Address of the packet. </li>
Upon completion of a segment, a pointer in the new routing header is <li>
incremented and indicates the next segment.</t> The PCECC forms both SR Policies POL1 and POL2.
</li>
<li>
The PCECC sends both POL1 and POL2 to R1 via PCEP.
</li>
<li>
The PCECC optionally allocates BSIDs for the SR Policies.
</li>
<li>
The traffic from R1 to R8, which fits to color 100, will be
steered to POL1 and follows the path:
"R1-link1-R2-link3-R4-R3-R8". The traffic from R1 to R8, which
fits color 200, will be steered to POL2 and follows the path:
"R1-link2-R2-link4-R5-R6-R8". Due to the possibility of having
many segment lists in the same candidate path of each
POL1/POL2, the PCECC could provision more paths towards R8 and
traffic will be balanced either as ECMP or as weighted-ECMP (W-E
CMP). This is
the advantage of SR Policy architecture.
</li>
</ul>
<t>As per <xref target="RFC8754"/>, an SRv6 Segment is a <t>Note that an SR Policy can be associated with multiple candidate
128-bit value. "SRv6 SID" or simply "SID" are often used as a paths. A candidate path is selected when it is valid and it is determined to be
shorter reference for "SRv6 Segment". the best path of the SR Policy as described in <xref target="RFC9256" format="de
<xref target="RFC8986"/> defines the SRv6 SID as consisting of LOC:FUNCT:ARG. fault"/>.</t>
</t> </section>
</section>
<t><xref target="I-D.ietf-pce-segment-routing-ipv6"/> extends <section anchor="sect-8" numbered="true" toc="default">
<xref target="RFC8664"/> to support SR for the IPv6 data plane. Further, <name>PCECC for SRv6</name>
<t>As per <xref target="RFC8402" format="default"/>, with
SR, a node steers a packet through an ordered list of
instructions, called segments. SR can be applied to
the IPv6 architecture with the Segment Routing Header (SRH) <xref
target="RFC8754" format="default"/>. A segment is encoded as an
IPv6 address. An ordered list of segments is encoded as an ordered
list of IPv6 addresses in the routing header. The active segment is
indicated by the destination address of the packet. Upon completion
of a segment, a pointer in the new routing header is incremented and
indicates the next segment.</t>
<t>As per <xref target="RFC8754" format="default"/>, an SR over IPv6
(SRv6) Segment is a 128-bit value. "SRv6 SID" or simply "SID" are
often used as a shorter reference for "SRv6 Segment". <xref
target="RFC8986" format="default"/> defines the SRv6 SID as
consisting of LOC:FUNCT:ARG.</t>
<t><xref target="RFC9603" format="default"/> extends
<xref target="RFC8664" format="default"/> to support SR for the IPv6 data pla
ne. Further,
a PCECC could be extended to support SRv6 SID allocation and distribution. a PCECC could be extended to support SRv6 SID allocation and distribution.
An example of how PCEP extensions could be An example of how PCEP extensions could be
extended for SRv6 for PCECC is described in <xref target="I-D.dhody-pce-pcep extended for SRv6 for a PCECC is described in <xref target="I-D.ietf-pce-pce
-extension-pce-controller-srv6"/>.</t> p-extension-pce-controller-srv6" format="default"/>.</t>
<figure anchor="fig_srv6">
<figure title="PCECC for SRv6" anchor="fig_srv6"><artwork> <name>PCECC for SRv6</name>
<![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
2001:db8::1 2001:db8::1
+----------+ +----------+
| R1 | | R1 |
+----------+ +----------+
| |
+----------+ +----------+
| R2 | 2001:db8::2 | R2 | 2001:db8::2
+----------+ +----------+
* | * * * | * *
* | * * * | * *
skipping to change at line 746 skipping to change at line 607
* | * * + * | * * +
* | * * + * | * * +
* | * * + * | * * +
+-----------+ +-----------+ +-----------+ +-----------+
2001:db8::3 | R3 | |R6 |2001:db8::6 2001:db8::3 | R3 | |R6 |2001:db8::6
+-----------+ +-----------+ +-----------+ +-----------+
| |
+-----------+ +-----------+
| R8 | 2001:db8::8 | R8 | 2001:db8::8
+-----------+ +-----------+
]]> ]]></artwork>
</artwork></figure> </figure>
<t>In this case, as shown in <xref target="fig_srv6"/>, PCECC could assign the <t>In this case, as shown in <xref target="fig_srv6"
SRv6 SID (in the form of an IPv6 address) to be used for node and adjacency. La format="default"/>, the PCECC could assign the SRv6 SID (in the form o
ter, the SRv6 path in the form of a list of SRv6 SIDs could be used at the ingre f
ss. Some examples - an IPv6 address) to be used for node and adjacency. Later, the SRv6
<list style="symbols"> path in the form of a list of SRv6 SIDs could be used at the
<t>SRv6 SID-List={2001:db8::8} - The best path towards R8</t> ingress. Some examples:
<t>SRv6 SID-List={2001:db8::5, 2001:db8::8} - The path towards R8 via R5</ </t>
t>
</list></t>
<t>The rest of the procedures and mechanisms remain the same as SR-MPLS.</t>
</section>
</section>
<section title="PCECC for Static TE LSP" anchor="sect-5"> <ul spacing="normal">
<li>
The best path towards R8: SRv6 SID-List={2001:db8::8}
</li>
<li>
The path towards R8 via R5: SRv6 SID-List={2001:db8::5, 2001:db8::
8}
</li>
</ul>
<t>As described in Section 3.1.2 of <xref target="RFC8283"/>, PCECC architect <t>The rest of the procedures and mechanisms remain the same as SR-MPL
ure supports S.</t>
the provisioning of static TE LSP. To achieve this, the
</section>
</section>
<section anchor="sect-5" numbered="true" toc="default">
<name>PCECC for Static TE LSPs</name>
<t>As described in <xref target="RFC8283" section="3.1.2" sectionFormat=
"of"/>, the PCECC architecture supports
the provisioning of static TE LSPs. To achieve this, the
existing PCEP can be used to communicate between the PCECC and existing PCEP can be used to communicate between the PCECC and
nodes along the path to provision explicit label instructions at each hop on the nodes along the path to provision explicit label instructions at each hop on the
end-to-end path. Each router along the path must be told what label-forwardi ng instructions to program and what resources to reserve. end-to-end path. Each router along the path must be told what label-forwardi ng instructions to program and what resources to reserve.
The PCE-based controller keeps a view of the network and determines The PCECC keeps a view of the network and determines
the paths of the end-to-end LSPs, and the controller uses PCEP to the paths of the end-to-end LSPs, and the controller uses PCEP to
communicate with each router along the path of the end-to-end LSP.</t> communicate with each router along the path of the end-to-end LSP.</t>
<figure anchor="fig-te">
<figure title="PCECC TE LSP Setup Example" anchor="fig-te"><artwork><![CD <name>PCECC TE LSP Setup Example</name>
ATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
192.0.2.1/32 192.0.2.1/32
+----------+ +----------+
| R1 | | R1 |
+----------+ +----------+
| | | |
|link1 | |link1 |
| |link2 | |link2
+----------+ +----------+
| R2 | 192.0.2.2/32 | R2 | 192.0.2.2/32
+----------+ +----------+
skipping to change at line 799 skipping to change at line 673
* | * * + * | * * +
+-----------+ +-----------+ +-----------+ +-----------+
192.0.2.3/32 | R3 | |R6 |192.0.2.6/32 192.0.2.3/32 | R3 | |R6 |192.0.2.6/32
+-----------+ +-----------+ +-----------+ +-----------+
| | | |
|link8 | |link8 |
| |link9 | |link9
+-----------+ +-----------+
| R8 | 192.0.2.8/32 | R8 | 192.0.2.8/32
+-----------+ +-----------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Refer to <xref target="fig-te"/> for an example TE topology. <t>Refer to <xref target="fig-te" format="default"/> for an example TE t
<list style="symbols"> opology.</t>
<t>Based on path computation request/delegation or PCE initiation, the PCECC
receives a request with constraints and optimization criteria. </t>
<t>PCECC will calculate the optimal path according to the given constraints
(e.g. bandwidth).</t>
<t>PCECC will provision each node along the path and assign incoming and outgoin <ul spacing="normal">
g labels from R1 to R8 with the <li>
<t>Based on path computation request/delegation or PCE initiation, t
he PCECC
receives a request with constraints and optimization criteria.</t>
</li>
<li>
<t>The PCECC will calculate the optimal path according to the given
constraints
(e.g., BW).</t>
</li>
<li>
<t>The PCECC will provision each node along the path and assign inco
ming and outgoing labels from R1 to R8 with the
path as "R1-link1-R2-link3-R4-link10-R3-link8-R8": path as "R1-link1-R2-link3-R4-link10-R3-link8-R8":
<list style="symbols"> </t>
<t>R1: Outgoing label 1001 on link 1</t> <ul spacing="normal">
<t>R2: Incoming label 1001 on link 1</t> <li>
<t>R2: Outgoing label 2003 on link 3</t> <t>R1: Outgoing label 1001 on link 1</t>
<t>R4: Incoming label 2003 on link 3</t> </li>
<t>R4: Outgoing label 4010 on link 10</t> <li>
<t>R3: Incoming label 4010 on link 10</t> <t>R2: Incoming label 1001 on link 1</t>
<t>R3: Outgoing label 3008 on link 8</t> </li>
<t>R8: Incoming label 3008 on link 8</t> <li>
</list></t> <t>R2: Outgoing label 2003 on link 3</t>
<t>This can also be represented as </li>
{R1, link1, 1001}, {1001, R2, link3, 2003], {2003, R4, link10, 4010}, {4010, <li>
R3, link8, 3008}, {3008, R8}.</t> <t>R4: Incoming label 2003 on link 3</t>
</li>
<t>For the end-to-end protection, PCECC programs each node along the <li>
path from R1 to R8 with the secondary path: {R1, link2, 1002}, <t>R4: Outgoing label 4010 on link 10</t>
{1002, R2, link4, 2004], {2004, R5, link7, 5007}, {5007, R3, link9, 3009}, {3 </li>
009, R8}.</t> <li>
<t>R3: Incoming label 4010 on link 10</t>
</li>
<li>
<t>R3: Outgoing label 3008 on link 8</t>
</li>
<li>
<t>R8: Incoming label 3008 on link 8</t>
</li>
</ul>
</li>
<li>
<t>This can also be represented as: {R1, link1, 1001}, {1001, R2,
link3, 2003}, {2003, R4, link10, 4010}, {4010, R3, link8, 3008},
{3008, R8}.</t>
</li>
<li>
<t>For the end-to-end protection, the PCECC programs each node along
the path from R1 to R8 with the secondary path: {R1, link2, 1002},
{1002, R2, link4, 2004}, {2004, R5, link7, 5007}, {5007, R3,
link9, 3009}, {3009, R8}.</t>
</li>
<li>
<t>It is also possible to have a bypass path for the local
protection set up by the PCECC. For example, use the primary path
as above, then to protect the node R4 locally, the PCECC can program
the bypass path like this: {R2, link5, 2005}, {2005, R3}. By doing
this, the node R4 is locally protected at R2.</t>
</li>
</ul>
</section>
<t>It is also possible to have a bypass path for the local <section anchor="sect-lb" numbered="true" toc="default">
protection set up by the PCECC. For example, the primary path as above, then <name>PCECC for Load Balancing (LB)</name>
to protect the node <t>
R4 locally, PCECC can program the bypass path like this: Very often, many service providers use TE tunnels for solving issues
{R2, link5, 2005}, {2005, R3}. By doing
this, the node R4 is locally protected at R2.</t>
</list></t>
</section>
<section title="PCECC for Load Balancing (LB)" anchor="sect-lb">
<t>
Very often many service providers use TE tunnels for solving issues
with non-deterministic paths in their networks. One example of such with non-deterministic paths in their networks. One example of such
applications is the usage of TEs in the mobile backhaul (MBH). applications is the usage of TEs in the mobile backhaul (MBH).
Consider the topology as shown in <xref target="fig_lb"/> (AGG1...AGGN are Ag gregation Routers, Core 1...Core N are Core routers) - </t> Consider the topology as shown in <xref target="fig_lb" format="default"/> (w here AGG 1...AGG N are Aggregation routers, and Core 1...Core N are Core routers ). </t>
<figure title="PCECC Load Balancing (LB) Use Case" anchor="fig_lb"><artwo <figure anchor="fig_lb">
rk><![CDATA[ <name>PCECC LB Use Case</name>
TE1 --------------> <artwork name="" type="" align="left" alt=""><![CDATA[
+---------+ +--------+ +--------+ +--------+ +------+ +---+ TE1 ----------->
| Access |----| Access |----| AGG 1 |----| AGG N-1|----|Core 1|--|SR1| +--------+ +------+ +-----+ +-------+ +------+ +---+
| SubNode1| | Node 1 | +--------+ +--------+ +------+ +---+ |Access |----|Access|----|AGG 1|----|AGG N-1|----|Core 1|--|SR1|
+---------+ +--------+ | | | ^ | |SubNode1| |Node1 | +-----+ +-------+ +------+ +---+
| Access | Access | AGG Ring 1 | | | +--------+ +------+ | | | ^ |
| SubRing 1 | Ring 1 | | | | | | Access | Access | AGG Ring 1| | |
+---------+ +--------+ +--------+ | | | | SubRing 1 | Ring 1 | | | | |
| Access | | Access | | AGG 2 | | | | +--------+ +------+ +-----+ | | |
| SubNode2| | Node 2 | +--------+ | | | |Access | |Access| |AGG 2| | | |
+---------+ +--------+ | | | | | |SubNode2| |Node2 | +-----+ | | |
| | | | | | | +--------+ +------+ | | | | |
| | | +----TE2----|-+ | | | | | | | |
+---------+ +--------+ +--------+ +--------+ +------+ +---+ | | | +---TE2---|-+ |
| Access | | Access |----| AGG 3 |----| AGG N |----|Core N|--|SRn| +--------+ +------+ +-----+ +-------+ +------+ +---+
| SubNodeN|----| Node N | +--------+ +--------+ +------+ +---+ |Access | |Access|----|AGG 3|----| AGG N |----|Core N|--|SRn|
+---------+ +--------+ |SubNodeN|----|NodeN | +-----+ +-------+ +------+ +---+
+--------+ +------+
]]></artwork> ]]></artwork>
</figure> --------+ <span class="insert">+------+</span>
<t> </figure>
<t>
This MBH architecture uses L2 access rings and sub-rings. L3 starts at This MBH architecture uses L2 access rings and sub-rings. L3 starts at
the aggregation layer. For the sake of simplicity, the figure shows only one access the aggregation layer. For the sake of simplicity, the figure shows only one access
sub-ring. The access ring and aggregation ring are connected sub-ring. The access ring and aggregation ring are connected
by Nx10GE interfaces. The aggregation domain runs its own IGP. There are by Nx10GE interfaces. The aggregation domain runs its own IGP. There are
two Egress routers (AGG N-1, AGG N) that are connected to the Core two egress routers (AGG N-1 and AGG N) that are connected to the Core
domain (Core 1...Core N) via L2 interfaces. Core also has connections to serv domain (Core 1...Core N) via L2 interfaces. The Core also has connections to
ice routers, service routers;
RSVP-TE or SR-TE is used for MPLS transport inside the ring. There could be RSVP-TE or SR-TE is used for MPLS transport inside the ring. There could be
at least 2 tunnels (one way) from each AGG router to egress AGG at least two tunnels (one way) from each AGG router to egress AGG
routers. There are also many L2 access rings connected to AGG routers.</t> routers. There are also many L2 access rings connected to AGG routers.</t>
<t> <t>
Service deployment is made by means of Layer 2 Virtual Private Networks (L2VP Service deployment is made by means of Layer 2 Virtual Private Networks
Ns) (Virtual Private LAN Services (VPLS)), Layer 3 Virtual Private Networks (L3V (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 Virtual Private
PNs) or Ethernet VPNs (EVPNs). Networks (L3VPNs), or Ethernet VPNs (EVPNs). Those services use MPLS TE
Those services use MPLS TE (or SR-TE) as transport towards egress AGG routers (or SR-TE) as transport towards egress AGG routers. TE tunnels could be
. used as transport towards service routers in case of architecture based on
TE tunnels could be used as transport towards service routers in seamless MPLS <xref target="I-D.ietf-mpls-seamless-mpls"
case of seamless MPLS (<xref target="I-D.ietf-mpls-seamless-mpls"/>) based ar format="default"/>.
chitecture.</t> </t>
<t>Load Balancing (LB) between TE tunnels involves distributing network
<t>Load balancing between TE tunnels involves distributing network traffic ac traffic across multiple TE tunnels to optimize the use of available
ross multiple TE tunnels to optimize the use of available network resources, enh network resources, enhance performance, and ensure reliability. Some
ance performance, and ensure reliability. Some common techniques include Equal-C common techniques include Equal-Cost Multipath (ECMP) and
ost Multi-Path (ECMP) and Unequal-Cost Multi-Path (UCMP) based on the bandwidth Unequal-Cost Multipath (UCMP) based on the BW of the TE
of the TE tunnels.</t> tunnels.</t>
<t>There is a need to solve the following tasks:
<t>There is a need to solve the following tasks: </t>
<list style="symbols"> <ul spacing="normal">
<li>
<t>Perform automatic load-balance amongst TE tunnels according to current <t>Perform automatic LB amongst TE tunnels according to current traf
traffic load.</t> fic loads.</t>
<t>TE bandwidth (BW) management: Provide guaranteed BW for specific </li>
services: High-Speed Data Service (HSI)), IPTV, etc., and provide time-ba <li>
sed BW reservation (BW on demand (BoD)) for other services.</t> <t>Manage TE BW by guaranteeing BW for specific
<t>Simplify the development of TE tunnels by automation without any manual int services (such as High-Speed Internet (HSI), IPTV, etc.)
ervention.</t> and enabling time-based BW reservation (such as Bandwidth
on Demand (BoD)).</t>
<t>Provide flexibility for Service Router placement (anywhere </li>
in the network by the creation of transport LSPs to them).</t> <li>
</list></t> <t>Simplify the development of TE tunnels by automation without any
<t>In this section, the focus is on load balancing (LB) tasks. LB task manual intervention.</t>
could be solved by means of PCECC in the following way: </li>
<list style="symbols"> <li>
<t>Application or network service or operator can ask the SDN <t>Provide flexibility for service router placement
controller (PCECC) for LSP-based load balancing between AGG X and AGG N/A (anywhere in the network by the creation of transport LSPs to
GG N-1 them).</t>
(egress AGG routers that have connections to the core). </li>
Each of these will have associated constraints (i.e. bandwidth, inclus </ul>
ion or exclusion specific links <t>In this section, the focus is on LB tasks. LB tasks
or nodes, number of paths, objective function (OF), need for disjoint LSP could be solved by means of the PCECC in the following ways:
paths etc.);</t> </t>
<t>PCECC could calculate multiple (say N) LSPs according to given constra
ints,
the calculation is based on results of Objective Function (OF) <xref targ
et="RFC5541"/>, constraints, endpoints, same or different
bandwidth (BW), different links (in case of disjoint paths) and other
constraints.</t>
<t>Depending on the given LSP Path setup type (PST), PCECC will download
instructions to the PCC. At this stage, it is assumed the PCECC is aware
of the label space it controls and SID allocation and
distribution is already done in the case of SR.</t>
<t>PCECC will send PCInitiate message <xref target="RFC8281"/> towards in <ul spacing="normal">
gress AGG X router(PCC) for each of N LSPs <li>
and receive PCRpt message <xref target="RFC8231"/> back from <t>Applications, network services, or operators can ask the SDN
PCCs. If PST is PCECC-SR, the PCECC will include a SID stack as per <xref controller (PCECC) for LSP-based LB between AGG X and
target="RFC8664"/>. AGG N/AGG N-1 (egress AGG routers that have connections to the
If PST is PCECC (basic), then the PCECC will assign labels along the calc core). Each of these will have associated constraints
ulated path and set up the (such as BW, inclusion or exclusion of specific links or nodes,
path by sending central controller instructions in a PCEP message to each nod number of paths, Objective Function (OF), need for disjoint LSP
e along the path of the paths, etc.).</t>
LSP as per <xref target="RFC9050"/> and then </li>
send PCUpd message to the ingress AGG X router with <li>
information about new LSP. AGG X(PCC) will respond with PCRpt <t>The PCECC could calculate multiple (say N) LSPs according to give
with LSP status.</t> n
constraints. The calculation is based on the results of the OF <xref
target="RFC5541" format="default"/>,
constraints, endpoints, same or different BW,
different links (in case of disjoint paths), and other
constraints.</t>
</li>
<li>
<t>Depending on the given LSP PST, the PCECC will
download instructions to the PCC. At this stage, it is assumed the
PCECC is aware of the label space it controls and SID allocation
and distribution is already done in the case of SR.</t>
</li>
<t>AGG X as an ingress router now has N LSPs towards AGG N and AG <li>
G N-1 <t>The PCECC will send a PCInitiate message <xref target="RFC8281"
which are available for installation to the router's forwarding table and format="default"/> towards the ingress AGG X router (PCC) for each o
load-balance traffic f
N LSPs and receive a PCRpt message <xref target="RFC8231"
format="default"/> back from PCCs. If the PST is a PCECC-SR, the PCE
CC
will include a SID stack as per <xref target="RFC8664"
format="default"/>. If the PST is set to "PCECC" type, then the PCE
CC will
assign labels along the calculated path and set up the path by
sending central controller instructions in a PCEP message to each
node along the path of the LSP as per <xref target="RFC9050"
format="default"/>. Then, the PCECC will send a PCUpd message to the
ingress AGG
X router with information about the new LSP. AGG X (PCC) will respon
d
with a PCRpt with LSP status.</t>
</li>
<li>
<t>AGG X as an ingress router now has N LSPs towards AGG N and AGG N
-1,
which are available for installation to the router's forwarding table and
for LB traffic
between them. Traffic distribution between those LSPs depends on between them. Traffic distribution between those LSPs depends on
the particular realization of the hash-function on that router.</t> the particular realization of the hash function on that router.</t>
</li>
<t>Since PCECC is aware of TEDB (TE state) and LSP-DB, it can manage and <li>
<t>Since the PCECC is aware of the Traffic Engineering Database (TED
) (TE state) and the LSP Database (LSP-DB), it can manage and
prevent possible over-subscriptions and limit the number of available loa d-balance prevent possible over-subscriptions and limit the number of available loa d-balance
states. Via PCECC mechanism the control can take quick actions into the n states. Via a PCECC mechanism, the control can take quick actions into th
etwork by directly provisioning the central control instructions.</t> e network by directly provisioning the central control instructions.</t>
</li>
</list> </ul>
</t> </section>
<section anchor="sect-5.1" numbered="true" toc="default">
</section> <name>PCECC and Inter-AS TE</name>
<t>
<section title="PCECC and Inter-AS TE" anchor="sect-5.1"> There are various signalling options for establishing Inter-AS TE
<t> LSPs: contiguous TE LSPs <xref target="RFC5151" format="default"/>,
There are various signalling options for establishing Inter-AS TE LSP: stitched TE LSPs <xref target="RFC5150" format="default"/>, and
contiguous TE LSP <xref target="RFC5151"/>, stitched TE LSP <xref target="RFC nested TE LSPs <xref target="RFC4206" format="default"/>.</t>
5150"/>, <t>
and nested TE LSP <xref target="RFC4206"/>.</t> The requirements for PCE-based Inter-AS setup <xref target="RFC5376" format="
default"/> describe the approach
<t>
Requirements for PCE-based Inter-AS setup <xref target="RFC5376"/> describe t
he approach
and PCEP functionality that is needed for establishing Inter-AS TE LSPs.</t> and PCEP functionality that is needed for establishing Inter-AS TE LSPs.</t>
<t>
<t> <xref target="RFC5376" format="default"/> also gives an Inter-AS and
<xref target="RFC5376"/> also gives Inter- and Intra-AS PCE Reference Model ( Intra-AS PCE Reference Model (as shown in <xref target="fig_short"
as shown in <xref target="fig_short"/>) that is format="default"/>) that is provided below in shortened form for the sake
provided below in shortened form for the sake of simplicity.</t> of simplicity.</t>
<figure anchor="fig_short">
<figure title="Shortened form of Inter- and Intra-AS PCE Reference Model" <name>Shortened Form of the Inter-AS and Intra-AS PCE Reference Model<
anchor="fig_short"><artwork><![CDATA[ /name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Inter-AS Inter-AS Inter-AS Inter-AS
PCC <-->PCE1<--------->PCE2 PCC <-->PCE1<--------->PCE2
:: :: :: :: :: ::
:: :: :: :: :: ::
R1----ASBR1====ASBR3---R3---ASBR5 R1----ASBR1====ASBR3---R3---ASBR5
| AS1 | | PCC | | AS1 | | PCC |
| | | AS2 | | | | AS2 |
R2----ASBR2====ASBR4---R4---ASBR6 R2----ASBR2====ASBR4---R4---ASBR6
:: :: :: ::
:: :: :: ::
skipping to change at line 964 skipping to change at line 900
:: :: :: :: :: ::
:: :: :: :: :: ::
R1----ASBR1====ASBR3---R3---ASBR5 R1----ASBR1====ASBR3---R3---ASBR5
| AS1 | | PCC | | AS1 | | PCC |
| | | AS2 | | | | AS2 |
R2----ASBR2====ASBR4---R4---ASBR6 R2----ASBR2====ASBR4---R4---ASBR6
:: :: :: ::
:: :: :: ::
Intra-AS Intra-AS Intra-AS Intra-AS
PCE3 PCE4 PCE3 PCE4
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The PCECC belonging to the different domains can cooperate to set
<t>The PCECC belonging to the different domains can cooperate to set up inter- up Inter-AS TE LSPs. The stateful Hierarchical PCE (H-PCE) mechanism <xr
AS TE LSP. The stateful H-PCE <xref target="RFC8751"/> mechanism could also be u ef
sed to establish a per-domain PCECC target="RFC8751" format="default"/> could also be used to establish a
LSP first. These could be stitched together to form inter-AS TE LSP as descr per-domain PCECC LSP first. These could be stitched together to form
ibed in <xref target="I-D.ietf-pce-stateful-interdomain"/>.</t> an Inter-AS TE LSP as described in <xref
<t> target="I-D.ietf-pce-stateful-interdomain" format="default"/>.</t>
For the sake of simplicity, here the focus is on a simplified Inter-AS case w <t>
hen both AS1 and For the sake of simplicity, here the focus is on a simplified
AS2 belong to the same service provider administration. In that case, Inter Inter-AS case when both AS1 and AS2 belong to the same service
and Intra-AS PCEs could be combined in one single PCE if such combined PCE provider administration. In that case, Inter-AS and Intra-AS PCEs could
performance is enough to handle the load. The PCE will require be combined in one single PCE if such combined PCE performance is
interfaces (PCEP and BGP-LS) to both domains. PCECC redundancy enough to handle the load. The PCE will require interfaces (PCEP
mechanisms are described in <xref target="RFC8283"/>. Thus routers (PCCs) in and BGP-LS) to both domains. PCECC redundancy mechanisms are
AS1 and AS2 described in <xref target="RFC8283" format="default"/>. Thus, routers
can send PCEP messages towards the same PCECC. In <xref target="fig_inter_as_ (PCCs) in AS1 and AS2 can send PCEP messages towards the same
pce"/>, PCECC maintains a BGP-LS session with route reflectors (RRs) in each AS. PCECC. In <xref target="fig_inter_as_pce" format="default"/>, the PCECC
This allows the RRs to redistribute routes to other BGP routers (clients) witho maintains a BGP-LS session with Route Reflectors (RRs) in each
ut requiring a full mesh. The RRs act as BGP-LS Propagator and PCECC act as a BG AS. This allows the RRs to redistribute routes to other BGP routers
P-LS Consumer <xref target="RFC9552"/>.</t> (clients) without requiring a full mesh. The RRs act as a BGP-LS
Propagator, and the PCECC acts as a BGP-LS Consumer <xref target="RFC95
<figure title="Particular case of Inter-AS PCE" anchor="fig_inter_as_pce" 52"
><artwork><![CDATA[ format="default"/>.</t>
<figure anchor="fig_inter_as_pce">
<name>Particular Case of Inter-AS PCE</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+----BGP-LS------+ +------BGP-LS-----+ +----BGP-LS------+ +------BGP-LS-----+
| | | | | | | |
+-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+ +-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+
+-:------|----::-:-+ +--::-:-|-------:---+ +-:------|----::-:-+ +--::-:-|-------:---+
| : | :: : | | :: : | : | | : | :: : | | :: : | : |
| : RR1 :: : | | :: : RR2 : | | : RR1 :: : | | :: : RR2 : |
| v v: : | LSP1 | :: v v | | v v: : | LSP1 | :: v v |
| R1---------ASBR1=======================ASBR3--------R3 | | R1---------ASBR1=======================ASBR3--------R3 |
| | v : | | :v | | | | v : | | :v | |
| +----------ASBR2=======================ASBR4---------+ | | +----------ASBR2=======================ASBR4---------+ |
skipping to change at line 998 skipping to change at line 944
| | v : | | :v | | | | v : | | :v | |
| +----------ASBR2=======================ASBR4---------+ | | +----------ASBR2=======================ASBR4---------+ |
| | Region 1 : | | : Region 1 | | | | Region 1 : | | : Region 1 | |
|----------------:-| |--:-------------|--| |----------------:-| |--:-------------|--|
| | v | LSP2 | v | | | | v | LSP2 | v | |
| +----------ASBR5=======================ASBR6---------+ | | +----------ASBR5=======================ASBR6---------+ |
| Region 2 | | Region 2 | | Region 2 | | Region 2 |
+------------------+ <--------------> +-------------------+ +------------------+ <--------------> +-------------------+
MPLS Domain 1 Inter-AS MPLS Domain 2 MPLS Domain 1 Inter-AS MPLS Domain 2
<=======AS1=======> <========AS2=======> <=======AS1=======> <========AS2=======>
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In the case of the PCECC Inter-AS TE scenario (as shown in <xref target="fig_ In the case of the PCECC Inter-AS TE scenario (as shown in <xref target="fig_
inter_as_pce"/>) where the service provider inter_as_pce" format="default"/>), where the service provider
controls both domains (AS1 and AS2), each of them has its own IGP and MPLS controls both domains (AS1 and AS2), each of them has its own IGP and MPLS
transport. There is a need to set up Inter-AS LSPs for transporting different transport. There is a need to set up Inter-AS LSPs for transporting different
services on top of them (Voice, L3VPN etc.). Inter-AS links with different services on top of them (such as Voice, L3VPN, etc.). Inter-AS links with dif ferent
capacities exist in several regions. The task is not only to provision capacities exist in several regions. The task is not only to provision
those Inter-AS LSPs with given constraints but also to calculate the path those Inter-AS LSPs with given constraints but also to calculate the path
and pre-setup the backup Inter-AS LSPs that will be used if the primary LSP f ails.</t> and pre-setup the backup Inter-AS LSPs that will be used if the primary LSP f ails.</t>
<t>
<t> As per <xref target="fig_inter_as_pce" format="default"/>, LSP1 from R1 to R
As per <xref target="fig_inter_as_pce"/>, LSP1 from R1 to R3 goes via ASBR1 3 goes via ASBR1
and ASBR3, and it is the primary Inter-AS LSP. R1-R3 LSP2 that goes via and ASBR3, and it is the primary Inter-AS LSP. LSP2 from R1 to R3 that goes v
ASBR5 and ASBR6 are the backup ones. In addition, there could also be a bypas ia
s LSP ASBR5 and ASBR6 is the backup one. In addition, there could also be a bypass
setup to protect against ASBR or inter-AS link failures.</t> LSP
setup to protect against ASBR or Inter-AS link failures.</t>
<t> <t>
After the addition of PCECC functionality to PCE (SDN controller), the PCECC- After the addition of PCECC functionality to the PCE (SDN controller),
based Inter-AS TE model should follow the PCECC use case for TE LSP the PCECC-based Inter-AS TE model should follow the PCECC use case
including requirements of <xref target="RFC5376"/> with the following details for TE LSP including the requirements described in <xref target="RFC537
: 6"
format="default"/> with the following details:
<list style="symbols"> </t>
<t>Since PCECC needs to know the topology of both domains AS1 and AS2, PC <ul spacing="normal">
ECC <li>
<t>Since the PCECC needs to know the topology of both domains AS1 an
d AS2, the PCECC
can utilize the BGP-LS peering with BGP routers (or RRs) in both domains. </t> can utilize the BGP-LS peering with BGP routers (or RRs) in both domains. </t>
</li>
<t>PCECC needs to establish PCEP connectivity with all routers in both <li>
domains (see also section 4 in <xref target="RFC5376"/>).</t> <t>The PCECC needs to establish PCEP connectivity with all routers i
n both
<t>After the operator's application or service orchestrator creates a req domains (see also <xref target="RFC5376" section="4" sectionFormat="of"/>
uest ).</t>
for tunnel creation of a specific service, PCECC will receive that reques </li>
t via NBI <li>
(NBI type is implementation dependent, it could be NETCONF/Yang, REST etc <t>After the operator's application or service orchestrator
.). Then creates a request for tunnel creation of a specific service, the PCE
PCECC will calculate the optimal path based on Objective Function (OF) an CC
d given will receive that request via the Northbound Interface (NBI) (note t
constraints (i.e. path setup type, bandwidth etc.), including those from hat the NBI type is
<xref target="RFC5376"/>: implementation-dependent; it could be NETCONF/YANG, REST,
priority, AS sequence, preferred ASBR, disjoint paths, and protection typ etc.). Then, the PCECC will calculate the optimal path based on the
e. In this OF and
step, we will have two paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3</t> given constraints (i.e., PST, BW, etc.). These constraints include
those from <xref target="RFC5376" format="default"/>, such as
<t>PCECC will use central control download priority, AS sequence, preferred ASBR, disjoint paths, and
instructions to the PCC based on the PST. At this stage, it is assumed the P protection type. In this step, we will have two paths:
CECC is aware "R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3".</t>
of the label space it controls and in the case of SR the SID allocation and </li>
distribution is already done.</t> <li>
<t>The PCECC will use central control download instructions to the P
<t>PCECC will send PCInitiate message <xref target="RFC8281"/> towards the ing CC
ress router R1 (PCC) in AS1 based on the PST. At this stage, it is assumed the PCECC is aware
and receive the PCRpt message <xref target="RFC8231"/> back from it. of the label space it controls, and in the case of SR, the SID
<list style="symbols"> allocation and distribution is already done.</t>
<t>If the PST is SR-MPLS, the PCECC will include the SID stack as per </li>
<xref target="RFC8664"/>. <li>
Optionally, a binding SID or BGP Peering-SID <xref target="RFC9087"/> can <t>The PCECC will send a PCInitiate message <xref target="RFC8281"
also be included on the AS boundary. The backup SID stack can be installed at i format="default"/> towards the ingress router R1 (PCC) in AS1 and
ngress R1 but more importantly, receive the PCRpt message <xref target="RFC8231"
each node along the SR path could also do the local protection just based format="default"/> back from it.
on the top segment.</t> </t>
<t>If the PST is PCECC, the PCECC will assign labels along the calculated <ul spacing="normal">
paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3) and sets up the <li>
path by sending central controller instructions in PCEP message to each node <t>If the PST is SR-MPLS, the PCECC will include the SID stack
along the path of the as per <xref target="RFC8664" format="default"/>. Optionally,
LSPs as per <xref target="RFC9050"/>. After these steps, the PCECC will send a BSID or BGP Peering-SID <xref target="RFC9087"
a PCUpd message to the ingress R1 router with information about new LSPs and R1 format="default"/> can also be included on the AS
will respond by PCRpt with LSP(s) status.</t></list></t> boundary. The backup SID stack can be installed at ingress R1,
but more importantly, each node along the SR path could also
<!--<t>AGG X as ingress router now have N LSPs towards AGG N and AGG N-1 do the local protection just based on the top segment.</t>
which are available for installing to router's forwarding table and load- </li>
balance a traffic <li>
between them. Traffic distribution between those LSPs depends on <t>If the PST is a PCECC, the PCECC will assign labels along the
particular realization of hash-function on that router.</t>--> calculated paths ("R1-ASBR1-ASBR3-R3", "R1-ASBR5-ASBR6-R3") and
sets up the path by sending central controller instructions in a
<t>After that step, R1 now have primary and backup TEs (LSP1 and LSP2) to PCEP message to each node along the path of the LSPs as per
wards <xref target="RFC9050" format="default"/>. After these steps,
R3. It is up to router implementation how to make switchover to backup LS the PCECC will send a PCUpd message to the ingress R1 router
P2 if LSP1 fails.</t> with information about new LSPs and R1 will respond by a PCRpt
with LSP(s) status.</t>
</list></t> </li>
</section> </ul>
</li>
<section title="PCECC for Multicast LSPs" anchor="sect-6"><t> <li>
<t>After that step, R1 now has primary and backup TEs (LSP1 and LSP2
) towards
R3. It is up to the router implementation for how to switchover to backup
LSP2 if LSP1 fails.</t>
</li>
</ul>
</section>
<section anchor="sect-6" numbered="true" toc="default">
<name>PCECC for Multicast LSPs</name>
<t>
The multicast LSPs can be set up via the RSVP-TE P2MP or The multicast LSPs can be set up via the RSVP-TE P2MP or
Multipoint LDP (mLDP) protocols. The setup of these LSPs may require Multipoint LDP (mLDP) protocols. The setup of these LSPs may require
manual configurations and complex signalling when the manual configurations and complex signalling when the
protection is considered. By using the PCECC solution, the multicast protection is considered. By using the PCECC solution, the multicast
LSP can be computed and set up through a centralized controller which LSP can be computed and set up through a centralized controller that
has the full picture of the topology and bandwidth usage for each has the full picture of the topology and BW usage for each
link. It not only reduces the complex configurations comparing the link. It not only reduces the complex configurations comparing the
distributed RSVP-TE P2MP or mLDP signalling, but also it can distributed RSVP-TE P2MP or mLDP signalling, but also it can
compute the disjoint primary path and secondary P2MP path efficiently.</t> compute the disjoint primary path and secondary P2MP path efficiently.</t>
<section title="PCECC for P2MP/MP2MP LSPs' Setup" anchor="sect-6.1"> <section anchor="sect-6.1" numbered="true" toc="default">
<!--<t> <name>PCECC for the Setup of P2MP/MP2MP LSPs</name>
With the capability of global label and local label existing at the
same time in the PCECC network, PCECC will use compute, setup and
maintain the P2MP and MP2MP lsp using the local label range for each
network nodes.</t>-->
<t>It is assumed the PCECC is aware of the label space it controls for <t>It is assumed the PCECC is aware of the label space it controls for
all nodes and makes allocations accordingly.</t> all nodes and makes allocations accordingly.</t>
<figure title="Using PCECC for P2MP/MP2MP LSPs' Setup" anchor="fig_p2mp"> <figure anchor="fig_p2mp">
<artwork><![CDATA[ <name>Using a PCECC for the Setup of P2MP/MP2MP LSPs</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+----------+ +----------+
| R1 | Root node of the multicast LSP | R1 | Root Node of the multicast LSP
+----------+ +----------+
|9000 (L0) |9000 (link0)
+----------+ +----------+
Transit Node | R2 | Transit Node | R2 |
branch +----------+ branch +----------+
* | * * * | * *
9001* | * *9002 9001* | * *9002
L1 * | * *L2 link1 * | * *link2
+-----------+ | * +-----------+ +-----------+ | * +-----------+
| R4 | | * | R5 | Transit Nodes | R4 | | * | R5 | Transit Nodes
+-----------+ | * +-----------+ +-----------+ | * +-----------+
* | * * + * | * * +
9003* | * * +9004 9003* | * * +9004
L3 * | * * +L4 link3 * | * * +link4
+-----------+ +-----------+ +-----------+ +-----------+
| R3 | | R6 | Leaf Node | R3 | | R6 | Leaf Node
+-----------+ +-----------+ +-----------+ +-----------+
9005| L5 9005| link5
+-----------+ +-----------+
| R8 | Leaf Node | R8 | Leaf Node
+-----------+ +-----------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The P2MP examples (based on <xref target="fig_p2mp"/>) are explained here, <t>The P2MP examples (based on <xref target="fig_p2mp" format="default
where R1 is the root and the router R8 and R6 are the leaves. "/>) are explained here, where R1 is the root and the routers R8 and R6 are the
<list style="symbols"> leaves.
<t>Based on the P2MP path computation request/delegation or PCE initiation, the </t>
PCECC <ul spacing="normal">
<li>
<t>Based on the P2MP path computation request/delegation or PCE in
itiation, the PCECC
receives the request with constraints and optimization criteria. </t> receives the request with constraints and optimization criteria. </t>
</li>
<t>PCECC will calculate the optimal P2MP path according to given constraints <li>
(i.e.bandwidth).</t> <t>The PCECC will calculate the optimal P2MP path according to giv
en constraints
<t>PCECC will provision each node along the path and assign incoming and outgoin (i.e., BW).</t>
g labels from R1 to {R6, R8} with the </li>
<li>
<t>The PCECC will provision each node along the path and assign in
coming and outgoing labels from R1 to {R6, R8} with the
path as "R1-L0-R2-L2-R5-L4-R6" and "R1-L0-R2-L1-R4-L3-R3-L5-R8": path as "R1-L0-R2-L2-R5-L4-R6" and "R1-L0-R2-L1-R4-L3-R3-L5-R8":
<list style="symbols"> </t>
<t>R1: Outgoing label 9000 on link L0</t> <ul spacing="normal">
<t>R2: Incoming label 9000 on link L0</t> <li>
<t>R2: Outgoing label 9001 on link L1 (*)</t> <t>R1: Outgoing label 9000 on link L0</t>
<t>R2: Outgoing label 9002 on link L2 (*)</t> </li>
<t>R5: Incoming label 9002 on link L2</t> <li>
<t>R5: Outgoing label 9004 on link L4</t> <t>R2: Incoming label 9000 on link L0</t>
<t>R6: Incoming label 9004 on link L4</t> </li>
<t>R4: Incoming label 9001 on link L1</t> <li>
<t>R4: Outgoing label 9003 on link L3</t> <t>R2: Outgoing label 9001 on link L1 (*)</t>
<t>R3: Incoming label 9003 on link L3</t> </li>
<t>R3: Outgoing label 9005 on link L5</t> <li>
<t>R8: Incoming label 9005 on link L5</t> <t>R2: Outgoing label 9002 on link L2 (*)</t>
</list></t> </li>
<li>
<t>This can also be represented as <t>R5: Incoming label 9002 on link L2</t>
: {R1, 6000}, {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {90 </li>
03, R3, 9005}, {9004, R6}, {9005, R8}. The main difference (*) <li>
is in the branch node instruction at R2 where two copies of a packet are sent <t>R5: Outgoing label 9004 on link L4</t>
towards R4 and R5 with 9001 and 9002 labels respectively.</t> </li>
<li>
</list></t> <t>R6: Incoming label 9004 on link L4</t>
<t>The packet forwarding involves - </li>
<list> <li>
<t> <t>R4: Incoming label 9001 on link L1</t>
Step 1: R1 sends a packet to R2 simply by pushing the label of </li>
9000 to the packet.</t> <li>
<t>R4: Outgoing label 9003 on link L3</t>
<t> </li>
Step 2: When R2 receives the packet with label 9000, it will <li>
forward it to R4 by swapping label 9000 to 9001 and at the same time, <t>R3: Incoming label 9003 on link L3</t>
it will replicate the packet and swap the label 9000 to 9002 and forward it t </li>
o R5.</t> <li>
<t>R3: Outgoing label 9005 on link L5</t>
<t> </li>
Step 3: When R4 receives the packet with label 9001, it will <li>
forward it to R3 by swapping 9001 to 9003. When R5 receives the <t>R8: Incoming label 9005 on link L5</t>
packet with the label 9002, it will forward it to R6 by swapping 9002 to </li>
9004.</t> </ul>
</li>
<t> <li>
Step 4: When R3 receives the packet with label 9003, it will <t>This can also be represented as: {R1, 6000}, {6000, R2,
forward it to R8 by swapping it to 9005 and when R5 receives the {9001, 9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3,
packet with label 9002, it will be swapped to 9004 and sent to R6.</t> 9005}, {9004, R6}, {9005, R8}. The main difference (*) is in the
branch node instruction at R2, where two copies of a packet are
<t>Step 5: When R8 receives the packet with label 9005, it will pop the label sent towards R4 and R5 with 9001 and 9002 labels, respectively.</t
; when R6 receives the packet with label 9004, it will pop the label.</t> >
</list></t> </li>
</section> </ul>
<t>The packet forwarding involves the following:</t>
<section title="PCECC for the End-to-End Protection of P2MP/MP2MP LSPs" <ol type="Step %d.">
anchor="sect-6.2"><t> <li>R1 sends a packet to R2 simply by pushing the label of 9000 to
In this section, the end-to-end managed path protection the packet.</li>
<li>When R2 receives the packet with label 9000, it will forward
it to R4 by swapping label 9000 to 9001. At the same time, it will
replicate the packet and swap the label 9000 to 9002 and forward
it to R5.</li>
<li>When R4 receives the packet with label 9001, it will forward
it to R3 by swapping 9001 to 9003. When R5 receives the packet
with the label 9002, it will forward it to R6 by swapping 9002 to
9004.</li>
<li>When R3 receives the packet with label 9003, it will forward
it to R8 by swapping it to 9005. When R5 receives the packet with
label 9002, it will be swapped to 9004 and sent to R6.</li>
<li>When R8 receives the packet with label 9005, it will pop the
label. When R6 receives the packet with label 9004, it will pop
the label.</li>
</ol>
</section>
<section anchor="sect-6.2" numbered="true" toc="default">
<name>PCECC for the End-to-End Protection of P2MP/MP2MP LSPs</name>
<t>
This section describes the end-to-end managed path protection
service as well as the local protection with the operation management in the service as well as the local protection with the operation management in the
PCECC network for the P2MP/MP2MP LSP.</t> PCECC network for the P2MP/MP2MP LSP.</t>
<t>
<t>
An end-to-end protection principle can be An end-to-end protection principle can be
applied for computing backup P2MP or MP2MP LSPs. During the computation applied for computing backup P2MP or MP2MP LSPs. During the computation
of the primary multicast trees, PCECC could also take the computation of a se condary tree into of the primary multicast trees, the PCECC could also take the computation of a secondary tree into
consideration. A PCECC could compute the consideration. A PCECC could compute the
primary and backup P2MP (or MP2MP) LSPs together or sequentially.</t> primary and backup P2MP (or MP2MP) LSPs together or sequentially.</t>
<figure anchor="fig_p2mp-res">
<figure title="PCECC for the End-to-End Protection of the P2MP/MP2MP LSPs <name>PCECC for the End-to-End Protection of P2MP/MP2MP LSPs</name>
" anchor="fig_p2mp-res"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+----+ +----+ +----+ +----+
Root node of LSP | R1 |--| R11| Root Node of LSP | R1 |--| R11|
+----+ +----+ +----+ +----+
/ + / +
10/ +20 10/ +20
/ + / +
+----------+ +-----------+ +----------+ +-----------+
Transit Node | R2 | | R3 | Transit Node | R2 | | R3 |
+----------+ +-----------+ +----------+ +-----------+
| \ + + | \ + +
| \ + + | \ + +
10| 10\ +20 20+ 10| 10\ +20 20+
| \ + + | \ + +
| \ + | \ +
| + \ + | + \ +
+-----------+ +-----------+ Leaf Nodes +-----------+ +-----------+ Leaf Nodes
| R4 | | R5 | (Downstream LSR) | R4 | | R5 | (Downstream LSR)
+-----------+ +-----------+ +-----------+ +-----------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In <xref target="fig_p2mp-res"/>, when the PCECC setups the primary multicast In <xref target="fig_p2mp-res" format="default"/>, when the PCECC sets up the
tree primary multicast tree
from the root node R1 to the leaves, which is R1-&gt;R2-&gt;{R4, R5}, at the from the root node R1 to the leaves, which is R1-&gt;R2-&gt;{R4, R5}, it can
same time, it can setup the backup tree, which is R1-&gt;R11-&gt;R3-&gt;{R4, set up the backup tree at the same time, which is R1-&gt;R11-&gt;R3-&gt;{R4, R5}
R5}. .
Both of them (primary forwarding tree and secondary forwarding Both of them (the primary forwarding tree and secondary forwarding
tree) will be downloaded to each router along the primary path and tree) will be downloaded to each router along the primary path and
the secondary path. The traffic will be forwarded through the the secondary path. The traffic will be forwarded through the
R1-&gt;R2-&gt;{R4, R5} path normally, but when a node in the R1-&gt;R2-&gt;{R4, R5} path normally, but when a node in the
primary tree fails (say R2) the root node R1 will switch the flow to the primary tree fails (say R2), the root node R1 will switch the flow to the
backup tree, which is R1-&gt;R11-&gt;R3-&gt;{R4, R5}. By using the PCECC a backup tree, which is R1-&gt;R11-&gt;R3-&gt;{R4, R5}. By using the PCECC,
path computation, label downloading and finally forwarding can be done path computation, label downloading, and finally forwarding can be done
without complex signalling used in the P2MP RSVP-TE or mLDP.</t> without the complex signalling used in the P2MP RSVP-TE or mLDP.</t>
</section>
</section> <section anchor="sect-6.3" numbered="true" toc="default">
<name>PCECC for the Local Protection of P2MP/MP2MP LSPs</name>
<section title="PCECC for the Local Protection of the P2MP/MP2MP LSPs" an <t>
chor="sect-6.3"><t>
In this section, we describe the local protection service in the PCECC In this section, we describe the local protection service in the PCECC
network for the P2MP/MP2MP LSP.</t> network for the P2MP/MP2MP LSP.</t>
<t>
<t>
While the PCECC sets up the primary multicast tree, it can also build While the PCECC sets up the primary multicast tree, it can also build
the backup LSP between the Point of Local Repair (PLR), the protected node an d Merge Points (MPs) (the downstream the backup LSP between the Point of Local Repair (PLR), protected node, and M erge Points (MPs) (the downstream
nodes of the protected node). In the cases where the amount of nodes of the protected node). In the cases where the amount of
downstream nodes is huge, this mechanism can avoid unnecessary downstream nodes is huge, this mechanism can avoid unnecessary
packet duplication on PLR and protect the network from traffic packet duplication on the PLR and protect the network from traffic
congestion risk.</t> congestion risks.</t>
<figure anchor="fig_p2mp-loc">
<figure title="PCECC for the Local Protection of the P2MP/MP2MP LSPs" anc <name>PCECC for the Local Protection of P2MP/MP2MP LSPs</name>
hor="fig_p2mp-loc"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+------------+ +------------+
| R1 | Root Node | R1 | Root Node
+------------+ +------------+
. .
. .
. .
+------------+ Point of Local Repair/ +------------+ Point of Local Repair /
| R10 | Switchover Point | R10 | Switchover Point
+------------+ (Upstream LSR) +------------+ (Upstream LSR)
/ + / +
10/ +20 10/ +20
/ + / +
+----------+ +-----------+ +----------+ +-----------+
Protected Node | R20 | | R30 | Protected Node | R20 | | R30 |
+----------+ +-----------+ +----------+ +-----------+
| \ + + | \ + +
| \ + + | \ + +
10| 10\ +20 20+ 10| 10\ +20 20+
| \ + + | \ + +
| \ + | \ +
| + \ + | + \ +
+-----------+ +-----------+ Merge Point +-----------+ +-----------+ Merge Point
| R40 | | R50 | (Downstream LSR) | R40 | | R50 | (Downstream LSR)
+-----------+ +-----------+ +-----------+ +-----------+
. . . .
. . . .
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In <xref target="fig_p2mp-loc"/>, when the PCECC setups the primary multicast In <xref target="fig_p2mp-loc" format="default"/>, when the PCECC sets up the
path primary multicast path
around the PLR node R10 to protect node R20, which is R10-&gt;R20-&gt;{R40, around the PLR node R10 to protect node R20, which is R10-&gt;R20-&gt;{R40,
R50}, at the same time, it can set up the backup path R10-&gt;R30-&gt;{R40, R50}, it can set up the backup path R10-&gt;R30-&gt;{R40,
R50}. Both the primary forwarding path and secondary bypass R50} at the same time. Both the primary forwarding path and the secondary by
pass
forwarding path will be downloaded to each router along the primary forwarding path will be downloaded to each router along the primary
path and the secondary bypass path. The traffic will be forwarded through path and the secondary bypass path. The traffic will be forwarded through
the R10-&gt;R20-&gt;{R40, R50} path normally and when there is a node the R10-&gt;R20-&gt;{R40, R50} path normally, and when there is a node
failure for node R20, the PLR node R10 will switch the flow to failure for node R20, the PLR node R10 will switch the flow to
the backup path, which is R10-&gt;R30-&gt;{R40, R50}. By using the PCECC, the backup path, which is R10-&gt;R30-&gt;{R40, R50}. By using the PCECC,
path computation, label downloading and finally forwarding can be done path computation, label downloading, and finally forwarding can be done
without complex signalling used in the P2MP RSVP-TE or mLDP.</t> without the complex signalling used in the P2MP RSVP-TE or mLDP.</t>
</section>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default">
</section> <name>PCECC for Traffic Classification</name>
<t>As described in <xref target="RFC8283" format="default"/>, traffic cl
<section title="PCECC for Traffic Classification" anchor="sect-7"> assification is an important part of traffic engineering.
<t>As described in <xref target="RFC8283"/>, traffic classification is an imp
ortant part of traffic engineering.
It is the process of looking into a packet to determine how it should It is the process of looking into a packet to determine how it should
be treated while it is forwarded through the network. It applies in be treated while it is forwarded through the network. It applies in
many scenarios including the following: many scenarios, including the following:
<list><t>MPLS traffic engineering (where it </t>
determines what traffic is forwarded into which LSPs),</t> <ul>
<t>Segment Routing (where it is used to select which set of forwarding <li>
instructions (SIDs) to add to a packet),</t> MPLS traffic engineering (where it determines what traffic is
<t>SFC (where it indicates how a packet should be forwarded across forwarded into which LSPs),
which service function path ).</t></list></t> </li>
<t>In conjunction with traffic engineering, traffic classification is an <li>
important enabler for load balancing. Traffic classification is closely linke SR (where it is used to select which set of
d to the computational forwarding instructions (SIDs) to add to a packet), and
</li>
<li>
SFC (where it indicates how a packet should be forwarded across
which service function path).
</li>
</ul>
<t>In conjunction with traffic engineering, traffic classification is an
important enabler for LB. Traffic classification is closely linked to the com
putational
elements of planning for the network functions because it elements of planning for the network functions because it
determines how traffic is balanced and distributed through the determines how traffic is balanced and distributed through the
network. Therefore, selecting what traffic classification mechanism should b e network. Therefore, selecting what traffic classification mechanism should b e
performed by a router is an important part of the work done by a performed by a router is an important part of the work done by a
PCECC.</t> PCECC.</t>
<t>The description of traffic flows by the combination of multiple Flow Speci
fication components and their dissemination as traffic flow specifications (Flow
Specifications) is described for BGP in <xref target="RFC8955"/>. When a PCECC
is used to initiate tunnels (such as TE-LSPs or SR paths) using PCEP, it is impo
rtant that the head end of the tunnels understands what traffic to place on each
tunnel. <xref target="RFC9168"/> specifies a set of extensions to PCEP to suppo
rt the dissemination of Flow Specification components where the instructions are
passed from the PCECC to the routers using PCEP.</t>
<t>
Along with traffic classification, there are a few more questions that need t
o be considered after path setup:
<list style="symbols"><t>how to use it</t>
<t>Whether it is a virtual link</t>
<t>Whether to advertise it in the IGP as a virtual link</t>
<t>What bits of this information to signal to the tail end</t>
</list> <t>The description of traffic flows by the combination of multiple Flow
</t> Specification components and their dissemination as traffic Flow Specifications
<t>These are out of the scope of this document.</t> is described for BGP in <xref target="RFC8955" format="default"/>. When a PCECC
is used to initiate tunnels (such as TE LSPs or SR paths) using PCEP, it is impo
rtant that the headend of the tunnels understands what traffic to place on each
tunnel. <xref target="RFC9168" format="default"/> specifies a set of extensions
to PCEP to support the dissemination of Flow Specification components where the
instructions are passed from the PCECC to the routers using PCEP.</t>
</section> <t>
Along with traffic classification, there are a few more questions about the t
unnels set up by the PCECC that need to be considered:
</t>
<ul spacing="normal">
<li>
<t>how to use it,</t>
</li>
<li>
<t>whether it is a virtual link,</t>
</li>
<li>
<t>whether to advertise it in the IGP as a virtual link, and</t>
</li>
<li>
<t>what bits of this information to signal to the tail end.</t>
</li>
</ul>
<t>These are out of the scope of this document.</t>
</section>
<section title="PCECC for SFC" anchor="sect-9" > <section anchor="sect-9" numbered="true" toc="default">
<t>Service Function Chaining (SFC) is described in <xref target="RFC7665"/>. <name>PCECC for SFC</name>
It is the process of directing <t>Service Function Chaining (SFC) is described in <xref target="RFC7665
" format="default"/>. It is the process of directing
traffic in a network such that it passes through specific hardware traffic in a network such that it passes through specific hardware
devices or virtual machines (known as service function nodes) that devices or virtual machines (known as service function nodes) that
can perform particular desired functions on the traffic. The set of can perform particular desired functions on the traffic. The set of
functions to be performed and the order in which they are to be functions to be performed and the order in which they are to be
performed is known as a service function chain. The chain is performed is known as a service function chain. The chain is
enhanced with the locations at which the service functions are to be enhanced with the locations at which the service functions are to be
performed to derive a Service Function Path (SFP). Each packet is performed to derive a Service Function Path (SFP). Each packet is
marked as belonging to a specific SFP, and that marking lets each marked as belonging to a specific SFP, and that marking lets each
successive service function node know which functions to perform and successive service function node know which functions to perform and
to which service function node to send the packet next. To operate an SFC net work, the service function nodes must be to which service function node to send the packet next. To operate an SFC net work, the service function nodes must be
configured to understand the packet markings, and the edge nodes must configured to understand the packet markings, and the edge nodes must
be told how to mark packets entering the network. Additionally, it be told how to mark packets entering the network. Additionally, it
may be necessary to establish tunnels between service function nodes may be necessary to establish tunnels between service function nodes
to carry the traffic. Planning an SFC network requires load balancing between service to carry the traffic. Planning an SFC network requires LB between service
function nodes and traffic engineering across the network that function nodes and traffic engineering across the network that
connects them. As per <xref target="RFC8283"/>, these are operations that ca connects them. As per <xref target="RFC8283" format="default"/>, these are o
n be performed by a perations that can be performed by a
PCE-based controller, and that controller can use PCEP to program the PCECC, and that controller can use PCEP to program the
network and install the service function chains and any required network and install the service function chains and any required
tunnels.</t> tunnels.</t>
<t>A possible mechanism could add support for SFC-based central control instr <t>A possible mechanism could add support for SFC-based central control
uctions. PCECC will be able to instruct each SFF along the SFP. instructions. The PCECC will be able to instruct each Service Function Forwarder
<list style="symbols"> (SFF) along the SFP.</t>
<t>Service Path Identifier (SPI): Uniquely identifies an SFP. </t> <ul>
<t>Service Index (SI): Provides location within the SFP.</t> <li>Service Path Identifier (SPI): Uniquely identifies an SFP.</li>
<t>SFC Proxy handling</t> <li>Service Index (SI): Provides location within the SFP.</li>
</list> <li>Provide SFC Proxy handling instruction.</li>
</t> </ul>
<t>PCECC can play the role of setting the traffic classification rules (as pe <t>The PCECC can play the role of setting the traffic classification rul
r <xref target="sect-7"/>) at the classifier to impose the Network Service Heade es (as per <xref target="sect-7" format="default"/>) at the classifier to impose
r (NSH) <xref target="RFC8300"/> as well as downloading the forwarding instructi the Network Service Header (NSH) <xref target="RFC8300" format="default"/>. It
ons to each SFF along the way so that they could process the NSH and forward acc can also download the forwarding instructions to each SFF along the way so that
ordingly. Including instructions for the service classifier that handles the con they could process the NSH and forward accordingly. This includes instructions f
text header, metadata etc. This metadata/context is shared amongst SFs and class or the service classifier that handles the context header, metadata, etc. This m
ifiers, between SFs, and between external systems (such as PCECC) and SFs. As de etadata/context is shared amongst SFs and classifiers, between SFs, and between
scribed in <xref target="RFC7665"/>, the SFC encapsulation enables the sharing o external systems (such as a PCECC) and SFs. As described in <xref target="RFC766
f metadata/context information along the SFP.</t> 5" format="default"/>, the SFC encapsulation enables the sharing of metadata/con
text information along the SFP.</t>
<t>It is also possible to support SFC with SR in conjunction with or without <t>It is also possible to support SFC with SR in conjunction with or wit
NSH such as <xref target="RFC9491"/> and <xref target="I-D.ietf-spring-sr-servic hout an NSH such as described in <xref target="RFC9491" format="default"/> and <
e-programming"/>. PCECC technique can also be used for service function-related xref target="I-D.ietf-spring-sr-service-programming" format="default"/>. PCECC t
segments and SR service policies. </t> echniques can also be used for service-function-related segments and SR service
policies. </t>
</section> </section>
<section title="PCECC for Native IP" anchor="sect-10" > <section anchor="sect-10" numbered="true" toc="default">
<t><xref target="RFC8735"/> describes the scenarios and simulation results f <name>PCECC for Native IP</name>
or
the "Centrally Control Dynamic Routing (CCDR)" solution, which
integrates the advantage of using distributed protocols (IGP/BGP) and the pow
er of a centralized control technology (PCE/SDN), providing traffic engineering
for native IP networks. <xref target="RFC8821"/> defines the framework for CCDR
traffic engineering
within a Native IP network, using multiple BGP sessions and a PCE as the cent
ralized controller. It requires the PCECC to send the instructions to the
PCCs, to build multiple BGP sessions, distribute different prefixes
on the established BGP sessions and assign the different paths to the
BGP next hops. PCEP protocol is used to transfer
the key parameters between PCE and the underlying network
devices (PCC) using the PCECC technique. The central control instructions fro
m PCECC to PCC will identify which prefix should be advertised on which BGP sess
ion. There are PCEP extensions defined in <xref target="I-D.ietf-pce-pcep-extens
ion-native-ip"/> for it.</t>
<figure title="PCECC for Native IP" anchor="fig_native_ip"><artwork>
<![CDATA[
+------+
+----------+ PCECC+-------+
| +------+ |
| |
PCEP | BGP Session 1(lo11/lo21)| PCEP
+-------------------------+
| |
| BGP Session 2(lo12/lo22)|
+-------------------------+
PF12 | | PF22
PF11 | | PF21
+---+ +-----+-----+ +-----+-----+ +---+
|SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+-----------+SW2|
+---+ | R1 +-------------+ R2 | +---+
+-----------+ +-----------+
]]>
</artwork></figure>
<t>In the case, as shown in <xref target="fig_native_ip"/>, PCECC will instruct
both R1 and R2 via PCEP how to form BGP sessions with each other and which IP pr
efixes
need to be advertised via which BGP session.</t>
</section>
<section title="PCECC for BIER" anchor="sect-11">
<t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> defines an
architecture where all intended multicast receivers are encoded as a
bitmask in the multicast packet header within different
encapsulations. A router that
receives such a packet will forward that packet based on the bit
position in the packet header towards the receiver(s) following a
precomputed tree for each of the bits in the packet. Each receiver
is represented by a unique bit in the bitmask.</t>
<t>BIER-TE <xref target="RFC9262"/> shares architecture and <t>
packet formats with BIER. BIER-TE forwards <xref target="RFC8735" format="default"/> describes the scenarios
and replicates packets based on a BitString in the packet header, but and simulation results for the "Centralized Control Dynamic Routing
every BitPosition of the BitString of a BIER-TE packet indicates one (CCDR)" solution, which integrates the advantage of using
or more adjacencies. BIER-TE paths can be derived from a PCE and used at the distributed protocols (IGP/BGP) and the power of a centralized
ingress ( a possible mechanism is described in <xref target="I-D.chen-pce-bier"/ control technology (PCE/SDN), providing traffic engineering for
>).</t> native IP networks. <xref target="RFC8821" format="default"/>
defines the framework for CCDR traffic engineering within a native
IP network, using multiple BGP sessions and a PCE as the centralized
controller. It requires the PCECC to send the instructions to the
PCCs to build multiple BGP sessions, distribute different prefixes
on the established BGP sessions, and assign the different paths to
the BGP next hops. The PCEP is used to transfer the key
parameters between the PCE and the underlying network devices (PCC)
using the PCECC technique. The central control instructions from
the PCECC to PCC will identify which prefix should be advertised on
which BGP session. There are PCEP extensions defined in <xref
target="I-D.ietf-pce-pcep-extension-native-ip" format="default"/>
for it.
</t>
<figure anchor="fig_native_ip">
<name>PCECC for Native IP</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+------+
+----------+ PCECC+-------+
| +------+ |
| |
PCEP | BGP Session 1(lo11/lo21)| PCEP
+-------------------------+
| |
| BGP Session 2(lo12/lo22)|
+-------------------------+
PF12 | | PF22
PF11 | | PF21
+---+ +-----+-----+ +-----+-----+ +---+
|SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+-----------+SW2|
+---+ | R1 +-------------+ R2 | +---+
+-----------+ +-----------+
]]></artwork>
</figure>
<t>In the case as shown in <xref target="fig_native_ip"
format="default"/>, the PCECC will instruct both R1 and R2 how to form B
GP
sessions with each other via PCEP and which IP prefixes need to be
advertised via which BGP session.</t>
</section>
<t>PCECC mechanism could be used for the allocation of bits for the BIER rout <section anchor="sect-11" numbered="true" toc="default">
er for BIER as well as for the adjacencies for BIER-TE. PCECC-based controllers <name>PCECC for BIER</name>
can use PCEP to instruct the BIER-capable routers on the meaning of the b <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"
its as well as other fields needed for BIER encapsulation. The PCECC could be us format="default"/> defines an architecture where all intended
ed to program the BIER router with various parameters used in the BIER encapsula multicast receivers are encoded as a BitMask in the multicast packet
tion such as BIER subdomain-ID, BFR-ID, BIER Encapsulation etc. for both node an header within different encapsulations. A router that receives such a
d adjacency.</t> packet will forward that packet based on the bit position in the
<t> A possible way for the PCECC usage and PCEP extension is described in <xref packet header towards the receiver(s) following a precomputed tree for
target="I-D.chen-pce-pcep-extension-pce-controller-bier"/>.</t> each of the bits in the packet. Each receiver is represented by a
unique bit in the BitMask.</t>
<t>BIER-TE <xref target="RFC9262" format="default"/> shares
architecture and packet formats with BIER. BIER-TE forwards and
replicates packets based on a BitString in the packet header, but
every BitPosition of the BitString of a BIER-TE packet indicates one
or more adjacencies. BIER-TE paths can be derived from a PCE and used
at the ingress (a possible mechanism is described in <xref
target="I-D.ietf-pce-bier-te" format="default"/>).</t>
</section> <t>The PCECC mechanism could be used for the allocation of bits for the
BIER router for BIER as well as for the adjacencies for
BIER-TE. PCECC-based controllers can use PCEP to instruct the
BIER-capable routers on the meaning of the bits as well as other
fields needed for BIER encapsulation. The PCECC could be used to
program the BIER router with various parameters used in the BIER
encapsulation (such as BIER sub-domain-id, BFR-id,
etc.) for both node and adjacency.</t>
</section> <t>A possible way to use the PCECC and PCEP extension is described in
<xref target="I-D.chen-pce-pcep-extension-pce-controller-bier"
format="default"/>.</t>
</section>
<section title="IANA Considerations" anchor="sect-12"><t> </section>
This document does not require any action from IANA.</t>
</section> <section anchor="sect-12" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section title="Security Considerations" anchor="sect-13"> <section anchor="sect-13" numbered="true" toc="default">
<t><xref target="RFC8283"/> describes how the security considerations for a <name>Security Considerations</name>
PCE-based controller are a little different from those for any other PCE system. <t><xref target="RFC8283" format="default"/> describes how the security
PCECC operations rely heavily on the use and security of PCEP, so considerations for a PCECC are a little different from
due consideration should be given to the security features discussed in those for any other PCE system. PCECC operations rely heavily on the
<xref target="RFC5440"/> and the additional mechanisms described in <xref tar use and security of PCEP, so due consideration should be given to the
get="RFC8253"/>. It further lists the vulnerability of a security features discussed in <xref target="RFC5440" format="default"/>
central controller architecture, such as a central point of failure, and the additional mechanisms described in <xref target="RFC8253"
denial of service, and a focus on interception and modification of format="default"/>. It further lists the vulnerability of a central
messages sent to individual Network Elements (NEs).</t> controller architecture, such as a central point of failure, denial of
<t>As per <xref target="RFC9050"/>, the use of service, and a focus on interception and modification of messages sent
Transport Layer Security (TLS) in PCEP is recommended, as it provides support to individual Network Elements (NEs).</t>
for <t>As per <xref target="RFC9050" format="default"/>, the use of
peer authentication, message encryption, and integrity. It further Transport Layer Security (TLS) in PCEP is recommended, as it provides
provides mechanisms for associating peer identities with different support for peer authentication, message encryption, and integrity. It
levels of access and/or authoritativeness via an attribute in X.509 further provides mechanisms for associating peer identities with
certificates or a local policy with a specific accept-list of X.509 different levels of access and/or authoritativeness via an attribute in
certificates. This can be used to check the authority for the PCECC X.509 certificates or a local policy with a specific accept-list of
operations.</t> X.509 certificates. This can be used to check the authority for the
<t>It is expected that each new document that is produced for a specific PCECC operations.</t>
use case will also include considerations of the security impacts of <t>It is expected that each new document that is produced for a specific
the use of a PCE-based central controller on the network type and use case will also include considerations of the security impacts of the
services being managed.</t> use of a PCECC on the network type and services
being managed.</t>
</section>
</section> </middle>
<section title="Acknowledgments" anchor="sect-14"><t> <back>
Thanks to Adrian Farrel, Aijun Wang, Robert Tao, <displayreference target="I-D.ietf-pce-pcep-extension-pce-controller-sr" to=
Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Elperin "PCECC-SR"/>
and Evgeniy Brodskiy for their useful comments and suggestions.</t> <displayreference target="I-D.ietf-pce-controlled-id-space" to="PCE-ID"/>
<t>Thanks to Mach Chen and Carlos Pignataro for the RTGDIR review. Thanks to <displayreference target="I-D.ietf-pce-stateful-interdomain" to="PCE-INTERDO
Derrell Piper for the SECDIR review. Thanks to Sue Hares for GENART review.</t> MAIN"/>
<t>Thanks to Vishnu Pavan Beeram for being the document shepherd and Jim Guic <displayreference target="I-D.cbrt-pce-stateful-local-protection" to="PCE-PR
hard for being the responsible AD.</t> OTECTION"/>
<t>Thanks to Roman Danyliw for the IESG review comments.</t> <displayreference target="I-D.ietf-mpls-seamless-mpls" to="MPLS-SEAMLESS"/>
<displayreference target="I-D.ietf-pce-bier-te" to="PCEP-BIER"/>
<displayreference target="I-D.ietf-spring-sr-service-programming" to="SR-SER
VICE"/>
<displayreference target="I-D.ietf-pce-segment-routing-policy-cp" to="PCEP-P
OLICY"/>
<displayreference target="I-D.chen-pce-pcep-extension-pce-controller-bier" t
o="PCECC-BIER"/>
<displayreference target="I-D.ietf-pce-pcep-extension-native-ip" to="PCEP-NA
TIVE"/>
<displayreference target="I-D.ietf-pce-pcep-extension-pce-controller-srv6" t
o="PCECC-SRv6"/>
</section> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54
40.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.76
65.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
281.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
283.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
402.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
195.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
328.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
209.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
036.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
985.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
206.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
456.xml"/>
<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.5
150.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
151.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.5
376.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
025.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
399.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
491.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
279.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
355.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
408.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
664.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
735.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
751.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
821.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
955.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
050.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
168.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
012.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
087.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
262.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
491.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
522.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
552.xml"/>
</middle> <!-- [I-D.ietf-pce-pcep-extension-pce-controller-sr] IESG state: I-D Exists as o
f 06/06/24-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
e-pcep-extension-pce-controller-sr.xml"/>
<back> <!-- [I-D.li-pce-controlled-id-space] IESG state: Replaced by draft-ietf-pce-con
trolled-id-space as of 06/06/24. -->
<reference anchor="I-D.ietf-pce-controlled-id-space" target="https://datatracker
.ietf.org/doc/html/draft-ietf-pce-controlled-id-space-00">
<front>
<title>
Path Computation Element Communication Protocol (PCEP) extension to advertise th
e PCE Controlled Identifier Space
</title>
<author fullname="Cheng Li" initials="C." surname="Li">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Hang Shi" initials="H." surname="Shi" role="editor">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Aijun Wang" initials="A." surname="Wang">
<organization>China Telecom</organization>
</author>
<author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
<organization>China Mobile</organization>
</author>
<author fullname="Chao Zhou" initials="C." surname="Zhou">
<organization>HPE</organization>
</author>
<date day="4" month="June" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-controlled-id-space-00"/
>
</reference>
<references title="Normative References"> <!-- [I-D.ietf-pce-stateful-interdomain] IESG state: Expired as of 06/06/24-->
<!--&RFC2119;--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
&RFC5440; e-stateful-interdomain.xml"/>
<!--&RFC8174;-->
&RFC7665;
&RFC8231;
&RFC8281;
&RFC8283;
&RFC8253;
&RFC8402; <!-- [I-D.cbrt-pce-stateful-local-protection] IESG state: Expired as of 06/06/24
</references> -->
<references title="Informative References"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-cbrt-pc
&RFC1195; e-stateful-local-protection.xml"/>
&RFC2328; <!-- [I-D.ietf-pce-segment-routing-ipv6] IESG state: RFC Ed Queue as
&RFC5340; of 06/06/24. Published as [RFC9603]. Updated reference and cite tags
&RFC3209; accordingly.-->
&RFC5036; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
603.xml"/>
&RFC3985; <!-- [I-D.ietf-mpls-seamless-mpls] IESG state: Expired (IESG: Dead) as of 06/06/
&RFC4206; 24. Added missing editor role to XML.-->
&RFC4364; <reference anchor="I-D.ietf-mpls-seamless-mpls" target="https://datatracker.ietf
&RFC4456; .org/doc/html/draft-ietf-mpls-seamless-mpls-07">
&RFC4655; <front>
&RFC5150; <title>Seamless MPLS Architecture</title>
&RFC5151; <author fullname="Nicolai Leymann" initials="N." surname="Leymann" role="editor"
&RFC5541; >
&RFC5376; <organization>Deutsche Telekom AG</organization>
&RFC7025; </author>
&RFC7399; <author fullname="Bruno Decraene" initials="B." surname="Decraene">
&RFC7432; <organization>Orange</organization>
&RFC7491; </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems</organization>
</author>
<author fullname="Maciek Konstantynowicz" initials="M." surname="Konstantynowicz
" role="editor">
<organization>Cisco Systems</organization>
</author>
<author fullname="Dirk Steinberg" initials="D." surname="Steinberg">
<organization>Steinberg Consulting</organization>
</author>
<date day="28" month="June" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-seamless-mpls-07"/>
</reference>
&RFC8279; <!-- [I-D.chen-pce-bier] IESG state: Replaced by draft-ietf-pce-bier-te as of 06
/06/24
Updated from "draft-chen-pce-bier" to "draft-ietf-pce-bier-te".-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
e-bier-te-00.xml"/>
&RFC8300; <!-- [I-D.ietf-spring-sr-service-programming] IESG state: I-D Exists as of 06/06
&RFC8355; /24-->
&RFC8408; <reference anchor="I-D.ietf-spring-sr-service-programming" target="https://datat
racker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-10">
<front>
<title>Service Programming with Segment Routing</title>
<author fullname="Francois Clad" initials="F." surname="Clad" role="editor">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Xiaohu Xu" initials="X." surname="Xu" role="editor">
<organization>China Mobile</organization>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Daniel Bernier" initials="D." surname="Bernier">
<organization>Bell Canada</organization>
</author>
<author fullname="Cheng Li" initials="C." surname="Li">
<organization>Huawei</organization>
</author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization>
</author>
<author fullname="Shaowen Ma" initials="S." surname="Ma">
<organization>Mellanox</organization>
</author>
<author fullname="Chaitanya Yadlapalli" initials="C." surname="Yadlapalli">
<organization>AT&amp;T</organization>
</author>
<author fullname="Wim Henderickx" initials="W." surname="Henderickx">
<organization>Nokia</organization>
</author>
<author fullname="Stefano Salsano" initials="S." surname="Salsano">
<organization>Universita di Roma "Tor Vergata"</organization>
</author>
<date day="23" month="August" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-service-programmin
g-10"/>
</reference>
&RFC8664; <!-- [I-D.ietf-pce-segment-routing-policy-cp] IESG state: I-D Exists as of 06/06
&RFC8735; /24-->
&RFC8751; <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
&RFC8754; e-segment-routing-policy-cp.xml"/>
&RFC8821;
&RFC8955;
&RFC8986;
&RFC9050;
&RFC9168;
&RFC9256;
&RFC9012;
&RFC9087;
&RFC9262;
&RFC9491;
&RFC9522;
&RFC9552;
&I-D.ietf-pce-pcep-extension-pce-controller-sr; <!-- [I-D.ietf-pce-binding-label-sid] Published as RFC 9604. Updated
&I-D.li-pce-controlled-id-space; reference and citation tags for [PCE-BINDING-LABEL-SID] to [RFC9604]. -->
&I-D.ietf-pce-stateful-interdomain; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
&I-D.cbrt-pce-stateful-local-protection; 604.xml"/>
&I-D.ietf-pce-segment-routing-ipv6;
&I-D.ietf-mpls-seamless-mpls;
&I-D.chen-pce-bier; <!-- [I-D.chen-pce-pcep-extension-pce-controller-bier] IESG state: Expired as of
&I-D.ietf-spring-sr-service-programming; 06/06/24-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-chen-pc
e-pcep-extension-pce-controller-bier.xml"/>
&I-D.ietf-pce-segment-routing-policy-cp; <!-- [I-D.ietf-pce-pcep-extension-native-ip] IESG state: Publication Requested a
s of 06/06/24-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
e-pcep-extension-native-ip.xml"/>
&I-D.ietf-pce-binding-label-sid; <!-- [I-D.dhody-pce-pcep-extension-pce-controller-srv6] IESG state:
&I-D.chen-pce-pcep-extension-pce-controller-bier; Replaced by draft-ietf-pce-pcep-extension-pce-controller-srv6 as of
&I-D.ietf-pce-pcep-extension-native-ip; 06/06/24. Updated URL and cite tag to use most current I-D. -->
&I-D.dhody-pce-pcep-extension-pce-controller-srv6; <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
e-pcep-extension-pce-controller-srv6.xml"/>
<reference anchor="MAP-REDUCE" target="http://leeky.me/publications/m <reference anchor="MAP-REDUCE" target="https://leeky.me/publications/map
apreduce_p2p.pdf"> reduce_p2p.pdf">
<front> <front>
<title>Parallel Processing Framework on a P2P System Using Map and R educe Primitives</title> <title>Parallel Processing Framework on a P2P System Using Map and R educe Primitives</title>
<author initials="K" surname="Lee" fullname="Kyungyong Lee"> <author initials="K" surname="Lee" fullname="Kyungyong Lee">
<organization /> <organization/>
</author> </author>
<author initials="T" surname="Choi" fullname="Tae Woong Choi"> <author initials="T" surname="Choi" fullname="Tae Woong Choi">
<organization /> <organization/>
</author> </author>
<author initials="A" surname="Ganguly" fullname="Arijit Ganguly"> <author initials="A" surname="Ganguly" fullname="Arijit Ganguly">
<organization /> <organization/>
</author> </author>
<author initials="D" surname="Wolinsky" fullname="David I. Wolinsky" > <author initials="D" surname="Wolinsky" fullname="David I. Wolinsky" >
<organization /> <organization/>
</author> </author>
<author initials="P" surname="Boykin" fullname="P.Oscar Boykin"> <author initials="P" surname="Boykin" fullname="P.Oscar Boykin">
<organization /> <organization/>
</author> </author>
<author initials="R" surname="Figueiredo" fullname="Renato Figueired o"> <author initials="R" surname="Figueiredo" fullname="Renato Figueired o">
<organization /> <organization/>
</author> </author>
<date month="may" year="2011" /> <date month="May" year="2011"/>
</front> </front>
<seriesInfo name="" value="" /> <seriesInfo name="DOI" value="10.1109/IPDPS.2011.315"/>
</reference> </reference>
<reference anchor="MPLS-DC" target="https://www.slideshare.net/DmitryAfana
siev1/yandex-nag201320131031"> <reference anchor="MPLS-DC" target="https://www.slideshare.net/DmitryAfa
<front> nasiev1/yandex-nag201320131031">
<front>
<title>MPLS in DC and inter-DC <title>MPLS in DC and inter-DC
networks: the unified forwarding mechanism for network networks: the unified forwarding mechanism for network
programmability at scale</title> programmability at scale</title>
<author initials="D" surname="Afanasiev" fullname="Dimitry Afanasiev "> <author initials="D" surname="Afanasiev" fullname="Dimitry Afanasiev ">
<organization /> <organization/>
</author> </author>
<author initials="D" surname="Ginsburg" fullname="Daniel Ginsburg"> <author initials="D" surname="Ginsburg" fullname="Daniel Ginsburg">
<organization /> <organization/>
</author> </author>
<date month="march" year="2014" /> <date month="March" year="2014"/>
</front> </front>
<seriesInfo name="" value="" /> </reference>
</reference>
</references> </references>
<section title="Other Use Cases of PCECC" anchor="sect-15"> </references>
<t>This section lists some more use cases of PCECC that were proposed by operato <section anchor="sect-15" numbered="true" toc="default">
rs and discussed within the working group, but are not in active development at <name>Other Use Cases of the PCECC</name>
the time of publication. They are listed here for future consideration.</t> <t>This section lists some more use cases of the PCECC that were proposed
<section title="PCECC for Network Migration" anchor="sect-15.1"><t> by operators and discussed within the working group but are not in active develo
pment at the time of publication. They are listed here for future consideration.
</t>
<section anchor="sect-15.1" numbered="true" toc="default">
<name>PCECC for Network Migration</name>
<t>
One of the main advantages of the PCECC solution is its backward One of the main advantages of the PCECC solution is its backward
compatibility. The PCE server can function as a compatibility. The PCE server can function as a
proxy node of the MPLS network for all the new nodes that no longer support proxy node of the MPLS network for all the new nodes that no longer support
the signalling protocols.</t> the signalling protocols.</t>
<t> <t>
As illustrated in the following example, the current network As illustrated in the following example, the current network
could migrate to a total PCECC-controlled network gradually by could migrate to a total PCECC-controlled network gradually by
replacing the legacy nodes. During the migration, the legacy nodes replacing the legacy nodes. During the migration, the legacy nodes
still need to use the existing MPLS protocols signalling such as LDP and still need to use the existing MPLS signalling protocols such as LDP and
RSVP-TE, and the new nodes will set up their portion of the forwarding path RSVP-TE, and the new nodes will set up their portion of the forwarding path
through PCECC directly. With the PCECC function as the proxy of through the PCECC directly. With the PCECC function as the proxy of
these new nodes, MPLS signalling can populate through the network for both: o these new nodes, MPLS signalling can populate through the network for both ol
ld and new nodes.</t> d and new nodes.</t>
<t>
<t>
The example described in this section is based on network configurations The example described in this section is based on network configurations
illustrated using <xref target="fig_mig"/>:</t> illustrated in <xref target="fig_mig" format="default"/>:</t>
<figure anchor="fig_mig">
<figure title="PCECC Initiated LSP Setup In the Network Migration" anchor="fig <name>PCECC-Initiated LSP Setup in the Network Migration</name>
_mig"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| PCE DOMAIN | | PCE DOMAIN |
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
| | PCECC | | | | PCECC | |
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
| ^ ^ ^ ^ | | ^ ^ ^ ^ |
| | PCEP | | PCEP | | | | PCEP | | PCEP | |
| V V V V | | V V V V |
| +--------+ +--------+ +--------+ +--------+ +--------+ | | +--------+ +--------+ +--------+ +--------+ +--------+ |
| | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | | | Node1 | | Node2 | | Node3 | | Node4 | | Node5 | |
| | |...| |...| |...| |...| | | | | |...| |...| |...| |...| | |
| | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | | | | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | |
| | Node | | Node | |Enabled | |Enabled | | Enabled| | | | Node | | Node | |Enabled | |Enabled | | Enabled| |
| +--------+ +--------+ +--------+ +--------+ +--------+ | | +--------+ +--------+ +--------+ +--------+ +--------+ |
| | | |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
In this example, there are five nodes for the TE LSP from the head end
(Node1) to the tail end (Node5). Where Node4 and Node5 are centrally
controlled and other nodes are legacy nodes.</t>
<t><list style="symbols"><t>Node1 sends a path request message for the setup o
f LSP
with the destination as Node5.</t>
<t>PCECC sends to Node1 a reply message for LSP setup with the path:
(Node1, if1),(Node2, if2), (Node3, if3), (Node4, if4), Node5.</t>
<t>Node1, Node2, and Node3 will set up the LSP to Node5 using the local
labels as usual. Node 3 with the help of PCECC could proxy the signalling.<
/t>
<t>Then the PCECC will program the out-segment of Node3, the in-segment/ <t>In this example, there are five nodes for the TE LSP from the headend
out-segment of Node4, and the in-segment for Node5.</t> (Node1) to the tail end (Node5), where Node4 and Node5 are
centrally controlled and other nodes are legacy nodes.</t>
</list> <ul spacing="normal">
</t> <li>
Node1 sends a path request message for the setup of the LSP
with the destination as Node5.
</li>
<li>
The PCECC sends a reply message to Node1 for LSP setup with the path
:
(Node1, if1), (Node2, if2), (Node3, if3), (Node4, if4), Node5.
</li>
<li>
Node1, Node2, and Node3 will set up the LSP to Node5 using the local
labels as usual. With the help of the PCECC, Node3 could proxy the si
gnalling.
</li>
<li>
Then, the PCECC will program the out-segment of Node3, the
in-segment/out-segment of Node4, and the in-segment for Node5.
</li>
</ul>
</section>
</section> <section anchor="sect-15.2" numbered="true" toc="default">
<name>PCECC for L3VPN and PWE3</name>
<section title="PCECC for L3VPN and PWE3" anchor="sect-15.2"> <t>As described in <xref target="RFC8283" format="default"/>, various
<t>As described in <xref target="RFC8283"/>, various network services may be network services may be offered over a network. These include
offered over a network. These protection services (including Virtual Private Network (VPN) services
include protection services (including such as L3VPN <xref target="RFC4364" format="default"/> or
Virtual Private Network (VPN) services (such as Layer 3 VPNs EVPNs <xref target="RFC7432" format="default"/>) or
<xref target="RFC4364"/> or Ethernet VPNs <xref target="RFC7432"/>); or Pseud pseudowires <xref target="RFC3985" format="default"/>. Delivering
owires <xref target="RFC3985"/>. services over a network in an optimal way requires coordination in the
Delivering services over a network in an optimal way requires way where network resources are allocated to support the services. A
coordination in the way where network resources are allocated to PCECC can consider the whole network and all
support the services. A PCE-based central controller can consider components of a service at once when planning how to deliver the
the whole network and all components of a service at once when service. It can then use PCEP to manage the network resources and to
planning how to deliver the service. It can then use PCEP to manage install the necessary associations between those resources.</t>
the network resources and to install the necessary associations
between those resources.</t>
<!--<t>
The existing services using MPLS LSP tunnels based on MPLS signaling
mechanism such L3VPN, PWE3 and IPv6 can be simplified by using the
PCECC for label assignments for the L3VPN, PWE3 and
IPv6 as well.</t>-->
<t> <t>
In the case of L3VPN, VPN labels could also be assigned and distributed In the case of L3VPN, VPN labels could also be assigned and distributed
through PCEP among the PE router instead of using the BGP through PCEP among the Provider Edge (PE) router instead of using the BGP
protocols.</t> protocols.</t>
<t>
<t>
The example described in this section is based on network configurations The example described in this section is based on network configurations
illustrated using <xref target="fig_l3vpn"/>:</t> illustrated in <xref target="fig_l3vpn" format="default"/>:</t>
<figure anchor="fig_l3vpn">
<figure title="PCECC for L3VPN and PWE3" anchor="fig_l3vpn"><artwork><![CDATA[ <name>PCECC for L3VPN and PWE3</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------------------------------------------+ +-------------------------------------------+
| PCE DOMAIN | | PCE DOMAIN |
| +-----------------------------------+ | | +-----------------------------------+ |
| | PCECC | | | | PCECC | |
| +-----------------------------------+ | | +-----------------------------------+ |
| ^ ^ ^ | | ^ ^ ^ |
|PWE3/L3VPN | PCEP PCEP|LSP PWE3/L3VPN|PCEP | | PWE3/L3VPN|PCEP PCEP|LSP PWE3/L3VPN|PCEP |
| V V V | | V V V |
+--------+ | +--------+ +--------+ +--------+ | +--------+ +--------+ | +--------+ +--------+ +--------+ | +--------+
| CE | | | PE1 | | NODE x | | PE2 | | | CE | | CE | | | PE1 | | Nodex | | PE2 | | | CE |
| |...... | |...| |...| |.....| | | |...... | |...| |...| |.....| |
| Legacy | |if1 | PCECC |if2|PCCEC |if3| PCECC |if4 | Legacy | | Legacy | |if1 | PCECC |if2|PCECC |if3| PCECC |if4 | Legacy |
| Node | | | Enabled| |Enabled | |Enabled | | | Node | | Node | | | Enabled| |Enabled | |Enabled | | | Node |
+--------+ | +--------+ +--------+ +--------+ | +--------+ +--------+ | +--------+ +--------+ +--------+ | +--------+
| | | |
+-------------------------------------------+ +-------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In the case of PWE3, instead of using the LDP signalling protocols, the In the case of PWE3, instead of using the LDP signalling protocols, the
label and port pairs assigned to each pseudowire can be assigned label and port pairs assigned to each pseudowire can be assigned
through PCECC among the PE routers and the corresponding forwarding through the PCECC among the PE routers and the corresponding forwarding
entries will be distributed into each PE router through the extended entries will be distributed into each PE router through the extended
PCEP and PCECC mechanism.</t> PCEP and PCECC mechanism.</t>
</section>
</section> <section anchor="sect-15.3" numbered="true" toc="default">
<section title="PCECC for Local Protection (RSVP-TE)" anchor="sect-15.3"> <name>PCECC for Local Protection (RSVP-TE)</name>
<t><xref target="I-D.cbrt-pce-stateful-local-protection"/> claim that there <t><xref target="I-D.cbrt-pce-stateful-local-protection" format="default
is a need for the PCE to maintain and associate the local protection paths for t "/> claims that there is a need for the PCE to maintain and associate the local
he RSVP-TE LSP. protection paths for the RSVP-TE LSP.
Local protection requires the setup of a bypass at the PLR. This Local protection requires the setup of a bypass at the PLR. This
bypass can be PCC-initiated and delegated, or PCE-initiated. In bypass can be PCC-initiated and delegated or PCE-initiated. In
either case, the PLR needs to maintain a PCEP session with the PCE. The Bypas either case, the PLR needs to maintain a PCEP session with the PCE. The bypas
s LSPs s LSPs
need to be mapped to the primary LSP. This could be done locally at the PLR b need to be mapped to the primary LSP. This could be done locally at the PLR b
ased on a local policy ased on a local policy,
but there is a need for a PCE to do the mapping as well to exert greater cont rol. </t> but there is a need for a PCE to do the mapping as well to exert greater cont rol. </t>
<t>This mapping can be done via PCECC procedures where the PCE could ins
<t>This mapping can be done via PCECC procedures where the PCE could instruct truct the PLR to the mapping and
the PLR to the mapping and
identify the primary LSP for which bypass should be used. identify the primary LSP for which bypass should be used.
</t> </t>
</section> </section>
<section title="Using reliable P2MP TE based multicast delivery for distribute <section anchor="sect-15.4" numbered="true" toc="default">
d computations (MapReduce-Hadoop)" anchor="sect-15.4"> <name>Using Reliable P2MP TE-Based Multicast Delivery for Distributed Co
<t> mputations (MapReduce-Hadoop)</name>
MapReduce model of distributed computations in computing clusters is
widely deployed. In <eref target="https://hadoop.apache.org/">Hadoop</eref> 1
.0 architecture MapReduce operations on
big data <!--performs by means of Master-Slave architecture-->in the Hadoop
Distributed File System (HDFS), where NameNode knows about
resources of the cluster and where actual data (chunks) for a particular
task are located (which DataNode). Each chunk of data (64MB or more)
should have 3 saved copies in different DataNodes based on their
proximity.</t>
<t> <t>
The proximity level currently has a semi-manual allocation and is based on The MapReduce model of distributed computations in computing clusters is
Rack IDs (The assumption is that closer data are better because of access widely deployed.
speed/smaller latency).</t>
<t> In <eref target="https://hadoop.apache.org/">Hadoop</eref> 1.0 architecture,
JobTracker node is responsible for computation tasks, and scheduling across MapReduce operations occur on big data in the Hadoop Distributed File System
DataNodes and also has Rack-awareness. Currently, transport protocols (HDFS), where
NameNode knows about resources of the cluster and where actual data
(chunks) for a particular task are located (which DataNode).
Each chunk of data (64 MB or more) should have three saved copies in
different DataNodes based on their proximity.</t>
<t>
The proximity level currently has a semi-manual allocation and is based on
Rack IDs (the assumption is that closer data is better because of access
speed / smaller latency).</t>
<t>
The JobTracker node is responsible for computation tasks and scheduling acros
s
DataNodes and also has Rack awareness. Currently, transport protocols
between NameNode/JobTracker and DataNodes are based on IP unicast. between NameNode/JobTracker and DataNodes are based on IP unicast.
It has simplicity as an advantage but has numerous drawbacks related to It has simplicity as an advantage but has numerous drawbacks related to
its flat approach.</t> its flat approach.</t>
<t>
<t> There is a need to go beyond one data center (DC) for Hadoop cluster
There is a need to go beyond one data centre (DC) for Hadoop cluster creation creation and move towards distributed clusters. In that case, one needs to
and move towards distributed clusters. In that case, one needs to handle handle performance and latency issues. Latency depends on the speed of
performance and latency issues. light in the fiber links and on the latency introduced by intermediate
Latency depends on the speed of light in the fibre links and on the latency devices in between. The latter is closely correlated with network device
introduced by intermediate devices in between. The latter is architecture and performance. The current performance of routers based on Ne
closely correlated with network device architecture and performance. twork Processing Unit (NPU)
The current performance of NPU-based routers should be enough for creating should be enough for creating distributed Hadoop clusters with predicted
distributed Hadoop clusters with predicted latency. The performance of softwa latency. The performance of software-based routers (mainly Virtual Network
re-based routers (mainly virtual network functions (VNF)) with additional hardwa Functions (VNFs)) with additional hardware features such as the Data Plane
re features such Development Kit (DPDK) is promising but requires additional research and
as the Data Plane Development Kit (DPDK) is promising but requires additional testing.</t>
research and testing.</t> <t>
<t>
The main question is how to create a simple but effective architecture for The main question is how to create a simple but effective architecture for
a distributed Hadoop cluster.</t> a distributed Hadoop cluster.</t>
<t>
<t> There is research <xref target="MAP-REDUCE" format="default"/> that shows
There is research <xref target="MAP-REDUCE"/> that show
how usage of the multicast tree could improve the speed of resource or cluste r how usage of the multicast tree could improve the speed of resource or cluste r
members' discovery inside the cluster as well as increased redundancy in members' discovery inside the cluster as well as increased redundancy in
communications between cluster nodes.</t> communications between cluster nodes.</t>
<t> <t>
The traditional IP-based multicast may not be appropriate because it The conventional IP-based multicast may not be appropriate because it
requires an additional control plane (IGMP, PIM) and a lot of signalling, tha requires an additional control plane (IGMP, PIM) and a lot of signalling, whi
t ch
is not suitable for high-performance computations, that are very sensitive is not suitable for high-performance computations that are very sensitive
to latency.</t> to latency.</t>
<t>
<t>
P2MP TE tunnels are more suitable as a potential solution for the creation P2MP TE tunnels are more suitable as a potential solution for the creation
of multicast-based communications between NameNode as root and DataNodes as l eaves inside the of multicast-based communications between NameNode as the root and DataNodes as leaves inside the
cluster. These P2MP tunnels could be dynamically created and cluster. These P2MP tunnels could be dynamically created and
turned down (with no manual intervention). Here, the PCECC comes into play wi th turned down (with no manual intervention). Here, the PCECC comes into play wi th
the main objective of creating an optimal topology for each particular reque st for the main objective of creating an optimal topology for each particular reque st for
MapReduce computation and creating P2MP tunnels with needed parameters MapReduce computation and creating P2MP tunnels with needed parameters
such as bandwidth and delay.</t> such as BW and delay.</t>
<t>
<t>
This solution will require the use of MPLS label-based forwarding inside the This solution will require the use of MPLS label-based forwarding inside the
cluster. The usage of label-based forwarding inside DC was proposed by Yandex cluster. The usage of label-based forwarding inside DC was proposed by Yandex
<xref target="MPLS-DC"/>. Technically it is already possible because MPLS on <xref target="MPLS-DC" format="default"/>. Technically, it is already possibl
switches e because MPLS on switches
is already supported by some vendors, MPLS also exists on Linux and OVS.</t> is already supported by some vendors, and MPLS also exists on Linux and Open
vSwitch (OVS).</t>
<t>A possible framework for this task is shown in <xref target="fig_mapred"/>: <t>A possible framework for this task is shown in <xref target="fig_mapr
</t> ed" format="default"/>:
</t>
<figure title="Using reliable P2MP TE based multicast delivery for distributed <figure anchor="fig_mapred">
computations (MapReduce-Hadoop)" anchor="fig_mapred"><artwork><![CDATA[ <name>Using Reliable P2MP TE-Based Multicast Delivery for Distributed
Computations (MapReduce-Hadoop)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------+
| APP | | APP |
+--------+ +--------+
| NBI (REST API,...) | NBI (REST API,...)
| |
PCEP +----------+ REST API PCEP +----------+ REST API
+---------+ +---| PCECC |----------+ +---------+ +---| PCECC |----------+
| Client |---|---| | | | Client |---|---| | |
+---------+ | +----------+ | +---------+ | +----------+ |
| | | | | | | | | | | |
skipping to change at line 1785 skipping to change at line 1915
| | | | | | | | | | | | | | | |
+-------------+ | | | | +----------+ +-------------+ | | | | +----------+
+------------------+ | +-----------+ +------------------+ | +-----------+
| | | | | | | |
|---+-----P2MP TE--+-----|-----------| | |---+-----P2MP TE--+-----|-----------| |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| DataNode1| | DataNode2| | DataNodeN| | DataNode1| | DataNode2| | DataNodeN|
|TaskTraker| |TaskTraker| .... |TaskTraker| |TaskTraker| |TaskTraker| .... |TaskTraker|
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
Communication between JobTracker, NameNode
and PCECC can be done via REST API directly or via
cluster manager such as Mesos.</t>
<t>
Phase 1: Distributed cluster resources discovery
During this phase, JobTracker and NameNode should identify and find available
DataNodes according to computing requests from the application (APP).
NameNode should query PCECC about available DataNodes, NameNode may
provide additional constraints to PCECC such as topological proximity,
and redundancy level.</t>
<t>
PCECC should analyze the topology of the distributed cluster and perform
constraint-based path calculation from the client towards the most
suitable NameNodes. PCECC should reply to NameNode with the list of the most
suitable DataNodes and their resource capabilities. The topology discovery
mechanism for PCECC will be added later to that framework.</t>
<t> <t>Communication between the JobTracker, NameNode, and PCECC can be done
Phase 2: PCECC should create P2MP LSP from the client towards those via REST API directly or via a cluster manager such as Mesos.</t>
DataNodes by means of PCEP messages following the previously calculated path. <ul>
</t> <li>
<t>
Phase 1: Distributed cluster resource discovery occurs during this
phase. JobTracker and NameNode should identify and find available
DataNodes according to computing requests from the application (APP).
NameNode should query the PCECC about available DataNodes, and NameNode ma
y
provide additional constraints to the PCECC such as topological proximity
and redundancy level.
</t>
<t>
The PCECC should analyze the topology of the distributed cluster and perfo
rm
a constraint-based path calculation from the client towards the most
suitable NameNodes. The PCECC should reply to NameNode with the list of th
e
most suitable DataNodes and their resource capabilities. The topology
discovery mechanism for the PCECC will be added later to that framework.
</t>
</li>
<li>
Phase 2: The PCECC should create P2MP LSPs from the client towards those
DataNodes by means of PCEP messages following the previously calculated
path.
</li>
<li>
Phase 3: NameNode should send this information to the client, and the PCECC
should inform the client about the optimal P2MP path towards DataNodes via a
PCEP message.
</li>
<li>
Phase 4: The client sends data blocks to those DataNodes for writing via
the created P2MP tunnel.
</li>
</ul>
<t>When this task is finished, the P2MP tunnel could be turned down.</t>
</section>
</section>
<t>Phase 3. NameNode should send this information to the client, and PCECC sho <section anchor="sect-14" numbered="false" toc="default">
uld inform <name>Acknowledgments</name>
the client about the optimal P2MP path towards DataNodes via PCEP message. <t>Thanks to <contact fullname="Adrian Farrel"/>, <contact
</t> fullname="Aijun Wang"/>, <contact fullname="Robert Tao"/>, <contact
fullname="Changjiang Yan"/>, <contact fullname="Tieying Huang"/>,
<contact fullname="Sergio Belotti"/>, <contact fullname="Dieter
Beller"/>, <contact fullname="Andrey Elperin"/>, and <contact
fullname="Evgeniy Brodskiy"/> for their useful comments and
suggestions.</t>
<t>Thanks to <contact fullname="Mach Chen"/> and <contact
fullname="Carlos Pignataro"/> for the RTGDIR review. Thanks to <contact
fullname="Derrell Piper"/> for the SECDIR review. Thanks to <contact
fullname="Sue Hares"/> for GENART review.</t>
<t>Thanks to <contact fullname="Vishnu Pavan Beeram"/> for being the
document shepherd and <contact fullname="Jim Guichard"/> for being the
responsible AD.</t>
<t>Thanks to <contact fullname="Roman Danyliw"/> for the IESG review
comments.</t>
</section>
<t> <section toc="default" numbered="false">
Phase 4. The Client sends data blocks to those DataNodes for writing via <name>Contributors</name>
the created P2MP tunnel.</t>
<t> <contact fullname="Luyuan Fang">
When this task is finished, the P2MP tunnel could be turned down.</t> <organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>United States of America</country>
</postal>
<email>luyuanf@gmail.com</email>
</address>
</contact>
</section> <contact fullname="Chao Zhou">
</section> <organization>HPE</organization>
<section title="Contributor Addresses" toc="default"> <address>
<t><figure align="left" alt="" height="" suppress-title="false" title="" <postal>
width=""> <street></street>
<artwork align="left" alt="" height="" name="" type="" width="" <city></city>
xml:space="preserve"><![CDATA[ <region></region>
<code></code>
<country></country>
</postal>
<email>chaozhou_us@yahoo.com</email>
</address>
</contact>
Luyuan Fang <contact fullname="Boris Zhang">
United States of America <organization>Amazon</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>zhangyud@amazon.com</email>
</address>
</contact>
Email: luyuanf@gmail.com <contact fullname="Artsiom Rachytski">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>Belarus</country>
</postal>
<email>arachyts@gmail.com</email>
</address>
</contact>
Chao Zhou <contact fullname="Anton Gulida">
HPE <organization>EPAM Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>Belarus</country>
</postal>
<email>Anton_Hulida@epam.com</email>
</address>
</contact>
</section>
Email: chaozhou_us@yahoo.com <!-- [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.
Boris Zhang a) For example, please consider whether "native" should be updated in the text
Amazon below:
Email: zhangyud@amazon.com Original:
Artsiom Rachytski Section 3.9. PCECC for Native IP
Belarus
Email: arachyts@gmail.com Figure 12: PCECC for Native IP
Anton Gulida ...traffic engineering for native IP networks. [RFC8821] defines the
EPAM Systems, Inc. framework for CCDR traffic engineering within a Native IP network...
Belarus -->
Email: Anton_Hulida@epam.com
]]></artwork>
</figure></t>
</section>
</back> </back>
</rfc>
</rfc>
 End of changes. 214 change blocks. 
1585 lines changed or deleted 1737 lines changed or added

This html diff was produced by rfcdiff 1.48.