<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY RFC4206 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4206.xml"> zwsp   "&#8203;">
  <!ENTITY RFC5150 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5150.xml"> nbhy   "&#8209;">
  <!ENTITY RFC5151 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     "&#8288;">
]>

<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 S CLAREMONT 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 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>
    <keyword>SDN</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 Traffic Engineering (TE) paths in MPLS
      networks, which are supplied to the head end headend of the paths using the Path
      Computation Element Communication Protocol (PCEP).</t>
      <t>SDN has much broader applicability than signaled signalled MPLS traffic-engineered
   (TE)
      TE networks, and the PCE may be used to determine
      paths in a range of use cases including static LSPs, 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.  PCEP extensions extensions, which are required for the PCECC use cases cases,
      are covered in separate documents.</t>

   <!--<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 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>
    <section title="Introduction" anchor="sect-1"> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The PCE <xref target="RFC4655"/> target="RFC4655" format="default"/> was developed to offload
   the path computation function from routers in an MPLS traffic-engineered Traffic Engineering (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
   <xref target="RFC7025"/> target="RFC7025" format="default"/> or Multicast), Multicast)
   and to allow delegated stateful control <xref target="RFC8231"/> target="RFC8231" format="default"/> and PCE-initiated
   use of network resources <xref target="RFC8281"/>.</t> target="RFC8281" format="default"/>.</t>
      <t>According to <xref target="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 a
   controller,
   "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 <xref target="RFC7491"/>.</t> target="RFC7491" format="default"/>.</t>
      <t><xref target="RFC8283"/> introduces target="RFC8283" format="default"/> outlines the architecture for the PCE as a central
   controller as an extension to
   controller, extending the architecture framework described in <xref target="RFC4655"/> target="RFC4655" format="default"/>,
   and assumes the continued use of demonstrates how PCEP can serve as the a general southbound control protocol used between the PCE
and PCC. Path Computation Client (PCC). <xref target="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>
   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><xref target="RFC9050"/> target="RFC9050" format="default"/> introduces the procedures and
   extensions for PCEP to support the PCECC architecture <xref target="RFC8283"/>.</t> target="RFC8283" format="default"/>.</t>
      <t>
   This document describes the various use cases for the PCECC architecture.</t>

    <!--<t>This is a living document to catalog the use cases for PCECC. There is currently no intention to publish this work as an RFC. [Update: Chairs are evaluating if the document should be published instead.]</t>-->
	</section>
    <section title="Terminology" anchor="sect-2"> anchor="sect-2" numbered="true" toc="default">
      <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 <xref target="RFC9552"/>.
	</t>

	  <t hangText="LSP:">
	Label Switched Path.
	</t>

  <t hangText="IGP:">
	Interior target="RFC9552" format="default"/></dd>
        <dt>IGP:</dt>
        <dd>Interior Gateway Protocol. In the Protocol (in this document, we assume IGP as either Open Shortest Path First (OSPF) <xref target="RFC2328"/><xref target="RFC5340"/> target="RFC2328" format="default"/> <xref target="RFC5340" format="default"/> or
        Intermediate System to Intermediate System (IS-IS) <xref target="RFC1195"/> as IGP.
	</t>

	<t hangText="PCC:">
	Path target="RFC1195" format="default"/>)</dd>
        <dt>LSP:</dt>
        <dd>Label-Switched Path</dd>
        <dt>PCC:</dt>
        <dd>Path Computation Client. As Client (as per <xref target="RFC4655"/>, target="RFC4655" format="default"/>, any client application requesting a path
        computation to be performed by a Path Computation Element.
	</t>

	<t hangText="PCE:">
	Path PCE)</dd>
        <dt>PCE:</dt>
        <dd>Path Computation Element. As Element (as per <xref target="RFC4655"/>, target="RFC4655" format="default"/>, an entity (component, such as a component, application, or network node) node that is capable of computing a network path or route based on a
        network graph and applying computational
      constraints.
	</t>

  <t hangText="PCECC:">
  PCE constraints)</dd>
        <dt>PCECC:</dt>
        <dd>PCE as a Central Controller. Extension Controller (an extension of a PCE to support SDN functions as per <xref target="RFC8283"/>.
  </t>

    <t hangText="PST:">
  Path target="RFC8283" format="default"/>)</dd>
        <dt>PST:</dt>
        <dd>Path Setup Type <xref target="RFC8408"/>.
  </t>

	<t hangText="RR:">
	Route target="RFC8408" format="default"/></dd>
        <dt>RR:</dt>
        <dd>Route Reflector <xref target='RFC4456'/>.
	</t>

	<t hangText="SID:">
	Segment target="RFC4456" format="default"/></dd>
        <dt>SID:</dt>
        <dd>Segment Identifier <xref target='RFC8402'/>.
	</t>

	<t hangText="SR:">
	Segment target="RFC8402" format="default"/></dd>
        <dt>SR:</dt>
        <dd>Segment Routing <xref target='RFC8402'/>.
	</t>

		<t hangText="SRGB:">
	Segment target="RFC8402" format="default"/></dd>
        <dt>SRGB:</dt>
        <dd>Segment Routing Global Block <xref target='RFC8402'/>.
	</t>

		<t hangText="SRLB:">
	Segment target="RFC8402" format="default"/></dd>
        <dt>SRLB:</dt>
        <dd>Segment Routing Local Block <xref target='RFC8402'/>.
	</t>

	<t hangText="TE:">
	Traffic target="RFC8402" format="default"/></dd>
        <dt>TE:</dt>
        <dd>Traffic Engineering <xref target='RFC9522'/>.
	</t>

	</list></t> target="RFC9522" format="default"/></dd>
      </dl>
    </section>
    <section title="Use Cases"> numbered="true" toc="default">

      <name>Use Cases</name>
      <t><xref target="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 up Static static TE LSPs. The LSPs (the PCEP extension for this use case is in <xref target="RFC9050"/>.</t>
    <t>Use target="RFC9050" format="default"/>)
        </li>
        <li>
          use of a PCECC in Segment Routing SR <xref target="RFC8402"/>.</t>
    <t>Use target="RFC8402" format="default"/>
        </li>
        <li>
          use of a PCECC to set up Multicast Point-to-Multipoint (P2MP) LSP.</t>
    <t>Use LSPs
        </li>
        <li>
          use of a PCECC to set up Service Function Chaining (SFC) <xref target="RFC7665"/>.</t>
    <t>Use target="RFC7665" format="default"/>
        </li>
        <li>
          use of a PCECC in Optical Networks.</t>
  </list>
  </t> optical networks
        </li>
      </ul>
      <t><xref target="sect-3"/> target="sect-3" format="default"/> describes the general case of a  PCECC being in charge of
 	   managing MPLS label space space, 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>
      <section title="PCECC anchor="sect-3" numbered="true" toc="default">
        <name>PCECC for Label Management" anchor="sect-3"> Management</name>
        <t>As per <xref target="RFC8283"/>, target="RFC8283" format="default"/>, in some cases, the PCE-based controller PCECC 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><xref target="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 PCECC will
        take responsibility for managing some part of the MPLS label space for
        each of the routers that it controls.  An extension to PCEP could be
        done to allow a PCC to inform the PCE of such a label space to control. (See control
        (see <xref target="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 space to for the PCE to control.)</t> control).</t>

        <t><xref target="RFC8664"/> target="RFC8664" format="default"/> specifies extensions to PCEP that
   allow a stateful PCE to compute, update update, or initiate SR-TE paths.
   <xref target="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 an allocation allocation, the PCE needs to
   be aware of the label space from the Segment Routing Global Block (SRGB)
   or Segment Routing Local Block (SRLB)
   <xref target="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 <xref target="RFC9552"/> target="RFC9552" format="default"/> mechanisms.</t>
        <t>Further, there have been proposals for a global label range in MPLS, MPLS as well as the use of PCECC
    architecture could be used as a means to learn the label space of nodes, and could also be used each node to
	determine and provision the global label range.</t>

	<!--<t>
   This use case is based on network configuration illustrated using
   the following figure:</t>-->
  	<figure title="PCECC anchor="fig_label">
          <name>PCECC for MPLS Label Management" 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 | Node11 |        | Node1n | NODE 1n| |    | |NODE 21 | Node21 |        | Node2n | NODE 2n| |
| |        | ...... |        | |    | |        | ...... |        | |
| | PCECC  |        |  PCECC | |    | | PCECC  |        |PCECC   | |
| |Enabled |        | Enabled| |    | |Enabled |        |Enabled | |
| +--------+        +--------+ |    | +--------+        +--------+ |
|                              |    |                              |
+------------------------------+    +------------------------------+
]]></artwork>
        </figure>
	<t><list style="symbols"><t>As
<t>As shown in <xref target="fig_label"/>, target="fig_label"/>:</t>
        <ul spacing="normal">
          <li>
            <t>The PCC
            will advertise the PCECC capability to the PCE central
      controller (PCECC) PCECC  <xref target="RFC9050"/>.</t> target="RFC9050" format="default"/>.</t>
          </li>
          <li>
            <t>The PCECC could also learn the label range set aside by the PCC
            (via <xref target="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 the network.
  <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 <xref target="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>

      <section title="PCECC anchor="sect-4" numbered="true" toc="default">
        <name>PCECC and Segment Routing" anchor="sect-4">
    <t>Segment Routing (SR) SR</name>

        <t>SR <xref target="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 <xref target="RFC5036"/> target="RFC5036" format="default"/> or
        RSVP-TE <xref target="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
        the network, network or to perform a specific service on the packet.  A
        database of segments can be distributed through the network using a an
        intra-domain routing protocol (such as IS-IS or
   OSPF) or OSPF), an inter-domain
        protocol (BGP), (such as BGP), or by any other means.  PCEP could also be one
        of other protocols.</t>

         <t><xref target="RFC8664"/> target="RFC8664" format="default"/> specifies the
   SR-specific PCEP
        extension specific to SR for SR-MPLS. SR over MPLS (SR-MPLS). The PCECC may further
        use the PCEP protocol for distributing SR SIDs (Segment Identifiers)
   distribution Segment Identifiers (SIDs)
        to the SR nodes (PCC) with some benefits. If the PCECC allocates and
        maintains the SIDs in the network for the nodes and adjacencies; adjacencies, and
        further distributes them to the SR nodes directly via the PCEP session session,
        then it is more advantageous over the configurations on each SR node
        and flooding them via IGP, especially in an SDN environment. </t>

   <!--<t>
   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 the node.  For the allocation of Adj-SID, node and the
   allocation
   Adj-SID is allocated from the SRLB of the node as described in <xref target="I-D.ietf-pce-pcep-extension-pce-controller-sr"/>.</t> target="I-D.ietf-pce-pcep-extension-pce-controller-sr" format="default"/>.</t>
        <t><xref target="RFC8355"/> target="RFC8355" format="default"/> identifies various protection and resiliency usecases use cases for SR.
   Path protection lets the ingress node be in charge of the failure
   recovery (used for SR-TE <xref target="RFC8664"/>). target="RFC8664" format="default"/>). Also, protection can be
   performed by the node adjacent to the failed component, commonly
   referred to as local "local protection techniques techniques" or fast-reroute "fast-reroute (FRR) techniques. techniques".
   In the case of the PCECC, the protection paths can be pre-computed precomputed
   and set up by the PCE.</t>
        <t>
   The
   <xref target="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>
        <figure title="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>

     <section title="PCECC anchor="sect-4.1" numbered="true" toc="default">
          <name>PCECC SID Allocation for SR-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 the nexthop next hop and download the label
   forwarding instructions accordingly. The forwarding behaviour behavior and the end result
   are the same as IGP shortest-path SR forwarding based on Node-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 an Adj-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 forwarding behaviour behavior and the end result are similar to IGP-based
   Adj-SID allocation and usage in SR.</t>
          <t>These mechanisms are described in <xref target="I-D.ietf-pce-pcep-extension-pce-controller-sr"/>.</t> target="I-D.ietf-pce-pcep-extension-pce-controller-sr" format="default"/>.</t>
        </section>
        <section title="PCECC anchor="sect-4.2" numbered="true" toc="default">
          <name>PCECC for SR-MPLS Best Effort (BE) Path" anchor="sect-4.2"><t>
   In this use case, Paths</name>
          <t>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).  The ingress router of the forwarding path needs
   to encapsulate the destination Node-SID on top of the packet.
   All the intermediate nodes will forward the packet based on the
   destination Node-SID.  It is similar to the LDP LSP.</t>
          <t>R1 may send a packet to R8 simply by pushing an SR label with
   segment {1008} (Node-SID for R8). The path will be based on the routing/nexthop routing / next hop calculation on the routers.</t>
        </section>
        <section title="PCECC anchor="sect-4.3" numbered="true" toc="default">
          <name>PCECC for SR-MPLS TE Path" anchor="sect-4.3">

   		<t>SR-TE Paths</name>
          <t>
	    SR-TE paths may not follow an IGP shortest path tree (SPT).  Such
	    paths may be chosen by a PCECC and provisioned on the ingress node
	    of the SR-TE path.  The SR header consists of a list of SIDs (or
	    MPLS labels).  The header has all necessary information so that
	    the packets can be guided from the ingress node to the egress node
	    of the path. Hence, there is no need for any signalling protocol.
	    For the case where a strict traffic engineering path is needed,
	    all the Adj-SID Adj-SIDs are stacked, stacked; otherwise, a combination of node-SID Node-SIDs
	    or adj-SID Adj-SIDs can be used for the SR-TE paths.</t>

<t>As
          <t>
	    As shown in <xref target="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}. Where 1008}, where 1002 and 1008 are the Node-SID Node-SIDs of R2 and R8
	    R8, respectively. 9001 is the Adj-SID for link1. The path should
	    be: R1-R2-link1-R3-R8.</t> "R1-R2-link1-R3-R8".</t>
          <t>
	    To achieve this, the PCECC first allocates and distributes SIDs as
	    described in <xref target="sect-4.1"/>. target="sect-4.1" format="default"/>. <xref target="RFC8664"/>
	    target="RFC8664" format="default"/> describes the mechanism for a
	    PCE to compute, update, or initiate SR-MPLS TE paths.
	  </t>
          <figure title="PCECC anchor="fig-sr-te">
            <name>PCECC TE LSP Setup Example" 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 <xref target="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 a PCC. </t>

<t>PCECC PCC.</t>
            </li>
            <li>
              <t>The PCECC will calculate the optimal path according to the given
              constraints
   (e.g. bandwidth). </t>

<t> (e.g., bandwidth (BW)).</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> {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> ("R1-link2-R2-link4-R5-R8"): {90012, 1002, 90024, 1005, 1008}.</t>
            </li>
          </ul>

          <section title="PCECC anchor="sect-4.4" numbered="true" toc="default">
            <name>PCECC for SR Policy" anchor="sect-4.4"> Policy</name>

            <t><xref target="RFC8402"/> target="RFC8402" format="default"/> defines Segment Routing SR
            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 <xref target="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 specific SLA) Service Level Agreement (SLA)) from that
            node.</t>

	    <t>An SR Policy is identified through the tuple &lt;headend,
	    color,
   endpoint&gt;. </t> endpoint&gt;.</t>

	    <t><xref target="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 - are where the Node-SIDs are 100x and 900xx - the Adj-SIDs are Adj-SIDs.</t> 900xx.</t>

            <t>Let's assume that R1 needs to have two disjoint SR Policies
            towards R8 based on different bandwidths, BWs. This means the possible paths are:
   <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 <xref target="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)
            <xref target="RFC8402"/> target="RFC8402" format="default"/> can be used for traffic
            steering of labelled traffic into an SR Policy, Policy; a BSID can be
            provisioned from the PCECC also via PCEP <xref target="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 Color extended community Extended Community <xref target="RFC9012"/> </t>

   <t>
            target="RFC9012" format="default"/>.</t>

            <t>The procedure is as follows:</t>
            <ul>
              <li>
                The procedure: <list>
   <t> PCECC allocates Node-SIDs and Adj-SIDs using the mechanism described in <xref target="sect-4.1"/> target="sect-4.1" format="default"/> for all nodes and links. </t>
   <t>
              </li>
              <li>
                The PCECC will calculate calculates disjoint paths for POL1 and POL2 and create Segment Lists segment lists for them:{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 PCECC will form forms both SR Policies POL1 and POL2.</t>
   <t> POL2.
              </li>
              <li>
                The PCECC will send sends both POL1 and POl2 POL2 to R1 via PCEP. </t>
   <t>
              </li>
              <li>
                The PCECC optionally can allocate allocates BSIDs for the SR Policies.</t>

   <t>The Policies.
              </li>
              <li>
                The traffic from R1 to R8 R8, which fits to color 100 100, will be
                steered to POL1 and follows the path: R1-link1-R2-link3-R4-R3-R8.
                "R1-link1-R2-link3-R4-R3-R8". The traffic from R1 to R8 R8, which
                fits color 200 200, will be steered to POL2 and follows the path: R1-link2-R2-link4-R5-R6-R8.
                "R1-link2-R2-link4-R5-R6-R8". Due to the possibility of having
                many Segment Lists segment lists in the same Candidate Path candidate path of each
                POL1/POL2, the PCECC could provision more paths towards R8 and
                traffic will be balanced either as ECMP or as w/ECMP. weighted-ECMP (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 <xref target="RFC9256"/>.</t> target="RFC9256" format="default"/>.</t>
          </section>
        </section>

        <section title="PCECC anchor="sect-8" numbered="true" toc="default">
          <name>PCECC for SRv6" anchor="sect-8"> SRv6</name>
          <t>As per <xref target="RFC8402"/>, target="RFC8402" format="default"/>, with Segment Routing (SR),
          SR, a node steers a packet through an ordered list of
          instructions, called segments.  Segment Routing  SR can be applied to
          the IPv6 architecture with the Segment Routing Header (SRH) <xref target="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 the Destination Address destination address of the packet.  Upon completion
          of a segment, a pointer in the new routing header is incremented and
          indicates the next segment.</t>
          <t>As per <xref target="RFC8754"/>, target="RFC8754" format="default"/>, an SRv6 SR over IPv6
          (SRv6) Segment is a 128-bit value.  "SRv6 SID" or simply "SID" are
          often used as a shorter reference for "SRv6 Segment".  <xref target="RFC8986"/>
          target="RFC8986" format="default"/> defines the SRv6 SID as
          consisting of LOC:FUNCT:ARG.</t>
          <t><xref target="I-D.ietf-pce-segment-routing-ipv6"/> target="RFC9603" format="default"/> extends
   <xref target="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 <xref target="I-D.dhody-pce-pcep-extension-pce-controller-srv6"/>.</t> target="I-D.ietf-pce-pcep-extension-pce-controller-srv6" format="default"/>.</t>
          <figure title="PCECC anchor="fig_srv6">
            <name>PCECC for SRv6" 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 <xref target="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. Some examples -
    <list style="symbols">
      <t>SRv6 SID-List={2001:db8::8} - examples:
          </t>

          <ul spacing="normal">
            <li>
              The best path towards R8</t>
      <t>SRv6 SID-List={2001:db8::5, 2001:db8::8} - R8: SRv6 SID-List={2001:db8::8}
            </li>
            <li>
              The path towards R8 via R5</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>

      <section title="PCECC anchor="sect-5" numbered="true" toc="default">
        <name>PCECC for Static TE LSP" anchor="sect-5"> LSPs</name>
        <t>As described in Section 3.1.2 of <xref target="RFC8283"/>, target="RFC8283" section="3.1.2" sectionFormat="of"/>, the PCECC architecture supports
   the provisioning of static TE LSP. 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 PCECC 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>
        <figure title="PCECC anchor="fig-te">
          <name>PCECC TE LSP Setup Example" 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 <xref target="fig-te"/> target="fig-te" format="default"/> for an example TE topology.
	<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 optimization criteria. </t>

<t>PCECC criteria.</t>
          </li>
          <li>
            <t>The PCECC will calculate the optimal path according to the given constraints
   (e.g. bandwidth).</t>

<t>PCECC
   (e.g., BW).</t>
          </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 represented as as: {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>

      <section title="PCECC anchor="sect-lb" numbered="true" toc="default">
        <name>PCECC for Load Balancing (LB)" anchor="sect-lb"> (LB)</name>
        <t>
   Very often often, 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 <xref target="fig_lb"/> (AGG1...AGGN target="fig_lb" format="default"/> (where AGG 1...AGG N are Aggregation Routers, routers, and Core 1...Core N are Core routers) - routers). </t>

        <figure title="PCECC Load Balancing (LB) anchor="fig_lb">
          <name>PCECC LB Use Case" 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|    |Node1 | SubNode1|    | Node 1 |    +--------+    +--------+    +-----+    +-------+    +------+  +---+
+---------+
+--------+    +------+       | |         | ^          |
    |   Access    |  Access  | AGG Ring 1  | 1| |          |
    |  SubRing 1  |  Ring 1  | |         | |          |
+---------+
+--------+    +--------+         | |          |
| Access  |    | Access    +------+    +-----+        | | AGG 2          |
|Access  |    |Access|    |AGG 2|        | |          | SubNode2|
|SubNode2|    |Node2 | Node 2    +-----+        |    +--------+ |          |          |
+---------+
+--------+    +------+       | |         | |          |
    |             |          | |         | |          |
    |             |          | +----TE2----|-+ +---TE2---|-+          |
+---------+    +--------+    +--------+
+--------+    +------+    +-----+    +-------+    +------+  +---+
|Access  | Access  |    | Access |----| AGG 3  |----|    |Access|----|AGG 3|----| AGG N |----|Core N|--|SRn|
|SubNodeN|----|NodeN | 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
   two Egress egress routers (AGG N-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 service routers, routers;
   RSVP-TE or SR-TE is used for MPLS transport inside the ring. There could be
   at least 2 two tunnels (one way) from each AGG router to egress AGG
   routers. There are also many L2 access rings connected to AGG routers.</t>

        <t>
   Service deployment is made by means of Layer 2 Virtual Private Networks (L2VPNs) (Virtual
   (L2VPNs), Virtual Private LAN Services (VPLS)), (VPLSs), Layer 3 Virtual Private
   Networks (L3VPNs) (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 Balancing (LB) between TE tunnels involves distributing network
        traffic across multiple TE tunnels to optimize the use of available
        network resources, enhance performance, and ensure reliability. Some
        common techniques include Equal-Cost Multi-Path Multipath (ECMP) and
        Unequal-Cost Multi-Path Multipath (UCMP) based on the bandwidth BW of the TE
        tunnels.</t>
<t>There is a need to solve the following tasks:
  <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>Perform automatic load-balance LB amongst TE tunnels according to current traffic load.</t>
	<t>TE bandwidth (BW) management: Provide guaranteed loads.</t>
          </li>
          <li>
            <t>Manage TE BW by guaranteeing BW for specific
       services:
      services (such as High-Speed Data Service (HSI)), Internet (HSI), IPTV, etc., etc.)
           and provide enabling time-based BW reservation (BW (such as Bandwidth
           on demand (BoD)) for other services.</t> Demand (BoD)).</t>
          </li>
          <li>
            <t>Simplify the development of TE tunnels by automation without any manual intervention.</t>
          </li>
          <li>
            <t>Provide flexibility for Service Router service 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) LB tasks. LB task tasks
        could be solved by means of the PCECC in the following way:
	<list style="symbols">
    <t>Application or ways:
        </t>

        <ul spacing="normal">
          <li>
            <t>Applications, network service services, or operator operators can ask the SDN
            controller (PCECC) for LSP-based load balancing LB 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. bandwidth,
            (such as BW, inclusion or exclusion of specific links or nodes,
            number of paths, objective function Objective Function (OF), need for disjoint LSP paths etc.);</t>

	<t>PCECC
            paths, etc.).</t>
          </li>
          <li>
            <t>The PCECC could calculate multiple (say N) LSPs according to given constraints,
       the
            constraints. The calculation is based on the results of Objective Function (OF) the OF <xref target="RFC5541"/>, target="RFC5541" format="default"/>,
            constraints, endpoints, same or different
       bandwidth (BW), BW,
            different links (in case of disjoint paths) paths), and other
            constraints.</t>
          </li>
          <li>
            <t>Depending on the given LSP Path setup type (PST), 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>

<li>
            <t>The PCECC will send a PCInitiate message <xref target="RFC8281"/> target="RFC8281"
            format="default"/> towards the ingress AGG X router(PCC) router (PCC) for each of
            N LSPs and receive a PCRpt message <xref target="RFC8231"/> target="RFC8231"
            format="default"/> back from PCCs. If the PST is a PCECC-SR, the PCECC
            will include a SID stack as per <xref target="RFC8664"/>. target="RFC8664"
            format="default"/>.  If the PST is PCECC (basic), set to "PCECC" type, 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 <xref target="RFC9050"/> and then target="RFC9050"
            format="default"/>. Then, the PCECC will send a PCUpd message to the ingress AGG
            X router with information about the new LSP. AGG X(PCC) 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 AGG N-1 N-1,
       which are available for installation to the router's forwarding table and load-balance for LB traffic
       between them. Traffic distribution between those LSPs depends on
       the particular realization of the hash-function hash function on that router.</t>
          </li>
          <li>
            <t>Since the PCECC is aware of TEDB the Traffic Engineering Database (TED) (TE state) and LSP-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 PCECC mechanism mechanism, the control can take quick actions into the network by directly provisioning the central control instructions.</t>

	</list>
	</t>
          </li>
        </ul>
      </section>
      <section title="PCECC anchor="sect-5.1" numbered="true" toc="default">
        <name>PCECC and Inter-AS TE" anchor="sect-5.1"> TE</name>
        <t>
	  There are various signalling options for establishing Inter-AS TE LSP:
	  LSPs: contiguous TE LSP LSPs <xref target="RFC5151"/>, target="RFC5151" format="default"/>,
	  stitched TE LSP LSPs <xref target="RFC5150"/>, target="RFC5150" format="default"/>, and
	  nested TE LSP LSPs <xref target="RFC4206"/>.</t> target="RFC4206" format="default"/>.</t>
        <t>
   Requirements
   The requirements for PCE-based Inter-AS setup <xref target="RFC5376"/> target="RFC5376" format="default"/> describe the approach
   and PCEP functionality that is needed for establishing Inter-AS TE LSPs.</t>
        <t>
   <xref target="RFC5376"/> target="RFC5376" format="default"/> also gives Inter- an Inter-AS and
   Intra-AS PCE Reference Model (as shown in <xref target="fig_short"/>) target="fig_short"
   format="default"/>) that is provided below in shortened form for the sake
   of simplicity.</t>
        <figure title="Shortened form anchor="fig_short">
          <name>Shortened Form of Inter- the Inter-AS and Intra-AS PCE Reference Model" 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
        up inter-AS Inter-AS TE LSP. LSPs. The stateful H-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 form inter-AS
        an Inter-AS TE LSP as described in <xref target="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, Inter Inter-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 <xref target="RFC8283"/>. Thus target="RFC8283" format="default"/>. Thus, routers
	  (PCCs) in AS1 and AS2 can send PCEP messages towards the same
	  PCECC. In <xref target="fig_inter_as_pce"/>, target="fig_inter_as_pce" format="default"/>, the PCECC
	  maintains a BGP-LS session with route reflectors Route 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-LS Propagator
	  Propagator, and the PCECC act acts as a BGP-LS Consumer <xref target="RFC9552"/>.</t> target="RFC9552"
	  format="default"/>.</t>
        <figure title="Particular case anchor="fig_inter_as_pce">
          <name>Particular Case of Inter-AS PCE" 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 <xref target="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>
   As per <xref target="fig_inter_as_pce"/>, 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 from R1 to R3 that goes via
   ASBR5 and ASBR6 are is the backup ones. one. In addition, there could also be a bypass LSP
   setup to protect against ASBR or inter-AS Inter-AS link failures.</t>
        <t>
	  After the addition of PCECC functionality to the PCE (SDN controller),
	  the PCECC-based Inter-AS TE model should follow the PCECC use case
	  for TE LSP including the requirements of described in <xref target="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 also section 4 in <xref target="RFC5376"/>).</t> target="RFC5376" section="4" sectionFormat="of"/>).</t>
          </li>
          <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 the Northbound Interface (NBI) (note that the NBI
       (NBI type is implementation dependent,
            implementation-dependent; it could be NETCONF/Yang, REST NETCONF/YANG, REST,
            etc.). Then Then, the PCECC will calculate the optimal path based on Objective Function (OF) the OF and
            given constraints (i.e. path setup type, bandwidth etc.), including (i.e., PST, BW, etc.). These constraints include
            those from <xref target="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>PCECC
            "R1-ASBR1-ASBR3-R3, R1-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 it controls controls, and in the case of SR SR, the SID
            allocation and distribution is already done.</t>

  <t>PCECC
          </li>
          <li>
            <t>The PCECC will send a PCInitiate message <xref target="RFC8281"/> target="RFC8281"
            format="default"/> towards the ingress router R1 (PCC) in AS1 and
            receive the PCRpt message <xref target="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 <xref target="RFC8664"/>. target="RFC8664" format="default"/>.  Optionally,
                a binding SID BSID or BGP Peering-SID <xref target="RFC9087"/> target="RFC9087"
                format="default"/> can also be included on the AS
                boundary. The backup SID stack can be installed at ingress R1 R1,
                but more importantly, each node along the SR path could also
                do the local protection just based on the top segment.</t>
              </li>
              <li>
                <t>If the PST is a PCECC, the PCECC will assign labels along the
                calculated paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3) ("R1-ASBR1-ASBR3-R3", "R1-ASBR5-ASBR6-R3") and
                sets up the path by sending central controller instructions in a
                PCEP message to each node along the path of the LSPs as per
                <xref target="RFC9050"/>. 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>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>--> status.</t>
              </li>
            </ul>
          </li>
	<li>
            <t>After that step, R1 now have has primary and backup TEs (LSP1 and LSP2) towards
       R3. It is up to the router implementation for how to make switchover to backup LSP2 if LSP1 fails.</t>

  </list></t>
          </li>
        </ul>
      </section>
      <section title="PCECC anchor="sect-6" numbered="true" toc="default">
        <name>PCECC for Multicast LSPs" 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 controller which that
   has the full picture of the topology and bandwidth BW 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>

        <section title="PCECC anchor="sect-6.1" numbered="true" toc="default">
          <name>PCECC for P2MP/MP2MP LSPs' Setup" anchor="sect-6.1">
    <!--<t>
   With the capability Setup 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>--> P2MP/MP2MP LSPs</name>
   <t>It is assumed the PCECC is aware of the label space it controls for
   all nodes and makes allocations accordingly.</t>

          <figure title="Using anchor="fig_p2mp">
            <name>Using a PCECC for the Setup of P2MP/MP2MP LSPs' Setup" anchor="fig_p2mp"><artwork><![CDATA[ LSPs</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                       +----------+
                       |    R1    | Root node Node of the multicast LSP
                       +----------+
                           |9000 (L0) (link0)
                       +----------+
        Transit Node   |    R2    |
        branch         +----------+
                       *  |   *  *
                  9001*   |   *   *9002
                  L1
               link1 *    |   *    *L2    *link2
        +-----------+     |   *     +-----------+
        |    R4     |     |   *     |    R5     | Transit Nodes
        +-----------+     |   *     +-----------+
                   *      |   *      *     +
                9003*     |   *     *      +9004
                L3
               link3 *    |   *    *       +L4       +link4
                     +-----------+  +-----------+
                     |    R3     |  |    R6     | Leaf Node
                     +-----------+  +-----------+
                      9005| L5 link5
                     +-----------+
                     |    R8     | Leaf Node
                     +-----------+
]]></artwork>
          </figure>
          <t>The P2MP examples (based on <xref target="fig_p2mp"/>) target="fig_p2mp" format="default"/>) are explained here, where R1 is the root and the router routers 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., BW).</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" "R1-link0-R2-link2-R5-link4-R6" and "R1-L0-R2-L1-R4-L3-R3-L5-R8":
      <list style="symbols"> "R1-link0-R2-link1-R4-link3-R3-link5-R8":
              </t>
              <ul spacing="normal">
                <li>
                  <t>R1: Outgoing label 9000 on link L0</t> link0</t>
                </li>
                <li>
                  <t>R2: Incoming label 9000 on link L0</t> link0</t>
                </li>
                <li>
                  <t>R2: Outgoing label 9001 on link L1 link1 (*)</t>
                </li>
                <li>
                  <t>R2: Outgoing label 9002 on link L2 link2 (*)</t>
                </li>
                <li>
                  <t>R5: Incoming label 9002 on link L2</t> link2</t>
                </li>
                <li>
                  <t>R5: Outgoing label 9004 on link L4</t> link4</t>
                </li>
                <li>
                  <t>R6: Incoming label 9004 on link L4</t> link4</t>
                </li>
                <li>
                  <t>R4: Incoming label 9001 on link L1</t> link1</t>
                </li>
                <li>
                  <t>R4: Outgoing label 9003 on link L3</t> link3</t>
                </li>
                <li>
                  <t>R3: Incoming label 9003 on link L3</t> link3</t>
                </li>
                <li>
                  <t>R3: Outgoing label 9005 on link L5</t> link5</t>
                </li>
                <li>
                  <t>R8: Incoming label 9005 on link L5</t>
   </list></t> link5</t>
                </li>
              </ul>
            </li>
            <li>
              <t>This can also be represented as
   : as: {R1, 6000}, {6000, R2, {9001,9002}},
              {9001, 9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3,
              9005}, {9004, R6}, {9005, R8}. The main difference (*) is in the
              branch node instruction at R2 R2, where two copies of a packet are
              sent towards R4 and R5 with 9001 and 9002 labels labels, respectively.</t>

  </list></t>
            </li>
          </ul>
          <t>The packet forwarding involves -
  <list>
	<t>
   Step 1: R1 the following:</t>
          <ol type="Step %d.">
            <li>R1 sends a packet to R2 simply by pushing the label of 9000 to
            the packet.</t>

	<t>
   Step 2: When packet.</li>
            <li>When R2 receives the packet with label 9000, it will forward
            it to R4 by swapping label 9000 to 9001 and at 9001. At the same time, it will
            replicate the packet and swap the label 9000 to 9002 and forward
            it to R5.</t>

	<t>
   Step 3: When R5.</li>
            <li>When R4 receives the packet with label 9001, it will forward
            it to R3 by swapping 9001 to 9003. When R5 receives the packet
            with the label 9002, it will forward it to R6 by swapping 9002 to
   9004.</t>

	<t>
   Step 4: When
            9004.</li>
            <li>When R3 receives the packet with label 9003, it will forward
            it to R8 by swapping it to 9005 and when 9005. When R5 receives the packet with
            label 9002, it will be swapped to 9004 and sent to R6.</t>

   <t>Step 5: When R6.</li>
            <li>When R8 receives the packet with label 9005, it will pop the label; when
            label. When R6 receives the packet with label 9004, it will pop
            the label.</t>
  </list></t> label.</li>
          </ol>
        </section>
        <section title="PCECC anchor="sect-6.2" numbered="true" toc="default">
          <name>PCECC for the End-to-End Protection of P2MP/MP2MP LSPs" 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>
          <figure title="PCECC anchor="fig_p2mp-res">
            <name>PCECC for the End-to-End Protection of the P2MP/MP2MP LSPs" anchor="fig_p2mp-res"><artwork><![CDATA[ LSPs</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                            +----+  +----+
           Root node Node of LSP | R1 |--| R11|
                            +----+  +----+
                              /         +
                           10/           +20
                            /             +
                    +----------+        +-----------+
     Transit Node   |    R2    |        |     R3    |
                    +----------+        +-----------+
                      |        \       +         +
                      |         \     +          +
                    10|        10\   +20       20+
                      |           \ +            +
                      |            \             +
                      |           + \            +
                    +-----------+      +-----------+ Leaf Nodes
                    |    R4     |      |    R5     | (Downstream LSR)
                    +-----------+      +-----------+
]]></artwork>
          </figure>
          <t>
   In <xref target="fig_p2mp-res"/>, target="fig_p2mp-res" format="default"/>, when the PCECC setups sets up the primary multicast tree
   from the root node R1 to the leaves, which is R1-&gt;R2-&gt;{R4, R5}, at the
   same time, it can setup set up the backup tree, tree at the same time, which is R1-&gt;R11-&gt;R3-&gt;{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-&gt;R2-&gt;{R4, R5} path normally,  but when a node in the
   primary tree fails (say R2) R2), the root node R1 will switch the flow to the
   backup tree, which is R1-&gt;R11-&gt;R3-&gt;{R4, R5}. By using the PCECC a PCECC,
   path computation, label downloading downloading, and finally forwarding can be done
   without the complex signalling used in the P2MP RSVP-TE or mLDP.</t>
        </section>
        <section title="PCECC anchor="sect-6.3" numbered="true" toc="default">
          <name>PCECC for the Local Protection of the P2MP/MP2MP LSPs" 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), the protected node node, 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
   congestion risk.</t> risks.</t>
          <figure title="PCECC anchor="fig_p2mp-loc">
            <name>PCECC for the Local Protection of the P2MP/MP2MP LSPs" anchor="fig_p2mp-loc"><artwork><![CDATA[ LSPs</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                            +------------+
                            |     R1     | Root Node
                            +------------+
                                   .
                                   .
                                   .
                            +------------+ Point of Local Repair/ 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 <xref target="fig_p2mp-loc"/>, target="fig_p2mp-loc" format="default"/>, when the PCECC setups sets up the primary multicast path
   around the PLR node R10 to protect node R20, which is R10-&gt;R20-&gt;{R40,
   R50}, at the same time, it can set up the backup path R10-&gt;R30-&gt;{R40,
   R50}.
   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-&gt;R20-&gt;{R40, R50} path normally normally, 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-&gt;R30-&gt;{R40, R50}.  By using the PCECC,
   path computation, label downloading downloading, and finally forwarding can be done
   without the complex signalling used in the P2MP RSVP-TE or mLDP.</t>
        </section>
      </section>
      <section title="PCECC anchor="sect-7" numbered="true" toc="default">
        <name>PCECC for Traffic Classification" anchor="sect-7"> Classification</name>
        <t>As described in <xref target="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
   many scenarios scenarios, including the following:
   <list><t>MPLS
        </t>
        <ul>
          <li>
            MPLS traffic engineering (where it determines what traffic is
            forwarded into which LSPs),</t>
   <t>Segment Routing LSPs),
          </li>
          <li>
	    SR (where it is used to select which set of
	    forwarding instructions (SIDs) to add to a packet),</t>
   <t>SFC packet), and
          </li>
          <li>
	    SFC (where it indicates how a packet should be forwarded across
	    which service function path ).</t></list></t> path).
          </li>
        </ul>
        <t>In conjunction with traffic engineering, traffic classification is an
   important enabler for load balancing. LB. 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>

        <t>The description of traffic flows by the combination of multiple Flow Specification components and their dissemination as traffic flow specifications (Flow Specifications) Flow Specifications is described for BGP in <xref target="RFC8955"/>. target="RFC8955" format="default"/>. When a PCECC is used to initiate tunnels (such as TE-LSPs TE LSPs or SR paths) using PCEP, it is important that the head end headend of the tunnels understands what traffic to place on each tunnel. <xref target="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>
   Along with traffic classification, there are a few more questions about the tunnels set up by the PCECC that need to be considered after path setup:

	<list style="symbols"><t>how considered:
        </t>
        <ul spacing="normal">
          <li>
            <t>how to use it</t>

	<t>Whether it,</t>
          </li>
          <li>
            <t>whether it is a virtual link</t>

	<t>Whether link,</t>
          </li>
          <li>
            <t>whether to advertise it in the IGP as a virtual link</t>

	<t>What link, and</t>
          </li>
          <li>
            <t>what bits of this information to signal to the tail end</t>

	</list>
	</t> end.</t>
          </li>
        </ul>
        <t>These are out of the scope of this document.</t>
      </section>

      <section title="PCECC for SFC" anchor="sect-9" > numbered="true" toc="default">
        <name>PCECC for SFC</name>
        <t>Service Function Chaining (SFC) is described in <xref target="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 LB between service
   function nodes and traffic engineering across the network that
   connects them.  As per <xref target="RFC8283"/>, target="RFC8283" format="default"/>, these are operations that can be performed by a
   PCE-based controller,
   PCECC, 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 SFF Service Function Forwarder (SFF) along the SFP.
    <list style="symbols">
      <t>Service SFP.</t>
        <ul>
          <li>Service Path Identifier (SPI): Uniquely identifies an SFP. </t>
      <t>Service SFP.</li>
          <li>Service Index (SI): Provides location within the SFP.</t>
      <t>SFC SFP.</li>
          <li>Provide SFC Proxy handling</t>
    </list>
   </t>
   <t>PCECC handling instruction.</li>
	</ul>
        <t>The PCECC can play the role of setting the traffic classification rules (as per <xref target="sect-7"/>) target="sect-7" format="default"/>) at the classifier to impose the Network Service Header (NSH) <xref target="RFC8300"/> as well as downloading target="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. Including This includes instructions for the service classifier that handles the context header, metadata metadata, 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 <xref target="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 <xref target="RFC9491"/> target="RFC9491" format="default"/> and <xref target="I-D.ietf-spring-sr-service-programming"/>. target="I-D.ietf-spring-sr-service-programming" format="default"/>. PCECC technique techniques can also be used for service function-related service-function-related segments and SR service policies. </t>
      </section>
      <section title="PCECC anchor="sect-10" numbered="true" toc="default">
        <name>PCECC for Native IP" 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. <xref target="RFC8821"/> target="RFC8821" format="default"/>
	  defines the framework for CCDR traffic engineering within a Native native
	  IP network, using multiple BGP sessions and a PCE as the centralized
	  controller. It requires the PCECC to send the instructions to the
   PCCs,
	  PCCs to build multiple BGP sessions, distribute different prefixes
	  on the established BGP sessions sessions, and assign the different paths to
	  the BGP next hops. The PCEP protocol is used to transfer the key
	  parameters between the PCE and the underlying network devices (PCC)
	  using the PCECC technique. The central control instructions from
	  the PCECC to PCC will identify which prefix should be advertised on
	  which BGP session. There are PCEP extensions defined in <xref target="I-D.ietf-pce-pcep-extension-native-ip"/>
	  target="I-D.ietf-pce-pcep-extension-native-ip" format="default"/>
	  for it.</t> it.
	</t>
        <figure title="PCECC anchor="fig_native_ip">
          <name>PCECC for Native IP" 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 the case, case as shown in <xref target="fig_native_ip"/>, target="fig_native_ip"
        format="default"/>, the PCECC will instruct both R1 and R2 via PCEP how to form BGP
        sessions with each other via PCEP and which IP prefixes need to be
        advertised via which BGP session.</t>
      </section>

      <section title="PCECC anchor="sect-11" numbered="true" toc="default">
        <name>PCECC for BIER" anchor="sect-11"> BIER</name>
        <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> target="RFC8279"
        format="default"/> defines an architecture where all intended
        multicast receivers are encoded as a
   bitmask BitMask in the multicast packet
        header within different encapsulations.  A router that receives such a
        packet will forward that packet based on the bit position in the
        packet header towards the receiver(s) following a precomputed tree for
        each of the bits in the packet.  Each receiver is represented by a
        unique bit in the bitmask.</t> BitMask.</t>
        <t>BIER-TE <xref target="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 <xref target="I-D.chen-pce-bier"/>).</t>

   <t>PCECC
        target="I-D.ietf-pce-bier-te" format="default"/>).</t>

        <t>The PCECC mechanism could be used for the allocation of bits for the
        BIER router for BIER as well as for the adjacencies for
        BIER-TE. PCECC-based controllers can use PCEP to instruct the
        BIER-capable routers on the meaning of the bits as well as other
        fields needed for BIER encapsulation. The PCECC could be used to
        program the BIER router with various parameters used in the BIER
        encapsulation such (such as BIER subdomain-ID, BFR-ID, BIER Encapsulation etc. sub-domain-id, BFR-id,
        etc.) for both node and adjacency.</t>
<t> A

        <t>A possible way for to use the PCECC usage and PCEP extension is described in
        <xref target="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>

    <section title="IANA Considerations" anchor="sect-12"><t>
   This anchor="sect-12" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document does not require any action from IANA.</t> has no IANA actions.</t>
    </section>

    <section title="Security Considerations" anchor="sect-13"> anchor="sect-13" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t><xref target="RFC8283"/> target="RFC8283" format="default"/> describes how the security
      considerations for a PCE-based controller PCECC are a little different from
      those for any other PCE system.  PCECC operations rely heavily on the
      use and security of PCEP, so due consideration should be given to the
      security features discussed in <xref target="RFC5440"/> target="RFC5440" format="default"/>
      and the additional mechanisms described in <xref target="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 <xref target="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 PCECC 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>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
	<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 to Derrell Piper for advertise the SECDIR review. Thanks PCE Controlled Identifier Space
</title>
<author fullname="Cheng Li" initials="C." surname="Li">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Hang Shi" initials="H." surname="Shi" role="editor">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Aijun Wang" initials="A." surname="Wang">
<organization>China Telecom</organization>
</author>
<author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
<organization>China Mobile</organization>
</author>
<author fullname="Chao Zhou" initials="C." surname="Zhou">
<organization>HPE</organization>
</author>
<date day="4" month="June" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-controlled-id-space-00"/>
</reference>

<!-- [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 to Sue Hares for GENART review.</t>
   <t>Thanks XML.-->
<reference anchor="I-D.ietf-mpls-seamless-mpls" target="https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls-07">
<front>
<title>Seamless MPLS Architecture</title>
<author fullname="Nicolai Leymann" initials="N." surname="Leymann" role="editor">
<organization>Deutsche Telekom AG</organization>
</author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems</organization>
</author>
<author fullname="Maciek Konstantynowicz" initials="M." surname="Konstantynowicz" role="editor">
<organization>Cisco Systems</organization>
</author>
<author fullname="Dirk Steinberg" initials="D." surname="Steinberg">
<organization>Steinberg Consulting</organization>
</author>
<date day="28" month="June" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-seamless-mpls-07"/>
</reference>

<!-- [I-D.chen-pce-bier] IESG state: Replaced by draft-ietf-pce-bier-te as of 06/06/24
Updated from "draft-chen-pce-bier" to Vishnu 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&amp;T</organization>
</author>
<author fullname="Wim Henderickx" initials="W." surname="Henderickx">
<organization>Nokia</organization>
</author>
<author fullname="Stefano Salsano" initials="S." surname="Salsano">
<organization>Universita di Roma "Tor Vergata"</organization>
</author>
<date day="23" month="August" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-service-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 and Jim Guichard citation tags for being the responsible AD.</t>
   <t>Thanks [PCE-BINDING-LABEL-SID] to Roman 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] IESG review 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>
            <date month="may" year="2011" /> month="May" year="2011"/>
          </front>
          <seriesInfo name="" 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>
            <date month="march" year="2014" /> month="March" year="2014"/>
          </front>
        <seriesInfo name="" value="" />
        </reference>

      </references>
    </references>
    <section title="Other anchor="sect-15" numbered="true" toc="default">
      <name>Other Use Cases of PCECC" 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 working group, group but are not in active development at the time of publication. They are listed here for future consideration.</t>
      <section title="PCECC anchor="sect-15.1" numbered="true" toc="default">
        <name>PCECC for Network Migration" 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>

        <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 protocols 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 for both: both old and new nodes.</t>
        <t>
   The example described in this section is based on network configurations
   illustrated using in <xref target="fig_mig"/>:</t> target="fig_mig" format="default"/>:</t>
        <figure title="PCECC Initiated anchor="fig_mig">
          <name>PCECC-Initiated LSP Setup In in the Network Migration" 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 Node1  |   | NODE 2 Node2  |   | NODE 3 Node3  |   | NODE 4 Node4  |   | NODE 5 Node5  |   |
| |        |...|        |...|        |...|        |...|        |   |
| | 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 headend
        (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 as Node5.</t>

  <t>PCECC Node5.
          </li>
          <li>
            The PCECC sends to Node1 a 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 with With the help of PCECC the PCECC, Node3 could proxy the signalling.</t>

  <t>Then signalling.
          </li>
          <li>
            Then, the PCECC will program the out-segment of Node3, the in-segment/
      out-segment
	    in-segment/out-segment of Node4, and the in-segment for Node5.</t>

  </list>
  </t> Node5.
          </li>
        </ul>
      </section>

      <section title="PCECC anchor="sect-15.2" numbered="true" toc="default">
        <name>PCECC for L3VPN and PWE3" anchor="sect-15.2"> PWE3</name>

        <t>As described in <xref target="RFC8283"/>, target="RFC8283" format="default"/>, various
        network services may be offered over a network.  These include
        protection services (including Virtual Private Network (VPN) services (such
        such as Layer 3 VPNs L3VPN <xref target="RFC4364"/> target="RFC4364" format="default"/> or Ethernet VPNs
        EVPNs <xref target="RFC7432"/>); target="RFC7432" format="default"/>) or Pseudowires
        pseudowires <xref target="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
        PCECC 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>
   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 the PE Provider Edge (PE) router instead of using the BGP
   protocols.</t>
        <t>
   The example described in this section is based on network configurations
   illustrated using in <xref target="fig_l3vpn"/>:</t> target="fig_l3vpn" format="default"/>:</t>
        <figure title="PCECC anchor="fig_l3vpn">
          <name>PCECC for L3VPN and PWE3" anchor="fig_l3vpn"><artwork><![CDATA[ PWE3</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
            +-------------------------------------------+
            |                   PCE DOMAIN              |
            |    +-----------------------------------+  |
            |    |                PCECC              |  |
            |    +-----------------------------------+  |
            |           ^          ^              ^     |
            |PWE3/L3VPN
            | PCEP PWE3/L3VPN|PCEP  PCEP|LSP PWE3/L3VPN|PCEP |
            |           V          V              V     |
 +--------+ |     +--------+   +--------+   +--------+  |  +--------+
 |  CE    | |     | PE1    |   | NODE x Nodex  |   | PE2    |  |  |   CE   |
 |        |...... |        |...|        |...|        |.....|        |
 | Legacy | |if1  | PCECC  |if2|PCCEC  |if2|PCECC   |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>
      <section title="PCECC anchor="sect-15.3" numbered="true" toc="default">
        <name>PCECC for Local Protection (RSVP-TE)" anchor="sect-15.3"> (RSVP-TE)</name>
        <t><xref target="I-D.cbrt-pce-stateful-local-protection"/> claim target="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 and delegated, delegated or PCE-initiated.  In
   either case, the PLR needs to maintain a PCEP session with the PCE. The Bypass bypass LSPs
   need to be mapped to the primary LSP. This could be done locally at the PLR based on a local policy policy,
   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>
      <section title="Using reliable anchor="sect-15.4" numbered="true" toc="default">
        <name>Using Reliable P2MP TE based multicast delivery TE-Based Multicast Delivery for distributed 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.0 architecture architecture,
   MapReduce operations occur on big data <!--performs by means of Master-Slave architecture-->in 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 have 3 three saved copies in
   different DataNodes based on their proximity.</t>
        <t>
   The proximity level currently has a semi-manual allocation and is based on
   Rack IDs (The (the assumption is that closer data are is better because of access
   speed/smaller
   speed / smaller latency).</t>
        <t>
   The JobTracker node is responsible for computation tasks, tasks and scheduling across
   DataNodes and also has Rack-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 data centre center (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 the fibre fiber 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 of NPU-based routers based on Network Processing Unit (NPU)
   should be enough for creating distributed Hadoop clusters with predicted
   latency. The performance of software-based routers (mainly virtual 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 <xref target="MAP-REDUCE"/> target="MAP-REDUCE" format="default"/> that show shows
   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 conventional IP-based multicast may not be appropriate because it
   requires an additional control plane (IGMP, PIM) and a lot of signalling, that which
   is not suitable for high-performance computations, 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 BW 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
   <xref target="MPLS-DC"/>. Technically target="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 and OVS.</t> Open vSwitch (OVS).</t>
        <t>A possible framework for this task is shown in <xref target="fig_mapred"/>: target="fig_mapred" format="default"/>:
        </t>
        <figure title="Using reliable anchor="fig_mapred">
          <name>Using Reliable P2MP TE based multicast delivery TE-Based Multicast Delivery for distributed 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, NameNode NameNode, and PCECC can be done
        via REST API directly or via a cluster manager such as Mesos.</t>
<ul>
  <li>
    <t>
      Phase 1: Distributed cluster resources resource discovery
   During occurs during this phase,
      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 topological proximity, proximity
      and redundancy level.</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 that framework.</t>

  <t> framework.
    </t>
  </li>
  <li>
    Phase 2: The PCECC should create P2MP LSP LSPs from the client towards those
    DataNodes by means of PCEP messages following the previously calculated path.</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>
    Phase 4. 4: The Client client sends data blocks to those DataNodes for writing via
    the created P2MP tunnel.</t>

  <t>
   When tunnel.
  </li>
</ul>
        <t>When this task is finished, the P2MP tunnel could be turned down.</t>
      </section>
    </section>

    <section title="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 of America

   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
   EPAM America</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] 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...
-->

  </back>
</rfc>