idnits 2.17.1 draft-ietf-pce-sr-bidir-path-02.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 (March 13, 2020) is 1503 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 (-30) exists of draft-ietf-mpls-bfd-directed-13 == Outdated reference: A later version (-11) exists of draft-gandhi-spring-twamp-srpm-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-02 == 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 == Outdated reference: A later version (-06) exists of draft-barth-pce-segment-routing-policy-cp-04 Summary: 0 errors (**), 0 flaws (~~), 9 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: September 14, 2020 W. Cheng 6 China Mobile 7 R. Gandhi 8 Cisco Systems, Inc. 9 Q. Xiong 10 ZTE Corporation 11 March 13, 2020 13 PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths 14 draft-ietf-pce-sr-bidir-path-02 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 Traffic Engineering (TE) Paths. Furthermore, PCEP 24 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 September 14, 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 with Reverse LSP Association 72 Group . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1.1. Bidirectional LSP Association Group TLV . . . . . . . 5 74 4. PCEP Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. PCE Initiated Associated Bidirectional SR Paths . . . . . 7 76 4.2. PCC Initiated Associated Bidirectional SR Paths . . . . . 7 77 4.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 9 78 4.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 10 79 4.5. State Synchronization . . . . . . . . . . . . . . . . . . 10 80 4.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 10 81 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 82 5.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 11 83 5.2. ZTE's Commercial Delivery . . . . . . . . . . . . . . . . 11 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 7. Manageability Considerations . . . . . . . . . . . . . . . . 12 86 7.1. Control of Function and Policy . . . . . . . . . . . . . 12 87 7.2. Information and Data Models . . . . . . . . . . . . . . . 12 88 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 89 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 90 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 91 7.6. Impact On Network Operations . . . . . . . . . . . . . . 12 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 8.1. Association Type . . . . . . . . . . . . . . . . . . . . 13 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 96 9.2. Informative References . . . . . . . . . . . . . . . . . 14 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 (PM) [I-D.gandhi-spring-twamp-srpm] those 146 require PCC to be aware of the reverse direction SR Path. For such 147 use-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 the SR Paths in both directions, 150 including their status and all other path related information. 151 Associating an unidirectional SR Path with a reverse direction 152 unidirectional RSVP-TE LSP to form a bidirectional LSP and vice 153 versa, are outside the scope of this document. 155 2. Terminology 157 This document makes use of the terms defined in [RFC8408]. The 158 reader is assumed to be familiar with the terminology defined in 159 [RFC5440], [RFC8231], [RFC8281], [RFC8697], and 160 [I-D.ietf-pce-association-bidir]. 162 2.1. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 3. PCEP Extensions 172 As per [RFC8697], TE LSPs are associated by adding them to a common 173 association group by a PCEP peer. [I-D.ietf-pce-association-bidir] 174 uses the association group object and the procedures as specified in 175 [RFC8697] to group two unidirectional RSVP-TE LSPs. Similarly, two 176 SR Paths can also be associated using similar technique. This 177 document extends these association mechanisms for bidirectional SR 178 Paths. Two unidirectional SR Paths (one in each direction in the 179 network) can be associated together by using the association group 180 defined in this document for PCEP messages. 182 Note that the procedure for using the association group defined in 183 this document is specific to the associated bidirectional SR Paths. 184 The procedure for this association group is different than the 185 bidirectional association groups defined in 186 [I-D.ietf-pce-association-bidir] for associated bidirectional RSVP-TE 187 LSPs. 189 [I-D.ietf-pce-sr-path-segment] defines a mechanism for communicating 190 Path Segment Identifier (PSID) in PCEP for SR. The PSID is defined 191 for SR-MPLS in [I-D.ietf-spring-mpls-path-segment]. The PSID can be 192 used for identifying an SR Path of an associated bidirectional SR 193 Path. The PATH-SEGMENT TLV MAY be included for each SR Path in the 194 LSP object to support required use-cases. The PATH-SEGMENT TLV MUST 195 be handled as defined in [I-D.ietf-pce-sr-path-segment] and is not 196 modified for associated bidirectional SR Path. 198 3.1. Double-sided Bidirectional with Reverse LSP Association Group 200 For associating two unidirectional SR Paths, this document defines a 201 new Association Type called 'Double-sided Bidirectional with Reverse 202 LSP Association Group' for Association Group Object (Class-Value 40) 203 as follows: 205 o Association Type (TBD1 to be assigned by IANA) = Double-sided 206 Bidirectional with Reverse LSP Association Group 208 Similar to RSVP-TE bidirectional LSP associations, this Association 209 Type is also operator-configured in nature and statically created by 210 the operator on the PCEP peers. 'Operator-configured Association 211 Range' TLV (Value 29) [RFC8697] MUST NOT be sent for this Association 212 Type, and MUST be ignored, so that the entire range of association ID 213 can be used for it. 215 The handling of the Association ID, Association Source, optional 216 Global Association Source and optional Extended Association ID in 217 this association are set in the same way as 218 [I-D.ietf-pce-association-bidir]. 220 A member of the 'Double-sided Bidirectional with Reverse LSP 221 Association Group' can take the role of a forward or reverse 222 direction SR Path and follow the similar rules defined in 223 [I-D.ietf-pce-association-bidir] for LSPs. 225 o An SR Path (forward or reverse) cannot be part of more than one 226 'Double-sided Bidirectional with Reverse LSP Association Group'. 228 o The endpoints of the SR Paths in 'Double-sided Bidirectional with 229 Reverse LSP Association Group' cannot be different. 231 3.1.1. Bidirectional LSP Association Group TLV 233 In 'Double-sided Bidirectional with Reverse LSP Association Group', 234 for properties such as forward and reverse direction and co-routed 235 path, it uses the Bidirectional LSP Association Group TLV defined in 236 [I-D.ietf-pce-association-bidir]. All fields and processing rules 237 are as per [I-D.ietf-pce-association-bidir]. 239 4. PCEP Procedures 241 For a Bidirectional SR Path, an ingress PCC is aware of the forward 242 direction SR Path beginning from itself to the egress PCC using the 243 existing PCEP procedures. For the use-cases which require the 244 ingress PCC to be aware of the reverse direction SR Path, PCE informs 245 the reverse SR Path to the ingress PCC. To achieve this, a 246 PCInitiate message for the reverse SR Path is sent to the ingress PCC 247 and a PCInitiate message for the forward SR Path is sent to the 248 egress PCC (with the matching association group). These PCInitiate 249 message MUST NOT trigger initiation of SR Paths on PCCs. 251 The SR Path can be identified by an LSP of an SR Policy as described 252 in [I-D.barth-pce-segment-routing-policy-cp]. 254 For a bidirectional LSP computation when using both direction LSPs on 255 a node, the same LSP would need to be identified using 2 different 256 PLSP-IDs based on the PCEP session to the ingress or the egress node. 257 Note that the PLSP-ID space is independent at each PCC, the PLSP-ID 258 allocated by the egress PCC cannot be used for the LSP at the ingress 259 PCC (PLSP-ID conflict may occur). As per normal PCInitiate 260 operations, PCC assigns the PLSP-IDs for the local LSPs. Hence, when 261 the PCE notifies an ingress PCC of the reverse LSP, it does so by 262 using PCInitiate operations and sets PLSP-ID to zero and sets the R 263 bit in the Bidirectional LSP Association Group TLV in the association 264 object to indicate that this PCInitiate LSP is a reverse LSP. The 265 PCC upon receiving the PCInitiate MUST locally assign a new PLSP-ID 266 and it MUST issue a PCRpt to PCE for this LSP containing the new 267 PLSP-ID. This reverse direction LSP MUST NOT be instantiated on the 268 PCC. 270 In other words, a given LSP will be identified by PLSP-ID A at the 271 ingress node while it will be identified by PLSP-ID B at the egress 272 node. The PCE will maintain two PLSP-IDs for the same LSP. For 273 example, ingress PCC1 may report to PCE an LSP1 with PLSP-ID 100. 274 Egress PCC2 may report to PCE an LSP2 with PLSP-ID 200. Both of 275 these LSPs are part of a bidirectional association. When PCE 276 notifies PCC1 of the reverse direction LSP2, it does so by sending a 277 PCInitiate to PCC1 with PLSP-ID set to zero and R bit set in the 278 Bidirectional LSP Association Group TLV. PCC1 upon reception of this 279 generates a new PLSP-ID (example PLSP-ID 300) and issues a PCRpt to 280 PCE. Thus there would two PLSP-ID associated for LSP2 (300 at PCC1 281 and 200 at PCC2). 283 4.1. PCE Initiated Associated Bidirectional SR Paths 285 As specified in [RFC8697], Associated Bidirectional SR Paths can be 286 created by a Stateful PCE as shown in Figure 1. 288 o Stateful PCE can create and update the forward and reverse SR 289 Paths independently for 'Double-sided Bidirectional with Reverse 290 LSP Association Group'. 292 o Stateful PCE can establish and remove the association relationship 293 on a per SR Path basis. 295 o Stateful PCE can create and update the SR Path and the association 296 on a PCC via PCInitiate and PCUpd messages, respectively, using 297 the procedures described in [RFC8697]. 299 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 300 D as shown in Figure 1) SHOULD be informed by the PCE via 301 PCInitiate message with the matching association group for the 302 use-cases which require the PCC to be aware of the reverse 303 direction SR Path. 305 +-----+ 306 | PCE | 307 +-----+ 308 PCInitiate/PCUpd: / \ PCInitiate/PCUpd: 309 Tunnel 1 (F) / \ Tunnel 2 (F) 310 (LSP1 (F), LSP2 (R)) / \ (LSP2 (F), LSP1 (R)) 311 Association #1 / \ Association #1 312 / \ 313 v v 314 +-----+ LSP1 +-----+ 315 | S |------------>| D | 316 | |<------------| | 317 +-----+ LSP2 +-----+ 318 320 Figure 1: PCE-Initiated Associated Bidirectional SR Path 321 with Forward and Reverse Direction SR Paths 323 4.2. PCC Initiated Associated Bidirectional SR Paths 325 As specified in [RFC8697], Associated Bidirectional SR Paths can also 326 be created by a PCC as shown in Figure 2a and 2b. 328 o PCC can create and update the forward SR Path and update the 329 reverse SR Path independently for a 'Double-sided Bidirectional 330 with Reverse LSP Association Group'. 332 o PCC cannot instantiate a reverse SR Path in a bidirectional SR 333 Path. 335 o PCC can establish and remove the association relationship on a per 336 SR Path basis. 338 o PCC MUST report the change in the association group of an SR Path 339 to PCE(s) via PCRpt message. 341 o PCC can report the forward and reverse SR Paths independently to 342 PCE(s) via PCRpt message. 344 o PCC can delegate the forward and reverse SR Paths independently to 345 a Stateful PCE, where PCE would control the SR Paths. 347 o Stateful PCE can update the SR Paths in the 'Double-sided 348 Bidirectional with Reverse LSP Association Group' via PCUpd 349 message, using the procedures described in [RFC8697]. 351 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 352 D as shown in Figure 2b) SHOULD be informed by the PCE via 353 PCInitiate message with the matching association group for the 354 use-cases which require the PCC to be aware of the reverse 355 direction SR Path. 357 +-----+ 358 | PCE | 359 +-----+ 360 Report/Delegate: ^ ^ Report/Delegate: 361 Tunnel 1 (F) / \ Tunnel 2 (F) 362 (LSP1 (F)) / \ (LSP2 (F)) 363 Association #2 / \ Association #2 364 / \ 365 / \ 366 +-----+ LSP1 +-----+ 367 | S |------------>| D | 368 | |<------------| | 369 +-----+ LSP2 +-----+ 370 372 Figure 2a: Step 1: PCC-Initiated Associated Bidirectional SR 373 Path with Forward Direction SR Paths 375 +-----+ 376 | PCE | 377 +-----+ 378 PCUpd/PCInitiate: / \ PCUpd/PCInitiate: 379 Tunnel 1 (F) / \ Tunnel 2 (F) 380 (LSP1 (F), LSP2 (R)) / \ (LSP2 (F), LSP1 (R)) 381 Association #2 / \ Association #2 382 / \ 383 v v 384 +-----+ LSP1 +-----+ 385 | S |------------>| D | 386 | |<------------| | 387 +-----+ LSP2 +-----+ 388 390 Figure 2b: Step 2: PCE-Updated/Initiated Associated Bidirectional SR 391 Path with Reverse Direction SR Paths 393 4.3. Stateless PCE 395 As defined in [I-D.ietf-pce-association-bidir], for a stateless PCE, 396 it might be useful to associate a path computation request to an 397 association group, thus enabling it to associate a common set of 398 configuration parameters or behaviors with the request. A PCC can 399 request co-routed or non-co-routed forward and reverse direction 400 paths from a stateless PCE for a bidirectional SR association group. 402 4.4. Bidirectional (B) Flag 404 The Bidirectional (B) flag in Request Parameters (RP) object 405 [RFC5440] and Stateful PCE Request Parameter (SRP) object 406 [I-D.ietf-pce-pcep-stateful-pce-gmpls] follow the procedure defined 407 in [I-D.ietf-pce-association-bidir]. 409 4.5. State Synchronization 411 During state synchronization, a PCC MUST report all the existing 412 Bidirectional Association Groups to the Stateful PCE as per 413 [RFC8697]. After the state synchronization, the PCE MUST remove all 414 stale Bidirectional Association Groups. 416 4.6. Error Handling 418 The error handling as described in section 5.7 of 419 [I-D.ietf-pce-association-bidir] continue to apply. 421 The PCEP Path Setup Type (PST) for SR is set to 'TE Path is Setup 422 using Segment Routing' [RFC8408]. If a PCEP speaker receives a 423 different PST value for 'Double-sided Bidirectional with Reverse LSP 424 Association Group' and it does not support; it MUST send a PCErr 425 message with Error-Type = 26 (Association Error) and Error-Value = 426 'Bidirectional LSP Association - Path Setup Type Not Supported' 427 defined in [I-D.ietf-pce-association-bidir]. 429 5. Implementation Status 431 [Note to the RFC Editor - remove this section before publication, as 432 well as remove the reference to [RFC7942]. 434 This section records the status of known implementations of the 435 protocol defined by this specification at the time of posting of this 436 Internet-Draft, and is based on a proposal described in [RFC7942]. 437 The description of implementations in this section is intended to 438 assist the IETF in its decision processes in progressing drafts to 439 RFCs. Please note that the listing of any individual implementation 440 here does not imply endorsement by the IETF. Furthermore, no effort 441 has been spent to verify the information presented here that was 442 supplied by IETF contributors. This is not intended as, and must not 443 be construed to be, a catalog of available implementations or their 444 features. Readers are advised to note that other implementations may 445 exist. 447 According to [RFC7942], "this will allow reviewers and working groups 448 to assign due consideration to documents that have the benefit of 449 running code, which may serve as evidence of valuable experimentation 450 and feedback that have made the implemented protocols more mature. 451 It is up to the individual working groups to use this information as 452 they see fit". 454 5.1. Huawei's Commercial Delivery 456 The feature is developing based on Huawei VRP8. 458 o Organization: Huawei 460 o Implementation: Huawei's Commercial Delivery implementation based 461 on VRP8. 463 o Description: The implementation is under development. 465 o Maturity Level: Product 467 o Contact: tanren@huawei.com 469 5.2. ZTE's Commercial Delivery 471 o Organization: ZTE 473 o Implementation: ZTE's Commercial Delivery implementation based on 474 Rosng v8. 476 o Description: The implementation is under development. 478 o Maturity Level: Product 480 o Contact: zhan.shuangping@zte.com.cn 482 6. Security Considerations 484 The security considerations described in [RFC5440], [RFC8231], 485 [RFC8281], and [RFC8408] apply to the extensions defined in this 486 document as well. 488 A new Association Type for the Association Object, 'Double-sided 489 Bidirectional with Reverse LSP Association Group' is introduced in 490 this document. Additional security considerations related to LSP 491 associations due to a malicious PCEP speaker is described in 492 [RFC8697] and apply to this Association Type. Hence, securing the 493 PCEP session using Transport Layer Security (TLS) [RFC8253] is 494 recommended. 496 7. Manageability Considerations 498 All manageability requirements and considerations listed in 499 [RFC5440], [RFC8231], and [RFC8281] apply to PCEP protocol extensions 500 defined in this document. In addition, requirements and 501 considerations listed in this section apply. 503 7.1. Control of Function and Policy 505 The mechanisms defined in this document do not imply any control or 506 policy requirements in addition to those already listed in [RFC5440], 507 [RFC8231], and [RFC8281]. 509 7.2. Information and Data Models 511 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 512 defined for 'Double-sided Bidirectional with Reverse LSP Association 513 Groups'. The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data 514 model for Associated Bidirectional SR Paths. 516 7.3. Liveness Detection and Monitoring 518 Mechanisms defined in this document do not imply any new liveness 519 detection and monitoring requirements in addition to those already 520 listed in [RFC5440], [RFC8231], and [RFC8281]. 522 7.4. Verify Correct Operations 524 Mechanisms defined in this document do not imply any new operation 525 verification requirements in addition to those already listed in 526 [RFC5440], [RFC8231], and [RFC8408]. 528 7.5. Requirements On Other Protocols 530 Mechanisms defined in this document do not imply any new requirements 531 on other protocols. 533 7.6. Impact On Network Operations 535 Mechanisms defined in [RFC5440], [RFC8231], and [RFC8408] also apply 536 to PCEP extensions defined in this document. 538 8. IANA Considerations 539 8.1. Association Type 541 This document defines a new Association Type for the Association 542 Object (Class Value 40) defined [RFC8697]. IANA is requested to make 543 the assignment of a type for the sub-registry "ASSOCIATION Type" as 544 follows: 546 Type Name Reference 547 ------------------------------------------------------------------- 548 TBD1 Double-sided Bidirectional with Reverse This document 549 LSP Association Group 551 9. References 553 9.1. Normative References 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, 557 DOI 10.17487/RFC2119, March 1997, 558 . 560 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 561 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 562 DOI 10.17487/RFC5440, March 2009, 563 . 565 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 566 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 567 May 2017, . 569 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 570 Computation Element Communication Protocol (PCEP) 571 Extensions for Stateful PCE", RFC 8231, 572 DOI 10.17487/RFC8231, September 2017, 573 . 575 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 576 Computation Element Communication Protocol (PCEP) 577 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 578 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 579 . 581 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 582 Dhody, D., and Y. Tanaka, "Path Computation Element 583 Communication Protocol (PCEP) Extensions for Establishing 584 Relationships between Sets of Label Switched Paths 585 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 586 . 588 [I-D.ietf-pce-association-bidir] 589 Gandhi, R., Barth, C., and B. Wen, "PCEP Extensions for 590 Associated Bidirectional Label Switched Paths (LSPs)", 591 draft-ietf-pce-association-bidir-05 (work in progress), 592 February 2020. 594 [I-D.ietf-pce-sr-path-segment] 595 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 596 "Path Computation Element Communication Protocol (PCEP) 597 Extension for Path Segment in Segment Routing (SR)", 598 draft-ietf-pce-sr-path-segment-00 (work in progress), 599 October 2019. 601 9.2. Informative References 603 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 604 "PCEPS: Usage of TLS to Provide a Secure Transport for the 605 Path Computation Element Communication Protocol (PCEP)", 606 RFC 8253, DOI 10.17487/RFC8253, October 2017, 607 . 609 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 610 Decraene, B., Litkowski, S., and R. Shakir, "Segment 611 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 612 July 2018, . 614 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 615 Code: The Implementation Status Section", BCP 205, 616 RFC 7942, DOI 10.17487/RFC7942, July 2016, 617 . 619 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 620 Hardwick, "Path Computation Element Communication Protocol 621 (PCEP) Management Information Base (MIB) Module", 622 RFC 7420, DOI 10.17487/RFC7420, December 2014, 623 . 625 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 626 Hardwick, "Conveying Path Setup Type in PCE Communication 627 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 628 July 2018, . 630 [I-D.ietf-mpls-bfd-directed] 631 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 632 "Bidirectional Forwarding Detection (BFD) Directed Return 633 Path", draft-ietf-mpls-bfd-directed-13 (work in progress), 634 December 2019. 636 [I-D.gandhi-spring-twamp-srpm] 637 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 638 Janssens, "Performance Measurement Using TWAMP Light and 639 STAMP for Segment Routing Networks", draft-gandhi-spring- 640 twamp-srpm-07 (work in progress), March 2020. 642 [I-D.ietf-spring-mpls-path-segment] 643 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 644 "Path Segment in MPLS Based Segment Routing Network", 645 draft-ietf-spring-mpls-path-segment-02 (work in progress), 646 February 2020. 648 [I-D.ietf-pce-pcep-yang] 649 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 650 YANG Data Model for Path Computation Element 651 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 652 yang-13 (work in progress), October 2019. 654 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 655 Lee, Y., Zheng, H., Dios, O., Lopezalvarez, V., and Z. 656 Ali, "Path Computation Element (PCE) Protocol Extensions 657 for Stateful PCE Usage in GMPLS-controlled Networks", 658 draft-ietf-pce-pcep-stateful-pce-gmpls-12 (work in 659 progress), October 2019. 661 [I-D.barth-pce-segment-routing-policy-cp] 662 Koldychev, M., Sivabalan, S., Barth, C., Li, C., and H. 663 Bidgoli, "PCEP extension to support Segment Routing Policy 664 Candidate Paths", draft-barth-pce-segment-routing-policy- 665 cp-04 (work in progress), October 2019. 667 Acknowledgments 669 Many thanks to Marina Fizgeer, Adrian Farrel, and Andrew Stone for 670 the detailed review of this document and providing many useful 671 comments. 673 Contributors 675 The following people have substantially contributed to this document: 677 Dhruv Dhody 678 Huawei Technologies 679 Divyashree Techno Park, Whitefield 680 Bangalore, Karnataka 560066 681 India 683 Email: dhruv.ietf@gmail.com 685 Zhenbin Li 686 Huawei Technologies 687 Huawei Campus, No. 156 Beiqing Rd. 688 Beijing 100095 689 China 691 Email: lizhenbin@huawei.com 693 Jie Dong 694 Huawei Technologies 695 Huawei Campus, No. 156 Beiqing Rd. 696 Beijing 100095 697 China 699 Email: jie.dong@huawei.com 701 Authors' Addresses 703 Cheng Li 704 Huawei Technologies 705 Huawei Campus, No. 156 Beiqing Rd. 706 Beijing 100095 707 China 709 Email: chengli13@huawei.com 711 Mach(Guoyi) Chen 712 Huawei Technologies 713 Huawei Campus, No. 156 Beiqing Rd. 714 Beijing 100095 715 China 717 Email: Mach.chen@huawei.com 718 Weiqiang Cheng 719 China Mobile 720 China 722 Email: chengweiqiang@chinamobile.com 724 Rakesh Gandhi 725 Cisco Systems, Inc. 726 Canada 728 Email: rgandhi@cisco.com 730 Quan Xiong 731 ZTE Corporation 732 China 734 Email: xiong.quan@zte.com.cn