rfc9059.original   rfc9059.txt 
PCE Working Group R. Gandhi, Ed. Internet Engineering Task Force (IETF) R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc. Request for Comments: 9059 Cisco Systems, Inc.
Intended status: Standards Track C. Barth Category: Standards Track C. Barth
Expires: August 25, 2021 Juniper Networks ISSN: 2070-1721 Juniper Networks
B. Wen B. Wen
Comcast Comcast
February 21, 2021 June 2021
Path Computation Element Communication Protocol (PCEP) Extensions for Path Computation Element Communication Protocol (PCEP) Extensions for
Associated Bidirectional Label Switched Paths (LSPs) Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-pce-association-bidir-14
Abstract Abstract
This document defines PCEP extensions for grouping two unidirectional This document defines Path Computation Element Communication Protocol
MPLS-TE Label Switched Paths (LSPs), one in each direction in the (PCEP) extensions for grouping two unidirectional MPLS-TE Label
network, into an Associated Bidirectional LSP. These PCEP extensions Switched Paths (LSPs), one in each direction in the network, into an
can be applied using a Stateful PCE for both PCE-Initiated and PCC- associated bidirectional LSP. These PCEP extensions can be applied
Initiated LSPs, as well as when using a Stateless PCE. The PCEP either using a stateful PCE for both PCE-initiated and PCC-initiated
procedures defined are applicable to the LSPs using RSVP-TE for LSPs or using a stateless PCE. The PCEP procedures defined are
signaling. applicable to the LSPs using RSVP-TE for signaling.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on August 25, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9059.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 4 2.1. Key Word Definitions
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview
3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 3.1. Single-Sided Initiation
3.1.1. PCE-Initiated Single-sided Bidirectional LSP . . . . 5 3.1.1. PCE-Initiated Single-Sided Bidirectional LSP
3.1.2. PCC-Initiated Single-sided Bidirectional LSP . . . . 6 3.1.2. PCC-Initiated Single-Sided Bidirectional LSP
3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 7 3.2. Double-Sided Initiation
3.2.1. PCE-Initiated Double-sided Bidirectional LSP . . . . 7 3.2.1. PCE-Initiated Double-Sided Bidirectional LSP
3.2.2. PCC-Initiated Double-sided Bidirectional LSP . . . . 8 3.2.2. PCC-Initiated Double-Sided Bidirectional LSP
3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . 9 3.3. Co-routed Associated Bidirectional LSP
3.4. Summary of PCEP Extensions . . . . . . . . . . . . . . . 9 3.4. Summary of PCEP Extensions
3.5. Operational Considerations . . . . . . . . . . . . . . . 10 3.5. Operational Considerations
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Extensions
4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . 11 4.1. ASSOCIATION Object
4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 12 4.2. Bidirectional LSP Association Group TLV
5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 13 5. PCEP Procedure
5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 14 5.1. PCE-Initiated LSPs
5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 14 5.2. PCC-Initiated LSPs
5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Stateless PCE
5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 15 5.4. Bidirectional (B) Flag
5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 16 5.5. PLSP-ID Usage
5.6. State Synchronization . . . . . . . . . . . . . . . . . . 16 5.6. State Synchronization
5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 16 5.7. Error Handling
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations
6.1. Implementation . . . . . . . . . . . . . . . . . . . . . 18 7. Manageability Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.1. Control of Function and Policy
8. Manageability Considerations . . . . . . . . . . . . . . . . 18 7.2. Information and Data Models
8.1. Control of Function and Policy . . . . . . . . . . . . . 18 7.3. Liveness Detection and Monitoring
8.2. Information and Data Models . . . . . . . . . . . . . . . 18 7.4. Verify Correct Operations
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 19 7.5. Requirements on Other Protocols
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 19 7.6. Impact on Network Operations
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 19 8. IANA Considerations
8.6. Impact On Network Operations . . . . . . . . . . . . . . 19 8.1. Association Types
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.2. Bidirectional LSP Association Group TLV
9.1. Association Types . . . . . . . . . . . . . . . . . . . . 19 8.2.1. Flag Field in Bidirectional LSP Association Group TLV
9.2. Bidirectional LSP Association Group TLV . . . . . . . . . 19 8.3. PCEP Errors
9.2.1. Flag Field in Bidirectional LSP Association Group TLV 20 9. References
9.1. Normative References
9.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgments
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Communication [RFC5440] describes the Path Computation Element Communication
Protocol (PCEP) as a communication mechanism between a Path Protocol (PCEP) as a communication mechanism between a Path
Computation Client (PCC) and a Path Computation Element (PCE), or Computation Client (PCC) and a Path Computation Element (PCE), or
between PCE and PCC, that enables computation of Multiprotocol Label between PCE and PCC, that enables computation of Multiprotocol Label
Switching (MPLS) - Traffic Engineering (TE) Label Switched Paths Switching (MPLS) - Traffic Engineering (TE) Label Switched Paths
(LSPs). (LSPs).
[RFC8231] specifies extensions to PCEP to enable stateful control of [RFC8231] specifies extensions to PCEP to enable stateful control of
MPLS-TE LSPs. It describes two modes of operation - Passive Stateful MPLS-TE LSPs. It describes two modes of operation: passive stateful
PCE and Active Stateful PCE. In [RFC8231], the focus is on Active PCE and active stateful PCE. In [RFC8231], the focus is on active
Stateful PCE where LSPs are provisioned on the PCC and control over stateful PCE where LSPs are provisioned on the PCC and control over
them is delegated to a PCE. Further, [RFC8281] describes the setup, them is delegated to a PCE. Further, [RFC8281] describes the setup,
maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE maintenance, and teardown of PCE-initiated LSPs for the stateful PCE
model. model.
[RFC8697] introduces a generic mechanism to create a grouping of [RFC8697] introduces a generic mechanism for creating a grouping of
LSPs. This grouping can then be used to define associations between 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 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) is equally applicable to the stateful PCE (active and passive modes)
and the stateless PCE. and the stateless PCE.
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]
specifies that "MPLS-TP MUST support unidirectional, co-routed specifies that "MPLS-TP MUST support unidirectional, co-routed
bidirectional, and associated bidirectional point-to-point transport bidirectional, and associated bidirectional point-to-point transport
paths". [RFC7551] defines RSVP signaling extensions for binding paths". [RFC7551] defines RSVP signaling extensions for binding
forward and reverse unidirectional LSPs into an associated forward and reverse unidirectional LSPs into an associated
bidirectional LSP. The fast reroute (FRR) procedures for associated bidirectional LSP. The fast reroute (FRR) procedures for associated
bidirectional LSPs are described in [RFC8537]. bidirectional LSPs are described in [RFC8537].
This document defines PCEP extensions for grouping two unidirectional This document defines PCEP extensions for grouping two unidirectional
MPLS-TE LSPs into an Associated Bidirectional LSP for both single- MPLS-TE LSPs into an associated bidirectional LSP for both single-
sided and double-sided initiation cases when using a Stateful PCE for sided and double-sided initiation cases either when using a stateful
both PCE-Initiated and PCC-Initiated LSPs as well as when using a PCE for both PCE-initiated and PCC-initiated LSPs or when using a
Stateless PCE. The procedures defined are applicable to the LSPs stateless PCE. The procedures defined are applicable to the LSPs
using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) using Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
for signaling [RFC3209]. Specifically, this document defines two new for signaling [RFC3209]. Specifically, this document defines two new
Association Types, "Single-sided Bidirectional LSP Association" and Association Types, Single-Sided Bidirectional LSP Association and
"Double-sided Bidirectional LSP Association", as well as Double-Sided Bidirectional LSP Association, as well as the
"Bidirectional LSP Association Group TLV" to carry additional Bidirectional LSP Association Group TLV, to carry additional
information for the association. information for the association.
The procedure for associating two unidirectional Segment Routing (SR) The procedure for associating two unidirectional Segment Routing (SR)
Paths to form an Associated Bidirectional SR Path is defined in 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 [BIDIR-PATH] and is outside the scope of this document.
document.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Key Word Definitions 2.1. Key Word Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Terminology 2.2. Terminology
The reader is assumed to be familiar with the terminology defined in The reader is assumed to be familiar with the terminology defined in
[RFC5440], [RFC7551], [RFC8231], and [RFC8697]. [RFC5440], [RFC7551], [RFC8231], and [RFC8697].
3. Overview 3. Overview
As shown in Figure 1, forward and reverse unidirectional LSPs can be As shown in Figure 1, forward and reverse unidirectional LSPs can be
grouped to form an associated bidirectional LSP. The node A is grouped to form an associated bidirectional LSP. Node A is the
ingress node for LSP1 and egress node for LSP2, whereas node D is 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 ingress node for LSP2 and egress node for LSP1. There are two
methods of initiating the bidirectional LSP association, single-sided methods of initiating the Bidirectional LSP Association, single-sided
and double-sided, as defined in [RFC7551] and described in the and double-sided, as defined in [RFC7551] and described in the
following sections. following sections.
LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 -->
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +-----------+ B +-----------+ C +-----------+ D | | A +-----------+ B +-----------+ C +-----------+ D |
+-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+ +-----+
<-- LSP2 | | <-- LSP2 <-- LSP2 | | <-- LSP2
| | | |
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| E +-----------+ F | | E +-----------+ F |
+-----+ +-----+ +-----+ +-----+
<-- LSP2 <-- LSP2
Figure 1: Example of Associated Bidirectional LSP Figure 1: Example of Associated Bidirectional LSP
3.1. Single-sided Initiation 3.1. Single-Sided Initiation
As specified in [RFC7551], in the single-sided case, the As specified in [RFC7551], in the single-sided case, the
bidirectional tunnel is provisioned only on one endpoint node (PCC) bidirectional tunnel is provisioned only on one endpoint node (PCC)
of the tunnel. Both endpoint nodes act as PCCs. Both forward and of the tunnel. Both endpoint nodes act as PCCs. Both forward and
reverse LSPs of this tunnel are initiated with the Association Type reverse LSPs of this tunnel are initiated with the Association Type
set to "Single-sided Bidirectional LSP Association" on the set to "Single-Sided Bidirectional LSP Association" on the
originating endpoint node. The forward and reverse LSPs are originating endpoint node. The forward and reverse LSPs are
identified in the "Bidirectional LSP Association Group TLV" of their identified in the Bidirectional LSP Association Group TLV of their
PCEP ASSOCIATION Objects. PCEP ASSOCIATION objects.
The originating endpoint node signals the properties for the reverse The originating endpoint node signals the properties for the reverse
LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path LSP in the RSVP REVERSE_LSP object [RFC7551] of the forward LSP Path
message. The remote endpoint node then creates the corresponding message. The remote endpoint node then creates the corresponding
reverse tunnel and reverse LSP, and signals the reverse LSP in reverse tunnel and reverse LSP, and it then signals the reverse LSP
response to the received RSVP-TE Path message. Similarly, the remote in response to the received RSVP-TE Path message. Similarly, the
endpoint node deletes the reverse LSP when it receives the RSVP-TE remote endpoint node deletes the reverse LSP when it receives the
message to delete the forward LSP [RFC3209]. RSVP-TE message to delete the forward LSP [RFC3209].
As specified in [RFC8537], for fast reroute bypass tunnel assignment, As specified in [RFC8537], for fast reroute bypass tunnel assignment,
the LSP starting from the originating endpoint node is identified as the LSP starting from the originating endpoint node is identified as
the forward LSP of the single-sided initiated bidirectional LSP. the forward LSP of the single-sided initiated bidirectional LSP.
3.1.1. PCE-Initiated Single-sided Bidirectional LSP 3.1.1. PCE-Initiated Single-Sided Bidirectional LSP
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Initiates: | \ Initiates: | \
Tunnel 1 (F) | \ Tunnel 1 (F) | \
(LSP1 (F, 0), LSP2 (R, 0)) | \ (LSP1 (F, 0), LSP2 (R, 0)) | \
Association #1 v \ Association #1 v \
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
skipping to change at page 6, line 26 skipping to change at line 231
| PCE | | PCE |
+-----+ +-----+
Reports: ^ ^ Reports: Reports: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3))
Association #1 | \ Association #1 Association #1 | \ Association #1
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F=Forward LSP, R=Reverse LSP, (0,P1,P2,P3)=PLSP-IDs Legend: F = Forward LSP, R = Reverse LSP, (0,P1,P2,P3) = PLSP-IDs
Figure 2: Example of PCE-Initiated Single-sided Bidirectional LSP Figure 2: Example of PCE-Initiated Single-Sided Bidirectional LSP
Using partial topology from Figure 1, as shown in Figure 2, the Using partial topology from Figure 1, as shown in Figure 2, the
forward tunnel 1 and both forward LSP1 and reverse LSP2 are initiated forward Tunnel 1 and both forward LSP1 and reverse LSP2 are initiated
on the originating endpoint node A by the PCE. The PLSP-IDs used are on the originating endpoint node A by the PCE. The PCEP-specific LSP
P1 and P2 on the originating endpoint node A and P3 on the remote identifiers (PLSP-IDs) used are P1 and P2 on the originating endpoint
endpoint node D. The originating endpoint node A reports tunnels 1 node A and P3 on the remote endpoint node D. The originating
and forward LSP1 and reverse LSP2 to the PCE. The endpoint (PCC) endpoint node A reports Tunnel 1 and forward LSP1 and reverse LSP2 to
node D reports tunnel 2 and LSP2 to the PCE. the PCE. The endpoint (PCC) node D reports Tunnel 2 and LSP2 to the
PCE.
3.1.2. PCC-Initiated Single-Sided Bidirectional LSP
3.1.2. PCC-Initiated Single-sided Bidirectional LSP
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Reports/Delegates: ^ ^ Reports: Reports/Delegates: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3))
Association #2 | \ Association #2 Association #2 | \ Association #2
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F=Forward LSP, R=Reverse LSP, (P1,P2,P3)=PLSP-IDs Legend: F = Forward LSP, R = Reverse LSP, (P1,P2,P3) = PLSP-IDs
Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP Figure 3: Example of PCC-Initiated Single-Sided Bidirectional LSP
Using partial topology from Figure 1, as shown in Figure 3, the Using partial topology from Figure 1, as shown in Figure 3, the
forward tunnel 1 and both forward LSP1 and reverse LSP2 are initiated forward Tunnel 1 and both forward LSP1 and reverse LSP2 are initiated
on the originating endpoint node A (the originating PCC). The PLSP- 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 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 the remote endpoint node D. The originating endpoint (PCC) node A
may delegate the forward LSP1 and reverse LSP2 to the PCE. The may delegate the forward LSP1 and reverse LSP2 to the PCE. The
originating endpoint node A reports tunnels 1 and forward LSP1 and originating endpoint node A reports Tunnel 1 and forward LSP1 and
reverse LSP2 to the PCE. The endpoint (PCC) node D reports tunnel 2 reverse LSP2 to the PCE. The endpoint (PCC) node D reports Tunnel 2
and LSP2 to the PCE. and LSP2 to the PCE.
3.2. Double-sided Initiation 3.2. Double-Sided Initiation
As specified in [RFC7551], in the double-sided case, the As specified in [RFC7551], in the double-sided case, the
bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of
the tunnel. The forward and reverse LSPs of this tunnel are the tunnel. The forward and reverse LSPs of this tunnel are
initiated with the Association Type set to "Double-sided initiated with the Association Type set to "Double-Sided
Bidirectional LSP Association" on both endpoint nodes. The forward Bidirectional LSP Association" on both endpoint nodes. The forward
and reverse LSPs are identified in the "Bidirectional LSP Association and reverse LSPs are identified in the Bidirectional LSP Association
Group TLV" of their ASSOCIATION Objects. Group TLV of their ASSOCIATION objects.
As specified in [RFC8537], for fast reroute bypass tunnel assignment, As specified in [RFC8537], for fast reroute bypass tunnel assignment,
the LSP with the higher Source Address [RFC3209] is identified as the the LSP with the higher source address [RFC3209] is identified as the
forward LSP of the double-sided initiated bidirectional LSP. forward LSP of the double-sided initiated bidirectional LSP.
3.2.1. PCE-Initiated Double-sided Bidirectional LSP 3.2.1. PCE-Initiated Double-Sided Bidirectional LSP
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Initiates: | \ Initiates: Initiates: | \ Initiates:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, 0)) | \ (LSP2 (F, 0)) (LSP1 (F, 0)) | \ (LSP2 (F, 0))
Association #3 v v Association #3 Association #3 v v Association #3
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
skipping to change at page 8, line 26 skipping to change at line 309
| PCE | | PCE |
+-----+ +-----+
Reports: ^ ^ Reports: Reports: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P4)) | \ (LSP2 (F, P5)) (LSP1 (F, P4)) | \ (LSP2 (F, P5))
Association #3 | \ Association #3 Association #3 | \ Association #3
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F=Forward LSP, (0,P4,P5)=PLSP-IDs Legend: F = Forward LSP, (0,P4,P5) = PLSP-IDs
Figure 4: Example of PCE-Initiated Double-sided Bidirectional LSP Figure 4: Example of PCE-Initiated Double-Sided Bidirectional LSP
Using partial topology from Figure 1, as shown in Figure 4, the Using partial topology from Figure 1, as shown in Figure 4, the
forward tunnel 1 and forward LSP1 are initiated on the endpoint node forward Tunnel 1 and forward LSP1 are initiated on the endpoint node
A and the reverse tunnel 2 and reverse LSP2 are initiated on the A, and the reverse Tunnel 2 and reverse LSP2 are initiated on the
endpoint node D by the PCE. The PLSP-IDs used are P4 on the endpoint 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) node A and P5 on the endpoint node D. The endpoint node A (PCC)
reports the forward LSP1 and endpoint node D reports the forward LSP2 reports the forward LSP1, and endpoint node D reports the forward
to the PCE. LSP2 to the PCE.
3.2.2. PCC-Initiated Double-Sided Bidirectional LSP
3.2.2. PCC-Initiated Double-sided Bidirectional LSP
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Reports/Delegates: ^ ^ Reports/Delegates: Reports/Delegates: ^ ^ Reports/Delegates:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P4)) | \ (LSP2 (F, P5)) (LSP1 (F, P4)) | \ (LSP2 (F, P5))
Association #4 | \ Association #4 Association #4 | \ Association #4
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F=Forward LSP, (P4,P5)=PLSP-IDs Legend: F = Forward LSP, (P4,P5) = PLSP-IDs
Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP Figure 5: Example of PCC-Initiated Double-Sided Bidirectional LSP
Using partial topology from Figure 1, as shown in Figure 5, the Using partial topology from Figure 1, as shown in Figure 5, the
forward tunnel 1 and forward LSP1 are initiated on the endpoint node forward Tunnel 1 and forward LSP1 are initiated on the endpoint node
A and the reverse tunnel 2 and reverse LSP2 are initiated on the A, and the reverse Tunnel 2 and reverse LSP2 are initiated on the
endpoint node D (the PCCs). The PLSP-IDs used are P4 on the endpoint 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 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 delegate the forward LSP1 and LSP2 to the PCE. The endpoint node A
(PCC) reports the forward LSP1 and endpoint node D reports the (PCC) reports the forward LSP1, and endpoint node D reports the
forward LSP2 to the PCE. forward LSP2 to the PCE.
3.3. Co-routed Associated Bidirectional LSP 3.3. Co-routed Associated Bidirectional LSP
In both single-sided and double-sided initiation cases, forward and In both single-sided and double-sided initiation cases, forward and
reverse LSPs can be co-routed as shown in Figure 6, where both reverse LSPs can be co-routed as shown in Figure 6, where both
forward and reverse LSPs of a bidirectional LSP follow the same forward and reverse LSPs of a bidirectional LSP follow the same
congruent path in the forward and reverse directions, respectively. congruent path in the forward and reverse directions, respectively.
LSP3 --> LSP3 --> LSP3 --> LSP3 --> LSP3 --> LSP3 -->
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +-----------+ B +-----------+ C +-----------+ D | | A +-----------+ B +-----------+ C +-----------+ D |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
<-- LSP4 <-- LSP4 <-- LSP4 <-- LSP4 <-- LSP4 <-- LSP4
Figure 6: Example of Co-routed Associated Bidirectional LSP Figure 6: Example of Co-routed Associated Bidirectional LSP
The procedure specified in [RFC8537] for fast reroute bypass tunnel The procedure specified in [RFC8537] for fast reroute bypass tunnel
assignment is also applicable to the Co-routed Associated assignment is also applicable to the co-routed associated
Bidirectional LSPs. bidirectional LSPs.
3.4. Summary of PCEP Extensions 3.4. Summary of PCEP Extensions
The PCEP extensions defined in this document cover the following The PCEP extensions defined in this document cover the following
modes of operations under the stateful PCE model: modes of operation under the stateful PCE model:
o A PCC initiates the forward and reverse LSP of a Single-sided * A PCC initiates the forward and reverse LSP of a single-sided
Bidirectional LSP and retains the control of the LSPs. Similarly, bidirectional LSP and retains control of the LSPs. Similarly,
both PCCs initiate the forward LSPs of a Double-sided both PCCs initiate the forward LSPs of a double-sided
Bidirectional LSP and retain the control of the LSPs. The PCC bidirectional LSP and retain control of the LSPs. The PCC
computes the path itself or makes a request for path computation computes the path itself or makes a request for path computation
to a PCE. After the path setup, it reports the information and to a PCE. After the path setup, it reports the information and
state of the path to the PCE. This includes the association group state of the path to the PCE. This includes the association group
identifying the bidirectional LSP. This is the Passive Stateful identifying the bidirectional LSP. This is the passive stateful
mode defined in [RFC8051]. mode defined in [RFC8051].
o A PCC initiates the forward and reverse LSP of a Single-sided * A PCC initiates the forward and reverse LSP of a single-sided
Bidirectional LSP and delegates the control of the LSPs to a bidirectional LSP and delegates control of the LSPs to a stateful
Stateful PCE. Similarly, both PCCs initiate the forward LSPs of a PCE. Similarly, both PCCs initiate the forward LSPs of a double-
Double-sided Bidirectional LSP and delegate the control of the sided bidirectional LSP and delegate control of the LSPs to a
LSPs to a Stateful PCE. During delegation the association group stateful PCE. During delegation, the association group
identifying the bidirectional LSP is included. The PCE computes identifying the bidirectional LSP is included. The PCE computes
the path of the LSP and updates the PCC with the information about 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 the path as long as it controls the LSP. This is the active
Stateful mode defined in [RFC8051]. stateful mode defined in [RFC8051].
o A PCE initiates the forward and reverse LSP of a Single-sided * A PCE initiates the forward and reverse LSP of a single-sided
Bidirectional LSP on a PCC and retains the control of the LSP. bidirectional LSP on a PCC and retains control of the LSP.
Similarly, a PCE initiates the forward LSPs of a Double-sided Similarly, a PCE initiates the forward LSPs of a double-sided
Bidirectional LSP on both PCCs and retains the control of the bidirectional LSP on both PCCs and retains control of the LSPs.
LSPs. The PCE is responsible for computing the path of the LSP The PCE is responsible for computing the path of the LSP and
and updating the PCC with the information about the path as well updating the PCC with the information about the path as well as
as the association group identifying the bidirectional LSP. This the association group identifying the bidirectional LSP. This is
is the PCE-Initiated mode defined in [RFC8281]. the PCE-initiated mode defined in [RFC8281].
o A PCC requests co-routed or non-co-routed paths for forward and * A PCC requests co-routed or non-co-routed paths for forward and
reverse LSPs of a bidirectional LSP including when using a reverse LSPs of a bidirectional LSP, including when using a
Stateless PCE [RFC5440]. stateless PCE [RFC5440].
3.5. Operational Considerations 3.5. Operational Considerations
The double-sided case has an advantage when compared to the single- The double-sided case has an advantage when compared to the single-
sided case summarized as following: sided case, summarized as follows:
o In double-sided case, two existing unidirectional LSPs in reverse * In the double-sided case, two existing unidirectional LSPs in
directions in the network can be associated to form a reverse directions in the network can be associated to form a
bidirectional LSP without significantly increasing the operational bidirectional LSP without significantly increasing the operational
complexity. complexity.
The single-sided case has some advantages when compared to the The single-sided case has some advantages when compared to the
double-sided case summarized as following: double-sided case, summarized as follows:
o Some Operations, Administration, and Maintenance (OAM) use-cases * Some Operations, Administration, and Maintenance (OAM) use cases
may require an endpoint node to know both forward and reverse may require an endpoint node to know both forward and reverse
direction paths for monitoring the bidirectional LSP. For such paths for monitoring the bidirectional LSP. For such use cases,
use-cases, single-sided case may be preferred. the single-sided case may be preferred.
o For Co-routed Associated Bidirectional LSPs in PCC initiated mode, * For co-routed associated bidirectional LSPs in PCC-initiated mode,
the single-sided case allows the originating PCC to dynamically the single-sided case allows the originating PCC to dynamically
compute co-routed forward and reverse paths. This may not be compute co-routed forward and reverse paths. This may not be
possible with double-sided case where the forward and reverse possible with the double-sided case where the forward and reverse
direction paths are computed separately as triggered by two paths are computed separately as triggered by two different PCCs.
different PCCs.
o The Associated Bidirectional LSPs with single-sided case can be * The associated bidirectional LSPs in the single-sided case can be
deployed in a network where PCEP is only enabled on the deployed in a network where PCEP is only enabled on the
originating endpoint nodes as remote endpoint nodes create the originating endpoint nodes as remote endpoint nodes create the
reverse tunnels using RSVP-TE Path messages. reverse tunnels using RSVP-TE Path messages.
4. Protocol Extensions 4. Protocol Extensions
4.1. ASSOCIATION Object 4.1. ASSOCIATION Object
As per [RFC8697], LSPs are associated by adding them to a common As per [RFC8697], LSPs are associated by adding them to a common
association group. This document defines two new Association Types, association group. This document defines two new Association Types,
called "Single-sided Bidirectional LSP" (TBD1) and "Double-sided called "Single-Sided Bidirectional LSP Association" (4) and "Double-
Bidirectional LSP" (TBD2), using the generic ASSOCIATION Object Sided Bidirectional LSP Association" (5), using the generic
((Object-Class value 40). A member of the Bidirectional LSP ASSOCIATION object (Object-Class value 40). A member of the
Association can take the role of a forward or reverse LSP and follows Bidirectional LSP Association can take the role of a forward or
the following rules: reverse LSP and follows the following rules:
o An LSP (forward or reverse) MUST NOT be part of more than one * An LSP (forward or reverse) MUST NOT be part of more than one
Bidirectional LSP Association. Bidirectional LSP Association.
o The LSPs in a Bidirectional LSP Association MUST have matching * The LSPs in a Bidirectional LSP Association MUST have matching
endpoint nodes in the reverse directions. endpoint nodes in the reverse directions.
o The Tunnel (as defined in Section 2.1 of [RFC3209]) containing the * The same tunnel (as defined in Section 2.1 of [RFC3209]) MUST
forward and reverse LSPs of the Single-sided Bidirectional LSP contain the forward and reverse LSPs of the Single-Sided
Association on the originating node MUST be the same, albeit both Bidirectional LSP Association on the originating node, albeit both
LSPs have reversed endpoint nodes. LSPs have reversed endpoint nodes.
The Bidirectional LSP Association types are considered to be both The Bidirectional LSP Association Types are considered to be both
dynamic and operator-configured in nature. As per [RFC8697], the dynamic and operator configured in nature. As per [RFC8697], the
association group could be manually created by the operator on the association group could be manually created by the operator on the
PCEP peers, and the LSPs belonging to this association are conveyed PCEP peers, and the LSPs belonging to this association are conveyed
via PCEP messages to the PCEP peer; alternately, the association via PCEP messages to the PCEP peer; alternately, the association
group could be created dynamically by the PCEP speaker, and both the group could be created dynamically by the PCEP speaker, and both the
association group information and the LSPs belonging to the association group information and the LSPs belonging to the
association group are conveyed to the PCEP peer. The Operator- association group are conveyed to the PCEP peer. The operator-
configured Association Range MUST be set for this association-type to configured Association Range MUST be set for this Association Type to
mark a range of Association Identifiers that are used for operator- mark a range of Association Identifiers that are used for operator-
configured associations to avoid any Association Identifier clash configured associations to avoid any Association Identifier clash
within the scope of the Association Source (Refer to [RFC8697]). within the scope of the Association Source (refer to [RFC8697]).
Specifically, for the PCE Initiated Bidirectional LSPs, these Specifically, for the PCE-initiated bidirectional LSPs, these
Associations are dynamically created by the PCE on the PCE peers. associations are dynamically created by the PCE on the PCE peers.
Similarly, for both PCE Initiated and PCC Initiated single-sided Similarly, for both the PCE-initiated and the PCC-initiated single-
case, these associations are also dynamically created on the remote sided cases, these associations are also dynamically created on the
endpoint node using the information received from the RSVP message remote endpoint node using the information received from the RSVP
from the originating node. message from the originating node.
The Association ID, Association Source, optional Global Association The Association ID, Association Source, optional Global Association
Source TLV and optional Extended Association ID TLV in the Source TLV, and optional Extended Association ID TLV in the
Bidirectional LSP Association Object are initialized using the Bidirectional LSP ASSOCIATION object are initialized using the
procedures defined in [RFC8697] and [RFC7551]. procedures defined in [RFC8697] and [RFC7551].
[RFC8697] specifies the mechanism for the capability advertisement of [RFC8697] specifies the mechanism for the capability advertisement of
the Association Types supported by a PCEP speaker by defining an the Association Types supported by a PCEP speaker by defining an
ASSOC-Type-List TLV to be carried within an OPEN Object. This ASSOC-Type-List TLV to be carried within an OPEN object. This
capability exchange for the Bidirectional LSP Association Types MUST capability exchange for the Bidirectional LSP Association Types MUST
be done before using the Bidirectional LSP Association. Thus, the be done before using the Bidirectional LSP Association. Thus, the
PCEP speaker MUST include the Bidirectional LSP Association Types in PCEP speaker MUST include the Bidirectional LSP Association Types in
the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer
before using the Bidirectional LSP Association in PCEP messages. before using the Bidirectional LSP Association in PCEP messages.
4.2. Bidirectional LSP Association Group TLV 4.2. Bidirectional LSP Association Group TLV
The "Bidirectional LSP Association Group TLV" is an OPTIONAL TLV for The Bidirectional LSP Association Group TLV is an OPTIONAL TLV for
use with the Bidirectional LSP Associations (ASSOCIATION Object with use with Bidirectional LSP Associations (ASSOCIATION object with
Association Type TBD1 for Single-sided Bidirectional LSP or TBD2 for Association Type 4 for Single-Sided Bidirectional LSP Association or
Double-sided Bidirectional LSP). 5 for Double-Sided Bidirectional LSP Association).
o The "Bidirectional LSP Association Group TLV" follows the PCEP TLV * The Bidirectional LSP Association Group TLV follows the PCEP TLV
format from [RFC5440]. format from [RFC5440].
o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. * The Type (16 bits) of the TLV is 54.
o The Length is 4 Bytes. * The Length is 4 bytes.
o The value comprises of a single field, the Bidirectional LSP * The value comprises of a single field, the Flags field (32 bits),
Association Flag (32 bits), where each bit represents a flag where each bit represents a flag option.
option.
o If the "Bidirectional LSP Association Group TLV" is missing, it * If the Bidirectional LSP Association Group TLV is missing, it
means the LSP is the forward LSP and it is not co-routed LSP. means the LSP is the forward LSP, and it is not a co-routed LSP.
o When "Bidirectional LSP Association Group TLV" is present, the R * When the Bidirectional LSP Association Group TLV is present, the R
flag MUST be reset for the forward LSP for both co-routed and non flag MUST be reset for the forward LSP for both co-routed and non-
co-routed LSPs. co-routed LSPs.
o For co-routed LSPs, this TLV MUST be present and C flag set. * For co-routed LSPs, this TLV MUST be present and the C flag set.
o For reverse LSPs, this TLV MUST be present and R flag set. * For reverse LSPs, this TLV MUST be present and the R flag set.
o The "Bidirectional LSP Association Group TLV" MUST NOT be present * The Bidirectional LSP Association Group TLV MUST NOT be present
more than once. If it appears more than once, only the first more than once. If it appears more than once, only the first
occurrence is processed and any others MUST be ignored. occurrence is processed, and any others MUST be ignored.
The format of the "Bidirectional LSP Association Group TLV" is shown The format of the Bidirectional LSP Association Group TLV is shown in
in Figure 7: Figure 7.
0 1 2 3 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 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 | | Type = 54 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |C|R| | Flags |C|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Bidirectional LSP Association Group TLV format Figure 7: Bidirectional LSP Association Group TLV Format
Flags for "Bidirectional LSP Association Group TLV" are defined as Flags for the Bidirectional LSP Association Group TLV are defined as
following. follows.
R (Reverse LSP, 1 bit, Bit number 31) - Indicates whether the LSP R (Reverse LSP, 1 bit, bit number 31): Indicates whether the LSP
associated is the reverse LSP of the bidirectional LSP. If this flag associated is the reverse LSP of the bidirectional LSP. If this
is set, the LSP is a reverse LSP. If this flag is not set, the LSP flag is set, the LSP is a reverse LSP. If this flag is not set,
is a forward LSP. the LSP is a forward LSP.
C (Co-routed Path, 1 bit, Bit number 30) - Indicates whether the C (Co-routed Path, 1 bit, bit number 30): Indicates whether the
bidirectional LSP is co-routed. This flag MUST be set for both the bidirectional LSP is co-routed. This flag MUST be set for both
forward and reverse LSPs of a co-routed bidirectional LSP. 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 The C flag is used by the PCE (both stateful and stateless) to
compute bidirectional paths of the forward and reverse LSPs of a co- compute bidirectional paths of the forward and reverse LSPs of a co-
routed bidirectional LSP. routed bidirectional LSP.
The unassigned flags (Bit Number 0-29) MUST be set to 0 when sent and The unassigned flags (bit numbers 0-29) MUST be set to 0 when sent
MUST be ignored when received. and MUST be ignored when received.
5. PCEP Procedure 5. PCEP Procedure
The PCEP procedure defined in this document is applicable to the The PCEP procedure defined in this document is applicable to the
following three scenarios: following three scenarios:
o Neither unidirectional LSP exists, and both must be established. * Neither unidirectional LSP exists, and both must be established.
o Both unidirectional LSPs exist, but the association must be * Both unidirectional LSPs exist, but the association must be
established. established.
o One LSP exists, but the reverse associated LSP must be * One LSP exists, but the reverse associated LSP must be
established. established.
5.1. PCE Initiated LSPs 5.1. PCE-Initiated LSPs
As specified in [RFC8697], the Bidirectional LSP Associations can be As specified in [RFC8697], Bidirectional LSP Associations can be
created and updated by a Stateful PCE. created and updated by a stateful PCE.
o For Single-sided Bidirectional LSP Association initiated by the * For a Single-Sided Bidirectional LSP Association initiated by the
PCE, it MUST send PCInitiate message to the originating endpoint PCE, the PCE MUST send a PCInitiate message to the originating
node with both direction LSPs. For Double-sided Bidirectional LSP endpoint node with both forward and reverse LSPs. For a Double-
Association initiated by the PCE, it MUST send PCInitiate message Sided Bidirectional LSP Association initiated by the PCE, it MUST
to both endpoint nodes with forward direction LSPs. send a PCInitiate message to both endpoint nodes with forward
LSPs.
o Both PCCs MUST report the forward and reverse LSPs in the * Both PCCs MUST report the forward and reverse LSPs in the
Bidirectional LSP Association to the PCE. PCC reports via PCRpt Bidirectional LSP Association to the PCE. A PCC reports via a
message. PCRpt message.
o Stateful PCEs MAY create and update the forward and reverse LSPs * Stateful PCEs MAY create and update the forward and reverse LSPs
independently for the Single-sided Bidirectional LSP Association independently for the Single-Sided Bidirectional LSP Association
on the originating endpoint node. on the originating endpoint node.
o Stateful PCEs MAY create and update the forward LSP independently * Stateful PCEs MAY create and update the forward LSP independently
for the Double-sided Bidirectional LSP Association on the endpoint for the Double-Sided Bidirectional LSP Association on the endpoint
nodes. nodes.
o Stateful PCEs establish and remove the association relationship on * Stateful PCEs establish and remove the association relationship on
a per LSP basis. a per-LSP basis.
o Stateful PCEs create and update the LSP and the association on * Stateful PCEs create and update the LSP and the association on
PCCs via PCInitiate and PCUpd messages, respectively, using the PCCs via PCInitiate and PCUpd messages, respectively, using the
procedures described in [RFC8697]. procedures described in [RFC8697].
5.2. PCC Initiated LSPs 5.2. PCC-Initiated LSPs
As specified in [RFC8697], the Bidirectional LSP Associations can As specified in [RFC8697], Bidirectional LSP Associations can also be
also be created and updated by a PCC. created and updated by a PCC.
o For Single-sided Bidirectional LSP Association initiated at a PCC, * For a Single-Sided Bidirectional LSP Association initiated at a
it MUST send PCRpt message to the PCE with both direction LSPs. PCC, the PCC MUST send a PCRpt message to the PCE with both
For Double-sided Bidirectional LSP Association initiated at the forward and reverse LSPs. For a Double-Sided Bidirectional LSP
PCCs, both PCCs MUST send PCRpt message to the PCE with forward Association initiated at the PCCs, both PCCs MUST send a PCRpt
direction LSPs. message to the PCE with forward LSPs.
o PCCs on the originating endpoint node MAY create and update the * PCCs on the originating endpoint node MAY create and update the
forward and reverse LSPs independently for the Single-sided forward and reverse LSPs independently for the Single-Sided
Bidirectional LSP Association. Bidirectional LSP Association.
o PCCs on the endpoint nodes MAY create and update the forward LSP * PCCs on the endpoint nodes MAY create and update the forward LSP
independently for the Double-sided Bidirectional LSP Association. independently for the Double-Sided Bidirectional LSP Association.
o PCCs establish and remove the association group on a per LSP * PCCs establish and remove the association group on a per-LSP
basis. PCCs MUST report the change in the association group of an basis. PCCs MUST report the change in the association group of an
LSP to PCE(s) via PCRpt message. LSP to PCE(s) via a PCRpt message.
o PCCs report the forward and reverse LSPs in the Bidirectional LSP * PCCs report the forward and reverse LSPs in the Bidirectional LSP
Association independently to PCE(s) via PCRpt message. Association independently to PCE(s) via a PCRpt message.
o PCCs for the single-sided case MAY delegate the forward and * PCCs for the single-sided case MAY delegate the forward and
reverse LSPs independently to a Stateful PCE, where PCE would reverse LSPs independently to a stateful PCE, where the PCE would
control the LSPs. In this case, the originating (PCC) endpoint control the LSPs. In this case, the originating (PCC) endpoint
node SHOULD delegate both forward and reverse LSPs of a tunnel node SHOULD delegate both forward and reverse LSPs of a tunnel
together to a Stateful PCE in order to avoid any race condition. 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 * PCCs for the double-sided case MAY delegate the forward LSPs to a
Stateful PCE, where PCE would control the LSPs. stateful PCE, where the PCE would control the LSPs.
o Stateful PCE updates the LSPs in the Bidirectional LSP Association * A stateful PCE updates the LSPs in the Bidirectional LSP
via PCUpd message, using the procedures described in [RFC8697]. Association via a PCUpd message, using the procedures described in
[RFC8697].
5.3. Stateless PCE 5.3. Stateless PCE
For a stateless PCE, it might be useful to associate a path For a stateless PCE, it might be useful to associate a path
computation request to an association group, thus enabling it to computation request to an association group, thus enabling it to
associate a common set of configuration parameters or behaviors with associate a common set of configuration parameters or behaviors with
the request [RFC8697]. A PCC can request co-routed or non-co-routed the request [RFC8697]. A PCC can request co-routed or non-co-routed
forward and reverse direction paths from a stateless PCE for a forward and reverse paths from a stateless PCE for a Bidirectional
Bidirectional LSP Association. LSP Association.
5.4. Bidirectional (B) Flag 5.4. Bidirectional (B) Flag
As defined in [RFC5440], the Bidirectional (B) flag in the Request As defined in [RFC5440], the Bidirectional (B) flag in the Request
Parameters (RP) Object is set when the PCC specifies that the path Parameters (RP) object is set when the PCC specifies that the path
computation request is for a bidirectional TE LSP with the same TE computation request is for a bidirectional TE LSP with the same TE
requirements in each direction. For an associated bidirectional LSP, requirements in each direction. For an associated bidirectional LSP,
the B-flag is also set when the PCC makes the path computation the B flag is also set when the PCC makes the path computation
request for the same TE requirements for the forward and reverse request for the same TE requirements for the forward and reverse
direction LSPs. LSPs.
Note that the B-flag defined in Stateful PCE Request Parameter (SRP) Note that the B flag defined in a Stateful PCE Request Parameter
Object [I-D.ietf-pce-pcep-stateful-pce-gmpls] to indicate (SRP) object [STATEFUL-PCE-GMPLS] to indicate "bidirectional co-
'bidirectional co-routed LSP' is used for GMPLS signaled routed LSP" is used for GMPLS-signaled bidirectional LSPs and is not
bidirectional LSPs and is not applicable to the associated applicable to the associated bidirectional LSPs.
bidirectional LSPs.
5.5. PLSP-ID Usage 5.5. PLSP-ID Usage
As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is 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 created by a PCC to uniquely identify an LSP, and it remains the same
for the lifetime of a PCEP session. for the lifetime of a PCEP session.
In case of Single-sided Bidirectional LSP Association, the reverse In the case of a Single-Sided Bidirectional LSP Association, the
LSP of a bidirectional LSP created on the originating endpoint node reverse LSP of a bidirectional LSP created on the originating
is identified by the PCE using 2 different PLSP-IDs based on the PCEP endpoint node is identified by the PCE using two different PLSP-IDs,
session on the ingress or egress node PCCs for the LSP. In other based on the PCEP session on the ingress or egress node PCCs for the
words, the LSP will have a PLSP-ID P2 allocated at the ingress node LSP. In other words, the LSP will have a PLSP-ID P2 allocated at the
PCC while it will have a PLSP-ID P3 allocated at the egress node PCC ingress node PCC, while it will have a PLSP-ID P3 allocated at the
(as shown in Figure 2 and Figure 3). There is no change in the PLSP- egress node PCC (as shown in Figures 2 and 3). There is no change in
ID allocation procedure for the forward LSP of a Single-sided the PLSP-ID allocation procedure for the forward LSP of a single-
Bidirectional LSP created on the originating endpoint node. sided bidirectional LSP created on the originating endpoint node.
In case of Double-sided Bidirectional LSP Association, there is no In the case of a Double-Sided Bidirectional LSP Association, there is
change in the PLSP-ID allocation procedure for the forward LSPs on no change in the PLSP-ID allocation procedure for the forward LSPs on
both PCCs. either PCC.
For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231] For an associated bidirectional LSP, the LSP-IDENTIFIERS TLV
MUST be included in all forward and reverse LSPs. [RFC8231] MUST be included in all forward and reverse LSPs.
5.6. State Synchronization 5.6. State Synchronization
During state synchronization, a PCC MUST report all the existing During state synchronization, a PCC MUST report all the existing
Bidirectional LSP Associations to the Stateful PCE as per [RFC8697]. Bidirectional LSP Associations to the stateful PCE, as per [RFC8697].
After the state synchronization, the PCE MUST remove all previous After the state synchronization, the PCE MUST remove all previous
Bidirectional LSP Associations absent in the report. Bidirectional LSP Associations absent in the report.
5.7. Error Handling 5.7. Error Handling
If a PCE speaker receives an LSP with a Bidirectional LSP Association 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 Type that it does not support, the PCE speaker MUST send PCErr with
Error-Type = 26 (Association Error) and Error-Value = 1 (Association Error-Type = 26 (Association Error) and Error-value = 1 (Association
Type is not supported). Type is not supported).
An LSP (forward or reverse) cannot be part of more than one An LSP (forward or reverse) cannot be part of more than one
Bidirectional LSP Association. If a PCE speaker receives an LSP not Bidirectional LSP Association. If a PCE speaker receives an LSP not
complying to this rule, the PCE speaker MUST send PCErr with Error- complying to this rule, the PCE speaker MUST send PCErr with Error-
Type = 26 (Association Error) and Error-Value = TBD4 (Bidirectional Type = 26 (Association Error) and Error-value = 14 (Association group
LSP Association - Group Mismatch). mismatch).
The LSPs (forward or reverse) in a Single-sided Bidirectional
Association MUST belong to the same TE Tunnel (as defined in
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- [RFC3209]). If a PCE speaker attempts to add an LSP in a Single-
sided Bidirectional LSP Association for a different Tunnel, the PCE Sided Bidirectional LSP Association for a different tunnel, the PCE
speaker MUST send PCErr with Error-Type = 26 (Association Error) and speaker MUST send PCErr with Error-Type = 26 (Association Error) and
Error-Value = TBD5 (Bidirectional Association - Tunnel Mismatch). Error-value = 15 (Tunnel mismatch in the association group).
The PCEP Path Setup Type (PST) for RSVP-TE is set to 'Path is set up 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 using the RSVP-TE signaling protocol" (Value 0) [RFC8408]. If a PCEP
speaker receives a different PST value for the Bidirectional LSP speaker receives a different PST value for the Bidirectional LSP
Associations defined in this document, the PCE speaker MUST return a Associations defined in this document, the PCE speaker MUST return a
PCErr message with Error-Type = 26 (Association Error) and Error- PCErr message with Error-Type = 26 (Association Error) and Error-
Value = TBD6 (Bidirectional LSP Association - Path Setup Type Not value = 16 (Path Setup Type not supported).
Supported).
A Bidirectional LSP Association cannot have both unidirectional LSPs A Bidirectional LSP Association cannot have both unidirectional LSPs
identified as Reverse LSPs or both LSPs identified as Forward LSPs. identified as reverse LSPs or both LSPs identified as forward LSPs.
If a PCE speaker receives an LSP not complying to this rule, the PCE 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 speaker MUST send PCErr with Error-Type = 26 (Association Error) and
Error-Value = TBD7 (Bidirectional LSP Association - Direction Error-value = 17 (Bidirectional LSP direction mismatch).
Mismatch).
A Bidirectional LSP Association cannot have one unidirectional LSP A Bidirectional LSP Association cannot have one unidirectional LSP
identified as co-routed and the other identified as non-co-routed. 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 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 speaker MUST send PCErr with Error-Type = 26 (Association Error) and
Error-Value = TBD8 (Bidirectional LSP Association - Co-routed Error-value = 18 (Bidirectional LSP co-routed mismatch).
Mismatch).
The unidirectional LSPs forming the Bidirectional LSP Association The unidirectional LSPs forming the Bidirectional LSP Association
MUST have matching endpoint nodes in the reverse directions. If a MUST have matching endpoint nodes in the reverse directions. If a
PCE speaker receives an LSP not complying to this rule, the PCE PCE speaker receives an LSP not complying to this rule, the PCE
speaker MUST send PCErr with Error-Type = 26 (Association Error) and speaker MUST send PCErr with Error-Type = 26 (Association Error) and
Error-Value = TBD9 (Bidirectional LSP Association - Endpoint Error-value = 19 (Endpoint mismatch in the association group).
Mismatch).
The processing rules as specified in Section 6.4 of [RFC8697] The processing rules as specified in Section 6.4 of [RFC8697]
continue to apply to the Association Types defined in this document. continue to apply to the Association Types defined in this document.
6. Implementation Status 6. Security Considerations
[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 The security considerations described in [RFC5440], [RFC8231], and
[RFC8281] apply to the extensions defined in this document as well. [RFC8281] apply to the extensions defined in this document as well.
Two new Association Types for the ASSOCIATION Object, Single-sided Two new Association Types for the ASSOCIATION object, Single-Sided
Bidirectional LSP Association and Double-sided Bidirectional LSP Bidirectional LSP Association and Double-Sided Bidirectional LSP
Association are introduced in this document. Additional security Association, are introduced in this document. Additional security
considerations related to LSP associations due to a malicious PCEP considerations related to LSP associations due to a malicious PCEP
speaker is described in [RFC8697] and apply to these Association speaker are described in [RFC8697] and apply to these Association
Types. Hence, securing the PCEP session using Transport Layer Types. Hence, securing the PCEP session using Transport Layer
Security (TLS) [RFC8253] is RECOMMENDED. Security (TLS) [RFC8253] is RECOMMENDED.
8. Manageability Considerations 7. Manageability Considerations
8.1. Control of Function and Policy 7.1. Control of Function and Policy
The mechanisms defined in this document do not imply any control or The mechanisms defined in this document do not imply any control or
policy requirements in addition to those already listed in [RFC5440], policy requirements in addition to those already listed in [RFC5440],
[RFC8231], and [RFC8281]. [RFC8231], and [RFC8281].
8.2. Information and Data Models 7.2. Information and Data Models
[RFC7420] describes the PCEP MIB, there are no new MIB Objects [RFC7420] describes the PCEP MIB; there are no new MIB objects
defined for LSP associations. defined for LSP associations.
The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data model for The PCEP YANG module [PCE-PCEP-YANG] defines a data model for LSP
LSP associations. associations.
8.3. Liveness Detection and Monitoring 7.3. Liveness Detection and Monitoring
The mechanisms defined in this document do not imply any new liveness The mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in [RFC5440], [RFC8231], and [RFC8281]. listed in [RFC5440], [RFC8231], and [RFC8281].
8.4. Verify Correct Operations 7.4. Verify Correct Operations
The mechanisms defined in this document do not imply any new The mechanisms defined in this document do not imply any new
operation verification requirements in addition to those already operation verification requirements in addition to those already
listed in [RFC5440], [RFC8231], and [RFC8281]. listed in [RFC5440], [RFC8231], and [RFC8281].
8.5. Requirements On Other Protocols 7.5. Requirements on Other Protocols
The mechanisms defined in this document do not add any new The mechanisms defined in this document do not add any new
requirements on other protocols. requirements on other protocols.
8.6. Impact On Network Operations 7.6. Impact on Network Operations
The mechanisms defined in this document do not have any impact on The mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in [RFC5440], network operations in addition to those already listed in [RFC5440],
[RFC8231], and [RFC8281]. [RFC8231], and [RFC8281].
9. IANA Considerations 8. IANA Considerations
9.1. Association Types
This document defines two new Association Types, originally described
in [RFC8697]. IANA is requested to assign the following new values
in the "ASSOCIATION Type Field" subregistry [RFC8697] within the
"Path Computation Element Protocol (PCEP) Numbers" registry:
Type Name Reference 8.1. Association Types
---------------------------------------------------------------------
TBD1 Single-sided Bidirectional LSP Association [This document]
TBD2 Double-sided Bidirectional LSP Association [This document]
9.2. Bidirectional LSP Association Group TLV This document defines two new Association Types [RFC8697]. IANA has
assigned the following new values in the "ASSOCIATION Type Field"
subregistry [RFC8697] within the "Path Computation Element Protocol
(PCEP) Numbers" registry:
This document defines a new TLV for carrying additional information +======+============================================+===========+
of LSPs within a Bidirectional LSP Association. IANA is requested to | Type | Name | Reference |
add the assignment of a new value in the existing "PCEP TLV Type +======+============================================+===========+
Indicators" registry as follows: | 4 | Single-Sided Bidirectional LSP Association | RFC 9059 |
+------+--------------------------------------------+-----------+
| 5 | Double-Sided Bidirectional LSP Association | RFC 9059 |
+------+--------------------------------------------+-----------+
Value Meaning Reference Table 1: Additions to ASSOCIATION Type Field Subregistry
-------------------------------------------------------------------
TBD3 Bidirectional LSP Association Group TLV [This document]
9.2.1. Flag Field in Bidirectional LSP Association Group TLV 8.2. Bidirectional LSP Association Group TLV
This document requests that a new sub-registry, named "Bidirectional This document defines a new TLV for carrying additional information
LSP Association Group TLV Flag Field", is created within the "Path about LSPs within a Bidirectional LSP Association. IANA has assigned
Computation Element Protocol (PCEP) Numbers" registry to manage the the following value in the "PCEP TLV Type Indicators" subregistry
Flag field in the Bidirectional LSP Association Group TLV. New within the "Path Computation Element Protocol (PCEP) Numbers"
values are to be assigned by Standards Action [RFC8126]. Each bit registry:
should be tracked with the following qualities:
o Bit number (count from 0 as the most significant bit) +=======+=========================================+===========+
| Value | Meaning | Reference |
+=======+=========================================+===========+
| 54 | Bidirectional LSP Association Group TLV | RFC 9059 |
+-------+-----------------------------------------+-----------+
o Description Table 2: Addition to PCEP TLV Type Indicators Subregistry
o Reference 8.2.1. Flag Field in Bidirectional LSP Association Group TLV
The following values are defined in this document for the Flag field. IANA has created a new subregistry, named "Bidirectional LSP
Association Group TLV Flag Field", within the "Path Computation
Element Protocol (PCEP) Numbers" registry to manage the Flag field in
the Bidirectional LSP Association Group TLV. New values are assigned
by Standards Action [RFC8126]. Each bit should be tracked with the
following qualities:
Bit No. Description Reference * Bit number (count from 0 as the most significant bit)
---------------------------------------------------------
31 R - Reverse LSP [This document]
30 C - Co-routed Path [This document]
0-29 Unassigned
9.3. PCEP Errors * Description
This document defines new Error value for Error Type 26 (Association * Reference
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 The initial contents of this registry are as follows:
---------------------------------------------------------
26 Association Error
Error value: TBD4 [This document] +======+====================+===========+
Bidirectional LSP Association - Group Mismatch | Bit | Description | Reference |
+======+====================+===========+
| 0-29 | Unassigned | |
+------+--------------------+-----------+
| 30 | C - Co-routed Path | RFC 9059 |
+------+--------------------+-----------+
| 31 | R - Reverse LSP | RFC 9059 |
+------+--------------------+-----------+
Error value: TBD5 [This document] Table 3: New Bidirectional LSP
Bidirectional LSP Association - Tunnel Mismatch Association Group TLV Flag Field
Subregistry
Error value: TBD6 [This document] 8.3. PCEP Errors
Bidirectional LSP Association - Path Setup Type
Not Supported
Error value: TBD7 [This document] This document defines new Error-values for Error-Type 26 (Association
Bidirectional LSP Association - Direction Mismatch Error). IANA has allocated the following new Error-values within the
"PCEP-ERROR Object Error Types and Values" subregistry of the "Path
Computation Element Protocol (PCEP) Numbers" registry:
Error value: TBD8 [This document] +============+=============+==========================+===========+
Bidirectional LSP Association - Co-routed Mismatch | Error-Type | Meaning | Error-value | Reference |
+============+=============+==========================+===========+
| 26 | Association | 14: Association group | RFC 9059 |
| | Error | mismatch | |
| | +--------------------------+-----------+
| | | 15: Tunnel mismatch in | RFC 9059 |
| | | the association group | |
| | +--------------------------+-----------+
| | | 16: Path Setup Type not | RFC 9059 |
| | | supported | |
| | +--------------------------+-----------+
| | | 17: Bidirectional LSP | RFC 9059 |
| | | direction mismatch | |
| | +--------------------------+-----------+
| | | 18: Bidirectional LSP | RFC 9059 |
| | | co-routed mismatch | |
| | +--------------------------+-----------+
| | | 19: Endpoint mismatch in | RFC 9059 |
| | | the association group | |
+------------+-------------+--------------------------+-----------+
Error value: TBD9 [This document] Table 4: Additions to PCEP-ERROR Object Error Types and Values
Bidirectional LSP Association - Endpoint Mismatch Subregistry
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 22, line 45 skipping to change at line 952
DOI 10.17487/RFC8537, February 2019, DOI 10.17487/RFC8537, February 2019,
<https://www.rfc-editor.org/info/rfc8537>. <https://www.rfc-editor.org/info/rfc8537>.
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>. <https://www.rfc-editor.org/info/rfc8697>.
10.2. Informative References 9.2. Informative References
[I-D.ietf-pce-pcep-stateful-pce-gmpls]
Lee, Y., Zheng, H., Dios, O., 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-14 (work in progress), December
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-15 (work in progress), October 2020.
[I-D.ietf-pce-sr-bidir-path] [BIDIR-PATH]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"Path Computation Element Communication Protocol (PCEP) "Path Computation Element Communication Protocol (PCEP)
Extensions for Associated Bidirectional Segment Routing Extensions for Associated Bidirectional Segment Routing
(SR) Paths", draft-ietf-pce-sr-bidir-path-05 (work in (SR) Paths", Work in Progress, Internet-Draft, draft-ietf-
progress), January 2021. pce-sr-bidir-path-05, 26 January 2021,
<https://tools.ietf.org/html/draft-ietf-pce-sr-bidir-path-
05>.
[PCE-PCEP-YANG]
Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura,
"A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-16, 22 February
2021,
<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-16>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654, Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <https://www.rfc-editor.org/info/rfc5654>. September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014, RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>. <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 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051, Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017, DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>. <https://www.rfc-editor.org/info/rfc8051>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>. July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[STATEFUL-PCE-GMPLS]
Lee, Y., Ed., Zheng, H., Ed., de Dios, O., Lopez, V., and
Z. Ali, "Path Computation Element (PCE) Protocol
Extensions for Stateful PCE Usage in GMPLS-controlled
Networks", Work in Progress, Internet-Draft, draft-ietf-
pce-pcep-stateful-pce-gmpls-14, 28 December 2020,
<https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-
pce-gmpls-14>.
Acknowledgments Acknowledgments
The authors would like to thank Dhruv Dhody for various discussions The authors would like to thank Dhruv Dhody for various discussions
on association groups and inputs to this document. The authors would on association groups and inputs to this document. The authors would
also like to thank Mike Taillon, Harish Sitaraman, Al Morton, and also like to thank Mike Taillon, Harish Sitaraman, Al Morton, and
Marina Fizgeer for reviewing this document and providing valuable Marina Fizgeer for reviewing this document and providing valuable
comments. The authors would like to thank the following IESG members comments. The authors would like to thank the following IESG members
for their review comments and suggestions: Barry Leiba, Eric Vyncke, for their review comments and suggestions: Barry Leiba, Éric Vyncke,
Benjamin Kaduk, Murray Kucherawy, Martin Duke, and Alvaro Retana. Benjamin Kaduk, Murray Kucherawy, Martin Duke, and Alvaro Retana.
Authors' Addresses Authors' Addresses
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Canada Canada
Email: rgandhi@cisco.com Email: rgandhi@cisco.com
 End of changes. 176 change blocks. 
448 lines changed or deleted 429 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/