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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3209 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC7551 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7551.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.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 RFC8537 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8537.xml">
<!ENTITY RFC8697 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8697.xml">
<!ENTITY RFC5654 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5654.xml">
<!ENTITY RFC7420 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7420.xml">
<!ENTITY RFC7942 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml">
<!ENTITY RFC8051 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml">
<!ENTITY RFC8408 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8408.xml">
<!ENTITY I-D.ietf-pce-pcep-yang SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-yang.xml">
<!ENTITY I-D.ietf-pce-pcep-stateful-pce-gmpls SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-stateful-pce-gmpls.xml">
<!ENTITY I-D.ietf-pce-sr-bidir-path SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-sr-bidir-path.xml">
]> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-pce-association-bidir-14" number="9059" ipr="trust200902" submissionType="IETF"> submissionType="IETF" category="std" consensus="true" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <!-- Generated by id2xml 1.5.0 on 2020-02-01T01:23:15Z -->

  <?rfc compact="yes"?>

  <?rfc text-list-symbols="oo*+-"?>

  <?rfc subcompact="no"?>

  <?rfc sortrefs="yes"?>

  <?rfc symrefs="yes"?>

  <?rfc strict="yes"?>

  <?rfc toc="yes"?>

  <front>
    <title abbrev="PCEP for Associated Bidirectional LSP"> Path LSPs">Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)</title>
    <seriesInfo name="RFC" value="9059"/>
    <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Canada</street>
        </postal>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author fullname="Colby Barth" initials="C." surname="Barth">
      <organization>Juniper Networks</organization>
      <address>
        <email>cbarth@juniper.net</email>
      </address>
    </author>
    <author fullname="Bin Wen" initials="B." surname="Wen">
      <organization>Comcast</organization>
      <address>
        <email>Bin_Wen@cable.comcast.com</email>
      </address>
    </author>
    <date day="21" month="February" month="June" year="2021"/>
    <workgroup>PCE Working Group</workgroup>

    <abstract>
      <t/>

      <t>This document defines PCEP Path Computation Element Communication Protocol
      (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched
      Paths (LSPs), one in each direction in the network, into an
      Associated Bidirectional associated
      bidirectional LSP.  These PCEP extensions can be applied either using a Stateful
      stateful PCE for both PCE-Initiated PCE-initiated and PCC-Initiated LSPs, as well as when PCC-initiated LSPs or using
      a Stateless stateless PCE. The PCEP procedures defined are applicable
      to the LSPs using RSVP-TE for signaling.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC5440"/> target="RFC5440" format="default"/> describes the Path Computation Element
      Communication Protocol (PCEP) as a communication mechanism between a Path Computation
      Client (PCC) and a Path Computation Element (PCE), or between PCE and PCC,
      that enables computation of Multiprotocol Label Switching (MPLS) - Traffic
      Engineering (TE) Label Switched Paths (LSPs).</t>
      <t><xref target="RFC8231"/> target="RFC8231" format="default"/> specifies extensions to PCEP to enable
      stateful control of MPLS-TE LSPs. It describes two modes of operation -
      Passive Stateful operation:
      passive stateful PCE and Active Stateful active stateful PCE. In <xref
      target="RFC8231"/>, target="RFC8231" format="default"/>, the focus is on Active Stateful active stateful PCE where LSPs are
      provisioned on the PCC and control over them is delegated to a PCE.
      Further, <xref target="RFC8281"/> target="RFC8281" format="default"/> describes the setup, maintenance maintenance, and
      teardown of PCE-Initiated PCE-initiated LSPs for the Stateful stateful PCE model.</t>
      <t><xref target="RFC8697"/> target="RFC8697" format="default"/> introduces a generic mechanism to create for creating a grouping of LSPs.
      This grouping can then be used to define associations between
      sets of LSPs or between a set of LSPs and a set of attributes,
      and it is equally applicable to the stateful PCE (active and
      passive modes) and the stateless PCE.</t>
      <t>The MPLS Transport Profile (MPLS-TP) requirements document <xref
      target="RFC5654"/> target="RFC5654" format="default"/> specifies that
      "MPLS-TP MUST <bcp14>MUST</bcp14> support unidirectional, co-routed bidirectional, and
       associated bidirectional point-to-point transport paths".
      <xref target="RFC7551"/> target="RFC7551" format="default"/> defines RSVP
      signaling extensions for binding forward and reverse unidirectional LSPs
      into an associated bidirectional LSP. The fast
      reroute (FRR) procedures for associated bidirectional LSPs are described
      in <xref target="RFC8537"/>.</t> target="RFC8537" format="default"/>.</t>
      <t>This document defines PCEP extensions for grouping two unidirectional
      MPLS-TE LSPs into an Associated Bidirectional associated bidirectional LSP for both single-sided
      and double-sided initiation cases either when using a Stateful stateful PCE for both
      PCE-Initiated
      PCE-initiated and PCC-Initiated PCC-initiated LSPs as well as or when using a Stateless stateless
      PCE. The procedures defined are applicable to the LSPs using Resource
      Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling <xref target="RFC3209"/>. target="RFC3209" format="default"/>.
      Specifically, this document defines two new Association Types, "Single-sided Single-Sided
      Bidirectional LSP Association" Association and "Double-sided Double-Sided Bidirectional
      LSP Association", Association, as well as "Bidirectional the Bidirectional LSP Association Group TLV" TLV, to carry
      additional information for the association.</t>
      <t>The procedure for associating two unidirectional Segment Routing (SR) Paths paths
      to form an Associated Bidirectional associated bidirectional SR Path path is defined in
      <xref target="I-D.ietf-pce-sr-bidir-path"/>, target="I-D.ietf-pce-sr-bidir-path" format="default"/> and is outside the scope of
      this document.</t>
    </section>
    <section anchor="sect-2" title="Conventions numbered="true" toc="default">
      <name>Conventions Used in This Document"> Document</name>
      <section anchor="sect-2.1" title="Key numbered="true" toc="default">
        <name>Key Word Definitions">
        <t>The Definitions</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      </section>
      <section anchor="sect-2.2" title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>The reader is assumed to be familiar with the terminology defined
        in <xref target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC7551"/>, target="RFC7551" format="default"/>, <xref
        target="RFC8231"/>, target="RFC8231" format="default"/>, and <xref target="RFC8697"/>.</t> target="RFC8697" format="default"/>.</t>
      </section>
    </section>
    <section anchor="sect-3" title="Overview"> numbered="true" toc="default">
      <name>Overview</name>
      <t>As shown in Figure 1, <xref target="ure-example-of-associated-bidirectional-lsp" />, forward and reverse unidirectional LSPs can be grouped
      to form an associated bidirectional LSP. The node Node A is the ingress node for LSP1 and
      egress node for LSP2, whereas node D is the ingress node
      for LSP2 and egress node for LSP1. There are two methods of
      initiating the bidirectional Bidirectional LSP association, Association, single-sided and
      double-sided, as defined in <xref target="RFC7551"/> target="RFC7551" format="default"/> and described in
      the following sections.</t>
      <figure anchor="ure-example-of-associated-bidirectional-lsp"
              title="Example anchor="ure-example-of-associated-bidirectional-lsp">
        <name>Example of Associated Bidirectional LSP">
        <artwork> LSP</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
            LSP1 --&gt; -->          LSP1 --&gt; -->          LSP1 --&gt; -->
   +-----+           +-----+           +-----+           +-----+
   |  A  +-----------+  B  +-----------+  C  +-----------+  D  |
   +-----+           +--+--+           +--+--+           +-----+
            &lt;--
            <-- LSP2    |                 |     &lt;--     <-- LSP2
                        |                 |
                        |                 |
                     +--+--+           +--+--+
                     |  E  +-----------+  F  |
                     +-----+           +-----+
                             &lt;--
                             <-- LSP2
</artwork>
]]></artwork>
      </figure>
      <section anchor="sect-3.1" title="Single-sided Initiation"> numbered="true" toc="default">
        <name>Single-Sided Initiation</name>
        <t>As specified in <xref target="RFC7551"/>, target="RFC7551" format="default"/>, in the single-sided case,
        the bidirectional tunnel is provisioned only on one endpoint node
        (PCC) of the tunnel. Both endpoint nodes act as PCCs.
        Both forward and reverse LSPs of this tunnel are
        initiated with the Association Type set to "Single-sided "Single-Sided Bidirectional
        LSP Association" on the originating endpoint node. The forward and
        reverse LSPs are identified in the "Bidirectional Bidirectional LSP Association Group
        TLV"
        TLV of their PCEP ASSOCIATION Objects.</t> objects.</t>
        <t>The originating endpoint node signals the properties for the reverse
        LSP in the RSVP REVERSE_LSP Object object <xref target="RFC7551"/> target="RFC7551" format="default"/> of the
        forward LSP Path message. The remote endpoint node then creates the
        corresponding reverse tunnel and reverse LSP, and it then signals the reverse LSP in response
        to the received RSVP-TE Path message. Similarly, the remote endpoint node
        deletes the reverse LSP when it receives the RSVP-TE message to delete the forward LSP
        <xref target="RFC3209"/>.</t> target="RFC3209" format="default"/>.</t>

        <t>As specified in <xref target="RFC8537"/>, target="RFC8537" format="default"/>, for fast reroute bypass
        tunnel assignment, the LSP starting from the originating endpoint node is
        identified as the forward LSP of the single-sided initiated
        bidirectional LSP.</t>
        <section anchor="sect-3.1.1" title="PCE-Initiated Single-sided numbered="true" toc="default">
          <name>PCE-Initiated Single-Sided Bidirectional LSP"> LSP</name>
          <figure anchor="ure-example-of-pce-initiated-single-sided-bidirectional-lsp"
                title="Example anchor="ure-example-of-pce-initiated-single-sided-bidirectional-lsp">
            <name>Example of PCE-Initiated Single-sided Single-Sided Bidirectional LSP">
          <artwork> LSP</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                                +-----+
                                | PCE |
                                +-----+
    Initiates:                   |    \
    Tunnel 1 (F)                 |     \
    (LSP1 (F, 0), LSP2 (R, 0))   |      \
    Association #1               v       \
                              +-----+    +-----+
                              |  A  |    |  D  |
                              +-----+    +-----+

                                +-----+
                                | PCE |
                                +-----+
    Reports:                     ^    ^      Reports:
    Tunnel 1 (F)                 |     \     Tunnel 2 (F)
    (LSP1 (F, P1), LSP2 (R, P2)) |      \    (LSP2 (F, P3))
    Association #1               |       \   Association #1
                              +-----+    +-----+
                              |  A  |    |  D  |
                              +-----+    +-----+

  Legends: F=Forward

  Legend: F = Forward LSP, R=Reverse R = Reverse LSP, (0,P1,P2,P3)=PLSP-IDs
</artwork> (0,P1,P2,P3) = PLSP-IDs
]]></artwork>
          </figure>
          <t>Using partial topology from Figure 1, <xref target="ure-example-of-associated-bidirectional-lsp"/>, as shown in Figure 2, <xref target="ure-example-of-pce-initiated-single-sided-bidirectional-lsp"/>, the forward tunnel Tunnel 1 and both forward LSP1 and reverse LSP2 are initiated on the originating endpoint node
       A by the PCE.  The PLSP-IDs PCEP-specific LSP identifiers (PLSP-IDs) used are P1 and P2 on the originating endpoint node A
       and P3 on the remote endpoint node D.
       The originating endpoint node A reports tunnels Tunnel 1 and forward LSP1 and reverse LSP2
       to the PCE. The endpoint (PCC) node D reports
       tunnel Tunnel 2 and LSP2 to the PCE.
          </t>
        </section>
        <section anchor="sect-3.1.2" title="PCC-Initiated Single-sided numbered="true" toc="default">
          <name>PCC-Initiated Single-Sided Bidirectional LSP"> LSP</name>
          <figure anchor="ure-example-of-pcc-initiated-single-sided-bidirectional-lsp"
                title="Example anchor="ure-example-of-pcc-initiated-single-sided-bidirectional-lsp">
            <name>Example of PCC-Initiated Single-sided Single-Sided Bidirectional LSP">
          <artwork> LSP</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                                +-----+
                                | PCE |
                                +-----+
    Reports/Delegates:           ^    ^      Reports:
    Tunnel 1 (F)                 |     \     Tunnel 2 (F)
    (LSP1 (F, P1), LSP2 (R, P2)) |      \    (LSP2 (F, P3))
    Association #2               |       \   Association #2
                              +-----+    +-----+
                              |  A  |    |  D  |
                              +-----+    +-----+

  Legends: F=Forward

  Legend: F = Forward LSP, R=Reverse R = Reverse LSP, (P1,P2,P3)=PLSP-IDs
</artwork> (P1,P2,P3) = PLSP-IDs
]]></artwork>
          </figure>
          <t>Using partial topology from Figure 1, <xref target="ure-example-of-associated-bidirectional-lsp"/>, as shown in Figure 3, <xref target="ure-example-of-pcc-initiated-single-sided-bidirectional-lsp"/>, the forward tunnel Tunnel 1 and both forward LSP1 and reverse LSP2 are initiated on the originating endpoint node
       A (the originating PCC).
       The PLSP-IDs used are P1 and P2 on the originating endpoint node A
       and P3 on the remote endpoint node D.
       The originating endpoint (PCC) node A may delegate the
       forward LSP1 and reverse LSP2 to the PCE.
       The originating endpoint node A reports tunnels Tunnel 1 and forward LSP1 and reverse LSP2
       to the PCE. The endpoint (PCC) node D reports
       tunnel
       Tunnel 2 and LSP2 to the PCE.
          </t>
        </section>
      </section>
      <section anchor="sect-3.2" title="Double-sided Initiation"> numbered="true" toc="default">
        <name>Double-Sided Initiation</name>
        <t>As specified in <xref target="RFC7551"/>, target="RFC7551" format="default"/>, in the double-sided case,
        the bidirectional tunnel is provisioned on both endpoint nodes (PCCs)
        of the tunnel. The forward and reverse LSPs of this tunnel are
        initiated with the Association Type set to "Double-sided "Double-Sided Bidirectional
        LSP Association" on both endpoint nodes. The forward and reverse LSPs
        are identified in the "Bidirectional Bidirectional LSP Association Group TLV" TLV of their
        ASSOCIATION Objects.</t> objects.</t>
        <t>As specified in <xref target="RFC8537"/>, target="RFC8537" format="default"/>, for fast reroute bypass
        tunnel assignment, the LSP with the higher Source Address source address <xref
        target="RFC3209"/> target="RFC3209" format="default"/> is identified as the forward LSP of the
        double-sided initiated bidirectional LSP.</t>
        <section anchor="sect-3.2.1" title="PCE-Initiated Double-sided numbered="true" toc="default">
          <name>PCE-Initiated Double-Sided Bidirectional LSP"> LSP</name>
          <figure anchor="ure-example-of-pce-initiated-double-sided-bidirectional-lsp"
                title="Example anchor="ure-example-of-pce-initiated-double-sided-bidirectional-lsp">
            <name>Example of PCE-Initiated Double-sided Double-Sided Bidirectional LSP">
          <artwork> LSP</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                            +-----+
                            | PCE |
                            +-----+
          Initiates:         |    \      Initiates:
          Tunnel 1 (F)       |     \     Tunnel 2 (F)
          (LSP1 (F, 0))      |      \    (LSP2 (F, 0))
          Association #3     v       v   Association #3
                          +-----+    +-----+
                          |  A  |    |  D  |
                          +-----+    +-----+

                            +-----+
                            | PCE |
                            +-----+
          Reports:           ^    ^      Reports:
          Tunnel 1 (F)       |     \     Tunnel 2 (F)
          (LSP1 (F, P4))     |      \    (LSP2 (F, P5))
          Association #3     |       \   Association #3
                          +-----+    +-----+
                          |  A  |    |  D  |
                          +-----+    +-----+

  Legends: F=Forward

  Legend: F = Forward LSP, (0,P4,P5)=PLSP-IDs
</artwork> (0,P4,P5) = PLSP-IDs
]]></artwork>
          </figure>
          <t>Using partial topology from Figure 1, <xref target="ure-example-of-associated-bidirectional-lsp"/>, as shown in Figure 4, <xref target="ure-example-of-pce-initiated-double-sided-bidirectional-lsp"/>, the forward tunnel Tunnel 1 and forward LSP1
        are initiated on the endpoint node A A, and the reverse tunnel Tunnel 2 and
        reverse LSP2 are initiated on the endpoint node D by the PCE.
        The PLSP-IDs used are P4 on the endpoint node A
        and P5 on the endpoint node D.
        The endpoint node A (PCC) reports the forward LSP1 LSP1, and endpoint node D reports the forward LSP2 to the PCE.
          </t>
        </section>
        <section anchor="sect-3.2.2" title="PCC-Initiated Double-sided numbered="true" toc="default">
          <name>PCC-Initiated Double-Sided Bidirectional LSP"> LSP</name>
          <figure anchor="ure-example-of-pcc-initiated-double-sided-bidirectional-lsp"
                title="Example anchor="ure-example-of-pcc-initiated-double-sided-bidirectional-lsp">
            <name>Example of PCC-Initiated Double-sided Double-Sided Bidirectional LSP">
          <artwork> LSP</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                            +-----+
                            | PCE |
                            +-----+
        Reports/Delegates:   ^    ^      Reports/Delegates:
        Tunnel 1 (F)         |     \     Tunnel 2 (F)
        (LSP1 (F, P4))       |      \    (LSP2 (F, P5))
        Association #4       |       \   Association #4
                          +-----+    +-----+
                          |  A  |    |  D  |
                          +-----+    +-----+

  Legends: F=Forward

  Legend: F = Forward LSP, (P4,P5)=PLSP-IDs
</artwork> (P4,P5) = PLSP-IDs
]]></artwork>
          </figure>
          <t>Using partial topology from Figure 1, <xref target="ure-example-of-associated-bidirectional-lsp"/>, as shown in Figure 5, <xref target="ure-example-of-pcc-initiated-double-sided-bidirectional-lsp"/>, the forward tunnel Tunnel 1 and forward LSP1
        are initiated on the endpoint node A A, and the reverse tunnel Tunnel 2 and
        reverse LSP2 are initiated on the endpoint node D (the PCCs).
        The PLSP-IDs used are P4 on the endpoint node A and P5 on the endpoint node D.
        Both endpoint (PCC) nodes may delegate the forward LSP1 and LSP2 to the PCE.
        The endpoint node A (PCC) reports the forward LSP1 LSP1, and endpoint node D reports the forward LSP2 to the PCE.
          </t>
        </section>
      </section>
      <section anchor="sect-3.3"
               title="Co-routed numbered="true" toc="default">
        <name>Co-routed Associated Bidirectional LSP"> LSP</name>
        <t>In both single-sided and double-sided initiation cases, forward and
        reverse LSPs can be co-routed as shown in Figure 6, <xref target="ure-example-of-co-routed-associated-bidirectional-lsp"/>, where both forward
        and reverse LSPs of a bidirectional LSP follow the same congruent path
        in the forward and reverse directions, respectively.</t>
        <figure anchor="ure-example-of-co-routed-associated-bidirectional-lsp"
                title="Example anchor="ure-example-of-co-routed-associated-bidirectional-lsp">
          <name>Example of Co-routed Associated Bidirectional LSP">
          <artwork> LSP</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
            LSP3 --&gt; -->          LSP3 --&gt; -->          LSP3 --&gt; -->
   +-----+           +-----+           +-----+           +-----+
   |  A  +-----------+  B  +-----------+  C  +-----------+  D  |
   +-----+           +-----+           +-----+           +-----+
           &lt;--
           <-- LSP4          &lt;--          <-- LSP4          &lt;--          <-- LSP4
</artwork>
]]></artwork>
        </figure>
        <t>The procedure specified in [RFC8537] <xref target="RFC8537"/> for fast reroute bypass tunnel
    assignment is also applicable to the Co-routed Associated Bidirectional co-routed associated bidirectional LSPs.</t>
      </section>
      <section anchor="sect-3.4" title="Summary numbered="true" toc="default">
        <name>Summary of PCEP Extensions"><t> Extensions</name>
        <t>
      The PCEP extensions defined in this document cover the following modes of
      operations
      operation under the stateful PCE model:</t>

      <t><list style="symbols">
          <t>A
        <ul spacing="normal">
          <li>A PCC initiates the forward and reverse LSP of a Single-sided
          Bidirectional single-sided
          bidirectional LSP and retains the control of the
          LSPs. Similarly, both PCCs initiate the forward LSPs of a
          Double-sided Bidirectional
          double-sided bidirectional LSP and retain the control of the
          LSPs. The PCC computes the path itself or makes a request for path
          computation to a PCE. After the path setup, it reports the
          information and state of the path to the PCE. This includes the
          association group identifying the bidirectional LSP. This is the
          Passive Stateful
          passive stateful mode defined in <xref target="RFC8051"/>.</t>

          <t>A target="RFC8051" format="default"/>.</li>
          <li>A PCC initiates the forward and reverse LSP of a Single-sided
          Bidirectional single-sided
          bidirectional LSP and delegates the control of the
          LSPs to a Stateful stateful PCE. Similarly, both PCCs initiate the forward LSPs of a
          Double-sided Bidirectional
          double-sided bidirectional LSP and delegate the control of the
          LSPs to a Stateful stateful PCE. During delegation delegation, the association group
          identifying the bidirectional LSP is included. The PCE computes the
          path of the LSP and updates the PCC with the information about the
          path as long as it controls the LSP. This is the Active Stateful active stateful
          mode defined in <xref target="RFC8051"/>.</t>

          <t>A target="RFC8051" format="default"/>.</li>
          <li>A PCE initiates the forward and reverse LSP of a Single-sided
          Bidirectional single-sided
          bidirectional LSP on a PCC and retains the control
          of the LSP. Similarly, a PCE initiates the forward LSPs of a
          Double-sided Bidirectional
          double-sided bidirectional LSP on both PCCs and retains the control
          of the LSPs. The PCE is responsible for computing the path of the LSP
          and updating the PCC with the information about the path as well as
          the association group identifying the bidirectional LSP. This is the
          PCE-Initiated
          PCE-initiated mode defined in <xref target="RFC8281"/>.</t>

          <t>A target="RFC8281" format="default"/>.</li>
          <li>A PCC requests co-routed or non-co-routed paths for forward and
          reverse LSPs of a bidirectional LSP LSP, including when using a Stateless stateless PCE <xref
          target="RFC5440"/>.</t>
    </list></t> target="RFC5440" format="default"/>.</li>
        </ul>
      </section>
      <section anchor="sect-3.5" title="Operational Considerations"><t> numbered="true" toc="default">
        <name>Operational Considerations</name>
        <t>
      The double-sided case has an advantage when compared to the single-sided
      case
      case, summarized as following:</t>

      <t><list style="symbols">
      <t>In follows:</t>
        <ul spacing="normal">
          <li>In the double-sided case, two existing unidirectional LSPs in reverse
      directions in the network can be associated to form a bidirectional LSP without
      significantly increasing the operational complexity.</t>
      </list></t> complexity.</li>
        </ul>
        <t>The single-sided case has some advantages when compared to the double-sided case case, summarized as following:</t>

      <t><list style="symbols">
       <t>Some follows:</t>
        <ul spacing="normal">
          <li>Some Operations, Administration, and Maintenance (OAM) use-cases use cases
       may require an endpoint node to know both forward and
       reverse direction paths for monitoring the bidirectional LSP. For such use-cases, use cases, the
       single-sided case may be preferred.</t>

       <t>For Co-routed Associated Bidirectional preferred.</li>
          <li>For co-routed associated bidirectional LSPs in PCC initiated PCC-initiated mode,
       the single-sided case allows the originating PCC to dynamically compute
       co-routed forward and reverse paths. This may not be possible with the double-sided
       case where the forward and reverse direction paths are computed
       separately as triggered by two different PCCs.</t>

       <t>The Associated Bidirectional PCCs.</li>
          <li>The associated bidirectional LSPs with in the single-sided case can be deployed
       in a network where PCEP is only enabled on the originating endpoint nodes as
       remote endpoint nodes create the reverse tunnels using RSVP-TE Path messages.</t>
      </list></t> messages.</li>
        </ul>
      </section>
    </section>
    <section anchor="sect-4" title="Protocol Extensions"> numbered="true" toc="default">
      <name>Protocol Extensions</name>
      <section anchor="sect-4.1" title="ASSOCIATION Object"> numbered="true" toc="default">
        <name>ASSOCIATION Object</name>
        <t>As per <xref target="RFC8697"/>, target="RFC8697" format="default"/>, LSPs are associated by adding them
        to a common association group. This document defines two new Association Types, called
        "Single-sided
        "Single-Sided Bidirectional LSP" (TBD1) LSP Association" (4) and "Double-sided "Double-Sided
        Bidirectional LSP" (TBD2), LSP Association" (5), using the generic ASSOCIATION
        Object ((Object-Class
        object (Object-Class value 40).
        A member of the Bidirectional LSP Association
        can take the role of a forward or reverse LSP and follows the following rules:</t>

        <t><list style="symbols">
         <t>An
        <ul spacing="normal">
          <li>An LSP (forward or reverse) MUST NOT <bcp14>MUST NOT</bcp14> be part of more than one
         Bidirectional LSP Association.</t>

         <t>The Association.</li>
          <li>The LSPs in a Bidirectional LSP Association MUST <bcp14>MUST</bcp14> have matching endpoint
         nodes in the reverse directions.</t>

         <t>The Tunnel directions.</li>
          <li>The same tunnel (as defined in Section 2.1 of <xref target="RFC3209"/>) containing target="RFC3209"
          sectionFormat="of" section="2.1"/>) <bcp14>MUST</bcp14> contain the
          forward and reverse LSPs of the Single-sided Single-Sided Bidirectional LSP
          Association on the originating node MUST be the same, node, albeit both LSPs have reversed
          endpoint nodes.</t>
        </list></t> nodes.</li>
        </ul>
        <t>The Bidirectional LSP Association types Types are considered to be both dynamic and
        operator-configured
        operator configured in nature.  As per [RFC8697], <xref target="RFC8697"/>, the association group could
        be manually created by the operator on the PCEP peers, and the LSPs
        belonging to this association are conveyed via PCEP messages to the
        PCEP peer; alternately, the association group could be created
        dynamically by the PCEP speaker, and both the association group
        information and the LSPs belonging to the association group are
        conveyed to the PCEP peer.  The Operator-configured operator-configured Association Range
        MUST
        <bcp14>MUST</bcp14> be set for this association-type Association Type to mark a range of Association
        Identifiers that are used for operator-configured associations to
        avoid any Association Identifier clash within the scope of the
        Association Source (Refer (refer to <xref target="RFC8697"/>).</t> target="RFC8697" format="default"/>).</t>
        <t>Specifically, for the PCE Initiated Bidirectional PCE-initiated bidirectional LSPs, these Associations associations
        are dynamically created by the PCE on the PCE peers. Similarly,
        for both PCE Initiated the PCE-initiated and PCC Initiated the PCC-initiated single-sided case, cases,
        these associations are also dynamically created on the
        remote endpoint node using the information
        received from the RSVP message from the originating node.</t>
        <t>The Association ID, Association Source, optional Global Association
        Source TLV TLV, and optional Extended Association ID TLV in the Bidirectional LSP
        Association Object
        ASSOCIATION object are initialized using the procedures defined
        in <xref target="RFC8697"/> target="RFC8697" format="default"/> and <xref target="RFC7551"/>.</t> target="RFC7551" format="default"/>.</t>
        <t><xref target="RFC8697"/> target="RFC8697" format="default"/> specifies the mechanism for the capability advertisement of
        the Association Types supported by a PCEP speaker by defining an
        ASSOC-Type-List TLV to be carried within an OPEN Object. object.  This
        capability exchange for the Bidirectional LSP Association Types MUST <bcp14>MUST</bcp14> be
        done before using the Bidirectional LSP Association.  Thus, the PCEP
        speaker MUST <bcp14>MUST</bcp14> include the Bidirectional LSP Association Types in the
        ASSOC-Type-List TLV and MUST <bcp14>MUST</bcp14> receive the same from the PCEP peer
        before using the Bidirectional LSP Association in PCEP messages.</t>
      </section>
      <section anchor="sect-4.2"
               title="Bidirectional numbered="true" toc="default">
        <name>Bidirectional LSP Association Group TLV"> TLV</name>
        <t>The "Bidirectional Bidirectional LSP Association Group TLV" TLV is an OPTIONAL <bcp14>OPTIONAL</bcp14> TLV for use with the
        Bidirectional LSP Associations (ASSOCIATION Object object with Association
        Type TBD1 4 for Single-sided Single-Sided Bidirectional LSP Association or TBD2 5 for Double-sided Double-Sided Bidirectional LSP Association).</t>
        <ul spacing="normal">
          <li>The Bidirectional LSP).</t>

        <t><list style="symbols">
            <t>The "Bidirectional LSP Association Group TLV" TLV follows the PCEP
            TLV format from <xref target="RFC5440"/>.</t>

            <t>The target="RFC5440" format="default"/>.</li>
          <li>The Type (16 bits) of the TLV is TBD3, to be assigned by
            IANA.</t>

            <t>The 54.</li>
          <li>The Length is 4 Bytes.</t>

            <t>The bytes.</li>
          <li>The value comprises of a single field, the Bidirectional LSP
            Association Flag
            Flags field (32 bits), where each bit represents a flag
            option.</t>

            <t>If
            option.</li>
          <li>If the "Bidirectional Bidirectional LSP Association Group TLV" TLV is missing, it
            means the LSP is the forward LSP LSP, and it is not a co-routed LSP.</t>

            <t>When "Bidirectional LSP.</li>
          <li>When the Bidirectional LSP Association Group TLV" TLV is present, the R
            flag MUST <bcp14>MUST</bcp14> be reset for the forward LSP for both co-routed and non co-routed LSPs.</t>

            <t>For non-co-routed LSPs.</li>
          <li>For co-routed LSPs, this TLV MUST <bcp14>MUST</bcp14> be present and the C flag set.</t>

            <t>For set.</li>
          <li>For reverse LSPs, this TLV MUST <bcp14>MUST</bcp14> be present and the R flag set.</t>

            <t>The "Bidirectional set.</li>
          <li>The Bidirectional LSP Association Group TLV" MUST NOT TLV <bcp14>MUST NOT</bcp14> be present
            more than once. If it appears more than once, only the first
            occurrence is processed processed, and any others MUST <bcp14>MUST</bcp14> be ignored.</t>
          </list></t> ignored.</li>
        </ul>

        <t>The format of the "Bidirectional Bidirectional LSP Association Group TLV" TLV is shown
        in Figure 7:</t> <xref target="ure-bidirectional-lsp-association-group-tlv-format"/>.</t>

        <figure anchor="ure-bidirectional-lsp-association-group-tlv-format"
                title="Bidirectional anchor="ure-bidirectional-lsp-association-group-tlv-format">
          <name>Bidirectional LSP Association Group TLV format">
          <artwork> Format</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type = TBD3 54             |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Flags                               |C|R|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
]]></artwork>
        </figure>
        <t>Flags for "Bidirectional the Bidirectional LSP Association Group TLV" TLV are defined as following.</t>

        <t>R follows.</t>
<dl>
<dt>R (Reverse LSP, 1 bit, Bit bit number 31) - Indicates 31):</dt><dd>Indicates whether the LSP associated is
        the reverse LSP of the bidirectional LSP. If this flag is set, the LSP
        is a reverse LSP. If this flag is not set, the LSP is a forward LSP.</t>

        <t>C LSP.</dd>

<dt>C (Co-routed Path, 1 bit, Bit bit number 30) - Indicates 30):</dt><dd>Indicates whether the bidirectional LSP
        is co-routed. This flag MUST <bcp14>MUST</bcp14> be set for both the forward and reverse
        LSPs of a co-routed bidirectional LSP.</t> LSP.</dd>
</dl>
        <t>The C flag is used by the PCE (for both Stateful (both stateful and Stateless) stateless) to
        compute bidirectional paths of the forward and reverse LSPs of a
        co-routed bidirectional LSP.</t>
        <t>The unassigned flags (Bit Number (bit numbers 0-29) MUST <bcp14>MUST</bcp14> be set to 0 when sent and MUST <bcp14>MUST</bcp14> be ignored
        when received.</t>
      </section>
    </section>
    <section anchor="sect-5" title="PCEP Procedure"> numbered="true" toc="default">
      <name>PCEP Procedure</name>
      <t>The PCEP procedure defined in this document is applicable to the following three scenarios:</t>

        <t><list style="symbols">
          <t>Neither
      <ul spacing="normal">
        <li>Neither unidirectional LSP exists, and both must be established.</t>
          <t>Both established.</li>
        <li>Both unidirectional LSPs exist, but the association must be established.</t>
          <t>One established.</li>
        <li>One LSP exists, but the reverse associated LSP must be established.</t>
          </list></t> established.</li>
      </ul>
      <section anchor="sect-5.1" title="PCE Initiated LSPs"> numbered="true" toc="default">
        <name>PCE-Initiated LSPs</name>
        <t>As specified in <xref target="RFC8697"/>, the target="RFC8697" format="default"/>, Bidirectional LSP
        Associations can be created and updated by a Stateful stateful PCE.</t>

        <t><list style="symbols">
        <t>For Single-sided
        <ul spacing="normal">
          <li>For a Single-Sided Bidirectional LSP Association initiated by the PCE,
        it MUST
        the PCE <bcp14>MUST</bcp14> send a PCInitiate message to the originating endpoint node with both
        direction forward and reverse LSPs. For Double-sided a Double-Sided Bidirectional LSP Association
        initiated by the PCE, it MUST <bcp14>MUST</bcp14> send a PCInitiate message to both
        endpoint nodes with forward direction LSPs. </t>

            <t>Both </li>
          <li>Both PCCs MUST <bcp14>MUST</bcp14> report the forward and reverse LSPs in the
            Bidirectional LSP Association to the PCE. A PCC reports via a PCRpt message.</t>

            <t>Stateful message.</li>
          <li>Stateful PCEs MAY <bcp14>MAY</bcp14> create and update the forward and reverse LSPs
            independently for the Single-sided Single-Sided Bidirectional
            LSP Association on the originating endpoint node.</t>

            <t>Stateful node.</li>
          <li>Stateful PCEs MAY <bcp14>MAY</bcp14> create and update the forward LSP
            independently for the Double-sided Double-Sided Bidirectional
            LSP Association on the endpoint nodes.</t>

            <t>Stateful nodes.</li>
          <li>Stateful PCEs establish and remove the association
            relationship on a per LSP basis.</t>

            <t>Stateful per-LSP basis.</li>
          <li>Stateful PCEs create and update the LSP and the association
            on PCCs via PCInitiate and PCUpd messages, respectively, using
            the procedures described in <xref target="RFC8697"/>.</t>
          </list></t> target="RFC8697" format="default"/>.</li>
        </ul>
      </section>
      <section anchor="sect-5.2" title="PCC Initiated LSPs"> numbered="true" toc="default">
        <name>PCC-Initiated LSPs</name>
        <t>As specified in <xref target="RFC8697"/>, the target="RFC8697" format="default"/>, Bidirectional LSP
        Associations can also be created and updated by a PCC.</t>

        <t><list style="symbols">
        <t>For Single-sided
        <ul spacing="normal">

          <li>For a Single-Sided Bidirectional LSP Association initiated at a PCC,
        it MUST
        the PCC <bcp14>MUST</bcp14> send a PCRpt message to the PCE with both direction forward and reverse LSPs.
        For Double-sided a Double-Sided Bidirectional LSP Association initiated at the PCCs,
        both PCCs MUST <bcp14>MUST</bcp14> send a PCRpt message to the PCE with forward direction LSPs.</t>

            <t>PCCs LSPs.</li>
          <li>PCCs on the originating endpoint node MAY <bcp14>MAY</bcp14> create and update the forward and reverse LSPs
            independently for the Single-sided Single-Sided Bidirectional LSP Association.</t>

            <t>PCCs Association.</li>
          <li>PCCs on the endpoint nodes MAY <bcp14>MAY</bcp14> create and update the forward LSP
            independently for the Double-sided Double-Sided Bidirectional LSP Association.</t>

            <t>PCCs Association.</li>
          <li>PCCs establish and remove the association group on a
            per LSP
            per-LSP basis. PCCs MUST <bcp14>MUST</bcp14> report the change in the association group of an LSP
            to PCE(s) via a PCRpt message.</t>

            <t>PCCs message.</li>
          <li>PCCs report the forward and reverse LSPs in the Bidirectional LSP Association independently to
            PCE(s) via a PCRpt message.</t>

            <t>PCCs message.</li>
          <li>PCCs for the single-sided case MAY <bcp14>MAY</bcp14> delegate the forward and reverse LSPs independently to
            a Stateful stateful PCE, where the PCE would control the LSPs. In this case,
            the originating (PCC) endpoint node SHOULD <bcp14>SHOULD</bcp14> delegate both forward and reverse
            LSPs of a tunnel together to a Stateful stateful PCE in order to avoid any race condition.</t>

            <t>PCCs condition.</li>
          <li>PCCs for the double-sided case MAY <bcp14>MAY</bcp14> delegate the forward LSPs to
            a Stateful stateful PCE, where the PCE would control the LSPs.</t>

            <t>Stateful LSPs.</li>
          <li>A stateful PCE updates the LSPs in the Bidirectional LSP
            Association via a PCUpd message, using the procedures
            described in <xref target="RFC8697"/>.</t>
          </list></t> target="RFC8697" format="default"/>.</li>
        </ul>
      </section>
      <section anchor="sect-5.3" title="Stateless PCE"> numbered="true" toc="default">
        <name>Stateless PCE</name>
        <t>For a stateless PCE, it might be useful to associate a path computation request to an association group, thus enabling it to
        associate a common set of configuration parameters or behaviors with
        the request <xref target="RFC8697"/>. target="RFC8697" format="default"/>. A PCC can request co-routed or non-co-routed forward and
        reverse direction paths from a stateless PCE for a Bidirectional LSP Association.</t>
      </section>
      <section anchor="sect-5.4" title="Bidirectional numbered="true" toc="default">
        <name>Bidirectional (B) Flag"> Flag</name>
        <t>As defined in <xref target="RFC5440"/>, target="RFC5440" format="default"/>, the Bidirectional (B) flag
        in the Request Parameters (RP) Object object is set when the PCC specifies
        that the path computation request is for a bidirectional TE LSP with the
        same TE requirements in each direction. For an
        associated bidirectional LSP, the B-flag B flag is also set when the PCC makes
        the path computation request for the same TE requirements for the
        forward and reverse direction LSPs.</t>
        <t>Note that the B-flag B flag defined in a Stateful PCE Request Parameter (SRP)
        Object
        object <xref target="I-D.ietf-pce-pcep-stateful-pce-gmpls"/> target="I-D.ietf-pce-pcep-stateful-pce-gmpls" format="default"/> to
        indicate 'bidirectional "bidirectional co-routed LSP' LSP" is used for GMPLS signaled GMPLS-signaled bidirectional LSPs
        and is not applicable to the associated bidirectional LSPs.</t>
      </section>
      <section anchor="sect-5.5" title="PLSP-ID Usage"> numbered="true" toc="default">
        <name>PLSP-ID Usage</name>
        <t>As defined in <xref target="RFC8231"/>, target="RFC8231" format="default"/>, a PCEP-specific LSP
        Identifier (PLSP-ID) is created by a PCC to uniquely identify an LSP LSP,
        and it remains the same for the lifetime of a PCEP session.</t>
        <t>In the case of Single-sided a Single-Sided Bidirectional LSP Association, the reverse
        LSP of a bidirectional LSP created on the originating endpoint node is
        identified by the PCE using 2 two different PLSP-IDs PLSP-IDs, based on the PCEP
        session on the ingress or egress node PCCs for the LSP. In other words,
        the LSP will have a PLSP-ID P2 allocated at the
        ingress node PCC PCC, while it will have a PLSP-ID P3 allocated at the egress node PCC
        (as shown in Figure 2 Figures <xref target="ure-example-of-pce-initiated-single-sided-bidirectional-lsp" format="counter" /> and Figure 3). <xref target="ure-example-of-pcc-initiated-single-sided-bidirectional-lsp" format="counter"/>).  There is no change in the PLSP-ID
        allocation procedure for the forward LSP of a Single-sided
	Bidirectional single-sided
	bidirectional LSP created on the originating endpoint node.</t>
        <t>In the case of Double-sided a Double-Sided Bidirectional LSP
        Association, there is no change in the PLSP-ID allocation
        procedure for the forward LSPs on both PCCs.</t> either PCC.</t>
        <t>For an Associated Bidirectional associated bidirectional LSP, the LSP-IDENTIFIERS TLV <xref
        target="RFC8231"/> MUST target="RFC8231" format="default"/> <bcp14>MUST</bcp14> be included in all forward and reverse
        LSPs.</t>
      </section>
      <section anchor="sect-5.6" title="State Synchronization"> numbered="true" toc="default">
        <name>State Synchronization</name>
        <t>During state synchronization, a PCC MUST <bcp14>MUST</bcp14> report all the existing
        Bidirectional LSP Associations to the Stateful PCE stateful PCE, as per <xref
        target="RFC8697"/>. target="RFC8697" format="default"/>.  After the state synchronization, the PCE MUST <bcp14>MUST</bcp14>
        remove all previous
        Bidirectional LSP Associations absent in the report.</t>
      </section>
      <section anchor="sect-5.7" title="Error Handling"> numbered="true" toc="default">
        <name>Error Handling</name>
        <t>If a PCE speaker receives an LSP with a
        Bidirectional LSP Association Type that it does not support,
        the PCE speaker MUST <bcp14>MUST</bcp14> send PCErr with Error-Type =
        26 (Association Error) and Error-Value Error-value = 1 (Association Type
        is not supported).</t>
        <t>An LSP (forward or reverse) cannot be part of more than one
        Bidirectional LSP Association. If a PCE speaker receives an LSP
        not complying to this rule, the PCE speaker MUST <bcp14>MUST</bcp14> send PCErr with Error-Type =
        26 (Association Error) and Error-Value Error-value = TBD4 (Bidirectional LSP
        Association - Group Mismatch).</t> 14 (Association group mismatch).</t>

        <t>The LSPs (forward or reverse) in a Single-sided Single-Sided Bidirectional
        Association MUST <bcp14>MUST</bcp14> belong to the same TE Tunnel tunnel (as defined in
        <xref target="RFC3209"/>). target="RFC3209" format="default"/>). If a PCE speaker attempts to add an LSP in a
        Single-sided
        Single-Sided Bidirectional LSP Association for a different
        Tunnel,
        tunnel, the PCE speaker MUST <bcp14>MUST</bcp14> send PCErr with Error-Type = 26 (Association
        Error) and Error-Value Error-value = TBD5 (Bidirectional Association - Tunnel
        Mismatch).</t> 15 (Tunnel mismatch in the association group).</t>
        <t>The PCEP Path Setup Type (PST) for RSVP-TE is set to
        'Path
        "Path is set up using the RSVP-TE signaling protocol' protocol" (Value 0)
        <xref target="RFC8408"/>. target="RFC8408" format="default"/>. If a PCEP speaker receives a
        different PST value for the Bidirectional LSP Associations
        defined in this document, the PCE speaker MUST <bcp14>MUST</bcp14> return a PCErr message with Error-Type =
        26 (Association Error) and Error-Value Error-value = TBD6 (Bidirectional LSP
        Association - Path 16 (Path Setup Type Not Supported).</t> not supported).</t>
        <t>A Bidirectional LSP Association cannot have both unidirectional
        LSPs identified as Reverse reverse LSPs or both LSPs
        identified as Forward forward LSPs. If a PCE speaker receives an LSP
        not complying to this rule, the PCE speaker MUST <bcp14>MUST</bcp14> send PCErr with Error-Type =
        26 (Association Error) and Error-Value Error-value = TBD7 17 (Bidirectional LSP
        Association - Direction Mismatch).</t> direction mismatch).</t>
        <t>A Bidirectional LSP Association cannot have one unidirectional
        LSP identified as co-routed and the other identified as non-co-routed. If a PCE speaker receives an LSP
        not complying to this rule, the PCE speaker MUST <bcp14>MUST</bcp14> send PCErr with Error-Type =
        26 (Association Error) and Error-Value Error-value = TBD8 18 (Bidirectional LSP
        Association - Co-routed Mismatch).</t> co-routed mismatch).</t>
        <t>The unidirectional LSPs forming the Bidirectional
        LSP Association MUST <bcp14>MUST</bcp14> have matching endpoint nodes in the reverse directions.
        If a PCE speaker receives an LSP
        not complying to this rule, the PCE speaker MUST <bcp14>MUST</bcp14> send PCErr with Error-Type =
        26 (Association Error) and Error-Value Error-value = TBD9 (Bidirectional LSP
        Association - Endpoint Mismatch).</t> 19 (Endpoint mismatch in the association group).</t>
        <t>The processing rules as specified in Section 6.4 of <xref
        target="RFC8697"/> target="RFC8697" section="6.4" sectionFormat="of"/> continue to apply to the Association Types defined
        in this document.</t>
      </section>
    </section>
    <section anchor="sect-6" title="Implementation Status">
      <t>[Note to the RFC Editor - remove this section before publication, as
      well as remove the reference to RFC 7942.]</t>

      <t>This section records the status of known implementations of the
      protocol defined by this specification at the time of posting of this
      Internet-Draft, and is based on a proposal described in <xref
      target="RFC7942"/>. The description of implementations in this section
      is intended to assist the IETF in its decision processes in progressing
      drafts to RFCs. Please note that the listing of any individual
      implementation here does not imply endorsement by the IETF. Furthermore,
      no effort has been spent to verify the information presented here that
      was supplied by IETF contributors. This is not intended as, and must not
      be construed to be, a catalog of available implementations or their
      features. Readers are advised to note that other implementations may
      exist.</t>

      <t>According to <xref target="RFC7942"/>, "this will allow reviewers and
      working groups to assign due consideration to documents that have the
      benefit of running code, which may serve as evidence of valuable
      experimentation and feedback that have made the implemented protocols
      more mature. It is up to the individual working groups to use this
      information as they see fit".</t>

      <section anchor="sect-6.1" title="Implementation">
        <t>The PCEP extensions defined in this document has been implemented
        by a vendor on their product. No further information is available at
        this time.</t>
      </section>
    </section>

    <section anchor="sect-7" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations described in <xref target="RFC5440"/>, target="RFC5440" format="default"/>,
      <xref target="RFC8231"/>, target="RFC8231" format="default"/>, and <xref target="RFC8281"/> target="RFC8281" format="default"/> apply to the
      extensions defined in this document as well.</t>
      <t>Two new Association Types for the ASSOCIATION Object, Single-sided object, Single-Sided
      Bidirectional LSP Association and Double-sided Double-Sided Bidirectional LSP
      Association
      Association, are introduced in this document. Additional security
      considerations related to LSP associations due to a malicious PCEP
      speaker is are described in <xref target="RFC8697"/> target="RFC8697" format="default"/> and apply to these
      Association Types. Hence, securing the PCEP session using Transport
      Layer Security (TLS) <xref target="RFC8253"/> target="RFC8253" format="default"/> is RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</t>
    </section>
    <section anchor="sect-8" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <section anchor="sect-8.1" title="Control numbered="true" toc="default">
        <name>Control of Function and Policy"> Policy</name>
        <t>The mechanisms defined in this document do not imply any control or
        policy requirements in addition to those already listed in <xref
        target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC8231"/>, target="RFC8231" format="default"/>, and <xref
        target="RFC8281"/>.</t> target="RFC8281" format="default"/>.</t>
      </section>
      <section anchor="sect-8.2" title="Information numbered="true" toc="default">
        <name>Information and Data Models"> Models</name>
        <t><xref target="RFC7420"/> target="RFC7420" format="default"/> describes the PCEP MIB, MIB; there are no new
        MIB Objects objects defined for LSP associations.</t>
        <t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang"/> target="I-D.ietf-pce-pcep-yang" format="default"/>
        defines a data model for LSP associations.</t>
      </section>
      <section anchor="sect-8.3" title="Liveness numbered="true" toc="default">
        <name>Liveness Detection and Monitoring"> Monitoring</name>
        <t>The mechanisms defined in this document do not imply any new
        liveness detection and monitoring requirements in addition to those
        already listed in <xref target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC8231"/>, target="RFC8231" format="default"/>,
        and <xref target="RFC8281"/>.</t> target="RFC8281" format="default"/>.</t>
      </section>
      <section anchor="sect-8.4" title="Verify numbered="true" toc="default">
        <name>Verify Correct Operations"> Operations</name>
        <t>The mechanisms defined in this document do not imply any new
        operation verification requirements in addition to those already
        listed in <xref target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC8231"/>, target="RFC8231" format="default"/>, and
        <xref target="RFC8281"/>.</t> target="RFC8281" format="default"/>.</t>
      </section>
      <section anchor="sect-8.5" title="Requirements On numbered="true" toc="default">
        <name>Requirements on Other Protocols"> Protocols</name>
        <t>The mechanisms defined in this document do not add any new
        requirements on other protocols.</t>
      </section>
      <section anchor="sect-8.6" title="Impact On numbered="true" toc="default">
        <name>Impact on Network Operations"> Operations</name>
        <t>The mechanisms defined in this document do not have any impact on
        network operations in addition to those already listed in <xref
        target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC8231"/>, target="RFC8231" format="default"/>, and <xref
        target="RFC8281"/>.</t> target="RFC8281" format="default"/>.</t>
      </section>
    </section>
    <section anchor="sect-9" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section anchor="sect-9.1" title="Association Types"> numbered="true" toc="default">
        <name>Association Types</name>

        <t>This document defines two new Association Types, originally described in Types
    <xref target="RFC8697"/>. target="RFC8697" format="default"/>.  IANA is requested to assign has assigned the following new values in the
    "ASSOCIATION Type Field" subregistry <xref target="RFC8697"/> target="RFC8697" format="default"/> within the "Path
    Computation Element Protocol (PCEP) Numbers" registry:</t>

        <figure>
          <artwork>

<table anchor="assoc-types">
  <name>Additions to ASSOCIATION Type Name                                             Reference
---------------------------------------------------------------------
TBD1 Single-sided Bidirectional LSP Association      [This document]
TBD2 Double-sided Bidirectional LSP Association      [This document]
</artwork>
        </figure> Field Subregistry</name>
  <thead>
    <tr>
      <th>Type</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>4</td>
      <td>Single-Sided Bidirectional LSP Association</td>
      <td>RFC 9059</td>
    </tr>
    <tr>
      <td>5</td>
      <td>Double-Sided Bidirectional LSP Association</td>
      <td>RFC 9059</td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="sect-9.2"
               title="Bidirectional numbered="true" toc="default">
        <name>Bidirectional LSP Association Group TLV"> TLV</name>
        <t>This document defines a new TLV for carrying additional information
        of
        about LSPs within a Bidirectional LSP Association. IANA is
        requested to add has
        assigned the assignment of a new following value in the existing "PCEP
        TLV Type Indicators" registry as follows:</t>

        <figure>
          <artwork>
Value     Meaning                                   Reference
-------------------------------------------------------------------
 TBD3     Bidirectional subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry:</t>

<table anchor="new-tlv">
  <name>Addition to PCEP TLV Type Indicators Subregistry
</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Meaning</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>54</td>
      <td>Bidirectional LSP Association Group TLV   [This document]
</artwork>
        </figure> TLV</td>
      <td>RFC 9059</td>
    </tr>
  </tbody>
</table>

        <section anchor="sect-9.2.1"
                 title="Flag numbered="true" toc="default">
          <name>Flag Field in Bidirectional LSP Association Group TLV">
          <t>This document requests that TLV</name>
          <t>IANA has created a new sub-registry, subregistry, named
          "Bidirectional LSP Association Group TLV Flag Field", is created
          within the "Path Computation Element Protocol (PCEP) Numbers"
          registry to manage the Flag field in the Bidirectional LSP
          Association Group TLV. New values are to be assigned by Standards
          Action <xref target="RFC8126"/>. target="RFC8126" format="default"/>. Each bit should be tracked with the
          following qualities:</t>

          <t><list style="symbols">
              <t>Bit
          <ul spacing="normal">
            <li>Bit number (count from 0 as the most significant bit)</t>

              <t>Description</t>

              <t>Reference</t>
            </list></t> bit)</li>
            <li>Description</li>
            <li>Reference</li>
          </ul>
          <t>The following values are defined in initial contents of this document for the Flag
          field.</t>

          <figure>
            <artwork>
Bit No.     Description                   Reference
---------------------------------------------------------
 31         R - Reverse registry are as follows:
          </t>

<table anchor="flag-field">
  <name>New Bidirectional LSP               [This document]
 30         C Association Group TLV Flag Field Subregistry</name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>

    <tr>
      <td>0-29</td>
      <td>Unassigned</td>
      <td></td>
    </tr>
    <tr>
      <td>30</td>
      <td>C - Co-routed Path            [This document]
 0-29       Unassigned
</artwork>
          </figure> Path</td>
      <td>RFC 9059</td>
    </tr>
    <tr>
      <td>31</td>
      <td>R - Reverse LSP</td>
      <td>RFC 9059</td>
    </tr>
  </tbody>
</table>
        </section>
      </section>
      <section anchor="sect-9.3" title="PCEP Errors"> numbered="true" toc="default">
        <name>PCEP Errors</name>
        <t>This document defines new Error value Error-values for Error Type Error-Type 26
        (Association Error). IANA is requested to allocate has allocated the following new Error value Error-values
        within the "PCEP-ERROR Object Error Types and Values" sub-registry subregistry of
        the PCEP Numbers registry, as follows:</t>

        <figure>
          <artwork>
Error Type  Description                  Reference
---------------------------------------------------------
 26         Association Error

            Error value: TBD4            [This document]
            Bidirectional LSP Association - Group Mismatch "Path Computation Element Protocol (PCEP) Numbers" registry:</t>

<table anchor="error-value">
  <name>Additions to PCEP-ERROR Object Error value: TBD5            [This document]
            Bidirectional LSP Types and Values Subregistry</name>
  <thead>
    <tr>
      <th>Error-Type</th>
      <th>Meaning</th>
      <th>Error-value</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td rowspan="6">26</td>
      <td rowspan="6">Association Error</td>
      <td>14: Association - group mismatch</td>
      <td>RFC 9059</td>
    </tr>
    <tr>
      <td>15: Tunnel Mismatch

            Error value: TBD6            [This document]
            Bidirectional LSP Association - mismatch in the association group</td>
      <td>RFC 9059</td>
    </tr>
    <tr>
      <td>16: Path Setup Type
                                            Not Supported

            Error value: TBD7            [This document]
            Bidirectional LSP Association - Direction Mismatch

            Error value: TBD8            [This document] not supported</td>
      <td>RFC 9059</td>
    </tr>
    <tr>
      <td>17: Bidirectional LSP Association - Co-routed Mismatch

            Error value: TBD9            [This document] direction mismatch</td>
      <td>RFC 9059</td>
    </tr>
    <tr>
      <td>18: Bidirectional LSP Association - co-routed mismatch</td>
      <td>RFC 9059</td>
    </tr>
    <tr>
      <td>19: Endpoint Mismatch

</artwork>
        </figure> mismatch in the association group</td>
      <td>RFC 9059</td>
    </tr>
  </tbody>
</table>

      </section>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      &RFC2119;

      &RFC3209;

      &RFC5440;

      &RFC7551;

      &RFC8126;

      &RFC8174;

      &RFC8231;

      &RFC8253;

      &RFC8281;

      &RFC8537;

      &RFC8697;

<displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
<displayreference target="I-D.ietf-pce-pcep-stateful-pce-gmpls" to="STATEFUL-PCE-GMPLS"/>
<displayreference target="I-D.ietf-pce-sr-bidir-path" to="BIDIR-PATH"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.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.7551.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.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.8281.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8537.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8697.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5654.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7420.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8408.xml"/>

<!-- [I-D.ietf-pce-pcep-yang] IESG state I-D Exists -->

<reference anchor='I-D.ietf-pce-pcep-yang'>
<front>
<title>A YANG Data Model for Path Computation Element Communications Protocol (PCEP)</title>

<author initials='D' surname='Dhody' fullname='Dhruv Dhody' role="editor">
    <organization />
</author>

<author initials='J' surname='Hardwick' fullname='Jonathan Hardwick'>
    <organization />
</author>

<author initials='V' surname='Beeram' fullname='Vishnu Beeram'>
    <organization />
</author>

<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
    <organization />
</author>

<date month='February' day='22' year='2021' />

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-pce-pcep-yang-16' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-yang-16.txt' />
</reference>

<!-- [I-D.ietf-pce-pcep-stateful-pce-gmpls] IESG state I-D Exists -->

<reference anchor='I-D.ietf-pce-pcep-stateful-pce-gmpls'>
<front>
<title>Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks</title>

<author initials='Y' surname='Lee' fullname='Young Lee' role="editor">
    <organization />
</author>

<author initials='H' surname='Zheng' fullname='Haomian Zheng' role="editor">
    <organization />
</author>

<author initials='O' surname='de Dios' fullname='Oscar de Dios'>
    <organization />
</author>

<author initials='V' surname='Lopez' fullname='Victor Lopez'>
    <organization />
</author>

<author initials='Z' surname='Ali' fullname='Zafar Ali'>
    <organization />
</author>

<date month='December' day='28' year='2020' />

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-pce-pcep-stateful-pce-gmpls-14' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-stateful-pce-gmpls-14.txt' />
</reference>

<!-- [I-D.ietf-pce-sr-bidir-path] IESG state I-D Exists -->

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-pce-sr-bidir-path.xml"/>
      </references>

    <references title="Informative References">
      &RFC5654;

      &RFC7420;

      &RFC7942;

      &RFC8051;

      &RFC8408;

      &I-D.ietf-pce-pcep-yang;
      &I-D.ietf-pce-pcep-stateful-pce-gmpls;
      &I-D.ietf-pce-sr-bidir-path;
    </references>
    <section anchor="acknowledgments" numbered="no" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Dhruv Dhody <contact fullname="Dhruv Dhody"/> for various discussions
      on association groups and inputs to this document. The authors would
      also like to thank  Mike Taillon, Harish Sitaraman, Al Morton, and Marina Fizgeer  <contact fullname="Mike Taillon"/>, <contact fullname="Harish Sitaraman"/>, <contact fullname="Al Morton"/>, and <contact fullname="Marina Fizgeer"/> for
      reviewing this document and providing valuable comments.
      The authors would like to thank the following IESG members for their
      review comments and suggestions: Barry Leiba, Éric Vyncke, Benjamin Kaduk,
      Murray Kucherawy, Martin Duke, and Alvaro Retana. <contact fullname="Barry Leiba"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Benjamin Kaduk"/>,
      <contact fullname="Murray Kucherawy"/>, <contact fullname="Martin Duke"/>, and <contact fullname="Alvaro Retana"/>.
      </t>
    </section>

  </back>
</rfc>