idnits 2.17.1 draft-ietf-pce-sr-bidir-path-01.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 (February 14, 2020) is 1504 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 (-14) exists of draft-ietf-pce-association-bidir-05 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-00 == Outdated reference: A later version (-26) exists of draft-ietf-mpls-bfd-directed-13 == Outdated reference: A later version (-11) exists of draft-gandhi-spring-twamp-srpm-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-01 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-13 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-12 Summary: 0 errors (**), 0 flaws (~~), 8 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: August 17, 2020 W. Cheng 6 China Mobile 7 R. Gandhi 8 Cisco Systems, Inc. 9 Q. Xiong 10 ZTE Corporation 11 February 14, 2020 13 PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths 14 draft-ietf-pce-sr-bidir-path-01 16 Abstract 18 The Path Computation Element Communication Protocol (PCEP) provides 19 mechanisms for Path Computation Elements (PCEs) to perform path 20 computations in response to Path Computation Clients (PCCs) requests. 21 Segment routing (SR) leverages the source routing and tunneling 22 paradigms. The Stateful PCEP extensions allow stateful control of 23 Segment Routing (SR) Traffic Engineering (TE) Paths. Furthermore, 24 PCEP can be used for computing SR TE paths in the network. 26 This document defines PCEP extensions for grouping two unidirectional 27 SR Paths (one in each direction in the network) into a single 28 Associated Bidirectional SR Path. The mechanisms defined in this 29 document can also be applied using a Stateful PCE for both PCE- 30 Initiated and PCC-Initiated LSPs, as well as when using a Stateless 31 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 August 17, 2020. 50 Copyright Notice 52 Copyright (c) 2020 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 SR Path Association Group . . 5 72 3.1.1. Bidirectional LSP Association Group TLV . . . . . . . 5 73 4. PCEP Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.1. PCE Initiated Associated Bidirectional SR Paths . . . . . 6 75 4.2. PCC Initiated Associated Bidirectional SR Paths . . . . . 7 76 4.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 9 77 4.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 9 78 4.5. State Synchronization . . . . . . . . . . . . . . . . . . 9 79 4.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 9 80 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 81 5.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 10 82 5.2. ZTE's Commercial Delivery . . . . . . . . . . . . . . . . 10 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 7. Manageability Considerations . . . . . . . . . . . . . . . . 11 85 7.1. Control of Function and Policy . . . . . . . . . . . . . 11 86 7.2. Information and Data Models . . . . . . . . . . . . . . . 11 87 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 88 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 89 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 90 7.6. Impact On Network Operations . . . . . . . . . . . . . . 12 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 8.1. Association Type . . . . . . . . . . . . . . . . . . . . 12 93 8.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 12 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 96 9.2. Informative References . . . . . . . . . . . . . . . . . 13 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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]. 111 [RFC5440] describes the Path Computation Element (PCE) Communication 112 Protocol (PCEP). PCEP enables the communication between a Path 113 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 114 purpose of computation of Traffic Engineering (TE) Label Switched 115 Paths (LSP). [RFC8231] specifies a set of extensions to PCEP to 116 enable stateful control of TE LSPs within and across PCEP sessions. 117 The mode of operation where LSPs are initiated from the PCE is 118 described in [RFC8281]. 120 [RFC8408] specifies extensions to the Path Computation Element 121 Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE 122 to compute and initiate SR TE paths, as well as a PCC to request, 123 report or delegate them. 125 [RFC8697] introduces a generic mechanism to create a grouping of LSPs 126 which can then be used to define associations between a set of LSPs 127 and/or a set of attributes, and is equally applicable to the active 128 and passive modes of a Stateful PCE [RFC8231] or a stateless PCE 129 [RFC5440]. 131 [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping 132 two unidirectional RSVP-TE LSPs into an Associated Bidirectional LSP 133 when using a Stateful PCE for both PCE-Initiated and PCC-Initiated 134 LSPs as well as when using a Stateless PCE. It specifies the 135 procedure for Double-sided Bidirectional LSP Association, where the 136 PCE creates the association and provisions the forward LSPs at their 137 ingress nodes. The RSVP-TE signals the forward LSPs to the egress 138 nodes. Thus, both endpoints learn the reverse LSPs forming the 139 bidirectional LSP association. 141 This document extends the bidirectional LSP association to SR by 142 specifying PCEP extensions for grouping two unidirectional SR Paths 143 into a bidirectional SR Path. For bidirectional SR, there are use 144 cases such as directed BFD [I-D.ietf-mpls-bfd-directed] and SR 145 performance measurement [I-D.gandhi-spring-twamp-srpm] those require 146 PCC to be aware of the reverse direction SR path. For such use- 147 cases, the reverse SR paths are also communicated to the ingress 148 nodes using the PCEP extensions defined in this document. This 149 allows both endpoints to be aware of SR Paths in both directions, 150 including their status and all other path related information. 152 2. Terminology 154 This document makes use of the terms defined in [RFC8408]. The 155 reader is assumed to be familiar with the terminology defined in 156 [RFC5440], [RFC8231], [RFC8281], [RFC8697], and 157 [I-D.ietf-pce-association-bidir]. 159 2.1. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 3. PCEP Extensions 169 As per [RFC8697], TE LSPs are associated by adding them to a common 170 association group by a PCEP peer. [I-D.ietf-pce-association-bidir] 171 uses the the association group object and the procedures as specified 172 in [RFC8697] to group two unidirectional RSVP-TE LSPs. Similarly, 173 two SR Paths can also be associated using similar technique. This 174 document extends these association mechanisms for bidirectional SR 175 Paths. Two unidirectional SR Paths (one in each direction in the 176 network) can be associated together by using the Bidirectional SR 177 Path Association Group defined in this document for PCEP messages. 179 Note that the association group defined in this document is specific 180 to the bidirectional SR Paths. The procedure for this association 181 group is different than the RSVP-TE bidirectional association groups 182 defined in [I-D.ietf-pce-association-bidir]. 184 [I-D.ietf-pce-sr-path-segment] defines a mechanism for communicating 185 Path Segment Identifier (PSID) in PCEP for SR. The PSID is defined 186 for SR-MPLS in [I-D.ietf-spring-mpls-path-segment]. The PSID can be 187 used for identifying an SR Path of an associated bidirectional SR 188 Path. The PATH-SEGMENT TLV MAY be included for each SR Path in the 189 LSP object to support required use-cases. The PATH-SEGMENT TLV MUST 190 be handled as defined in [I-D.ietf-pce-sr-path-segment] and is not 191 modified for associated bidirectional SR Path. 193 3.1. Double-sided Bidirectional SR Path Association Group 195 For associating two unidirectional SR paths, this document defines a 196 new Association Type called 'Double-sided Bidirectional SR Path 197 Association Group' for Association Group Object (Class-Value 40) as 198 follows: 200 o Association Type (TBD1 to be assigned by IANA) = Double-sided 201 Bidirectional SR Path Association Group 203 Similar to RSVP-TE bidirectional LSP associations, this Association 204 Type is operator-configured in nature and statically created by the 205 operator on the PCEP peers. The paths belonging to this association 206 is conveyed via PCEP messages to the PCEP peer. Operator-configured 207 Association Range TLV [RFC8697] MUST NOT be sent for these 208 Association Types, and MUST be ignored, so that the entire range of 209 association ID can be used for them. The handling of the Association 210 ID, Association Source, optional Global Association Source and 211 optional Extended Association ID in this association are set in the 212 same way as [I-D.ietf-pce-association-bidir]. 214 A member of the 'Double-sided Bidirectional SR Path Association 215 Group' can take the role of a forward or reverse SR Path and follow 216 the similar rules defined in [I-D.ietf-pce-association-bidir] for 217 LSPs. 219 o An SR Path (forward or reverse) cannot be part of more than one 220 'Double-sided Bidirectional SR Path Association Group'. 222 o The endpoints of the SR Paths in this associations cannot be 223 different. 225 3.1.1. Bidirectional LSP Association Group TLV 227 In Bidirectional SR Association Group, for properties such as forward 228 and reverse direction and co-routed path, it uses the Bidirectional 229 LSP Association Group TLV defined in 230 [I-D.ietf-pce-association-bidir]. All fields and processing rules 231 are as per [I-D.ietf-pce-association-bidir]. 233 4. PCEP Procedures 235 For bidirectional SR path, an ingress PCC is aware of the forward 236 direction SR path beginning from itself to the egress PCC using the 237 existing PCEP procedures. For the use-cases which require the 238 ingress PCC to be aware of the reverse direction SR path, PCE informs 239 the reverse SR Path to the ingress PCC. To achieve this, a 240 PCInitiate message for the reverse SR Path is sent to the ingress PCC 241 and a PCInitiate message for the forward SR Path is sent to the 242 egress PCC (with the matching association group). These PCInitiate 243 message MUST NOT trigger initiation of SR Paths on PCCs. 245 For a bidirectional LSP computation when using both direction LSPs on 246 a node, the same LSP would need to be identified using 2 different 247 PLSP-IDs based on the PCEP session to the ingress or the egress node. 248 Note that the PLSP-ID space is independent at each PCC, the PLSP-ID 249 allocated by the egress PCC cannot be used for the LSP at the ingress 250 PCC (PLSP-ID conflict may occur). As per normal PCInitiate 251 operations, PCC assigns the PLSP-IDs for the local LSPs. Hence, when 252 the PCE notifies an ingress PCC of the reverse LSP, it does so by 253 using PCInitiate operations and sets PLSP-ID to zero and sets the R 254 bit in the Bidirectional LSP Association Group TLV in the association 255 object to indicate that this PCInitiate LSP is a reverse LSP. The 256 PCC upon receiving the PCInitiate MUST locally assign a new PLSP-ID 257 and it MUST issue a PCRpt to PCE for this LSP containing the new 258 PLSP-ID. This reverse direction LSP MUST NOT be instantiated on the 259 PCC. 261 In other words, a given LSP will be identified by PLSP-ID A at the 262 ingress node while it will be identified by PLSP-ID B at the egress 263 node. The PCE will maintain two PLSP-IDs for the same LSP. For 264 example, ingress PCC1 may report to PCE an LSP1 with PLSP-ID 100. 265 Egress PCC2 may report to PCE an LSP2 with PLSP-ID 200. Both of 266 these LSPs are part of a bidirectional association. When PCE 267 notifies PCC1 of the reverse direction LSP2, it does so by sending a 268 PCInitiate to PCC1 with PLSP-ID set to zero and R bit set in the 269 Bidirectional LSP Association Group TLV. PCC1 upon reception of this 270 generates a new PLSP-ID (example PLSP-ID 300) and issues a PCRpt to 271 PCE. Thus there would two PLSP-ID associated for LSP2 (300 at PCC1 272 and 200 at PCC2). 274 4.1. PCE Initiated Associated Bidirectional SR Paths 276 As specified in [RFC8697], Bidirectional SR Path Association Group 277 can be created by a Stateful PCE as shown in Figure 1. 279 o Stateful PCE can create and update the forward and reverse SR 280 Paths independently for 'Double-sided Bidirectional SR Path 281 Association Group'. 283 o Stateful PCE can establish and remove the association relationship 284 on a per SR Path basis. 286 o Stateful PCE can create and update the SR Path and the association 287 on a PCC via PCInitiate and PCUpd messages, respectively, using 288 the procedures described in [RFC8697]. 290 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 291 D as shown in Figure 1) SHOULD be informed by the PCE via 292 PCInitiate message with the matching association group for the 293 use-cases which require the PCC to be aware of the reverse 294 direction SR path. 296 +-----+ 297 | PCE | 298 +-----+ 299 PCInitiate/PCUpd: / \ PCInitiate/PCUpd: 300 Tunnel 1 (F) / \ Tunnel 2 (F) 301 (LSP1 (F), LSP2 (R)) / \ (LSP2 (F), LSP1 (R)) 302 Association #1 / \ Association #1 303 / \ 304 v v 305 +-----+ LSP1 +-----+ 306 | S |------------>| D | 307 | |<------------| | 308 +-----+ LSP2 +-----+ 309 311 Figure 1: PCE-Initiated Double-sided Bidirectional SR Path 312 with Forward and Reverse Direction SR Paths 314 4.2. PCC Initiated Associated Bidirectional SR Paths 316 As specified in [RFC8697], Bidirectional SR Path Association Group 317 can also be created by a PCC as shown in Figure 2a and 2b. 319 o PCC can create and update the forward SR Path and update the 320 reverse SR Path independently for a 'Double-sided Bidirectional SR 321 Path Association Group'. 323 o PCC cannot instantiate a reverse SR Path in a bidirectional SR 324 Path. 326 o PCC can establish and remove the association relationship on a per 327 SR Path basis. 329 o PCC MUST report the change in the association group of an SR Path 330 to PCE(s) via PCRpt message. 332 o PCC can report the forward and reverse SR Paths independently to 333 PCE(s) via PCRpt message. 335 o PCC can delegate the forward and reverse SR Paths independently to 336 a Stateful PCE, where PCE would control the SR Paths. 338 o Stateful PCE can update the SR Paths in the 'Double-sided 339 Bidirectional SR Path Association Group' via PCUpd message, using 340 the procedures described in [RFC8697]. 342 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 343 D as shown in Figure 2b) SHOULD be informed by the PCE via 344 PCInitiate message with the matching association group for the 345 use-cases which require the PCC to be aware of the reverse 346 direction SR path. 348 +-----+ 349 | PCE | 350 +-----+ 351 Report/Delegate: ^ ^ Report/Delegate: 352 Tunnel 1 (F) / \ Tunnel 2 (F) 353 (LSP1 (F)) / \ (LSP2 (F)) 354 Association #2 / \ Association #2 355 / \ 356 / \ 357 +-----+ LSP1 +-----+ 358 | S |------------>| D | 359 | |<------------| | 360 +-----+ LSP2 +-----+ 361 363 Figure 2a: Step 1: PCC-Initiated Double-sided Bidirectional 364 SR Path with Forward Direction SR Paths 366 +-----+ 367 | PCE | 368 +-----+ 369 PCUpd/PCInitiate: / \ PCUpd/PCInitiate: 370 Tunnel 1 (F) / \ Tunnel 2 (F) 371 (LSP1 (F), LSP2 (R)) / \ (LSP2 (F), LSP1 (R)) 372 Association #2 / \ Association #2 373 / \ 374 v v 375 +-----+ LSP1 +-----+ 376 | S |------------>| D | 377 | |<------------| | 378 +-----+ LSP2 +-----+ 379 381 Figure 2b: Step 2: PCE-Updated/Initiated Double-sided Bidirectional 382 SR Path with Reverse Direction SR Paths 384 4.3. Stateless PCE 386 As defined in [I-D.ietf-pce-association-bidir], for a stateless PCE, 387 it might be useful to associate a path computation request to an 388 association group, thus enabling it to associate a common set of 389 configuration parameters or behaviors with the request. A PCC can 390 request co-routed or non-co-routed forward and reverse direction 391 paths from a stateless PCE for a bidirectional SR association group. 393 4.4. Bidirectional (B) Flag 395 As defined in [RFC5440], the Bidirectional (B) flag in Request 396 Parameters (RP) object MUST be set when the PCC specifies that the 397 path computation request relates to a bidirectional TE LSP. The 398 B-flag also MUST be set when the PCC specifies that the path 399 computation request relates to an associated bidirectional SR Path. 401 Note that the B-flag defined in Stateful PCE Request Parameter (SRP) 402 object [I-D.ietf-pce-pcep-stateful-pce-gmpls] is not required for 403 associated bidirectional SR path as association group is used to 404 indicate that the path is bidirectional. 406 4.5. State Synchronization 408 During state synchronization, a PCC MUST report all the existing 409 Bidirectional SR Association Groups to the Stateful PCE as per 410 [RFC8697]. After the state synchronization, the PCE MUST remove all 411 stale Bidirectional SR Associations. 413 4.6. Error Handling 415 The error handling as described in section 5.7 of 416 [I-D.ietf-pce-association-bidir] continue to apply. 418 The PCEP Path Setup Type (PST) for SR is set to 'TE Path is Setup 419 using Segment Routing' [RFC8408]. If a PCEP speaker receives a 420 different PST value for Bidirectional SR Path association group and 421 it does not support; it MUST send a PCErr message with Error-Type = 422 26 (Association Error) and Error-Value = TBD2 (Bidirectional LSP 423 Association - Path Setup Type Not Supported). 425 5. Implementation Status 427 [Note to the RFC Editor - remove this section before publication, as 428 well as remove the reference to [RFC7942]. 430 This section records the status of known implementations of the 431 protocol defined by this specification at the time of posting of this 432 Internet-Draft, and is based on a proposal described in [RFC7942]. 433 The description of implementations in this section is intended to 434 assist the IETF in its decision processes in progressing drafts to 435 RFCs. Please note that the listing of any individual implementation 436 here does not imply endorsement by the IETF. Furthermore, no effort 437 has been spent to verify the information presented here that was 438 supplied by IETF contributors. This is not intended as, and must not 439 be construed to be, a catalog of available implementations or their 440 features. Readers are advised to note that other implementations may 441 exist. 443 According to [RFC7942], "this will allow reviewers and working groups 444 to assign due consideration to documents that have the benefit of 445 running code, which may serve as evidence of valuable experimentation 446 and feedback that have made the implemented protocols more mature. 447 It is up to the individual working groups to use this information as 448 they see fit". 450 5.1. Huawei's Commercial Delivery 452 The feature is developing based on Huawei VRP8. 454 o Organization: Huawei 456 o Implementation: Huawei's Commercial Delivery implementation based 457 on VRP8. 459 o Description: The implementation is under development. 461 o Maturity Level: Product 463 o Contact: tanren@huawei.com 465 5.2. ZTE's Commercial Delivery 467 o Organization: ZTE 469 o Implementation: ZTE's Commercial Delivery implementation based on 470 Rosng v8. 472 o Description: The implementation is under development. 474 o Maturity Level: Product 476 o Contact: zhan.shuangping@zte.com.cn 478 6. Security Considerations 480 The security considerations described in [RFC5440], [RFC8231], 481 [RFC8281], and [RFC8408] apply to the extensions defined in this 482 document as well. 484 A new Association Type for the Association Object, 'Double-sided 485 Associated Bidirectional SR Path Association Group' is introduced in 486 this document. Additional security considerations related to LSP 487 associations due to a malicious PCEP speaker is described in 488 [RFC8697] and apply to this Association Type. Hence, securing the 489 PCEP session using Transport Layer Security (TLS) [RFC8253] is 490 recommended. 492 7. Manageability Considerations 494 All manageability requirements and considerations listed in 495 [RFC5440], [RFC8231], and [RFC8281] apply to PCEP protocol extensions 496 defined in this document. In addition, requirements and 497 considerations listed in this section apply. 499 7.1. Control of Function and Policy 501 The mechanisms defined in this document do not imply any control or 502 policy requirements in addition to those already listed in [RFC5440], 503 [RFC8231], and [RFC8281]. 505 7.2. Information and Data Models 507 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 508 defined for Bidirectional SR Path associations. The PCEP YANG module 509 [I-D.ietf-pce-pcep-yang] defines data model for Bidirectional SR Path 510 associations. 512 7.3. Liveness Detection and Monitoring 514 Mechanisms defined in this document do not imply any new liveness 515 detection and monitoring requirements in addition to those already 516 listed in [RFC5440], [RFC8231], and [RFC8281]. 518 7.4. Verify Correct Operations 520 Mechanisms defined in this document do not imply any new operation 521 verification requirements in addition to those already listed in 522 [RFC5440], [RFC8231], and [RFC8408]. 524 7.5. Requirements On Other Protocols 526 Mechanisms defined in this document do not imply any new requirements 527 on other protocols. 529 7.6. Impact On Network Operations 531 Mechanisms defined in [RFC5440], [RFC8231], and [RFC8408] also apply 532 to PCEP extensions defined in this document. 534 8. IANA Considerations 536 8.1. Association Type 538 This document defines a new Association Type for the Association 539 Object (Class Value 40) defined [RFC8697]. IANA is requested to make 540 the assignment of a type for the sub-registry "ASSOCIATION Type" as 541 follows: 543 Type Name Reference 544 ------------------------------------------------------------------- 545 TBD1 Double-sided Bidirectional SR Path This document 546 Association Group 548 8.2. PCEP Errors 550 This document defines new Error value for Error Type 26 (Association 551 Error). IANA is requested to allocate new Error value within the 552 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 553 Numbers registry, as follows: 555 Error Type Description Reference 556 ------------------------------------------------------------------- 557 26 Association Error 559 Error value: TBD2 This document 560 Bidirectional LSP Association - 561 Path Setup Type Not Supported 563 9. References 565 9.1. Normative References 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, 570 . 572 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 573 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 574 DOI 10.17487/RFC5440, March 2009, 575 . 577 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 578 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 579 May 2017, . 581 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 582 Computation Element Communication Protocol (PCEP) 583 Extensions for Stateful PCE", RFC 8231, 584 DOI 10.17487/RFC8231, September 2017, 585 . 587 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 588 Computation Element Communication Protocol (PCEP) 589 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 590 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 591 . 593 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 594 Dhody, D., and Y. Tanaka, "Path Computation Element 595 Communication Protocol (PCEP) Extensions for Establishing 596 Relationships between Sets of Label Switched Paths 597 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 598 . 600 [I-D.ietf-pce-association-bidir] 601 Gandhi, R., Barth, C., and B. Wen, "PCEP Extensions for 602 Associated Bidirectional Label Switched Paths (LSPs)", 603 draft-ietf-pce-association-bidir-05 (work in progress), 604 February 2020. 606 [I-D.ietf-pce-sr-path-segment] 607 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 608 "Path Computation Element Communication Protocol (PCEP) 609 Extension for Path Segment in Segment Routing (SR)", 610 draft-ietf-pce-sr-path-segment-00 (work in progress), 611 October 2019. 613 9.2. Informative References 615 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 616 "PCEPS: Usage of TLS to Provide a Secure Transport for the 617 Path Computation Element Communication Protocol (PCEP)", 618 RFC 8253, DOI 10.17487/RFC8253, October 2017, 619 . 621 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 622 Decraene, B., Litkowski, S., and R. Shakir, "Segment 623 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 624 July 2018, . 626 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 627 Code: The Implementation Status Section", BCP 205, 628 RFC 7942, DOI 10.17487/RFC7942, July 2016, 629 . 631 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 632 Hardwick, "Path Computation Element Communication Protocol 633 (PCEP) Management Information Base (MIB) Module", 634 RFC 7420, DOI 10.17487/RFC7420, December 2014, 635 . 637 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 638 Hardwick, "Conveying Path Setup Type in PCE Communication 639 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 640 July 2018, . 642 [I-D.ietf-mpls-bfd-directed] 643 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 644 "Bidirectional Forwarding Detection (BFD) Directed Return 645 Path", draft-ietf-mpls-bfd-directed-13 (work in progress), 646 December 2019. 648 [I-D.gandhi-spring-twamp-srpm] 649 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 650 Janssens, "Performance Measurement Using TWAMP Light for 651 Segment Routing Networks", draft-gandhi-spring-twamp- 652 srpm-05 (work in progress), December 2019. 654 [I-D.ietf-spring-mpls-path-segment] 655 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 656 "Path Segment in MPLS Based Segment Routing Network", 657 draft-ietf-spring-mpls-path-segment-01 (work in progress), 658 September 2019. 660 [I-D.ietf-pce-pcep-yang] 661 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 662 YANG Data Model for Path Computation Element 663 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 664 yang-13 (work in progress), October 2019. 666 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 667 Lee, Y., Zheng, H., Dios, O., Lopezalvarez, V., and Z. 668 Ali, "Path Computation Element (PCE) Protocol Extensions 669 for Stateful PCE Usage in GMPLS-controlled Networks", 670 draft-ietf-pce-pcep-stateful-pce-gmpls-12 (work in 671 progress), October 2019. 673 Acknowledgments 675 Many thanks to Marina Fizgeer, Adrian Farrel, and Andrew Stone for 676 the detailed review of this document and providing many useful 677 comments. 679 Contributors 681 The following people have substantially contributed to this document: 683 Dhruv Dhody 684 Huawei Technologies 685 Divyashree Techno Park, Whitefield 686 Bangalore, Karnataka 560066 687 India 689 Email: dhruv.ietf@gmail.com 691 Zhenbin Li 692 Huawei Technologies 693 Huawei Campus, No. 156 Beiqing Rd. 694 Beijing 100095 695 China 697 Email: lizhenbin@huawei.com 699 Jie Dong 700 Huawei Technologies 701 Huawei Campus, No. 156 Beiqing Rd. 702 Beijing 100095 703 China 705 Email: jie.dong@huawei.com 707 Authors' Addresses 709 Cheng Li 710 Huawei Technologies 711 Huawei Campus, No. 156 Beiqing Rd. 712 Beijing 100095 713 China 715 Email: chengli13@huawei.com 717 Mach(Guoyi) Chen 718 Huawei Technologies 719 Huawei Campus, No. 156 Beiqing Rd. 720 Beijing 100095 721 China 723 Email: Mach.chen@huawei.com 725 Weiqiang Cheng 726 China Mobile 727 China 729 Email: chengweiqiang@chinamobile.com 731 Rakesh Gandhi 732 Cisco Systems, Inc. 733 Canada 735 Email: rgandhi@cisco.com 737 Quan Xiong 738 ZTE Corporation 739 China 741 Email: xiong.quan@zte.com.cn