draft-ietf-pce-association-bidir-09.txt   draft-ietf-pce-association-bidir-10.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: June 19, 2021 Juniper Networks Expires: July 10, 2021 Juniper Networks
B. Wen B. Wen
Comcast Comcast
December 16, 2020 January 06, 2021
Path Computation Element Communication Protocol (PCEP) Extensions for Path Computation Element Communication Protocol (PCEP) Extensions for
Associated Bidirectional Label Switched Paths (LSPs) Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-pce-association-bidir-09 draft-ietf-pce-association-bidir-10
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 47 skipping to change at page 1, line 47
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 June 19, 2021. This Internet-Draft will expire on July 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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.1.1. PCE-Initiated Single-sided Bidirectional LSP . . . . 5 3.1.1. PCE-Initiated Single-sided Bidirectional LSP . . . . 5
3.1.2. PCC-Initiated Single-sided Bidirectional LSP . . . . 6 3.1.2. PCC-Initiated Single-sided Bidirectional LSP . . . . 6
3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 7 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 7
3.2.1. PCE-Initiated Double-sided Bidirectional LSP . . . . 7 3.2.1. PCE-Initiated Double-sided Bidirectional LSP . . . . 7
3.2.2. PCC-Initiated Double-sided Bidirectional LSP . . . . 8 3.2.2. PCC-Initiated Double-sided Bidirectional LSP . . . . 8
3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . 9 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . 9
3.4. Summary of PCEP Extensions . . . . . . . . . . . . . . . 9 3.4. Summary of PCEP Extensions . . . . . . . . . . . . . . . 10
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 10
4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . 10 4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . 10
4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 11 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 12
5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 13 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 13 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 13
5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 14 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 14
5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 15 5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 15
5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 15 5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 15
5.6. State Synchronization . . . . . . . . . . . . . . . . . . 16 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 16
5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 16 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 16
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
6.1. Implementation . . . . . . . . . . . . . . . . . . . . . 17 6.1. Implementation . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 6, line 4 skipping to change at page 6, line 4
reverse tunnel and reverse LSP, and signals the reverse LSP in reverse tunnel and reverse LSP, and signals the reverse LSP in
response to the received RSVP-TE Path message. Similarly, the remote response to the received RSVP-TE Path message. Similarly, the remote
endpoint node deletes the reverse LSP when it receives the RSVP-TE endpoint node deletes the reverse LSP when it receives the RSVP-TE
message to delete the forward LSP [RFC3209]. message to delete the forward LSP [RFC3209].
As specified in [RFC8537], for fast reroute bypass tunnel assignment, As specified in [RFC8537], for fast reroute bypass tunnel assignment,
the LSP starting from the originating endpoint node is identified as the LSP starting from the originating endpoint node is identified as
the forward LSP of the single-sided initiated bidirectional LSP. the forward LSP of the single-sided initiated bidirectional LSP.
3.1.1. PCE-Initiated Single-sided Bidirectional LSP 3.1.1. PCE-Initiated Single-sided Bidirectional LSP
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Initiates: | \ Initiates: | \
Tunnel 1 (F) | \ Tunnel 1 (F) | \
(LSP1 (F, 0), LSP2 (R, 0)) | \ (LSP1 (F, 0), LSP2 (R, 0)) | \
Association #1 v \ Association #1 v \
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Reports: ^ ^ Reports: Reports: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3))
Association #1 | \ Association #1 Association #1 | \ Association #1
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F = Forward LSP, R = Reverse LSP, (0, P1, P2, P3) = PLSP-IDs Legends: F = Forward LSP, R = Reverse LSP, (0,P1,P2,P3) = PLSP-IDs
Figure 2: Example of PCE-Initiated Single-sided Bidirectional LSP Figure 2: Example of PCE-Initiated Single-sided Bidirectional LSP
As shown in Figure 2, the forward tunnel 1 and both forward LSP1 and As shown in Figure 2, the forward tunnel 1 and both forward LSP1 and
reverse LSP2 are initiated on the originating endpoint node A by the reverse LSP2 are initiated on the originating endpoint node A by the
PCE. The PLSP-IDs used are P1 and P2 on the originating endpoint PCE. The PLSP-IDs used are P1 and P2 on the originating endpoint
node A and P3 on the remote endpoint node D. The originating node A and P3 on the remote endpoint node D. The originating
endpoint node A reports tunnels 1 and forward LSP1 and reverse LSP2 endpoint node A reports tunnels 1 and forward LSP1 and reverse LSP2
to the PCE. The endpoint (PCC) node D reports tunnel 2 and LSP2 to to the PCE. The endpoint (PCC) node D reports tunnel 2 and LSP2 to
the PCE. The endpoint (PCC) node D also reports the reverse LSP1 the PCE. The endpoint (PCC) node D also reports the reverse LSP1
skipping to change at page 7, line 15 skipping to change at page 7, line 15
| PCE | | PCE |
+-----+ +-----+
Reports/Delegates: ^ ^ Reports: Reports/Delegates: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3))
Association #2 | \ Association #2 Association #2 | \ Association #2
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F = Forward LSP, R = Reverse LSP, (P1, P2, P3) = PLSP-IDs Legends: F = Forward LSP, R = Reverse LSP, (P1,P2,P3) = PLSP-IDs
Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP
As shown in Figure 3, the forward tunnel 1 and both forward LSP1 and As shown in Figure 3, the forward tunnel 1 and both forward LSP1 and
reverse LSP2 are initiated on the originating endpoint node A (the reverse LSP2 are initiated on the originating endpoint node A (the
originating PCC). The PLSP-IDs used are P1 and P2 on the originating originating PCC). The PLSP-IDs used are P1 and P2 on the originating
endpoint node A and P3 on the remote endpoint node D. The endpoint node A and P3 on the remote endpoint node D. The
originating endpoint (PCC) node A may delegate the forward LSP1 and originating endpoint (PCC) node A may delegate the forward LSP1 and
reverse LSP2 to the PCE. The originating endpoint node A reports reverse LSP2 to the PCE. The originating endpoint node A reports
tunnels 1 and forward LSP1 and reverse LSP2 to the PCE. The endpoint tunnels 1 and forward LSP1 and reverse LSP2 to the PCE. The endpoint
skipping to change at page 8, line 26 skipping to change at page 8, line 26
| PCE | | PCE |
+-----+ +-----+
Reports: ^ ^ Reports: Reports: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P4)) | \ (LSP2 (F, P5)) (LSP1 (F, P4)) | \ (LSP2 (F, P5))
Association #3 | \ Association #3 Association #3 | \ Association #3
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F = Forward LSP, (0, P4, P5) = PLSP-IDs Legends: F = Forward LSP, (0,P4,P5) = PLSP-IDs
Figure 4: Example of PCE-Initiated Double-sided Bidirectional LSP Figure 4: Example of PCE-Initiated Double-sided Bidirectional LSP
As shown in Figure 4, the forward tunnel 1 and forward LSP1 are As shown in Figure 4, the forward tunnel 1 and forward LSP1 are
initiated on the endpoint node A and the reverse tunnel 2 and reverse initiated on the endpoint node A and the reverse tunnel 2 and reverse
LSP2 are initiated on the endpoint node D by the PCE. The PLSP-IDs LSP2 are initiated on the endpoint node D by the PCE. The PLSP-IDs
used are P4 on the endpoint node A and P5 on the endpoint node D. used are P4 on the endpoint node A and P5 on the endpoint node D.
Both endpoint (PCC) nodes report the forward LSP1 and LSP2 to the The endpoint node A (PCC) reports the forward LSP1 and endpoint node
PCE. Both endpoint (PCC) nodes also report the reverse LSPs (not D reports the forward LSP2 to the PCE. Both endpoint (PCC) nodes
shown for simplicity) to the PCE. also report the reverse LSPs (not shown for simplicity) to the PCE.
3.2.2. PCC-Initiated Double-sided Bidirectional LSP 3.2.2. PCC-Initiated Double-sided Bidirectional LSP
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Reports/Delegates: ^ ^ Reports/Delegates: Reports/Delegates: ^ ^ Reports/Delegates:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P4)) | \ (LSP2 (F, P5)) (LSP1 (F, P4)) | \ (LSP2 (F, P5))
Association #4 | \ Association #4 Association #4 | \ Association #4
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F = Forward LSP, (P4, P5) = PLSP-IDs Legends: F = Forward LSP, (P4,P5) = PLSP-IDs
Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP
As shown in Figure 5, the forward tunnel 1 and forward LSP1 are As shown in Figure 5, the forward tunnel 1 and forward LSP1 are
initiated on the endpoint node A and the reverse tunnel 2 and reverse initiated on the endpoint node A and the reverse tunnel 2 and reverse
LSP2 are initiated on the endpoint node D (the PCCs). The PLSP-IDs LSP2 are initiated on the endpoint node D (the PCCs). The PLSP-IDs
used are P4 on the endpoint node A and P5 on the endpoint node D. used are P4 on the endpoint node A and P5 on the endpoint node D.
Both endpoint (PCC) nodes may delegate the forward LSP1 and LSP2 to Both endpoint (PCC) nodes may delegate the forward LSP1 and LSP2 to
the PCE. Both endpoint (PCC) nodes report the forward LSP1 and LSP2 the PCE. The endpoint node A (PCC) reports the forward LSP1 and
to the PCE. Both endpoint (PCC) nodes also report the reverse LSPs endpoint node D reports the forward LSP2 to the PCE. Both endpoint
(not shown for simplicity) to the PCE. (PCC) nodes also report the reverse LSPs (not shown for simplicity)
to the PCE.
3.3. Co-routed Associated Bidirectional LSP 3.3. Co-routed Associated Bidirectional LSP
In both single-sided and double-sided initiation cases, forward and In both single-sided and double-sided initiation cases, forward and
reverse LSPs can be co-routed as shown in Figure 6, where both reverse LSPs can be co-routed as shown in Figure 6, where both
forward and reverse LSPs of a bidirectional LSP follow the same forward and reverse LSPs of a bidirectional LSP follow the same
congruent path in the forward and reverse directions, respectively. congruent path in the forward and reverse directions, respectively.
LSP3 --> LSP3 --> LSP3 --> LSP3 --> LSP3 --> LSP3 -->
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +-----------+ B +-----------+ C +-----------+ D | | A +-----------+ B +-----------+ C +-----------+ D |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
<-- LSP4 <-- LSP4 <-- LSP4 <-- LSP4 <-- LSP4 <-- LSP4
Figure 6: Example of Co-routed Associated Bidirectional LSP Figure 6: Example of Co-routed Associated Bidirectional LSP
The procedure specified in [RFC8537] for fast reroute bypass tunnel
assignment is also applicable to the Co-routed Associated
Bidirectional LSPs.
3.4. Summary of PCEP Extensions 3.4. Summary of PCEP Extensions
The PCEP extensions defined in this document cover the following The PCEP extensions defined in this document cover the following
modes of operations under the stateful PCE model: modes of operations under the stateful PCE model:
o A PCC initiates the forward and reverse LSP of a Single-sided o A PCC initiates the forward and reverse LSP of a Single-sided
Bidirectional LSP and retains the control of the LSPs. Similarly, Bidirectional LSP and retains the control of the LSPs. Similarly,
both PCCs initiate the forward LSPs of a Double-sided both PCCs initiate the forward LSPs of a Double-sided
Bidirectional LSP and retain the control of the LSPs. The PCC Bidirectional LSP and retain the control of the LSPs. The PCC
computes the path itself or makes a request for path computation computes the path itself or makes a request for path computation
skipping to change at page 10, line 48 skipping to change at page 11, line 10
association group. This document defines two new Association Types, association group. This document defines two new Association Types,
called "Single-sided Bidirectional LSP" (TBD1) and "Double-sided called "Single-sided Bidirectional LSP" (TBD1) and "Double-sided
Bidirectional LSP" (TBD2), based on the generic ASSOCIATION Object Bidirectional LSP" (TBD2), based on the generic ASSOCIATION Object
((Object-Class value 40). A member of the Bidirectional LSP ((Object-Class value 40). A member of the Bidirectional LSP
Association can take the role of a forward or reverse LSP and follows Association can take the role of a forward or reverse LSP and follows
the following rules: the following rules:
o An LSP (forward or reverse) MUST NOT be part of more than one o An LSP (forward or reverse) MUST NOT be part of more than one
Bidirectional LSP Association. Bidirectional LSP Association.
o A Bidirectional LSP Association SHOULD NOT have more than two
unidirectional LSPs.
o The LSPs in a Bidirectional LSP Association MUST have matching o The LSPs in a Bidirectional LSP Association MUST have matching
endpoint nodes in the reverse directions. endpoint nodes in the reverse directions.
o The Tunnel (as defined in [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 endpoint node MUST be the same, albeit with reverse originating endpoint node MUST be the same, albeit with reverse
endpoint nodes. endpoint nodes.
The Bidirectional LSP Association types are considered to be both The Bidirectional LSP Association types are considered to be both
dynamic and operator- configured in nature. As per [RFC8697], the dynamic and operator-configured in nature. As per [RFC8697], the
association group could be manually created by the operator on the association group could be manually created by the operator on the
PCEP peers, and the LSPs belonging to this association are conveyed PCEP peers, and the LSPs belonging to this association are conveyed
via PCEP messages to the PCEP peer; alternately, the association via PCEP messages to the PCEP peer; alternately, the association
group could be created dynamically by the PCEP speaker, and both the group could be created dynamically by the PCEP speaker, and both the
association group information and the LSPs belonging to the association group information and the LSPs belonging to the
association group are conveyed to the PCEP peer. The Operator- association group are conveyed to the PCEP peer. The Operator-
configured Association Range MUST be set for this association-type to configured Association Range MUST be set for this association-type to
mark a range of Association Identifiers that are used for operator- mark a range of Association Identifiers that are used for operator-
configured associations to avoid any Association Identifier clash configured associations to avoid any Association Identifier clash
within the scope of the Association Source (Refer to [RFC8697]). within the scope of the Association Source (Refer to [RFC8697]).
Specifically, for the PCE Initiated Bidirectional LSPs, these Specifically, for the PCE Initiated Bidirectional LSPs, these
Associations are dynamically created by the PCE on the PCE peers. Associations are dynamically created by the PCE on the PCE peers.
Similarly, for both PCE Initiated and PCC Initiated single-sided Similarly, for both PCE Initiated and PCC Initiated single-sided
case, these associations are also dynamically created on thee remote case, these associations are also dynamically created on the remote
endpoint node using the information received from the RSVP message endpoint node using the information received from the RSVP message
from the originating node. from the originating node.
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 Object are initialized using the procedures defined in Association Object are initialized using the procedures defined in
[RFC8697] and [RFC7551]. [RFC8697] and [RFC7551].
[RFC8697] specifies the mechanism for the capability advertisement of [RFC8697] specifies the mechanism for the capability advertisement of
the Association Types supported by a PCEP speaker by defining an the Association Types supported by a PCEP speaker by defining an
skipping to change at page 12, line 19 skipping to change at page 12, line 26
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 Flag (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 When "Bidirectional LSP Association Group TLV" is present, the F
flag MUST be set for the forward LSP for both co-routed and non
co-routed LSPs.
o For co-routed LSPs, this TLV MUST be present and C flag set. o For co-routed LSPs, this TLV MUST be present and C flag set.
o For reverse LSPs, this TLV MUST be present and R flag set. o For reverse LSPs, this TLV MUST be present and R flag set.
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 The format of the "Bidirectional LSP Association Group TLV" is shown
in Figure 7: in Figure 7:
skipping to change at page 14, line 14 skipping to change at page 14, line 22
o Stateful PCE establishes and removes the association relationship o Stateful PCE establishes and removes the association relationship
on a per LSP basis. on a per LSP basis.
o Stateful PCE creates and updates the LSP and the association on a o Stateful PCE creates and updates the LSP and the association on a
PCC via PCInitiate and PCUpd messages, respectively, using the PCC via PCInitiate and PCUpd messages, respectively, using the
procedures described in [RFC8697]. procedures described in [RFC8697].
5.2. PCC Initiated LSPs 5.2. PCC Initiated LSPs
As specified in [RFC8697], Bidirectional LSP Associations can also be As specified in [RFC8697], the Bidirectional LSP Associations can
created and updated by a PCC. also be created and updated by a PCC.
o For Single-sided Bidirectional LSP Association initiated at a PCC, o For Single-sided Bidirectional LSP Association initiated at a PCC,
it MUST send PCRpt message to the PCE with both direction LSPs. it MUST send PCRpt message to the PCE with both direction LSPs.
For Double-sided Bidirectional LSP Association initiated at the For Double-sided Bidirectional LSP Association initiated at the
PCCs, both PCCs MUST send PCRpt message to the PCE with forward PCCs, both PCCs MUST send PCRpt message to the PCE with forward
direction LSPs. direction LSPs.
o PCC on the originating endpoint node MAY create and update the o PCC on the originating endpoint node MAY create and update the
forward and reverse LSPs independently for the Single-sided forward and reverse LSPs independently for the Single-sided
Bidirectional LSP Association. Bidirectional LSP Association.
skipping to change at page 16, line 35 skipping to change at page 16, line 35
The LSPs (forward or reverse) in a Single-sided Bidirectional The LSPs (forward or reverse) in a Single-sided Bidirectional
Association MUST belong to the same TE Tunnel (as defined in Association MUST belong to the same TE Tunnel (as defined in
[RFC3209]). If a PCE speaker attempts to add an LSP in a Single- [RFC3209]). If a PCE speaker attempts to add an LSP in a Single-
sided Bidirectional LSP Association for a different Tunnel, the PCE sided Bidirectional LSP Association for a different Tunnel, the PCE
speaker MUST send PCErr with Error-Type = 26 (Association Error) and speaker MUST send PCErr with Error-Type = 26 (Association Error) and
Error-Value = TBD5 (Bidirectional Association - Tunnel Mismatch). Error-Value = TBD5 (Bidirectional Association - Tunnel Mismatch).
The PCEP Path Setup Type (PST) for RSVP-TE is set to 'Path is set up The PCEP Path Setup Type (PST) for RSVP-TE is set to 'Path is set up
using the RSVP-TE signaling protocol' (Value 0) [RFC8408]. If a PCEP using the RSVP-TE signaling protocol' (Value 0) [RFC8408]. If a PCEP
speaker receives a different PST value for the Bidirectional LSP speaker receives a different PST value for the Bidirectional LSP
Associations defined in this document and it does not support; the Associations defined in this document, the PCE speaker MUST return a
PCE speaker MUST return a PCErr message with Error-Type = 26 PCErr message with Error-Type = 26 (Association Error) and Error-
(Association Error) and Error-Value = TBD6 (Bidirectional LSP Value = TBD6 (Bidirectional LSP Association - Path Setup Type Not
Association - Path Setup Type Not Supported). Supported).
A Bidirectional LSP Association cannot have both unidirectional LSPs A Bidirectional LSP Association cannot have both unidirectional LSPs
identified as Reverse LSPs or both LSPs identified as Forward LSPs. identified as Reverse LSPs or both LSPs identified as Forward LSPs.
If a PCE speaker receives an LSP not complying to this rule, the PCE If a PCE speaker receives an LSP not complying to this rule, the PCE
speaker MUST send PCErr with Error-Type = 26 (Association Error) and speaker MUST send PCErr with Error-Type = 26 (Association Error) and
Error-Value = TBD7 (Bidirectional LSP Association - Direction Error-Value = TBD7 (Bidirectional LSP Association - Direction
Mismatch). Mismatch).
A Bidirectional LSP Association cannot have one unidirectional LSP A Bidirectional LSP Association cannot have one unidirectional LSP
identified as co-routed and the other identified as non-co-routed. identified as co-routed and the other identified as non-co-routed.
skipping to change at page 22, line 11 skipping to change at page 22, line 11
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] [I-D.ietf-pce-pcep-stateful-pce-gmpls]
Lee, Y., Zheng, H., Dios, O., Lopez, V., and Z. Ali, "Path Lee, Y., Zheng, H., Dios, O., Lopez, V., and Z. Ali, "Path
Computation Element (PCE) Protocol Extensions for Stateful Computation Element (PCE) Protocol Extensions for Stateful
PCE Usage in GMPLS-controlled Networks", draft-ietf-pce- PCE Usage in GMPLS-controlled Networks", draft-ietf-pce-
pcep-stateful-pce-gmpls-13 (work in progress), April 2020. pcep-stateful-pce-gmpls-14 (work in progress), December
2020.
[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-15 (work in progress), October 2020. yang-15 (work in progress), October 2020.
[I-D.ietf-pce-sr-bidir-path] [I-D.ietf-pce-sr-bidir-path]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"PCEP Extensions for Associated Bidirectional Segment "PCEP Extensions for Associated Bidirectional Segment
skipping to change at page 23, line 14 skipping to change at page 23, line 14
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>. July 2018, <https://www.rfc-editor.org/info/rfc8408>.
Acknowledgments Acknowledgments
The authors would like to thank Dhruv Dhody for various discussions The authors would like to thank Dhruv Dhody for various discussions
on association groups and inputs to this document. The authors would on association groups and inputs to this document. The authors would
also like to thank Mike Taillon, and Marina Fizgeer for reviewing also like to thank Mike Taillon, Harish Sitaraman, and Marina Fizgeer
this document and providing valuable comments. for reviewing this document and providing valuable comments.
Authors' Addresses Authors' Addresses
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Canada Canada
Email: rgandhi@cisco.com Email: rgandhi@cisco.com
Colby Barth Colby Barth
 End of changes. 24 change blocks. 
51 lines changed or deleted 58 lines changed or added

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