idnits 2.17.1 draft-ietf-pce-sr-bidir-path-05.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 (January 27, 2021) is 1179 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 (-25) exists of draft-ietf-pce-segment-routing-ipv6-08 == Outdated reference: A later version (-14) exists of draft-ietf-pce-association-bidir-10 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-02 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-15 == Outdated reference: A later version (-07) exists of draft-gandhi-spring-stamp-srpm-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-03 == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-00 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-15 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-02 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: July 31, 2021 W. Cheng 6 China Mobile 7 R. Gandhi 8 Cisco Systems, Inc. 9 Q. Xiong 10 ZTE Corporation 11 January 27, 2021 13 Path Computation Element Communication Protocol (PCEP) Extensions for 14 Associated Bidirectional Segment Routing (SR) Paths 15 draft-ietf-pce-sr-bidir-path-05 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, as well as when using a Stateless 32 PCE. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 31, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Double-sided Bidirectional with Reverse LSP 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 . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . 14 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 93 8.1. Association Type . . . . . . . . . . . . . . . . . . . . 14 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 96 9.2. Informative References . . . . . . . . . . . . . . . . . 16 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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.gandhi-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 [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping 142 two unidirectional Resource Reservation Protocol - Traffic 143 Engineering (RSVP-TE) LSPs into an Associated Bidirectional LSP when 144 using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as 145 well as when using a Stateless PCE. Specifically, it defines the 146 procedure for 'Double-sided Bidirectional LSP Association', where the 147 PCE creates the association and provisions the forward LSPs at their 148 ingress nodes. The RSVP-TE signals the forward LSPs to the egress 149 nodes. Thus, both endpoints learn the reverse LSPs forming the 150 bidirectional LSP 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 An SR Policy may contain one or more Candidate-Paths (CPs), each 162 Candidate-Path may contain one or more Segment Lists (SLs) 163 [I-D.ietf-spring-segment-routing-policy]. Recall that in PCEP, an 164 LSP identifies a Candidate-Path as described in 165 [I-D.ietf-pce-segment-routing-policy-cp]. Two unidirectional 166 Candidate-Paths containing a single Segment List (two unidirectional 167 Segment Lists) are associated to form a bidirectional Candidate-Path 168 using the procedures defined in this document. Association of two 169 unidirectional Candidate-Paths containing multiple Segment Lists to 170 form a bidirectional Candidate-Path are outside the scope of this 171 document. 173 2. Terminology 175 This document makes use of the terms defined in [RFC8408]. The 176 reader is assumed to be familiar with the terminology defined in 177 [RFC5440], [RFC8231], [RFC8281], [RFC8697], and 178 [I-D.ietf-pce-association-bidir]. 180 2.1. Requirements Language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL" in this document are to be interpreted as described in BCP 185 14 [RFC2119] [RFC8174] when, and only when, they appear in all 186 capitals, as shown here. 188 3. PCEP Extensions 190 As per [RFC8697], TE LSPs are associated by adding them to a common 191 association group by a PCEP peer. [I-D.ietf-pce-association-bidir] 192 uses the association group object and the procedures as specified in 193 [RFC8697] to group two unidirectional RSVP-TE LSPs. Similarly, two 194 SR Paths can also be associated using similar technique. This 195 document extends these association mechanisms for bidirectional SR 196 Paths. Two unidirectional SR Paths (one in each direction in the 197 network) can be associated together by using the association group 198 defined in this document for PCEP messages. 200 [I-D.ietf-pce-sr-path-segment] defines a mechanism for communicating 201 Path Segment Identifier (PSID) in PCEP for SR. The SR-MPLS PSID is 202 defined in [I-D.ietf-spring-mpls-path-segment] and SRv6 PSID is 203 defined in [I-D.ietf-spring-srv6-path-segment]. The PSID can be used 204 for identifying an SR Path of an associated bidirectional SR Path. 205 The PATH-SEGMENT TLV MAY be included for each SR Path in the LSP 206 object to support required use-cases. The PATH-SEGMENT TLV MUST be 207 handled as defined in [I-D.ietf-pce-sr-path-segment] and is not 208 modified for associated bidirectional SR Path. 210 3.1. Double-sided Bidirectional with Reverse LSP Association 212 For associating two unidirectional SR Paths, this document defines a 213 new Association Type called 'Double-sided Bidirectional with Reverse 214 LSP Association' for Association Group Object (Class-Value 40) as 215 follows: 217 o Association Type (TBD1 to be assigned by IANA) = Double-sided 218 Bidirectional with Reverse LSP Association 220 The Bidirectional Association is considered to be both dynamic and 221 operator-configured in nature. As per [RFC8697], the association 222 group could be manually created by the operator on the PCEP peers, 223 and the LSPs belonging to this association are conveyed via PCEP 224 messages to the PCEP peer; alternately, the association group could 225 be created dynamically by the PCEP speaker, and both the association 226 group information and the LSPs belonging to the association group are 227 conveyed to the PCEP peer. The Operator-configured Association Range 228 MUST be set for this association-type to mark a range of Association 229 Identifiers that are used for operator-configured associations to 230 avoid any Association Identifier clash within the scope of the 231 Association Source (Refer to [RFC8697]). Specifically, for the PCE 232 Initiated Associated Bidirectional SR Paths, the Association Type is 233 dynamically created by the PCE on the PCE peers. 235 The handling of the Association ID, Association Source, optional 236 Global Association Source and optional Extended Association ID in 237 this association are set in the same way as 238 [I-D.ietf-pce-association-bidir]. 240 [RFC8697] specifies the mechanism for the capability advertisement of 241 the Association Types supported by a PCEP speaker by defining an 242 ASSOC-Type-List TLV to be carried within an OPEN Object. This 243 capability exchange for the Bidirectional Association MUST be done 244 before using the Bidirectional Association Type. Thus, the PCEP 245 speaker MUST include the Bidirectional Association Type in the ASSOC- 246 Type-List TLV and MUST receive the same from the PCEP peer before 247 using the Bidirectional Association in PCEP messages. 249 A member of the 'Double-sided Bidirectional with Reverse LSP 250 Association' can take the role of a forward or reverse direction SR 251 Path and follow the similar rules defined in 252 [I-D.ietf-pce-association-bidir] for LSPs. 254 o An SR Path (forward or reverse) MUST NOT be part of more than one 255 'Double-sided Bidirectional with Reverse LSP Association'. 257 o The endpoint nodes of the SR Paths in 'Double-sided Bidirectional 258 with Reverse LSP Association' MUST be matching in the reverse 259 directions. 261 3.1.1. Bidirectional LSP Association Group TLV 263 In 'Double-sided Bidirectional with Reverse LSP Association', for 264 properties such as forward and reverse direction and co-routed path, 265 it uses the 'Bidirectional LSP Association Group TLV' defined in 266 [I-D.ietf-pce-association-bidir]. All fields and processing rules 267 are as per [I-D.ietf-pce-association-bidir]. 269 4. PCEP Procedures 271 For an Associated Bidirectional SR Path, an ingress node PCC is aware 272 of the forward direction SR Path beginning from itself to the egress 273 node PCC using the existing PCEP procedures. For the use-cases which 274 require the ingress node PCC to be aware of the reverse direction SR 275 Path, PCE informs the reverse SR Path to the ingress node PCC. To 276 achieve this, a PCInitiate message for the reverse SR Path is sent to 277 the ingress node PCC and a PCInitiate message for the forward SR Path 278 is sent to the egress node PCC (with the matching association group). 279 These PCInitiate message MUST NOT trigger initiation of SR Paths on 280 PCCs. 282 The PCEP procedure defined in this document is applicable to the 283 following three scenarios: 285 o Neither unidirectional LSP exists, and both must be established. 287 o Both unidirectional LSPs exist, but the association must be 288 established. 290 o One LSP exists, but the reverse associated LSP must be 291 established. 293 4.1. PCE Initiated Associated Bidirectional SR Paths 295 As specified in [RFC8697], Associated Bidirectional SR Paths can be 296 created and updated by a Stateful PCE as shown in Figure 1. 298 o Stateful PCE MAY create and update the forward and reverse SR 299 Paths independently for the 'Double-sided Bidirectional with 300 Reverse LSP Association'. 302 o Stateful PCE MAY establish and remove the association relationship 303 on a per SR Path basis. 305 o Stateful PCE MUST create and update the SR Path and the 306 association on a PCC via PCInitiate and PCUpd messages, 307 respectively, using the procedures described in [RFC8697]. 309 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 310 D as shown in Figure 1) SHOULD be informed by the PCE via 311 PCInitiate message with the matching association group for the 312 use-cases which require the PCC to be aware of the reverse 313 direction SR Path. 315 +-----+ 316 | PCE | 317 +-----+ 318 PCInitiate: / \ PCInitiate: 319 Tunnel 1 (F) / \ Tunnel 2 (F) 320 LSP1 (F,0), LSP2 (R,0) / \ LSP2 (F,0), LSP1 (R,0) 321 Association #1 / \ Association #1 322 / \ 323 v v 324 +-----+ LSP1 +-----+ 325 | S |------------>| D | 326 | |<------------| | 327 +-----+ LSP2 +-----+ 328 330 Legends: F = Forward LSP, R = Reverse LSP, (0) = PLSP-IDs 332 Figure 1a: PCE-Initiated Associated Bidirectional SR Path 333 with Forward and Reverse Direction SR Paths 335 +-----+ 336 | PCE | 337 +-----+ 338 PCRpt: ^ ^ PCRpt: 339 Tunnel 1 (F) / \ Tunnel 2 (F) 340 LSP1 (F,100), LSP2 (R,300) / \ LSP2 (F,200), LSP1 (R,400) 341 Association #1 / \ Association #1 342 / \ 343 / \ 344 +-----+ LSP1 +-----+ 345 | S |------------>| D | 346 | |<------------| | 347 +-----+ LSP2 +-----+ 348 350 Legends: F=Forward LSP, R = Reverse LSP, (100,200,300,400)=PLSP-IDs 352 Figure 1b: PCC-Reported Bidirectional SR Path 353 with Forward and Reverse Direction SR Paths 355 4.2. PCC Initiated Associated Bidirectional SR Paths 357 As specified in [RFC8697], Associated Bidirectional SR Paths can also 358 be created and updated by a PCC as shown in Figure 2a and 2b. 360 o PCC MAY create and update the forward SR Path and update the 361 reverse SR Path independently for the 'Double-sided Bidirectional 362 with Reverse LSP Association'. 364 o PCC MUST NOT instantiate a reverse SR Path in a bidirectional SR 365 Path. 367 o PCC MAY establish and remove the association relationship on a per 368 SR Path basis. 370 o PCC MUST report the change in the association group of an SR Path 371 to PCE(s) via PCRpt message. 373 o PCC reports the forward and reverse SR Paths independently to 374 PCE(s) via PCRpt message. 376 o PCC MAY delegate the forward and reverse SR Paths independently to 377 a Stateful PCE, where PCE would control the SR Paths. 379 o Stateful PCE updates the SR Paths in the 'Double-sided 380 Bidirectional with Reverse LSP Association' via PCUpd message, 381 using the procedures described in [RFC8697]. 383 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 384 D as shown in Figure 2b) SHOULD be informed by the PCE via 385 PCInitiate message with the matching association group for the 386 use-cases which require the PCC to be aware of the reverse 387 direction SR Path. 389 +-----+ 390 | PCE | 391 +-----+ 392 Report/Delegate: ^ ^ Report/Delegate: 393 Tunnel 1 (F) / \ Tunnel 2 (F) 394 LSP1 (F,100) / \ LSP2 (F,200) 395 Association #2 / \ Association #2 396 / \ 397 / \ 398 +-----+ LSP1 +-----+ 399 | S |------------>| D | 400 | |<------------| | 401 +-----+ LSP2 +-----+ 402 404 Legends: F = Forward LSP, R = Reverse LSP, (100,200) = PLSP-IDs 406 Figure 2a: Step 1: PCC-Initiated Associated Bidirectional SR 407 Path with Forward Direction SR Paths 408 +-----+ 409 | PCE | 410 +-----+ 411 PCInitiate: / \ PCInitiate: 412 Tunnel 1 (F) / \ Tunnel 2 (F) 413 LSP1 (F,100), LSP2 (R,0) / \ LSP2 (F,200), LSP1 (R,0) 414 Association #2 / \ Association #2 415 / \ 416 v v 417 +-----+ LSP1 +-----+ 418 | S |------------>| D | 419 | |<------------| | 420 +-----+ LSP2 +-----+ 421 423 Legends: F = Forward LSP, R = Reverse LSP, (0,100,200) = PLSP-IDs 425 Figure 2b: Step 2: PCE-Initiated Associated Bidirectional SR 426 Path with Reverse Direction SR Paths 428 +-----+ 429 | PCE | 430 +-----+ 431 PCRpt: ^ ^ PCRpt: 432 Tunnel 1 (F) / \ Tunnel 2 (F) 433 LSP1 (F,100), LSP2 (R,300) / \ LSP2 (F,200), LSP1 (R,400) 434 Association #2 / \ Association #2 435 / \ 436 / \ 437 +-----+ LSP1 +-----+ 438 | S |------------>| D | 439 | |<------------| | 440 +-----+ LSP2 +-----+ 441 443 Legends: F=Forward LSP, R = Reverse LSP, (100,200,300,400)=PLSP-IDs 445 Figure 2c: Step 3: PCC-Reported Associated Bidirectional SR 446 Path with Reverse Direction SR Paths 448 4.3. Stateless PCE 450 As defined in [I-D.ietf-pce-association-bidir], for a stateless PCE, 451 it might be useful to associate a path computation request to an 452 association group, thus enabling it to associate a common set of 453 configuration parameters or behaviors with the request [RFC8697]. A 454 PCC can request co-routed or non-co-routed forward and reverse 455 direction paths from a stateless PCE for a Bidirectional SR Path. 457 4.4. Bidirectional (B) Flag 459 The Bidirectional (B) flag in Request Parameters (RP) object 460 [RFC5440] and Stateful PCE Request Parameter (SRP) object 461 [I-D.ietf-pce-pcep-stateful-pce-gmpls] follow the procedure defined 462 in [I-D.ietf-pce-association-bidir]. 464 4.5. PLSP-ID Usage 466 For a bidirectional LSP computation when using both direction LSPs on 467 a node, the same LSP would need to be identified using 2 different 468 PLSP-IDs based on the PCEP session to the ingress or the egress node. 469 Note that the PLSP-ID space is independent at each PCC, the PLSP-ID 470 allocated by the egress PCC cannot be used for the LSP at the ingress 471 PCC (PLSP-ID conflict may occur). As per normal PCInitiate 472 operations, PCC assigns the PLSP-IDs for the local LSPs. Hence, when 473 the PCE notifies an ingress PCC of the reverse LSP, it does so by 474 using PCInitiate operations and sets PLSP-ID to zero and sets the R 475 bit in the 'Bidirectional LSP Association Group TLV' in the 476 association object to indicate that this PCInitiate LSP is a reverse 477 LSP. The PCC upon receiving the PCInitiate MUST locally assign a new 478 PLSP-ID and it MUST issue a PCRpt to PCE for this LSP containing the 479 new PLSP-ID. This reverse direction LSP MUST NOT be instantiated on 480 the PCC. 482 In other words, a given LSP will be identified by PLSP-ID A at the 483 ingress node while it will be identified by PLSP-ID B at the egress 484 node. The PCE will maintain two PLSP-IDs for the same LSP. For 485 example, ingress PCC1 may report to PCE an LSP1 with PLSP-ID 100. 486 Egress PCC2 may report to PCE an LSP2 with PLSP-ID 200. Both of 487 these LSPs are part of a bidirectional association. When PCE 488 notifies PCC1 of the reverse direction LSP2, it does so by sending a 489 PCInitiate to PCC1 with PLSP-ID set to zero and R bit set in the 490 'Bidirectional LSP Association Group TLV'. PCC1 upon reception of 491 this generates a new PLSP-ID (example PLSP-ID 300) and issues a PCRpt 492 to PCE. Thus there would two PLSP-ID associated for LSP2 (300 at 493 PCC1 and 200 at PCC2). 495 For an Associated Bidirectional SR Path, LSP-IDENTIFIERS TLV 496 [RFC8231] MUST be included in all forward and reverse LSPs. 498 4.6. State Synchronization 500 During state synchronization, a PCC MUST report all the existing 501 Bidirectional Associations to the Stateful PCE as per [RFC8697]. 502 After the state synchronization, the PCE MUST remove all stale 503 Bidirectional Associations. 505 4.7. Error Handling 507 The error handling as described in section 5.7 of 508 [I-D.ietf-pce-association-bidir] continue to apply. 510 The PCEP Path Setup Type (PST) for SR is set to 'TE Path is Setup 511 using Segment Routing' [RFC8408] or 'Path is setup using SRv6' 512 [I-D.ietf-pce-segment-routing-ipv6]. 514 If a PCEP speaker receives a different PST value for the 'Double- 515 sided Bidirectional with Reverse LSP Association', the PCE speaker 516 MUST return a PCErr message with Error-Type = 26 (Association Error) 517 and Error-Value = 'Bidirectional LSP Association - Path Setup Type 518 Not Supported' defined in [I-D.ietf-pce-association-bidir]. 520 5. Implementation Status 522 [Note to the RFC Editor - remove this section before publication, as 523 well as remove the reference to [RFC7942]. 525 This section records the status of known implementations of the 526 protocol defined by this specification at the time of posting of this 527 Internet-Draft, and is based on a proposal described in [RFC7942]. 528 The description of implementations in this section is intended to 529 assist the IETF in its decision processes in progressing drafts to 530 RFCs. Please note that the listing of any individual implementation 531 here does not imply endorsement by the IETF. Furthermore, no effort 532 has been spent to verify the information presented here that was 533 supplied by IETF contributors. This is not intended as, and must not 534 be construed to be, a catalog of available implementations or their 535 features. Readers are advised to note that other implementations may 536 exist. 538 According to [RFC7942], "this will allow reviewers and working groups 539 to assign due consideration to documents that have the benefit of 540 running code, which may serve as evidence of valuable experimentation 541 and feedback that have made the implemented protocols more mature. 542 It is up to the individual working groups to use this information as 543 they see fit". 545 5.1. Huawei's Commercial Delivery 547 The feature is developing based on Huawei VRP8. 549 o Organization: Huawei 551 o Implementation: Huawei's Commercial Delivery implementation based 552 on VRP8. 554 o Description: The implementation is under development. 556 o Maturity Level: Product 558 o Contact: tanren@huawei.com 560 5.2. ZTE's Commercial Delivery 562 o Organization: ZTE 564 o Implementation: ZTE's Commercial Delivery implementation based on 565 Rosng v8. 567 o Description: The implementation is under development. 569 o Maturity Level: Product 571 o Contact: zhan.shuangping@zte.com.cn 573 6. Security Considerations 575 The security considerations described in [RFC5440], [RFC8231], 576 [RFC8281], and [RFC8408] apply to the extensions defined in this 577 document as well. 579 A new Association Type for the Association Object, 'Double-sided 580 Bidirectional with Reverse LSP Association' is introduced in this 581 document. Additional security considerations related to LSP 582 associations due to a malicious PCEP speaker is described in 583 [RFC8697] and apply to this Association Type. Hence, securing the 584 PCEP session using Transport Layer Security (TLS) [RFC8253] is 585 recommended. 587 7. Manageability Considerations 589 All manageability requirements and considerations listed in 590 [RFC5440], [RFC8231], and [RFC8281] apply to PCEP protocol extensions 591 defined in this document. In addition, requirements and 592 considerations listed in this section apply. 594 7.1. Control of Function and Policy 596 The mechanisms defined in this document do not imply any control or 597 policy requirements in addition to those already listed in [RFC5440], 598 [RFC8231], and [RFC8281]. 600 7.2. Information and Data Models 602 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 603 defined for 'Double-sided Bidirectional with Reverse LSP 604 Associations'. The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines 605 data model for Associated Bidirectional SR Paths. 607 7.3. Liveness Detection and Monitoring 609 Mechanisms defined in this document do not imply any new liveness 610 detection and monitoring requirements in addition to those already 611 listed in [RFC5440], [RFC8231], and [RFC8281]. 613 7.4. Verify Correct Operations 615 Mechanisms defined in this document do not imply any new operation 616 verification requirements in addition to those already listed in 617 [RFC5440], [RFC8231], and [RFC8408]. 619 7.5. Requirements On Other Protocols 621 Mechanisms defined in this document do not imply any new requirements 622 on other protocols. 624 7.6. Impact On Network Operations 626 Mechanisms defined in [RFC5440], [RFC8231], and [RFC8408] also apply 627 to PCEP extensions defined in this document. 629 8. IANA Considerations 631 8.1. Association Type 633 This document defines a new Association Type, originally described in 634 [RFC8697]. IANA is requested to assign the following new value in 635 the "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path 636 Computation Element Protocol (PCEP) Numbers" registry: 638 Type Name Reference 639 --------------------------------------------------------------------- 640 TBD1 Double-sided Bidirectional with Reverse [This document] 641 LSP Association 643 9. References 645 9.1. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, 650 . 652 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 653 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 654 DOI 10.17487/RFC5440, March 2009, 655 . 657 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 658 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 659 May 2017, . 661 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 662 Computation Element Communication Protocol (PCEP) 663 Extensions for Stateful PCE", RFC 8231, 664 DOI 10.17487/RFC8231, September 2017, 665 . 667 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 668 Computation Element Communication Protocol (PCEP) 669 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 670 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 671 . 673 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 674 Dhody, D., and Y. Tanaka, "Path Computation Element 675 Communication Protocol (PCEP) Extensions for Establishing 676 Relationships between Sets of Label Switched Paths 677 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 678 . 680 [I-D.ietf-pce-segment-routing-ipv6] 681 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 682 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 683 Routing leveraging the IPv6 data plane", draft-ietf-pce- 684 segment-routing-ipv6-08 (work in progress), November 2020. 686 [I-D.ietf-pce-association-bidir] 687 Gandhi, R., Barth, C., and B. Wen, "Path Computation 688 Element Communication Protocol (PCEP) Extensions for 689 Associated Bidirectional Label Switched Paths (LSPs)", 690 draft-ietf-pce-association-bidir-10 (work in progress), 691 January 2021. 693 [I-D.ietf-pce-sr-path-segment] 694 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 695 "Path Computation Element Communication Protocol (PCEP) 696 Extension for Path Segment in Segment Routing (SR)", 697 draft-ietf-pce-sr-path-segment-02 (work in progress), 698 November 2020. 700 9.2. Informative References 702 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 703 "PCEPS: Usage of TLS to Provide a Secure Transport for the 704 Path Computation Element Communication Protocol (PCEP)", 705 RFC 8253, DOI 10.17487/RFC8253, October 2017, 706 . 708 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 709 Decraene, B., Litkowski, S., and R. Shakir, "Segment 710 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 711 July 2018, . 713 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 714 Code: The Implementation Status Section", BCP 205, 715 RFC 7942, DOI 10.17487/RFC7942, July 2016, 716 . 718 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 719 Hardwick, "Path Computation Element Communication Protocol 720 (PCEP) Management Information Base (MIB) Module", 721 RFC 7420, DOI 10.17487/RFC7420, December 2014, 722 . 724 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 725 Hardwick, "Conveying Path Setup Type in PCE Communication 726 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 727 July 2018, . 729 [I-D.ietf-mpls-bfd-directed] 730 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 731 "Bidirectional Forwarding Detection (BFD) Directed Return 732 Path for MPLS Label Switched Paths (LSPs)", draft-ietf- 733 mpls-bfd-directed-15 (work in progress), August 2020. 735 [I-D.gandhi-spring-stamp-srpm] 736 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 737 Janssens, "Performance Measurement Using Simple TWAMP 738 (STAMP) for Segment Routing Networks", draft-gandhi- 739 spring-stamp-srpm-04 (work in progress), January 2021. 741 [I-D.ietf-spring-mpls-path-segment] 742 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 743 "Path Segment in MPLS Based Segment Routing Network", 744 draft-ietf-spring-mpls-path-segment-03 (work in progress), 745 September 2020. 747 [I-D.ietf-spring-srv6-path-segment] 748 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 749 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 750 ietf-spring-srv6-path-segment-00 (work in progress), 751 November 2020. 753 [I-D.ietf-pce-pcep-yang] 754 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 755 YANG Data Model for Path Computation Element 756 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 757 yang-15 (work in progress), October 2020. 759 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 760 Lee, Y., Zheng, H., Dios, O., Lopez, V., and Z. Ali, "Path 761 Computation Element (PCE) Protocol Extensions for Stateful 762 PCE Usage in GMPLS-controlled Networks", draft-ietf-pce- 763 pcep-stateful-pce-gmpls-14 (work in progress), December 764 2020. 766 [I-D.ietf-spring-segment-routing-policy] 767 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 768 P. Mattes, "Segment Routing Policy Architecture", draft- 769 ietf-spring-segment-routing-policy-09 (work in progress), 770 November 2020. 772 [I-D.ietf-pce-segment-routing-policy-cp] 773 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 774 Bidgoli, "PCEP extension to support Segment Routing Policy 775 Candidate Paths", draft-ietf-pce-segment-routing-policy- 776 cp-02 (work in progress), January 2021. 778 Acknowledgments 780 Many thanks to Marina Fizgeer, Adrian Farrel, Andrew Stone, and Tarek 781 Saad for the detailed review of this document and providing many 782 useful comments. 784 Contributors 786 The following people have substantially contributed to this document: 788 Dhruv Dhody 789 Huawei Technologies 790 Divyashree Techno Park, Whitefield 791 Bangalore, Karnataka 560066 792 India 794 Email: dhruv.ietf@gmail.com 796 Zhenbin Li 797 Huawei Technologies 798 Huawei Campus, No. 156 Beiqing Rd. 799 Beijing 100095 800 China 802 Email: lizhenbin@huawei.com 804 Jie Dong 805 Huawei Technologies 806 Huawei Campus, No. 156 Beiqing Rd. 807 Beijing 100095 808 China 810 Email: jie.dong@huawei.com 812 Authors' Addresses 814 Cheng Li 815 Huawei Technologies 816 Huawei Campus, No. 156 Beiqing Rd. 817 Beijing 100095 818 China 820 Email: c.l@huawei.com 821 Mach(Guoyi) Chen 822 Huawei Technologies 823 Huawei Campus, No. 156 Beiqing Rd. 824 Beijing 100095 825 China 827 Email: Mach.chen@huawei.com 829 Weiqiang Cheng 830 China Mobile 831 China 833 Email: chengweiqiang@chinamobile.com 835 Rakesh Gandhi 836 Cisco Systems, Inc. 837 Canada 839 Email: rgandhi@cisco.com 841 Quan Xiong 842 ZTE Corporation 843 China 845 Email: xiong.quan@zte.com.cn