PCE Working Group                                         R. Gandhi, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                                C. Barth
Expires: March June 19, 2021                                  Juniper Networks
                                                                  B. Wen
                                                                 Comcast
                                                      September 15,
                                                       December 16, 2020

PCEP

 Path Computation Element Communication Protocol (PCEP) Extensions for
          Associated Bidirectional Label Switched Paths (LSPs)
                  draft-ietf-pce-association-bidir-08
                  draft-ietf-pce-association-bidir-09

Abstract

   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.
   The Stateful PCE extensions allow stateful control of Multiprotocol
   Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
   (LSPs) using PCEP.

   This document defines PCEP extensions for grouping two unidirectional
   MPLS TE LSPs (one in each direction in the network) into an
   Associated Bidirectional LSP.  The mechanisms defined in this
   document can be applied using a Stateful PCE for both PCE-Initiated
   and PCC-Initiated LSPs, as well as when using a Stateless PCE.  The
   procedures defined are applicable to the LSPs using Resource
   Reservation Protocol (RSVP) - Traffic Engineering (RSVP-TE) for signaling.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March June 19, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Summary of PCEP Extensions  . . . . . . . . . . . . . . .   4
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
     2.1.  Key Word Definitions  . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5   4
     3.1.  Single-sided Initiation . . . . . . . . . . . . . . . . .   5
       3.1.1.  PCE-Initiated Single-sided Bidirectional LSP  . . . .   5
       3.1.2.  PCC-Initiated Single-sided Bidirectional LSP  . . . .   6
     3.2.  Double-sided Initiation . . . . . . . . . . . . . . . . .   7
       3.2.1.  PCE-Initiated Double-sided Bidirectional LSP  . . . .   7
       3.2.2.  PCC-Initiated Double-sided Bidirectional LSP  . . . .   8
     3.3.  Co-routed Associated Bidirectional LSP  . . . . . . . . .   8   9
     3.4.  Summary of PCEP Extensions  . . . . . . . . . . . . . . .   9
   4.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   8  10
     4.1.  ASSOCIATION Object  . . . . . . . . . . . . . . . . . . .   8  10
     4.2.  Bidirectional LSP Association Group TLV . . . . . . . . .   9  11
   5.  PCEP Procedure  . . . . . . . . . . . . . . . . . . . . . . .  10  13
     5.1.  PCE Initiated LSPs  . . . . . . . . . . . . . . . . . . .  11  13
     5.2.  PCC Initiated LSPs  . . . . . . . . . . . . . . . . . . .  11  14
     5.3.  Stateless PCE . . . . . . . . . . . . . . . . . . . . . .  12  15
     5.4.  Bidirectional (B) Flag  . . . . . . . . . . . . . . . . .  12  15
     5.5.  PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . .  12  15
     5.6.  State Synchronization . . . . . . . . . . . . . . . . . .  13  16
     5.7.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  13  16
   6.  Implementation Status . . . . . . . . . . . . . . . . . . . .  13  17
     6.1.  Implementation  . . . . . . . . . . . . . . . . . . . . .  14  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14  17
   8.  Manageability Considerations  . . . . . . . . . . . . . . . .  14  18
     8.1.  Control of Function and Policy  . . . . . . . . . . . . .  14  18
     8.2.  Information and Data Models . . . . . . . . . . . . . . .  14  18
     8.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  15  18
     8.4.  Verify Correct Operations . . . . . . . . . . . . . . . .  15  18
     8.5.  Requirements On Other Protocols . . . . . . . . . . . . .  15  18
     8.6.  Impact On Network Operations  . . . . . . . . . . . . . .  15  18
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15  19
     9.1.  Association Types . . . . . . . . . . . . . . . . . . . .  15  19
     9.2.  Bidirectional LSP Association Group TLV . . . . . . . . .  15  19
       9.2.1.  Flag Field in Bidirectional LSP Association Group TLV  16  19
     9.3.  PCEP Errors . . . . . . . . . . . . . . . . . . . . . . .  16  20
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17  20
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  17  20
     10.2.  Informative References . . . . . . . . . . . . . . . . .  18  22
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  19  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19  23

1.  Introduction

   [RFC5440] describes the Path Computation Element Communication
   Protocol (PCEP) as a communication mechanism between a Path
   Computation Client (PCC) and a Path Control Element (PCE), or between
   PCE and PCC, that enables computation of Multiprotocol Label
   Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
   (LSPs).

   [RFC8231] specifies extensions to PCEP to enable stateful control of
   MPLS TE LSPs.  It describes two modes of operation - Passive Stateful
   PCE and Active Stateful PCE.  In [RFC8231], the focus is on Active
   Stateful PCE where LSPs are provisioned on the PCC and control over
   them is delegated to a PCE.  Further, [RFC8281] describes the setup,
   maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE
   model.

   [RFC8697] introduces a generic mechanism to create a grouping of LSPs
   which
   LSPs.  This grouping can then be used to define associations between
   sets of LSPs or between a set of LSPs
   and/or and a set of attributes, for example primary and secondary LSP
   associations, and it
   is equally applicable to the active stateful PCE (active and passive
   modes of a Stateful PCE [RFC8231] or a modes)
   and the stateless PCE [RFC5440]. PCE.

   The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]
   specifies that MPLS-TP "MPLS-TP MUST support unidirectional, co-routed
   bidirectional, and associated bidirectional point-
   to-point LSPs. point-to-point transport
   paths".  [RFC7551] defines RSVP signaling extensions for binding two
   forward and reverse unidirectional LSPs [RFC3209] into an associated
   bidirectional LSP.  The fast reroute (FRR) procedures for associated
   bidirectional LSPs are described in [RFC8537].

   This document defines PCEP extensions for grouping two unidirectional
   MPLS-TE LSPs into an Associated Bidirectional LSP for both single-
   sided and double-sided initiation cases when using a Stateful PCE for
   both PCE-Initiated and PCC-Initiated LSPs as well as when using a
   Stateless PCE.  The procedures defined are applicable to the TE LSPs
   using Resource Reservation Protocol (RSVP) - Traffic Engineering (RSVP-TE)
   for signaling [RFC3209].  Specifically, this document defines two new
   Association Types, "Single-sided Bidirectional LSP Association" and
   "Double-sided Bidirectional LSP Association", as well as
   "Bidirectional LSP Association Group TLV" to carry additional
   information for the association.

   The procedure for associating two unidirectional Segment Routing (SR)
   Paths to form an Associated Bidirectional SR Path is defined in
   [I-D.ietf-pce-sr-bidir-path], and is outside the scope of this
   document.

1.1.  Summary of PCEP Extensions

2.  Conventions Used in This Document

2.1.  Key Word Definitions

   The PCEP extensions defined key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document cover the following
   cases:

   o  A PCC initiates are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Terminology

   The reader is assumed to be familiar with the terminology defined in
   [RFC5440], [RFC7551], [RFC8231], and [RFC8697].

3.  Overview

   As shown in Figure 1, forward and/ or and reverse LSP of a single-sided
      or double-sided unidirectional LSPs can be
   grouped to form an associated bidirectional LSP and retains the control of the LSP.  The PCC computes the path itself or makes a request node A is
   ingress node for path
      computation to a PCE.  After the path setup, it reports the
      information LSP1 and state egress node for LSP2, whereas node D is
   ingress node for LSP2 and egress node for LSP1.  There are two
   methods of the path to the PCE.  This includes the
      association group identifying initiating the bidirectional LSP.  This is the
      Passive Stateful mode defined in [RFC8051].

   o  A PCC initiates the forward and/ or reverse LSP of a association, single-sided
      or double-sided bidirectional LSP
   and delegates double-sided, as defined in [RFC7551] and described in the control
   following sections.

               LSP1 -->          LSP1 -->          LSP1 -->
      +-----+           +-----+           +-----+           +-----+
      |  A  +-----------+  B  +-----------+  C  +-----------+  D  |
      +-----+           +--+--+           +--+--+           +-----+
               <-- LSP2    |                 |     <-- LSP2
                           |                 |
                           |                 |
                        +--+--+           +--+--+
                        |  E  +-----------+  F  |
                        +-----+           +-----+
                                 <-- LSP2

             Figure 1: Example of the Associated Bidirectional LSP to a Stateful PCE.  During delegation

3.1.  Single-sided Initiation

   As specified in [RFC7551], in the association group
      identifying single-sided case, the
   bidirectional LSP tunnel is included.  The PCE computes
      the path of the LSP and updates the PCC with the information about provisioned only on one endpoint node (PCC)
   of the path as long tunnel.  Both endpoint nodes act as it controls the LSP.  This is the Active
      Stateful mode defined in [RFC8051].

   o  A PCE initiates the a PCC.  Both forward and/ or and
   reverse LSP LSPs of a single-sided
      or double-sided bidirectional this tunnel are initiated with the Association Type
   set to "Single-sided Bidirectional LSP Association" on a PCC the
   originating endpoint node.  The forward and retains reverse LSPs are
   identified in the control "Bidirectional LSP Association Group TLV" of the LSP. their
   PCEP ASSOCIATION Objects.

   The PCE is responsible originating endpoint node signals the properties for computing the path reverse
   LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path
   message.  The remote endpoint node then creates the corresponding
   reverse tunnel and updating reverse LSP, and signals the PCC with reverse LSP in
   response to the information about received RSVP-TE Path message.  Similarly, the path as
      well as remote
   endpoint node deletes the association group identifying reverse LSP when it receives the bidirectional LSP.
      This is RSVP-TE
   message to delete the PCE-Initiated mode defined forward LSP [RFC3209].

   As specified in [RFC8281].

   o  A PCC requests co-routed or non-co-routed paths [RFC8537], for fast reroute bypass tunnel assignment,
   the LSP starting from the originating endpoint node is identified as
   the forward and
      reverse LSPs LSP of a the single-sided initiated bidirectional LSP.

3.1.1.  PCE-Initiated Single-sided Bidirectional LSP from a Stateless
                                +-----+
                                | PCE
      [RFC5440].

2.  Conventions Used |
                                +-----+
    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 LSP, R = Reverse LSP, (0, P1, P2, P3) = PLSP-IDs

     Figure 2: Example of PCE-Initiated Single-sided Bidirectional LSP

   As shown in This Document

2.1.  Key Word Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", Figure 2, the forward tunnel 1 and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, both forward LSP1 and only when, they appear in all
   capitals, as shown here.

2.2.  Terminology
   reverse LSP2 are initiated on the originating endpoint node A by the
   PCE.  The reader is assumed to be familiar with PLSP-IDs used are P1 and P2 on the originating endpoint
   node A and P3 on the terminology defined in
   [RFC5440], [RFC7551], [RFC8231], remote endpoint node D.  The originating
   endpoint node A reports tunnels 1 and forward LSP1 and [RFC8697].

3.  Overview

   As shown in Figure 1, two reverse unidirectional LSPs can be grouped LSP2
   to form an associated bidirectional LSP.  There are two methods of
   initiating the bidirectional LSP association, single-sided and
   double-sided, as defined in [RFC7551] PCE.  The endpoint (PCC) node D reports tunnel 2 and described in LSP2 to
   the following
   sections.

               LSP1 -->          LSP1 --> PCE.  The endpoint (PCC) node D also reports the reverse LSP1 -->
      +-----+           +-----+           +-----+
   (not shown for simplicity) to the PCE.

3.1.2.  PCC-Initiated Single-sided Bidirectional LSP
                                   +-----+
                                   |  A  +-----------+  B  +-----------+  C  +-----------+  D PCE |
                                   +-----+           +--+--+           +--+--+           +-----+
               <-- LSP2    |
       Reports/Delegates:           ^    ^      Reports:
       Tunnel 1 (F)                 |     <--     \     Tunnel 2 (F)
       (LSP1 (F, P1), LSP2 (R, P2)) |      \    (LSP2 (F, P3))
       Association #2               |       \   Association #2
                                 +-----+    +-----+
                                 |  A  |
                        +--+--+           +--+--+    |  E  +-----------+  F  D  |
                                 +-----+    +-----+
                                 <-- LSP2

      Legends: F = Forward LSP, R = Reverse LSP, (P1, P2, P3) = PLSP-IDs

     Figure 1: 3: Example of Associated PCC-Initiated Single-sided Bidirectional LSP

3.1.  Single-sided

   As shown in Figure 3, the forward 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 1 and forward LSP1 and reverse LSP2 to the PCE.  The endpoint
   (PCC) node D reports tunnel 2 and LSP2 to the PCE.  The endpoint
   (PCC) node D also reports the reverse LSP1 (not shown for simplicity)
   to the PCE.

3.2.  Double-sided Initiation

   As specified in [RFC7551], in the single-sided double-sided case, the
   bidirectional tunnel is provisioned only on one both endpoint node (PCC) nodes (PCCs) of
   the tunnel.  Both  The forward and reverse LSPs of this tunnel are
   initiated with the Association Type set to "Single-sided "Double-sided
   Bidirectional LSP Association" on the originating both endpoint node. nodes.  The forward
   and reverse LSPs are identified in the Bidirectional "Bidirectional LSP Association
   Group TLV TLV" of their PCEP ASSOCIATION Objects.

   The originating endpoint node signals the properties

   As specified in [RFC8537], for fast reroute bypass tunnel assignment,
   the revere LSP in with the RSVP REVERSE_LSP Object [RFC7551] of higher Source Address [RFC3209] is identified as the
   forward LSP Path
   message.  The remote endpoint then creates the corresponding reverse
   tunnel and signals of the reverse double-sided initiated bidirectional LSP.

3.2.1.  PCE-Initiated Double-sided Bidirectional LSP
                               +-----+
                               | 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 LSP, (0, P4, P5) = PLSP-IDs

     Figure 4: Example of PCE-Initiated Double-sided Bidirectional LSP

   As shown in response to Figure 4, the received RSVP
   Path message.  Similarly, forward tunnel 1 and forward LSP1 are
   initiated on the remote endpoint node deletes A and the reverse LSP when it receives tunnel 2 and reverse
   LSP2 are initiated on the RSVP Path delete message [RFC3209]
   for endpoint node D by the forward LSP. PCE.  The originating PLSP-IDs
   used are P4 on the endpoint node A and P5 on the endpoint (PCC) node may report/ delegate D.
   Both endpoint (PCC) nodes report the forward LSP1 and reverse direction LSPs LSP2 to a the
   PCE.  The remote  Both endpoint (PCC) node
   may nodes also report its forward direction LSP the reverse LSPs (not
   shown for simplicity) to a the PCE.

3.2.2.  PCC-Initiated Double-sided Bidirectional LSP
                               +-----+
                               | PCE |
                               +-----+
       Initiates:                   |    \
       Tunnel 1 (F)                 |     \
       (LSP1 (F, 0), LSP2 (R, 0))   |      \
       Association #1               v       \
                                 +-----+    +-----+
                                 |  A  |    |  D  |
                                 +-----+    +-----+

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

      Legends: F = Forward LSP, (P4, P5) = PLSP-IDs

     Figure 2: 5: Example of PCE-Initiated Single-sided PCC-Initiated Double-sided Bidirectional LSP

                                   +-----+
                                   | PCE |
                                   +-----+
       Reports/Delegates:           ^    ^      Reports:
       Tunnel

   As shown in Figure 5, the forward tunnel 1 (F)                 |     \     Tunnel and forward LSP1 are
   initiated on the endpoint node A and the reverse tunnel 2 (F)
       (LSP1 (F, P1), and reverse
   LSP2 (R, P2)) |      \    (LSP2 (F, P3))
       Association #2               |       \   Association #2 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.  Both endpoint (PCC) nodes report the forward LSP1 and LSP2
   to the PCE.  Both endpoint (PCC) nodes also report the reverse LSPs
   (not shown for simplicity) to the PCE.

3.3.  Co-routed Associated Bidirectional LSP

   In both single-sided and double-sided initiation cases, forward and
   reverse LSPs can be co-routed as shown in Figure 6, where both
   forward and reverse LSPs of a bidirectional LSP follow the same
   congruent path in the forward and reverse directions, respectively.

               LSP3 -->          LSP3 -->          LSP3 -->
      +-----+           +-----+           +-----+           +-----+
      |  A  |    |  +-----------+  B  +-----------+  C  +-----------+  D  |
      +-----+           +-----+           +-----+           +-----+
              <-- LSP4          <-- LSP4          <-- LSP4

        Figure 3: 6: Example of PCC-Initiated Single-sided Co-routed Associated Bidirectional LSP

   As shown

3.4.  Summary of PCEP Extensions

   The PCEP extensions defined in Figures 2 and 3, the forward tunnel and both forward LSP1
   and reverse LSP2 are initiated on this document cover the originating endpoint node A,
   either by following
   modes of operations under the stateful PCE or the originating PCC, respectively.  The
   originating endpoint node model:

   o  A signals PCC initiates the properties of forward and reverse LSP2 in
   the RSVP REVERSE_LSP Object in LSP of a Single-sided
      Bidirectional LSP and retains the Path message control of the LSPs.  Similarly,
      both PCCs initiate the forward LSP1.
   The creation LSPs of reverse tunnel a Double-sided
      Bidirectional LSP and reverse LSP2 on retain the remote
   endpoint node D is triggered by control of the RSVP signaled forward LSP1.
   PLSP-IDs used are shown in LSPs.  The PCC
      computes the Figures as P1, P2 and P3.

   As specified in [RFC8537], path itself or makes a request for fast reroute bypass tunnel assignment,
   the LSP starting from path computation
      to a PCE.  After the originating node is identified as path setup, it reports the
   forward LSP information and
      state of the single-sided initiated bidirectional LSP.

3.2.  Double-sided Initiation

   As specified in [RFC7551], in path to the double-sided case, PCE.  This includes the association group
      identifying the bidirectional tunnel LSP.  This is provisioned on both endpoint nodes (PCCs) of the tunnel.  The Passive Stateful
      mode defined in [RFC8051].

   o  A PCC initiates the forward and reverse LSPs LSP of this tunnel are
   initiated with a Single-sided
      Bidirectional LSP and delegates the Association Type set control of the LSPs to "Double-sided
   Bidirectional LSP Association" on a
      Stateful PCE.  Similarly, both endpoint nodes.  The PCCs initiate the forward
   and reverse LSPs are identified in the of a
      Double-sided Bidirectional LSP Association
   Group TLV of their ASSOCIATION Objects.

   The endpoint (PCC) nodes may report/ and delegate the forward and reverse
   direction control of the
      LSPs to a Stateful PCE.

                               +-----+
                               |  During delegation the association group
      identifying the bidirectional LSP is included.  The PCE |
                               +-----+
             Initiates:         |    \      Initiates:
             Tunnel 1 (F)       |     \     Tunnel 2 (F)
             (LSP1 (F, 0))      |      \    (LSP2 (F, 0))
             Association #3     v       v   Association #3
                             +-----+    +-----+
                             | 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 mode defined in [RFC8051].

   o  A  |    |  D  |
                             +-----+    +-----+

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

     Figure 4: Example initiates the forward and reverse LSP of PCE-Initiated Double-sided a Single-sided
      Bidirectional LSP
                               +-----+
                               | on a PCC and retains the control of the LSP.
      Similarly, a PCE |
                               +-----+
           Reports/Delegates:   ^    ^      Reports/Delegates:
           Tunnel 1 (F)         |     \     Tunnel 2 (F)
           (LSP1 (F, P4))       |      \    (LSP2 (F, P5))
           Association #4       |       \   Association #4
                             +-----+    +-----+
                             |  A  |    |  D  |
                             +-----+    +-----+

     Figure 5: Example initiates the forward LSPs of PCC-Initiated a Double-sided
      Bidirectional LSP

   As shown in Figures 4 and 5, the forward tunnel and forward LSP1 are
   initiated on the endpoint node A and the reverse tunnel both PCCs and reverse
   LSP2 are initiated on retains the endpoint node D, either by control of the
      LSPs.  The PCE or is responsible for computing the
   PCCs, respectively.  PLSP-IDs used are shown in path of the Figures as P4 LSP
      and
   P5.

   As specified in [RFC8537], for fast reroute bypass tunnel assignment, updating the LSP PCC with the higher Source Address [RFC3209] is identified information about the path as well
      as the
   forward LSP of association group identifying the double-sided initiated bidirectional LSP.

3.3.  Co-routed Associated Bidirectional LSP

   In both single-sided and double-sided initiation cases, forward and
   reverse LSPs may be co-routed as shown  This
      is the PCE-Initiated mode defined in Figure 6, where both [RFC8281].

   o  A PCC requests co-routed or non-co-routed paths for forward and
      reverse LSPs of a bidirectional LSP follow the same
   congruent path in the forward and reverse directions, respectively.

               LSP3 -->          LSP3 -->          LSP3 -->
      +-----+           +-----+           +-----+           +-----+
      |  A  +-----------+  B  +-----------+  C  +-----------+  D  |
      +-----+           +-----+           +-----+           +-----+
              <-- LSP4          <-- LSP4          <-- LSP4

        Figure 6: Example of Co-routed Associated Bidirectional LSP including when using a
      Stateless PCE [RFC5440].

4.  Protocol Extensions

4.1.  ASSOCIATION Object

   As per [RFC8697], LSPs are associated by adding them to a common
   association group.  This document defines two new Bidirectional LSP Association Groups to be used by Types,
   called "Single-sided Bidirectional LSP" (TBD1) and "Double-sided
   Bidirectional LSP" (TBD2), based on the associated bidirectional LSPs. generic ASSOCIATION Object
   ((Object-Class value 40).  A member of the Bidirectional LSP
   Association Group can take the role of a forward or reverse LSP and follows
   the following rules:

   o  An LSP (forward or reverse) cannot MUST NOT be part of more than one
      Bidirectional LSP Association.

   o  A Bidirectional LSP Association Group.  More SHOULD NOT have more than one forward LSP
      and/ or reverse LSP can be part of two
      unidirectional LSPs.

   o  The LSPs in a Bidirectional LSP Association
      Group. MUST have matching
      endpoint nodes in the reverse directions.

   o  The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs
      of the Single-sided Bidirectional LSP Association on the
      originating node MUST be the same.

   This document defines two new Association Types for the ASSOCIATION
   Object (Object-Class value 40) as follows:

   o  Association Type (TBD1) = the Single-sided Bidirectional LSP Association Group

   o  Association Type (TBD2) = Double-sided on the
      originating endpoint node MUST be the same, albeit with reverse
      endpoint nodes.

   The Bidirectional LSP Association Group

   These Association Types types are operator-configured associations in
   nature considered to be both
   dynamic and statically operator- configured in nature.  As per [RFC8697], the
   association group could be manually created by the operator on the
   PCEP peers.
   'Operator-configured 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 Association Range' TLV (Value 29) [RFC8697] Range MUST
   NOT be sent set for these this association-type to
   mark a range of Association Types, and MUST be ignored, so Identifiers that are used for operator-
   configured associations to avoid any Association Identifier clash
   within the entire range scope of association ID can be used the Association Source (Refer to [RFC8697]).

   Specifically, for the PCE Initiated Bidirectional LSPs, these
   Associations are dynamically created by the PCE on the PCE peers.
   Similarly, for them. both PCE Initiated and PCC Initiated single-sided
   case, these associations are also dynamically created on thee remote
   endpoint node using the information received from the RSVP message
   from the originating node.

   The Association ID, Association Source, optional Global Association
   Source and optional Extended Association ID in the Bidirectional LSP
   Association Group Object are initialized using the procedures defined in
   [RFC8697] and [RFC7551].

   [RFC8697] 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.  This
   capability exchange for the Bidirectional LSP Association Types MUST
   be done before using the Bidirectional LSP Association.  Thus, the
   PCEP speaker MUST include the Bidirectional LSP Association Types in
   the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer
   before using the Bidirectional LSP Association in PCEP messages.

4.2.  Bidirectional LSP Association Group TLV

   The Bidirectional "Bidirectional LSP Association Group TLV" an OPTIONAL TLV is defined for use
   with the Single-sided and Double-sided Bidirectional LSP Association Group Associations (ASSOCIATION Object Types. with
   Association Type TBD1 for Single-sided Bidirectional LSP or TBD2 for
   Double-sided Bidirectional LSP).

   o  The Bidirectional "Bidirectional LSP Association Group TLV TLV" follows the PCEP TLV
      format from [RFC5440].

   o  The Type (16 bits) of the TLV is TBD3, to be assigned by IANA.

   o  The Length is 4 Bytes.

   o  The value comprises of a single field, the Bidirectional LSP
      Association Flag (32 bits), where each bit represents a flag
      option.

   o  If the Bidirectional "Bidirectional LSP Association Group TLV TLV" is missing, it
      means the LSP is the forward LSP and it is not co-routed LSP.

   o  For co-routed LSPs, this TLV MUST be present. present and C flag set.

   o  For reverse LSPs, this TLV MUST be present. present and R flag set.

   o  The Bidirectional "Bidirectional LSP Association Group TLV TLV" MUST NOT be present
      more than once.  If it appears more than once, only the first
      occurrence is processed and any others MUST be ignored.

   The format of the Bidirectional "Bidirectional LSP Association Group TLV TLV" is shown
   in Figure 7:

    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           |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Reserved                       Flags                             |C|R|F|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 7: Bidirectional LSP Association Group TLV format

   Flags for Bidirectional "Bidirectional LSP Association Group TLV TLV" are defined as
   following.

   F (Forward LSP, 1 bit) bit, Bit number 31) - Indicates whether the LSP
   associated is the forward LSP of the bidirectional LSP.  If this flag
   is set, the LSP is a forward LSP.

   R (Reverse LSP, 1 bit) bit, Bit number 30) - Indicates whether the LSP
   associated is the reverse LSP of the bidirectional LSP.  If this flag
   is set, the LSP is a reverse LSP.

   C (Co-routed Path, 1 bit) bit, Bit number 29) - Indicates whether the
   bidirectional LSP is co-routed.  This flag MUST be set for both the
   forward and reverse LSPs of a co-routed bidirectional LSP.

   The C flag is used by the PCE (for both Stateful and Stateless) to
   compute bidirectional paths of the forward and reverse LSPs of a co-
   routed bidirectional LSP.

   The Reserved unassigned flags (Bit Number 0-28) MUST be set to 0 when sent and
   MUST be ignored when received.

5.  PCEP Procedure

   The PCEP procedure defined in this document is applicable to the
   following three scenarios:

   o  Neither unidirectional LSP exists, and both must be established.

   o  Both unidirectional LSPs exist, but the association must be
      established.

   o  One LSP exists, but the reverse associated LSP must be
      established.

5.1.  PCE Initiated LSPs

   As specified in [RFC8697], the Bidirectional LSP Association Groups Associations can be
   created and updated by a Stateful PCE.

   o  For Single-sided Bidirectional LSP Association initiated by the
      PCE, it MUST send PCInitiate message to the originating endpoint
      node with both direction LSPs.  For Double-sided Bidirectional LSP
      Association initiated by the PCE, it MUST send PCInitiate message
      to both endpoint nodes with forward direction LSPs.

   o  Both PCCs MUST report the forward and reverse LSPs in the
      Bidirectional LSP Association to the PCE.  PCC reports via PCRpt
      message.

   o  Stateful PCE can MAY create and update the forward and reverse LSPs
      independently for both the Single-sided Bidirectional LSP Association
      on the originating endpoint node.

   o  Stateful PCE MAY create and update the forward LSP independently
      for the Double-sided Bidirectional LSP Association Groups. on the endpoint
      nodes.

   o  Stateful PCE can establish establishes and remove removes the association relationship
      on a per LSP basis.

   o  Stateful PCE can create creates and update updates the LSP and the association on a
      PCC via PCInitiate and PCUpd messages, respectively, using the
      procedures described in [RFC8697].

5.2.  PCC Initiated LSPs

   As specified in [RFC8697], Bidirectional LSP Association Groups Associations can also be
   created and updated by a PCC.

   o  For Single-sided Bidirectional LSP Association initiated at a PCC,
      it MUST send PCRpt message to the PCE with both direction LSPs.
      For Double-sided Bidirectional LSP Association initiated at the
      PCCs, both PCCs MUST send PCRpt message to the PCE with forward
      direction LSPs.

   o  PCC can on the originating endpoint node MAY create and update the
      forward and reverse LSPs independently for both the Single-sided
      Bidirectional LSP Association.

   o  PCC on the endpoint nodes MAY create and update the forward LSP
      independently for the Double-sided Bidirectional LSP Association Groups. Association.

   o  PCC can establish establishes and remove removes the association relationship group on a per LSP
      basis.

   o  PCC MUST report the change in the association group of an
      LSP to PCE(s) via PCRpt message.

   o  PCC can report reports the forward and reverse LSPs in the Bidirectional LSP
      Association independently to PCE(s) via PCRpt message.

   o  PCC can for the single-sided case MAY delegate the forward and reverse
      LSPs independently to a Stateful PCE, where PCE would control the
      LSPs.  For single-sided  In this case, the originating (PCC) endpoint node can SHOULD
      delegate both forward and reverse LSPs of a tunnel together to a
      Stateful PCE in order to avoid any race condition.

   o  PCCs for the double-sided case MAY delegate the forward LSPs to a
      Stateful PCE, where PCE can update would control the LSPs.

   o  Stateful PCE updates the LSPs in the Bidirectional LSP Association Group
      via PCUpd message, using the procedures described in [RFC8697].

5.3.  Stateless PCE

   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. request [RFC8697].  A PCC can request co-routed or non-co-routed
   forward and reverse direction paths from a stateless PCE for a
   Bidirectional LSP Association Group. Association.

5.4.  Bidirectional (B) Flag

   As defined in [RFC5440], 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 is also set when the PCC makes the path computation
   request for the same TE requirements for the forward and reverse
   direction LSPs.

   Note that the B-flag defined in Stateful PCE Request Parameter (SRP)
   object
   Object [I-D.ietf-pce-pcep-stateful-pce-gmpls] to indicate
   'bidirectional co-routed LSP' is used for GMPLS signaled
   bidirectional LSPs and is not applicable to the associated
   bidirectional LSPs.

5.5.  PLSP-ID Usage

   As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is
   created by a PCC to uniquely identify an LSP and it remains the same
   for the lifetime of a PCEP session.

   In case of 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 different PLSP-IDs based on the PCEP
   session on the ingress or egress nodes for the LSP.  In other words,
   the reverse LSP will have a PLSP-ID P1 at the ingress node while it
   will have a PLSP-ID P3 at the egress node.  There is no change in the
   PLSP-ID allocation procedure for the forward LSP of the Single-sided
   Bidirectional LSP on the originating endpoint node.  In case of
   Double-sided Bidirectional LSP Association, there is no change in the
   PLSP-ID allocation procedure.

   For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231]
   MUST be included in all forward and reverse LSPs.

5.6.  State Synchronization

   During state synchronization, a PCC MUST report all the existing
   Bidirectional LSP Association Groups Associations to the Stateful PCE as per [RFC8697].
   After the state synchronization, the PCE MUST remove all stale
   Bidirectional LSP Associations.

5.7.  Error Handling

   If a PCE speaker receives an LSP with a Bidirectional LSP Association
   Type that it does not support, the PCE speaker MUST send PCErr with
   Error-Type = 26 (Association Error) and Error-Value = 1 (Association
   Type is not supported).

   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 send PCErr with Error-
   Type = 26 (Association Error) and Error-Value = TBD4 (Bidirectional
   LSP Association - Group Mismatch).

   The LSPs (forward or reverse) in a Single-sided Bidirectional
   Association MUST belong to the same TE Tunnel (as defined in
   [RFC3209]).  If a PCE speaker attempts to add an LSP in a Single-
   sided Bidirectional LSP Association for a different Tunnel, the PCE
   speaker MUST send PCErr with Error-Type = 26 (Association Error) and
   Error-Value = TBD5 (Bidirectional Association - Tunnel Mismatch).

   The PCEP Path Setup Type (PST) for RSVP-TE is set to 'Path is set up
   using the RSVP-TE signaling protocol' (Value 0) [RFC8408].  If a PCEP
   speaker receives a different PST value for the Bidirectional LSP
   Associations defined in this document and it does not support; the
   PCE speaker MUST return a PCErr message with Error-Type = 26
   (Association Error) and Error-Value = TBD6 (Bidirectional LSP
   Association - Path Setup Type Not Supported).

   A Bidirectional LSP Association Group. cannot have both unidirectional LSPs
   identified as Reverse LSPs or both LSPs identified as Forward LSPs.
   If a PCE attempts to add speaker receives an LSP not complying to this rule, the PCC PCE
   speaker MUST send PCErr with Error-Type = 26 (Association Error) and
   Error-Value = TBD4 TBD7 (Bidirectional LSP Association - Group Direction
   Mismatch).  Similarly, if

   A Bidirectional LSP Association cannot have one unidirectional LSP
   identified as co-routed and the other identified as non-co-routed.
   If a PCC attempts to add PCE speaker receives an LSP at PCE not complying to this rule, the PCE MUST send this
   PCErr.

   The LSPs (forward or reverse) in a Single-sided Bidirectional
   Association Group MUST belong to the same TE Tunnel (as defined in
   [RFC3209]).  If a PCE attempts to add an LSP in a Single-sided
   Bidirectional LSP Association Group for a different Tunnel, the PCC
   speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error-
   Value
   Error-Value = TBD5 TBD8 (Bidirectional LSP Association - Tunnel Co-routed
   Mismatch).
   Similarly, if a PCC attempts to add an LSP to a Single-sided

   The unidirectional LSPs forming the Bidirectional LSP Association Group at
   MUST have matching endpoint nodes in the reverse directions.  If a
   PCE speaker receives an LSP not complying to this rule, the PCE MUST send this PCErr.

   The PCEP Path Setup Type (PST) for RSVP is set to 'Path is set up
   using the RSVP-TE signaling protocol' (Value 0) [RFC8408].  If a PCEP
   speaker receives a different PST value for the Bidirectional LSP
   Association Groups defined in this document and it does not support;
   it MUST return a send PCErr message with Error-Type = 26 (Association Error) and
   Error-Value = TBD6 TBD9 (Bidirectional LSP Association - Path
   Setup Type Not Supported). Endpoint
   Mismatch).

   The processing rules as specified in Section 6.4 of [RFC8697]
   continue to apply to the Association Types defined in this document.

6.  Implementation Status

   [Note to the RFC Editor - remove this section before publication, as
   well as remove the reference to RFC 7942.]

   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 [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.

   According to [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".

6.1.  Implementation

   The PCEP extensions defined in this document has been implemented by
   a vendor on their product.  No further information is available at
   this time.

7.  Security Considerations

   The security considerations described in [RFC5440], [RFC8231], and
   [RFC8281] apply to the extensions defined in this document as well.

   Two new Association Types for the ASSOCIATION Object, Single-sided
   Bidirectional LSP Association Group and Double-sided Bidirectional LSP
   Association Group are introduced in this document.  Additional security
   considerations related to LSP associations due to a malicious PCEP
   speaker is described in [RFC8697] and apply to these Association
   Types.  Hence, securing the PCEP session using Transport Layer
   Security (TLS) [RFC8253] is recommended.

8.  Manageability Considerations

8.1.  Control of Function and Policy

   The mechanisms defined in this document do not imply any control or
   policy requirements in addition to those already listed in [RFC5440],
   [RFC8231], and [RFC8281].

8.2.  Information and Data Models

   [RFC7420] describes the PCEP MIB, there are no new MIB Objects
   defined for LSP associations.

   The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data model for
   LSP associations.

8.3.  Liveness Detection and Monitoring

   The mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440], [RFC8231], and [RFC8281].

8.4.  Verify Correct Operations

   The mechanisms defined in this document do not imply any new
   operation verification requirements in addition to those already
   listed in [RFC5440], [RFC8231], and [RFC8281].

8.5.  Requirements On Other Protocols

   The mechanisms defined in this document do not add any new
   requirements on other protocols.

8.6.  Impact On Network Operations

   The mechanisms defined in this document do not have any impact on
   network operations in addition to those already listed in [RFC5440],
   [RFC8231], and [RFC8281].

9.  IANA Considerations

9.1.  Association Types

   This document adds defines two new Association Types for the ASSOCIATION Object
   (Object-class value 40) defined Types, originally described
   in [RFC8697].  IANA is requested to make assign the assignment of following new values for
   in the sub-registry "ASSOCIATION Type"
   [RFC8697], as follows: Type Field" subregistry [RFC8697] within the
   "Path Computation Element Protocol (PCEP) Numbers" registry:

   Type Name                                             Reference
   ---------------------------------------------------------------------
   TBD1 Single-sided Bidirectional LSP Association Group      [This document]
   TBD2 Double-sided Bidirectional LSP Association Group      [This document]

9.2.  Bidirectional LSP Association Group TLV

   This document defines a new TLV for carrying additional information
   of LSPs within a Bidirectional LSP Association Group. Association.  IANA is requested to
   add the assignment of a new value in the existing "PCEP TLV Type
   Indicators" registry as follows:

   Value     Meaning                                   Reference
   -------------------------------------------------------------------
    TBD3     Bidirectional LSP Association Group TLV   [This document]

9.2.1.  Flag Field in Bidirectional LSP Association Group TLV

   This document requests that a new sub-registry, 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 [RFC8126].  Each bit
   should be tracked with the following qualities:

   o  Bit number (count from 0 as the most significant bit)

   o  Description

   o  Reference

   The following values are defined in this document for the Flag field.

   Bit No.     Description                   Reference
   ---------------------------------------------------------
    31         F - Forward LSP               [This document]
    30         R - Reverse LSP               [This document]
    29         C - Co-routed Path            [This document]
    0-28       Unassigned

9.3.  PCEP Errors

   This document defines new Error value for Error Type 26 (Association
   Error).  IANA is requested to allocate new Error value within the
   "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP
   Numbers registry, as follows:

   Error Type  Description                  Reference
   ---------------------------------------------------------
    26         Association Error

               Error value: TBD4            [This document]
               Bidirectional LSP Association - Group Mismatch

               Error value: TBD5            [This document]
               Bidirectional LSP Association - Tunnel Mismatch

               Error value: TBD6            [This document]
               Bidirectional LSP Association - Path Setup Type
                                               Not Supported

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

               Error value: TBD8            [This document]
               Bidirectional LSP Association - Co-routed Mismatch

               Error value: TBD9            [This document]
               Bidirectional LSP Association - Endpoint Mismatch

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC7551]  Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
              Extensions for Associated Bidirectional Label Switched
              Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
              <https://www.rfc-editor.org/info/rfc7551>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

   [RFC8537]  Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to
              the Fast Reroute Procedures for Co-routed Associated
              Bidirectional Label Switched Paths (LSPs)", RFC 8537,
              DOI 10.17487/RFC8537, February 2019,
              <https://www.rfc-editor.org/info/rfc8537>.

   [RFC8697]  Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
              Dhody, D., and Y. Tanaka, "Path Computation Element
              Communication Protocol (PCEP) Extensions for Establishing
              Relationships between Sets of Label Switched Paths
              (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
              <https://www.rfc-editor.org/info/rfc8697>.

10.2.  Informative References

   [I-D.ietf-pce-pcep-stateful-pce-gmpls]
              Lee, Y., Zheng, H., Dios, O., Lopezalvarez, Lopez, V., and Z. Ali, "Path
              Computation Element (PCE) Protocol Extensions for Stateful
              PCE Usage in GMPLS-controlled Networks",
              draft-ietf-pce-pcep-stateful-pce-gmpls-13 draft-ietf-pce-
              pcep-stateful-pce-gmpls-13 (work in progress), April 2020.

   [I-D.ietf-pce-pcep-yang]
              Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
              YANG Data Model for Path Computation Element
              Communications Protocol (PCEP)", draft-ietf-pce-pcep-
              yang-14
              yang-15 (work in progress), July October 2020.

   [I-D.ietf-pce-sr-bidir-path]
              Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
              "PCEP Extensions for Associated Bidirectional Segment
              Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-02 draft-ietf-pce-sr-bidir-path-03 (work
              in progress), March September 2020.

   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
              Sprecher, N., and S. Ueno, "Requirements of an MPLS
              Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
              September 2009, <https://www.rfc-editor.org/info/rfc5654>.

   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "Path Computation Element Communication Protocol
              (PCEP) Management Information Base (MIB) Module",
              RFC 7420, DOI 10.17487/RFC7420, December 2014,
              <https://www.rfc-editor.org/info/rfc7420>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [RFC8051]  Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
              Stateful Path Computation Element (PCE)", RFC 8051,
              DOI 10.17487/RFC8051, January 2017,
              <https://www.rfc-editor.org/info/rfc8051>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC8408]  Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
              Hardwick, "Conveying Path Setup Type in PCE Communication
              Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
              July 2018, <https://www.rfc-editor.org/info/rfc8408>.

Acknowledgments

   The authors would like to thank Dhruv Dhody for various discussions
   on association groups and inputs to this document.  The authors would
   also like to thank Dhruv Dhody, Mike Taillon, and Marina Fizgeer for reviewing
   this document and providing valuable comments.

Authors' Addresses

   Rakesh Gandhi (editor)
   Cisco Systems, Inc.
   Canada

   Email: rgandhi@cisco.com

   Colby Barth
   Juniper Networks

   Email: cbarth@juniper.net

   Bin Wen
   Comcast

   Email: Bin_Wen@cable.comcast.com