idnits 2.17.1 draft-li-pce-sr-bidir-path-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2019) is 1860 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 (-10) exists of draft-ietf-pce-association-group-08 == Outdated reference: A later version (-14) exists of draft-ietf-pce-association-bidir-03 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-11 == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-00 == Outdated reference: A later version (-08) exists of draft-li-pce-sr-path-segment-04 == Outdated reference: A later version (-07) exists of draft-li-spring-srv6-path-segment-00 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-10 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-00 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 24, 2019 W. Cheng 6 China Mobile 7 Z. Li 8 J. Dong 9 Huawei Technologies 10 R. Gandhi 11 Cisco Systems, Inc. 12 Q. Xiong 13 ZTE Corporation 14 March 23, 2019 16 PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths 17 draft-li-pce-sr-bidir-path-05 19 Abstract 21 The Path Computation Element Communication Protocol (PCEP) provides 22 mechanisms for Path Computation Elements (PCEs) to perform path 23 computations in response to Path Computation Clients (PCCs) requests. 24 The Stateful PCE extensions allow stateful control of Multiprotocol 25 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 26 (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths 27 in Segment Routing (SR) TE networks. 29 This document defines PCEP extensions for grouping two reverse 30 unidirectional SR Paths into an Associated Bidirectional SR Path when 31 using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as 32 well as when using a Stateless PCE. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 24, 2019. 50 Copyright Notice 52 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 3. PCEP Extension for Bidirectional SR Path . . . . . . . . . . 4 71 3.1. Double-sided Bidirectional SR Path Association Group 72 Object . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Bidirectional Flag . . . . . . . . . . . . . . . . . . . . . 6 74 5. Procedures for Associated Bidirectional SR Path Computation . 6 75 5.1. PCE Initiated Associated Bidirectional SR Paths . . . . . 7 76 5.2. PCC Initiated Associated Bidirectional SR Paths . . . . . 7 77 5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 9 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 6.1. Association Type . . . . . . . . . . . . . . . . . . . . 10 80 6.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 10 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 10.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 Segment routing (SR) [RFC8402] leverages the source routing and 92 tunneling paradigms. SR supports to steer packets into an explicit 93 forwarding path at the ingress node. 95 [RFC5440] describes the Path Computation Element (PCE) Communication 96 Protocol (PCEP). PCEP enables the communication between a Path 97 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 98 purpose of computation of Multiprotocol Label Switching (MPLS) as 99 well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched 100 Path (TE LSP) characteristics. 102 [RFC8231] specifies a set of extensions to PCEP to enable stateful 103 control of TE LSPs within and across PCEP sessions in compliance with 104 [RFC4657]. It includes mechanisms to effect LSP State 105 Synchronization between PCCs and PCEs, delegation of control over 106 LSPs to PCEs, and PCE control of timing and sequence of path 107 computations within and across PCEP sessions. The model of operation 108 where LSPs are initiated from the PCE is described in [RFC8281]. 110 [I-D.ietf-pce-segment-routing] specifies extensions to the Path 111 Computation Element Protocol (PCEP) [RFC5440] for SR networks, that 112 allow a stateful PCE to compute and initiate SR-TE paths, as well as 113 a PCC to request, report or delegate SR Paths. 114 [I-D.ietf-pce-segment-routing-ipv6] extend PCEP to support SR for 115 IPv6 data plane. 117 [I-D.ietf-pce-association-group] introduces a generic mechanism to 118 create a grouping of LSPs which can then be used to define 119 associations between a set of LSPs and/or a set of attributes, for 120 example primary and secondary LSP associations, and is equally 121 applicable to the active and passive modes of a Stateful PCE 122 [RFC8231] or a stateless PCE [RFC5440]. 124 Currently, SR networks only support unidirectional paths. However, 125 bidirectional SR Paths are required in some networks, for example, in 126 mobile backhaul transport networks. The requirement of bidirectional 127 SR Path is specified in [I-D.ietf-spring-mpls-path-segment]. 129 [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping 130 two reverse unidirectional MPLS TE LSPs into an Associated 131 Bidirectional LSP when using a Stateful PCE for both PCE-Initiated 132 and PCC-Initiated LSPs as well as when using a Stateless PCE. 134 This document extends the bidirectional association to segment 135 routing by specifying PCEP extensions for grouping two reverse 136 unidirectional SR Paths into a bidirectional SR Path. 138 [I-D.ietf-pce-association-bidir] specifies the Double-sided 139 Bidirectional LSP Association procedure, where the PCE creates the 140 association and provisions at both endpoints, the RSVP-TE does the 141 signaling to the egress the status of the forward LSP and the ingress 142 about the reverse LSP. Thus, the both endpoints learn the reverse 143 LSPs forming the bidirectional LSP association. In case of SR, to 144 support the bidirectional path use-case, this is done using the PCEP 145 protocol. This is done so that both endpoints are aware of the the 146 unidirectional SR Path, as well as the status and other SR path 147 related information. 149 [I-D.li-pce-sr-path-segment] defines a procedure for Path Segment 150 Identifier (PSID) in PCEP for SR using PATH-SEGMENT TLV. The PSID 151 can be a Path Segment Identifier in SR-MPLS 152 [I-D.ietf-spring-mpls-path-segment], or a Path Segment Identifier in 153 SRv6 [I-D.li-spring-srv6-path-segment]. The PSID can be used for an 154 associated bidirectional SR Path for identifying the SR Path. 156 2. Terminology 158 This document makes use of the terms defined in 159 [I-D.ietf-pce-segment-routing]. The reader is assumed to be familiar 160 with the terminology defined in [RFC5440], [RFC8231], [RFC8281], 161 [I-D.ietf-pce-association-group] and 162 [I-D.ietf-pce-association-bidir]. 164 2.1. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 3. PCEP Extension for Bidirectional SR Path 174 As per [I-D.ietf-pce-association-group], LSPs are associated by 175 adding them to a common association group. 176 [I-D.ietf-pce-association-bidir] specifies PCEP extensions for 177 grouping two reverse unidirectional MPLS-TE LSPs into an Associated 178 Bidirectional LSP for both single-sided and double-sided initiation 179 cases by defining two new Bidirectional LSP Association Groups. 181 This document extends the procedure for associated bidirectional SR 182 Paths by defining a new bidirectional association group (Double-sided 183 Bidirectional SR Path Association Group). The document further 184 describes the mechanism for associating two unidirectional SR Paths 185 into a bidirectional SR Path. [I-D.li-pce-sr-path-segment] defines a 186 procedure for communicating Path Segment in PCEP for SR using PATH- 187 SEGMENT TLV. The bidirectional SR Path can also use the PATH-SEGMENT 188 TLV. 190 Note that an association group is defined in this document to define 191 procedures specific to SR Paths (and the procedures are different 192 than the RSVP-TE bidirectional association groups defined in 193 [I-D.ietf-pce-association-bidir]). 195 3.1. Double-sided Bidirectional SR Path Association Group Object 197 As defined in [I-D.ietf-pce-association-bidir], two LSPs are 198 associated as a bidirectional MPLS-TE LSP by a common bidirectional 199 LSP association group. For associating two SR paths, this document 200 defines a new association group called 'Double-sided Bidirectional SR 201 Path Association Group' as follows: 203 o Association Type (TBD1 to be assigned by IANA) = Double-sided 204 Bidirectional SR Path Association Group 206 Similar to other bidirectional associations, this Association Type is 207 operator-configured in nature and statically created by the operator 208 on the PCEP peers. The paths belonging to this association is 209 conveyed via PCEP messages to the PCEP peer. Operator-configured 210 Association Range TLV [I-D.ietf-pce-association-group] MUST NOT be 211 sent for these Association Types, and MUST be ignored, so that the 212 entire range of association ID can be used for them. The handling of 213 the Association ID, Association Source, optional Global Association 214 Source and optional Extended Association ID in this association are 215 set in the same way as [I-D.ietf-pce-association-bidir]. 217 A member of the 'Double-sided Bidirectional SR Path Association 218 Group' can take the role of a forward or reverse SR Path and follow 219 the similar rules defined in [I-D.ietf-pce-association-bidir] for 220 LSPs. 222 o An SR Path (forward or reverse) can not be part of more than one 223 'Double-sided Bidirectional SR Path Association Group'. 225 o The endpoints of the SR Paths in this associations cannot be 226 different. 228 For describing the SR Paths in this association group, such as 229 direction and co-routed information, this association group reuses 230 the Bidirectional LSP Association Group TLV defined in 231 [I-D.ietf-pce-association-bidir]. All fields and processing rules 232 are as per [I-D.ietf-pce-association-bidir]. 234 4. Bidirectional Flag 236 As defined in [RFC5440], the B-flag in RP object MUST be set when the 237 PCC specifies that the path computation request relates to a 238 bidirectional TE LSP. In this document, the B-flag also MUST be set 239 when the PCC specifies that the path computation request relates to a 240 bidirectional SR Path. When a stateful PCE initiates or updates a 241 bidirectional SR Paths including LSPs and SR paths, the B-flag in SRP 242 object [I-D.ietf-pce-pcep-stateful-pce-gmpls] MAY be set as well. 244 5. Procedures for Associated Bidirectional SR Path Computation 246 Two unidirectional SR Paths can be associated by the association 247 group object as specified in [I-D.ietf-pce-association-group]. A 248 bidirectional LSP association group object is defined in 249 [I-D.ietf-pce-association-bidir] (for MPLS-TE). This document 250 extends these association mechanisms for bidirectional SR Paths. Two 251 SR Paths can be associated together by using the Bidirectional SR 252 Path Association Group defined in this document for PCEP messages. 253 The PATH-SEGMENT TLV [I-D.li-pce-sr-path-segment] SHOULD also be 254 included in the LSP object for these SR Paths to support required 255 use-cases. 257 For bidirectional SR Paths, there is a need to know the reverse 258 direction SR paths. The PCE SHOULD inform the reverse SR Paths to 259 the ingress PCCs and vice versa. To achieve this, a PCInitiate 260 message for the reverse SR Path is sent to the ingress PCC and a 261 PCInitiate message for the forward SR Path is sent to the egress PCC 262 (with the same association group). These PCInitiate message MUST NOT 263 trigger initiation of SR Paths. The reverse direction SR Path can be 264 used for several use-cases, such as directed BFD 265 [I-D.ietf-mpls-bfd-directed]. 267 For a bidirectional LSP computation when using both direction LSPs on 268 a node, the same LSP would need to be identified using 2 different 269 PLSP-IDs based on the PCEP session to the ingress or the egress. In 270 other words, the LSP will have a PLSP-ID A at the ingress node while 271 it will have the PLSP-ID B at the egress node. The PCE will maintain 272 the two PLSP-IDs for the same LSP. For instance, an ingress PCC 273 requests a bidirectional SR Path computation, and the PCE computes a 274 forward LSP1 with PLSP-ID say 100. The reverse LSP2 from the egress 275 to the ingress with PLSP-ID say 200 is allocated by the egress PCC. 276 Since the PLSP-ID space is independent at each PCC, the PLSP-ID 277 allocated by the egress PCC can not be used for the LSP at the 278 ingress PCC (PLSP-ID conflict may occur). Hence, the PCE needs to 279 allocate a PLSP-ID for LSP2 from the ingress PCC's PLSP-ID space , 280 say 101. Similarly for LSP1, it has PLSP-ID 100 at the ingress, and 281 may have say PLSP-ID 201 at the egress node. 283 5.1. PCE Initiated Associated Bidirectional SR Paths 285 As specified in [I-D.ietf-pce-association-group], Bidirectional SR 286 Path Association Group can be created by a Stateful PCE. 288 o Stateful PCE can create and update the forward and reverse SR 289 Paths independently for a 'Double-sided Bidirectional SR Path 290 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 [I-D.ietf-pce-association-group]. 299 o The PATH-SEGMENT TLV SHOULD be included for each SR Path in the 300 LSP object. 302 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 303 D) SHOULD be informed by PCE via PCInitiate message with the 304 matching association group. 306 +-----+ 307 | PCE | 308 +-----+ 309 PCInitiate/PCUpd: / \ PCInitiate/PCUpd: 310 Tunnel 1 (F) / \ Tunnel 2 (F) 311 (LSP1 (F), LSP2 (R)) / \ (LSP2 (F), LSP1 (R)) 312 Association #1 / \ Association #1 313 / \ 314 v v 315 +-----+ LSP1 +-----+ 316 | S |------------>| D | 317 | |<------------| | 318 +-----+ LSP2 +-----+ 319 321 Figure 1: PCE-Initiated Double-sided Bidirectional SR Path 322 with Forward and Reverse Direction SR Paths 324 5.2. PCC Initiated Associated Bidirectional SR Paths 326 As specified in [I-D.ietf-pce-association-group], Bidirectional SR 327 Path Association Group can also be created by a PCC. 329 o PCC can create and update the forward and reverse SR Paths 330 independently for a 'Double-sided Bidirectional SR Path 331 Association Group'. 333 o PCC can establish and remove the association relationship on a per 334 SR Path basis. 336 o PCC MUST report the change in the association group of an SR Path 337 to PCE(s) via PCRpt message. 339 o PCC can report the forward and reverse SR Paths independently to 340 PCE(s) via PCRpt message. 342 o PCC can delegate the forward and reverse SR Paths independently to 343 a Stateful PCE, where PCE would control the SR Paths. 345 o Stateful PCE can update the SR Paths in the 'Double-sided 346 Bidirectional SR Path Association Group' via PCUpd message, using 347 the procedures described in [I-D.ietf-pce-association-group]. 349 o The PATH-SEGMENT TLV MUST be handled as defined in 350 [I-D.li-pce-sr-path-segment]. 352 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 353 D) SHOULD be informed by PCE via PCInitiate message with the 354 matching association group. 356 +-----+ 357 | PCE | 358 +-----+ 359 Report/Delegate: ^ ^ Report/Delegate: 360 Tunnel 1 (F) / \ Tunnel 2 (F) 361 (LSP1 (F)) / \ (LSP2 (F)) 362 Association #2 / \ Association #2 363 / \ 364 / \ 365 +-----+ LSP1 +-----+ 366 | S |------------>| D | 367 | |<------------| | 368 +-----+ LSP2 +-----+ 369 371 Figure 2a: Step 1: PCC-Initiated Double-sided Bidirectional SR Path 372 with Forward Direction SR Paths 374 +-----+ 375 | PCE | 376 +-----+ 377 PCUpd/PCInitiate: / \ PCUpd/PCInitiate: 378 Tunnel 1 (F) / \ Tunnel 2 (F) 379 (LSP1 (F), LSP2 (R)) / \ (LSP2 (F), LSP1 (R)) 380 Association #2 / \ Association #2 381 / \ 382 v v 383 +-----+ LSP1 +-----+ 384 | S |------------>| D | 385 | |<------------| | 386 +-----+ LSP2 +-----+ 387 389 Figure 2b: Step 2: PCE-Upd/Initiated Double-sided Bidirectional Path 390 Along with Reverse Direction SR Paths 392 5.3. Error Handling 394 The error handling as described in section 5.5 of 395 [I-D.ietf-pce-association-bidir] continue to apply. 397 The PCEP Path Setup Type (PST) MUST be set to 'TE Path is Setup using 398 Segment Routing' [I-D.ietf-pce-segment-routing] for the LSP belonging 399 to the 'Double-sided Bidirectional SR Path Association Group'. In 400 case a PCEP speaker receives a different PST value for this 401 association group, it MUST send a PCErr message with Error-Type = 29 402 (Early allocation by IANA) (Association Error) and Error-Value = TBD2 403 (Bidirectional LSP Association - Path Setup Type Mismatch). 405 6. IANA Considerations 407 6.1. Association Type 409 This document defines a new Association Type for the Association 410 Object defined [I-D.ietf-pce-association-group]. IANA is requested 411 to make the assignment of a value for the sub-registry "ASSOCIATION 412 Type Field" (to be created in [I-D.ietf-pce-association-group]), as 413 follows: 415 Value Name Reference 416 ------------------------------------------------------------------- 417 TBD1 Double-sided Bidirectional This document 418 SR Path Association Group 420 6.2. PCEP Errors 422 This document defines new Error value for Error Type 29 (Association 423 Error). IANA is requested to allocate new Error value within the 424 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 425 Numbers registry, as follows: 427 Error Type Description Reference 428 ------------------------------------------------------------------- 429 29 Association Error 431 Error value: TBD2 This document 432 Bidirectional LSP Association - 433 Path Setup Type Mismatch 435 7. Security Considerations 437 The security considerations described in [RFC5440], [RFC8231], 438 [RFC8281], and [I-D.ietf-pce-segment-routing] apply to the extensions 439 defined in this document as well. 441 A new Association Type for the Association Object, 'Double-sided 442 Associated Bidirectional SR Path Association Group' is introduced in 443 this document. Additional security considerations related to LSP 444 associations due to a malicious PCEP speaker is described in 445 [I-D.ietf-pce-association-group] and apply to this Association Type. 446 Hence, securing the PCEP session using Transport Layer Security (TLS) 447 [RFC8253] is recommended. 449 8. Contributors 451 The following people have substantially contributed to this document: 453 Dhruv Dhody 454 Huawei Technologies 455 Divyashree Techno Park, Whitefield 456 Bangalore, Karnataka 560066 457 India 459 Email: dhruv.ietf@gmail.com 461 9. Acknowledgments 463 Many thanks to Marina Fizgeer for detailed review and comments. 465 10. References 467 10.1. Normative References 469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, 471 DOI 10.17487/RFC2119, March 1997, 472 . 474 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 475 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 476 DOI 10.17487/RFC5440, March 2009, 477 . 479 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 480 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 481 May 2017, . 483 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 484 Computation Element Communication Protocol (PCEP) 485 Extensions for Stateful PCE", RFC 8231, 486 DOI 10.17487/RFC8231, September 2017, 487 . 489 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 490 Computation Element Communication Protocol (PCEP) 491 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 492 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 493 . 495 [I-D.ietf-pce-association-group] 496 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 497 Dhody, D., and Y. Tanaka, "PCEP Extensions for 498 Establishing Relationships Between Sets of LSPs", draft- 499 ietf-pce-association-group-08 (work in progress), March 500 2019. 502 [I-D.ietf-pce-association-bidir] 503 Gandhi, R., Barth, C., and B. Wen, "PCEP Extensions for 504 Associated Bidirectional Label Switched Paths (LSPs)", 505 draft-ietf-pce-association-bidir-03 (work in progress), 506 March 2019. 508 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 509 Lee, Y., Zheng, H., Dios, O., Lopezalvarez, V., and Z. 510 Ali, "Path Computation Element (PCE) Protocol Extensions 511 for Stateful PCE Usage in GMPLS-controlled Networks", 512 draft-ietf-pce-pcep-stateful-pce-gmpls-11 (work in 513 progress), March 2019. 515 [I-D.ietf-pce-segment-routing-ipv6] 516 Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP 517 Extensions for Segment Routing leveraging the IPv6 data 518 plane", draft-ietf-pce-segment-routing-ipv6-00 (work in 519 progress), March 2019. 521 [I-D.li-pce-sr-path-segment] 522 Li, C., Chen, M., Cheng, W., Dong, J., Li, Z., and R. 523 Gandhi, "Path Computation Element Communication Protocol 524 (PCEP) Extension for Path Segment in Segment Routing 525 (SR)", draft-li-pce-sr-path-segment-04 (work in progress), 526 March 2019. 528 [I-D.li-spring-srv6-path-segment] 529 Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. 530 Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", 531 draft-li-spring-srv6-path-segment-00 (work in progress), 532 October 2018. 534 10.2. Informative References 536 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 537 Element (PCE) Communication Protocol Generic 538 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 539 2006, . 541 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 542 "PCEPS: Usage of TLS to Provide a Secure Transport for the 543 Path Computation Element Communication Protocol (PCEP)", 544 RFC 8253, DOI 10.17487/RFC8253, October 2017, 545 . 547 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 548 Decraene, B., Litkowski, S., and R. Shakir, "Segment 549 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 550 July 2018, . 552 [I-D.ietf-pce-segment-routing] 553 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 554 and J. Hardwick, "PCEP Extensions for Segment Routing", 555 draft-ietf-pce-segment-routing-16 (work in progress), 556 March 2019. 558 [I-D.ietf-mpls-bfd-directed] 559 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 560 "Bidirectional Forwarding Detection (BFD) Directed Return 561 Path", draft-ietf-mpls-bfd-directed-10 (work in progress), 562 September 2018. 564 [I-D.ietf-spring-mpls-path-segment] 565 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 566 "Path Segment in MPLS Based Segment Routing Network", 567 draft-ietf-spring-mpls-path-segment-00 (work in progress), 568 March 2019. 570 Authors' Addresses 572 Cheng Li 573 Huawei Technologies 574 Huawei Campus, No. 156 Beiqing Rd. 575 Beijing 100095 576 China 578 Email: chengli13@huawei.com 580 Mach(Guoyi) Chen 581 Huawei Technologies 582 Huawei Campus, No. 156 Beiqing Rd. 583 Beijing 100095 584 China 586 Email: Mach.chen@huawei.com 587 Weiqiang Cheng 588 China Mobile 589 China 591 Email: chengweiqiang@chinamobile.com 593 Zhenbin Li 594 Huawei Technologies 595 Huawei Campus, No. 156 Beiqing Rd. 596 Beijing 100095 597 China 599 Email: lizhenbin@huawei.com 601 Jie Dong 602 Huawei Technologies 603 Huawei Campus, No. 156 Beiqing Rd. 604 Beijing 100095 605 China 607 Email: jie.dong@huawei.com 609 Rakesh Gandhi 610 Cisco Systems, Inc. 611 Canada 613 Email: rgandhi@cisco.com 615 Quan Xiong 616 ZTE Corporation 617 China 619 Email: xiong.quan@zte.com.cn