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">
<!-- [auth]
<author fullname="Luyuan Fang" initials="L." surname="Fang">
<organization>Expedia, Inc.</organization> <organization>Expedia, Inc.</organization>
<address> <address>
<postal> <postal>
<street></street> <street></street>
<city></city> <city></city>
<region></region> <region></region>
<country>USA</country> <country>USA</country>
</postal> </postal>
<email>luyuanf@gmail.com</email> <email>luyuanf@gmail.com</email>
</address> </address>
skipping to change at line 222 skipping to change at line 143
<street>Krasnoarmeyskaya str., 24</street> <street>Krasnoarmeyskaya str., 24</street>
<city>Minsk</city> <city>Minsk</city>
<code>220030</code> <code>220030</code>
<region></region> <region></region>
<country>Belarus</country> <country>Belarus</country>
</postal> </postal>
<email>anton.gulida@life.com.by</email> <email>anton.gulida@life.com.by</email>
</address> </address>
</author> --> </author> -->
<date/> <date month="November" year="2024"/>
<workgroup>TEAS Working Group</workgroup> <area>RTG</area>
<abstract> <workgroup>teas</workgroup>
<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 <!-- [rfced] Please insert any keywords (beyond those that appear in
(TE) networks, and the PCE may be used to determine paths in a range the title) for use on https://www.rfc-editor.org/search. -->
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 <keyword>example</keyword>
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 <abstract>
currently no intention to publish this work as an RFC. [Update: Chairs are eval <t>The PCE is a core component of a Software-Defined Networking (SDN)
uating if the document should be published instead.]</t>--> system. It can be used to compute optimal paths for network traffic and
update existing paths to reflect changes in the network or traffic
demands. The PCE was developed to derive traffic-engineered (TE) 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 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>
<!-- [auth] <t>This is a living document to catalog the use cases for PCEC
C. There is currently no intention to publish this work as an RFC. [Update: Chai
rs are evaluating if the document should be published instead.]</t>-->
</abstract> </abstract>
<!--<note title="Requirements Language"> <!-- [auth] <note title="Requirements Language">
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the y appear in all 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the y appear in all
capitals, as shown here.</t> capitals, as shown here.</t>
</note>--> </note>-->
</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
oad
the path computation function from routers in an MPLS traffic-engineered (TE) network. It can compute optimal paths for traffic the path computation function from routers in an MPLS traffic-engineered (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"/> introduces the architecture for the PCE as a central <!--[rfced] The text below suggests that RFC 8283 (rather than a person)
controller as an extension to the architecture described in <xref target="RFC can "assume" something. Since we try to avoid the personification of RFCs,
4655"/> may we rephrase the text as shown below for clarity?
Original:
[RFC8283] introduces the architecture for the PCE as a central
controller as an extension to the architecture described in [RFC4655]
and assumes the continued use of PCEP as the protocol used between and assumes the continued use of PCEP as the protocol used between
the PCE and PCC. <xref target="RFC8283"/> further examines the motivations a the PCE and PCC.
nd
Perhaps:
[RFC8283] introduces the architecture for the PCE as a central
controller and as an extension to the architecture described in [RFC4655].
It is assumed that PCEP continues to be used as the protocol between
the PCE and PCC.
-->
<t><xref target="RFC8283" format="default"/> introduces the architecture f
or the PCE as a central
controller as an extension to the architecture described in <xref target="RFC
4655" format="default"/>
and assumes the continued use of PCEP as the protocol used between
the PCE and Path Computation Client (PCC). <xref target="RFC8283" format="de
fault"/> further 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>
<!-- [auth] <t>
<!--<t>
An Architecture for Use of PCE and PCEP <xref target="RFC5440"/> in a Networ k with Central An Architecture for Use of PCE and PCEP <xref target="RFC5440"/> in a Networ k with Central
Control <xref target="RFC8283"/> describes a Control <xref target="RFC8283"/> describes a
SDN architecture where the Path Computation Element (PCE) determines SDN architecture where the Path Computation Element (PCE) determines
the paths for variety of different usecases, with PCEP as a general southboun d the paths for variety of different usecases, with PCEP as a general southboun d
communication protocol with all the nodes along the path.</t>--> communication protocol with all the nodes along the path.</t>-->
<t><xref target="RFC9050"/> introduces the procedures and <t><xref target="RFC9050" format="default"/> introduces the procedures and
extensions for PCEP to support the PCECC architecture <xref target="RFC8283"/ extensions for PCEP to support the PCECC architecture <xref target="RFC8283"
>.</t> format="default"/>.</t>
<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>
<!-- [auth] <t>This is a living document to catalog the use cases for PCEC
<!--<t>This is a living document to catalog the use cases for PCECC. There i C. There is currently no intention to publish this work as an RFC. [Update: Chai
s currently no intention to publish this work as an RFC. [Update: Chairs are eva rs are evaluating if the document should be published instead.]</t>-->
luating if the document should be published instead.]</t>-->
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
<section title="Terminology" anchor="sect-2"> <!--[rfced] FYI - We have ordered the list of terms in Section 2 alphabetically.
<t> Please let us know of any objections.
The following terminology is used in this document. -->
<list style="hanging" hangIndent="0">
<t hangText="BGP-LS:">
Border Gateway Protocol - Link State <xref target="RFC9552"/>.
</t>
<t hangText="LSP:">
Label Switched Path.
</t>
<t hangText="IGP:">
Interior Gateway Protocol. In the document, we assume either Open Shortes
t Path First (OSPF) <xref target="RFC2328"/><xref target="RFC5340"/> or Intermed
iate System
to Intermediate System (IS-IS) <xref target="RFC1195"/> as IGP.
</t>
<t hangText="PCC:">
Path Computation Client. As per <xref target="RFC4655"/>, any client appl
ication requesting a
path computation to be performed by a Path Computation Element.
</t>
<t hangText="PCE:">
Path Computation Element. As per <xref target="RFC4655"/>, an entity (com
ponent, application,
or network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
</t>
<t hangText="PCECC:">
PCE as a Central Controller. Extension of PCE to support SDN functions as per
<xref target="RFC8283"/>.
</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 <name>Terminology</name>
rted via BGP instead of PCEP. However, within the scope of this document, the fo <t>
cus is on the use of PCEP.</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="PCECC for Label Management" anchor="sect-3"> <name>Use Cases</name>
<t>As per <xref target="RFC8283"/>, in some cases, the PCE-based controller <t><xref target="RFC8283" format="default"/> describes various use cases f
can take responsibility for or a PCECC such as:
</t>
<ul spacing="normal">
<li>
use of a PCECC to set up static TE LSPs (the PCEP extension for this u
se case is in <xref target="RFC9050" format="default"/>)
</li>
<li>
use of a PCECC in Segment Routing <xref target="RFC8402" format="defau
lt"/>
</li>
<li>
use of a PCECC to set up Multicast Point-to-Multipoint (P2MP) LSPs
</li>
<li>
use of a PCECC to set up Service Function Chaining (SFC) <xref target=
"RFC7665" format="default"/>
</li>
<li>
use of a PCECC in optical networks
</li>
</ul>
<t><xref target="sect-3" format="default"/> describes the general case of
a PCECC being in charge of
managing MPLS label space, which is a prerequisite for further use cas
es.
Further, various use cases (SR, Multicast, etc.) are described in the
following sections to showcase scenarios that can benefit from the use of a PCEC
C.
</t>
<t>It is interesting to note that some of the use cases listed can also be
supported via BGP instead of PCEP. However, within the scope of this document,
the focus is on the use of PCEP.</t>
<section anchor="sect-3" numbered="true" toc="default">
<name>PCECC for Label Management</name>
<t>As per <xref target="RFC8283" format="default"/>, 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 PCE-based controller 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 <!--[rfced] FYI - We have updated the text below for clarity. Please
CECC review and let us know if this has changed the intended meaning.
architecture could be used as a means to learn the label space of nodes, and
could also be used to
determine and provision the global label range.</t>
<!--<t> Original:
Further, there have been proposals for a global label range in MPLS,
the PCECC architecture could be used as a means to learn the label
space of nodes, and could also be used to determine and provision the
global label range.
Current:
Further, there have been proposals for a global label range in MPLS
as well as PCECC architecture being used as a means to learn the label
space of nodes and being used to determine and provision the global
label range.
-->
<t>Further, there have been proposals for a global label range in MPLS a
s well as PCECC
architecture being used as a means to learn the label space of nodes and bei
ng used to
determine and provision the global label range.</t>
<!-- [auth] <t>
This use case is based on network configuration illustrated using This use case is based on network configuration illustrated using
the following figure:</t>--> the following figure:</t>-->
<figure title="PCECC for MPLS Label Management" anchor="fig_label"><artwo <figure anchor="fig_label">
rk><![CDATA[ <name>PCECC for MPLS Label Management</name>
<artwork name="" type="" align="left" alt=""><![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| | | |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| |
| | | ...... | | | | | | ...... | | | | | | ...... | | | | | | ...... | | |
| | 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
ill advertise the PCECC capability to the PCE central
controller (PCECC) <xref target="RFC9050"/>.</t>
<t>The PCECC could also learn the label range set aside by the PCC (via < <!-- [rfced] Should an introductory sentence be added to the list that appears
xref target="I-D.li-pce-controlled-id-space"/>). </t> after Figure 1 to provide context for the proceeding text?
<t>Optionally, the PCECC could determine the shared MPLS global label range fo
r the network.
<list style="symbols">
<t>In the case that the shared global label range needs to be
negotiated across multiple domains, the central controllers of
these domains will also need to negotiate a common global
label range across domains.</t>
<t>The PCECC will need to set the shared global label Original:
range to all PCC nodes in the network.</t>
</list></t>
</list> Figure 1: PCECC for MPLS Label Management
</t>
<t>As per <xref target="RFC9050"/>, PCECC could also rely on the PCC to make l
abel allocations initially and use PCEP to distribute it to where it is needed.<
/t>
</section> * As shown in Figure 1, PCC will advertise the PCECC capability to
the PCE central controller (PCECC) [RFC9050].
<section title="PCECC and Segment Routing" anchor="sect-4"> * The PCECC could also learn the label range set aside by the PCC
<t>Segment Routing (SR) <xref target="RFC8402"/> leverages the source routin (via [I-D.li-pce-controlled-id-space]).
g paradigm. Using
SR, a source node steers a packet through a path without relying on
hop-by-hop signalling protocols such as LDP <xref target="RFC5036"/> or RSVP-
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 Perhaps:
SR-specific PCEP extension for SR-MPLS. PCECC may further use PCEP protocol
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> Figure 1: PCECC for MPLS Label Management
As shown in Figure 1:
* PCC will advertise the PCECC capability to
the PCE central controller (PCECC) [RFC9050].
* The PCECC could also learn the label range set aside by the PCC
(via [I-D.li-pce-controlled-id-space]).
-->
<ul spacing="normal">
<li>
<t>As shown in <xref target="fig_label" format="default"/>, the PCC
will advertise the PCECC capability to the PCECC <xref target="RFC9
050" format="default"/>.</t>
</li>
<li>
<t>The PCECC could also learn the label range set aside by the PCC
(via <xref target="I-D.ietf-pce-controlled-id-space"
format="default"/>).</t>
</li>
<li>
<t>Optionally, the PCECC could determine the shared MPLS global
label range for the network.</t>
<ul spacing="normal">
<li>
<t>In the case that the shared global label range needs to be
negotiated across multiple domains, the central controllers of
these domains will also need to negotiate a common global
label range across domains.</t>
</li>
<li>
<t>The PCECC will need to set the shared global label range to
all PCC nodes in the network.</t>
</li>
</ul>
</li>
</ul>
<t>As per <xref target="RFC9050" format="default"/>, the PCECC could als
o
rely on the PCC to make label allocations initially and use PCEP to
distribute it to where it is needed.</t>
</section>
<section anchor="sect-4" numbered="true" toc="default">
<name>PCECC and Segment Routing</name>
<t>Segment Routing (SR) <xref target="RFC8402" format="default"/>
leverages the source routing paradigm. Using SR, a source node steers
a packet through a path without relying on hop-by-hop signalling
protocols such as LDP <xref target="RFC5036" format="default"/> or
RSVP-TE <xref target="RFC3209" format="default"/>. 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 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 protocol 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>
<!-- [auth] <t>
For the centralized network, the performance achieved through For the centralized network, the performance achieved through
distributed system can not be easy matched if all of the forwarding distributed system can not be easy matched if all of the forwarding
paths are computed, downloaded and maintained by the centralized paths are computed, downloaded and maintained by the centralized
controller. The performance can be improved by supporting part of controller. The performance can be improved by supporting part of
the forwarding path in the PCECC network through the segment routing the forwarding path in the PCECC network through the segment routing
mechanism except that node segment IDs and adjacency segment IDs for mechanism except that node segment IDs and adjacency segment IDs for
all the network are allocated dynamically and propagated through the all the network are allocated dynamically and propagated through the
centralized controller instead of using the IGP extensions.</t>--> centralized controller instead of using the IGP extensions.</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 539
* | * * + * | * * +
* | * * + * | * * +
+-----------+ +-----------+ +-----------+ +-----------+
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
xtension-pce-controller-sr" format="default"/>.</t>
</section>
<section anchor="sect-4.2" numbered="true" toc="default">
<name>PCECC for SR-MPLS Best Effort (BE) Paths</name>
<t>These mechanisms are described in <xref target="I-D.ietf-pce-pcep-extensio <!-- [rfced] Section 3.2.2 begins with the text below; how may we rephrase to
n-pce-controller-sr"/>.</t> clarify what "this use case" refers to?
</section>
<section title="PCECC for SR-MPLS Best Effort (BE) Path" anchor="sect-4.2
"><t>
In this use case, the PCECC needs to allocate the
Node-SID (without calculating the explicit
path for the SR path). The ingress router of the forwarding path needs
to encapsulate the destination Node-SID on top of the packet.
All the intermediate nodes will forward the packet based on the
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 Original:
segment {1008} (Node-SID for R8). The path will be based on the routing/nexth
op calculation on the routers.</t>
</section> 3.2.2. PCECC for SR-MPLS Best Effort (BE) Path
<section title="PCECC for SR-MPLS TE Path" anchor="sect-4.3"> In this use case, the PCECC needs to allocate the Node-SID (without
calculating the explicit path for the SR path).
<t>SR-TE paths may not follow an IGP shortest path tree (SPT). S Perhaps:
uch paths may be chosen by a
PCECC and provisioned on the ingress node of the SR-TE path. The SR
header consists of a list of SIDs (or MPLS labels). The header has
all necessary information so that the packets can be guided from the
ingress node to the egress node of the path. Hence, there is no need
for any signalling protocol. For the case where a strict traffic
engineering path is needed, all the Adj-SID are stacked,
otherwise, a combination of node-SID or adj-SID can be used for the
SR-TE paths.</t>
<t>As shown in <xref target="fig-sr-te"/>, R1 may send a packet to R8 by pushing 3.2.2. PCECC for SR-MPLS Best Effort (BE) Path
an SR header with segment
list {1002, 9001, 1008}. Where 1002 and 1008 are the Node-SID of R2 and R8 re
spectively. 9001 is the Adj-SID for link1. The path should be: R1-R2-link1-R3-R8
.</t>
<t> When using PCECC for SR-MPLS Best Effort (BE) Paths, the PCECC needs to
To achieve this, the PCECC first allocates and distributes SIDs as allocate the Node-SID (without calculating the explicit path for the SR path
described in <xref target="sect-4.1"/>. <xref target="RFC8664"/> describes t ).
he -->
mechanism for a PCE to
compute, update, or initiate SR-MPLS TE paths. </t>
<figure title="PCECC TE LSP Setup Example" anchor="fig-sr-te"><artwork><! <t>
[CDATA[ In this use case, the PCECC needs to allocate the
Node-SID (without calculating the explicit
path for the SR path). The ingress router of the forwarding path needs
to encapsulate the destination Node-SID on top of the packet.
All the intermediate nodes will forward the packet based on the
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
segment {1008} (Node-SID for R8). The path will be based on the routing / nex
t hop calculation on the routers.</t>
</section>
<section anchor="sect-4.3" numbered="true" toc="default">
<name>PCECC for SR-MPLS TE Paths</name>
<t>
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
of the SR-TE path. The SR header consists of a list of SIDs (or
MPLS labels). The header has all necessary information so that
the packets can be guided from the ingress node to the egress node
of the path. Hence, there is no need for any signalling protocol.
For the case where a strict traffic engineering path is needed,
all the Adj-SIDs are stacked; otherwise, a combination of Node-SIDs
or Adj-SIDs can be used for the SR-TE paths.</t>
<t>
As shown in <xref target="fig-sr-te" format="default"/>, R1 may
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
R8, respectively. 9001 is the Adj-SID for link1. The path should
be: R1-R2-link1-R3-R8.</t>
<t>
To achieve this, the PCECC first allocates and distributes SIDs as
described in <xref target="sect-4.1" format="default"/>. <xref
target="RFC8664" format="default"/> describes the mechanism for a
PCE to compute, update, or initiate SR-MPLS TE paths.
</t>
<figure anchor="fig-sr-te">
<name>PCECC TE LSP Setup Example</name>
<artwork name="" type="" align="left" alt=""><![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 644
* | * + * | * +
+-----------+ +-----------+ +-----------+ +-----------+
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 <t>
(e.g. bandwidth). </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>
<t> PCECC will provision SR-MPLS TE LSP (path R1-link1-R2-link6-R3-R8) at the in <ul spacing="normal">
gress node: {90011,1002,90026,1003,1008}</t> <li>
<t>For the end-to-end protection, PCECC can provision the secondary path (R1-lin <t>The SID allocation and distribution are done by the PCECC with
k2-R2-link4-R5-R8): {90012,1002,90024,1005,1008}.</t> 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).</t>
</li>
<li>
<t>The PCECC will provision the SR-MPLS TE LSP path (R1-link1-R2-l
ink6-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>
</list></t> <section anchor="sect-4.4" numbered="true" toc="default">
<name>PCECC for SR Policy</name>
<section title="PCECC for SR Policy" anchor="sect-4.4"> <t><xref target="RFC8402" format="default"/> defines Segment
Routing architecture, which uses an SR Policy to steer packets
from a node through an ordered list of segments. The SR Policy
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 delivery from the PCE to PCC. </t
>
<t><xref target="RFC8402"/> defines Segment Routing architecture, which uses an <t>An SR Policy architecture is described in <xref
SR Policy target="RFC9256" format="default"/>. An SR Policy is a framework
to steer packets from a node through an ordered list of segments. The SR Poli that enables the instantiation of an ordered list of segments on a
cy could be node for implementing a source routing policy for the steering of
configured on the headend or instantiated by an SR controller. traffic for a specific purpose (e.g., for a specific Service Level A
The SR architecture does not restrict how the controller programs the greement (SLA)) from that
network. In this case, the focus is on PCEP as the protocol for SR Policy del node.</t>
ivery from PCE to PCC. </t>
<t>An SR Policy architecture is described in <xref target="RFC9256"/>. An SR <t>An SR Policy is identified through the tuple &lt;headend,
Policy is a framework that enables the color, endpoint&gt;.</t>
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 SLA) from that node.</t>
<t>An SR Policy is identified through the tuple &lt;headend, color, <t><xref target="fig-sr-te" format="default"/> is used as an
endpoint&gt;. </t> example of PCECC application for SR Policy instantiation for
SR-MPLS, where the Node-SIDs are 100x and the Adj-SIDs are 900xx.</t>
<t><xref target="fig-sr-te"/> is used as an example of PCECC application for S <t>Let's assume that R1 needs to have two disjoint SR Policies
R Policy instantiation for SR-MPLS, where, 100x - are Node-SIDs and 900xx - are towards R8 based on different bandwidths. This means the possible pa
Adj-SIDs.</t> ths
are:</t>
<t>Let's assume that R1 needs to have two disjoint SR Policies towards R8 bas <ul>
ed on different bandwidths, the possible paths are: <li>
<list> POL1: {Headend R1, color 100, Endpoint R8; Candidate Path1: Segm
<t>POL1: {Headend R1, color 100, Endpoint R8; Candidate Path1: Segment List 1 ent List 1: {90011,1002,90023,1004,1003,1008}}
: {90011,1002,90023,1004,1003,1008}}</t> </li>
<t>POL2: {Headend R1, color 200, Endpoint R8; Candidate Path1: Segment List 1 <li>
: {90012,1002,90024,1005,1006,1008}}</t> POL2: {Headend R1, color 200, Endpoint R8; Candidate Path1: Segm
</list></t> ent List 1: {90012,1002,90024,1005,1006,1008}}
<t>Each SR Policy (including candidate path and segment list) will be signall </li>
ed to a headend (R1) via PCEP <xref target="I-D.ietf-pce-segment-routing-policy </ul>
-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>Each SR Policy (including the candidate path and segment list) wi
<t> PCECC allocates Node-SIDs and Adj-SIDs using the mechanism described in < ll
xref target="sect-4.1"/> for all nodes and links. </t> be signalled to a headend (R1) via PCEP <xref
<t> PCECC will calculate disjoint paths for POL1 and POL2 and create Segment target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/>
Lists for them:{90011,1002,90023,1004,1003,1008};{90012,1002,90024,1005,1006,100 with the addition of an ASSOCIATION object. A Binding SID (BSID)
8}.</t> <xref target="RFC8402" format="default"/> can be used for traffic
<t> PCECC will form both SR Policies POL1 and POL2.</t> steering of labelled traffic into an SR Policy; a BSID can be
<t> PCECC will send both POL1 and POl2 to R1 via PCEP. </t> provisioned from the PCECC also via PCEP <xref target="RFC9604"
<t> PCECC optionally can allocate BSIDs for the SR Policies.</t> 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>
<t>The traffic from R1 to R8 which fits to color 100 will be steered to POL1 <t>The procedure is as follows:</t>
and follows the path: R1-link1-R2-link3-R4-R3-R8. The traffic from R1 to R8 whic <ul>
h fits color 200 <li>
will be steered to POL2 and follows the path: R1-link2-R2-link4-R5-R6-R8. Due The PCECC allocates Node-SIDs and Adj-SIDs using the mechanism d
to the possibility of having many Segment Lists in the same Candidate Path of e escribed in <xref target="sect-4.1" format="default"/> for all nodes and links.
ach POL1/POL2, </li>
PCECC could provision more paths towards R8 and traffic will be balanced eith <li>
er as ECMP or as w/ECMP. This is the advantage of SR Policy architecture. </t> The PCECC calculates disjoint paths for POL1 and POL2 and create
</list></t> segment lists for them: {90011,1002,90023,1004,1003,1008};{90012,1002,90024,100
5,1006,1008}.
</li>
<li>
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>
<t>Note that an SR Policy can be associated with multiple candidate paths. A <!-- [rfced] For clarity, can "w/ECMP" be updated to "with ECMP" in the text
candidate path is selected when it is valid and it is determined to be the best below?
path of the SR Policy as described in <xref target="RFC9256"/>.</t>
</section> Original:
</section>
<section title="PCECC for SRv6" anchor="sect-8">
<t>As per <xref target="RFC8402"/>, with Segment Routing (SR),
a node steers a packet through an ordered list of instructions,
called segments. Segment Routing
can be applied to the IPv6 architecture with the Segment Routing
Header (SRH) <xref target="RFC8754"/>. 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"/>, an SRv6 Segment is a Due to the possibility of having many Segment Lists in the same
128-bit value. "SRv6 SID" or simply "SID" are often used as a Candidate Path of each POL1/POL2, PCECC could provision more paths
shorter reference for "SRv6 Segment". towards R8 and traffic will be balanced either as ECMP or as w/ECMP.
<xref target="RFC8986"/> defines the SRv6 SID as consisting of LOC:FUNCT:ARG.
</t>
<t><xref target="I-D.ietf-pce-segment-routing-ipv6"/> extends Perhaps:
<xref target="RFC8664"/> to support SR for the IPv6 data plane. Further,
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 with ECMP.
-->
<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 w/ECMP. This is
the advantage of SR Policy architecture.
</li>
</ul>
<t>Note that an SR Policy can be associated with multiple candidate
paths. A candidate path is selected when it is valid and it is determined to be
the best path of the SR Policy as described in <xref target="RFC9256" format="de
fault"/>.</t>
</section>
</section>
<section anchor="sect-8" numbered="true" toc="default">
<name>PCECC for SRv6</name>
<t>As per <xref target="RFC8402" format="default"/>, with Segment
Routing (SR), a node steers a packet through an ordered list of
instructions, called segments. Segment Routing 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 824
* | * * + * | * * +
* | * * + * | * * +
* | * * + * | * * +
+-----------+ +-----------+ +-----------+ +-----------+
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 PCE-based controller 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 890
* | * * + * | * * +
+-----------+ +-----------+ +-----------+ +-----------+
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., bandwidth).</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 <!--[rfced] FYI - We have slightly adjusted the spacing and formatting
rk><![CDATA[ of the ASCII artwork in Figure 6 as it exceeded the 72-character limit.
TE1 --------------> Please review and let us know if any further changes are necessary. -->
+---------+ +--------+ +--------+ +--------+ +------+ +---+
| Access |----| Access |----| AGG 1 |----| AGG N-1|----|Core 1|--|SR1| <figure anchor="fig_lb">
| SubNode1| | Node 1 | +--------+ +--------+ +------+ +---+ <name>PCECC Load Balancing (LB) Use Case</name>
+---------+ +--------+ | | | ^ | <artwork name="" type="" align="left" alt=""><![CDATA[
| Access | Access | AGG Ring 1 | | | TE1 ----------->
| SubRing 1 | Ring 1 | | | | | +--------+ +------+ +-----+ +-------+ +------+ +---+
+---------+ +--------+ +--------+ | | | |Access |----|Access|----|AGG 1|----|AGG N-1|----|Core 1|--|SR1|
| Access | | Access | | AGG 2 | | | | |SubNode1| |Node 1| +-----+ +-------+ +------+ +---+
| SubNode2| | Node 2 | +--------+ | | | +--------+ +------+ | | | ^ |
+---------+ +--------+ | | | | | | Access | Access | AGG Ring 1| | |
| | | | | | | | SubRing 1 | Ring 1 | | | | |
| | | +----TE2----|-+ | +--------+ +------+ +-----+ | | |
+---------+ +--------+ +--------+ +--------+ +------+ +---+ |Access | |Access| |AGG 2| | | |
| Access | | Access |----| AGG 3 |----| AGG N |----|Core N|--|SRn| |SubNode2| |Node 2| +-----+ | | |
| SubNodeN|----| Node N | +--------+ +--------+ +------+ +---+ +--------+ +------+ | | | | |
+---------+ +--------+ | | | | | | |
| | | +---TE2---|-+ |
+--------+ +------+ +-----+ +-------+ +------+ +---+
|Access | |Access|----|AGG 3|----| AGG N |----|Core N|--|SRn|
|SubNodeN|----|Node N| +-----+ +-------+ +------+ +---+
+--------+ +------+
]]></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> <!-- [rfced] We have removed the parentheses around "Virtual Private LAN
Service deployment is made by means of Layer 2 Virtual Private Networks (L2VP Services (VPLS)" in the text below. Please review and let us know if this
Ns) (Virtual Private LAN Services (VPLS)), Layer 3 Virtual Private Networks (L3V changed the intended meaning of the text.
PNs) or Ethernet VPNs (EVPNs).
Those services use MPLS TE (or SR-TE) as transport towards egress AGG routers
.
TE tunnels could be used as transport towards service routers in
case of seamless MPLS (<xref target="I-D.ietf-mpls-seamless-mpls"/>) based ar
chitecture.</t>
<t>Load balancing between TE tunnels involves distributing network traffic ac ross multiple TE tunnels to optimize the use of available network resources, enh ance performance, and ensure reliability. Some common techniques include Equal-C ost Multi-Path (ECMP) and Unequal-Cost Multi-Path (UCMP) based on the bandwidth of the TE tunnels.</t> Original:
<t>There is a need to solve the following tasks: Service deployment is made by means of Layer 2 Virtual Private
<list style="symbols"> Networks (L2VPNs) (Virtual Private LAN Services (VPLS)), Layer 3
Virtual Private Networks (L3VPNs) or Ethernet VPNs (EVPNs).
<t>Perform automatic load-balance amongst TE tunnels according to current Current:
traffic load.</t>
<t>TE bandwidth (BW) management: Provide guaranteed BW for specific
services: High-Speed Data Service (HSI)), IPTV, etc., and provide time-ba
sed BW reservation (BW on demand (BoD)) for other services.</t>
<t>Simplify the development of TE tunnels by automation without any manual int
ervention.</t>
<t>Provide flexibility for Service Router placement (anywhere Service deployment is made by means of Layer 2 Virtual Private
in the network by the creation of transport LSPs to them).</t> Networks (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3
</list></t> Virtual Private Networks (L3VPNs), or Ethernet VPNs (EVPNs).
<t>In this section, the focus is on load balancing (LB) tasks. LB task -->
could be solved by means of PCECC in the following way:
<list style="symbols">
<t>Application or network service or operator can ask the SDN
controller (PCECC) for LSP-based load balancing between AGG X and AGG N/A
GG N-1
(egress AGG routers that have connections to the core).
Each of these will have associated constraints (i.e. bandwidth, inclus
ion or exclusion specific links
or nodes, number of paths, objective function (OF), need for disjoint LSP
paths etc.);</t>
<t>PCECC could calculate multiple (say N) LSPs according to given constra <t>
ints, Service deployment is made by means of Layer 2 Virtual Private Networks
the calculation is based on results of Objective Function (OF) <xref targ (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 Virtual Private
et="RFC5541"/>, constraints, endpoints, same or different Networks (L3VPNs), or Ethernet VPNs (EVPNs). Those services use MPLS TE
bandwidth (BW), different links (in case of disjoint paths) and other (or SR-TE) as transport towards egress AGG routers. TE tunnels could be
constraints.</t> used as transport towards service routers in case of architecture based on
seamless MPLS <xref target="I-D.ietf-mpls-seamless-mpls"
format="default"/>.
</t>
<t>Load balancing between TE tunnels involves distributing network
traffic across multiple TE tunnels to optimize the use of available
network resources, enhance performance, and ensure reliability. Some
common techniques include Equal-Cost Multipath (ECMP) and
Unequal-Cost Multipath (UCMP) based on the bandwidth of the TE
tunnels.</t>
<t>Depending on the given LSP Path setup type (PST), PCECC will download <!-- [rfced] To improve readability, may we update this this text
instructions to the PCC. At this stage, it is assumed the PCECC is aware as follows? Additionally, should "HSI" be listed as an example
of the label space it controls and SID allocation and of high-speed data services?
distribution is already done in the case of SR.</t>
<t>PCECC will send PCInitiate message <xref target="RFC8281"/> towards in Original:
gress AGG X router(PCC) for each of N LSPs
and receive PCRpt message <xref target="RFC8231"/> back from
PCCs. If PST is PCECC-SR, the PCECC will include a SID stack as per <xref
target="RFC8664"/>.
If PST is PCECC (basic), then the PCECC will assign labels along the calc
ulated path and set up the
path by sending central controller instructions in a PCEP message to each nod
e along the path of the
LSP as per <xref target="RFC9050"/> and then
send PCUpd message to the ingress AGG X router with
information about new LSP. AGG X(PCC) will respond with PCRpt
with LSP status.</t>
<t>AGG X as an ingress router now has N LSPs towards AGG N and AG * TE bandwidth (BW) management: Provide guaranteed BW for specific
G N-1 services: High-Speed Data Service (HSI)), IPTV, etc., and provide
which are available for installation to the router's forwarding table and time-based BW reservation (BW on demand (BoD)) for other services.
load-balance traffic
between them. Traffic distribution between those LSPs depends on
the particular realization of the hash-function on that router.</t>
<t>Since PCECC is aware of TEDB (TE state) and LSP-DB, it can manage and Perhaps:
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
etwork by directly provisioning the central control instructions.</t>
</list> * Manage TE bandwidth (BW) and provide guaranteed BW for specific
</t> services (such as high-speed data services like High-Speed Internet
(HSI), IPTV, etc.) and provide time-based BW reservation (such as
Bandwidth on Demand (BoD)) for other services.
-->
</section> <t>There is a need to solve the following tasks:
</t>
<ul spacing="normal">
<li>
<t>Perform automatic load balancing amongst TE tunnels according to
current traffic loads.</t>
</li>
<li>
<t>TE bandwidth (BW) management: Provide guaranteed BW for specific
services: High-Speed Data Service (HSI)), IPTV, etc., and provide
time-based BW reservation (BW on demand (BoD)) for other services.</t>
</li>
<li>
<t>Simplify the development of TE tunnels by automation without any
manual intervention.</t>
</li>
<li>
<t>Provide flexibility for service router placement
(anywhere in the network by the creation of transport LSPs to
them).</t>
</li>
</ul>
<t>In this section, the focus is on load balancing (LB) tasks. LB tasks
could be solved by means of the PCECC in the following ways:
</t>
<section title="PCECC and Inter-AS TE" anchor="sect-5.1"> <ul spacing="normal">
<t> <li>
There are various signalling options for establishing Inter-AS TE LSP: <t>Applications, network services, or operators can ask the SDN
contiguous TE LSP <xref target="RFC5151"/>, stitched TE LSP <xref target="RFC controller (PCECC) for LSP-based load balancing between AGG X and
5150"/>, AGG N/AGG N-1 (egress AGG routers that have connections to the
and nested TE LSP <xref target="RFC4206"/>.</t> core). Each of these will have associated constraints
(such as bandwidth, inclusion or exclusion of specific links or node
s,
number of paths, Objective Function (OF), need for disjoint LSP
paths, etc.).</t>
</li>
<li>
<t>The PCECC could calculate multiple (say N) LSPs according to give
n
constraints. The calculation is based on the results of Objective Fu
nction (OF) <xref target="RFC5541" format="default"/>,
constraints, endpoints, same or different bandwidth (BW),
different links (in case of disjoint paths), and other
constraints.</t>
</li>
<li>
<t>Depending on the given LSP Path Setup Type (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> <!-- [rfced] FYI - We have broken up the sentence below to improve readability.
Requirements for PCE-based Inter-AS setup <xref target="RFC5376"/> describe t Please review and let us know if any further updates are necessary.
he approach
and PCEP functionality that is needed for establishing Inter-AS TE LSPs.</t>
<t> Original:
<xref target="RFC5376"/> also gives Inter- and Intra-AS PCE Reference Model (
as shown in <xref target="fig_short"/>) that is
provided below in shortened form for the sake of simplicity.</t>
<figure title="Shortened form of Inter- and Intra-AS PCE Reference Model" If PST is PCECC (basic), then the PCECC
anchor="fig_short"><artwork><![CDATA[ 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 [RFC9050] and then send
PCUpd message to the ingress AGG X router with information about
new LSP.
Current:
If the PST is a PCECC (basic), then the PCECC
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 [RFC9050]. Then, the
PCECC will send a PCUpd message to the ingress AGG X router with
information about the new LSP.
-->
<li>
<t>The PCECC will send a PCInitiate message <xref target="RFC8281"
format="default"/> towards the ingress AGG X router (PCC) for each o
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 a PCECC (basic), then the PCECC w
ill
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 load balancing traffic
between them. Traffic distribution between those LSPs depends on
the particular realization of the hash function on that router.</t>
</li>
<li>
<t>Since the PCECC is aware of the TEDB (TE state) and the LSP Datab
ase (LSP-DB), it can manage and
prevent possible over-subscriptions and limit the number of available loa
d-balance
states. Via a PCECC mechanism, the control can take quick actions into th
e network by directly provisioning the central control instructions.</t>
</li>
</ul>
</section>
<section anchor="sect-5.1" numbered="true" toc="default">
<name>PCECC and Inter-AS TE</name>
<t>
There are various signalling options for establishing Inter-AS TE
LSPs: contiguous TE LSPs <xref target="RFC5151" format="default"/>,
stitched TE LSPs <xref target="RFC5150" format="default"/>, and
nested TE LSPs <xref target="RFC4206" format="default"/>.</t>
<t>
The requirements for PCE-based Inter-AS setup <xref target="RFC5376" format="
default"/> describe the approach
and PCEP functionality that is needed for establishing Inter-AS TE LSPs.</t>
<t>
<xref target="RFC5376" format="default"/> also gives an Inter-AS and
Intra-AS PCE Reference Model (as shown in <xref target="fig_short"
format="default"/>) that is provided below in shortened form for the sake
of simplicity.</t>
<figure anchor="fig_short">
<name>Shortened Form of the Inter-AS and Intra-AS PCE Reference Model<
/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 1178
:: :: :: :: :: ::
:: :: :: :: :: ::
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 1222
| | 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> <!-- [rfced] To parallel the preceding sentence, may we update "R1-R3 LSP2"
As per <xref target="fig_inter_as_pce"/>, LSP1 from R1 to R3 goes via ASBR1 to be "LSP2 from R1 to R3"?
and ASBR3, and it is the primary Inter-AS LSP. R1-R3 LSP2 that goes via
ASBR5 and ASBR6 are the backup ones. In addition, there could also be a bypas
s LSP
setup to protect against ASBR or inter-AS link failures.</t>
<t> Original:
After the addition of PCECC functionality to PCE (SDN controller), the PCECC-
based Inter-AS TE model should follow the PCECC use case for TE LSP
including requirements of <xref target="RFC5376"/> with the following details
:
<list style="symbols"> As per Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it
<t>Since PCECC needs to know the topology of both domains AS1 and AS2, PC is the primary Inter-AS LSP. R1-R3 LSP2 that goes via ASBR5 and
ECC ASBR6 are the backup ones.
Perhaps:
As per Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it
is the primary Inter-AS LSP. LSP2 from R1 to R3 that goes via ASBR5 and
ASBR6 is the backup one.
-->
<t>
As per <xref target="fig_inter_as_pce" format="default"/>, LSP1 from R1 to R
3 goes via ASBR1
and ASBR3, and it is the primary Inter-AS LSP. R1-R3 LSP2 that goes via
ASBR5 and ASBR6 is the backup one. In addition, there could also be a bypass
LSP
setup to protect against ASBR or Inter-AS link failures.</t>
<t>
After the addition of PCECC functionality to the PCE (SDN controller),
the PCECC-based Inter-AS TE model should follow the PCECC use case
for TE LSP including the requirements described in <xref target="RFC537
6"
format="default"/> with the following details:
</t>
<ul spacing="normal">
<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>
<li>
<t>The PCECC needs to establish PCEP connectivity with all routers i
n both
domains (see also <xref target="RFC5376" section="4" sectionFormat="of"/>
).</t>
</li>
<t>PCECC needs to establish PCEP connectivity with all routers in both <!-- [rfced] We have broken up the sentence below to improve readability.
domains (see also section 4 in <xref target="RFC5376"/>).</t> Please review and let us know if any further updates are necessary.
<t>After the operator's application or service orchestrator creates a req Original:
uest
for tunnel creation of a specific service, PCECC will receive that reques
t via NBI
(NBI type is implementation dependent, it could be NETCONF/Yang, REST etc
.). Then
PCECC will calculate the optimal path based on Objective Function (OF) an
d given
constraints (i.e. path setup type, bandwidth etc.), including those from
<xref target="RFC5376"/>:
priority, AS sequence, preferred ASBR, disjoint paths, and protection typ
e. In this
step, we will have two paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3</t>
<t>PCECC will use central control download Then PCECC will calculate the optimal path based on Objective Function
instructions to the PCC based on the PST. At this stage, it is assumed the P (OF) and given constraints (i.e. path setup type, bandwidth etc.),
CECC is aware including those from [RFC5376]: priority, AS sequence, preferred ASBR,
of the label space it controls and in the case of SR the SID allocation and disjoint paths, and protection type.
distribution is already done.</t>
<t>PCECC will send PCInitiate message <xref target="RFC8281"/> towards the ing Current:
ress router R1 (PCC) in AS1
and receive the PCRpt message <xref target="RFC8231"/> back from it.
<list style="symbols">
<t>If the PST is SR-MPLS, the PCECC will include the SID stack as per
<xref target="RFC8664"/>.
Optionally, a binding SID or BGP Peering-SID <xref target="RFC9087"/> can
also be included on the AS boundary. The backup SID stack can be installed at i
ngress R1 but more importantly,
each node along the SR path could also do the local protection just based
on the top segment.</t>
<t>If the PST is PCECC, the PCECC will assign labels along the calculated
paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3) and sets up the
path by sending central controller instructions in PCEP message to each node
along the path of the
LSPs as per <xref target="RFC9050"/>. After these steps, the PCECC will send
a PCUpd message to the ingress R1 router with information about new LSPs and R1
will respond by PCRpt with LSP(s) status.</t></list></t>
<!--<t>AGG X as ingress router now have N LSPs towards AGG N and AGG N-1 Then, the PCECC will calculate the optimal path based on Objective Functio
n
(OF) and given constraints (i.e., path setup type, bandwidth, etc.).
These constraints include those from [RFC5376], such as priority,
AS sequence, preferred ASBR, disjoint paths, and protection type.
-->
<li>
<t>After the operator's application or service orchestrator
creates a request for tunnel creation of a specific service, the PCE
CC
will receive that request via NBI (note that the NBI type is
implementation-dependent; it could be NETCONF/YANG, REST,
etc.). Then, the PCECC will calculate the optimal path based on Obje
ctive Function (OF) and
given constraints (i.e., path setup type, bandwidth, etc.). These co
nstraints include
those from <xref target="RFC5376" format="default"/>, such as
priority, AS sequence, preferred ASBR, disjoint paths, and
protection type. In this step, we will have two paths:
R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3.</t>
</li>
<li>
<t>The PCECC will use central control download instructions to the P
CC
based on the PST. At this stage, it is assumed the PCECC is aware
of the label space it controls, and in the case of SR, the SID
allocation and distribution is already done.</t>
</li>
<li>
<t>The PCECC will send a PCInitiate message <xref target="RFC8281"
format="default"/> towards the ingress router R1 (PCC) in AS1 and
receive the PCRpt message <xref target="RFC8231"
format="default"/> back from it.
</t>
<ul spacing="normal">
<li>
<t>If the PST is SR-MPLS, the PCECC will include the SID stack
as per <xref target="RFC8664" format="default"/>. Optionally,
a BSID or BGP Peering-SID <xref target="RFC9087"
format="default"/> can also be included on the AS
boundary. The backup SID stack can be installed at ingress R1,
but more importantly, each node along the SR path could also
do the local protection just based on the top segment.</t>
</li>
<li>
<t>If the PST is a PCECC, the PCECC will assign labels along the
calculated paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3) and
sets up the path by sending central controller instructions in a
PCEP message to each node along the path of the LSPs as per
<xref target="RFC9050" format="default"/>. After these steps,
the PCECC will send a PCUpd message to the ingress R1 router
with information about new LSPs and R1 will respond by a PCRpt
with LSP(s) status.</t>
</li>
</ul>
</li>
<!-- [auth] <t>AGG X as ingress router now have N LSPs towards AGG N a
nd AGG N-1
which are available for installing to router's forwarding table and load- balance a traffic which are available for installing to router's forwarding table and load- balance a traffic
between them. Traffic distribution between those LSPs depends on between them. Traffic distribution between those LSPs depends on
particular realization of hash-function on that router.</t>--> particular realization of hash-function on that router.</t>-->
<t>After that step, R1 now have primary and backup TEs (LSP1 and LSP2) to <li>
wards <t>After that step, R1 now has primary and backup TEs (LSP1 and LSP2
R3. It is up to router implementation how to make switchover to backup LS ) towards
P2 if LSP1 fails.</t> R3. It is up to the router implementation for how to switchover to backup
LSP2 if LSP1 fails.</t>
</list></t> </li>
</section> </ul>
</section>
<section title="PCECC for Multicast LSPs" anchor="sect-6"><t> <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 bandwidth 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>
<!-- [auth] <t>
With the capability of global label and local label existing at the With the capability of global label and local label existing at the
same time in the PCECC network, PCECC will use compute, setup and 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 maintain the P2MP and MP2MP lsp using the local label range for each
network nodes.</t>--> 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"> <!--[rfced] We note that Figure 9 abbreviates links as "L1", "L2", etc., while
<artwork><![CDATA[ Figures 2, 3, 4, and 5 use "link1", "link2", etc. Should Figure 9 be updated
to also use "link1", "link2", etc. to reflect the other figures in this document
?
-->
<figure anchor="fig_p2mp">
<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 (L0)
+----------+ +----------+
Transit Node | R2 | Transit Node | R2 |
branch +----------+ branch +----------+
* | * * * | * *
9001* | * *9002 9001* | * *9002
L1 * | * *L2 L1 * | * *L2
+-----------+ | * +-----------+ +-----------+ | * +-----------+
| R4 | | * | R5 | Transit Nodes | R4 | | * | R5 | Transit Nodes
skipping to change at line 1105 skipping to change at line 1399
* | * * + * | * * +
9003* | * * +9004 9003* | * * +9004
L3 * | * * +L4 L3 * | * * +L4
+-----------+ +-----------+ +-----------+ +-----------+
| R3 | | R6 | Leaf Node | R3 | | R6 | Leaf Node
+-----------+ +-----------+ +-----------+ +-----------+
9005| L5 9005| L5
+-----------+ +-----------+
| 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>
<li>
<t>The PCECC will calculate the optimal P2MP path according to giv
en constraints
(i.e., bandwidth).</t>
</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":
</t>
<ul spacing="normal">
<li>
<t>R1: Outgoing label 9000 on link L0</t>
</li>
<li>
<t>R2: Incoming label 9000 on link L0</t>
</li>
<li>
<t>R2: Outgoing label 9001 on link L1 (*)</t>
</li>
<li>
<t>R2: Outgoing label 9002 on link L2 (*)</t>
</li>
<li>
<t>R5: Incoming label 9002 on link L2</t>
</li>
<li>
<t>R5: Outgoing label 9004 on link L4</t>
</li>
<li>
<t>R6: Incoming label 9004 on link L4</t>
</li>
<li>
<t>R4: Incoming label 9001 on link L1</t>
</li>
<li>
<t>R4: Outgoing label 9003 on link L3</t>
</li>
<li>
<t>R3: Incoming label 9003 on link L3</t>
</li>
<li>
<t>R3: Outgoing label 9005 on link L5</t>
</li>
<li>
<t>R8: Incoming label 9005 on link L5</t>
</li>
</ul>
</li>
<li>
<t>This can also be represented as: {R1, 6000}, {6000, R2,
{9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3,
9005}, {9004, R6}, {9005, R8}. The main difference (*) is in the
branch node instruction at R2, where two copies of a packet are
sent towards R4 and R5 with 9001 and 9002 labels, respectively.</t
>
</li>
</ul>
<t>The packet forwarding involves the following:</t>
<ol type="Step %d.">
<li>R1 sends a packet to R2 simply by pushing the label of 9000 to
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">
<t>PCECC will calculate the optimal P2MP path according to given constraints <!-- [rfced] We have updated the following text to make them complete
(i.e.bandwidth).</t> sentences. Please review and let us know if further updates are necessary.
<t>PCECC will provision each node along the path and assign incoming and outgoin a) Section 3.6.2:
g labels from R1 to {R6, R8} with the Original:
path as "R1-L0-R2-L2-R5-L4-R6" and "R1-L0-R2-L1-R4-L3-R3-L5-R8":
<list style="symbols">
<t>R1: Outgoing label 9000 on link L0</t>
<t>R2: Incoming label 9000 on link L0</t>
<t>R2: Outgoing label 9001 on link L1 (*)</t>
<t>R2: Outgoing label 9002 on link L2 (*)</t>
<t>R5: Incoming label 9002 on link L2</t>
<t>R5: Outgoing label 9004 on link L4</t>
<t>R6: Incoming label 9004 on link L4</t>
<t>R4: Incoming label 9001 on link L1</t>
<t>R4: Outgoing label 9003 on link L3</t>
<t>R3: Incoming label 9003 on link L3</t>
<t>R3: Outgoing label 9005 on link L5</t>
<t>R8: Incoming label 9005 on link L5</t>
</list></t>
<t>This can also be represented as In this section, the end-to-end managed path protection service as
: {R1, 6000}, {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {90 well as the local protection with the operation management in the
03, R3, 9005}, {9004, R6}, {9005, R8}. The main difference (*) PCECC network for the P2MP/MP2MP LSP.
is in the branch node instruction at R2 where two copies of a packet are sent
towards R4 and R5 with 9001 and 9002 labels respectively.</t>
</list></t> Current:
<t>The packet forwarding involves -
<list>
<t>
Step 1: R1 sends a packet to R2 simply by pushing the label of
9000 to the packet.</t>
<t> This section describes the end-to-end managed path protection service as
Step 2: When R2 receives the packet with label 9000, it will well as the local protection with operation management in the
forward it to R4 by swapping label 9000 to 9001 and at the same time, PCECC network for the P2MP/MP2MP LSP.
it will replicate the packet and swap the label 9000 to 9002 and forward it t
o R5.</t>
<t> b) Appendix A.4:
Step 3: When R4 receives the packet with label 9001, it will Original:
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.</t>
<t> In Hadoop (https://hadoop.apache.org/) 1.0
Step 4: When R3 receives the packet with label 9003, it will architecture MapReduce operations on big data in the Hadoop
forward it to R8 by swapping it to 9005 and when R5 receives the Distributed File System (HDFS), where NameNode knows about resources
packet with label 9002, it will be swapped to 9004 and sent to R6.</t> of the cluster and where actual data (chunks) for a particular task
are located (which DataNode).
<t>Step 5: When R8 receives the packet with label 9005, it will pop the label Current:
; when R6 receives the packet with label 9004, it will pop the label.</t>
</list></t>
</section>
<section title="PCECC for the End-to-End Protection of P2MP/MP2MP LSPs" In Hadoop (https://hadoop.apache.org/) 1.0 architecture, MapReduce
anchor="sect-6.2"><t> operations occur on big data in the Hadoop Distributed File System (HDFS), wh
In this section, the end-to-end managed path protection ere
NameNode knows about resources of the cluster and where actual data
(chunks) for a particular task are located (which DataNode).
-->
<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>
Segment Routing (where it is used to select which set of
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 load balancing. Traffic classification is closely linke d to the computational important enabler for load balancing. Traffic classification is closely linke d to the computational
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 <!-- [rfced] We note that "Flow Specification" occurs three times in the
fication components and their dissemination as traffic flow specifications (Flow sentence below. For concision and clarity, may we update the sentence as
Specifications) is described for BGP in <xref target="RFC8955"/>. When a PCECC follows?
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> Original:
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> The description of traffic flows by the combination of multiple Flow
Specification components and their dissemination as traffic flow
specifications (Flow Specifications) is described for BGP in [RFC8955].
<t>Whether it is a virtual link</t> Perhaps:
<t>Whether to advertise it in the IGP as a virtual link</t> The description of traffic flows by the combination of multiple Flow
Specification components and their dissemination as traffic Flow
Specifications is described for BGP in [RFC8955].
-->
<t>What bits of this information to signal to the tail end</t> <t>The description of traffic flows by the combination of multiple Flow Specification components and their dissemination as traffic flow specifications (Flow Specifications) is described for BGP in <xref target="RFC8955" format="def ault"/>. When a PCECC is used to initiate tunnels (such as TE LSPs or SR paths) using PCEP, it is important that the head end of the tunnels understands what tr affic to place on each tunnel. <xref target="RFC9168" format="default"/> specifi es a set of extensions to PCEP to support the dissemination of Flow Specificatio n components where the instructions are passed from the PCECC to the routers usi ng PCEP.</t>
</list> <!-- [rfced] For clarity, what does "it" refer to in the bullets below? Is
</t> it the PCECC?
<t>These are out of the scope of this document.</t>
</section> Original (Section 3.7):
<section title="PCECC for SFC" anchor="sect-9" > Along with traffic classification, there are a few more questions
<t>Service Function Chaining (SFC) is described in <xref target="RFC7665"/>. that need to be considered after path setup:
It is the process of directing
* how to use it
* Whether it is a virtual link
* Whether to advertise it in the IGP as a virtual link
* What bits of this information to signal to the tail end
Perhaps:
Along with traffic classification, there are a few more questions
about the PCECC that need to be considered after path setup:
* how to use it,
* whether it is a virtual link,
* whether to advertise it in the IGP as a virtual link, and
* what bits of this information to signal to the tail end.
-->
<t>
Along with traffic classification, there are a few more considerations after
path setup:
</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 anchor="sect-9" numbered="true" toc="default">
<name>PCECC for SFC</name>
<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 load balancing 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 n be performed by a connects them. As per <xref target="RFC8283" format="default"/>, these are o perations that can be performed by a
PCE-based controller, and that controller can use PCEP to program the PCE-based controller, 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>
<t>Service Index (SI): Provides location within the SFP.</t>
<t>SFC Proxy handling</t>
</list>
</t>
<t>PCECC can play the role of setting the traffic classification rules (as pe
r <xref target="sect-7"/>) at the classifier to impose the Network Service Heade
r (NSH) <xref target="RFC8300"/> as well as downloading the forwarding instructi
ons to each SFF along the way so that they could process the NSH and forward acc
ordingly. Including instructions for the service classifier that handles the con
text header, metadata etc. This metadata/context is shared amongst SFs and class
ifiers, between SFs, and between external systems (such as PCECC) and SFs. As de
scribed in <xref target="RFC7665"/>, the SFC encapsulation enables the sharing o
f metadata/context information along the SFP.</t>
<t>It is also possible to support SFC with SR in conjunction with or without <!-- [rfced] Would you like to add any additional text or a definition to "SFC
NSH such as <xref target="RFC9491"/> and <xref target="I-D.ietf-spring-sr-servic Proxy handling" below, for consistency with the other bulleted items in this lis
e-programming"/>. PCECC technique can also be used for service function-related t?
segments and SR service policies. </t>
</section> Original:
<section title="PCECC for Native IP" anchor="sect-10" >
<t><xref target="RFC8735"/> describes the scenarios and simulation results f
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> A possible mechanism could add support for SFC-based central control
<![CDATA[ instructions. PCECC will be able to instruct each SFF along the SFP.
+------+
+----------+ 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 | +---+
+-----------+ +-----------+
]]> * Service Path Identifier (SPI): Uniquely identifies an SFP.
</artwork></figure>
<t>In the case, as shown in <xref target="fig_native_ip"/>, PCECC will instruct * Service Index (SI): Provides location within the SFP.
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> * SFC Proxy handling
-->
<section title="PCECC for BIER" anchor="sect-11"> <ul>
<t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> defines an <li>Service Path Identifier (SPI): Uniquely identifies an SFP.</li>
architecture where all intended multicast receivers are encoded as a <li>Service Index (SI): Provides location within the SFP.</li>
bitmask in the multicast packet header within different <li>SFC Proxy handling</li>
encapsulations. A router that </ul>
receives such a packet will forward that packet based on the bit <t>The PCECC can play the role of setting the traffic classification rul
position in the packet header towards the receiver(s) following a es (as per <xref target="sect-7" format="default"/>) at the classifier to impose
precomputed tree for each of the bits in the packet. Each receiver the Network Service Header (NSH) <xref target="RFC8300" format="default"/>. It
is represented by a unique bit in the bitmask.</t> can also download the forwarding instructions to each SFF along the way so that
they could process the NSH and forward accordingly. This includes instructions f
or the service classifier that handles the context header, metadata, etc. This m
etadata/context is shared amongst SFs and classifiers, between SFs, and between
external systems (such as a PCECC) and SFs. As described in <xref target="RFC766
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 wit
hout an NSH such as described in <xref target="RFC9491" format="default"/> and <
xref target="I-D.ietf-spring-sr-service-programming" format="default"/>. PCECC t
echniques can also be used for service-function-related segments and SR service
policies. </t>
</section>
<section anchor="sect-10" numbered="true" toc="default">
<name>PCECC for Native IP</name>
<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 protocol 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> <!-- [rfced] FYI - Since "BIER encapsulation" appeared twice in the sentence
below, we removed the second instance and updated for conciseness. Please
review and let us know of any objections.
</section> Original:
<section title="IANA Considerations" anchor="sect-12"><t> The PCECC could be used to program the BIER router with various parameters
This document does not require any action from IANA.</t> used in the BIER encapsulation such as BIER subdomain-ID, BFR-ID, BIER
Encapsulation etc. for both node and adjacency.
</section> Current:
<section title="Security Considerations" anchor="sect-13"> The PCECC could be used to program the BIER router with various parameters
<t><xref target="RFC8283"/> describes how the security considerations for a used in the BIER encapsulation (such as BIER sub-domain-id, BFR-id, etc.)
PCE-based controller are a little different from those for any other PCE system. for both node and adjacency.
PCECC operations rely heavily on the use and security of PCEP, so -->
due consideration should be given to the security features discussed in
<xref target="RFC5440"/> and the additional mechanisms described in <xref tar
get="RFC8253"/>. It further lists the vulnerability of a
central controller architecture, such as a central point of failure,
denial of service, and a focus on interception and modification of
messages sent to individual Network Elements (NEs).</t>
<t>As per <xref target="RFC9050"/>, the use of
Transport Layer Security (TLS) in PCEP is recommended, as it provides support
for
peer authentication, message encryption, and integrity. It further
provides mechanisms for associating peer identities with different
levels of access and/or authoritativeness via an attribute in X.509
certificates or a local policy with a specific accept-list of X.509
certificates. This can be used to check the authority for the PCECC
operations.</t>
<t>It is expected that each new document that is produced for a specific
use case will also include considerations of the security impacts of
the use of a PCE-based central controller on the network type and
services being managed.</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 title="Acknowledgments" anchor="sect-14"><t> <t>A possible way to use the PCECC and PCEP extension is described in
Thanks to Adrian Farrel, Aijun Wang, Robert Tao, <xref target="I-D.chen-pce-pcep-extension-pce-controller-bier"
Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Elperin format="default"/>.</t>
and Evgeniy Brodskiy for their useful comments and suggestions.</t> </section>
<t>Thanks to Mach Chen and Carlos Pignataro for the RTGDIR review. Thanks to
Derrell Piper for the SECDIR review. Thanks to Sue Hares for GENART review.</t>
<t>Thanks to Vishnu Pavan Beeram for being the document shepherd and Jim Guic
hard for being the responsible AD.</t>
<t>Thanks to Roman Danyliw for the IESG review comments.</t>
</section> </section>
</middle> <section anchor="sect-12" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<back> <section anchor="sect-13" numbered="true" toc="default">
<name>Security Considerations</name>
<t><xref target="RFC8283" format="default"/> describes how the security
considerations for a PCE-based controller are a little different from
those for any other PCE system. PCECC operations rely heavily on the
use and security of PCEP, so due consideration should be given to the
security features discussed in <xref target="RFC5440" format="default"/>
and the additional mechanisms described in <xref target="RFC8253"
format="default"/>. It further lists the vulnerability of a central
controller architecture, such as a central point of failure, denial of
service, and a focus on interception and modification of messages sent
to individual Network Elements (NEs).</t>
<t>As per <xref target="RFC9050" format="default"/>, the use of
Transport Layer Security (TLS) in PCEP is recommended, as it provides
support for peer authentication, message encryption, and integrity. It
further provides mechanisms for associating peer identities with
different levels of access and/or authoritativeness via an attribute in
X.509 certificates or a local policy with a specific accept-list of
X.509 certificates. This can be used to check the authority for the
PCECC operations.</t>
<t>It is expected that each new document that is produced for a specific
use case will also include considerations of the security impacts of the
use of a PCE-based central controller on the network type and services
being managed.</t>
</section>
<references title="Normative References"> </middle>
<!--&RFC2119;-->
&RFC5440;
<!--&RFC8174;-->
&RFC7665;
&RFC8231;
&RFC8281;
&RFC8283;
&RFC8253;
&RFC8402; <back>
</references> <displayreference target="I-D.ietf-pce-pcep-extension-pce-controller-sr" to=
<references title="Informative References"> "PCECC-SR"/>
&RFC1195; <displayreference target="I-D.ietf-pce-controlled-id-space" to="PCE-ID"/>
<displayreference target="I-D.ietf-pce-stateful-interdomain" to="PCE-INTERDO
MAIN"/>
<displayreference target="I-D.cbrt-pce-stateful-local-protection" to="PCE-PR
OTECTION"/>
<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"/>
&RFC2328; <references>
&RFC5340; <name>References</name>
&RFC3209; <references>
&RFC5036; <name>Normative References</name>
<!-- [auth] &RFC2119;-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54
40.xml"/>
<!-- [auth] &RFC8174;-->
<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"/>
&RFC3985; <!-- [I-D.ietf-pce-pcep-extension-pce-controller-sr] IESG state: I-D Exists as o
&RFC4206; f 06/06/24-->
&RFC4364; <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
&RFC4456; e-pcep-extension-pce-controller-sr.xml"/>
&RFC4655;
&RFC5150;
&RFC5151;
&RFC5541;
&RFC5376;
&RFC7025;
&RFC7399;
&RFC7432;
&RFC7491;
&RFC8279; <!-- [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>
&RFC8300; <!-- [I-D.ietf-pce-stateful-interdomain] IESG state: Expired as of 06/06/24-->
&RFC8355; <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
&RFC8408; e-stateful-interdomain.xml"/>
&RFC8664; <!-- [I-D.cbrt-pce-stateful-local-protection] IESG state: Expired as of 06/06/24
&RFC8735; -->
&RFC8751; <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-cbrt-pc
&RFC8754; e-stateful-local-protection.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-segment-routing-ipv6] IESG state: RFC Ed Queue as
&I-D.li-pce-controlled-id-space; of 06/06/24. Published as [RFC9603]. Updated reference and cite tags
&I-D.ietf-pce-stateful-interdomain; accordingly.-->
&I-D.cbrt-pce-stateful-local-protection; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
&I-D.ietf-pce-segment-routing-ipv6; 603.xml"/>
&I-D.ietf-mpls-seamless-mpls;
&I-D.chen-pce-bier; <!-- [I-D.ietf-mpls-seamless-mpls] IESG state: Expired (IESG: Dead) as of 06/06/
&I-D.ietf-spring-sr-service-programming; 24. Added missing editor role to XML.-->
<reference anchor="I-D.ietf-mpls-seamless-mpls" target="https://datatracker.ietf
.org/doc/html/draft-ietf-mpls-seamless-mpls-07">
<front>
<title>Seamless MPLS Architecture</title>
<author fullname="Nicolai Leymann" initials="N." surname="Leymann" role="editor"
>
<organization>Deutsche Telekom AG</organization>
</author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization>
</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>
&I-D.ietf-pce-segment-routing-policy-cp; <!-- [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"/>
&I-D.ietf-pce-binding-label-sid; <!-- [I-D.ietf-spring-sr-service-programming] IESG state: I-D Exists as of 06/06
&I-D.chen-pce-pcep-extension-pce-controller-bier; /24-->
&I-D.ietf-pce-pcep-extension-native-ip; <reference anchor="I-D.ietf-spring-sr-service-programming" target="https://datat
&I-D.dhody-pce-pcep-extension-pce-controller-srv6; 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>
<reference anchor="MAP-REDUCE" target="http://leeky.me/publications/m <!-- [I-D.ietf-pce-segment-routing-policy-cp] IESG state: I-D Exists as of 06/06
apreduce_p2p.pdf"> /24-->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
e-segment-routing-policy-cp.xml"/>
<!-- [I-D.ietf-pce-binding-label-sid] Published as RFC 9604. Updated
reference and citation tags for [PCE-BINDING-LABEL-SID] to [RFC9604]. -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
604.xml"/>
<!-- [I-D.chen-pce-pcep-extension-pce-controller-bier] IESG state: Expired as of
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-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.dhody-pce-pcep-extension-pce-controller-srv6] IESG state:
Replaced by draft-ietf-pce-pcep-extension-pce-controller-srv6 as of
06/06/24. Updated URL and cite tag to use most current I-D. -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
e-pcep-extension-pce-controller-srv6.xml"/>
<reference anchor="MAP-REDUCE" target="https://leeky.me/publications/map
reduce_p2p.pdf">
<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> <!-- [rfced] Should "signalling" be moved before "protocols" in the
sentence below?
Original:
During the migration, the legacy nodes still need
to use the existing MPLS protocols signalling such as LDP and RSVP-
TE...
Perhaps:
During the migration, the legacy nodes still need
to use the existing MPLS signalling protocols such as LDP and RSVP-
TE...
-->
<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 protocols signalling 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 | | | | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | |
skipping to change at line 1597 skipping to change at line 2192
| | PCEP | | PCEP | | | | PCEP | | PCEP | |
| V V V V | | V V V V |
| +--------+ +--------+ +--------+ +--------+ +--------+ | | +--------+ +--------+ +--------+ +--------+ +--------+ |
| | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | | | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | |
| | |...| |...| |...| |...| | | | | |...| |...| |...| |...| | |
| | 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 head
out-segment of Node4, and the in-segment for Node5.</t> end (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, Node 3 could proxy the s
ignalling.
</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 Layer 3 VPNs <xref target="RFC4364" format="default"/> or
Virtual Private Network (VPN) services (such as Layer 3 VPNs Ethernet VPNs <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 PCE-based central controller 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 <!-- [auth] <t>
between those resources.</t>
<!--<t>
The existing services using MPLS LSP tunnels based on MPLS signaling The existing services using MPLS LSP tunnels based on MPLS signaling
mechanism such L3VPN, PWE3 and IPv6 can be simplified by using the mechanism such L3VPN, PWE3 and IPv6 can be simplified by using the
PCECC for label assignments for the L3VPN, PWE3 and PCECC for label assignments for the L3VPN, PWE3 and
IPv6 as well.</t>--> 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 | | NODE x | | PE2 | | | CE |
| |...... | |...| |...| |.....| | | |...... | |...| |...| |.....| |
| Legacy | |if1 | PCECC |if2|PCCEC |if3| PCECC |if4 | Legacy | | Legacy | |if1 | PCECC |if2|PCCEC |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 <!-- [auth] performs by
DataNodes and also has Rack-awareness. Currently, transport protocols means of Master-Slave architecture-->in the Hadoop Distributed File System (H
DFS), 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 traditional 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 bandwidth 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 2382
| | | | | | | | | | | | | | | |
+-------------+ | | | | +----------+ +-------------+ | | | | +----------+
+------------------+ | +-----------+ +------------------+ | +-----------+
| | | | | | | |
|---+-----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> <t>Communication between the JobTracker, NameNode, and PCECC can be done
Phase 1: Distributed cluster resources discovery via REST API directly or via a cluster manager such as Mesos.</t>
During this phase, JobTracker and NameNode should identify and find available <ul>
DataNodes according to computing requests from the application (APP). <li>
NameNode should query PCECC about available DataNodes, NameNode may <t>
provide additional constraints to PCECC such as topological proximity, Phase 1: Distributed cluster resource discovery occurs during this
and redundancy level.</t> 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> <section anchor="sect-14" numbered="false" toc="default">
PCECC should analyze the topology of the distributed cluster and perform <name>Acknowledgments</name>
constraint-based path calculation from the client towards the most <t>Thanks to <contact fullname="Adrian Farrel"/>, <contact
suitable NameNodes. PCECC should reply to NameNode with the list of the most fullname="Aijun Wang"/>, <contact fullname="Robert Tao"/>, <contact
suitable DataNodes and their resource capabilities. The topology discovery fullname="Changjiang Yan"/>, <contact fullname="Tieying Huang"/>,
mechanism for PCECC will be added later to that framework.</t> <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 2: PCECC should create P2MP LSP from the client towards those <name>Contributors</name>
DataNodes by means of PCEP messages following the previously calculated path.
</t>
<t>Phase 3. NameNode should send this information to the client, and PCECC sho <contact fullname="Luyuan Fang">
uld inform <organization></organization>
the client about the optimal P2MP path towards DataNodes via PCEP message. <address>
</t> <postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>United States of America</country>
</postal>
<email>luyuanf@gmail.com</email>
</address>
</contact>
<t> <contact fullname="Chao Zhou">
Phase 4. The Client sends data blocks to those DataNodes for writing via <organization>HPE</organization>
the created P2MP tunnel.</t> <address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>chaozhou_us@yahoo.com</email>
</address>
</contact>
<t> <contact fullname="Boris Zhang">
When this task is finished, the P2MP tunnel could be turned down.</t> <organization>Amazon</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>zhangyud@amazon.com</email>
</address>
</contact>
</section> <contact fullname="Artsiom Rachytski">
</section> <organization></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>Belarus</country>
</postal>
<email>arachyts@gmail.com</email>
</address>
</contact>
Luyuan Fang <contact fullname="Anton Gulida">
United States of America <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: luyuanf@gmail.com <!-- [rfced] We note that paths appear to be formatted differently throughout
this document. Should they appear in quotation marks or without any additional
text styling?
Chao Zhou Original (some examples):
HPE
Email: chaozhou_us@yahoo.com 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.
...
In this step, we will
have two paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3
...
* PCECC will provision each node along the path and assign incoming
and outgoing labels from R1 to R8 with the path as
"R1-link1-R2-link3-R4-link10-R3-link8-R8":
-->
Boris Zhang <!-- [rfced] Should spaces appear between values (90012,1002,90024, etc.)?
Amazon
Email: zhangyud@amazon.com Original (some examples):
Artsiom Rachytski * For the end-to-end protection, PCECC can provision the secondary
Belarus path (R1-link2-R2-link4-R5-R8): {90012,1002,90024,1005,1008}.
...
As shown in Figure 3, R1 may send a packet to R8 by pushing an SR
header with segment list {1002, 9001, 1008}.
-->
Email: arachyts@gmail.com <!-- [rfced] Terminology
Anton Gulida a) Should instances of "PCEP protocol" be updated to read simply
EPAM Systems, Inc. "PCEP" to avoid redundancy (if expanded, "PCEP protocol" would read "Path
Belarus Computation Element Communication Protocol protocol")? Please review and
let us know if any updates are needed.
Email: Anton_Hulida@epam.com b) We note use of the terms "PCE-based controller" and "PCE-based central
]]></artwork> controller". Should these be updated to "PCECC"?
</figure></t>
</section>
</back>
</rfc> Original (some examples):
For this to work, the PCE-based controller will take responsibility
for managing some part of the MPLS label space for each of the
routers that it controls.
...
A PCE-based central controller can consider the whole
network and all components of a service at once when planning how to
deliver the service.
c) FYI - The terms below have been updated to match how they appear in RFCs
8279 and 9262. Please review and let us know any objections.
Original / Current:
bitmask / BitMask
BFR-ID / BFR-id
subdomain-ID / sub-domain-id
BIER Encapsulation / BIER encapsulation
d) We note the following differences in the use of the terms below. Please
review and let us know how to update each item for consistency.
headend v. head end
NODE 1 v. Node1 v. Node 3 (regarding spacing and capitalization)
-->
<!-- [rfced] Abbreviations
a) FYI - we have added expansions for "AS" and "ASBR" to the Terminology section
to avoid awkward expansions in the body of the text. Please let us know any
objections.
b) To match usage in RFC 5440, may we expand and update "TEDB" to "Traffic
Engineering Database (TED)" ?
Original:
* Since PCECC is aware of TEDB (TE state) and LSP-DB...
Perhaps:
* Since PCECC is aware of Traffic Engineering Database (TED) (TE state)
and LSP-DB...
c) How should "NBI" be expanded in the text below?
Original:
* After the operator's application or service orchestrator creates a
request for tunnel creation of a specific service, PCECC will
receive that request via NBI (NBI type is implementation
dependent, it could be NETCONF/Yang, REST etc.).
d) We note two different expansions of "TE" in this document. Should these
be updated for consistency?
traffic-engineered (TE)
Traffic Engineering (TE)
e) This document has mixed usage of the expanded and abbreviated forms of the
following terms. After they are expanded upon first use, may we replace all
instances thereafter with the abbreviated form (per guidance from the Web
Portion of the Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)?
Objective Function (OF)
bandwidth (BW)
Path Setup Type (PST)
Segment Routing (SR)
load balancing (LB)
Layer 3 VPN (L3VPN)
Ethernet VPN (EVPN)
f) FYI - We have updated the expansion for CCDR to match how it appears in
RFC 8735. Please let us know any objections.
Original:
Centrally Control Dynamic Routing (CCDR)
Current:
Centralized Control Dynamic Routing (CCDR)
g) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Hierarchical PCE (H-PCE)
LSP Database (LSP-DB) (per RFC 8283)
Network Processing Unit (NPU)
Open vSwitch (OVS)
Provider Edge (PE)
Service Level Agreement (SLA)
Service Function Forwarder (SFF)
SR over MPLS (SR-MPLS)
SR over IPv6 (SRv6)
-->
<!-- [rfced] FYI - There are several author comments in the XML file. These have
been
marked with [auth]. Please review these and let us know if any updates are need
ed
based on those comments, as they will be removed before publication.
-->
<!-- [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.
a) For example, please consider whether "native" should be updated in the text
below:
Original:
Section 3.9. PCECC for Native IP
Figure 12: PCECC for Native IP
...traffic engineering for native IP networks. [RFC8821] defines the
framework for CCDR traffic engineering within a Native IP network...
b) In addition, please consider whether "tradition" should be updated for
clarity. While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-a
uthor-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
Original:
The traditional IP-based multicast may not be appropriate because it...
-->
</back>
</rfc>
 End of changes. 267 change blocks. 
1391 lines changed or deleted 2037 lines changed or added

This html diff was produced by rfcdiff 1.48.