draft-ietf-pce-association-bidir-02.txt   draft-ietf-pce-association-bidir-03.txt 
PCE Working Group C. Barth PCE Working Group R. Gandhi, Ed.
Internet-Draft Juniper Networks Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track R. Gandhi, Ed. Intended status: Standards Track C. Barth
Expires: May 18, 2019 Cisco Systems, Inc. Expires: September 12, 2019 Juniper Networks
B. Wen B. Wen
Comcast Comcast
November 14, 2018 March 11, 2019
PCEP Extensions for PCEP Extensions for
Associated Bidirectional Label Switched Paths (LSPs) Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-pce-association-bidir-02 draft-ietf-pce-association-bidir-03
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 reverse
unidirectional MPLS TE LSPs into an Associated Bidirectional LSP when unidirectional MPLS TE LSPs into an Associated Bidirectional LSP when
using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as
well as when using a Stateless PCE. well as when using a Stateless PCE. The 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 http://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."
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 (http://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
skipping to change at page 2, line 33 skipping to change at page 2, line 34
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. State Synchronization . . . . . . . . . . . . . . . . . . 11 5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 11
5.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12
7. Manageability Considerations . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Control of Function and Policy . . . . . . . . . . . . . . 12 7. Manageability Considerations . . . . . . . . . . . . . . . . . 13
7.2. Information and Data Models . . . . . . . . . . . . . . . 12 7.1. Control of Function and Policy . . . . . . . . . . . . . . 13
7.2. Information and Data Models . . . . . . . . . . . . . . . 13
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 13 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 13
7.6. Impact On Network Operations . . . . . . . . . . . . . . . 13 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Association Types . . . . . . . . . . . . . . . . . . . . 13 8.1. Association Types . . . . . . . . . . . . . . . . . . . . 14
8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 13 8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 14
8.2.1. Flag Fields in Bidirectional LSP Association Group 8.2.1. Flag Fields in Bidirectional LSP Association Group
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 14 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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
skipping to change at page 3, line 34 skipping to change at page 3, line 37
between a set of LSPs and/or a set of attributes, for example primary between a set of LSPs and/or a set of attributes, for example primary
and secondary LSP associations, and is equally applicable to the and secondary LSP associations, and is equally applicable to the
active and passive modes of a Stateful PCE [RFC8231] or a stateless active and passive 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-to-point LSPs. [RFC7551] defines RSVP signaling extensions for point-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 bidirectional LSPs are described in [RFC8537].
[I-D.ietf-teas-assoc-corouted-bidir-frr].
This document specifies PCEP extensions for grouping two reverse This document defines PCEP extensions for grouping two reverse
unidirectional MPLS-TE LSPs into an Associated Bidirectional LSP for unidirectional MPLS-TE LSPs into an Associated Bidirectional LSP for
both single-sided and double-sided initiation cases when using a both single-sided and double-sided initiation cases when using a
Stateful (both active and passive modes) or Stateless PCE. The PCEP Stateful (both active and passive modes) or Stateless PCE. The
procedures defined are applicable to the LSPs using Resource
Reservation Protocol (RSVP) for signaling [RFC3209]. The PCEP
extensions cover the following cases: 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].
skipping to change at page 4, line 39 skipping to change at page 4, line 42
"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 [I-D.ietf-pce-association].
The term forward and reverse direction of an LSP is from the view
point of a PCE.
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 38 skipping to change at page 5, line 38
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
and reverse LSPs to a PCE. The remote endpoint (PCC) node may report and reverse direction LSPs to a PCE. The remote endpoint (PCC) node
the reverse LSP to a PCE. may report its forward direction LSP to a PCE.
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Initiates: | ^ Reports: Initiates: | ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (R) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F), LSP2 (R)) | \ (LSP2 (R)) (LSP1 (F), LSP2 (R)) | \ (LSP2 (F))
v \ Association #1 v \ Association #1
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Figure 2A: Example of PCE-Initiated Single-sided Bidirectional LSP Figure 2A: Example of PCE-Initiated Single-sided Bidirectional LSP
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Reports/Delegates: ^ ^ Reports: Reports/Delegates: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (R) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F), LSP2 (R)) | \ (LSP2 (R)) (LSP1 (F), LSP2 (R)) | \ (LSP2 (F))
| \ Association #2 | \ Association #2
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Figure 2B: Example of PCC-Initiated Single-sided Bidirectional LSP Figure 2B: 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 2A and 2B, the forward tunnel and both forward
LSP1 and reverse LSP2 are initiated on the originating endpoint node LSP1 and reverse LSP2 are initiated on the originating endpoint node
A, either by the PCE or the originating PCC. The originating A, either by the PCE or the originating PCC, respectively. The
endpoint node A signals the properties of reverse LSP2 in the RSVP originating endpoint node A signals the properties of reverse LSP2 in
REVERSE_LSP Object in the Path message of the forward LSP1. The the RSVP REVERSE_LSP Object in the Path message of the forward LSP1.
creation of reverse tunnel and reverse LSP2 on the remote endpoint The creation of reverse tunnel and reverse LSP2 on the remote
node D is triggered by the RSVP signaled forward LSP1. endpoint node D is triggered by the RSVP signaled forward LSP1.
As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast As specified in [RFC8537], for fast reroute bypass tunnel assignment,
reroute bypass tunnel assignment, the LSP starting from the the LSP starting from the originating node is identified as the
originating node is identified as the forward LSP of the single-sided forward LSP of the single-sided initiated bidirectional LSP.
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
LSPs to a PCE. direction LSPs to a PCE.
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Initiates: | \ Initiates: Initiates: | \ Initiates:
Tunnel 1 (F) | \ Tunnel 2 (R) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F)) | \ (LSP2 (R)) (LSP1 (F)) | \ (LSP2 (F))
v v Association #3 v v Association #3
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Figure 3A: Example of PCE-Initiated Double-sided Bidirectional LSP Figure 3A: Example of PCE-Initiated Double-sided Bidirectional LSP
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Reports/Delegates: ^ ^ Reports/Delegates: Reports/Delegates: ^ ^ Reports/Delegates:
Tunnel 1 (F) | \ Tunnel 2 (R) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F)) | \ (LSP2 (R)) (LSP1 (F)) | \ (LSP2 (F))
| \ Association #4 | \ Association #4
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Figure 3B: Example of PCC-Initiated Double-sided Bidirectional LSP Figure 3B: 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 3A and 3B, the forward tunnel and forward LSP1
are initiated on the endpoint node A and the reverse tunnel and are initiated on the endpoint node A and the reverse tunnel and
reverse LSP2 are initiated on the endpoint node D, either by the PCE reverse LSP2 are initiated on the endpoint node D, either by the PCE
or the PCCs. or the PCCs, respectively.
As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast As specified in [RFC8537], for fast reroute bypass tunnel assignment,
reroute bypass tunnel assignment, the LSP with the higher Source the LSP with the higher Source Address [RFC3209] is identified as the
Address [RFC3209] is identified as the forward LSP of the forward LSP of the double-sided initiated bidirectional LSP.
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 4, 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 -->
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
skipping to change at page 11, line 43 skipping to change at page 11, line 43
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. State Synchronization 5.5. PLSP-ID Usage
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
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
change in the PLSP-ID allocation.
For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231]
MUST be included in all forward and reverse LSPs.
5.6. State Synchronization
During state synchronization, a PCC MUST report all the existing 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 [I-D.ietf-pce-association]. After the state synchronization, the PCE
MUST remove all stale bidirectional LSP associations. MUST remove all stale bidirectional LSP associations.
5.6. 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 = 29 (Early allocation by IANA) (Association Error) and Error-Value =
TBD4 (Bidirectional LSP Association - Group Mismatch). Similarly, if TBD4 (Bidirectional LSP Association - Group Mismatch). Similarly, if
a PCC attempts to add an LSP at PCE not complying to this rule, the a PCC attempts to add an LSP at PCE not complying to this rule, the
PCE MUST send this PCErr. PCE MUST send this PCErr.
The LSPs (forward or reverse) in a single-sided bidirectional LSP The LSPs (forward or reverse) in a single-sided bidirectional LSP
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 = 29 (Early allocation by IANA)
(Association Error) and Error-Value = TBD5 (Bidirectional LSP (Association Error) and Error-Value = TBD5 (Bidirectional LSP
Association - Tunnel Mismatch). Similarly, if a PCC attempts to add Association - Tunnel Mismatch). Similarly, if a PCC attempts to add
an LSP to a single-sided bidirectional LSP association group at PCE an LSP to a single-sided bidirectional LSP association group at PCE
not complying to this rule, the PCE MUST send this PCErr. not complying to this rule, the PCE MUST send this PCErr.
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
belonging to the Bidirectional LSP Association Groups defined in this
document. In case a PCEP speaker receives a different PST value for
this association group, it MUST return a PCErr message with Error-
Type = 29 (Early allocation by IANA) (Association Error) and Error-
Value = TBD6 (Bidirectional LSP Association - Path Setup Type
Mismatch).
The processing rules as specified in Section 5.4 of
[I-D.ietf-pce-association] continue to apply for the Association
Types defined in this document.
6. Security Considerations 6. 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 Associated
Bidirectional LSP Group are introduced in this document. Additional Bidirectional LSP 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 [I-D.ietf-pce-association] and
skipping to change at page 15, line 5 skipping to change at page 15, line 31
Error Type Description Reference Error Type Description Reference
--------------------------------------------------------------------- ---------------------------------------------------------------------
29 Association Error 29 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]
Bidirectional LSP Association - Path Setup Type Mismatch
9. References 9. References
9.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, DOI Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997. 10.17487/RFC2119, March 1997.
[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
skipping to change at page 15, line 42 skipping to change at page 16, line 42
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, DOI Extensions for Stateful PCE", RFC 8231, DOI
10.17487/RFC8231, September 2017. 10.17487/RFC8231, September 2017.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", RFC 8281, December 2017. Model", RFC 8281, December 2017.
[RFC8537] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to
the Fast Reroute Procedures for Co-routed Associated
Bidirectional Label Switched Paths (LSPs)", RFC 8537,
February 2019.
[I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S., [I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S.,
Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "PCEP Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "PCEP
Extensions for Establishing Relationships Between Sets of Extensions for Establishing Relationships Between Sets of
LSPs", draft-ietf-pce-association-group (work in LSPs", draft-ietf-pce-association-group (work in
progress). progress).
[I-D.ietf-teas-assoc-corouted-bidir-frr] Gandhi, R., Ed., Shah, H.,
and J. Whittaker, "Fast Reroute Procedures for Co-routed
Associated Bidirectional Label Switched Paths (LSPs)",
draft-ietf-teas-assoc-corouted-bidir-frr (work in
progress).
9.2. Informative References 9.2. Informative References
[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, September 2009.
[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", RFC
7420, December 2014. 7420, December 2014.
[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. January 2017.
[RFC8253] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage [RFC8253] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage
of TLS to Provide a Secure Transport for the Path of TLS to Provide a Secure Transport for the Path
Computation Element Communication Protocol (PCEP)", RFC Computation Element Communication Protocol (PCEP)", RFC
8253, October 2017. 8253, October 2017.
[RFC8408] Sivabalan, S., et al. "Conveying Path Setup Type in PCE
Communication Protocol (PCEP) Messages", RFC 8408, July
2018.
[I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J.
Tantsura, "A YANG Data Model for Path Computation Element Tantsura, "A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang
(work in progress). (work in progress).
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 and Mike Taillon for reviewing this also like to thank Dhruv Dhody, Mike Taillon, and Marina Fizgeer for
document and providing valuable comments. reviewing this document and providing valuable comments.
Authors' Addresses Authors' Addresses
Colby Barth
Juniper Networks
Email: cbarth@juniper.net
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Canada Canada
Email: rgandhi@cisco.com Email: rgandhi@cisco.com
Colby Barth
Juniper Networks
Email: cbarth@juniper.net
Bin Wen Bin Wen
Comcast Comcast
Email: Bin_Wen@cable.comcast.com Email: Bin_Wen@cable.comcast.com
 End of changes. 32 change blocks. 
91 lines changed or deleted 132 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/