draft-ietf-pce-association-bidir-05.txt   draft-ietf-pce-association-bidir-06.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: August 7, 2020 Juniper Networks Expires: September 14, 2020 Juniper Networks
B. Wen B. Wen
Comcast Comcast
February 4, 2020 March 13, 2020
PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs) PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-pce-association-bidir-05 draft-ietf-pce-association-bidir-06
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.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 https://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. This Internet-Draft will expire on September 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Summary of PCEP Extensions . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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
skipping to change at page 3, line 5 skipping to change at page 3, line 6
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 Field in Bidirectional LSP Association Group TLV 15
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 15 9.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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
skipping to change at page 3, line 47 skipping to change at page 3, line 47
specifies that MPLS-TP MUST support associated bidirectional point- specifies that MPLS-TP MUST support associated bidirectional 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 unidirectional This document defines PCEP extensions for grouping two unidirectional
MPLS-TE LSPs into an Associated Bidirectional LSP for both single- MPLS-TE LSPs into an Associated Bidirectional LSP for both single-
sided and double-sided initiation cases when using a Stateful PCE for sided and double-sided initiation cases when using a Stateful PCE for
both PCE-Initiated and PCC-Initiated LSPs as well as when using a both PCE-Initiated and PCC-Initiated LSPs as well as when using a
Stateless PCE. The procedures defined are applicable to the LSPs Stateless PCE. The procedures defined are applicable to the TE LSPs
using Resource Reservation Protocol (RSVP) for signaling [RFC3209]. using Resource Reservation Protocol (RSVP) for signaling [RFC3209].
The PCEP extensions cover the following cases: The procedure for associating two unidirectional Segment Routing (SR)
Paths to form an Associated Bidirectional SR Path is defined in
[I-D.ietf-pce-sr-bidir-path], and is outside the scope of this
document.
1.1. Summary of PCEP Extensions
The PCEP extensions defined in this document 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 28 skipping to change at page 4, line 36
the path as long as it controls the LSP. This is the Active the path as long as it controls the LSP. This is the Active
Stateful mode defined in [RFC8051]. Stateful mode defined in [RFC8051].
o A PCE initiates the forward and/ or reverse LSP of a single-sided o A PCE initiates the forward and/ or reverse LSP of a single-sided
or double-sided bidirectional LSP on a PCC and retains the control or double-sided bidirectional LSP on a PCC and retains the control
of the LSP. The PCE is responsible for computing the path of the of the LSP. The PCE is responsible for computing the path of the
LSP and updating the PCC with the information about the path as LSP and updating the PCC with the information about the path as
well as the association group identifying the bidirectional LSP. well as the association group identifying the bidirectional LSP.
This is the PCE-Initiated mode defined in [RFC8281]. This is the PCE-Initiated mode defined in [RFC8281].
o A PCC requests co-routed or non co-routed paths for forward and o A PCC requests co-routed or non-co-routed paths for forward and
reverse LSPs of a bidirectional LSP from a Stateless PCE reverse LSPs of a bidirectional LSP from a Stateless PCE
[RFC5440]. [RFC5440].
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Key Word Definitions 2.1. Key Word Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 8, line 23 skipping to change at page 8, line 23
4. Protocol Extensions 4. Protocol Extensions
4.1. ASSOCIATION Object 4.1. ASSOCIATION Object
As per [RFC8697], LSPs are associated by adding them to a common As per [RFC8697], LSPs are associated by adding them to a common
association group. This document defines two new Bidirectional LSP association group. This document defines two new Bidirectional LSP
Association Groups to be used by the associated bidirectional LSPs. Association Groups to be used by the associated bidirectional LSPs.
A member of the Bidirectional LSP Association Group can take the role A member of the Bidirectional LSP Association Group can take the role
of a forward or reverse LSP and follows the following rules: of a forward or reverse LSP and follows the following rules:
o An LSP (forward or reverse) can not be part of more than one o An LSP (forward or reverse) cannot 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 (Object-Class value 40) 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.
LSP belonging to these associations is conveyed via PCEP messages to 'Operator-configured Association Range' TLV (Value 29) [RFC8697] MUST
the PCEP peer. Operator-configured Association Range TLV (Value 29) NOT be sent for these Association Types, and MUST be ignored, so that
[RFC8697] MUST NOT be sent for these Association Types, and MUST be the entire range of association ID can be used for them.
ignored, so that the entire range of association ID can be used for
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 [RFC8697] 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].
o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA.
o The Length is 4 Bytes. o The Length is 4 Bytes.
o The value comprises of a single field, the Bidirectional LSP o The value comprises of a single field, the Bidirectional LSP
Association Flags (32 bits), where each bit represents a flag Association Flag (32 bits), where each bit represents a flag
option. option.
o If the Bidirectional LSP Association Group TLV is missing, it o If the Bidirectional LSP Association Group TLV is missing, it
means the LSP is the forward LSP and it is not co-routed LSP. means the LSP is the forward LSP and it is not co-routed LSP.
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
skipping to change at page 9, line 46 skipping to change at page 9, line 46
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 7: Bidirectional LSP Association Group TLV format Figure 7: Bidirectional LSP Association Group TLV format
Bidirectional LSP Association Flags are defined as following. Flags for Bidirectional LSP Association Group TLV 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 Path, 1 bit) - Indicates whether the bidirectional LSP C (Co-routed Path, 1 bit) - Indicates whether the bidirectional LSP
skipping to change at page 11, line 23 skipping to change at page 11, line 23
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 [RFC8697]. 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 in each direction. For an associated bidirectional LSP,
bidirectional LSP, the B-flag MAY be set when the PCC makes the path the B-flag is also set when the PCC makes the path computation
computation request for the same TE requirements in the forward and request for the same TE requirements for the forward and reverse
reverse directions. When a stateful PCE initiates or updates the direction LSPs.
bidirectional LSPs, the B-flag in Stateful PCE Request Parameters
(SRP) object [RFC8231] MAY also be set. Note that the B-flag defined in Stateful PCE Request Parameter (SRP)
object [I-D.ietf-pce-pcep-stateful-pce-gmpls] to indicate
'bidirectional co-routed LSP' is used for GMPLS signaled
bidirectional LSPs and is not applicable to the associated
bidirectional LSPs.
5.5. PLSP-ID Usage 5.5. PLSP-ID Usage
As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is
created by a PCC to uniquely identify an LSP and it remains the same created by a PCC to uniquely identify an LSP and it remains the same
for the lifetime of a PCEP session. for the lifetime of a PCEP session.
In case of Single-sided Bidirectional LSP Association, the reverse In case of Single-sided Bidirectional LSP Association, the reverse
LSP of a bidirectional LSP created on the originating node is LSP of a bidirectional LSP created on the originating node is
identified by the PCE using 2 different PLSP-IDs based on the PCEP identified by the PCE using 2 different PLSP-IDs based on the PCEP
skipping to change at page 12, line 20 skipping to change at page 12, line 24
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
[RFC8697]. After the state synchronization, the PCE MUST remove all [RFC8697]. After the state synchronization, the PCE 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) cannot 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 =
26 (Association Error) and Error-Value = TBD4 (Bidirectional LSP 26 (Association Error) and Error-Value = TBD4 (Bidirectional LSP
Association - Group Mismatch). Similarly, if a PCC attempts to add Association - Group Mismatch). Similarly, if a PCC attempts to add
an LSP at PCE not complying to this rule, the PCE MUST send this an LSP at PCE not complying to this rule, the PCE MUST send this
PCErr. PCErr.
The LSPs (forward or reverse) in a Single-sided Bidirectional 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 = 26 (Association Error) and Error- MUST send PCErr with Error-Type = 26 (Association Error) and Error-
Value = TBD5 (Bidirectional Association - Tunnel Mismatch). Value = TBD5 (Bidirectional Association - Tunnel Mismatch).
Similarly, if a PCC attempts to add an LSP to a Single-sided Similarly, if a PCC attempts to add an LSP to a Single-sided
Bidirectional LSP Association Group at PCE not complying to this Bidirectional LSP Association Group at PCE 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) for RSVP is set to 'Path is set up
the RSVP-TE signaling protocol' (Value 0) [RFC8408] for the LSP using the RSVP-TE signaling protocol' (Value 0) [RFC8408]. If a PCEP
belonging to the Bidirectional LSP Association Groups defined in this speaker receives a different PST value for the Bidirectional LSP
document. In case a PCEP speaker receives a different PST value for Association Groups defined in this document and it does not support;
this association group, it MUST return a PCErr message with Error- it MUST return a PCErr message with Error-Type = 26 (Association
Type = 26 (Association Error) and Error-Value = TBD6 (Bidirectional Error) and Error-Value = TBD6 (Bidirectional LSP Association - Path
LSP Association - Path Setup Type Mismatch). Setup Type Not Supported).
The processing rules as specified in Section 6.4 of [RFC8697] The processing rules as specified in Section 6.4 of [RFC8697]
continue to apply to the Association Types defined in this document. continue to apply to the Association Types defined in this document.
6. Implementation Status 6. 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
skipping to change at page 14, line 50 skipping to change at page 14, line 50
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
(Object-class value 40) defined [RFC8697]. IANA is requested to make (Object-class value 40) defined [RFC8697]. IANA is requested to make
the assignment of values for the sub-registry "ASSOCIATION Type the assignment of values for the sub-registry "ASSOCIATION Type"
Field" [RFC8697], as follows: [RFC8697], as follows:
Type 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:
Value Meaning 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 Field 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)
skipping to change at page 16, line 16 skipping to change at page 16, line 16
--------------------------------------------------------- ---------------------------------------------------------
26 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
Not Supported
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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 17, line 32 skipping to change at page 17, line 32
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>. <https://www.rfc-editor.org/info/rfc8697>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-pce-pcep-stateful-pce-gmpls]
Lee, Y., Zheng, H., Dios, O., Lopezalvarez, V., and Z.
Ali, "Path Computation Element (PCE) Protocol Extensions
for Stateful PCE Usage in GMPLS-controlled Networks",
draft-ietf-pce-pcep-stateful-pce-gmpls-12 (work in
progress), October 2019.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep- Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-13 (work in progress), October 2019. yang-13 (work in progress), October 2019.
[I-D.ietf-pce-sr-bidir-path]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"PCEP Extensions for Associated Bidirectional Segment
Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-01 (work
in progress), February 2020.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654, Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <https://www.rfc-editor.org/info/rfc5654>. September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014, RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>. <https://www.rfc-editor.org/info/rfc7420>.
 End of changes. 23 change blocks. 
39 lines changed or deleted 65 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/