idnits 2.17.1 draft-ietf-pce-sr-bidir-path-03.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 (September 15, 2020) is 1311 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-07 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-01 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-15 == Outdated reference: A later version (-07) exists of draft-gandhi-spring-stamp-srpm-02 == 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-14 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-13 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-00 Summary: 0 errors (**), 0 flaws (~~), 10 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: March 19, 2021 W. Cheng 6 China Mobile 7 R. Gandhi 8 Cisco Systems, Inc. 9 Q. Xiong 10 ZTE Corporation 11 September 15, 2020 13 PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths 14 draft-ietf-pce-sr-bidir-path-03 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 March 19, 2021. 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 . . . . . . . 6 74 4. PCEP Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. PCE Initiated Associated Bidirectional SR Paths . . . . . 7 76 4.2. PCC Initiated Associated Bidirectional SR Paths . . . . . 8 77 4.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 10 78 4.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 10 79 4.5. State Synchronization . . . . . . . . . . . . . . . . . . 11 80 4.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 11 81 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 82 5.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 12 83 5.2. ZTE's Commercial Delivery . . . . . . . . . . . . . . . . 12 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 7. Manageability Considerations . . . . . . . . . . . . . . . . 12 86 7.1. Control of Function and Policy . . . . . . . . . . . . . 13 87 7.2. Information and Data Models . . . . . . . . . . . . . . . 13 88 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13 89 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13 90 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 13 91 7.6. Impact On Network Operations . . . . . . . . . . . . . . 13 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 93 8.1. Association Type . . . . . . . . . . . . . . . . . . . . 13 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 96 9.2. Informative References . . . . . . . . . . . . . . . . . 15 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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-stamp-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 Note that the procedure for using the association group defined in 156 this document is specific to the associated bidirectional SR Paths. 157 The procedure for this association group is different than the 158 bidirectional association groups defined in 159 [I-D.ietf-pce-association-bidir] for associated bidirectional RSVP-TE 160 LSPs. 162 An SR Policy may contain one or more Candidate-Paths (CPs), each 163 Candidate-Path may contain one or more Segment Lists (SLs) 164 [I-D.ietf-spring-segment-routing-policy]. Recall that in PCEP, an 165 LSP identifies a Candidate-Path as described in 166 [I-D.ietf-pce-segment-routing-policy-cp]. Two unidirectional 167 Candidate-Paths containing a single Segment List (two unidirectional 168 Segment Lists) are associated to form a bidirectional Candidate-Path 169 using the procedures defined in this document. Association of two 170 unidirectional Candidate-Paths containing multiple Segment Lists to 171 form a bidirectional Candidate-Path are outside the scope of this 172 document. 174 2. Terminology 176 This document makes use of the terms defined in [RFC8408]. The 177 reader is assumed to be familiar with the terminology defined in 178 [RFC5440], [RFC8231], [RFC8281], [RFC8697], and 179 [I-D.ietf-pce-association-bidir]. 181 2.1. Requirements Language 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 185 "OPTIONAL" in this document are to be interpreted as described in BCP 186 14 [RFC2119] [RFC8174] when, and only when, they appear in all 187 capitals, as shown here. 189 3. PCEP Extensions 191 As per [RFC8697], TE LSPs are associated by adding them to a common 192 association group by a PCEP peer. [I-D.ietf-pce-association-bidir] 193 uses the association group object and the procedures as specified in 195 [RFC8697] to group two unidirectional RSVP-TE LSPs. Similarly, two 196 SR Paths can also be associated using similar technique. This 197 document extends these association mechanisms for bidirectional SR 198 Paths. Two unidirectional SR Paths (one in each direction in the 199 network) can be associated together by using the association group 200 defined in this document for PCEP messages. 202 [I-D.ietf-pce-sr-path-segment] defines a mechanism for communicating 203 Path Segment Identifier (PSID) in PCEP for SR. The PSID is defined 204 for SR-MPLS in [I-D.ietf-spring-mpls-path-segment]. The PSID can be 205 used for identifying an SR Path of an associated bidirectional SR 206 Path. The PATH-SEGMENT TLV MAY be included for each SR Path in the 207 LSP object to support required use-cases. The PATH-SEGMENT TLV MUST 208 be handled as defined in [I-D.ietf-pce-sr-path-segment] and is not 209 modified for associated bidirectional SR Path. 211 3.1. Double-sided Bidirectional with Reverse LSP Association Group 213 For associating two unidirectional SR Paths, this document defines a 214 new Association Type called 'Double-sided Bidirectional with Reverse 215 LSP Association Group' for Association Group Object (Class-Value 40) 216 as follows: 218 o Association Type (TBD1 to be assigned by IANA) = Double-sided 219 Bidirectional with Reverse LSP Association Group 221 Similar to RSVP-TE bidirectional LSP associations, this Association 222 Type is also operator-configured in nature and statically created by 223 the operator on the PCEP peers. 'Operator-configured Association 224 Range' TLV (Value 29) [RFC8697] MUST NOT be sent for this Association 225 Type, and MUST be ignored, so that the entire range of association ID 226 can be used for it. 228 The handling of the Association ID, Association Source, optional 229 Global Association Source and optional Extended Association ID in 230 this association are set in the same way as 231 [I-D.ietf-pce-association-bidir]. 233 A member of the 'Double-sided Bidirectional with Reverse LSP 234 Association Group' can take the role of a forward or reverse 235 direction SR Path and follow the similar rules defined in 236 [I-D.ietf-pce-association-bidir] for LSPs. 238 o An SR Path (forward or reverse) cannot be part of more than one 239 'Double-sided Bidirectional with Reverse LSP Association Group'. 241 o The endpoints of the SR Paths in 'Double-sided Bidirectional with 242 Reverse LSP Association Group' cannot be different. 244 3.1.1. Bidirectional LSP Association Group TLV 246 In 'Double-sided Bidirectional with Reverse LSP Association Group', 247 for properties such as forward and reverse direction and co-routed 248 path, it uses the Bidirectional LSP Association Group TLV defined in 249 [I-D.ietf-pce-association-bidir]. All fields and processing rules 250 are as per [I-D.ietf-pce-association-bidir]. 252 4. PCEP Procedures 254 For a Bidirectional SR Path, an ingress PCC is aware of the forward 255 direction SR Path beginning from itself to the egress PCC using the 256 existing PCEP procedures. For the use-cases which require the 257 ingress PCC to be aware of the reverse direction SR Path, PCE informs 258 the reverse SR Path to the ingress PCC. To achieve this, a 259 PCInitiate message for the reverse SR Path is sent to the ingress PCC 260 and a PCInitiate message for the forward SR Path is sent to the 261 egress PCC (with the matching association group). These PCInitiate 262 message MUST NOT trigger initiation of SR Paths on PCCs. 264 For a bidirectional LSP computation when using both direction LSPs on 265 a node, the same LSP would need to be identified using 2 different 266 PLSP-IDs based on the PCEP session to the ingress or the egress node. 267 Note that the PLSP-ID space is independent at each PCC, the PLSP-ID 268 allocated by the egress PCC cannot be used for the LSP at the ingress 269 PCC (PLSP-ID conflict may occur). As per normal PCInitiate 270 operations, PCC assigns the PLSP-IDs for the local LSPs. Hence, when 271 the PCE notifies an ingress PCC of the reverse LSP, it does so by 272 using PCInitiate operations and sets PLSP-ID to zero and sets the R 273 bit in the Bidirectional LSP Association Group TLV in the association 274 object to indicate that this PCInitiate LSP is a reverse LSP. The 275 PCC upon receiving the PCInitiate MUST locally assign a new PLSP-ID 276 and it MUST issue a PCRpt to PCE for this LSP containing the new 277 PLSP-ID. This reverse direction LSP MUST NOT be instantiated on the 278 PCC. 280 In other words, a given LSP will be identified by PLSP-ID A at the 281 ingress node while it will be identified by PLSP-ID B at the egress 282 node. The PCE will maintain two PLSP-IDs for the same LSP. For 283 example, ingress PCC1 may report to PCE an LSP1 with PLSP-ID 100. 284 Egress PCC2 may report to PCE an LSP2 with PLSP-ID 200. Both of 285 these LSPs are part of a bidirectional association. When PCE 286 notifies PCC1 of the reverse direction LSP2, it does so by sending a 287 PCInitiate to PCC1 with PLSP-ID set to zero and R bit set in the 288 Bidirectional LSP Association Group TLV. PCC1 upon reception of this 289 generates a new PLSP-ID (example PLSP-ID 300) and issues a PCRpt to 290 PCE. Thus there would two PLSP-ID associated for LSP2 (300 at PCC1 291 and 200 at PCC2). 293 4.1. PCE Initiated Associated Bidirectional SR Paths 295 As specified in [RFC8697], Associated Bidirectional SR Paths can be 296 created by a Stateful PCE as shown in Figure 1. 298 o Stateful PCE can create and update the forward and reverse SR 299 Paths independently for 'Double-sided Bidirectional with Reverse 300 LSP Association Group'. 302 o Stateful PCE can establish and remove the association relationship 303 on a per SR Path basis. 305 o Stateful PCE can create and update the SR Path and the association 306 on a PCC via PCInitiate and PCUpd messages, respectively, using 307 the procedures described in [RFC8697]. 309 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 310 D as shown in Figure 1) SHOULD be informed by the PCE via 311 PCInitiate message with the matching association group for the 312 use-cases which require the PCC to be aware of the reverse 313 direction SR Path. 315 +-----+ 316 | PCE | 317 +-----+ 318 PCInitiate: / \ PCInitiate: 319 Tunnel 1 (F) / \ Tunnel 2 (F) 320 LSP1 (F,0), LSP2 (R,0) / \ LSP2 (F,0), LSP1 (R,0) 321 Association #1 / \ Association #1 322 / \ 323 v v 324 +-----+ LSP1 +-----+ 325 | S |------------>| D | 326 | |<------------| | 327 +-----+ LSP2 +-----+ 328 330 Figure 1a: PCE-Initiated Associated Bidirectional SR Path 331 with Forward and Reverse Direction SR Paths 333 +-----+ 334 | PCE | 335 +-----+ 336 PCRpt: ^ ^ PCRpt: 337 Tunnel 1 (F) / \ Tunnel 2 (F) 338 LSP1 (F,100), LSP2 (R,300) / \ LSP2 (F,200), LSP1 (R,400) 339 Association #1 / \ Association #1 340 / \ 341 / \ 342 +-----+ LSP1 +-----+ 343 | S |------------>| D | 344 | |<------------| | 345 +-----+ LSP2 +-----+ 346 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 by a PCC as shown in Figure 2a and 2b. 356 o PCC can create and update the forward SR Path and update the 357 reverse SR Path independently for a 'Double-sided Bidirectional 358 with Reverse LSP Association Group'. 360 o PCC cannot instantiate a reverse SR Path in a bidirectional SR 361 Path. 363 o PCC can 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 can report the forward and reverse SR Paths independently to 370 PCE(s) via PCRpt message. 372 o PCC can delegate the forward and reverse SR Paths independently to 373 a Stateful PCE, where PCE would control the SR Paths. 375 o Stateful PCE can update the SR Paths in the 'Double-sided 376 Bidirectional with Reverse LSP Association Group' via PCUpd 377 message, 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 Figure 2a: Step 1: PCC-Initiated Associated Bidirectional SR 401 Path with Forward Direction SR Paths 403 +-----+ 404 | PCE | 405 +-----+ 406 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 Figure 2b: Step 2: PCE-Initiated Associated Bidirectional SR 420 Path with Reverse Direction SR Paths 422 +-----+ 423 | PCE | 424 +-----+ 425 PCRpt: ^ ^ PCRpt: 426 Tunnel 1 (F) / \ Tunnel 2 (F) 427 LSP1 (F,100), LSP2 (R,300) / \ LSP2 (F,200), LSP1 (R,400) 428 Association #2 / \ Association #2 429 / \ 430 / \ 431 +-----+ LSP1 +-----+ 432 | S |------------>| D | 433 | |<------------| | 434 +-----+ LSP2 +-----+ 435 437 Figure 2c: Step 3: PCC-Reported Associated Bidirectional SR 438 Path with Reverse Direction SR Paths 440 4.3. Stateless PCE 442 As defined in [I-D.ietf-pce-association-bidir], for a stateless PCE, 443 it might be useful to associate a path computation request to an 444 association group, thus enabling it to associate a common set of 445 configuration parameters or behaviors with the request. A PCC can 446 request co-routed or non-co-routed forward and reverse direction 447 paths from a stateless PCE for a bidirectional SR association group. 449 4.4. Bidirectional (B) Flag 451 The Bidirectional (B) flag in Request Parameters (RP) object 452 [RFC5440] and Stateful PCE Request Parameter (SRP) object 454 [I-D.ietf-pce-pcep-stateful-pce-gmpls] follow the procedure defined 455 in [I-D.ietf-pce-association-bidir]. 457 4.5. State Synchronization 459 During state synchronization, a PCC MUST report all the existing 460 Bidirectional Association Groups to the Stateful PCE as per 461 [RFC8697]. After the state synchronization, the PCE MUST remove all 462 stale Bidirectional Association Groups. 464 4.6. Error Handling 466 The error handling as described in section 5.7 of 467 [I-D.ietf-pce-association-bidir] continue to apply. 469 The PCEP Path Setup Type (PST) for SR is set to 'TE Path is Setup 470 using Segment Routing' [RFC8408]. If a PCEP speaker receives a 471 different PST value for 'Double-sided Bidirectional with Reverse LSP 472 Association Group' and it does not support; it MUST send a PCErr 473 message with Error-Type = 26 (Association Error) and Error-Value = 474 'Bidirectional LSP Association - Path Setup Type Not Supported' 475 defined in [I-D.ietf-pce-association-bidir]. 477 5. Implementation Status 479 [Note to the RFC Editor - remove this section before publication, as 480 well as remove the reference to [RFC7942]. 482 This section records the status of known implementations of the 483 protocol defined by this specification at the time of posting of this 484 Internet-Draft, and is based on a proposal described in [RFC7942]. 485 The description of implementations in this section is intended to 486 assist the IETF in its decision processes in progressing drafts to 487 RFCs. Please note that the listing of any individual implementation 488 here does not imply endorsement by the IETF. Furthermore, no effort 489 has been spent to verify the information presented here that was 490 supplied by IETF contributors. This is not intended as, and must not 491 be construed to be, a catalog of available implementations or their 492 features. Readers are advised to note that other implementations may 493 exist. 495 According to [RFC7942], "this will allow reviewers and working groups 496 to assign due consideration to documents that have the benefit of 497 running code, which may serve as evidence of valuable experimentation 498 and feedback that have made the implemented protocols more mature. 499 It is up to the individual working groups to use this information as 500 they see fit". 502 5.1. Huawei's Commercial Delivery 504 The feature is developing based on Huawei VRP8. 506 o Organization: Huawei 508 o Implementation: Huawei's Commercial Delivery implementation based 509 on VRP8. 511 o Description: The implementation is under development. 513 o Maturity Level: Product 515 o Contact: tanren@huawei.com 517 5.2. ZTE's Commercial Delivery 519 o Organization: ZTE 521 o Implementation: ZTE's Commercial Delivery implementation based on 522 Rosng v8. 524 o Description: The implementation is under development. 526 o Maturity Level: Product 528 o Contact: zhan.shuangping@zte.com.cn 530 6. Security Considerations 532 The security considerations described in [RFC5440], [RFC8231], 533 [RFC8281], and [RFC8408] apply to the extensions defined in this 534 document as well. 536 A new Association Type for the Association Object, 'Double-sided 537 Bidirectional with Reverse LSP Association Group' is introduced in 538 this document. Additional security considerations related to LSP 539 associations due to a malicious PCEP speaker is described in 540 [RFC8697] and apply to this Association Type. Hence, securing the 541 PCEP session using Transport Layer Security (TLS) [RFC8253] is 542 recommended. 544 7. Manageability Considerations 546 All manageability requirements and considerations listed in 547 [RFC5440], [RFC8231], and [RFC8281] apply to PCEP protocol extensions 548 defined in this document. In addition, requirements and 549 considerations listed in this section apply. 551 7.1. Control of Function and Policy 553 The mechanisms defined in this document do not imply any control or 554 policy requirements in addition to those already listed in [RFC5440], 555 [RFC8231], and [RFC8281]. 557 7.2. Information and Data Models 559 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 560 defined for 'Double-sided Bidirectional with Reverse LSP Association 561 Groups'. The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data 562 model for Associated Bidirectional SR Paths. 564 7.3. Liveness Detection and Monitoring 566 Mechanisms defined in this document do not imply any new liveness 567 detection and monitoring requirements in addition to those already 568 listed in [RFC5440], [RFC8231], and [RFC8281]. 570 7.4. Verify Correct Operations 572 Mechanisms defined in this document do not imply any new operation 573 verification requirements in addition to those already listed in 574 [RFC5440], [RFC8231], and [RFC8408]. 576 7.5. Requirements On Other Protocols 578 Mechanisms defined in this document do not imply any new requirements 579 on other protocols. 581 7.6. Impact On Network Operations 583 Mechanisms defined in [RFC5440], [RFC8231], and [RFC8408] also apply 584 to PCEP extensions defined in this document. 586 8. IANA Considerations 588 8.1. Association Type 590 This document defines a new Association Type for the Association 591 Object (Class Value 40) defined [RFC8697]. IANA is requested to make 592 the assignment of a type for the sub-registry "ASSOCIATION Type" as 593 follows: 595 Type Name Reference 596 ------------------------------------------------------------------- 597 TBD1 Double-sided Bidirectional with Reverse This document 598 LSP Association Group 600 9. References 602 9.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, 606 DOI 10.17487/RFC2119, March 1997, 607 . 609 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 610 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 611 DOI 10.17487/RFC5440, March 2009, 612 . 614 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 615 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 616 May 2017, . 618 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 619 Computation Element Communication Protocol (PCEP) 620 Extensions for Stateful PCE", RFC 8231, 621 DOI 10.17487/RFC8231, September 2017, 622 . 624 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 625 Computation Element Communication Protocol (PCEP) 626 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 627 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 628 . 630 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 631 Dhody, D., and Y. Tanaka, "Path Computation Element 632 Communication Protocol (PCEP) Extensions for Establishing 633 Relationships between Sets of Label Switched Paths 634 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 635 . 637 [I-D.ietf-pce-association-bidir] 638 Gandhi, R., Barth, C., and B. Wen, "PCEP Extensions for 639 Associated Bidirectional Label Switched Paths (LSPs)", 640 draft-ietf-pce-association-bidir-07 (work in progress), 641 September 2020. 643 [I-D.ietf-pce-sr-path-segment] 644 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 645 "Path Computation Element Communication Protocol (PCEP) 646 Extension for Path Segment in Segment Routing (SR)", 647 draft-ietf-pce-sr-path-segment-01 (work in progress), May 648 2020. 650 9.2. Informative References 652 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 653 "PCEPS: Usage of TLS to Provide a Secure Transport for the 654 Path Computation Element Communication Protocol (PCEP)", 655 RFC 8253, DOI 10.17487/RFC8253, October 2017, 656 . 658 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 659 Decraene, B., Litkowski, S., and R. Shakir, "Segment 660 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 661 July 2018, . 663 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 664 Code: The Implementation Status Section", BCP 205, 665 RFC 7942, DOI 10.17487/RFC7942, July 2016, 666 . 668 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 669 Hardwick, "Path Computation Element Communication Protocol 670 (PCEP) Management Information Base (MIB) Module", 671 RFC 7420, DOI 10.17487/RFC7420, December 2014, 672 . 674 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 675 Hardwick, "Conveying Path Setup Type in PCE Communication 676 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 677 July 2018, . 679 [I-D.ietf-mpls-bfd-directed] 680 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 681 "Bidirectional Forwarding Detection (BFD) Directed Return 682 Path for MPLS Label Switched Paths (LSPs)", draft-ietf- 683 mpls-bfd-directed-15 (work in progress), August 2020. 685 [I-D.gandhi-spring-stamp-srpm] 686 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 687 Janssens, "Performance Measurement Using Simple TWAMP 688 (STAMP) for Segment Routing Networks", draft-gandhi- 689 spring-stamp-srpm-02 (work in progress), August 2020. 691 [I-D.ietf-spring-mpls-path-segment] 692 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 693 "Path Segment in MPLS Based Segment Routing Network", 694 draft-ietf-spring-mpls-path-segment-02 (work in progress), 695 February 2020. 697 [I-D.ietf-pce-pcep-yang] 698 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 699 YANG Data Model for Path Computation Element 700 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 701 yang-14 (work in progress), July 2020. 703 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 704 Lee, Y., Zheng, H., Dios, O., Lopezalvarez, V., and Z. 705 Ali, "Path Computation Element (PCE) Protocol Extensions 706 for Stateful PCE Usage in GMPLS-controlled Networks", 707 draft-ietf-pce-pcep-stateful-pce-gmpls-13 (work in 708 progress), April 2020. 710 [I-D.ietf-spring-segment-routing-policy] 711 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 712 P. Mattes, "Segment Routing Policy Architecture", draft- 713 ietf-spring-segment-routing-policy-08 (work in progress), 714 July 2020. 716 [I-D.ietf-pce-segment-routing-policy-cp] 717 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 718 Bidgoli, "PCEP extension to support Segment Routing Policy 719 Candidate Paths", draft-ietf-pce-segment-routing-policy- 720 cp-00 (work in progress), June 2020. 722 Acknowledgments 724 Many thanks to Marina Fizgeer, Adrian Farrel, Andrew Stone, and Tarek 725 Saad for the detailed review of this document and providing many 726 useful comments. 728 Contributors 730 The following people have substantially contributed to this document: 732 Dhruv Dhody 733 Huawei Technologies 734 Divyashree Techno Park, Whitefield 735 Bangalore, Karnataka 560066 736 India 738 Email: dhruv.ietf@gmail.com 740 Zhenbin Li 741 Huawei Technologies 742 Huawei Campus, No. 156 Beiqing Rd. 743 Beijing 100095 744 China 746 Email: lizhenbin@huawei.com 748 Jie Dong 749 Huawei Technologies 750 Huawei Campus, No. 156 Beiqing Rd. 751 Beijing 100095 752 China 754 Email: jie.dong@huawei.com 756 Authors' Addresses 758 Cheng Li 759 Huawei Technologies 760 Huawei Campus, No. 156 Beiqing Rd. 761 Beijing 100095 762 China 764 Email: chengli13@huawei.com 766 Mach(Guoyi) Chen 767 Huawei Technologies 768 Huawei Campus, No. 156 Beiqing Rd. 769 Beijing 100095 770 China 772 Email: Mach.chen@huawei.com 773 Weiqiang Cheng 774 China Mobile 775 China 777 Email: chengweiqiang@chinamobile.com 779 Rakesh Gandhi 780 Cisco Systems, Inc. 781 Canada 783 Email: rgandhi@cisco.com 785 Quan Xiong 786 ZTE Corporation 787 China 789 Email: xiong.quan@zte.com.cn