draft-ietf-pce-association-bidir-04.txt   draft-ietf-pce-association-bidir-05.txt 
PCE Working Group R. Gandhi, Ed. PCE Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track C. Barth Intended status: Standards Track C. Barth
Expires: March 14, 2020 Juniper Networks Expires: August 7, 2020 Juniper Networks
B. Wen B. Wen
Comcast Comcast
September 11, 2019 February 4, 2020
PCEP Extensions for PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs)
Associated Bidirectional Label Switched Paths (LSPs) draft-ietf-pce-association-bidir-05
draft-ietf-pce-association-bidir-04
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE extensions allow stateful control of Multiprotocol The Stateful PCE extensions allow stateful control of Multiprotocol
Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
(LSPs) using PCEP. (LSPs) using PCEP.
This document defines PCEP extensions for grouping two reverse This document defines PCEP extensions for grouping two unidirectional
unidirectional MPLS TE LSPs into an Associated Bidirectional LSP when MPLS TE LSPs (one in each direction in the network) into an
using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as Associated Bidirectional LSP. The mechanisms defined in this
well as when using a Stateless PCE. The procedures defined are document can be applied using a Stateful PCE for both PCE-Initiated
applicable to the LSPs using Resource Reservation Protocol (RSVP) for and PCC-Initiated LSPs, as well as when using a Stateless PCE. The
signaling. procedures defined are applicable to the LSPs using Resource
Reservation Protocol (RSVP) for signaling.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5
3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 6 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 6
3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . . 7 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . 7
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8
4.1. Association Object . . . . . . . . . . . . . . . . . . . . 8 4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . 8
4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9
5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 10 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 10
5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 10
5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . . 11 5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 11
5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 11 5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 11
5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12
5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 12
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
6.1. Implementation . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Implementation . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Manageability Considerations . . . . . . . . . . . . . . . . . 14 8. Manageability Considerations . . . . . . . . . . . . . . . . 14
8.1. Control of Function and Policy . . . . . . . . . . . . . . 14 8.1. Control of Function and Policy . . . . . . . . . . . . . 14
8.2. Information and Data Models . . . . . . . . . . . . . . . 14 8.2. Information and Data Models . . . . . . . . . . . . . . . 14
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 14 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 14
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 14 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 14
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 14 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 14
8.6. Impact On Network Operations . . . . . . . . . . . . . . . 14 8.6. Impact On Network Operations . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. Association Types . . . . . . . . . . . . . . . . . . . . 14 9.1. Association Types . . . . . . . . . . . . . . . . . . . . 14
9.2. Bidirectional LSP Association Group TLV . . . . . . . . . 15 9.2. Bidirectional LSP Association Group TLV . . . . . . . . . 15
9.2.1. Flag Fields in Bidirectional LSP Association Group 9.2.1. Flag Fields in Bidirectional LSP Association Group
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 15 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 15 9.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP) as a [RFC5440] describes the Path Computation Element Protocol (PCEP) as a
communication mechanism between a Path Computation Client (PCC) and a communication mechanism between a Path Computation Client (PCC) and a
Path Control Element (PCE), or between PCE and PCC, that enables Path Control Element (PCE), or between PCE and PCC, that enables
computation of Multiprotocol Label Switching (MPLS) Traffic computation of Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Label Switched Paths (LSPs). Engineering (TE) Label Switched Paths (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.
[I-D.ietf-pce-association] introduces a generic mechanism to create a [RFC8697] introduces a generic mechanism to create a grouping of LSPs
grouping of LSPs which can then be used to define associations which can then be used to define associations between a set of LSPs
between a set of LSPs and/or a set of attributes, for example primary and/or a set of attributes, for example primary and secondary LSP
and secondary LSP associations, and is equally applicable to the associations, and is equally applicable to the active and passive
active and passive modes of a Stateful PCE [RFC8231] or a stateless modes of a Stateful PCE [RFC8231] or a stateless PCE [RFC5440].
PCE [RFC5440].
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]
specifies that MPLS-TP MUST support associated bidirectional specifies that MPLS-TP MUST support associated bidirectional point-
point-to-point LSPs. [RFC7551] defines RSVP signaling extensions for to-point LSPs. [RFC7551] defines RSVP signaling extensions for
binding two reverse unidirectional LSPs [RFC3209] into an associated binding two reverse unidirectional LSPs [RFC3209] 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 reverse This document defines PCEP extensions for grouping two unidirectional
unidirectional MPLS-TE LSPs into an Associated Bidirectional LSP for MPLS-TE LSPs into an Associated Bidirectional LSP for both single-
both single-sided and double-sided initiation cases when using a sided and double-sided initiation cases when using a Stateful PCE for
Stateful (both active and passive modes) or Stateless PCE. The both PCE-Initiated and PCC-Initiated LSPs as well as when using a
procedures defined are applicable to the LSPs using Resource Stateless PCE. The procedures defined are applicable to the LSPs
Reservation Protocol (RSVP) for signaling [RFC3209]. The PCEP using Resource Reservation Protocol (RSVP) for signaling [RFC3209].
extensions cover the following cases: The PCEP extensions cover the following cases:
o A PCC initiates the forward and/ or reverse LSP of a single-sided o A PCC initiates the forward and/ or reverse LSP of a single-sided
or double-sided bidirectional LSP and retains the control of the or double-sided bidirectional LSP and retains the control of the
LSP. The PCC computes the path itself or makes a request for path LSP. The PCC computes the path itself or makes a request for path
computation to a PCE. After the path setup, it reports the computation to a PCE. After the path setup, it reports the
information and state of the path to the PCE. This includes the information and state of the path to the PCE. This includes the
association group identifying the bidirectional LSP. This is the association group identifying the bidirectional LSP. This is the
Passive Stateful mode defined in [RFC8051]. Passive Stateful mode defined in [RFC8051].
o A PCC initiates the forward and/ or reverse LSP of a single-sided o A PCC initiates the forward and/ or reverse LSP of a single-sided
skipping to change at page 4, line 45 skipping to change at page 4, line 45
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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 [I-D.ietf-pce-association]. [RFC5440], [RFC7551], [RFC8231], and [RFC8697].
3. Overview 3. Overview
As shown in Figure 1, two reverse unidirectional LSPs can be grouped As shown in Figure 1, two reverse unidirectional LSPs can be grouped
to form an associated bidirectional LSP. There are two methods of to form an associated bidirectional LSP. There are two methods of
initiating the bidirectional LSP association, single-sided and initiating the bidirectional LSP association, single-sided and
double-sided, as defined in [RFC7551] and described in the following double-sided, as defined in [RFC7551] and described in the following
sections. sections.
LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 -->
skipping to change at page 5, line 20 skipping to change at page 5, line 19
| 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 forward and reverse LSPs of this tunnel are of the tunnel. Both forward and reverse LSPs of this tunnel are
initiated with the Association Type set to "Single-sided initiated with the Association Type set to "Single-sided
Bidirectional LSP Association" on the originating endpoint node. The Bidirectional LSP Association" on the originating endpoint node. The
forward and reverse LSPs are identified in the Bidirectional LSP forward and reverse LSPs are identified in the Bidirectional LSP
Association Group TLV of their PCEP Association Objects. Association Group TLV of their PCEP ASSOCIATION Objects.
The originating endpoint node signals the properties for the revere The originating endpoint node signals the properties for the revere
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 then creates the corresponding reverse message. The remote endpoint then creates the corresponding reverse
tunnel and signals the reverse LSP in response to the received RSVP tunnel and signals the reverse LSP in response to the received RSVP
Path message. Similarly, the remote endpoint node deletes the Path message. Similarly, the remote endpoint node deletes the
reverse LSP when it receives the RSVP Path delete message [RFC3209] reverse LSP when it receives the RSVP Path delete message [RFC3209]
for the forward LSP. for the forward LSP.
The originating endpoint (PCC) node may report/ delegate the forward The originating endpoint (PCC) node may report/ delegate the forward
skipping to change at page 6, line 7 skipping to change at page 6, line 16
| PCE | | PCE |
+-----+ +-----+
Initiates: | ^ Reports: Initiates: | ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F), LSP2 (R)) | \ (LSP2 (F)) (LSP1 (F), LSP2 (R)) | \ (LSP2 (F))
Association #1 v \ Association #1 Association #1 v \ Association #1
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Figure 2A: Example of PCE-Initiated Single-sided Bidirectional LSP Figure 2: Example of PCE-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), LSP2 (R)) | \ (LSP2 (F)) (LSP1 (F), LSP2 (R)) | \ (LSP2 (F))
Association #2 | \ Association #2 Association #2 | \ Association #2
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Figure 2B: Example of PCC-Initiated Single-sided Bidirectional LSP Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP
As shown in Figures 2A and 2B, the forward tunnel and both forward As shown in Figures 2 and 3, the forward tunnel and both forward LSP1
LSP1 and reverse LSP2 are initiated on the originating endpoint node and reverse LSP2 are initiated on the originating endpoint node A,
A, either by the PCE or the originating PCC, respectively. The either by the PCE or the originating PCC, respectively. The
originating endpoint node A signals the properties of reverse LSP2 in originating endpoint node A signals the properties of reverse LSP2 in
the RSVP REVERSE_LSP Object in the Path message of the forward LSP1. the RSVP REVERSE_LSP Object in the Path message of the forward LSP1.
The creation of reverse tunnel and reverse LSP2 on the remote The creation of reverse tunnel and reverse LSP2 on the remote
endpoint node D is triggered by the RSVP signaled forward LSP1. endpoint node D is triggered by the RSVP signaled forward LSP1.
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 node is identified as the the LSP starting from the originating node is identified as the
forward LSP of the single-sided initiated bidirectional LSP. forward LSP of the single-sided initiated bidirectional LSP.
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.
The endpoint (PCC) nodes may report/ delegate the forward and reverse The endpoint (PCC) nodes may report/ delegate the forward and reverse
direction LSPs to a PCE. direction LSPs to a PCE.
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Initiates: | \ Initiates: Initiates: | \ Initiates:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F)) | \ (LSP2 (F)) (LSP1 (F)) | \ (LSP2 (F))
Association #3 v v Association #3 Association #3 v v Association #3
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Figure 3A: Example of PCE-Initiated Double-sided Bidirectional LSP Figure 4: Example of PCE-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)) | \ (LSP2 (F)) (LSP1 (F)) | \ (LSP2 (F))
Association #4 | \ Association #4 Association #4 | \ Association #4
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Figure 3B: Example of PCC-Initiated Double-sided Bidirectional LSP Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP
As shown in Figures 3A and 3B, the forward tunnel and forward LSP1 As shown in Figures 4 and 5, the forward tunnel and forward LSP1 are
are initiated on the endpoint node A and the reverse tunnel and initiated on the endpoint node A and the reverse tunnel and reverse
reverse LSP2 are initiated on the endpoint node D, either by the PCE LSP2 are initiated on the endpoint node D, either by the PCE or the
or the PCCs, respectively. PCCs, respectively.
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.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 may be co-routed as shown in Figure 4, where both reverse LSPs may 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 4: Example of Co-routed Associated Bidirectional LSP Figure 6: Example of Co-routed Associated Bidirectional LSP
4. Protocol Extensions 4. Protocol Extensions
4.1. Association Object 4.1. ASSOCIATION Object
As per [I-D.ietf-pce-association], LSPs are associated by adding them As per [RFC8697], LSPs are associated by adding them to a common
to a common association group. This document defines two new association group. This document defines two new Bidirectional LSP
Bidirectional LSP Association Groups to be used by the associated Association Groups to be used by the associated bidirectional LSPs.
bidirectional LSPs. A member of the Bidirectional LSP Association A member of the Bidirectional LSP Association Group can take the role
Group can take the role of a forward or reverse LSP and follows the of a forward or reverse LSP and follows the following rules:
following rules:
o An LSP (forward or reverse) can not be part of more than one o An LSP (forward or reverse) can not be part of more than one
Bidirectional LSP Association Group. More than one forward LSP Bidirectional LSP Association Group. More than one forward LSP
and/ or reverse LSP can be part of a Bidirectional LSP Association and/ or reverse LSP can be part of a Bidirectional LSP Association
Group. Group.
o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs
of the single-sided bidirectional LSP association on the of the Single-sided Bidirectional LSP Association on the
originating node MUST be the same. originating node MUST be the same.
This document defines two new Association Types for the Association This document defines two new Association Types for the ASSOCIATION
Object as follows: Object (Object-Class value 40) as follows:
o Association Type (TBD1) = Single-sided Bidirectional LSP o Association Type (TBD1) = Single-sided Bidirectional LSP
Association Group Association Group
o Association Type (TBD2) = Double-sided Bidirectional LSP o Association Type (TBD2) = Double-sided Bidirectional LSP
Association Group Association Group
These Association Types are operator-configured associations in These Association Types are operator-configured associations in
nature and statically created by the operator on the PCEP peers. The nature and statically created by the operator on the PCEP peers. The
LSP belonging to these associations is conveyed via PCEP messages to LSP belonging to these associations is conveyed via PCEP messages to
the PCEP peer. Operator-configured Association Range TLV the PCEP peer. Operator-configured Association Range TLV (Value 29)
[I-D.ietf-pce-association] MUST NOT be sent for these Association [RFC8697] MUST NOT be sent for these Association Types, and MUST be
Types, and MUST be ignored, so that the entire range of association ignored, so that the entire range of association ID can be used for
ID can be used for them. them.
The Association ID, Association Source, optional Global Association The Association ID, Association Source, optional Global Association
Source and optional Extended Association ID in the Bidirectional LSP Source and optional Extended Association ID in the Bidirectional LSP
Association Group Object are initialized using the procedures defined Association Group Object are initialized using the procedures defined
in [I-D.ietf-pce-association] and [RFC7551]. in [RFC8697] and [RFC7551].
4.2. Bidirectional LSP Association Group TLV 4.2. Bidirectional LSP Association Group TLV
The Bidirectional LSP Association Group TLV is defined for use with The Bidirectional LSP Association Group TLV is defined for use with
the Single-sided and Double-sided Bidirectional LSP Association Group the Single-sided and Double-sided Bidirectional LSP Association Group
Object Types. Object Types.
o The Bidirectional LSP Association Group TLV follows the PCEP TLV o The Bidirectional LSP Association Group TLV follows the PCEP TLV
format from [RFC5440]. format from [RFC5440].
skipping to change at page 9, line 37 skipping to change at page 9, line 34
o For co-routed LSPs, this TLV MUST be present. o For co-routed LSPs, this TLV MUST be present.
o For reverse LSPs, this TLV MUST be present. o For reverse LSPs, this TLV MUST be present.
o The Bidirectional LSP Association Group TLV MUST NOT be present o 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 in The format of the Bidirectional LSP Association Group TLV is shown in
Figure 5: 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 = TBD3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C|R|F| | Reserved |C|R|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Bidirectional LSP Association Group TLV format Figure 7: Bidirectional LSP Association Group TLV format
Bidirectional LSP Association Flags are defined as following. Bidirectional LSP Association Flags are defined as following.
F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the
forward LSP of the bidirectional LSP. If this flag is set, the LSP forward LSP of the bidirectional LSP. If this flag is set, the LSP
is a forward LSP. is a forward LSP.
R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the
reverse LSP of the bidirectional LSP. If this flag is set, the LSP reverse LSP of the bidirectional LSP. If this flag is set, the LSP
is a reverse LSP. is a reverse LSP.
C (Co-routed LSP, 1 bit) - Indicates whether the bidirectional LSP is C (Co-routed Path, 1 bit) - Indicates whether the bidirectional LSP
co-routed. This flag MUST be set for both the forward and reverse is co-routed. This flag MUST be set for both the forward and reverse
LSPs of a co-routed bidirectional LSP. 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 (for both Stateful and Stateless) to
compute bidirectional paths of the forward and reverse LSPs of a compute bidirectional paths of the forward and reverse LSPs of a co-
co-routed bidirectional LSP. routed bidirectional LSP.
The Reserved flags MUST be set to 0 when sent and MUST be ignored The Reserved flags MUST be set to 0 when sent and MUST be ignored
when received. when received.
5. PCEP Procedure 5. PCEP Procedure
5.1. PCE Initiated LSPs 5.1. PCE Initiated LSPs
As specified in [I-D.ietf-pce-association], the Bidirectional LSP As specified in [RFC8697], the Bidirectional LSP Association Groups
Association Groups can be created by a Stateful PCE. can be created by a Stateful PCE.
o Stateful PCE can create and update the forward and reverse LSPs o Stateful PCE can create and update the forward and reverse LSPs
independently for both single-sided and double-sided bidirectional independently for both Single-sided and Double-sided Bidirectional
LSP association groups. LSP Association Groups.
o Stateful PCE can establish and remove the association relationship o Stateful PCE can establish and remove the association relationship
on a per LSP basis. on a per LSP basis.
o Stateful PCE can create and update the LSP and the association on o Stateful PCE can create and update the LSP and the association on
a PCC via PCInitiate and PCUpd messages, respectively, using the a PCC via PCInitiate and PCUpd messages, respectively, using the
procedures described in [I-D.ietf-pce-association]. procedures described in [RFC8697].
5.2. PCC Initiated LSPs 5.2. PCC Initiated LSPs
As specified in [I-D.ietf-pce-association], Bidirectional LSP As specified in [RFC8697], Bidirectional LSP Association Groups can
Association Groups can also be created by a PCC. also be created by a PCC.
o PCC can create and update the forward and reverse LSPs o PCC can create and update the forward and reverse LSPs
independently for both single-sided and double-sided bidirectional independently for both Single-sided and Double-sided Bidirectional
LSP association groups. LSP Association Groups.
o PCC can establish and remove the association relationship on a per o PCC can establish and remove the association relationship on a per
LSP basis. LSP basis.
o PCC MUST report the change in the association group of an LSP to o PCC MUST report the change in the association group of an LSP to
PCE(s) via PCRpt message. PCE(s) via PCRpt message.
o PCC can report the forward and reverse LSPs independently to o PCC can report the forward and reverse LSPs independently to
PCE(s) via PCRpt message. PCE(s) via PCRpt message.
o PCC can delegate the forward and reverse LSPs independently to a o PCC can delegate the forward and reverse LSPs independently to a
Stateful PCE, where PCE would control the LSPs. For single-sided Stateful PCE, where PCE would control the LSPs. For single-sided
case, originating (PCC) node can delegate both forward and reverse case, originating (PCC) node can delegate both forward and reverse
LSPs of a tunnel together to a Stateful PCE in order to avoid any LSPs of a tunnel together to a Stateful PCE in order to avoid any
race condition. race condition.
o Stateful PCE can update the LSPs in the bidirectional LSP o Stateful PCE can update the LSPs in the Bidirectional LSP
association group via PCUpd message, using the procedures Association Group via PCUpd message, using the procedures
described in [I-D.ietf-pce-association]. 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. A PCC can request co-routed or non co-routed forward the request. A PCC can request co-routed or non co-routed forward
and reverse direction paths from a stateless PCE for a bidirectional and reverse direction paths from a stateless PCE for a Bidirectional
LSP association group. LSP Association Group.
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 (e.g. latency) in each direction. For an associated requirements (e.g. latency) in each direction. For an associated
bidirectional LSP, the B-flag MAY be set when the PCC makes the path bidirectional LSP, the B-flag MAY be set when the PCC makes the path
computation request for the same TE requirements in the forward and computation request for the same TE requirements in the forward and
reverse directions. When a stateful PCE initiates or updates the reverse directions. When a stateful PCE initiates or updates the
bidirectional LSPs, the B-flag in Stateful PCE Request Parameters bidirectional LSPs, the B-flag in Stateful PCE Request Parameters
(SRP) object [RFC8231] MAY also be set. (SRP) object [RFC8231] MAY also be set.
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 each LSP and is constant for created by a PCC to uniquely identify an LSP and it remains the same
the lifetime of a PCEP session. for the lifetime of a PCEP session.
In case of single-sided bidirectional LSP association, the reverse
LSP of a bidirectional LSP on the originating node is identified
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 on the
originating node will have a PLSP-ID A at the ingress node while it
will have a PLSP-ID B at the egress node. This is not the case for
the forward LSP of the single-sided bidirectional LSP on the
originating node and there is no change in the PLSP-ID allocation for
it.
In case of double-sided bidirectional LSP association, there is no In case of Single-sided Bidirectional LSP Association, the reverse
change in the PLSP-ID allocation. LSP of a bidirectional LSP created on the originating 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 on the originating node will have a PLSP-ID A at the
ingress node while it will have a PLSP-ID B at the egress node. This
is not the case for the forward LSP of the Single-sided Bidirectional
LSP on the originating node and there is no change in the PLSP-ID
allocation procedure for it. 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] For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231]
MUST be included in all forward and reverse LSPs. 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 association groups to the Stateful PCE as per Bidirectional LSP Association Groups to the Stateful PCE as per
[I-D.ietf-pce-association]. After the state synchronization, the PCE [RFC8697]. After the state synchronization, the PCE MUST remove all
MUST remove all stale bidirectional LSP associations. stale Bidirectional LSP Associations.
5.7. Error Handling 5.7. Error Handling
An LSP (forward or reverse) can not be part of more than one An LSP (forward or reverse) can not be part of more than one
Bidirectional LSP Association Group. If a PCE attempts to add an LSP Bidirectional LSP Association Group. If a PCE attempts to add an LSP
not complying to this rule, the PCC MUST send PCErr with Error-Type = not complying to this rule, the PCC MUST send PCErr with Error-Type =
29 (Early allocation by IANA) (Association Error) and Error-Value = 26 (Association Error) and Error-Value = TBD4 (Bidirectional LSP
TBD4 (Bidirectional LSP Association - Group Mismatch). Similarly, if Association - Group Mismatch). Similarly, if a PCC attempts to add
a PCC attempts to add an LSP at PCE not complying to this rule, the an LSP at PCE not complying to this rule, the PCE MUST send this
PCE MUST send this PCErr. PCErr.
The LSPs (forward or reverse) in a single-sided bidirectional LSP The LSPs (forward or reverse) in a Single-sided Bidirectional
association group MUST belong to the same TE Tunnel (as defined in 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 [RFC3209]). If a PCE attempts to add an LSP in a Single-sided
bidirectional LSP association group for a different Tunnel, the PCC Bidirectional LSP Association Group for a different Tunnel, the PCC
MUST send PCErr with Error-Type = 29 (Early allocation by IANA) MUST send PCErr with Error-Type = 26 (Association Error) and Error-
(Association Error) and Error-Value = TBD5 (Bidirectional LSP Value = TBD5 (Bidirectional Association - Tunnel Mismatch).
Association - Tunnel Mismatch). Similarly, if a PCC attempts to add Similarly, if a PCC attempts to add an LSP to a Single-sided
an LSP to a single-sided bidirectional LSP association group at PCE Bidirectional LSP Association Group at PCE not complying to this
not complying to this rule, the PCE MUST send this PCErr. rule, the PCE MUST send this PCErr.
The PCEP Path Setup Type (PST) MUST be set to 'Path is set up using The PCEP Path Setup Type (PST) MUST be set to 'Path is set up using
the RSVP-TE signaling protocol' (Value 0) [RFC8408] for the LSP the RSVP-TE signaling protocol' (Value 0) [RFC8408] for the LSP
belonging to the Bidirectional LSP Association Groups defined in this belonging to the Bidirectional LSP Association Groups defined in this
document. In case a PCEP speaker receives a different PST value for document. In case a PCEP speaker receives a different PST value for
this association group, it MUST return a PCErr message with Error- this association group, it MUST return a PCErr message with Error-
Type = 29 (Early allocation by IANA) (Association Error) and Error- Type = 26 (Association Error) and Error-Value = TBD6 (Bidirectional
Value = TBD6 (Bidirectional LSP Association - Path Setup Type LSP Association - Path Setup Type Mismatch).
Mismatch).
The processing rules as specified in Section 5.4 of The processing rules as specified in Section 6.4 of [RFC8697]
[I-D.ietf-pce-association] continue to apply for the Association continue to apply to the Association Types defined in this document.
Types defined in this document.
6. Implementation Status 6. Implementation Status
[Note to the RFC Editor - remove this section before publication, as [Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.] well as remove the reference to RFC 7942.]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
skipping to change at page 13, line 45 skipping to change at page 13, line 41
The PCEP extensions defined in this document has been implemented by The PCEP extensions defined in this document has been implemented by
a vendor on their product. No further information is available at a vendor on their product. No further information is available at
this time. this time.
7. Security Considerations 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 Group and Double-sided Associated Bidirectional LSP Association Group and Double-sided Bidirectional
Bidirectional LSP Group are introduced in this document. Additional LSP Association Group are introduced in this document. Additional
security considerations related to LSP associations due to a security considerations related to LSP associations due to a
malicious PCEP speaker is described in [I-D.ietf-pce-association] and malicious PCEP speaker is described in [RFC8697] and apply to these
apply to these Association Types. Hence, securing the PCEP session Association Types. Hence, securing the PCEP session using Transport
using Transport Layer Security (TLS) [RFC8253] is recommended. Layer Security (TLS) [RFC8253] is recommended.
8. Manageability Considerations 8. Manageability Considerations
8.1. Control of Function and Policy 8.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 8.2. Information and Data Models
skipping to change at page 14, line 49 skipping to change at page 14, line 48
8.6. Impact On Network Operations 8.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 9. IANA Considerations
9.1. Association Types 9.1. Association Types
This document adds new Association Types for the Association Object This document adds new Association Types for the ASSOCIATION Object
defined [I-D.ietf-pce-association]. IANA is requested to make the (Object-class value 40) defined [RFC8697]. IANA is requested to make
assignment of values for the sub-registry "ASSOCIATION Type Field" the assignment of values for the sub-registry "ASSOCIATION Type
(to be created in [I-D.ietf-pce-association]), as follows: Field" [RFC8697], as follows:
Value Name Reference Type Name Reference
--------------------------------------------------------------------- ---------------------------------------------------------------------
TBD1 Single-sided Bidirectional LSP Association Group [This document] TBD1 Single-sided Bidirectional LSP Association Group [This document]
TBD2 Double-sided Bidirectional LSP Association Group [This document] TBD2 Double-sided Bidirectional LSP Association Group [This document]
9.2. Bidirectional LSP Association Group TLV 9.2. Bidirectional LSP Association Group TLV
This document defines a new TLV for carrying additional information This document defines a new TLV for carrying additional information
of LSPs within a Bidirectional LSP Association Group. IANA is of LSPs within a Bidirectional LSP Association Group. IANA is
requested to add the assignment of a new value in the existing "PCEP requested to add the assignment of a new value in the existing "PCEP
TLV Type Indicators" registry as follows: TLV Type Indicators" registry as follows:
TLV-Type Name Reference Value Meaning Reference
------------------------------------------------------------------- -------------------------------------------------------------------
TBD3 Bidirectional LSP Association Group TLV [This document] TBD3 Bidirectional LSP Association Group TLV [This document]
9.2.1. Flag Fields in Bidirectional LSP Association Group TLV 9.2.1. Flag Fields in Bidirectional LSP Association Group TLV
This document requests that a new sub-registry, named "Bidirectional This document requests that a new sub-registry, named "Bidirectional
LSP Association Group TLV Flag Field", is created within the "Path LSP Association Group TLV Flag Field", is created within the "Path
Computation Element Protocol (PCEP) Numbers" registry to manage the Computation Element Protocol (PCEP) Numbers" registry to manage the
Flag field in the Bidirectional LSP Association Group TLV. New Flag field in the Bidirectional LSP Association Group TLV. New
values are to be assigned by Standards Action [RFC8126]. Each bit values are to be assigned by Standards Action [RFC8126]. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (count from 0 as the most significant bit) o Bit number (count from 0 as the most significant bit)
o Description o Description
o Reference o Reference
The following values are defined in this document for the Flag field. The following values are defined in this document for the Flag field.
Bit No. Description Reference Bit No. Description Reference
--------------------------------------------------------- ---------------------------------------------------------
31 F - Forward LSP [This document] 31 F - Forward LSP [This document]
30 R - Reverse LSP [This document] 30 R - Reverse LSP [This document]
29 C - Co-routed LSP [This document] 29 C - Co-routed Path [This document]
9.3. PCEP Errors 9.3. PCEP Errors
This document defines new Error value for Error Type 29 (Association This document defines new Error value for Error Type 26 (Association
Error). IANA is requested to allocate new Error value within the Error). IANA is requested to allocate new Error value within the
"PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP
Numbers registry, as follows: Numbers registry, as follows:
Error Type Description Reference Error Type Description Reference
--------------------------------------------------------------------- ---------------------------------------------------------
29 Association Error 26 Association Error
Error value: TBD4 [This document] Error value: TBD4 [This document]
Bidirectional LSP Association - Group Mismatch Bidirectional LSP Association - Group Mismatch
Error value: TBD5 [This document] Error value: TBD5 [This document]
Bidirectional LSP Association - Tunnel Mismatch Bidirectional LSP Association - Tunnel Mismatch
Error value: TBD6 [This document] Error value: TBD6 [This document]
Bidirectional LSP Association - Path Setup Type Mismatch Bidirectional LSP Association - Path Setup Type Mismatch
10. References 10. References
10.1. Normative References 10.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, DOI Requirement Levels", BCP 14, RFC 2119,
10.17487/RFC2119, March 1997. DOI 10.17487/RFC2119, March 1997,
<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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. 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 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional LSPs", RFC 7551, Extensions for Associated Bidirectional Label Switched
May 2015. 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 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017. 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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, DOI Extensions for Stateful PCE", RFC 8231,
10.17487/RFC8231, September 2017. DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Extensions for PCE-initiated LSP Setup in a Stateful PCE Computation Element Communication Protocol (PCEP)
Model", RFC 8281, December 2017. 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 [RFC8537] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to
the Fast Reroute Procedures for Co-routed Associated the Fast Reroute Procedures for Co-routed Associated
Bidirectional Label Switched Paths (LSPs)", RFC 8537, Bidirectional Label Switched Paths (LSPs)", RFC 8537,
February 2019. DOI 10.17487/RFC8537, February 2019,
<https://www.rfc-editor.org/info/rfc8537>.
[I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S., [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "PCEP Dhody, D., and Y. Tanaka, "Path Computation Element
Extensions for Establishing Relationships Between Sets of Communication Protocol (PCEP) Extensions for Establishing
LSPs", draft-ietf-pce-association-group (work in Relationships between Sets of Label Switched Paths
progress). (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>.
10.2. Informative References 10.2. Informative References
[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-13 (work in progress), October 2019.
[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, September 2009. 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. [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", RFC (PCEP) Management Information Base (MIB) Module",
7420, December 2014. 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 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, RFC Code: The Implementation Status Section", BCP 205,
7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc- RFC 7942, DOI 10.17487/RFC7942, July 2016,
editor.org/info/rfc7942>. <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,
January 2017. DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8253] Lopez, D., 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, October 2017.
[RFC8408] Sivabalan, S., et al. "Conveying Path Setup Type in PCE [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
Communication Protocol (PCEP) Messages", RFC 8408, July "PCEPS: Usage of TLS to Provide a Secure Transport for the
2018. Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Tantsura, "A YANG Data Model for Path Computation Element Hardwick, "Conveying Path Setup Type in PCE Communication
Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
(work in progress). July 2018, <https://www.rfc-editor.org/info/rfc8408>.
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 Dhruv Dhody, Mike Taillon, and Marina Fizgeer for also like to thank Dhruv Dhody, Mike Taillon, and Marina Fizgeer for
reviewing this document and providing valuable comments. reviewing this document and providing valuable comments.
Authors' Addresses Authors' Addresses
 End of changes. 83 change blocks. 
223 lines changed or deleted 236 lines changed or added

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