<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="utf-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC4206 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4206.xml">zwsp "​"> <!ENTITYRFC5150 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5150.xml">nbhy "‑"> <!ENTITYRFC5151 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5151.xml"> <!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"> <!ENTITY RFC5441 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5441.xml"> <!ENTITY RFC5541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml"> <!ENTITY RFC5376 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5376.xml"> <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC8231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"> <!ENTITY RFC8281 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"> <!ENTITY RFC8283 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8283.xml"> <!ENTITY RFC8355 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8355.xml"> <!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"> <!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"> <!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"> <!ENTITY RFC3985 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3985.xml"> <!ENTITY RFC7665 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"> <!ENTITY RFC8279 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml"> <!ENTITY RFC8986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"> <!ENTITY RFC9168 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9168.xml"> <!ENTITY RFC8821 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8821.xml"> <!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"> <!ENTITY RFC7399 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7399.xml"> <!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"> <!ENTITY RFC7491 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7491.xml"> <!ENTITY RFC9256 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"> <!ENTITY RFC9012 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"> <!ENTITY RFC8300 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"> <!ENTITY I-D.chen-pce-bier SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.chen-pce-bier.xml"> <!ENTITY RFC8664 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"> <!ENTITY RFC8751 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8751.xml"> <!ENTITY RFC8754 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"> <!ENTITY RFC7025 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7025.xml"> <!ENTITY RFC9087 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9087.xml"> <!ENTITY RFC9262 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9262.xml"> <!ENTITY RFC9491 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9491.xml"> <!ENTITY RFC9522 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9522.xml"> <!ENTITY RFC9552 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"> <!ENTITY RFC8955 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml"> <!ENTITY RFC4456 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4456.xml"> <!ENTITY RFC8408 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.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/public/rfc/bibxml3/reference.I-D.ietf-pce-stateful-interdomain.xml"> <!ENTITY RFC9050 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9050.xml"> <!ENTITY I-D.ietf-pce-pcep-extension-pce-controller-sr SYSTEM "https://xml2rfc.ietf.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/public/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://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.chen-pce-pcep-extension-pce-controller-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://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.dhody-pce-pcep-extension-pce-controller-srv6.xml"> <!ENTITY I-D.ietf-mpls-seamless-mpls SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-seamless-mpls.xml"> <!ENTITY RFC1195 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"> <!ENTITY RFC2328 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"> <!ENTITY RFC5340 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"> <!ENTITY RFC8735 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8735.xml"> <!ENTITY RFC3209 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"> <!ENTITY RFC5036 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"> <!ENTITY RFC9262 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9262.xml">wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-teas-pcecc-use-cases-18" number="9689" 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"?>consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3"> <front> <title abbrev="PCECC">Use Cases for a PCE as a Central Controller (PCECC)</title> <seriesInfo name="RFC" value="9689"/> <author fullname="Zhenbin (Robin) Li" initials="Z." surname="Li"> <organization>Huawei Technologies</organization> <address> <postal> <street>Huawei Bld., No.156 Beiqing Rd.</street> <city>Beijing</city><region></region><code>100095</code> <country>China</country> </postal> <email>lizhenbin@huawei.com</email> </address> </author> <author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <organization>Huawei Technologies</organization> <address> <postal><street></street> <city></city> <region></region><country>India</country> </postal> <email>dhruv.ietf@gmail.com</email> </address> </author> <author initials="Q" surname="Zhao" fullname="Quintin Zhao"> <organization>Etheric Networks</organization> <address> <postal> <street>1009 SCLAREMONT ST</street> <city>SAN MATEO</city>Claremont St.</street> <city>San Mateo</city> <region>CA</region> <code>94402</code><country>USA</country><country>United States of America</country> </postal> <email>qzhao@ethericnetworks.com</email> </address> </author> <author fullname="King He" initials="K." surname="He"> <organization>Tencent Holdings Ltd.</organization> <address> <postal><street></street><city>Shenzhen</city><region></region><country>China</country> </postal> <email>kinghe@tencent.com</email> </address> </author> <author fullname="Boris Khasanov" initials="B." surname="Khasanov"> <organization>Yandex LLC</organization> <address> <postal> <street>Ulitsa Lva Tolstogo 16</street> <city>Moscow</city><region></region> <code></code> <country>Russia</country><country>Russian Federation</country> </postal> <email>bhassanov@yahoo.com</email> </address> </author><!--<author<!-- [auth] <author fullname="Luyuan Fang" initials="L." surname="Fang"> <organization>Expedia, Inc.</organization> <address> <postal> <street></street> <city></city> <region></region> <country>USA</country> </postal> <email>luyuanf@gmail.com</email> </address> </author> <author initials="C" surname="Zhou" fullname="Chao Zhou"> <organization>HPE</organization> <address> <postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal> <email>chaozhou_us@yahoo.com</email> </address> </author> <author fullname="Boris Zhang" initials="B." surname="Zhang"> <organization>Telus Communications</organization> <address> <postal> <street></street> <city></city> <region></region> <country></country> </postal> <email>Boris.zhang@telus.com</email> </address> </author> <author fullname="Artem Rachitskiy" initials="A." surname="Rachitskiy"> <organization>Mobile TeleSystems JLLC</organization> <address> <postal> <street>Nezavisimosti ave., 95</street> <city>Minsk</city> <code>220043</code> <region></region> <country>Belarus</country> </postal> <email>arachitskiy@mts.by</email> </address> </author> <author fullname="Anton Gulida" initials="A." surname="Gulida"> <organization>LLC "Lifetech"</organization> <address> <postal> <street>Krasnoarmeyskaya str., 24</street> <city>Minsk</city> <code>220030</code> <region></region> <country>Belarus</country> </postal> <email>anton.gulida@life.com.by</email> </address> </author> --><date/> <workgroup>TEAS Working Group</workgroup><date month="November" year="2024"/> <area>RTG</area> <workgroup>teas</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t>The PCE is a core component of a Software-Defined Networking (SDN) 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 thansignaledsignalled MPLStraffic-engineered (TE)TE networks, and the PCE may be used to determine paths in a range of use cases including staticLSPs,Label-Switched Paths (LSPs), Segment Routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network.It is, therefore,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. PCEPextensionsextensions, which are required for the PCECC usecasescases, are covered in separate documents.</t><!--<t>This<!-- [auth] <t>This is a living document to catalog the use cases for PCECC. There is currently no intention to publish this work as an RFC. [Update: Chairs are evaluating if the document should be published instead.]</t>--> </abstract><!--<note<!-- [auth] <note title="Requirements Language"> <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </note>--> </front> <middle> <sectiontitle="Introduction" anchor="sect-1">anchor="sect-1" numbered="true" toc="default"> <name>Introduction</name> <t>The PCE <xreftarget="RFC4655"/>target="RFC4655" format="default"/> was developed to offload 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 the network or traffic demands. The role and function of the PCE have grown to cover several other uses (such as GMPLS <xreftarget="RFC7025"/>target="RFC7025" format="default"/> orMulticast),Multicast) and to allow delegated stateful control <xreftarget="RFC8231"/>target="RFC8231" format="default"/> and PCE-initiated use of network resources <xreftarget="RFC8281"/>.</t>target="RFC8281" format="default"/>.</t> <t>According to <xreftarget="RFC7399"/>,target="RFC7399" format="default"/>, Software-Defined Networking (SDN) refers to a separation between the control elements and the forwarding components so that software running in a centralized system, called acontroller,"controller", can act to program the devices in the network to behave in specific ways. A required element in an SDN architecture is a component that plans how the network resources will be used and how the devices will be programmed. It is possible to view this component as performing specific computations to place traffic flows within the network given knowledge of the availability of the network resources, how other forwarding devices are programmed, and the way 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 system (including an SDN system) is presented in <xreftarget="RFC7491"/>.</t>target="RFC7491" format="default"/>.</t> <!--[rfced] The text below suggests that RFC 8283 (rather than a person) can "assume" something. Since we try to avoid the personification of RFCs, 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 the PCE and PCC. 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><xreftarget="RFC8283"/>target="RFC8283" format="default"/> introduces the architecture for the PCE as a central controller as an extension to the architecture described in <xreftarget="RFC4655"/>target="RFC4655" format="default"/> and assumes the continued use of PCEP as the protocol used between the PCE andPCC.Path Computation Client (PCC). <xreftarget="RFC8283"/>target="RFC8283" format="default"/> further examines the motivations and applicability of PCEP as a Southbound Interface (SBI) and introduces the implications for the protocol. </t><!--<t><!-- [auth] <t> An Architecture for Use of PCE and PCEP <xref target="RFC5440"/> in a Network with Central Control <xref target="RFC8283"/> describes a SDN architecture where the Path Computation Element (PCE) determines the paths for variety of different usecases, with PCEP as a general southbound communication protocol with all the nodes along the path.</t>--> <t><xreftarget="RFC9050"/>target="RFC9050" format="default"/> introduces the procedures and extensions for PCEP to support the PCECC architecture <xreftarget="RFC8283"/>.</t>target="RFC8283" format="default"/>.</t> <t> This document describes the various use cases for the PCECC architecture.</t><!--<t>This<!-- [auth] <t>This is a living document to catalog the use cases for PCECC. There is currently no intention to publish this work as an RFC. [Update: Chairs are evaluating if the document should be published instead.]</t>--> </section> <sectiontitle="Terminology" anchor="sect-2">anchor="sect-2" numbered="true" toc="default"> <!--[rfced] FYI - We have ordered the list of terms in Section 2 alphabetically. Please let us know of any objections. --> <name>Terminology</name> <t> The following terminology is used in this document.<list style="hanging" hangIndent="0"> <t hangText="BGP-LS:"></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 <xreftarget="RFC9552"/>. </t> <t hangText="LSP:"> Label Switched Path. </t> <t hangText="IGP:"> Interiortarget="RFC9552" format="default"/></dd> <dt>IGP:</dt> <dd>Interior GatewayProtocol. In theProtocol (in this document, we assume IGP as either Open Shortest Path First (OSPF) <xreftarget="RFC2328"/><xref target="RFC5340"/>target="RFC2328" format="default"/> <xref target="RFC5340" format="default"/> or Intermediate System to Intermediate System (IS-IS) <xreftarget="RFC1195"/> as IGP. </t> <t hangText="PCC:"> Pathtarget="RFC1195" format="default"/>)</dd> <dt>LSP:</dt> <dd>Label-Switched Path</dd> <dt>PCC:</dt> <dd>Path ComputationClient. AsClient (as per <xreftarget="RFC4655"/>,target="RFC4655" format="default"/>, any client application requesting a path computation to be performed by aPathPCE)</dd> <dt>PCE:</dt> <dd>Path ComputationElement. </t> <t hangText="PCE:"> Path Computation Element. AsElement (as per <xreftarget="RFC4655"/>,target="RFC4655" format="default"/>, an entity(component,such as a component, application, or networknode)node that is capable of computing a network path or route based on a network graph and applying computationalconstraints. </t> <t hangText="PCECC:"> PCEconstraints)</dd> <dt>PCECC:</dt> <dd>PCE as a CentralController. ExtensionController (an extension of a PCE to support SDN functions as per <xreftarget="RFC8283"/>. </t> <t hangText="PST:"> Pathtarget="RFC8283" format="default"/>)</dd> <dt>PST:</dt> <dd>Path Setup Type <xreftarget="RFC8408"/>. </t> <t hangText="RR:"> Routetarget="RFC8408" format="default"/></dd> <dt>RR:</dt> <dd>Route Reflector <xreftarget='RFC4456'/>. </t> <t hangText="SID:"> Segmenttarget="RFC4456" format="default"/></dd> <dt>SID:</dt> <dd>Segment Identifier <xreftarget='RFC8402'/>. </t> <t hangText="SR:"> Segmenttarget="RFC8402" format="default"/></dd> <dt>SR:</dt> <dd>Segment Routing <xreftarget='RFC8402'/>. </t> <t hangText="SRGB:"> Segmenttarget="RFC8402" format="default"/></dd> <dt>SRGB:</dt> <dd>Segment Routing Global Block <xreftarget='RFC8402'/>. </t> <t hangText="SRLB:"> Segmenttarget="RFC8402" format="default"/></dd> <dt>SRLB:</dt> <dd>Segment Routing Local Block <xreftarget='RFC8402'/>. </t> <t hangText="TE:"> Traffictarget="RFC8402" format="default"/></dd> <dt>TE:</dt> <dd>Traffic Engineering <xreftarget='RFC9522'/>. </t> </list></t>target="RFC9522" format="default"/></dd> </dl> </section> <sectiontitle="Use Cases">numbered="true" toc="default"> <name>Use Cases</name> <t><xreftarget="RFC8283"/>target="RFC8283" format="default"/> describes various use cases for a PCECC such as:<list style="symbols"> <t>Use</t> <ul spacing="normal"> <li> use of a PCECC to set upStaticstatic TELSPs. TheLSPs (the PCEP extension for this use case is in <xreftarget="RFC9050"/>.</t> <t>Usetarget="RFC9050" format="default"/>) </li> <li> use of a PCECC in Segment Routing <xreftarget="RFC8402"/>.</t> <t>Usetarget="RFC8402" format="default"/> </li> <li> use of a PCECC to set up Multicast Point-to-Multipoint (P2MP)LSP.</t> <t>UseLSPs </li> <li> use of a PCECC to set up Service Function Chaining (SFC) <xreftarget="RFC7665"/>.</t> <t>Usetarget="RFC7665" format="default"/> </li> <li> use of a PCECC inOptical Networks.</t> </list> </t>optical networks </li> </ul> <t><xreftarget="sect-3"/>target="sect-3" format="default"/> describes the general case of a PCECC being in charge of managing MPLS labelspacespace, which is a prerequisite for further use cases. Further, various use cases (SR,Multicast etc)Multicast, etc.) are described in the following sections to showcase scenarios that can benefit from the use of a PCECC. </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> <sectiontitle="PCECCanchor="sect-3" numbered="true" toc="default"> <name>PCECC for LabelManagement" anchor="sect-3">Management</name> <t>As per <xreftarget="RFC8283"/>,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 that it controls, and it may take wider responsibility for partitioning the label space for each router and allocating different parts for different uses, communicating the ranges to the router using PCEP.</t> <t><xreftarget="RFC9050"/>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 tocontrol. (Seecontrol (see <xreftarget="I-D.li-pce-controlled-id-space"/>target="I-D.ietf-pce-controlled-id-space" format="default"/> for a possible PCEP extension to support the advertisement of the MPLS label spacetofor the PCE tocontrol.)</t>control).</t> <t><xreftarget="RFC8664"/>target="RFC8664" format="default"/> specifies extensions to PCEP that allow a stateful PCE to compute,updateupdate, or initiate SR-TE paths. <xreftarget="I-D.ietf-pce-pcep-extension-pce-controller-sr"/>target="I-D.ietf-pce-pcep-extension-pce-controller-sr" format="default"/> describes the mechanism for a PCECC to allocate and provision the node/prefix/ adjacency label (Segment Routing Identifier (SID)) via PCEP. To make such anallocationallocation, the PCE needs to be aware of the label space from the Segment Routing Global Block (SRGB) or Segment Routing Local Block (SRLB) <xreftarget="RFC8402"/>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 control is needed within the PCEP. The full SRGB/SRLB of a node could be learned via existing IGP or BGP-LS <xreftarget="RFC9552"/>target="RFC9552" format="default"/> mechanisms.</t><t>Further,<!--[rfced] FYI - We have updated the text below for clarity. Please review and let us know if this has changed the intended meaning. 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 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><!--<t><!-- [auth] <t> This use case is based on network configuration illustrated using the following figure:</t>--> <figuretitle="PCECCanchor="fig_label"> <name>PCECC for MPLS LabelManagement" anchor="fig_label"><artwork><![CDATA[Management</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +------------------------------+ +------------------------------+ | PCE DOMAIN 1 | | PCE DOMAIN 2 | | +--------+ | | +--------+ | | | | | | | | | | | PCECC1 | ---------PCEP---------- | PCECC2 | | | | | | | | | | | | | | | | | | | +--------+ | | +--------+ | | ^ ^ | | ^ ^ | | / \ PCEP | | PCEP / \ | | V V | | V V | | +--------+ +--------+ | | +--------+ +--------+ | | |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| | | | | ...... | | | | | | ...... | | | | | PCECC | | PCECC | | | | PCECC | |PCECC | | | |Enabled | | Enabled| | | |Enabled | |Enabled | | | +--------+ +--------+ | | +--------+ +--------+ | | | | | +------------------------------+ +------------------------------+ ]]></artwork> </figure><t><list style="symbols"><t>As<!-- [rfced] Should an introductory sentence be added to the list that appears after Figure 1 to provide context for the proceeding text? Original: Figure 1: PCECC for MPLS Label Management * As shown in<xref target="fig_label"/>,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]). Perhaps: 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 <xreftarget="RFC9050"/>.</t>target="RFC9050" format="default"/>.</t> </li> <li> <t>The PCECC could also learn the label range set aside by the PCC (via <xreftarget="I-D.li-pce-controlled-id-space"/>). </t>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 thenetwork. <list style="symbols">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></list></t> </list> </t></li> </ul> </li> </ul> <t>As per <xreftarget="RFC9050"/>,target="RFC9050" format="default"/>, the PCECC could also rely on the PCC to make label allocations initially and use PCEP to distribute it to where it is needed.</t> </section> <sectiontitle="PCECCanchor="sect-4" numbered="true" toc="default"> <name>PCECC and SegmentRouting" anchor="sect-4">Routing</name> <t>Segment Routing (SR) <xreftarget="RFC8402"/>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 <xreftarget="RFC5036"/>target="RFC5036" format="default"/> or RSVP-TE <xreftarget="RFC3209"/>.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 thenetwork,network or to perform a specific service on the packet. A database of segments can be distributed through the network usingaan intra-domain routing protocol (such as IS-IS orOSPF) orOSPF), an inter-domain protocol(BGP),(such as BGP), or by any other means. PCEP could also be one of other protocols.</t> <t><xreftarget="RFC8664"/>target="RFC8664" format="default"/> specifies theSR-specificPCEP extension specific to SR forSR-MPLS.SR over MPLS (SR-MPLS). The PCECC may further use the PCEP protocol for distributing SRSIDs (Segment Identifiers) distributionSegment Identifiers (SIDs) to the SR nodes (PCC) with some benefits. If the PCECC allocates and maintains the SIDs in the network for the nodes andadjacencies;adjacencies, and further distributes them to the SR nodes directly via the PCEPsessionsession, then it is more advantageous over the configurations on each SR node and flooding them via IGP, especially in an SDN environment. </t><!--<t><!-- [auth] <t> For the centralized network, the performance achieved through distributed system can not be easy matched if all of the forwarding paths are computed, downloaded and maintained by the centralized controller. The performance can be improved by supporting part of the forwarding path in the PCECC network through the segment routing mechanism except that node segment IDs and adjacency segment IDs for all the network are allocated dynamically and propagated through the centralized controller instead of using the IGP extensions.</t>--> <t> 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 SRGB of thenode. For the allocation of Adj-SID,node and theallocationAdj-SID is allocated from the SRLB of the node as described in <xreftarget="I-D.ietf-pce-pcep-extension-pce-controller-sr"/>.</t>target="I-D.ietf-pce-pcep-extension-pce-controller-sr" format="default"/>.</t> <t><xreftarget="RFC8355"/>target="RFC8355" format="default"/> identifies various protection and resiliencyusecasesuse cases for SR. Path protection lets the ingress node be in charge of the failure recovery (used for SR-TE <xreftarget="RFC8664"/>).target="RFC8664" format="default"/>). Also, protection can be performed by the node adjacent to the failed component, commonly referred to aslocal"local protectiontechniquestechniques" orfast-reroute"fast-reroute (FRR)techniques.techniques". In the case of the PCECC, the protection paths can bepre-computedprecomputed and set up by the PCE.</t> <t>The<xreftarget="fig_sr"/>target="fig_sr" format="default"/> illustrates the use case where the Node-SID and Adj-SID are allocated by the PCECC for SR-MPLS.</t> <figuretitle="SR Topology" anchor="fig_sr"><artwork><![CDATA[anchor="fig_sr"> <name>SR Topology</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 192.0.2.1/32 +----------+ | R1(1001) | +----------+ | +----------+ | R2(1002) | 192.0.2.2/32 +----------+ * | * * * | * * *link1| * * 192.0.2.4/32 * | *link2 * 192.0.2.5/32 +-----------+ 9001| * +-----------+ | R4(1004) | | * | R5(1005) | +-----------+ | * +-----------+ * | *9003 * + * | * * + * | * * + +-----------+ +-----------+ 192.0.2.3/32 | R3(1003) | |R6(1006) |192.0.2.6/32 +-----------+ +-----------+ | +-----------+ | R8(1008) | 192.0.2.8/32 +-----------+ ]]></artwork> </figure> <sectiontitle="PCECCanchor="sect-4.1" numbered="true" toc="default"> <name>PCECC SID Allocation forSR-MPLS" anchor="sect-4.1" >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 the other nodes in the domain. After receiving the label mapping, each node (PCC) uses the local routing information to determine thenexthopnext hop and download the label forwarding instructions accordingly. The forwardingbehaviourbehavior and the end result are the same as IGP shortest-path SR forwarding based onNode-SID.Node-SIDs. Thus, from anywhere in the domain, it enforces the ECMP-aware shortest-path forwarding of the packet towards the related node.</t><t>For each adjacency in the network, a<t>The PCECC can allocate anAdj-SID.Adj-SID for each adjacency in the network. The PCECC sends a PCInitiate message to update the label mapping of each adjacency to the corresponding nodes in the domain. Each node (PCC) downloads the label forwarding instructions accordingly. The forwardingbehaviourbehavior and the end result are similar to IGP-based Adj-SID allocation and usage in SR.</t> <t>These mechanisms are described in <xreftarget="I-D.ietf-pce-pcep-extension-pce-controller-sr"/>.</t>target="I-D.ietf-pce-pcep-extension-pce-controller-sr" format="default"/>.</t> </section> <sectiontitle="PCECCanchor="sect-4.2" numbered="true" toc="default"> <name>PCECC for SR-MPLS Best Effort (BE)Path" anchor="sect-4.2"><t>Paths</name> <!-- [rfced] Section 3.2.2 begins with the text below; how may we rephrase to clarify what "this use case" refers to? Original: 3.2.2. PCECC for SR-MPLS Best Effort (BE) Path In this use case, the PCECC needs to allocate the Node-SID (without calculating the explicit path for the SR path). Perhaps: 3.2.2. PCECC for SR-MPLS Best Effort (BE) Path When using PCECC for SR-MPLS Best Effort (BE) Paths, the PCECC needs to allocate the Node-SID (without calculating the explicit path for the SR path). --> <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 segment {1008} (Node-SID for R8). The path will be based on therouting/nexthoprouting / next hop calculation on the routers.</t> </section> <sectiontitle="PCECCanchor="sect-4.3" numbered="true" toc="default"> <name>PCECC for SR-MPLS TEPath" anchor="sect-4.3"> <t>SR-TEPaths</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 theAdj-SIDAdj-SIDs arestacked,stacked; otherwise, a combination ofnode-SIDNode-SIDs oradj-SIDAdj-SIDs can be used for the SR-TE paths.</t><t>As<t> As shown in <xreftarget="fig-sr-te"/>,target="fig-sr-te" format="default"/>, R1 may send a packet to R8 by pushing an SR header with segment list {1002, 9001,1008}. Where1008}, where 1002 and 1008 are theNode-SIDNode-SIDs of R2 andR8R8, 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 <xreftarget="sect-4.1"/>.target="sect-4.1" format="default"/>. <xreftarget="RFC8664"/>target="RFC8664" format="default"/> describes the mechanism for a PCE to compute, update, or initiate SR-MPLS TE paths. </t> <figuretitle="PCECCanchor="fig-sr-te"> <name>PCECC TE LSP SetupExample" anchor="fig-sr-te"><artwork><![CDATA[Example</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 192.0.2.1/32 +----------+ | R1 (1001)| +----------+ | | 90011 | |90012 link1 | |link2 +----------+ | R2 (1002)| 192.0.2.2/32 +----------+ link3 * | * * link4 90023 * | * * 90024 *link5| * * 192.0.2.4/32 *90025 | *link6 * 192.0.2.5/32 +-----------+ | *90026+-----------+ | R4 (1004) | | * | R5 (1005) | +-----------+ | * +-----------+ * | * + link10 * | * link7 + * | * + +-----------+ +-----------+ 192.0.2.3/32 | R3 (1003) | |R6 (1006) |192.0.2.6/32 +-----------+ +-----------+ | | |link8 | | |----------|link9 +-----------+ | R8 (1008) | 192.0.2.8/32 +-----------+ ]]></artwork> </figure><t>Refer<t> Refer to <xreftarget="fig-sr-te"/>target="fig-sr-te" format="default"/> for an example of TE topology,where,where 100x-are Node-SIDs and 900xx-are Adj-SIDs.<list style="symbols"></t> <ul spacing="normal"> <li> <t>The SID allocation and distribution are done by the PCECC with all Node-SIDs (100x) and all Adj-SIDs (900xx).</t> </li> <li> <t>Based on path computation request/delegation or PCE initiation, the PCECC receives a request with constraints and optimization criteria from aPCC. </t> <t>PCECCPCC.</t> </li> <li> <t>The PCECC will calculate the optimal path according to the given constraints(e.g. bandwidth). </t> <t>(e.g., bandwidth).</t> </li> <li> <t>The PCECC will provision the SR-MPLS TE LSP(path R1-link1-R2-link6-R3-R8)path (R1-link1-R2-link6-R3-R8) at the ingress node: {90011,1002,90026,1003,1008}</t> </li> <li> <t>For the end-to-end protection, the PCECC can provision the secondary path (R1-link2-R2-link4-R5-R8): {90012,1002,90024,1005,1008}.</t></list></t></li> </ul> <sectiontitle="PCECCanchor="sect-4.4" numbered="true" toc="default"> <name>PCECC for SRPolicy" anchor="sect-4.4">Policy</name> <t><xreftarget="RFC8402"/>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>An SR Policy architecture is described in <xreftarget="RFC9256"/>.target="RFC9256" format="default"/>. An SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing policy for the steering of traffic for a specific purpose(e.g.(e.g., for a specificSLA)Service Level Agreement (SLA)) from that node.</t> <t>An SR Policy is identified through the tuple <headend, color,endpoint>. </t>endpoint>.</t> <t><xreftarget="fig-sr-te"/>target="fig-sr-te" format="default"/> is used as an example of PCECC application for SR Policy instantiation for SR-MPLS,where, 100x - arewhere the Node-SIDs are 100x and900xx -the Adj-SIDs areAdj-SIDs.</t>900xx.</t> <t>Let's assume that R1 needs to have two disjoint SR Policies towards R8 based on differentbandwidths,bandwidths. This means the possible pathsare: <list> <t>POL1:are:</t> <ul> <li> POL1: {Headend R1, color 100, Endpoint R8; Candidate Path1: Segment List 1:{90011,1002,90023,1004,1003,1008}}</t> <t>POL2:{90011,1002,90023,1004,1003,1008}} </li> <li> POL2: {Headend R1, color 200, Endpoint R8; Candidate Path1: Segment List 1:{90012,1002,90024,1005,1006,1008}}</t> </list></t>{90012,1002,90024,1005,1006,1008}} </li> </ul> <t>Each SR Policy (including the candidate path and segment list) will be signalled to a headend (R1) via PCEP <xreftarget="I-D.ietf-pce-segment-routing-policy-cp"/>target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/> with the addition of an ASSOCIATION object. A Binding SID (BSID) <xreftarget="RFC8402"/>target="RFC8402" format="default"/> can be used for traffic steering of labelled traffic into an SRPolicy,Policy; a BSID can be provisioned from the PCECC also via PCEP <xreftarget="I-D.ietf-pce-binding-label-sid"/>.target="RFC9604" format="default"/>. For non-labelled traffic steering into the SR Policy POL1 or POL2, a per-destination traffic steering will be used by means of the BGP Colorextended communityExtended Community <xreftarget="RFC9012"/> </t> <t>target="RFC9012" format="default"/>.</t> <t>The procedure is as follows:</t> <ul> <li> Theprocedure: <list> <t>PCECC allocates Node-SIDs and Adj-SIDs using the mechanism described in <xreftarget="sect-4.1"/>target="sect-4.1" format="default"/> for all nodes and links.</t> <t></li> <li> The PCECCwill calculatecalculates disjoint paths for POL1 and POL2 and createSegment Listssegment lists forthem:{90011,1002,90023,1004,1003,1008};{90012,1002,90024,1005,1006,1008}.</t> <t>them: {90011,1002,90023,1004,1003,1008};{90012,1002,90024,1005,1006,1008}. </li> <li> The PCECCwill formforms both SR Policies POL1 andPOL2.</t> <t>POL2. </li> <li> The PCECCwill sendsends both POL1 andPOl2POL2 to R1 via PCEP.</t> <t></li> <li> The PCECC optionallycan allocateallocates BSIDs for the SRPolicies.</t> <t>ThePolicies. </li> <!-- [rfced] For clarity, can "w/ECMP" be updated to "with ECMP" in the text below? Original: Due to the possibility of having many Segment Lists in the same Candidate Path of each POL1/POL2, PCECC could provision more paths towards R8 and traffic will be balanced either as ECMP or as w/ECMP. Perhaps: 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 toR8R8, which fits to color100100, will be steered to POL1 and follows the path: R1-link1-R2-link3-R4-R3-R8. The traffic from R1 toR8R8, which fits color200200, will be steered to POL2 and follows the path: R1-link2-R2-link4-R5-R6-R8. Due to the possibility of having manySegment Listssegment lists in the sameCandidate Pathcandidate 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.</t> </list></t></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 <xreftarget="RFC9256"/>.</t>target="RFC9256" format="default"/>.</t> </section> </section> <sectiontitle="PCECCanchor="sect-8" numbered="true" toc="default"> <name>PCECC forSRv6" anchor="sect-8">SRv6</name> <t>As per <xreftarget="RFC8402"/>,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) <xreftarget="RFC8754"/>.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 theDestination Addressdestination 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 <xreftarget="RFC8754"/>,target="RFC8754" format="default"/>, anSRv6SR over IPv6 (SRv6) Segment is a 128-bit value. "SRv6 SID" or simply "SID" are often used as a shorter reference for "SRv6 Segment". <xreftarget="RFC8986"/>target="RFC8986" format="default"/> defines the SRv6 SID as consisting of LOC:FUNCT:ARG.</t> <t><xreftarget="I-D.ietf-pce-segment-routing-ipv6"/>target="RFC9603" format="default"/> extends <xreftarget="RFC8664"/>target="RFC8664" format="default"/> to support SR for the IPv6 data plane. Further, a PCECC could be extended to support SRv6 SID allocation and distribution. An example of how PCEP extensions could be extended for SRv6 for a PCECC is described in <xreftarget="I-D.dhody-pce-pcep-extension-pce-controller-srv6"/>.</t>target="I-D.ietf-pce-pcep-extension-pce-controller-srv6" format="default"/>.</t> <figuretitle="PCECCanchor="fig_srv6"> <name>PCECC forSRv6" anchor="fig_srv6"><artwork> <![CDATA[SRv6</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 2001:db8::1 +----------+ | R1 | +----------+ | +----------+ | R2 | 2001:db8::2 +----------+ * | * * * | * * *link1| * * 2001:db8::4 * | *link2 * 2001:db8::5 +-----------+ | * +-----------+ | R4 | | * | R5 | +-----------+ | * +-----------+ * | * * + * | * * + * | * * + +-----------+ +-----------+ 2001:db8::3 | R3 | |R6 |2001:db8::6 +-----------+ +-----------+ | +-----------+ | R8 | 2001:db8::8 +-----------+]]> </artwork></figure>]]></artwork> </figure> <t>In this case, as shown in <xreftarget="fig_srv6"/>,target="fig_srv6" format="default"/>, the PCECC could assign the SRv6 SID (in the form of an IPv6 address) to be used for node and adjacency. Later, the SRv6 path in the form of a list of SRv6 SIDs could be used at the ingress. Someexamples - <list style="symbols"> <t>SRv6 SID-List={2001:db8::8} -examples: </t> <ul spacing="normal"> <li> The best path towardsR8</t> <t>SRv6 SID-List={2001:db8::5, 2001:db8::8} -R8: SRv6 SID-List={2001:db8::8} </li> <li> The path towards R8 viaR5</t> </list></t>R5: SRv6 SID-List={2001:db8::5, 2001:db8::8} </li> </ul> <t>The rest of the procedures and mechanisms remain the same as SR-MPLS.</t> </section> </section> <sectiontitle="PCECCanchor="sect-5" numbered="true" toc="default"> <name>PCECC for Static TELSP" anchor="sect-5">LSPs</name> <t>As described inSection 3.1.2 of<xreftarget="RFC8283"/>,target="RFC8283" section="3.1.2" sectionFormat="of"/>, the PCECC architecture supports the provisioning of static TELSP.LSPs. To achieve this, the 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 end-to-end path. Each router along the path must be told what label-forwarding instructions to program and what resources to reserve. 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 communicate with each router along the path of the end-to-end LSP.</t> <figuretitle="PCECCanchor="fig-te"> <name>PCECC TE LSP SetupExample" anchor="fig-te"><artwork><![CDATA[Example</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 192.0.2.1/32 +----------+ | R1 | +----------+ | | |link1 | | |link2 +----------+ | R2 | 192.0.2.2/32 +----------+ link3 * | * * link4 * | * * *link5| * * 192.0.2.4/32 * | *link6 * 192.0.2.5/32 +-----------+ | * +-----------+ | R4 | | * | R5 | +-----------+ | * +-----------+ * | * * + link10 * | * *link7 + * | * * + +-----------+ +-----------+ 192.0.2.3/32 | R3 | |R6 |192.0.2.6/32 +-----------+ +-----------+ | | |link8 | | |link9 +-----------+ | R8 | 192.0.2.8/32 +-----------+ ]]></artwork> </figure> <t>Refer to <xreftarget="fig-te"/>target="fig-te" format="default"/> for an example TEtopology. <list style="symbols">topology.</t> <ul spacing="normal"> <li> <t>Based on path computation request/delegation or PCE initiation, the PCECC receives a request with constraints and optimizationcriteria. </t> <t>PCECCcriteria.</t> </li> <li> <t>The PCECC will calculate the optimal path according to the given constraints(e.g.(e.g., bandwidth).</t><t>PCECC</li> <li> <t>The 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":<list style="symbols"></t> <ul spacing="normal"> <li> <t>R1: Outgoing label 1001 on link 1</t> </li> <li> <t>R2: Incoming label 1001 on link 1</t> </li> <li> <t>R2: Outgoing label 2003 on link 3</t> </li> <li> <t>R4: Incoming label 2003 on link 3</t> </li> <li> <t>R4: Outgoing label 4010 on link 10</t> </li> <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></list></t></li> </ul> </li> <li> <t>This can also be representedasas: {R1, link1, 1001}, {1001, R2, link3,2003],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}, {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></list></t></li> </ul> </section> <sectiontitle="PCECCanchor="sect-lb" numbered="true" toc="default"> <name>PCECC for Load Balancing(LB)" anchor="sect-lb">(LB)</name> <t> Veryoftenoften, many service providers use TE tunnels for solving issues with non-deterministic paths in their networks. One example of such applications is the usage of TEs in the mobile backhaul (MBH). Consider the topology as shown in <xreftarget="fig_lb"/> (AGG1...AGGNtarget="fig_lb" format="default"/> (where AGG 1...AGG N are AggregationRouters,routers, and Core 1...Core N are Corerouters) -routers). </t> <!--[rfced] FYI - We have slightly adjusted the spacing and formatting of the ASCII artwork in Figure 6 as it exceeded the 72-character limit. Please review and let us know if any further changes are necessary. --> <figuretitle="PCECCanchor="fig_lb"> <name>PCECC Load Balancing (LB) UseCase" anchor="fig_lb"><artwork><![CDATA[Case</name> <artwork name="" type="" align="left" alt=""><![CDATA[ TE1--------------> +---------+ +--------+ +--------+-----------> +--------+ +------+ +-----+ +-------+ +------+ +---+| Access |----| Access |----| AGG 1 |----| AGG|Access |----|Access|----|AGG 1|----|AGG N-1|----|Core 1|--|SR1|| SubNode1| | Node 1 | +--------+ +--------+|SubNode1| |Node 1| +-----+ +-------+ +------+ +---++---------++--------+ +------+ | | | ^ | | Access | Access | AGG Ring1 |1| | | | SubRing 1 | Ring 1 | | | | |+---------+ +--------++--------+ +------+ +-----+ | | | |Access |Access | | Access | | AGG 2 | | | ||Access| |AGG 2| |SubNode2||Node 2|+--------+|SubNode2| |Node 2| +-----+ | | |+---------++--------+ +------+ | | | | | | | | | | | | | | |+----TE2----|-++---TE2---|-+ |+---------+ +--------+ +--------++--------+ +------+ +-----+ +-------+ +------+ +---+ |Access |Access | | Access |----| AGG 3 |----||Access|----|AGG 3|----| AGG N |----|Core N|--|SRn|| SubNodeN|----| Node N | +--------+ +--------+|SubNodeN|----|Node N| +-----+ +-------+ +------+ +---++---------++--------+ +------+ ]]></artwork> </figure> <t> 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 sub-ring. The access ring and aggregation ring are connected by Nx10GE interfaces. The aggregation domain runs its own IGP. There are twoEgressegress routers (AGGN-1,N-1 and AGG N) that are connected to the Core domain (Core 1...Core N) via L2 interfaces. The Core also has connections to servicerouters,routers; RSVP-TE or SR-TE is used for MPLS transport inside the ring. There could be at least2two tunnels (one way) from each AGG router to egress AGG routers. There are also many L2 access rings connected to AGG routers.</t><t><!-- [rfced] We have removed the parentheses around "Virtual Private LAN Services (VPLS)" in the text below. Please review and let us know if this changed the intended meaning of the text. Original: Service deployment is made by means of Layer 2 Virtual Private Networks (L2VPNs) (Virtual Private LAN Services (VPLS)), Layer 3 Virtual Private Networks (L3VPNs) or Ethernet VPNs (EVPNs). Current: Service deployment is made by means of Layer 2 Virtual Private Networks (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 Virtual Private Networks (L3VPNs), or Ethernet VPNs (EVPNs). --> <t> Service deployment is made by means of Layer 2 Virtual Private Networks (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 Virtual Private Networks (L3VPNs), 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 architecture based on seamless MPLS(<xref target="I-D.ietf-mpls-seamless-mpls"/>) based architecture.</t><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-CostMulti-PathMultipath (ECMP) and Unequal-CostMulti-PathMultipath (UCMP) based on the bandwidth of the TE tunnels.</t> <!-- [rfced] To improve readability, may we update this this text as follows? Additionally, should "HSI" be listed as an example of high-speed data services? Original: * 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. Perhaps: * Manage TE bandwidth (BW) and provide guaranteed BW for specific 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. --> <t>There is a need to solve the following tasks:<list style="symbols"></t> <ul spacing="normal"> <li> <t>Perform automaticload-balanceload balancing amongst TE tunnels according to current trafficload.</t>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 forService Routerservice router placement (anywhere in the network by the creation of transport LSPs to them).</t></list></t></li> </ul> <t>In this section, the focus is on load balancing (LB) tasks. LBtasktasks could be solved by means of the PCECC in the followingway: <list style="symbols"> <t>Application orways: </t> <ul spacing="normal"> <li> <t>Applications, networkserviceservices, oroperatoroperators can ask the SDN controller (PCECC) for LSP-based load balancing between AGG X and AGG N/AGG N-1 (egress AGG routers that have connections to the core). Each of these will have associated constraints(i.e.(such as bandwidth, inclusion or exclusion of specific links or nodes, number of paths,objective functionObjective Function (OF), need for disjoint LSPpaths etc.);</t> <t>PCECCpaths, etc.).</t> </li> <li> <t>The PCECC could calculate multiple (say N) LSPs according to givenconstraints, theconstraints. The calculation is based on the results of Objective Function (OF) <xreftarget="RFC5541"/>,target="RFC5541" format="default"/>, constraints, endpoints, same or different bandwidth (BW), different links (in case of disjointpaths)paths), and other constraints.</t> </li> <li> <t>Depending on the given LSP Pathsetup typeSetup 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><t>PCECC</li> <!-- [rfced] FYI - We have broken up the sentence below to improve readability. Please review and let us know if any further updates are necessary. Original: If PST is 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] 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 <xreftarget="RFC8281"/>target="RFC8281" format="default"/> towards the ingress AGG Xrouter(PCC)router (PCC) for each of N LSPs and receive a PCRpt message <xreftarget="RFC8231"/>target="RFC8231" format="default"/> back from PCCs. If the PST is a PCECC-SR, the PCECC will include a SID stack as per <xreftarget="RFC8664"/>.target="RFC8664" format="default"/>. 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 <xreftarget="RFC9050"/> and thentarget="RFC9050" format="default"/>. Then, the PCECC will send a PCUpd message to the ingress AGG X router with information about the new LSP. AGGX(PCC)X (PCC) will respond with a PCRpt with LSP status.</t> </li> <li> <t>AGG X as an ingress router now has N LSPs towards AGG N and AGGN-1N-1, which are available for installation to the router's forwarding table andload-balancefor load balancing traffic between them. Traffic distribution between those LSPs depends on the particular realization of thehash-functionhash function on that router.</t> </li> <li> <t>Since the PCECC is aware of the TEDB (TE state) andLSP-DB,the LSP Database (LSP-DB), it can manage and prevent possible over-subscriptions and limit the number of available load-balance states. Via a PCECCmechanismmechanism, the control can take quick actions into the network by directly provisioning the central control instructions.</t></list> </t></li> </ul> </section> <sectiontitle="PCECCanchor="sect-5.1" numbered="true" toc="default"> <name>PCECC and Inter-ASTE" anchor="sect-5.1">TE</name> <t> There are various signalling options for establishing Inter-AS TELSP:LSPs: contiguous TELSPLSPs <xreftarget="RFC5151"/>,target="RFC5151" format="default"/>, stitched TELSPLSPs <xreftarget="RFC5150"/>,target="RFC5150" format="default"/>, and nested TELSPLSPs <xreftarget="RFC4206"/>.</t>target="RFC4206" format="default"/>.</t> <t>RequirementsThe requirements for PCE-based Inter-AS setup <xreftarget="RFC5376"/>target="RFC5376" format="default"/> describe the approach and PCEP functionality that is needed for establishing Inter-AS TE LSPs.</t> <t> <xreftarget="RFC5376"/>target="RFC5376" format="default"/> also givesInter-an Inter-AS and Intra-AS PCE Reference Model (as shown in <xreftarget="fig_short"/>)target="fig_short" format="default"/>) that is provided below in shortened form for the sake of simplicity.</t> <figuretitle="Shortened formanchor="fig_short"> <name>Shortened Form ofInter-the Inter-AS and Intra-AS PCE ReferenceModel" anchor="fig_short"><artwork><![CDATA[Model</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Inter-AS Inter-AS PCC <-->PCE1<--------->PCE2 :: :: :: :: :: :: R1----ASBR1====ASBR3---R3---ASBR5 | AS1 | | PCC | | | | AS2 | R2----ASBR2====ASBR4---R4---ASBR6 :: :: :: :: Intra-AS Intra-AS PCE3 PCE4 ]]></artwork> </figure> <t>The PCECC belonging to the different domains can cooperate to set upinter-ASInter-AS TELSP.LSPs. The statefulH-PCE <xref target="RFC8751"/>Hierarchical PCE (H-PCE) mechanism <xref target="RFC8751" format="default"/> could also be used to establish a per-domain PCECC LSP first. These could be stitched together to forminter-ASan Inter-AS TE LSP as described in <xreftarget="I-D.ietf-pce-stateful-interdomain"/>.</t>target="I-D.ietf-pce-stateful-interdomain" format="default"/>.</t> <t> For the sake of simplicity, here the focus is on a simplified Inter-AS case when both AS1 and AS2 belong to the same service provider administration. In that case,InterInter-AS and Intra-AS PCEs could be combined in one single PCE if such combined PCE performance is enough to handle the load. The PCE will require interfaces (PCEP and BGP-LS) to both domains. PCECC redundancy mechanisms are described in <xreftarget="RFC8283"/>. Thustarget="RFC8283" format="default"/>. Thus, routers (PCCs) in AS1 and AS2 can send PCEP messages towards the same PCECC. In <xreftarget="fig_inter_as_pce"/>,target="fig_inter_as_pce" format="default"/>, the PCECC maintains a BGP-LS session withroute reflectorsRoute Reflectors (RRs) in each AS. This allows the RRs to redistribute routes to other BGP routers (clients) without requiring a full mesh. The RRs act as a BGP-LSPropagatorPropagator, and the PCECCactacts as a BGP-LS Consumer <xreftarget="RFC9552"/>.</t>target="RFC9552" format="default"/>.</t> <figuretitle="Particular caseanchor="fig_inter_as_pce"> <name>Particular Case of Inter-ASPCE" anchor="fig_inter_as_pce"><artwork><![CDATA[PCE</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +----BGP-LS------+ +------BGP-LS-----+ | | | | +-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+ +-:------|----::-:-+ +--::-:-|-------:---+ | : | :: : | | :: : | : | | : RR1 :: : | | :: : RR2 : | | v v: : | LSP1 | :: v v | | R1---------ASBR1=======================ASBR3--------R3 | | | v : | | :v | | | +----------ASBR2=======================ASBR4---------+ | | | Region 1 : | | : Region 1 | | |----------------:-| |--:-------------|--| | | v | LSP2 | v | | | +----------ASBR5=======================ASBR6---------+ | | Region 2 | | Region 2 | +------------------+ <--------------> +-------------------+ MPLS Domain 1 Inter-AS MPLS Domain 2 <=======AS1=======> <========AS2=======> ]]></artwork> </figure> <t> In the case of the PCECC Inter-AS TE scenario (as shown in <xreftarget="fig_inter_as_pce"/>)target="fig_inter_as_pce" format="default"/>), where the service provider 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 services on top of them(Voice, L3VPN(such as Voice, L3VPN, etc.). Inter-AS links with different 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 and pre-setup the backup Inter-AS LSPs that will be used if the primary LSP fails.</t><t><!-- [rfced] To parallel the preceding sentence, may we update "R1-R3 LSP2" to be "LSP2 from R1 to R3"? Original: As per<xref target="fig_inter_as_pce"/>,Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it is the primary Inter-AS LSP. R1-R3 LSP2 that goes via ASBR5 and 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 R3 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 orinter-ASInter-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 requirementsofdescribed in <xreftarget="RFC5376"/>target="RFC5376" format="default"/> with the following details:<list style="symbols"></t> <ul spacing="normal"> <li> <t>Since the PCECC needs to know the topology of both domains AS1 and AS2, the PCECC can utilize the BGP-LS peering with BGP routers (or RRs) in both domains.</t><t>PCECC</li> <li> <t>The PCECC needs to establish PCEP connectivity with all routers in both domains (see alsosection 4 in<xreftarget="RFC5376"/>).</t>target="RFC5376" section="4" sectionFormat="of"/>).</t> </li> <!-- [rfced] We have broken up the sentence below to improve readability. Please review and let us know if any further updates are necessary. Original: Then PCECC will calculate the optimal path based on Objective Function (OF) and given constraints (i.e. path setup type, bandwidth etc.), including those from [RFC5376]: priority, AS sequence, preferred ASBR, disjoint paths, and protection type. Current: Then, the PCECC will calculate the optimal path based on Objective Function (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 PCECC will receive that request via NBI(NBI(note that the NBI type isimplementation dependent,implementation-dependent; it could beNETCONF/Yang, RESTNETCONF/YANG, REST, etc.).ThenThen, the PCECC will calculate the optimal path based on Objective Function (OF) and given constraints(i.e.(i.e., path setup type,bandwidth etc.), includingbandwidth, etc.). These constraints include those from <xreftarget="RFC5376"/>: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> <t>PCECCR1-ASBR5-ASBR6-R3.</t> </li> <li> <t>The PCECC will use central control download instructions to the PCC based on the PST. At this stage, it is assumed the PCECC is aware of the label space itcontrolscontrols, and in the case ofSRSR, the SID allocation and distribution is already done.</t><t>PCECC</li> <li> <t>The PCECC will send a PCInitiate message <xreftarget="RFC8281"/>target="RFC8281" format="default"/> towards the ingress router R1 (PCC) in AS1 and receive the PCRpt message <xreftarget="RFC8231"/>target="RFC8231" format="default"/> back from it.<list style="symbols"></t> <ul spacing="normal"> <li> <t>If the PST is SR-MPLS, the PCECC will include the SID stack as per <xreftarget="RFC8664"/>.target="RFC8664" format="default"/>. Optionally, abinding SIDBSID or BGP Peering-SID <xreftarget="RFC9087"/>target="RFC9087" format="default"/> can also be included on the AS boundary. The backup SID stack can be installed at ingressR1R1, 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 <xreftarget="RFC9050"/>.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></list></t> <!--<t>AGGstatus.</t> </li> </ul> </li> <!-- [auth] <t>AGG X as ingress router now have N LSPs towards AGG N and AGG N-1 which are available for installing to router's forwarding table and load-balance a traffic between them. Traffic distribution between those LSPs depends on particular realization of hash-function on that router.</t>--> <li> <t>After that step, R1 nowhavehas primary and backup TEs (LSP1 and LSP2) towards R3. It is up to the router implementation for how tomakeswitchover to backup LSP2 if LSP1 fails.</t></list></t></li> </ul> </section> <sectiontitle="PCECCanchor="sect-6" numbered="true" toc="default"> <name>PCECC for MulticastLSPs" anchor="sect-6"><t>LSPs</name> <t> The multicast LSPs can be set up via the RSVP-TE P2MP or Multipoint LDP (mLDP) protocols. The setup of these LSPs may require manual configurations and complex signalling when the protection is considered. By using the PCECC solution, the multicast LSP can be computed and set up through a centralized controllerwhichthat has the full picture of the topology and bandwidth usage for each link. It not only reduces the complex configurations comparing the distributed RSVP-TE P2MP or mLDP signalling, but also it can compute the disjoint primary path and secondary P2MP path efficiently.</t> <sectiontitle="PCECCanchor="sect-6.1" numbered="true" toc="default"> <name>PCECC for the Setup of P2MP/MP2MPLSPs' Setup" anchor="sect-6.1"> <!--<t>LSPs</name> <!-- [auth] <t> With the capability of global label and local label existing at the same time in the PCECC network, PCECC will use compute, setup and maintain the P2MP and MP2MP lsp using the local label range for each network nodes.</t>--> <t>It is assumed the PCECC is aware of the label space it controls for all nodes and makes allocations accordingly.</t> <!--[rfced] We note that Figure 9 abbreviates links as "L1", "L2", etc., while 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? --> <figuretitle="Usinganchor="fig_p2mp"> <name>Using a PCECC for the Setup of P2MP/MP2MPLSPs' Setup" anchor="fig_p2mp"><artwork><![CDATA[LSPs</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +----------+ | R1 | RootnodeNode of the multicast LSP +----------+ |9000 (L0) +----------+ Transit Node | R2 | branch +----------+ * | * * 9001* | * *9002 L1 * | * *L2 +-----------+ | * +-----------+ | R4 | | * | R5 | Transit Nodes +-----------+ | * +-----------+ * | * * + 9003* | * * +9004 L3 * | * * +L4 +-----------+ +-----------+ | R3 | | R6 | Leaf Node +-----------+ +-----------+ 9005| L5 +-----------+ | R8 | Leaf Node +-----------+ ]]></artwork> </figure> <t>The P2MP examples (based on <xreftarget="fig_p2mp"/>)target="fig_p2mp" format="default"/>) are explained here, where R1 is the root and therouterrouters R8 and R6 are the leaves.<list style="symbols"></t> <ul spacing="normal"> <li> <t>Based on the P2MP path computation request/delegation or PCE initiation, the PCECC receives the request with constraints and optimization criteria. </t><t>PCECC</li> <li> <t>The PCECC will calculate the optimal P2MP path according to given constraints(i.e.bandwidth).</t> <t>PCECC(i.e., bandwidth).</t> </li> <li> <t>The PCECC will provision each node along the path and assign incoming 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":<list style="symbols"></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></list></t></li> </ul> </li> <li> <t>This can also be representedas :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 atR2R2, where two copies of a packet are sent towards R4 and R5 with 9001 and 9002labelslabels, respectively.</t></list></t></li> </ul> <t>The packet forwarding involves- <list> <t> Step 1: R1the following:</t> <ol type="Step %d."> <li>R1 sends a packet to R2 simply by pushing the label of 9000 to thepacket.</t> <t> Step 2: Whenpacket.</li> <li>When R2 receives the packet with label 9000, it will forward it to R4 by swapping label 9000 to9001 and at9001. At the same time, it will replicate the packet and swap the label 9000 to 9002 and forward it toR5.</t> <t> Step 3: WhenR5.</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 to9004.</t> <t> Step 4: When9004.</li> <li>When R3 receives the packet with label 9003, it will forward it to R8 by swapping it to9005 and when9005. When R5 receives the packet with label 9002, it will be swapped to 9004 and sent toR6.</t> <t>Step 5: WhenR6.</li> <li>When R8 receives the packet with label 9005, it will pop thelabel; whenlabel. When R6 receives the packet with label 9004, it will pop thelabel.</t> </list></t>label.</li> </ol> </section> <sectiontitle="PCECCanchor="sect-6.2" numbered="true" toc="default"> <!-- [rfced] We have updated the following text to make them complete sentences. Please review and let us know if further updates are necessary. a) Section 3.6.2: Original: In this section, the end-to-end managed path protection service as well as the local protection with the operation management in the PCECC network for the P2MP/MP2MP LSP. Current: This section describes the end-to-end managed path protection service as well as the local protection with operation management in the PCECC network for the P2MP/MP2MP LSP. b) Appendix A.4: Original: In Hadoop (https://hadoop.apache.org/) 1.0 architecture MapReduce operations on big data 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). Current: In Hadoop (https://hadoop.apache.org/) 1.0 architecture, MapReduce operations occur on big data 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). --> <name>PCECC for the End-to-End Protection of P2MP/MP2MPLSPs" anchor="sect-6.2"><t> In this section,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 PCECC network for the P2MP/MP2MP LSP.</t> <t> An end-to-end protection principle can be applied for computing backup P2MP or MP2MP LSPs. During the computation of the primary multicast trees, the PCECC could also take the computation of a secondary tree into consideration. A PCECC could compute the primary and backup P2MP (or MP2MP) LSPs together or sequentially.</t> <figuretitle="PCECCanchor="fig_p2mp-res"> <name>PCECC for the End-to-End Protection oftheP2MP/MP2MPLSPs" anchor="fig_p2mp-res"><artwork><![CDATA[LSPs</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +----+ +----+ RootnodeNode of LSP | R1 |--| R11| +----+ +----+ / + 10/ +20 / + +----------+ +-----------+ Transit Node | R2 | | R3 | +----------+ +-----------+ | \ + + | \ + + 10| 10\ +20 20+ | \ + + | \ + | + \ + +-----------+ +-----------+ Leaf Nodes | R4 | | R5 | (Downstream LSR) +-----------+ +-----------+ ]]></artwork> </figure> <t> In <xreftarget="fig_p2mp-res"/>,target="fig_p2mp-res" format="default"/>, when the PCECCsetupssets up the primary multicast tree from the root node R1 to the leaves, which is R1->R2->{R4, R5},at the same time,it cansetupset up the backuptree,tree at the same time, which is R1->R11->R3->{R4, R5}. Both of them(primary(the primary forwarding tree and secondary forwarding tree) will be downloaded to each router along the primary path and the secondary path. The traffic will be forwarded through the R1->R2->{R4, R5} path normally, but when a node in the primary tree fails (sayR2)R2), the root node R1 will switch the flow to the backup tree, which is R1->R11->R3->{R4, R5}. By using thePCECC aPCECC, path computation, labeldownloadingdownloading, and finally forwarding can be done without the complex signalling used in the P2MP RSVP-TE or mLDP.</t> </section> <sectiontitle="PCECCanchor="sect-6.3" numbered="true" toc="default"> <name>PCECC for the Local Protection oftheP2MP/MP2MPLSPs" anchor="sect-6.3"><t>LSPs</name> <t> In this section, we describe the local protection service in the PCECC network for the P2MP/MP2MP LSP.</t> <t> While the PCECC sets up the primary multicast tree, it can also build the backup LSP between the Point of Local Repair (PLR),theprotectednodenode, and Merge Points (MPs) (the downstream nodes of the protected node). In the cases where the amount of downstream nodes is huge, this mechanism can avoid unnecessary packet duplication on the PLR and protect the network from traffic congestionrisk.</t>risks.</t> <figuretitle="PCECCanchor="fig_p2mp-loc"> <name>PCECC for the Local Protection oftheP2MP/MP2MPLSPs" anchor="fig_p2mp-loc"><artwork><![CDATA[LSPs</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +------------+ | R1 | Root Node +------------+ . . . +------------+ Point of LocalRepair/Repair / | R10 | Switchover Point +------------+ (Upstream LSR) / + 10/ +20 / + +----------+ +-----------+ Protected Node | R20 | | R30 | +----------+ +-----------+ | \ + + | \ + + 10| 10\ +20 20+ | \ + + | \ + | + \ + +-----------+ +-----------+ Merge Point | R40 | | R50 | (Downstream LSR) +-----------+ +-----------+ . . . . ]]></artwork> </figure> <t> In <xreftarget="fig_p2mp-loc"/>,target="fig_p2mp-loc" format="default"/>, when the PCECCsetupssets up the primary multicast path around the PLR node R10 to protect node R20, which is R10->R20->{R40, R50},at the same time,it can set up the backup path R10->R30->{R40,R50}.R50} at the same time. Both the primary forwarding path and the secondary bypass forwarding path will be downloaded to each router along the primary path and the secondary bypass path. The traffic will be forwarded through the R10->R20->{R40, R50} pathnormallynormally, and when there is a node failure for node R20, the PLR node R10 will switch the flow to the backup path, which is R10->R30->{R40, R50}. By using the PCECC, path computation, labeldownloadingdownloading, and finally forwarding can be done without the complex signalling used in the P2MP RSVP-TE or mLDP.</t> </section> </section> <sectiontitle="PCECCanchor="sect-7" numbered="true" toc="default"> <name>PCECC for TrafficClassification" anchor="sect-7">Classification</name> <t>As described in <xreftarget="RFC8283"/>,target="RFC8283" format="default"/>, traffic classification is an important part of traffic engineering. 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 manyscenariosscenarios, including the following:<list><t>MPLS</t> <ul> <li> MPLS traffic engineering (where it determines what traffic is forwarded into whichLSPs),</t> <t>SegmentLSPs), </li> <li> Segment Routing (where it is used to select which set of forwarding instructions (SIDs) to add to apacket),</t> <t>SFCpacket), and </li> <li> SFC (where it indicates how a packet should be forwarded across which service functionpath ).</t></list></t>path). </li> </ul> <t>In conjunction with traffic engineering, traffic classification is an important enabler for load balancing. Traffic classification is closely linked to the computational elements of planning for the network functions because it determines how traffic is balanced and distributed through the network. Therefore, selecting what traffic classification mechanism should be performed by a router is an important part of the work done by a PCECC.</t> <!-- [rfced] We note that "Flow Specification" occurs three times in the sentence below. For concision and clarity, may we update the sentence as follows? Original: 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]. Perhaps: 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>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 <xreftarget="RFC8955"/>.target="RFC8955" format="default"/>. When a PCECC is used to initiate tunnels (such asTE-LSPsTE LSPs or SR paths) using PCEP, it is important that the head end of the tunnels understands what traffic to place on each tunnel. <xreftarget="RFC9168"/>target="RFC9168" format="default"/> specifies a set of extensions to PCEP to support the dissemination of Flow Specification components where the instructions are passed from the PCECC to the routers using PCEP.</t><t><!-- [rfced] For clarity, what does "it" refer to in the bullets below? Is it the PCECC? Original (Section 3.7): Along with traffic classification, there are a few more questions that need to be considered after path setup:<list style="symbols"><t>how* how to useit</t> <t>Whetherit * Whether it is a virtuallink</t> <t>Whetherlink * Whether to advertise it in the IGP as a virtuallink</t> <t>Whatlink * What bits of this information to signal to the tailend</t> </list>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> <sectiontitle="PCECC for SFC"anchor="sect-9">numbered="true" toc="default"> <name>PCECC for SFC</name> <t>Service Function Chaining (SFC) is described in <xreftarget="RFC7665"/>.target="RFC7665" format="default"/>. It is the process of directing traffic in a network such that it passes through specific hardware devices or virtual machines (known as service function nodes) that can perform particular desired functions on the traffic. The set of functions to be performed and the order in which they are to be performed is known as a service function chain. The chain is enhanced with the locations at which the service functions are to be performed to derive a Service Function Path (SFP). Each packet is marked as belonging to a specific SFP, and that marking lets each successive service function node know which functions to perform and to which service function node to send the packet next. To operate an SFC network, the service function nodes must be configured to understand the packet markings, and the edge nodes must be told how to mark packets entering the network. Additionally, it may be necessary to establish tunnels between service function nodes to carry the traffic. Planning an SFC network requires load balancing between service function nodes and traffic engineering across the network that connects them. As per <xreftarget="RFC8283"/>,target="RFC8283" format="default"/>, these are operations that can be performed by a PCE-based controller, and that controller can use PCEP to program the network and install the service function chains and any required tunnels.</t> <t>A possible mechanism could add support for SFC-based central control instructions. The PCECC will be able to instruct each Service Function Forwarder (SFF) along the SFP.</t> <!-- [rfced] Would you like to add any additional text or a definition to "SFC Proxy handling" below, for consistency with the other bulleted items in this list? Original: A possible mechanism could add support for SFC-based central control instructions. PCECC will be able to instruct each SFF along the SFP.<list style="symbols"> <t>Service* Service Path Identifier (SPI): Uniquely identifies an SFP.</t> <t>Service* Service Index (SI): Provides location within theSFP.</t> <t>SFCSFP. * SFC Proxyhandling</t> </list> </t> <t>PCECChandling --> <ul> <li>Service Path Identifier (SPI): Uniquely identifies an SFP.</li> <li>Service Index (SI): Provides location within the SFP.</li> <li>SFC Proxy handling</li> </ul> <t>The PCECC can play the role of setting the traffic classification rules (as per <xreftarget="sect-7"/>)target="sect-7" format="default"/>) at the classifier to impose the Network Service Header (NSH) <xreftarget="RFC8300"/> as well as downloadingtarget="RFC8300" format="default"/>. It can also download the forwarding instructions to each SFF along the way so that they could process the NSH and forward accordingly.IncludingThis includes instructions for the service classifier that handles the context header,metadatametadata, etc. This metadata/context is shared amongst SFs and classifiers, between SFs, and between external systems (such as a PCECC) and SFs. As described in <xreftarget="RFC7665"/>,target="RFC7665" format="default"/>, the SFC encapsulation enables the sharing of metadata/context information along the SFP.</t> <t>It is also possible to support SFC with SR in conjunction with or without an NSH such as described in <xreftarget="RFC9491"/>target="RFC9491" format="default"/> and <xreftarget="I-D.ietf-spring-sr-service-programming"/>.target="I-D.ietf-spring-sr-service-programming" format="default"/>. PCECCtechniquetechniques can also be used forservice function-relatedservice-function-related segments and SR service policies. </t> </section> <sectiontitle="PCECCanchor="sect-10" numbered="true" toc="default"> <name>PCECC for NativeIP" anchor="sect-10" > <t><xref target="RFC8735"/>IP</name> <t> <xref target="RFC8735" format="default"/> describes the scenarios and simulation results for the"Centrally"Centralized Control Dynamic Routing (CCDR)" solution, which integrates the advantage of using distributed protocols (IGP/BGP) and the power of a centralized control technology (PCE/SDN), providing traffic engineering for native IP networks. <xreftarget="RFC8821"/>target="RFC8821" format="default"/> defines the framework for CCDR traffic engineering within aNativenative IP network, using multiple BGP sessions and a PCE as the centralized controller. It requires the PCECC to send the instructions to thePCCs,PCCs to build multiple BGP sessions, distribute different prefixes on the established BGPsessionssessions, 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 <xreftarget="I-D.ietf-pce-pcep-extension-native-ip"/>target="I-D.ietf-pce-pcep-extension-native-ip" format="default"/> forit.</t>it. </t> <figuretitle="PCECCanchor="fig_native_ip"> <name>PCECC for NativeIP" anchor="fig_native_ip"><artwork> <![CDATA[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>]]></artwork> </figure> <t>In thecase,case as shown in <xreftarget="fig_native_ip"/>,target="fig_native_ip" format="default"/>, the PCECC will instruct both R1 and R2via PCEPhow to form BGP sessions with each other via PCEP and which IP prefixes need to be advertised via which BGP session.</t> </section> <sectiontitle="PCECCanchor="sect-11" numbered="true" toc="default"> <name>PCECC forBIER" anchor="sect-11">BIER</name> <t>Bit Index Explicit Replication (BIER) <xreftarget="RFC8279"/>target="RFC8279" format="default"/> defines an architecture where all intended multicast receivers are encoded as abitmaskBitMask in the multicast packet header within different encapsulations. A router that receives such a packet will forward that packet based on the bit position in the packet header towards the receiver(s) following a precomputed tree for each of the bits in the packet. Each receiver is represented by a unique bit in thebitmask.</t>BitMask.</t> <t>BIER-TE <xreftarget="RFC9262"/>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(a possible mechanism is described in <xreftarget="I-D.chen-pce-bier"/>).</t> <t>PCECCtarget="I-D.ietf-pce-bier-te" format="default"/>).</t> <!-- [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. Original: The PCECC could be used to program the BIER router with various parameters used in the BIER encapsulation such as BIER subdomain-ID, BFR-ID, BIER Encapsulation etc. for both node and adjacency. Current: 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>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 encapsulationsuch(such as BIERsubdomain-ID, BFR-ID, BIER Encapsulation etc.sub-domain-id, BFR-id, etc.) for both node and adjacency.</t><t> A<t>A possible wayforto use the PCECCusageand PCEP extension is described in <xreftarget="I-D.chen-pce-pcep-extension-pce-controller-bier"/>.</t>target="I-D.chen-pce-pcep-extension-pce-controller-bier" format="default"/>.</t> </section> </section> <sectiontitle="IANA Considerations" anchor="sect-12"><t> Thisanchor="sect-12" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentdoes not require any action from IANA.</t>has no IANA actions.</t> </section> <sectiontitle="Security Considerations" anchor="sect-13">anchor="sect-13" numbered="true" toc="default"> <name>Security Considerations</name> <t><xreftarget="RFC8283"/>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 <xreftarget="RFC5440"/>target="RFC5440" format="default"/> and the additional mechanisms described in <xreftarget="RFC8253"/>.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 <xreftarget="RFC9050"/>,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><section title="Acknowledgments" anchor="sect-14"><t> Thanks to Adrian Farrel, Aijun Wang, Robert Tao, Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Elperin and Evgeniy Brodskiy for their useful comments and suggestions.</t> <t>Thanks to Mach Chen and Carlos Pignataro for the RTGDIR review. Thanks</middle> <back> <displayreference target="I-D.ietf-pce-pcep-extension-pce-controller-sr" to="PCECC-SR"/> <displayreference target="I-D.ietf-pce-controlled-id-space" to="PCE-ID"/> <displayreference target="I-D.ietf-pce-stateful-interdomain" to="PCE-INTERDOMAIN"/> <displayreference target="I-D.cbrt-pce-stateful-local-protection" to="PCE-PROTECTION"/> <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-SERVICE"/> <displayreference target="I-D.ietf-pce-segment-routing-policy-cp" to="PCEP-POLICY"/> <displayreference target="I-D.chen-pce-pcep-extension-pce-controller-bier" to="PCECC-BIER"/> <displayreference target="I-D.ietf-pce-pcep-extension-native-ip" to="PCEP-NATIVE"/> <displayreference target="I-D.ietf-pce-pcep-extension-pce-controller-srv6" to="PCECC-SRv6"/> <references> <name>References</name> <references> <name>Normative References</name> <!-- [auth] &RFC2119;--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/> <!-- [auth] &RFC8174;--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8283.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3985.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4206.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4456.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5150.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5151.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5376.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7025.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7399.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7491.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8355.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8408.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8735.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8751.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8821.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9050.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9168.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9087.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9262.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9491.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9522.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"/> <!-- [I-D.ietf-pce-pcep-extension-pce-controller-sr] IESG state: I-D Exists as of 06/06/24--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-pcep-extension-pce-controller-sr.xml"/> <!-- [I-D.li-pce-controlled-id-space] IESG state: Replaced by draft-ietf-pce-controlled-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 toDerrell Piper foradvertise theSECDIR review. ThanksPCE 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> <!-- [I-D.ietf-pce-stateful-interdomain] IESG state: Expired as of 06/06/24--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-stateful-interdomain.xml"/> <!-- [I-D.cbrt-pce-stateful-local-protection] IESG state: Expired as of 06/06/24 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-cbrt-pce-stateful-local-protection.xml"/> <!-- [I-D.ietf-pce-segment-routing-ipv6] IESG state: RFC Ed Queue as of 06/06/24. Published as [RFC9603]. Updated reference and cite tags accordingly.--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9603.xml"/> <!-- [I-D.ietf-mpls-seamless-mpls] IESG state: Expired (IESG: Dead) as of 06/06/24. Added missing editor role toSue Hares for GENART review.</t> <t>ThanksXML.--> <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.chen-pce-bier] IESG state: Replaced by draft-ietf-pce-bier-te as of 06/06/24 Updated from "draft-chen-pce-bier" toVishnu Pavan Beeram for being the document shepherd"draft-ietf-pce-bier-te".--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-bier-te-00.xml"/> <!-- [I-D.ietf-spring-sr-service-programming] IESG state: I-D Exists as of 06/06/24--> <reference anchor="I-D.ietf-spring-sr-service-programming" target="https://datatracker.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&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-programming-10"/> </reference> <!-- [I-D.ietf-pce-segment-routing-policy-cp] IESG state: I-D Exists as of 06/06/24--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-segment-routing-policy-cp.xml"/> <!-- [I-D.ietf-pce-binding-label-sid] Published as RFC 9604. Updated reference andJim Guichardcitation tags forbeing the responsible AD.</t> <t>Thanks[PCE-BINDING-LABEL-SID] toRoman Danyliw for the[RFC9604]. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9604.xml"/> <!-- [I-D.chen-pce-pcep-extension-pce-controller-bier] IESGreview comments.</t> </section> </middle> <back> <references title="Normative References"> <!--&RFC2119;--> &RFC5440; <!--&RFC8174;--> &RFC7665; &RFC8231; &RFC8281; &RFC8283; &RFC8253; &RFC8402; </references> <references title="Informative References"> &RFC1195; &RFC2328; &RFC5340; &RFC3209; &RFC5036; &RFC3985; &RFC4206; &RFC4364; &RFC4456; &RFC4655; &RFC5150; &RFC5151; &RFC5541; &RFC5376; &RFC7025; &RFC7399; &RFC7432; &RFC7491; &RFC8279; &RFC8300; &RFC8355; &RFC8408; &RFC8664; &RFC8735; &RFC8751; &RFC8754; &RFC8821; &RFC8955; &RFC8986; &RFC9050; &RFC9168; &RFC9256; &RFC9012; &RFC9087; &RFC9262; &RFC9491; &RFC9522; &RFC9552; &I-D.ietf-pce-pcep-extension-pce-controller-sr; &I-D.li-pce-controlled-id-space; &I-D.ietf-pce-stateful-interdomain; &I-D.cbrt-pce-stateful-local-protection; &I-D.ietf-pce-segment-routing-ipv6; &I-D.ietf-mpls-seamless-mpls; &I-D.chen-pce-bier; &I-D.ietf-spring-sr-service-programming; &I-D.ietf-pce-segment-routing-policy-cp; &I-D.ietf-pce-binding-label-sid; &I-D.chen-pce-pcep-extension-pce-controller-bier; &I-D.ietf-pce-pcep-extension-native-ip; &I-D.dhody-pce-pcep-extension-pce-controller-srv6;state: Expired as of 06/06/24--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-chen-pce-pcep-extension-pce-controller-bier.xml"/> <!-- [I-D.ietf-pce-pcep-extension-native-ip] IESG state: Publication Requested as of 06/06/24--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-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-pce-pcep-extension-pce-controller-srv6.xml"/> <reference anchor="MAP-REDUCE"target="http://leeky.me/publications/mapreduce_p2p.pdf">target="https://leeky.me/publications/mapreduce_p2p.pdf"> <front> <title>Parallel Processing Framework on a P2P System Using Map and Reduce Primitives</title> <author initials="K" surname="Lee" fullname="Kyungyong Lee"><organization /><organization/> </author> <author initials="T" surname="Choi" fullname="Tae Woong Choi"><organization /><organization/> </author> <author initials="A" surname="Ganguly" fullname="Arijit Ganguly"><organization /><organization/> </author> <author initials="D" surname="Wolinsky" fullname="David I. Wolinsky"><organization /><organization/> </author> <author initials="P" surname="Boykin" fullname="P.Oscar Boykin"><organization /><organization/> </author> <author initials="R" surname="Figueiredo" fullname="Renato Figueiredo"><organization /><organization/> </author> <datemonth="may" year="2011" />month="May" year="2011"/> </front> <seriesInfoname="" value="" />name="DOI" value="10.1109/IPDPS.2011.315"/> </reference> <reference anchor="MPLS-DC" target="https://www.slideshare.net/DmitryAfanasiev1/yandex-nag201320131031"> <front> <title>MPLS in DC and inter-DC networks: the unified forwarding mechanism for network programmability at scale</title> <author initials="D" surname="Afanasiev" fullname="Dimitry Afanasiev"><organization /><organization/> </author> <author initials="D" surname="Ginsburg" fullname="Daniel Ginsburg"><organization /><organization/> </author> <datemonth="march" year="2014" />month="March" year="2014"/> </front><seriesInfo name="" value="" /></reference> </references> </references> <sectiontitle="Otheranchor="sect-15" numbered="true" toc="default"> <name>Other Use Cases ofPCECC" anchor="sect-15">the PCECC</name> <t>This section lists some more use cases of the PCECC that were proposed by operators and discussed within the workinggroup,group but are not in active development at the time of publication. They are listed here for future consideration.</t> <sectiontitle="PCECCanchor="sect-15.1" numbered="true" toc="default"> <name>PCECC for NetworkMigration" anchor="sect-15.1"><t>Migration</name> <t> One of the main advantages of the PCECC solution is its backward compatibility. The PCE server can function as a proxy node of the MPLS network for all the new nodes that no longer support the signalling protocols.</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 could migrate to a total PCECC-controlled network gradually by replacing the legacy nodes. During the migration, the legacy nodes 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 through the PCECC directly. With the PCECC function as the proxy of these new nodes, MPLS signalling can populate through the network forboth:both old and new nodes.</t> <t> The example described in this section is based on network configurations illustratedusingin <xreftarget="fig_mig"/>:</t>target="fig_mig" format="default"/>:</t> <figuretitle="PCECC Initiatedanchor="fig_mig"> <name>PCECC-Initiated LSP SetupInin the NetworkMigration" anchor="fig_mig"><artwork><![CDATA[Migration</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +------------------------------------------------------------------+ | PCE DOMAIN | | +-----------------------------------------------------+ | | | PCECC | | | +-----------------------------------------------------+ | | ^ ^ ^ ^ | | | PCEP | | PCEP | | | V V V V | | +--------+ +--------+ +--------+ +--------+ +--------+ | | | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | | | |...| |...| |...| |...| | | | | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | | | | Node | | Node | |Enabled | |Enabled | | Enabled| | | +--------+ +--------+ +--------+ +--------+ +--------+ | | | +------------------------------------------------------------------+ ]]></artwork> </figure><t> In<t>In this example, there are five nodes for the TE LSP from the head end (Node1) to the tail end(Node5). Where(Node5), where Node4 and Node5 are centrally controlled and other nodes are legacy nodes.</t><t><list style="symbols"><t>Node1<ul spacing="normal"> <li> Node1 sends a path request message for the setup of the LSP with the destination asNode5.</t> <t>PCECCNode5. </li> <li> The PCECC sendsto Node1a reply message to Node1 for LSP setup with the path: (Node1,if1),(Node2,if1), (Node2, if2), (Node3, if3), (Node4, if4),Node5.</t> <t>Node1,Node5. </li> <li> Node1, Node2, and Node3 will set up the LSP to Node5 using the local labels as usual.Node 3 withWith the help ofPCECCthe PCECC, Node 3 could proxy thesignalling.</t> <t>Thensignalling. </li> <li> Then, the PCECC will program the out-segment of Node3, thein-segment/ out-segmentin-segment/out-segment of Node4, and the in-segment forNode5.</t> </list> </t>Node5. </li> </ul> </section> <sectiontitle="PCECCanchor="sect-15.2" numbered="true" toc="default"> <name>PCECC for L3VPN andPWE3" anchor="sect-15.2">PWE3</name> <t>As described in <xreftarget="RFC8283"/>,target="RFC8283" format="default"/>, various network services may be offered over a network. These include protection services (including Virtual Private Network (VPN) services(suchsuch as Layer 3 VPNs <xreftarget="RFC4364"/>target="RFC4364" format="default"/> or Ethernet VPNs <xreftarget="RFC7432"/>);target="RFC7432" format="default"/>) orPseudowirespseudowires <xreftarget="RFC3985"/>.target="RFC3985" format="default"/>. Delivering services over a network in an optimal way requires coordination in the way where network resources are allocated to support the services. 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. It can then use PCEP to manage the network resources and to install the necessary associations between those resources.</t><!--<t><!-- [auth] <t> The existing services using MPLS LSP tunnels based on MPLS signaling mechanism such L3VPN, PWE3 and IPv6 can be simplified by using the PCECC for label assignments for the L3VPN, PWE3 and IPv6 as well.</t>--> <t> In the case of L3VPN, VPN labels could also be assigned and distributed through PCEP among thePEProvider Edge (PE) router instead of using the BGP protocols.</t> <t> The example described in this section is based on network configurations illustratedusingin <xreftarget="fig_l3vpn"/>:</t>target="fig_l3vpn" format="default"/>:</t> <figuretitle="PCECCanchor="fig_l3vpn"> <name>PCECC for L3VPN andPWE3" anchor="fig_l3vpn"><artwork><![CDATA[PWE3</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +-------------------------------------------+ | PCE DOMAIN | | +-----------------------------------+ | | | PCECC | | | +-----------------------------------+ | | ^ ^ ^ ||PWE3/L3VPN|PCEPPWE3/L3VPN|PCEP PCEP|LSP PWE3/L3VPN|PCEP | | V V V | +--------+ | +--------+ +--------+ +--------+ | +--------+ | CE | | | PE1 | | NODE x | | PE2 | | | CE | | |...... | |...| |...| |.....| | | Legacy | |if1 | PCECC |if2|PCCEC |if3| PCECC |if4 | Legacy | | Node | | | Enabled| |Enabled | |Enabled | | | Node | +--------+ | +--------+ +--------+ +--------+ | +--------+ | | +-------------------------------------------+ ]]></artwork> </figure> <t> In the case of PWE3, instead of using the LDP signalling protocols, the label and port pairs assigned to each pseudowire can be assigned through the PCECC among the PE routers and the corresponding forwarding entries will be distributed into each PE router through the extended PCEP and PCECC mechanism.</t> </section> <sectiontitle="PCECCanchor="sect-15.3" numbered="true" toc="default"> <name>PCECC for Local Protection(RSVP-TE)" anchor="sect-15.3">(RSVP-TE)</name> <t><xreftarget="I-D.cbrt-pce-stateful-local-protection"/> claimtarget="I-D.cbrt-pce-stateful-local-protection" format="default"/> claims that there is a need for the PCE to maintain and associate the local protection paths for the RSVP-TE LSP. Local protection requires the setup of a bypass at the PLR. This bypass can be PCC-initiated anddelegated,delegated or PCE-initiated. In either case, the PLR needs to maintain a PCEP session with the PCE. TheBypassbypass LSPs need to be mapped to the primary LSP. This could be done locally at the PLR based on a localpolicypolicy, but there is a need for a PCE to do the mapping as well to exert greater control. </t> <t>This mapping can be done via PCECC procedures where the PCE could instruct the PLR to the mapping and identify the primary LSP for which bypass should be used. </t> </section> <sectiontitle="Using reliableanchor="sect-15.4" numbered="true" toc="default"> <name>Using Reliable P2MPTE based multicast deliveryTE-Based Multicast Delivery fordistributed computations (MapReduce-Hadoop)" anchor="sect-15.4">Distributed Computations (MapReduce-Hadoop)</name> <t> The MapReduce model of distributed computations in computing clusters is widely deployed. In <eref target="https://hadoop.apache.org/">Hadoop</eref> 1.0architecturearchitecture, MapReduce operations occur on big data<!--performs<!-- [auth] 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(64 MB or more) should have3three 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(the assumption is that closer dataareis better because of accessspeed/smallerspeed / smaller latency).</t> <t> The JobTracker node is responsible for computationtasks,tasks and scheduling across DataNodes and also hasRack-awareness.Rack awareness. Currently, transport protocols between NameNode/JobTracker and DataNodes are based on IP unicast. It has simplicity as an advantage but has numerous drawbacks related to its flat approach.</t> <t> There is a need to go beyond one datacentrecenter (DC) for Hadoop cluster creation and move towards distributed clusters. In that case, one needs to handle performance and latency issues. Latency depends on the speed of light in thefibrefiber links and on the latency introduced by intermediate devices in between. The latter is closely correlated with network device architecture and performance. The current performance ofNPU-basedrouters based on Network Processing Unit (NPU) should be enough for creating distributed Hadoop clusters with predicted latency. The performance of software-based routers (mainlyvirtual network functions (VNF))Virtual Network Functions (VNFs)) with additional hardware features such as the Data Plane Development Kit (DPDK) is promising but requires additional research and testing.</t> <t> The main question is how to create a simple but effective architecture for a distributed Hadoop cluster.</t> <t> There is research <xreftarget="MAP-REDUCE"/>target="MAP-REDUCE" format="default"/> thatshowshows how usage of the multicast tree could improve the speed of resource or cluster members' discovery inside the cluster as well as increased redundancy in communications between cluster nodes.</t> <t> The traditional IP-based multicast may not be appropriate because it requires an additional control plane (IGMP, PIM) and a lot of signalling,thatwhich is not suitable for high-performancecomputations,computations that are very sensitive to latency.</t> <t> P2MP TE tunnels are more suitable as a potential solution for the creation of multicast-based communications between NameNode as the root and DataNodes as leaves inside the cluster. These P2MP tunnels could be dynamically created and turned down (with no manual intervention). Here, the PCECC comes into play with the main objective of creating an optimal topology for each particular request for MapReduce computation and creating P2MP tunnels with needed parameters such as bandwidth and delay.</t> <t> 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 <xreftarget="MPLS-DC"/>. Technicallytarget="MPLS-DC" format="default"/>. Technically, it is already possible because MPLS on switches is already supported by some vendors, and MPLS also exists on Linux andOVS.</t>Open vSwitch (OVS).</t> <t>A possible framework for this task is shown in <xreftarget="fig_mapred"/>:target="fig_mapred" format="default"/>: </t> <figuretitle="Using reliableanchor="fig_mapred"> <name>Using Reliable P2MPTE based multicast deliveryTE-Based Multicast Delivery fordistributed computations (MapReduce-Hadoop)" anchor="fig_mapred"><artwork><![CDATA[Distributed Computations (MapReduce-Hadoop)</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +--------+ | APP | +--------+ | NBI (REST API,...) | PCEP +----------+ REST API +---------+ +---| PCECC |----------+ | Client |---|---| | | +---------+ | +----------+ | | | | | | | +-----|---+ |PCEP| | +--------+ | | | | | | | | | | | | REST API | | | | | | | | | | | +-------------+ | | | | +----------+ | Job Tracker | | | | | | NameNode | | | | | | | | | +-------------+ | | | | +----------+ +------------------+ | +-----------+ | | | | |---+-----P2MP TE--+-----|-----------| | +----------+ +----------+ +----------+ | DataNode1| | DataNode2| | DataNodeN| |TaskTraker| |TaskTraker| .... |TaskTraker| +----------+ +----------+ +----------+ ]]></artwork> </figure><t> Communication<t>Communication between the JobTracker,NameNodeNameNode, and PCECC can be done via REST API directly or via a cluster manager such as Mesos.</t> <ul> <li> <t> Phase 1: Distributed clusterresourcesresource discoveryDuringoccurs during thisphase,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 may provide additional constraints to the PCECC such as topologicalproximity,proximity and redundancylevel.</t>level. </t> <t> The PCECC should analyze the topology of the distributed cluster and perform a constraint-based path calculation from the client towards the most suitable NameNodes. The PCECC should reply to NameNode with the list of the most suitable DataNodes and their resource capabilities. The topology discovery mechanism for the PCECC will be added later to thatframework.</t> <t>framework. </t> </li> <li> Phase 2: The PCECC should create P2MPLSPLSPs from the client towards those DataNodes by means of PCEP messages following the previously calculatedpath.</t> <t>Phase 3.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.</t> <t></li> <li> Phase4.4: TheClientclient sends data blocks to those DataNodes for writing via the created P2MPtunnel.</t> <t> Whentunnel. </li> </ul> <t>When this task is finished, the P2MP tunnel could be turned down.</t> </section> </section> <sectiontitle="Contributor Addresses"anchor="sect-14" numbered="false" toc="default"><t><figure align="left" alt="" height="" suppress-title="false" title="" width=""> <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[ Luyuan Fang United<name>Acknowledgments</name> <t>Thanks to <contact fullname="Adrian Farrel"/>, <contact fullname="Aijun Wang"/>, <contact fullname="Robert Tao"/>, <contact fullname="Changjiang Yan"/>, <contact fullname="Tieying Huang"/>, <contact fullname="Sergio Belotti"/>, <contact fullname="Dieter Beller"/>, <contact fullname="Andrey Elperin"/>, and <contact fullname="Evgeniy Brodskiy"/> for their useful comments and suggestions.</t> <t>Thanks to <contact fullname="Mach Chen"/> and <contact fullname="Carlos Pignataro"/> for the RTGDIR review. Thanks to <contact fullname="Derrell Piper"/> for the SECDIR review. Thanks to <contact fullname="Sue Hares"/> for GENART review.</t> <t>Thanks to <contact fullname="Vishnu Pavan Beeram"/> for being the document shepherd and <contact fullname="Jim Guichard"/> for being the responsible AD.</t> <t>Thanks to <contact fullname="Roman Danyliw"/> for the IESG review comments.</t> </section> <section toc="default" numbered="false"> <name>Contributors</name> <contact fullname="Luyuan Fang"> <organization></organization> <address> <postal> <street></street> <city></city> <region></region> <code></code> <country>United States ofAmerica Email: luyuanf@gmail.com Chao Zhou HPE Email: chaozhou_us@yahoo.com Boris Zhang Amazon Email: zhangyud@amazon.com Artsiom Rachytski Belarus Email: arachyts@gmail.com Anton Gulida EPAMAmerica</country> </postal> <email>luyuanf@gmail.com</email> </address> </contact> <contact fullname="Chao Zhou"> <organization>HPE</organization> <address> <postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal> <email>chaozhou_us@yahoo.com</email> </address> </contact> <contact fullname="Boris Zhang"> <organization>Amazon</organization> <address> <postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal> <email>zhangyud@amazon.com</email> </address> </contact> <contact fullname="Artsiom Rachytski"> <organization></organization> <address> <postal> <street></street> <city></city> <region></region> <code></code> <country>Belarus</country> </postal> <email>arachyts@gmail.com</email> </address> </contact> <contact fullname="Anton Gulida"> <organization>EPAM Systems,Inc. Belarus Email: Anton_Hulida@epam.com ]]></artwork> </figure></t>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> <!-- [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? Original (some examples): 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": --> <!-- [rfced] Should spaces appear between values (90012,1002,90024, etc.)? Original (some examples): * For the end-to-end protection, PCECC can provision the secondary 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}. --> <!-- [rfced] Terminology a) Should instances of "PCEP protocol" be updated to read simply "PCEP" to avoid redundancy (if expanded, "PCEP protocol" would read "Path Computation Element Communication Protocol protocol")? Please review and let us know if any updates are needed. b) We note use of the terms "PCE-based controller" and "PCE-based central controller". Should these be updated to "PCECC"? 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 needed 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-author-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>