idnits 2.17.1 draft-li-pce-sr-bidir-path-04.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 11, 2019) is 1872 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 (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-10 == 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 Summary: 0 errors (**), 0 flaws (~~), 5 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 12, 2019 W. Cheng 6 China Mobile 7 Z. Li 8 J. Dong 9 Huawei Technologies 10 R. Gandhi 11 Cisco Systems, Inc. 12 March 11, 2019 14 PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths 15 draft-li-pce-sr-bidir-path-04 17 Abstract 19 The Path Computation Element Communication Protocol (PCEP) provides 20 mechanisms for Path Computation Elements (PCEs) to perform path 21 computations in response to Path Computation Clients (PCCs) requests. 22 The Stateful PCE extensions allow stateful control of Multiprotocol 23 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 24 (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths 25 in Segment Routing (SR) TE networks. 27 This document defines PCEP extensions for grouping two reverse 28 unidirectional SR Paths into an Associated Bidirectional SR Path when 29 using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as 30 well as when using a Stateless PCE. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 9, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 3. PCEP Extension for Bidirectional SR Path . . . . . . . . . . . 4 69 3.1. Double-sided Bidirectional SR Path Association Group 70 Object . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Bidirectional Flag . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Procedures for Associated Bidirectional SR Path Computation . 6 73 5.1. PCE Initiated Associated Bidirectional SR Paths . . . . . 7 74 5.2. PCC Initiated Associated Bidirectional SR Paths . . . . . 8 75 5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 6.1. Association Type . . . . . . . . . . . . . . . . . . . . . 10 78 6.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 10 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 10.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 Segment routing (SR) [RFC8402] leverages the source routing and 90 tunneling paradigms. SR supports to steer packets into an explicit 91 forwarding path at the ingress node. 93 [RFC5440] describes the Path Computation Element (PCE) Communication 94 Protocol (PCEP). PCEP enables the communication between a Path 95 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 96 purpose of computation of Multiprotocol Label Switching (MPLS) as 97 well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched 98 Path (TE LSP) characteristics. 100 [RFC8231] specifies a set of extensions to PCEP to enable stateful 101 control of TE LSPs within and across PCEP sessions in compliance with 102 [RFC4657]. It includes mechanisms to effect LSP State 103 Synchronization between PCCs and PCEs, delegation of control over 104 LSPs to PCEs, and PCE control of timing and sequence of path 105 computations within and across PCEP sessions. The model of operation 106 where LSPs are initiated from the PCE is described in [RFC8281]. 108 [I-D.ietf-pce-segment-routing] specifies extensions to the Path 109 Computation Element Protocol (PCEP) [RFC5440] for SR networks, that 110 allow a stateful PCE to compute and initiate SR-TE paths, as well as 111 a PCC to request, report or delegate SR Paths. 112 [I-D.ietf-pce-segment-routing-ipv6] extend PCEP to support SR for 113 IPv6 data plane. 115 [I-D.ietf-pce-association-group] introduces a generic mechanism to 116 create a grouping of LSPs which can then be used to define 117 associations between a set of LSPs and/or a set of attributes, for 118 example primary and secondary LSP associations, and is equally 119 applicable to the active and passive modes of a Stateful PCE 120 [RFC8231] or a stateless PCE [RFC5440]. 122 Currently, SR networks only support unidirectional paths. However, 123 bidirectional SR Paths are required in some networks, for example, in 124 mobile backhaul transport networks. The requirement of bidirectional 125 SR Path is specified in [I-D.ietf-spring-mpls-path-segment]. 127 [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping 128 two reverse unidirectional MPLS TE LSPs into an Associated 129 Bidirectional LSP when using a Stateful PCE for both PCE-Initiated 130 and PCC-Initiated LSPs as well as when using a Stateless PCE. 132 This document extends the bidirectional association to segment 133 routing by specifying PCEP extensions for grouping two reverse 134 unidirectional SR Paths into a bidirectional SR Path. 136 [I-D.ietf-pce-association-bidir] specifies the Double-sided 137 Bidirectional LSP Association procedure, where the PCE creates the 138 association and provisions at both endpoints, the RSVP-TE does the 139 signaling to the egress the status of the forward LSP and the ingress 140 about the reverse LSP. Thus, the both endpoints learn the reverse 141 LSPs forming the bidirectional LSP association. In case of SR, to 142 support the bidirectional path use-case, this is done using the PCEP 143 protocol. This is done so that both endpoints are aware of the the 144 unidirectional SR Path, as well as the status and other SR path 145 related information. 147 [I-D.li-pce-sr-path-segment] defines a procedure for Path Segment 148 Identifier (PSID) in PCEP for SR using PATH-SEGMENT TLV. The PSID 149 can be a Path Segment Identifier in SR-MPLS 150 [I-D.ietf-spring-mpls-path-segment], or a Path Segment Identifier in 151 SRv6 [I-D.li-spring-srv6-path-segment]. The PSID can be used for an 152 associated bidirectional SR Path for identifying the SR Path. 154 2. Terminology 156 This document makes use of the terms defined in 157 [I-D.ietf-pce-segment-routing]. The reader is assumed to be familiar 158 with the terminology defined in [RFC5440], [RFC8231], [RFC8281], 159 [I-D.ietf-pce-association-group] 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 Extension for Bidirectional SR Path 172 As per [I-D.ietf-pce-association-group], LSPs are associated by 173 adding them to a common association group. 174 [I-D.ietf-pce-association-bidir] specifies PCEP extensions for 175 grouping two reverse unidirectional MPLS-TE LSPs into an Associated 176 Bidirectional LSP for both single-sided and double-sided initiation 177 cases by defining two new Bidirectional LSP Association Groups. 179 This document extends the procedure for associated bidirectional SR 180 Paths by defining a new bidirectional association group (Double-sided 181 Bidirectional SR Path Association Group). The document further 182 describes the mechanism for associating two unidirectional SR Paths 183 into a bidirectional SR Path. [I-D.li-pce-sr-path-segment] defines a 184 procedure for communicating Path Segment in PCEP for SR using 185 PATH-SEGMENT TLV. The bidirectional SR Path can also use the 186 PATH-SEGMENT TLV. 188 Note that an association group is defined in this document to define 189 procedures specific to SR Paths (and the procedures are different 190 than the RSVP-TE bidirectional association groups defined in 191 [I-D.ietf-pce-association-bidir]). 193 3.1. Double-sided Bidirectional SR Path Association Group Object 195 As defined in [I-D.ietf-pce-association-bidir], two LSPs are 196 associated as a bidirectional MPLS-TE LSP by a common bidirectional 197 LSP association group. For associating two SR paths, this document 198 defines a new association group called 'Double-sided Bidirectional SR 199 Path Association Group' as follows: 201 o Association Type (TBD1 to be assigned by IANA) = Double-sided 202 Bidirectional SR Path Association Group 204 Similar to other bidirectional associations, this Association Type is 205 operator-configured in nature and statically created by the operator 206 on the PCEP peers. The paths belonging to this association is 207 conveyed via PCEP messages to the PCEP peer. Operator-configured 208 Association Range TLV [I-D.ietf-pce-association-group] MUST NOT be 209 sent for these Association Types, and MUST be ignored, so that the 210 entire range of association ID can be used for them. The handling of 211 the Association ID, Association Source, optional Global Association 212 Source and optional Extended Association ID in this association are 213 set in the same way as [I-D.ietf-pce-association-bidir]. 215 A member of the 'Double-sided Bidirectional SR Path Association 216 Group' can take the role of a forward or reverse SR Path and follow 217 the similar rules defined in [I-D.ietf-pce-association-bidir] for 218 LSPs. 220 o An SR Path (forward or reverse) can not be part of more than one 221 'Double-sided Bidirectional SR Path Association Group'. 223 o The endpoints of the SR Paths in this associations cannot be 224 different. 226 For describing the SR Paths in this association group, such as 227 direction and co-routed information, this association group reuses 228 the Bidirectional LSP Association Group TLV defined in 229 [I-D.ietf-pce-association-bidir]. All fields and processing rules 230 are as per [I-D.ietf-pce-association-bidir]. 232 4. Bidirectional Flag 234 As defined in [RFC5440], the B-flag in RP object MUST be set when the 235 PCC specifies that the path computation request relates to a 236 bidirectional TE LSP. In this document, the B-flag also MUST be set 237 when the PCC specifies that the path computation request relates to a 238 bidirectional SR Path. When a stateful PCE initiates or updates a 239 bidirectional SR Paths including LSPs and SR paths, the B-flag in SRP 240 object [I-D.ietf-pce-pcep-stateful-pce-gmpls] MAY be set as well. 242 5. Procedures for Associated Bidirectional SR Path Computation 244 Two unidirectional SR Paths can be associated by the association 245 group object as specified in [I-D.ietf-pce-association-group]. A 246 bidirectional LSP association group object is defined in 247 [I-D.ietf-pce-association-bidir] (for MPLS-TE). This document 248 extends these association mechanisms for bidirectional SR Paths. Two 249 SR Paths can be associated together by using the Bidirectional SR 250 Path Association Group defined in this document for PCEP messages. 251 The PATH-SEGMENT TLV [I-D.li-pce-sr-path-segment] SHOULD also be 252 included in the LSP object for these SR Paths to support required 253 use-cases. 255 For bidirectional SR Paths, there is a need to know the reverse 256 direction SR paths. The PCE SHOULD inform the reverse SR Paths to 257 the ingress PCCs and vice versa. To achieve this, a PCInitiate 258 message for the reverse SR Path is sent to the ingress PCC and a 259 PCInitiate message for the forward SR Path is sent to the egress PCC 260 (with the same association group). These PCInitiate message MUST NOT 261 trigger initiation of SR Paths. The reverse direction SR Path can be 262 used for several use-cases, such as directed BFD 263 [I-D.ietf-mpls-bfd-directed]. 265 For a bidirectional LSP computation when using both direction LSPs on 266 a node, the same LSP would need to be identified using 2 different 267 PLSP-IDs based on the PCEP session to the ingress or the egress. In 268 other words, the LSP will have a PLSP-ID A at the ingress node while 269 it will have the PLSP-ID B at the egress node. The PCE will maintain 270 the two PLSP-IDs for the same LSP. For instance, an ingress PCC 271 requests a bidirectional SR Path computation, and the PCE computes a 272 forward LSP1 with PLSP-ID say 100. The reverse LSP2 from the egress 273 to the ingress with PLSP-ID say 200 is allocated by the egress PCC. 274 Since the PLSP-ID space is independent at each PCC, the PLSP-ID 275 allocated by the egress PCC can not be used for the LSP at the 276 ingress PCC (PLSP-ID conflict may occur). Hence, the PCE needs to 277 allocate a PLSP-ID for LSP2 from the ingress PCC's PLSP-ID space , 278 say 101. Similarly for LSP1, it has PLSP-ID 100 at the ingress, and 279 may have say PLSP-ID 201 at the egress node. 281 5.1. PCE Initiated Associated Bidirectional SR Paths 283 As specified in [I-D.ietf-pce-association-group], Bidirectional SR 284 Path Association Group can be created by a Stateful PCE. 286 o Stateful PCE can create and update the forward and reverse SR 287 Paths independently for a 'Double-sided Bidirectional SR Path 288 Association Group'. 290 o Stateful PCE can establish and remove the association relationship 291 on a per SR Path basis. 293 o Stateful PCE can create and update the SR Path and the association 294 on a PCC via PCInitiate and PCUpd messages, respectively, using 295 the procedures described in [I-D.ietf-pce-association-group]. 297 o The PATH-SEGMENT TLV SHOULD be included for each SR Path in the 298 LSP object. 300 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 301 D) SHOULD be informed by PCE via PCInitiate message with the 302 matching association group. 304 +-----+ 305 | PCE | 306 +-----+ 307 PCInitiate/PCUpd: / \ PCInitiate/PCUpd: 308 Tunnel 1 (F) / \ Tunnel 2 (F) 309 (LSP1 (F), LSP2 (R)) / \ (LSP2 (F), LSP1 (R)) 310 Association #1 / \ Association #1 311 / \ 312 v v 313 +-----+ LSP1 +-----+ 314 | S |------------>| D | 315 | |<------------| | 316 +-----+ LSP2 +-----+ 317 319 Figure 1: PCE-Initiated Double-sided Bidirectional SR Path 320 with Forward and Reverse Direction SR Paths 322 5.2. PCC Initiated Associated Bidirectional SR Paths 324 As specified in [I-D.ietf-pce-association-group], Bidirectional SR 325 Path Association Group can also be created by a PCC. 327 o PCC can create and update the forward and reverse SR Paths 328 independently for a 'Double-sided Bidirectional SR Path 329 Association Group'. 331 o PCC can establish and remove the association relationship on a per 332 SR Path basis. 334 o PCC MUST report the change in the association group of an SR Path 335 to PCE(s) via PCRpt message. 337 o PCC can report the forward and reverse SR Paths independently to 338 PCE(s) via PCRpt message. 340 o PCC can delegate the forward and reverse SR Paths independently to 341 a Stateful PCE, where PCE would control the SR Paths. 343 o Stateful PCE can update the SR Paths in the 'Double-sided 344 Bidirectional SR Path Association Group' via PCUpd message, using 345 the procedures described in [I-D.ietf-pce-association-group]. 347 o The PATH-SEGMENT TLV MUST be handled as defined in 348 [I-D.li-pce-sr-path-segment]. 350 o The reverse direction SR Path (LSP2(R) at node S, LSP1(R) at node 351 D) SHOULD be informed by PCE via PCInitiate message with the 352 matching association group. 354 +-----+ 355 | PCE | 356 +-----+ 357 Report/Delegate: ^ ^ Report/Delegate: 358 Tunnel 1 (F) / \ Tunnel 2 (F) 359 (LSP1 (F)) / \ (LSP2 (F)) 360 Association #2 / \ Association #2 361 / \ 362 / \ 363 +-----+ LSP1 +-----+ 364 | S |------------>| D | 365 | |<------------| | 366 +-----+ LSP2 +-----+ 367 369 Figure 2a: Step 1: PCC-Initiated Double-sided Bidirectional SR Path 370 with Forward Direction SR Paths 372 +-----+ 373 | PCE | 374 +-----+ 375 PCUpd/PCInitiate: / \ PCUpd/PCInitiate: 376 Tunnel 1 (F) / \ Tunnel 2 (F) 377 (LSP1 (F), LSP2 (R)) / \ (LSP2 (F), LSP1 (R)) 378 Association #2 / \ Association #2 379 / \ 380 v v 381 +-----+ LSP1 +-----+ 382 | S |------------>| D | 383 | |<------------| | 384 +-----+ LSP2 +-----+ 385 387 Figure 2b: Step 2: PCE-Upd/Initiated Double-sided Bidirectional Path 388 Along with Reverse Direction SR Paths 390 5.3. Error Handling 392 The error handling as described in section 5.5 of 393 [I-D.ietf-pce-association-bidir] continue to apply. 395 The PCEP Path Setup Type (PST) MUST be set to 'TE Path is Setup using 396 Segment Routing' [I-D.ietf-pce-segment-routing] for the LSP belonging 397 to the 'Double-sided Bidirectional SR Path Association Group'. In 398 case a PCEP speaker receives a different PST value for this 399 association group, it MUST send a PCErr message with Error-Type = 29 400 (Early allocation by IANA) (Association Error) and Error-Value = TBD2 401 (Bidirectional LSP Association - Path Setup Type Mismatch). 403 6. IANA Considerations 405 6.1. Association Type 407 This document defines a new Association Type for the Association 408 Object defined [I-D.ietf-pce-association-group]. IANA is requested 409 to make the assignment of a value for the sub-registry "ASSOCIATION 410 Type Field" (to be created in [I-D.ietf-pce-association-group]), as 411 follows: 413 Value Name Reference 414 ------------------------------------------------------------------- 415 TBD1 Double-sided Bidirectional SR Path This document 416 Association Group 418 6.2. PCEP Errors 420 This document defines new Error value for Error Type 29 (Association 421 Error). IANA is requested to allocate new Error value within the 422 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 423 Numbers registry, as follows: 425 Error Type Description Reference 426 ------------------------------------------------------------------- 427 29 Association Error 429 Error value: TBD2 This document 430 Bidirectional LSP Association - 431 Path Setup Type Mismatch 433 7. Security Considerations 435 The security considerations described in [RFC5440], [RFC8231], 436 [RFC8281], and [I-D.ietf-pce-segment-routing] apply to the extensions 437 defined in this document as well. 439 A new Association Type for the Association Object, 'Double-sided 440 Associated Bidirectional SR Path Association Group' is introduced in 441 this document. Additional security considerations related to LSP 442 associations due to a malicious PCEP speaker is described in 443 [I-D.ietf-pce-association-group] and apply to this Association Type. 444 Hence, securing the PCEP session using Transport Layer Security (TLS) 446 [RFC8253] is recommended. 448 8. Contributors 450 The following people have substantially contributed to this document: 452 Dhruv Dhody 453 Huawei Technologies 454 Divyashree Techno Park, Whitefield 455 Bangalore, Karnataka 560066 456 India 458 Email: dhruv.ietf@gmail.com 460 Quan Xiong 461 ZTE Corporation 462 No.6 Huashi Park Rd 463 Wuhan, Hubei 430223 464 China 466 Email: xiong.quan@zte.com.cn 468 9. Acknowledgments 470 Many thanks to Marina Fizgeer for detailed review and comments. 472 10. References 474 10.1. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 482 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 483 DOI 10.17487/RFC5440, March 2009, 484 . 486 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 487 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 488 May 2017, . 490 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 491 Computation Element Communication Protocol (PCEP) 492 Extensions for Stateful PCE", RFC 8231, 493 DOI 10.17487/RFC8231, September 2017, 494 . 496 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 497 Computation Element Communication Protocol (PCEP) 498 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 499 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 500 . 502 [I-D.ietf-pce-association-group] 503 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 504 Dhody, D., and Y. Tanaka, "PCEP Extensions for 505 Establishing Relationships Between Sets of LSPs", draft- 506 ietf-pce-association-group-08 (work in progress), March 507 2019. 509 [I-D.ietf-pce-association-bidir] 510 Gandhi, R., Barth, C., and B. Wen, "PCEP Extensions for 511 Associated Bidirectional Label Switched Paths (LSPs)", 512 draft-ietf-pce-association-bidir (work in progress). 514 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 515 Lee, Y., Zhang, F., Casellas, R., Dios, O., and Z. Ali, 516 "Path Computation Element (PCE) Protocol Extensions for 517 Stateful PCE Usage in GMPLS-controlled Networks", draft- 518 ietf-pce-pcep-stateful-pce-gmpls-10 (work in progress), 519 March 2019. 521 [I-D.li-pce-sr-path-segment] 522 Li, C., Chen, M., Dhody, D., Cheng, W., Dong, J., Li, Z., 523 and R. Gandhi, "Path Computation Element Communication 524 Protocol (PCEP) Extension for Path Segment in Segment 525 Routing (SR)", draft-li-pce-sr-path-segment (work in 526 progress). 528 [I-D.ietf-spring-mpls-path-segment] 529 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 530 "Path Segment in MPLS Based Segment Routing Network", 531 draft-ietf-spring-mpls-path-segment (work in progress). 533 [I-D.li-spring-srv6-path-segment] 534 Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. 535 Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", 536 draft-li-spring-srv6-path-segment-00 (work in progress), 537 October 2018. 539 10.2. Informative References 541 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 542 Element (PCE) Communication Protocol Generic 543 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 544 2006, . 546 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 547 "PCEPS: Usage of TLS to Provide a Secure Transport for the 548 Path Computation Element Communication Protocol (PCEP)", 549 RFC 8253, DOI 10.17487/RFC8253, October 2017, 550 . 552 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 553 Decraene, B., Litkowski, S., and R. Shakir, "Segment 554 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 555 July 2018, . 557 [I-D.ietf-pce-segment-routing] 558 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 559 and J. Hardwick, "PCEP Extensions for Segment Routing", 560 draft-ietf-pce-segment-routing-16 (work in progress), 561 March 2019. 563 [I-D.ietf-pce-segment-routing-ipv6] 564 Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP 565 Extensions for Segment Routing leveraging the IPv6 data 566 plane", draft-ietf-pce-segment-routing-ipv6 (work in 567 progress). 569 [I-D.ietf-mpls-bfd-directed] 570 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 571 "Bidirectional Forwarding Detection (BFD) Directed Return 572 Path", draft-ietf-mpls-bfd-directed-10 (work in progress), 573 September 2018. 575 Authors' Addresses 577 Cheng Li 578 Huawei Technologies 579 Huawei Campus, No. 156 Beiqing Rd. 580 Beijing 100095 581 China 583 Email: chengli13@huawei.com 585 Mach(Guoyi) Chen 586 Huawei Technologies 587 Huawei Campus, No. 156 Beiqing Rd. 588 Beijing 100095 589 China 591 Email: Mach.chen@huawei.com 593 Weiqiang Cheng 594 China Mobile 595 China 597 Email: chengweiqiang@chinamobile.com 599 Zhenbin Li 600 Huawei Technologies 601 Huawei Campus, No. 156 Beiqing Rd. 602 Beijing 100095 603 China 605 Email: lizhenbin@huawei.com 607 Jie Dong 608 Huawei Technologies 609 Huawei Campus, No. 156 Beiqing Rd. 610 Beijing 100095 611 China 612 Email: jie.dong@huawei.com 614 Rakesh Gandhi 615 Cisco Systems, Inc. 616 Canada 618 Email: rgandhi@cisco.com