<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) --> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">
<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-teas-pce-native-ip-17"
     ipr="trust200902"> number="8821" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="pce abbrev="PCE in native ip">Path Computation Element (PCE) based Native IP">PCE-Based
    Traffic Engineering (TE) in Native IP Networks</title>
    <seriesInfo name="RFC" value="8821"/>
    <author fullname="Aijun Wang" initials="A" surname="Wang">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street> Town</street>
          <extaddr>Changping District</extaddr>
          <city>Beijing</city>

          <region/>
          <code>102209</code>
          <country>China</country>
        </postal>
        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>
    <author fullname="Boris Khasanov" initials="B" surname="Khasanov">
      <organization>Yandex LLC</organization>
      <address>
        <postal>
          <street/>
          <street>Ulitsa Lva Tolstogo 16</street>
          <city>Moscow</city>

          <region/>

          <code/>

          <country>Russia</country>
          <country>Russian Federation</country>
        </postal>
        <email>bhassanov@yahoo.com</email>
      </address>
    </author>
    <author fullname="Quintin Zhao" initials="Q" surname="Zhao">
      <organization>Etheric Networks</organization>
      <address>
        <postal>
          <street>1009 S CLAREMONT ST</street>

          <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="Huaimo Chen" initials="H" surname="Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street/>
          <city>Boston</city>
          <region>MA</region>

          <code/>
          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>huaimo.chen@futurewei.com</email>

        <uri/>
      </address>
    </author>
    <date day="2" month="February" month="April" year="2021"/>
    <area>RTG Area</area>
    <workgroup>TEAS Working Group</workgroup>

    <keyword>RFC</keyword>
    <abstract>
      <t>This document defines an architecture for providing traffic
      engineering in a native IP network using multiple BGP sessions and a
      Path Computation Element (PCE)-based central control mechanism. It
      defines the Central Centralized Control Dynamic Routing (CCDR) procedures and
      identifies needed extensions for the Path Computation Element
      Communication Protocol (PCEP).</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> anchor="intro">
      <name>Introduction</name>
      <t><xref target="RFC8283"/>, based on an extension of the Path
      Computation Element (PCE)
      PCE architecture described in <xref
      target="RFC4655"/> , target="RFC4655"/>, introduced a broader use applicability for a PCE as
      a central controller. PCEP Protocol (PCEP) continues to be used as the
      protocol between the PCE and the Path Computation Client (PCC). Building on that
      work, this document describes a solution of using a PCE for centralized
      control in a native IP network to provide End-to-End end-to-end (E2E) performance
      assurance and QoS for traffic. The solution combines the use of
      distributed routing protocols and a centralized controller, referred to
      as Centralized Control Dynamic Routing (CCDR).</t>
      <t><xref target="RFC8735"/> describes the scenarios and simulation
      results for traffic engineering in a native IP network based on use of a
      CCDR architecture. Per <xref target="RFC8735"/>, the architecture for
      traffic engineering in a native IP network should meet the following
      criteria:</t>

      <t><list style="symbols">
          <t>Same
      <ul>
        <li>Same solution for native IPv4 and IPv6 traffic.</t>

          <t>Support traffic.</li>
        <li>Support for intra-domain and inter-domain scenarios.</t>

          <t>Achieve End to End scenarios.</li>
        <li>Achieve E2E traffic assurance, with determined QoS
          behavior, for traffic requiring a service assurance (prioritized
          traffic).</t>

          <t>No
          traffic).</li>
        <li>No changes in a router's forwarding behavior.</t>

          <t>Based behavior.</li>
        <li>Based on centralized control through a distributed network
          control plane.</t>

          <t>Support plane.</li>
        <li>Support different network requirements such as high traffic
          volume and prefix scaling.</t>

          <t>Ability scaling.</li>
        <li>Ability to adjust the optimal path dynamically upon the changes
          of network status. No need for reserving resources for physical links resources reservations
          to be done
          in advance.</t>
        </list></t> advance.</li>
      </ul>
      <t>Building on the above documents, this document defines an
      architecture meeting these requirements by using a strategy of multiple BGP session
      strategy sessions
      and a PCE as the centralized controller. The architecture
      depends on the central control (PCE) element (PCE) to compute the optimal
      path,
      path and utilizes the dynamic routing behavior of IGP/BGP protocols IGP and BGP for
      forwarding the traffic.</t>
    </section>

    <section title="Terminology">
    <section>
      <name>Terminology</name>
      <t>This document uses the following terms defined in <xref target="RFC5440"/>:</t>

      <t><list style="symbols">
          <t>PCE: Path
      <dl>
        <dt>PCE:</dt>
        <dd>Path Computation Element</t>

          <t>PCEP: PCE Protocol</t>

          <t>PCC: Path Element</dd>
        <dt>PCEP:</dt>
        <dd>PCE Protocol</dd>
        <dt>PCC:</dt>
        <dd>Path Computation Client</t>
        </list></t> Client</dd>
      </dl>
      <t>Other terms are used in this document:</t>

      <t><list style="symbols">
          <t>CCDR: Central
      <dl>
        <dt>CCDR:</dt>
        <dd>Centralized Control Dynamic Routing</t>

          <t>E2E: End to End</t>

          <t>ECMP: Equal-Cost Multipath</t>

          <t>RR: Route Reflector</t>

          <t>SDN: Software Defined Network</t>
        </list></t> Routing</dd>
        <dt>E2E:</dt>
        <dd>End to End</dd>
        <dt>ECMP:</dt>
        <dd>Equal-Cost Multipath</dd>
        <dt>RR:</dt>
        <dd>Route Reflector</dd>
        <dt>SDN:</dt>
        <dd>Software-Defined Network</dd>
      </dl>
    </section>

    <section title="CCDR
    <section>
      <name>CCDR Architecture in a Simple Topology">
      <t>Figure 1 Topology</name>
      <t><xref target="fig-ccdr-arch-simple"/> illustrates the CCDR architecture for traffic engineering in
      a simple topology. The topology is composed of four devices devices, which are
      SW1, SW2, R1, and R2. There are multiple physical links between R1 and R2.
      Traffic between prefix PF11(on PF11 (on SW1) and prefix PF21(on PF21 (on SW2) is normal
      traffic,
      traffic; traffic between prefix PF12(on PF12 (on SW1) and prefix PF22(on PF22 (on SW2) is
      priority traffic that should be treated accordingly.</t>

      <figure>
      <figure anchor="fig-ccdr-arch-simple">
        <name>CCDR Architecture in a Simple Topology</name>
        <artwork align="center"><![CDATA[ name="" type="" alt="">
                               +-----+
                    +----------+ PCE +--------+
                    |          +-----+        |
                    |                         |
                    | BGP Session 1(lo11/lo21)|
                    +-------------------------+
                    |                         |
                    | BGP Session 2(lo12/lo22)|
                    +-------------------------+
PF12                |                         |                 PF22
PF11                |                         |                 PF21
+---+         +-----+-----+             +-----+-----+           +---+
|SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+--------------+SW2|
|SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+-----------+SW2|
+---+         |    R1     +-------------+    R2     |           +---+
              +-----------+             +-----------+

           Figure 1: CCDR architecture in simple topology
]]></artwork>
</artwork>
      </figure>

      <t/>
      <t>In the Intra-AS intra-domain scenario, IGP and BGP combined with a PCE are
      deployed between R1 and R2. In the inter-AS inter-domain scenario, only the native
      BGP protocol is deployed. The traffic between each address pair may
      change in real time and the corresponding source/destination addresses
      of the traffic may also change dynamically.</t>
      <t>The key ideas of the CCDR architecture for this simple topology are
      the following:</t>

      <t><list style="symbols">
          <t>Build
      <ul>
        <li>Build two BGP sessions between R1 and R2, R2 via the different
          loopback addresses on these routers (lo11 and lo12 are the loopback
          address
          addresses of R1, and lo21 and lo22 are the loopback address addresses of R2).</t>

          <t>Using R2).</li>
        <li>Using the PCE, set the explicit peer route on R1 and R2 for BGP
          next hop to different physical link addresses between R1 and R2. The
          explicit peer route can be set in the format of a static route,
          which is different from the route learned from the IGP protocol.</t>

          <t>Send IGP.</li>
        <li>Send different prefixes via the established BGP sessions. For
          example, send PF11/PF21 via the BGP session 1 and PF12/PF22 via the
          BGP session 2.</t>
        </list></t> 2.</li>
      </ul>
      <t>After the above actions, the bi-directional bidirectional traffic between the PF11
      and PF21, and the bi-directional bidirectional traffic between PF12 and PF22 PF22, will go
      through different physical links between R1 and R2.</t>
      <t>If there is more traffic between PF12 and PF22 that needs assured
      transport, one can add more physical links between R1 and R2 to reach
      the next hop for BGP session 2. In this case, the prefixes that are
      advertised by the BGP peers need not be changed.</t>
      <t>If, for example, there is bi-directional bidirectional priority traffic from
      another address pair (for example example, prefix PF13/PF23), and the total
      volume of priority traffic does not exceed the capacity of the
      previously provisioned physical links, one need only advertise the newly
      added source/destination prefixes via the BGP session 2. The
      bi-directional
      bidirectional traffic between PF13/PF23 will go through the same
      assigned
      assigned, dedicated physical links as the traffic between PF12/PF22.</t>
      <t>Such a decoupling philosophy of the IGP/BGP traffic link and the
      physical link achieves a flexible control capability for the network
      traffic, satisfying the needed QoS assurance to meet the application's
      requirement. The router needs only to support native IP and multiple BGP
      sessions setup set up via different loopback addresses.</t>

      <t/>
    </section>

    <section title="CCDR
    <section>
      <name>CCDR Architecture in Large Scale Topology"> a Large-Scale Topology</name>
      <t>When the priority traffic spans a large-scale network, such as that
      illustrated in Figure 2, <xref target="fig-ccdr-arch-large"/>, the multiple BGP sessions cannot be established
      hop by hop within one AS. autonomous system. For such a scenario, we propose using a Route
      Reflector (RR) <xref target="RFC4456"/> to achieve a similar effect.
      Every edge router will establish two BGP sessions with the RR via
      different loopback addresses respectively. The other steps for traffic
      differentiation are the same as that described in the CCDR architecture
      for the simple topology.</t>
      <t>As shown in Figure 2, <xref target="fig-ccdr-arch-large"/>, if we select R3 as the RR, every edge router(R1 router (R1
      and R7 in this example) will build two BGP session sessions with the RR. If the
      PCE selects the dedicated path as R1-R2-R4-R7, then the operator should
      set the explicit peer routes via PCEP protocol on these routers
      respectively, pointing to the BGP next hop (loopback addresses of R1 and
      R7, which are used to send the prefix of the priority traffic) to the
      selected forwarding address.</t>
      <figure align="right">
        <artwork><![CDATA[ anchor="fig-ccdr-arch-large">
        <name>CCDR Architecture in a Large-Scale Network</name>
        <artwork name="" type="" alt="">
                              +-----+
             +----------------+ PCE +------------------+
             |                +--+--+                  |
             |                   |                     |
             |                   |                     |
             |                +--+---+                 |
             +----------------+R3(RR)+-----------------+
PF12         |                +--+---+                 |         PF22
PF11         |                                         |         PF21
+---+       ++-+          +--+          +--+         +-++       +---+
|SW1+-------+R1+----------+R5+----------+R6+---------+R7+--------+SW2|
|SW1+-------+R1+----------+R5+----------+R6+---------+R7+-------+SW2|
+---+       ++-+          +--+          +--+         +-++       +---+
             |                                         |
             |                                         |
             |            +--+          +--+           |
             +------------+R2+----------+R4+-----------+
                          +--+          +--+
          Figure 2: CCDR architecture in large-scale network
]]></artwork>
</artwork>
      </figure>
    </section>

    <section title="CCDR
    <section>
      <name>CCDR Multiple BGP Sessions Strategy"> Strategy</name>
      <t>Generally, different applications may require different QoS criteria,
      which may include:</t>

      <t><list style="symbols">
          <t>Traffic
      <ul>
        <li>Traffic that requires low latency and is not sensitive to packet
          loss.</t>

          <t>Traffic
          loss.</li>
        <li>Traffic that requires low packet loss and can endure higher
          latency.</t>

          <t>Traffic
          latency.</li>
        <li>Traffic that requires low jitter.</t>
        </list>These jitter.</li>
      </ul>
      <t>These different traffic requirements can be are summarized in the
      following table:</t>

      <t><figure align="right">
          <artwork><![CDATA[      +----------------+-------------+---------------+-----------------+
      | Prefix Set No. |    Latency  |  Packet Loss  |   Jitter        |
      +----------------+-------------+---------------+-----------------+
      |        1       |    Low      |   Normal      |   Don't care    |
      +----------------+-------------+---------------+-----------------+
      |        2       |   Normal    |   Low         |   Don't care   |
      +----------------+-------------+---------------+-----------------+
      |        3       |   Normal    |   Normal      |   Low           |
      +----------------+-------------+---------------+-----------------+
                 Table 1. Traffic <xref target="tab-traffic-req"/>.</t>
      <table anchor="tab-traffic-req">
        <name>Traffic Requirement Criteria
]]></artwork>
        </figure></t> Criteria</name>
        <thead>
          <tr>
            <th>Prefix Set No.</th>
            <th>Latency</th>
            <th>Packet Loss</th>
            <th>Jitter</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">1</td>
            <td>Low</td>
            <td>Normal</td>
            <td>Don't care</td>
          </tr>
          <tr>
            <td align="center">2</td>
            <td>Normal</td>
            <td>Low</td>
            <td>Don't care</td>
          </tr>
          <tr>
            <td align="center">3</td>
            <td>Normal</td>
            <td>Normal</td>
            <td>Low</td>
          </tr>
        </tbody>
      </table>
      <t>For Prefix Set No.1, we can select the shortest distance path to
      carry the traffic; for Prefix Set No.2, we can select the path that has
      end to end
      E2E under-loaded links; for Prefix Set No.3, we can let traffic
      pass over a determined single path, as no Equal Cost Multipath (ECMP) ECMP
      distribution on the parallel links is desired.</t>
      <t>It is almost impossible to provide an End-to-End (E2E) E2E path
      efficiently with latency, jitter, and packet loss constraints to meet
      the above requirements in a large-scale large-scale, IP-based network only using a
      distributed routing protocol, but these requirements can be met with the
      assistance of PCE, as that described in <xref target="RFC4655"/> and
      <xref target="RFC8283"/>. The PCE will have the overall network view,
      ability to collect the real-time network topology, and the network
      performance information about the underlying network. The PCE can select
      the appropriate path to meet the various network performance
      requirements for different traffic.</t>
      <t>The architecture to implement the CCDR Multiple multiple BGP sessions strategy
      is as follows:</t>
      <t>The PCE will be responsible for the optimal path computation for the
      different priority classes of traffic:</t>

      <t><list style="symbols">
          <t>PCE
      <ul>
        <li>PCE collects topology information via BGP-LS<xref BGP-LS <xref target="RFC7752"> </xref> and link utilization information via the
          existing Network Monitoring System (NMS) from the underlying
          network.</t>

          <t>PCE
          network.</li>
        <li>PCE calculates the appropriate path based upon the application's
          requirements,
          requirements and sends the key parameters to edge/RR routers(R1, R7 routers (R1, R7,
          and R3 in Figure 3) <xref target="fig-ccdr-arch-multi"/>) to establish multiple BGP sessions. The loopback
          addresses used for the BGP sessions should be planned in advance and
          distributed in the domain.</t>

          <t>PCE domain.</li>
        <li>PCE sends the route information to the routers (R1,R2,R4,R7 (R1, R2, R4, and R7 in
          Figure 3)
          <xref target="fig-ccdr-arch-multi"/>) on the forwarding path via PCEP, PCEP to build the path to the
          BGP next-hop next hop of the advertised prefixes. The path to these BGP
          next-hop
          next hops will also be learned via the IGP protocol, IGP, but the route
          from the PCEP has the higher preference. Such a design can assure the
          IGP path to the BGP next-hop next hop can be used to protect the path
          assigned by PCE.</t>

          <t>PCE PCE.</li>
        <li>PCE sends the prefixes prefix information to the PCC(edge PCC (edge routers that
          have established BGP sessions) for advertising different prefixes
          via the specified BGP session.</t>

          <t>The session.</li>
        <li>The priority traffic may share some links or nodes, nodes if the path the
          shared links or nodes can meet the requirement of application. When
          the priority traffic prefixes were changed are changed, but the total volume of
          priority traffic does not exceed the physical capacity of the
          previous E2E path, the PCE needs only change the prefixed prefixes advertised
          via the edge routers (R1,R7 (R1 and R7 in Figure 3).</t>

          <t>If <xref target="fig-ccdr-arch-multi"/>).</li>
        <li>If the volume of priority traffic exceeds the capacity of the
          previous calculated path, the PCE can recalculate and add the
          appropriate paths to accommodate the exceeding traffic. After that,
          the PCE needs to update the on-path routers to build the forwarding
          path hop by hop.</t>
        </list><figure align="right">
          <artwork><![CDATA[ hop.</li>
      </ul>
      <figure anchor="fig-ccdr-arch-multi">
        <name>CCDR Architecture for Multi-BGP Sessions Deployment</name>
        <artwork name="" type="" alt="">
                          +------------+
                          | Application|
                          +------+-----+
                                 |
                        +--------+---------+
             +----------+SDN Controller/PCE+-----------+
             |          +--------^---------+           |
             |                   |                     |
             |                   |                     |
        PCEP |             BGP-LS|PCEP                 | PCEP
             |                   |                     |
             |                +--v---+                 |
             +----------------+R3(RR)+-----------------+
 PF12        |                +------+                 |         PF22
 PF11        |                                         |         PF21
+---+       +v-+          +--+          +--+         +-v+       +---+
|SW1+-------+R1+----------+R5+----------+R6+---------+R7+--------+SW2|
|SW1+-------+R1+----------+R5+----------+R6+---------+R7+-------+SW2|
+---+       ++-+          +--+          +--+         +-++       +---+
             |                                         |
             |                                         |
             |            +--+          +--+           |
             +------------+R2+----------+R4+-----------+
                          +--+          +--+

      Figure 3: CCDR architecture for Multi-BGP sessions deployment]]></artwork>
        </figure></t>
</artwork>
      </figure>
    </section>

    <section title="PCEP
    <section>
      <name>PCEP Extension for Critical Parameters Delivery">
      <t>The PCEP protocol Delivery</name>
      <t>PCEP needs to be extended to transfer the following
      critical parameters:</t>

      <t><list style="symbols">
          <t>Peer
      <ul>
        <li>Peer information that is used to build the BGP session</t>

          <t>Explicit session.</li>
        <li>Explicit route information for BGP next hop of advertised
          prefixes</t>

          <t>Advertised
          prefixes.</li>
        <li>Advertised prefixes and their associated BGP session.</t>
        </list>Once session.</li>
      </ul>
      <t>Once the router receives such information, it should establish
      the BGP session with the peer appointed in the PCEP message, build the
      end-to-end
      E2E dedicated path hop-by-hop, hop by hop, and advertise the prefixes that
      are contained in the corresponding PCEP message.</t>
      <t>The dedicated path is preferred by making sure that the explicit
      route created by PCE has the higher priority (lower route preference)
      than the route information created by other dynamic protocols.</t>
      <t>All of the above dynamically created states (BGP sessions, Explicit route explicit routes,
      and Prefix advertised prefix) prefixes) will be cleared on the expiration of the
      state timeout interval interval, which is based on the existing Stateful stateful PCE <xref target="RFC8231"/> and PCECC PCE as a Central Controller (PCECC) <xref target="RFC8283"/> mechanism.</t>
      <t>Regarding the BGP session, it is not different from that configured
      manually or via NETCONF/YANG. Network Configuration Protocol (NETCONF) and YANG. Different BGP sessions are used mainly for
      the clarification of the network prefixes, which can be differentiated
      via the different BGP nexthop. next hop. Based on this strategy, if we manipulate
      the path to the BGP nexthop, next hop, then the path to the prefixes that were
      advertised with the BGP sessions will be changed accordingly. Details of
      communications between PCEP and BGP subsystems in the router's control
      plane are out of scope of this draft.</t> document.</t>
    </section>

    <section title="Deployment Consideration">
      <section title="Scalability">
    <section>
      <name>Deployment Considerations</name>
      <section>
        <name>Scalability</name>
        <t>In the CCDR architecture, only the edge routers that connect with
        the PCE are responsible for the prefixes prefix advertisement via the
        multiple BGP sessions deployment. The route information for these
        prefixes within the on-path routers is distributed via the BGP
        protocol.</t> BGP.
        </t>
        <t>For multiple domain deployment, the PCE, or the pool of PCEs
        responsible for these domains, needs only to control the edge router
        to build the multiple EBGP External BGP (EBGP) sessions; all other procedures are the same
        as within one domain.</t>
        <t>The on-path router needs only to keep the specific policy routes
        for the BGP next-hop next hop of the differentiated prefixes, not the specific
        routes to the prefixes themselves. This lessens the burden of the
        table size of policy based policy-based routes for the on-path routers; and has
        more expandability compared with BGP flowspec Flowspec or Openflow OpenFlow solutions.
        For example, if we want to differentiate 1000 1,000 prefixes from the normal
        traffic, CCDR needs only one explicit peer route in every on-path
        router, whereas the BGP flowspec Flowspec or Openflow OpenFlow solutions need 1000 1,000
        policy routes on them.</t>
      </section>

      <section title="High Availability">
      <section>
        <name>High Availability</name>
        <t>The CCDR architecture is based on the use of the native IP
        protocol. IP.
        If the PCE fails, the forwarding plane will not be impacted,
        as the BGP sessions between all the devices will not flap flap, and the
        forwarding table remains unchanged.</t>
        <t>If one node on the optimal path fails, the priority traffic will
        fall over to the best-effort forwarding path. One can even design
        several paths to load balance/hot-standby balance or to create a hot standby
        of the priority traffic to meet a path failure situation.</t>
        <t>For ensuring high availability of a PCE/SDN-controllers
        architecture, an operator should rely on existing high availability
        solutions for SDN controllers, such as clustering technology and
        deployment.</t>
      </section>

      <section title="Incremental deployment">
      <section>
        <name>Incremental Deployment</name>
        <t>Not every router within the network needs to support the necessary
        PCEP extension. For such situations, routers on the edge of a domain
        can be upgraded first, and then the traffic can be prioritized between
        different domains. Within each domain, the traffic will be forwarded
        along the best-effort path. A service provider can selectively upgrade
        the routers on each domain in sequence.</t>
      </section>

      <section title="Loop Avoidance">
      <section>
        <name>Loop Avoidance</name>
        <t>A PCE needs to assure calculation of the E2E path based on the
        status of network and the service requirements in real-time.</t>
        <t>The PCE needs to consider the explicit route deployment order (for
        example, from tail router to head router) to eliminate any possible
        transient traffic loop.</t>
      </section>

      <section title="E2E
      <section>
        <name>E2E Path Performance Monitoring"> Monitoring</name>
        <t>It is necessary to deploy the corresponding E2E path performance
        monitoring mechanism to keep assure that the delay, jitter jitter, or packet
        loss index meet meets the original path performance aim. The performance
        monitoring results should provide feedback to the PCE to let in order for it to accomplish the
        re-optimize process,
        re-optimization process and send the update control message to the related PCC if
        necessary. Traditional OAM methods(ping, methods (ping, trace) can be used.</t>
      </section>
    </section>

    <section title="Security Considerations">
    <section>
      <name>Security Considerations</name>
      <t>The setup of BGP sessions, prefix advertisement, and explicit peer
      route establishment are all controlled by the PCE. See <xref target="RFC4271"/> and <xref target="RFC4272"/> for BGP security
      considerations. The Security consideration part Considerations found in <xref target="RFC5440"/> target="RFC5440" section="10"/>
      and <xref target="RFC8231"/> target="RFC8231" section="10"/> should be considered. To prevent a bogus
      PCE sending harmful messages to the network nodes, the network devices
      should authenticate the validity of the PCE and ensure a secure
      communication channel between them. Mechanisms described in <xref target="RFC8253"/> should be used.</t>
      <t>The CCDR architecture does not require changes to the forwarding
      behavior of the underlay devices. There are no additional security
      impacts on these devices.</t>
    </section>

    <section title="IANA Considerations">
    <section>
      <name>IANA Considerations</name>
      <t>This document does not require any has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4456.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8283.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8735.xml"/>
      </references>
    </references>
    <section title="Acknowledgement"> numbered="false">
      <name>Acknowledgments</name>
      <t>The author would like to thank Deborah Brungard, Adrian Farrel,
      Vishnu Beeram, Lou Berger, Dhruv Dhody, Raghavendra Mallya , Mike
      Koldychev, Haomian Zheng, Penghui Mi, Shaofu Peng, Donald Eastlake,
      Alvaro Retana, Martin Duke, Magnus Westerlund, Benjamin Kaduk, Roman
      Danyliw, Eric Vyncke, Murray Kucherawy, Erik Kline and Jessica Chen <contact fullname="Deborah Brungard"/>, <contact fullname="Adrian Farrel"/>,
      <contact fullname="Vishnu Beeram"/>, <contact fullname="Lou Berger"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Raghavendra Mallya"/>, <contact fullname="Mike       Koldychev"/>, <contact fullname="Haomian Zheng"/>, <contact fullname="Penghui Mi"/>, <contact fullname="Shaofu Peng"/>, <contact fullname="Donald Eastlake"/>,
      <contact fullname="Alvaro Retana"/>, <contact fullname="Martin Duke"/>, <contact fullname="Magnus Westerlund"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Roman       Danyliw"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Erik Kline"/>, and <contact fullname="Jessica Chen"/> for
      their supports and comments on this draft.</t> document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.4271"?>

      <?rfc include="reference.RFC.4272"?>

      <?rfc include="reference.RFC.4456"?>

      <?rfc include="reference.RFC.5440"?>

      <?rfc include="reference.RFC.7752"?>

      <?rfc include="reference.RFC.8231"?>

      <?rfc include="reference.RFC.8253"?>

      <?rfc include="reference.RFC.8283"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4655"?>

      <?rfc include="reference.RFC.8735"?>
    </references>
  </back>
</rfc>