idnits 2.17.1 draft-ietf-pce-sr-bidir-path-07.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 (July 12, 2021) is 1011 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-03 == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-09 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-17 == Outdated reference: A later version (-14) exists of draft-ietf-spring-stamp-srpm-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-04 == 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-16 == 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-11 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-04 Summary: 0 errors (**), 0 flaws (~~), 11 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: January 13, 2022 W. Cheng 6 China Mobile 7 R. Gandhi 8 Cisco Systems, Inc. 9 Q. Xiong 10 ZTE Corporation 11 July 12, 2021 13 Path Computation Element Communication Protocol (PCEP) Extensions for 14 Associated Bidirectional Segment Routing (SR) Paths 15 draft-ietf-pce-sr-bidir-path-07 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." 48 This Internet-Draft will expire on January 13, 2022. 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 . . . . . . . . . . . . . . . . . . . . . . . 4 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.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 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 [RFC9059]. 179 2.1. Requirements Language 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in BCP 184 14 [RFC2119] [RFC8174] when, and only when, they appear in all 185 capitals, as shown here. 187 3. PCEP Extensions 189 As per [RFC8697], TE LSPs are associated by adding them to a common 190 association group by a PCEP peer. [RFC9059] uses the association 191 group object and the procedures as specified in [RFC8697] to group 192 two unidirectional RSVP-TE LSPs. Similarly, two SR Paths can also be 193 associated using similar technique. This document extends these 194 association mechanisms for bidirectional SR Paths. Two 195 unidirectional SR Paths (one in each direction in the network) can be 196 associated together by using the association group defined in this 197 document for PCEP messages. 199 [I-D.ietf-pce-sr-path-segment] defines a mechanism for communicating 200 Path Segment Identifier (PSID) in PCEP for SR. The SR-MPLS PSID is 201 defined in [I-D.ietf-spring-mpls-path-segment] and SRv6 PSID is 202 defined in [I-D.ietf-spring-srv6-path-segment]. The PSID can be used 203 for identifying an SR Path of an associated bidirectional SR Path. 204 The PATH-SEGMENT TLV MAY be included for each SR Path in the LSP 205 object to support required use-cases. The PATH-SEGMENT TLV MUST be 206 handled as defined in [I-D.ietf-pce-sr-path-segment] and is not 207 modified for associated bidirectional SR Path. 209 3.1. Double-Sided Bidirectional with Reverse LSP Association 211 For associating two unidirectional SR Paths, this document defines a 212 new Association Type called 'Double-Sided Bidirectional with Reverse 213 LSP Association' for Association Group object (Class-Value 40) as 214 follows: 216 o Association Type (TBD1 to be assigned by IANA) = Double-Sided 217 Bidirectional with Reverse LSP Association 219 The bidirectional association is considered to be both dynamic and 220 operator-configured in nature. As per [RFC8697], the association 221 group could be manually created by the operator on the PCEP peers, 222 and the LSPs belonging to this association are conveyed via PCEP 223 messages to the PCEP peer; alternately, the association group could 224 be created dynamically by the PCEP speaker, and both the association 225 group information and the LSPs belonging to the association group are 226 conveyed to the PCEP peer. The Operator-configured Association Range 227 MUST be set for this Association Type to mark a range of Association 228 Identifiers that are used for operator-configured associations to 229 avoid any Association Identifier clash within the scope of the 230 Association Source (Refer to [RFC8697]). Specifically, for the PCE- 231 initiated associated bidirectional SR Paths, the Association Type is 232 dynamically created by the PCE on the PCE peers. 234 The handling of the Association ID, Association Source, optional 235 Global Association Source and optional Extended Association ID in 236 this association are set in the same way as [RFC9059]. 238 [RFC8697] specifies the mechanism for the capability advertisement of 239 the Association Types supported by a PCEP speaker by defining an 240 ASSOC-Type-List TLV (value 35) to be carried within an OPEN object. 241 This capability exchange for the Bidirectional Association MUST be 242 done before using the Bidirectional Association Type. Thus, the PCEP 243 speaker MUST include the bidirectional Association Type in the ASSOC- 244 Type-List TLV and MUST receive the same from the PCEP peer before 245 using the Bidirectional Association in PCEP messages. 247 A member of the 'Double-Sided Bidirectional with Reverse LSP 248 Association' can take the role of a forward or reverse direction SR 249 Path and follow the similar rules defined in [RFC9059] for LSPs. 251 o An SR Path (forward or reverse) MUST NOT be part of more than one 252 'Double-Sided Bidirectional with Reverse LSP Association'. 254 o The endpoint nodes of the SR Paths in 'Double-Sided Bidirectional 255 with Reverse LSP Association' MUST be matching in the reverse 256 directions. 258 3.1.1. Bidirectional LSP Association Group TLV 260 In 'Double-Sided Bidirectional with Reverse LSP Association', for 261 properties such as forward and reverse direction and co-routed path, 262 it uses the 'Bidirectional LSP Association Group TLV' defined in 263 [RFC9059]. All fields and processing rules are as per [RFC9059]. 265 4. PCEP Procedures 267 For an associated bidirectional SR Path, an ingress node PCC is aware 268 of the forward direction SR Path beginning from itself to the egress 269 node PCC using the existing PCEP procedures. For the use-cases which 270 require the ingress node PCC to be aware of the reverse direction SR 271 Path, PCE informs the reverse SR Path to the ingress node PCC. To 272 achieve this, a PCInitiate message for the reverse SR Path is sent to 273 the ingress node PCC and a PCInitiate message for the forward SR Path 274 is sent to the egress node PCC (with the matching association group). 275 These PCInitiate message MUST NOT trigger initiation of SR Paths on 276 PCCs. 278 The PCEP procedure defined in this document is applicable to the 279 following three scenarios: 281 o Neither unidirectional LSP exists, and both must be established. 283 o Both unidirectional LSPs exist, but the association must be 284 established. 286 o One LSP exists, but the reverse associated LSP must be 287 established. 289 4.1. PCE-Initiated Associated Bidirectional SR Paths 291 As specified in [RFC8697], associated bidirectional SR Paths can be 292 created and updated by a Stateful PCE as shown in Figure 1. 294 o Stateful PCE MAY create and update the forward and reverse SR 295 Paths independently for the 'Double-Sided Bidirectional with 296 Reverse LSP Association'. 298 o Stateful PCE MAY establish and remove the association relationship 299 on a per SR Path basis. 301 o Stateful PCE MUST create and update the SR Path and the 302 association on a PCC via PCInitiate and PCUpd messages, 303 respectively, using the procedures described in [RFC8697]. 305 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 306 D as shown in Figure 1) SHOULD be informed by the PCE via 307 PCInitiate message with the matching association group for the 308 use-cases which require the PCC to be aware of the reverse 309 direction SR Path. 311 +-----+ 312 | PCE | 313 +-----+ 314 PCInitiate: / \ PCInitiate: 315 Tunnel 1 (F) / \ Tunnel 2 (F) 316 LSP1 (F,0), LSP2 (R,0) / \ LSP2 (F,0), LSP1 (R,0) 317 Association #1 / \ Association #1 318 / \ 319 v v 320 +-----+ LSP1 +-----+ 321 | S |------------>| D | 322 | |<------------| | 323 +-----+ LSP2 +-----+ 324 326 Legends: F = Forward LSP, R = Reverse LSP, (0) = PLSP-IDs 328 Figure 1a: PCE-Initiated Associated Bidirectional SR Path 329 with Forward and Reverse Direction SR Paths 331 +-----+ 332 | PCE | 333 +-----+ 334 PCRpt: ^ ^ PCRpt: 335 Tunnel 1 (F) / \ Tunnel 2 (F) 336 LSP1 (F,100), LSP2 (R,300) / \ LSP2 (F,200), LSP1 (R,400) 337 Association #1 / \ Association #1 338 / \ 339 / \ 340 +-----+ LSP1 +-----+ 341 | S |------------>| D | 342 | |<------------| | 343 +-----+ LSP2 +-----+ 344 346 Legends: F=Forward LSP, R = Reverse LSP, (100,200,300,400)=PLSP-IDs 348 Figure 1b: PCC-Reported Bidirectional SR Path 349 with Forward and Reverse Direction SR Paths 351 4.2. PCC-Initiated Associated Bidirectional SR Paths 353 As specified in [RFC8697], associated bidirectional SR Paths can also 354 be created and updated by a PCC as shown in Figure 2a and 2b. 356 o PCC MAY create and update the forward SR Path and update the 357 reverse SR Path independently for the 'Double-Sided Bidirectional 358 with Reverse LSP Association'. 360 o PCC MUST NOT instantiate a reverse SR Path in a bidirectional SR 361 Path. 363 o PCC MAY establish and remove the association relationship on a per 364 SR Path basis. 366 o PCC MUST report the change in the association group of an SR Path 367 to PCE(s) via PCRpt message. 369 o PCC reports the forward and reverse SR Paths independently to 370 PCE(s) via PCRpt message. 372 o PCC MAY delegate the forward and reverse SR Paths independently to 373 a Stateful PCE, where PCE would control the SR Paths. 375 o Stateful PCE updates the SR Paths in the 'Double-Sided 376 Bidirectional with Reverse LSP Association' via PCUpd message, 377 using the procedures described in [RFC8697]. 379 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 380 D as shown in Figure 2b) SHOULD be informed by the PCE via 381 PCInitiate message with the matching association group for the 382 use-cases which require the PCC to be aware of the reverse 383 direction SR Path. 385 +-----+ 386 | PCE | 387 +-----+ 388 Report/Delegate: ^ ^ Report/Delegate: 389 Tunnel 1 (F) / \ Tunnel 2 (F) 390 LSP1 (F,100) / \ LSP2 (F,200) 391 Association #2 / \ Association #2 392 / \ 393 / \ 394 +-----+ LSP1 +-----+ 395 | S |------------>| D | 396 | |<------------| | 397 +-----+ LSP2 +-----+ 398 400 Legends: F = Forward LSP, R = Reverse LSP, (100,200) = PLSP-IDs 402 Figure 2a: Step 1: PCC-Initiated Associated Bidirectional SR 403 Path with Forward Direction SR Paths 404 +-----+ 405 | PCE | 406 +-----+ 407 PCInitiate: / \ PCInitiate: 408 Tunnel 1 (F) / \ Tunnel 2 (F) 409 LSP1 (F,100), LSP2 (R,0) / \ LSP2 (F,200), LSP1 (R,0) 410 Association #2 / \ Association #2 411 / \ 412 v v 413 +-----+ LSP1 +-----+ 414 | S |------------>| D | 415 | |<------------| | 416 +-----+ LSP2 +-----+ 417 419 Legends: F = Forward LSP, R = Reverse LSP, (0,100,200) = PLSP-IDs 421 Figure 2b: Step 2: PCE-Initiated Associated Bidirectional SR 422 Path with Reverse Direction SR Paths 424 +-----+ 425 | PCE | 426 +-----+ 427 PCRpt: ^ ^ PCRpt: 428 Tunnel 1 (F) / \ Tunnel 2 (F) 429 LSP1 (F,100), LSP2 (R,300) / \ LSP2 (F,200), LSP1 (R,400) 430 Association #2 / \ Association #2 431 / \ 432 / \ 433 +-----+ LSP1 +-----+ 434 | S |------------>| D | 435 | |<------------| | 436 +-----+ LSP2 +-----+ 437 439 Legends: F=Forward LSP, R = Reverse LSP, (100,200,300,400)=PLSP-IDs 441 Figure 2c: Step 3: PCC-Reported Associated Bidirectional SR 442 Path with Reverse Direction SR Paths 444 4.3. Stateless PCE 446 As defined in [RFC9059], for a stateless PCE, it might be useful to 447 associate a path computation request to an association group, thus 448 enabling it to associate a common set of configuration parameters or 449 behaviors with the request [RFC8697]. A PCC can request co-routed or 450 non-co-routed forward and reverse direction paths from a stateless 451 PCE for a bidirectional SR Path. 453 4.4. Bidirectional (B) Flag 455 The Bidirectional (B) flag in Request Parameters (RP) object 456 [RFC5440] and Stateful PCE Request Parameter (SRP) object 457 [I-D.ietf-pce-pcep-stateful-pce-gmpls] follow the procedure defined 458 in [RFC9059]. 460 4.5. PLSP-ID Usage 462 For a bidirectional LSP computation when using both direction LSPs on 463 a node, the same LSP would need to be identified using 2 different 464 PLSP-IDs based on the PCEP session to the ingress or the egress node. 465 Note that the PLSP-ID space is independent at each PCC, the PLSP-ID 466 allocated by the egress PCC cannot be used for the LSP at the ingress 467 PCC (PLSP-ID conflict may occur). As per normal PCInitiate 468 operations, PCC assigns the PLSP-IDs for the local LSPs. Hence, when 469 the PCE notifies an ingress PCC of the reverse LSP, it does so by 470 using PCInitiate operations and sets PLSP-ID to zero and sets the R 471 bit in the 'Bidirectional LSP Association Group TLV' in the 472 association object to indicate that this PCInitiate LSP is a reverse 473 LSP. The PCC upon receiving the PCInitiate MUST locally assign a new 474 PLSP-ID and it MUST issue a PCRpt to PCE for this LSP containing the 475 new PLSP-ID. This reverse direction LSP MUST NOT be instantiated on 476 the PCC. 478 In other words, a given LSP will be identified by PLSP-ID A at the 479 ingress node while it will be identified by PLSP-ID B at the egress 480 node. The PCE will maintain two PLSP-IDs for the same LSP. For 481 example, ingress PCC1 may report to PCE an LSP1 with PLSP-ID 100. 482 Egress PCC2 may report to PCE an LSP2 with PLSP-ID 200. Both of 483 these LSPs are part of a bidirectional association. When PCE 484 notifies PCC1 of the reverse direction LSP2, it does so by sending a 485 PCInitiate to PCC1 with PLSP-ID set to zero and R bit set in the 486 'Bidirectional LSP Association Group TLV'. PCC1 upon reception of 487 this generates a new PLSP-ID (example PLSP-ID 300) and issues a PCRpt 488 to PCE. Thus there would two PLSP-ID associated for LSP2 (300 at 489 PCC1 and 200 at PCC2). 491 For an associated bidirectional SR Path, LSP-IDENTIFIERS TLV 492 [RFC8231] MUST be included in all forward and reverse LSPs. 494 4.6. State Synchronization 496 During state synchronization, a PCC MUST report all the existing 497 Bidirectional Associations to the Stateful PCE as per [RFC8697]. 498 After the state synchronization, the PCE MUST remove all stale 499 Bidirectional Associations. 501 4.7. Error Handling 503 The error handling as described in section 5.7 of [RFC9059] continue 504 to apply. 506 The PCEP Path Setup Type (PST) for SR is set to 'TE Path is Setup 507 using Segment Routing' [RFC8408] or 'Path is setup using SRv6' 508 [I-D.ietf-pce-segment-routing-ipv6]. 510 If a PCEP speaker receives a different PST value for the 'Double- 511 Sided Bidirectional with Reverse LSP Association', the PCE speaker 512 MUST return a PCErr message with Error-Type = 26 (Association Error) 513 and Error-value = '16: Path Setup Type not supported' defined in 514 [RFC9059]. 516 5. Implementation Status 518 [Note to the RFC Editor - remove this section before publication, as 519 well as remove the reference to [RFC7942]. 521 This section records the status of known implementations of the 522 protocol defined by this specification at the time of posting of this 523 Internet-Draft, and is based on a proposal described in [RFC7942]. 524 The description of implementations in this section is intended to 525 assist the IETF in its decision processes in progressing drafts to 526 RFCs. Please note that the listing of any individual implementation 527 here does not imply endorsement by the IETF. Furthermore, no effort 528 has been spent to verify the information presented here that was 529 supplied by IETF contributors. This is not intended as, and must not 530 be construed to be, a catalog of available implementations or their 531 features. Readers are advised to note that other implementations may 532 exist. 534 According to [RFC7942], "this will allow reviewers and working groups 535 to assign due consideration to documents that have the benefit of 536 running code, which may serve as evidence of valuable experimentation 537 and feedback that have made the implemented protocols more mature. 538 It is up to the individual working groups to use this information as 539 they see fit". 541 5.1. Huawei's Commercial Delivery 543 The feature is developing based on Huawei VRP8. 545 o Organization: Huawei 547 o Implementation: Huawei's Commercial Delivery implementation based 548 on VRP8. 550 o Description: The implementation is under development. 552 o Maturity Level: Product 554 o Contact: tanren@huawei.com 556 5.2. ZTE's Commercial Delivery 558 o Organization: ZTE 560 o Implementation: ZTE's Commercial Delivery implementation based on 561 Rosng v8. 563 o Description: The implementation is under development. 565 o Maturity Level: Product 567 o Contact: zhan.shuangping@zte.com.cn 569 6. Security Considerations 571 The security considerations described in [RFC5440], [RFC8231], 572 [RFC8281], and [RFC8408] apply to the extensions defined in this 573 document as well. 575 A new Association Type for the Association object, 'Double-Sided 576 Bidirectional with Reverse LSP Association' is introduced in this 577 document. Additional security considerations related to LSP 578 associations due to a malicious PCEP speaker are described in 579 [RFC8697] and apply to this Association Type. Hence, securing the 580 PCEP session using Transport Layer Security (TLS) [RFC8253] is 581 recommended. 583 7. Manageability Considerations 585 All manageability requirements and considerations listed in 586 [RFC5440], [RFC8231], and [RFC8281] apply to PCEP protocol extensions 587 defined in this document. In addition, requirements and 588 considerations listed in this section apply. 590 7.1. Control of Function and Policy 592 The mechanisms defined in this document do not imply any control or 593 policy requirements in addition to those already listed in [RFC5440], 594 [RFC8231], and [RFC8281]. 596 7.2. Information and Data Models 598 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 599 defined for 'Double-Sided Bidirectional with Reverse LSP 600 Associations'. The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines 601 data model for associated bidirectional SR Paths. 603 7.3. Liveness Detection and Monitoring 605 Mechanisms defined in this document do not imply any new liveness 606 detection and monitoring requirements in addition to those already 607 listed in [RFC5440], [RFC8231], and [RFC8281]. 609 7.4. Verify Correct Operations 611 Mechanisms defined in this document do not imply any new operation 612 verification requirements in addition to those already listed in 613 [RFC5440], [RFC8231], and [RFC8408]. 615 7.5. Requirements On Other Protocols 617 Mechanisms defined in this document do not imply any new requirements 618 on other protocols. 620 7.6. Impact On Network Operations 622 Mechanisms defined in [RFC5440], [RFC8231], and [RFC8408] also apply 623 to PCEP extensions defined in this document. 625 8. IANA Considerations 627 8.1. Association Type 629 This document defines a new Association Type, originally described in 630 [RFC8697]. IANA is requested to assign the following new value in 631 the "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path 632 Computation Element Protocol (PCEP) Numbers" registry: 634 Type Name Reference 635 --------------------------------------------------------------------- 636 TBD1 Double-Sided Bidirectional with Reverse [This document] 637 LSP Association 639 9. References 641 9.1. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 649 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 650 DOI 10.17487/RFC5440, March 2009, 651 . 653 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 654 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 655 May 2017, . 657 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 658 Computation Element Communication Protocol (PCEP) 659 Extensions for Stateful PCE", RFC 8231, 660 DOI 10.17487/RFC8231, September 2017, 661 . 663 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 664 Computation Element Communication Protocol (PCEP) 665 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 666 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 667 . 669 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 670 Dhody, D., and Y. Tanaka, "Path Computation Element 671 Communication Protocol (PCEP) Extensions for Establishing 672 Relationships between Sets of Label Switched Paths 673 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 674 . 676 [RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation 677 Element Communication Protocol (PCEP) Extensions for 678 Associated Bidirectional Label Switched Paths (LSPs)", 679 RFC 9059, DOI 10.17487/RFC9059, June 2021, 680 . 682 9.2. Informative References 684 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 685 "PCEPS: Usage of TLS to Provide a Secure Transport for the 686 Path Computation Element Communication Protocol (PCEP)", 687 RFC 8253, DOI 10.17487/RFC8253, October 2017, 688 . 690 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 691 Decraene, B., Litkowski, S., and R. Shakir, "Segment 692 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 693 July 2018, . 695 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 696 Code: The Implementation Status Section", BCP 205, 697 RFC 7942, DOI 10.17487/RFC7942, July 2016, 698 . 700 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 701 Hardwick, "Path Computation Element Communication Protocol 702 (PCEP) Management Information Base (MIB) Module", 703 RFC 7420, DOI 10.17487/RFC7420, December 2014, 704 . 706 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 707 Hardwick, "Conveying Path Setup Type in PCE Communication 708 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 709 July 2018, . 711 [I-D.ietf-pce-sr-path-segment] 712 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 713 "Path Computation Element Communication Protocol (PCEP) 714 Extension for Path Segment in Segment Routing (SR)", 715 draft-ietf-pce-sr-path-segment-03 (work in progress), 716 February 2021. 718 [I-D.ietf-pce-segment-routing-ipv6] 719 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 720 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 721 Routing leveraging the IPv6 data plane", draft-ietf-pce- 722 segment-routing-ipv6-09 (work in progress), May 2021. 724 [I-D.ietf-mpls-bfd-directed] 725 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 726 "Bidirectional Forwarding Detection (BFD) Directed Return 727 Path for MPLS Label Switched Paths (LSPs)", draft-ietf- 728 mpls-bfd-directed-17 (work in progress), February 2021. 730 [I-D.ietf-spring-stamp-srpm] 731 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, 732 B., and R. Foote, "Performance Measurement Using Simple 733 TWAMP (STAMP) for Segment Routing Networks", draft-ietf- 734 spring-stamp-srpm-01 (work in progress), July 2021. 736 [I-D.ietf-spring-mpls-path-segment] 737 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 738 "Path Segment in MPLS Based Segment Routing Network", 739 draft-ietf-spring-mpls-path-segment-04 (work in progress), 740 April 2021. 742 [I-D.ietf-spring-srv6-path-segment] 743 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 744 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 745 ietf-spring-srv6-path-segment-00 (work in progress), 746 November 2020. 748 [I-D.ietf-pce-pcep-yang] 749 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 750 "A YANG Data Model for Path Computation Element 751 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 752 yang-16 (work in progress), February 2021. 754 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 755 Lee, Y., Zheng, H., Dios, O. G. D., Lopez, V., and Z. Ali, 756 "Path Computation Element (PCE) Protocol Extensions for 757 Stateful PCE Usage in GMPLS-controlled Networks", draft- 758 ietf-pce-pcep-stateful-pce-gmpls-14 (work in progress), 759 December 2020. 761 [I-D.ietf-spring-segment-routing-policy] 762 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 763 P. Mattes, "Segment Routing Policy Architecture", draft- 764 ietf-spring-segment-routing-policy-11 (work in progress), 765 April 2021. 767 [I-D.ietf-pce-segment-routing-policy-cp] 768 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 769 Bidgoli, "PCEP extension to support Segment Routing Policy 770 Candidate Paths", draft-ietf-pce-segment-routing-policy- 771 cp-04 (work in progress), March 2021. 773 Acknowledgments 775 Many thanks to Marina Fizgeer, Adrian Farrel, Andrew Stone, and Tarek 776 Saad for the detailed review of this document and providing many 777 useful comments. 779 Contributors 781 The following people have substantially contributed to this document: 783 Dhruv Dhody 784 Huawei Technologies 785 Divyashree Techno Park, Whitefield 786 Bangalore, Karnataka 560066 787 India 789 Email: dhruv.ietf@gmail.com 791 Zhenbin Li 792 Huawei Technologies 793 Huawei Campus, No. 156 Beiqing Rd. 794 Beijing 100095 795 China 797 Email: lizhenbin@huawei.com 799 Jie Dong 800 Huawei Technologies 801 Huawei Campus, No. 156 Beiqing Rd. 802 Beijing 100095 803 China 805 Email: jie.dong@huawei.com 807 Authors' Addresses 809 Cheng Li 810 Huawei Technologies 811 Huawei Campus, No. 156 Beiqing Rd. 812 Beijing 100095 813 China 815 Email: c.l@huawei.com 816 Mach(Guoyi) Chen 817 Huawei Technologies 818 Huawei Campus, No. 156 Beiqing Rd. 819 Beijing 100095 820 China 822 Email: Mach.chen@huawei.com 824 Weiqiang Cheng 825 China Mobile 826 China 828 Email: chengweiqiang@chinamobile.com 830 Rakesh Gandhi 831 Cisco Systems, Inc. 832 Canada 834 Email: rgandhi@cisco.com 836 Quan Xiong 837 ZTE Corporation 838 China 840 Email: xiong.quan@zte.com.cn