idnits 2.17.1 draft-ietf-pce-sr-bidir-path-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-05 == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-11 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-19 == Outdated reference: A later version (-15) exists of draft-ietf-spring-stamp-srpm-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-07 == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-03 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-18 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-17 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-06 == Outdated reference: A later version (-11) exists of draft-ietf-pce-multipath-04 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Li 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: 8 September 2022 W. Cheng 6 China Mobile 7 R. Gandhi 8 Cisco Systems, Inc. 9 Q. Xiong 10 ZTE Corporation 11 7 March 2022 13 Path Computation Element Communication Protocol (PCEP) Extensions for 14 Associated Bidirectional Segment Routing (SR) Paths 15 draft-ietf-pce-sr-bidir-path-09 17 Abstract 19 The Path Computation Element Communication Protocol (PCEP) provides 20 mechanisms for Path Computation Elements (PCEs) to perform path 21 computations in response to Path Computation Clients (PCCs) requests. 22 Segment routing (SR) leverages the source routing and tunneling 23 paradigms. The Stateful PCEP extensions allow stateful control of 24 Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP 25 can be used for computing SR TE paths in the network. 27 This document defines PCEP extensions for grouping two unidirectional 28 SR Paths (one in each direction in the network) into a single 29 associated bidirectional SR Path. The mechanisms defined in this 30 document can also be applied using a stateful PCE for both PCE- 31 initiated and PCC-initiated LSPs or when using a stateless PCE. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 8 September 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Bidirectional SR Policy Association . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Double-Sided Bidirectional with Reverse LSP 71 Association . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1.1. Bidirectional LSP Association Group TLV . . . . . . . 6 73 4. PCEP Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. PCE-Initiated Associated Bidirectional SR Paths . . . . . 7 75 4.2. PCC-Initiated Associated Bidirectional SR Paths . . . . . 8 76 4.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 11 77 4.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 11 78 4.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 11 79 4.6. State Synchronization . . . . . . . . . . . . . . . . . . 12 80 4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 12 81 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 82 5.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 13 83 5.2. ZTE's Commercial Delivery . . . . . . . . . . . . . . . . 13 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 7. Manageability Considerations . . . . . . . . . . . . . . . . 14 86 7.1. Control of Function and Policy . . . . . . . . . . . . . 14 87 7.2. Information and Data Models . . . . . . . . . . . . . . . 14 88 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 14 89 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 14 90 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 14 91 7.6. Impact On Network Operations . . . . . . . . . . . . . . 15 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 8.1. Association Type . . . . . . . . . . . . . . . . . . . . 15 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 96 9.2. Informative References . . . . . . . . . . . . . . . . . 16 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 101 1. Introduction 103 Segment routing (SR) [RFC8402] leverages the source routing and 104 tunneling paradigms. SR supports steering packets onto an explicit 105 forwarding path at the ingress node. SR is specified for 106 unidirectional paths. However, some applications require 107 bidirectional paths in SR networks, for example, in mobile backhaul 108 transport networks. The requirement for bidirectional SR Paths is 109 specified in [I-D.ietf-spring-mpls-path-segment] and 110 [I-D.ietf-spring-srv6-path-segment]. 112 [RFC5440] describes the Path Computation Element (PCE) Communication 113 Protocol (PCEP). PCEP enables the communication between a Path 114 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 115 purpose of computation of Traffic Engineering (TE) Label Switched 116 Paths (LSP). [RFC8231] specifies a set of extensions to PCEP to 117 enable stateful control of TE LSPs within and across PCEP sessions. 118 The mode of operation where LSPs are initiated from the PCE is 119 described in [RFC8281]. 121 [RFC8408] specifies extensions to the Path Computation Element 122 Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE 123 to compute and initiate SR TE paths, as well as a PCC to request, 124 report or delegate them. 126 [RFC8697] introduces a generic mechanism to create a grouping of 127 LSPs. This grouping can then be used to define associations between 128 sets of LSPs or between a set of LSPs and a set of attributes, and it 129 is equally applicable to the stateful PCE (active and passive modes) 130 [RFC8231] and the stateless PCE [RFC5440]. 132 For bidirectional SR paths, there are use-cases such as directed BFD 133 [I-D.ietf-mpls-bfd-directed] and Performance Measurement (PM) 134 [I-D.ietf-spring-stamp-srpm] those require ingress node (PCC) to be 135 aware of the reverse direction SR Path. For such use-cases, the 136 reverse SR Paths need to be communicated to the ingress node (PCCs) 137 using PCEP mechanisms. This allows both endpoint ingress nodes to be 138 aware of the SR Paths in both directions, including their status and 139 all other path related information. 141 [RFC9059] defines PCEP extensions for grouping two unidirectional 142 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs 143 into an associated bidirectional LSP when using a stateful PCE for 144 both PCE-initiated and PCC-initiated LSPs as well as when using a 145 stateless PCE. Specifically, it defines the procedure for 'Double- 146 Sided Bidirectional LSP Association', where the PCE creates the 147 association and provisions the forward LSPs at their ingress nodes. 148 The RSVP-TE signals the forward LSPs to the egress nodes. Thus, both 149 endpoints learn the reverse LSPs forming the bidirectional LSP 150 association. 152 This document extends the bidirectional LSP association to SR paths 153 by specifying PCEP extensions for grouping two unidirectional SR 154 Paths into an associated bidirectional SR Path. Note that the 155 procedure for using the association group defined in this document is 156 specific to the associated bidirectional SR Paths. Associating an 157 unidirectional SR Path with a reverse direction unidirectional RSVP- 158 TE LSP to form a bidirectional LSP and vice versa, are outside the 159 scope of this document. 161 1.1. Bidirectional SR Policy Association 163 An SR Policy contains one or more SR Policy Candidate Paths (CPs) 164 [I-D.ietf-spring-segment-routing-policy] where one or more such paths 165 can be computed via PCE. Each Candidate Path maps to a unique PLSP- 166 ID in PCEP. Multiple Candidate Paths can be associated together into 167 a single SR Policy, via the use of the PCEP Association object with 168 the "SR Policy Association" type as specified in 169 [I-D.ietf-pce-segment-routing-policy-cp]. The two unidirectional 170 Candidate Paths can be associated to form a bidirectional Candidate 171 Path using the procedure defined in this document. 173 Each Candidate Path of an SR Policy contains one or more Segment 174 Lists (SLs) [I-D.ietf-spring-segment-routing-policy]. If the 175 Candidate Path is computed by the PCE, it means that the PCE computed 176 all SLs of that Candidate Path. [I-D.ietf-pce-multipath] defines 177 procedure for carrying multiple SLs in a Candidate Path. The 178 procedure works at the SL level to identify the forward and the 179 reverse direction SLs in a Candidate Path as shown in an Example in 180 Section 7.4 (Opposite Direction Tunnels) in [I-D.ietf-pce-multipath]. 181 The procedure defined in this document allows to identify the forward 182 and reverse direction Candidate Paths in a bidirectional SR Policy. 184 2. Terminology 186 This document makes use of the terms defined in [RFC8408]. The 187 reader is assumed to be familiar with the terminology defined in 188 [RFC5440], [RFC8231], [RFC8281], [RFC8697], and [RFC9059]. 190 2.1. Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in BCP 195 14 [RFC2119] [RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 3. PCEP Extensions 200 As per [RFC8697], TE LSPs are associated by adding them to a common 201 association group by a PCEP peer. [RFC9059] uses the association 202 group object and the procedures as specified in [RFC8697] to group 203 two unidirectional RSVP-TE LSPs. Similarly, two SR Paths can also be 204 associated using similar technique. This document extends these 205 association mechanisms for bidirectional SR Paths. Two 206 unidirectional SR Paths (one in each direction in the network) can be 207 associated together by using the association group defined in this 208 document for PCEP messages. 210 [I-D.ietf-pce-sr-path-segment] defines a mechanism for communicating 211 Path Segment Identifier (PSID) in PCEP for SR. The SR-MPLS PSID is 212 defined in [I-D.ietf-spring-mpls-path-segment] and SRv6 PSID is 213 defined in [I-D.ietf-spring-srv6-path-segment]. The PSID can be used 214 for identifying the SR Path of an associated bidirectional SR Path. 215 The PATH-SEGMENT TLV MAY be included for the SR Path in the LSP 216 object to support the use-cases as required. The PATH-SEGMENT TLV 217 MUST be handled as defined in [I-D.ietf-pce-sr-path-segment] and is 218 not modified for associated bidirectional SR Path. 220 3.1. Double-Sided Bidirectional with Reverse LSP Association 222 For associating two unidirectional SR Paths, this document defines a 223 new Association Type called 'Double-Sided Bidirectional with Reverse 224 LSP Association' for Association Group object (Class-Value 40) as 225 follows: 227 * Association Type (TBD1 to be assigned by IANA) = Double-Sided 228 Bidirectional with Reverse LSP Association 230 The bidirectional association is considered to be both dynamic and 231 operator-configured in nature. As per [RFC8697], the association 232 group could be manually created by the operator on the PCEP peers, 233 and the LSPs belonging to this association are conveyed via PCEP 234 messages to the PCEP peer; alternately, the association group could 235 be created dynamically by the PCEP speaker, and both the association 236 group information and the LSPs belonging to the association group are 237 conveyed to the PCEP peer. The Operator-configured Association Range 238 MUST be set for this Association Type to mark a range of Association 239 Identifiers that are used for operator-configured associations to 240 avoid any Association Identifier clash within the scope of the 241 Association Source (Refer to [RFC8697]). Specifically, for the PCE- 242 initiated associated bidirectional SR Paths, the Association Type is 243 dynamically created by the PCE on the PCE peers. 245 The handling of the Association ID, Association Source, optional 246 Global Association Source and optional Extended Association ID in 247 this association are set in the same way as [RFC9059]. 249 [RFC8697] specifies the mechanism for the capability advertisement of 250 the Association Types supported by a PCEP speaker by defining an 251 ASSOC-Type-List TLV (value 35) to be carried within an OPEN object. 252 This capability exchange for the Bidirectional Association MUST be 253 done before using the Bidirectional Association Type. Thus, the PCEP 254 speaker MUST include the bidirectional Association Type in the ASSOC- 255 Type-List TLV and MUST receive the same from the PCEP peer before 256 using the Bidirectional Association in PCEP messages. 258 A member of the 'Double-Sided Bidirectional with Reverse LSP 259 Association' can take the role of a forward or reverse direction SR 260 Path and follow the similar rules defined in [RFC9059] for LSPs. 262 * An SR Path (forward or reverse) MUST NOT be part of more than one 263 'Double-Sided Bidirectional with Reverse LSP Association'. 265 * The endpoint nodes of the SR Paths in 'Double-Sided Bidirectional 266 with Reverse LSP Association' MUST be matching in the reverse 267 directions. 269 3.1.1. Bidirectional LSP Association Group TLV 271 In 'Double-Sided Bidirectional with Reverse LSP Association', for 272 properties such as forward and reverse direction and co-routed path, 273 it uses the 'Bidirectional LSP Association Group TLV' defined in 274 [RFC9059]. All fields and processing rules are as per [RFC9059]. 276 4. PCEP Procedures 278 For an associated bidirectional SR Path, an ingress node PCC is aware 279 of the forward direction SR Path beginning from itself to the egress 280 node PCC using the existing PCEP procedures. For the use-cases which 281 require the ingress node PCC to be aware of the reverse direction SR 282 Path, PCE informs the reverse SR Path to the ingress node PCC. To 283 achieve this, a PCInitiate message for the reverse SR Path is sent to 284 the ingress node PCC and a PCInitiate message for the forward SR Path 285 is sent to the egress node PCC (with the matching association group). 287 These PCInitiate message MUST NOT trigger initiation of SR Paths on 288 PCCs. 290 The PCEP procedure defined in this document is applicable to the 291 following three scenarios: 293 * Neither unidirectional LSP exists, and both must be established. 295 * Both unidirectional LSPs exist, but the association must be 296 established. 298 * One LSP exists, but the reverse associated LSP must be 299 established. 301 4.1. PCE-Initiated Associated Bidirectional SR Paths 303 As specified in [RFC8697], associated bidirectional SR Paths can be 304 created and updated by a Stateful PCE as shown in Figure 1. 306 * Stateful PCE MAY create and update the forward and reverse SR 307 Paths independently for the 'Double-Sided Bidirectional with 308 Reverse LSP Association'. 310 * Stateful PCE MAY establish and remove the association relationship 311 on a per SR Path basis. 313 * Stateful PCE MUST create and update the SR Path and the 314 association on a PCC via PCInitiate and PCUpd messages, 315 respectively, using the procedures described in [RFC8697]. 317 * The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 318 D as shown in Figure 1) SHOULD be informed by the PCE via 319 PCInitiate message with the matching association group for the 320 use-cases which require the PCC to be aware of the reverse 321 direction SR Path. 323 +-----+ 324 | PCE | 325 +-----+ 326 PCInitiate: / \ PCInitiate: 327 Tunnel 1 (F) / \ Tunnel 2 (F) 328 LSP1 (F,0), LSP2 (R,0) / \ LSP2 (F,0), LSP1 (R,0) 329 Association #1 / \ Association #1 330 / \ 331 v v 332 +-----+ LSP1 +-----+ 333 | S |------------>| D | 334 | |<------------| | 335 +-----+ LSP2 +-----+ 336 338 Legends: F = Forward LSP, R = Reverse LSP, (0) = PLSP-IDs 340 Figure 1a: PCE-Initiated Associated Bidirectional SR Path 341 with Forward and Reverse Direction SR Paths 343 +-----+ 344 | PCE | 345 +-----+ 346 PCRpt: ^ ^ PCRpt: 347 Tunnel 1 (F) / \ Tunnel 2 (F) 348 LSP1 (F,100), LSP2 (R,300) / \ LSP2 (F,200), LSP1 (R,400) 349 Association #1 / \ Association #1 350 / \ 351 / \ 352 +-----+ LSP1 +-----+ 353 | S |------------>| D | 354 | |<------------| | 355 +-----+ LSP2 +-----+ 356 358 Legends: F=Forward LSP, R = Reverse LSP, (100,200,300,400)=PLSP-IDs 360 Figure 1b: PCC-Reported Bidirectional SR Path 361 with Forward and Reverse Direction SR Paths 363 4.2. PCC-Initiated Associated Bidirectional SR Paths 365 As specified in [RFC8697], associated bidirectional SR Paths can also 366 be created and updated by a PCC as shown in Figure 2a and 2b. 368 * PCC MAY create and update the forward SR Path and update the 369 reverse SR Path independently for the 'Double-Sided Bidirectional 370 with Reverse LSP Association'. 372 * PCC MUST NOT instantiate a reverse SR Path in a bidirectional SR 373 Path. 375 * PCC MAY establish and remove the association relationship on a per 376 SR Path basis. 378 * PCC MUST report the change in the association group of an SR Path 379 to PCE(s) via PCRpt message. 381 * PCC reports the forward and reverse SR Paths independently to 382 PCE(s) via PCRpt message. 384 * PCC MAY delegate the forward and reverse SR Paths independently to 385 a Stateful PCE, where PCE would control the SR Paths. 387 * Stateful PCE updates the SR Paths in the 'Double-Sided 388 Bidirectional with Reverse LSP Association' via PCUpd message, 389 using the procedures described in [RFC8697]. 391 * The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 392 D as shown in Figure 2b) SHOULD be informed by the PCE via 393 PCInitiate message with the matching association group for the 394 use-cases which require the PCC to be aware of the reverse 395 direction SR Path. 397 +-----+ 398 | PCE | 399 +-----+ 400 Report/Delegate: ^ ^ Report/Delegate: 401 Tunnel 1 (F) / \ Tunnel 2 (F) 402 LSP1 (F,100) / \ LSP2 (F,200) 403 Association #2 / \ Association #2 404 / \ 405 / \ 406 +-----+ LSP1 +-----+ 407 | S |------------>| D | 408 | |<------------| | 409 +-----+ LSP2 +-----+ 410 412 Legends: F = Forward LSP, R = Reverse LSP, (100,200) = PLSP-IDs 414 Figure 2a: Step 1: PCC-Initiated Associated Bidirectional SR 415 Path with Forward Direction SR Paths 416 +-----+ 417 | PCE | 418 +-----+ 419 PCInitiate: / \ PCInitiate: 420 Tunnel 1 (F) / \ Tunnel 2 (F) 421 LSP1 (F,100), LSP2 (R,0) / \ LSP2 (F,200), LSP1 (R,0) 422 Association #2 / \ Association #2 423 / \ 424 v v 425 +-----+ LSP1 +-----+ 426 | S |------------>| D | 427 | |<------------| | 428 +-----+ LSP2 +-----+ 429 431 Legends: F = Forward LSP, R = Reverse LSP, (0,100,200) = PLSP-IDs 433 Figure 2b: Step 2: PCE-Initiated Associated Bidirectional SR 434 Path with Reverse Direction SR Paths 436 +-----+ 437 | PCE | 438 +-----+ 439 PCRpt: ^ ^ PCRpt: 440 Tunnel 1 (F) / \ Tunnel 2 (F) 441 LSP1 (F,100), LSP2 (R,300) / \ LSP2 (F,200), LSP1 (R,400) 442 Association #2 / \ Association #2 443 / \ 444 / \ 445 +-----+ LSP1 +-----+ 446 | S |------------>| D | 447 | |<------------| | 448 +-----+ LSP2 +-----+ 449 451 Legends: F=Forward LSP, R = Reverse LSP, (100,200,300,400)=PLSP-IDs 453 Figure 2c: Step 3: PCC-Reported Associated Bidirectional SR 454 Path with Reverse Direction SR Paths 456 4.3. Stateless PCE 458 As defined in [RFC9059], for a stateless PCE, it might be useful to 459 associate a path computation request to an association group, thus 460 enabling it to associate a common set of configuration parameters or 461 behaviors with the request [RFC8697]. A PCC can request co-routed or 462 non-co-routed forward and reverse direction paths from a stateless 463 PCE for a bidirectional SR Path. 465 4.4. Bidirectional (B) Flag 467 The Bidirectional (B) flag in Request Parameters (RP) object 468 [RFC5440] and Stateful PCE Request Parameter (SRP) object 469 [I-D.ietf-pce-pcep-stateful-pce-gmpls] follow the procedure defined 470 in [RFC9059]. 472 4.5. PLSP-ID Usage 474 For a bidirectional LSP computation when using both direction LSPs on 475 a node, the same LSP would need to be identified using 2 different 476 PLSP-IDs based on the PCEP session to the ingress or the egress node. 477 Note that the PLSP-ID space is independent at each PCC, the PLSP-ID 478 allocated by the egress PCC cannot be used for the LSP at the ingress 479 PCC (PLSP-ID conflict may occur). As per normal PCInitiate 480 operations, PCC assigns the PLSP-IDs for the local LSPs. Hence, when 481 the PCE notifies an ingress PCC of the reverse LSP, it does so by 482 using PCInitiate operations and sets PLSP-ID to zero and sets the R 483 bit in the 'Bidirectional LSP Association Group TLV' in the 484 association object to indicate that this PCInitiate LSP is a reverse 485 LSP. The PCC upon receiving the PCInitiate MUST locally assign a new 486 PLSP-ID and it MUST issue a PCRpt to PCE for this LSP containing the 487 new PLSP-ID. This reverse direction LSP MUST NOT be instantiated on 488 the PCC. 490 In other words, a given LSP will be identified by PLSP-ID A at the 491 ingress node while it will be identified by PLSP-ID B at the egress 492 node. The PCE will maintain two PLSP-IDs for the same LSP. For 493 example, ingress PCC1 may report to PCE an LSP1 with PLSP-ID 100. 494 Egress PCC2 may report to PCE an LSP2 with PLSP-ID 200. Both of 495 these LSPs are part of a bidirectional association. When PCE 496 notifies PCC1 of the reverse direction LSP2, it does so by sending a 497 PCInitiate to PCC1 with PLSP-ID set to zero and R bit set in the 498 'Bidirectional LSP Association Group TLV'. PCC1 upon reception of 499 this generates a new PLSP-ID (example PLSP-ID 300) and issues a PCRpt 500 to PCE. Thus there would two PLSP-ID associated for LSP2 (300 at 501 PCC1 and 200 at PCC2). 503 For an associated bidirectional SR Path, LSP-IDENTIFIERS TLV 504 [RFC8231] MUST be included in all forward and reverse LSPs. 506 4.6. State Synchronization 508 During state synchronization, a PCC MUST report all the existing 509 Bidirectional Associations to the Stateful PCE as per [RFC8697]. 510 After the state synchronization, the PCE MUST remove all stale 511 Bidirectional Associations. 513 4.7. Error Handling 515 The error handling as described in section 5.7 of [RFC9059] continue 516 to apply. 518 The PCEP Path Setup Type (PST) for SR is set to 'TE Path is Setup 519 using Segment Routing' [RFC8408] or 'Path is setup using SRv6' 520 [I-D.ietf-pce-segment-routing-ipv6]. 522 If a PCEP speaker receives a different PST value for the 'Double- 523 Sided Bidirectional with Reverse LSP Association', the PCE speaker 524 MUST return a PCErr message with Error-Type = 26 (Association Error) 525 and Error-value = '16: Path Setup Type not supported' defined in 526 [RFC9059]. 528 5. Implementation Status 530 [Note to the RFC Editor - remove this section before publication, as 531 well as remove the reference to [RFC7942]. 533 This section records the status of known implementations of the 534 protocol defined by this specification at the time of posting of this 535 Internet-Draft, and is based on a proposal described in [RFC7942]. 536 The description of implementations in this section is intended to 537 assist the IETF in its decision processes in progressing drafts to 538 RFCs. Please note that the listing of any individual implementation 539 here does not imply endorsement by the IETF. Furthermore, no effort 540 has been spent to verify the information presented here that was 541 supplied by IETF contributors. This is not intended as, and must not 542 be construed to be, a catalog of available implementations or their 543 features. Readers are advised to note that other implementations may 544 exist. 546 According to [RFC7942], "this will allow reviewers and working groups 547 to assign due consideration to documents that have the benefit of 548 running code, which may serve as evidence of valuable experimentation 549 and feedback that have made the implemented protocols more mature. 550 It is up to the individual working groups to use this information as 551 they see fit". 553 5.1. Huawei's Commercial Delivery 555 The feature is developing based on Huawei VRP8. 557 * Organization: Huawei 559 * Implementation: Huawei's Commercial Delivery implementation based 560 on VRP8. 562 * Description: The implementation is under development. 564 * Maturity Level: Product 566 * Contact: tanren@huawei.com 568 5.2. ZTE's Commercial Delivery 570 * Organization: ZTE 572 * Implementation: ZTE's Commercial Delivery implementation based on 573 Rosng v8. 575 * Description: The implementation is under development. 577 * Maturity Level: Product 579 * Contact: zhan.shuangping@zte.com.cn 581 6. Security Considerations 583 The security considerations described in [RFC5440], [RFC8231], 584 [RFC8281], and [RFC8408] apply to the extensions defined in this 585 document as well. 587 A new Association Type for the Association object, 'Double-Sided 588 Bidirectional with Reverse LSP Association' is introduced in this 589 document. Additional security considerations related to LSP 590 associations due to a malicious PCEP speaker are described in 591 [RFC8697] and apply to this Association Type. Hence, securing the 592 PCEP session using Transport Layer Security (TLS) [RFC8253] is 593 recommended. 595 7. Manageability Considerations 597 All manageability requirements and considerations listed in 598 [RFC5440], [RFC8231], and [RFC8281] apply to PCEP protocol extensions 599 defined in this document. In addition, requirements and 600 considerations listed in this section apply. 602 7.1. Control of Function and Policy 604 The mechanisms defined in this document do not imply any control or 605 policy requirements in addition to those already listed in [RFC5440], 606 [RFC8231], and [RFC8281]. 608 7.2. Information and Data Models 610 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 611 defined for 'Double-Sided Bidirectional with Reverse LSP 612 Associations'. The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines 613 data model for associated bidirectional SR Paths. 615 7.3. Liveness Detection and Monitoring 617 Mechanisms defined in this document do not imply any new liveness 618 detection and monitoring requirements in addition to those already 619 listed in [RFC5440], [RFC8231], and [RFC8281]. 621 7.4. Verify Correct Operations 623 Mechanisms defined in this document do not imply any new operation 624 verification requirements in addition to those already listed in 625 [RFC5440], [RFC8231], and [RFC8408]. 627 7.5. Requirements On Other Protocols 629 Mechanisms defined in this document do not imply any new requirements 630 on other protocols. 632 7.6. Impact On Network Operations 634 Mechanisms defined in [RFC5440], [RFC8231], and [RFC8408] also apply 635 to PCEP extensions defined in this document. 637 8. IANA Considerations 639 8.1. Association Type 641 This document defines a new Association Type, originally described in 642 [RFC8697]. IANA is requested to assign the following new value in 643 the "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path 644 Computation Element Protocol (PCEP) Numbers" registry: 646 Type Name Reference 647 --------------------------------------------------------------------- 648 TBD1 Double-Sided Bidirectional with Reverse [This document] 649 LSP Association 651 9. References 653 9.1. Normative References 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, 657 DOI 10.17487/RFC2119, March 1997, 658 . 660 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 661 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 662 DOI 10.17487/RFC5440, March 2009, 663 . 665 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 666 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 667 May 2017, . 669 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 670 Computation Element Communication Protocol (PCEP) 671 Extensions for Stateful PCE", RFC 8231, 672 DOI 10.17487/RFC8231, September 2017, 673 . 675 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 676 Computation Element Communication Protocol (PCEP) 677 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 678 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 679 . 681 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 682 Dhody, D., and Y. Tanaka, "Path Computation Element 683 Communication Protocol (PCEP) Extensions for Establishing 684 Relationships between Sets of Label Switched Paths 685 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 686 . 688 [RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation 689 Element Communication Protocol (PCEP) Extensions for 690 Associated Bidirectional Label Switched Paths (LSPs)", 691 RFC 9059, DOI 10.17487/RFC9059, June 2021, 692 . 694 9.2. Informative References 696 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 697 "PCEPS: Usage of TLS to Provide a Secure Transport for the 698 Path Computation Element Communication Protocol (PCEP)", 699 RFC 8253, DOI 10.17487/RFC8253, October 2017, 700 . 702 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 703 Decraene, B., Litkowski, S., and R. Shakir, "Segment 704 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 705 July 2018, . 707 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 708 Code: The Implementation Status Section", BCP 205, 709 RFC 7942, DOI 10.17487/RFC7942, July 2016, 710 . 712 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 713 Hardwick, "Path Computation Element Communication Protocol 714 (PCEP) Management Information Base (MIB) Module", 715 RFC 7420, DOI 10.17487/RFC7420, December 2014, 716 . 718 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 719 Hardwick, "Conveying Path Setup Type in PCE Communication 720 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 721 July 2018, . 723 [I-D.ietf-pce-sr-path-segment] 724 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 725 "Path Computation Element Communication Protocol (PCEP) 726 Extension for Path Segment in Segment Routing (SR)", Work 727 in Progress, Internet-Draft, draft-ietf-pce-sr-path- 728 segment-05, 13 February 2022, 729 . 732 [I-D.ietf-pce-segment-routing-ipv6] 733 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 734 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 735 Routing leveraging the IPv6 data plane", Work in Progress, 736 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-11, 10 737 January 2022, . 740 [I-D.ietf-mpls-bfd-directed] 741 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 742 "Bidirectional Forwarding Detection (BFD) Directed Return 743 Path for MPLS Label Switched Paths (LSPs)", Work in 744 Progress, Internet-Draft, draft-ietf-mpls-bfd-directed-19, 745 14 February 2022, . 748 [I-D.ietf-spring-stamp-srpm] 749 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, 750 B., and R. Foote, "Performance Measurement Using Simple 751 TWAMP (STAMP) for Segment Routing Networks", Work in 752 Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-03, 753 1 February 2022, . 756 [I-D.ietf-spring-mpls-path-segment] 757 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 758 "Path Segment in MPLS Based Segment Routing Network", Work 759 in Progress, Internet-Draft, draft-ietf-spring-mpls-path- 760 segment-07, 20 December 2021, 761 . 764 [I-D.ietf-spring-srv6-path-segment] 765 Li, C., Cheng, W., Chen, M., Dhody, D., and Y. Zhu, "Path 766 Segment for SRv6 (Segment Routing in IPv6)", Work in 767 Progress, Internet-Draft, draft-ietf-spring-srv6-path- 768 segment-03, 27 November 2021, 769 . 772 [I-D.ietf-pce-pcep-yang] 773 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 774 "A YANG Data Model for Path Computation Element 775 Communications Protocol (PCEP)", Work in Progress, 776 Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 777 2022, . 780 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 781 Lee, Y., Zheng, H., Dios, O. G. D., Lopez, V., and Z. Ali, 782 "Path Computation Element (PCE) Protocol Extensions for 783 Stateful PCE Usage in GMPLS-controlled Networks", Work in 784 Progress, Internet-Draft, draft-ietf-pce-pcep-stateful- 785 pce-gmpls-17, 10 February 2022, 786 . 789 [I-D.ietf-spring-segment-routing-policy] 790 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 791 P. Mattes, "Segment Routing Policy Architecture", Work in 792 Progress, Internet-Draft, draft-ietf-spring-segment- 793 routing-policy-18, 17 February 2022, 794 . 797 [I-D.ietf-pce-segment-routing-policy-cp] 798 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 799 Bidgoli, "PCEP extension to support Segment Routing Policy 800 Candidate Paths", Work in Progress, Internet-Draft, draft- 801 ietf-pce-segment-routing-policy-cp-06, 22 October 2021, 802 . 805 [I-D.ietf-pce-multipath] 806 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 807 Bidgoli, H., Yadav, B., Peng, S., and G. Mishra, "PCEP 808 Extensions for Signaling Multipath Information", Work in 809 Progress, Internet-Draft, draft-ietf-pce-multipath-04, 25 810 February 2022, . 813 Acknowledgments 815 Many thanks to Marina Fizgeer, Adrian Farrel, Andrew Stone, Tarek 816 Saad, and Mike Koldychev for the detailed review of this document and 817 providing many useful comments. 819 Contributors 821 The following people have substantially contributed to this document: 823 Dhruv Dhody 824 Huawei Technologies 825 Divyashree Techno Park, Whitefield 826 Bangalore, Karnataka 560066 827 India 829 Email: dhruv.ietf@gmail.com 831 Zhenbin Li 832 Huawei Technologies 833 Huawei Campus, No. 156 Beiqing Rd. 834 Beijing 100095 835 China 837 Email: lizhenbin@huawei.com 839 Jie Dong 840 Huawei Technologies 841 Huawei Campus, No. 156 Beiqing Rd. 842 Beijing 100095 843 China 845 Email: jie.dong@huawei.com 847 Authors' Addresses 849 Cheng Li 850 Huawei Technologies 851 Huawei Campus, No. 156 Beiqing Rd. 852 Beijing 853 100095 854 China 855 Email: c.l@huawei.com 857 Mach(Guoyi) Chen 858 Huawei Technologies 859 Huawei Campus, No. 156 Beiqing Rd. 860 Beijing 861 100095 862 China 863 Email: Mach.chen@huawei.com 864 Weiqiang Cheng 865 China Mobile 866 China 867 Email: chengweiqiang@chinamobile.com 869 Rakesh Gandhi 870 Cisco Systems, Inc. 871 Canada 872 Email: rgandhi@cisco.com 874 Quan Xiong 875 ZTE Corporation 876 China 877 Email: xiong.quan@zte.com.cn