idnits 2.17.1 draft-li-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 (October 22, 2018) is 2012 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-06 == Outdated reference: A later version (-14) exists of draft-ietf-pce-association-bidir-01 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-08 == Outdated reference: A later version (-04) exists of draft-negi-pce-segment-routing-ipv6-03 == Outdated reference: A later version (-08) exists of draft-li-pce-sr-path-segment-02 == Outdated reference: A later version (-07) exists of draft-li-spring-srv6-path-segment-00 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-14 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-10 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 D. Dhody 5 Expires: April 25, 2019 Huawei Technologies 6 W. Cheng 7 China Mobile 8 Z. Li 9 J. Dong 10 Huawei Technologies 11 R. Gandhi 12 Cisco Systems, Inc. 13 October 22, 2018 15 PCEP Extension for Segment Routing (SR) Bidirectional Associated Paths 16 draft-li-pce-sr-bidir-path-02 18 Abstract 20 The Path Computation Element Communication Protocol (PCEP) provides 21 mechanisms for Path Computation Elements (PCEs) to perform path 22 computations in response to Path Computation Clients (PCCs) requests. 23 The Stateful PCE extensions allow stateful control of Multiprotocol 24 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 25 (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths 26 in SR networks. 28 This document defines PCEP extensions for grouping two reverse 29 unidirectional SR Paths into an Associated Bidirectional SR path when 30 using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as 31 well as when using a Stateless 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 April 25, 2019. 50 Copyright Notice 52 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . 5 74 5. Procedures of Bidirectional Path Computation . . . . . . . . 6 75 5.1. PCE Initiated SR Paths . . . . . . . . . . . . . . . . . 6 76 5.2. PCC Initiated SR Paths . . . . . . . . . . . . . . . . . 7 77 5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 6.1. Association Type . . . . . . . . . . . . . . . . . . . . 9 80 6.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 9 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 9.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 Segment routing (SR) [RFC8402] leverages the source routing and 91 tunneling paradigms. SR supports to steer packets into an explicit 92 forwarding path at the ingress node. 94 [RFC5440] describes the Path Computation Element (PCE) Communication 95 Protocol (PCEP). PCEP enables the communication between a Path 96 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 97 purpose of computation of Multiprotocol Label Switching (MPLS) as 98 well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched 99 Path (TE LSP) characteristics. 101 [RFC8231] specifies a set of extensions to PCEP to enable stateful 102 control of TE LSPs within and across PCEP sessions in compliance with 103 [RFC4657]. It includes mechanisms to effect LSP State 104 Synchronization between PCCs and PCEs, delegation of control over 105 LSPs to PCEs, and PCE control of timing and sequence of path 106 computations within and across PCEP sessions. The model of operation 107 where LSPs are initiated from the PCE is described in [RFC8281]. 109 [I-D.ietf-pce-segment-routing] specifies extensions to the Path 110 Computation Element Protocol (PCEP) [RFC5440] for SR networks, that 111 allow a stateful PCE to compute and initiate SR-TE paths, as well as 112 a PCC to request, report or delegate SR paths. 113 [I-D.negi-pce-segment-routing-ipv6] extend PCEP to support SR for 114 IPv6 data plane. 116 [I-D.ietf-pce-association-group] introduces a generic mechanism to 117 create a grouping of LSPs which can then be used to define 118 associations between a set of LSPs and/or a set of attributes, for 119 example primary and secondary LSP associations, and is equally 120 applicable to the active and passive modes of a Stateful PCE 121 [RFC8231] or a stateless PCE [RFC5440]. 123 Currently, SR network only supports unidirectional path, but the 124 bidirectional SR path is required in some scenarios, for example, 125 mobile backhaul transport network. The requirement of SR 126 bidirectional path is specified in 127 [I-D.cheng-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] specify the Double-sided 139 Bidirectional procedure, where the PCE creates the association and 140 provisions at the both ends, the RSVP-TE does the signaling to the 141 egress the status of the forward LSP and the ingress about the 142 reverse LSP. Thus, the both ends learn both the LSPs forming the 143 bidirectional association. In case of SR, to support the 144 bidirectional use-case, this is done via the PCEP protocol itself as 145 described in Section 3.1. This is done so that both ends are aware 146 of the Path Segment used by each of the unidirectional LSP, as well 147 as the status, the ERO etc. 149 [I-D.li-pce-sr-path-segment] defines a procedure for Path Segment in 150 PCEP for SR by defining the PATH-SEGMENT TLV. The Path Segment can 151 be a Path Segment in SR-MPLS [I-D.cheng-spring-mpls-path-segment], or 152 a Path Segment in SRv6 [I-D.li-spring-srv6-path-segment], or other 153 IDs that can identify an SR path. The PATH-SEGMENT TLV SHOULD be 154 included for associated bidirectional SR paths. 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 SR bidirectional associated 182 paths by defining a new bidirectional association type (i.e. Double- 183 sided Bidirectional SR Path Association Group). The document further 184 describes the mechanism of associating two unidirectional SR path 185 into a bidirectional SR path. [I-D.li-pce-sr-path-segment] defines a 186 procedure for Path Segment in PCEP for SR by defining the PATH- 187 SEGMENT TLV. The bidirectional SR path can also use the PATH-SEGMENT 188 TLV. 190 Note that a new association type is created by this document to 191 create new procedures applicable to SR-path (and are quite different 192 than the RSVP-TE bidirectional association groups). 194 3.1. Double-sided Bidirectional SR Path Association Group Object 196 As defined in [I-D.ietf-pce-association-bidir], two LSPs are 197 associated as a bidirectional MPLS-TE LSP by a common bidirectional 198 LSP association group. For associating two SR paths, this document 199 defines a new association group called 'Double-sided Bidirectional SR 200 Path Association Group' as follows: 202 o Association Type (TBD1 to be assigned by IANA) = Double-sided 203 Bidirectional SR Path Association Group 205 Similar to other bidirectional associations, this Association Type is 206 operator-configured in nature and statically created by the operator 207 on the PCEP peers. The paths belonging to this association is 208 conveyed via PCEP messages to the PCEP peer. Operator-configured 209 Association Range TLV [I-D.ietf-pce-association-group] MUST NOT be 210 sent for these Association Types, and MUST be ignored, so that the 211 entire range of association ID can be used for them. The handling of 212 the Association ID, Association Source, optional Global Association 213 Source and optional Extended Association ID in this association are 214 set in the same way as [I-D.ietf-pce-association-bidir]. 216 A member of the Double-sided Bidirectional SR Path Association Group 217 can take the role of a forward or reverse SR path and follows the 218 rules similar to the rules defined in 219 [I-D.ietf-pce-association-bidir] for LSPs. 221 o An SR path (forward or reverse) can not be part of more than one 222 Double-sided Bidirectional SR Path Association Group. 224 o The endpoints of the SR paths in this associations cannot be 225 different. 227 For describing the SR paths in this association group, such as 228 direction and co-routed information, this association group reuses 229 the Bidirectional LSP Association Group TLV defined in 230 [I-D.ietf-pce-association-bidir]. All fields and processing rules 231 are as per [I-D.ietf-pce-association-bidir]. 233 4. Bidirectional Flag 235 As defined in [RFC5440], the B-flag in RP object MUST be set when the 236 PCC specifies that the path computation request relates to a 237 bidirectional TE LSP. In this document, the B-flag also MUST be set 238 when the PCC specifies that the path computation request relates to a 239 bidirectional SR path. When a stateful PCE initiates or updates a 240 bidirectional SR paths including LSPs and SR paths, the B-flag in SRP 241 object [I-D.ietf-pce-pcep-stateful-pce-gmpls] may be set as well. 243 5. Procedures of Bidirectional Path Computation 245 Two unidirectional SR paths can be associated by the association 246 group object as specified in [I-D.ietf-pce-association-group]. A 247 bidirectional LSP association group object is defined in 248 [I-D.ietf-pce-association-bidir] (for MPLS-TE). This documents 249 extends the mechanism for bidirectional SR paths. Two SR paths can 250 be associated together by including the Bidirectional SR Path 251 Association Group in the PCEP messages. The PATH-SEGMENT TLV 252 [I-D.li-pce-sr-path-segment] SHOULD also be included in the LSP 253 object for these SR paths to support required use-cases. 255 There is also a need to include the reverse direction path in the 256 PCEP messages, to do this the PCE SHOULD inform the reverse SR path 257 to the ingress PCC 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 information of reverse direction 262 path can be used for several scenarios, such as directed BFD 263 [I-D.ietf-mpls-bfd-directed]. 265 5.1. PCE Initiated SR Paths 267 As specified in [I-D.ietf-pce-association-group] Bidirectional SR 268 Association Group can be created by a Stateful PCE. 270 o Stateful PCE can create and update the forward and reverse SR path 271 independently for Double-sided Bidirectional SR Path Association 272 Groups. 274 o Stateful PCE can establish and remove the association relationship 275 on a per SR path basis. 277 o Stateful PCE can create and update the SR path and the association 278 on a PCC via PCInitiate and PCUpd messages, respectively, using 279 the procedures described in [I-D.ietf-pce-association-group]. 281 o The PATH-SEGMENT TLV SHOULD be included for each SR path in the 282 LSP object. 284 o The opposite direction SR path (LSP2(R) at S, LSP1(F) at D ) 285 SHOULD be informed via PCInitiate message with the matching 286 association group. 288 +-----+ 289 | PCE | 290 +-----+ 291 PCUpd/PCInitiate / \ PCUpd/PCInitiate 292 Tunnel 1 (F) / \ Tunnel 2 (R) 293 (LSP1 (F), LSP2 (R)) / \ (LSP2 (R), LSP1 (F)) 294 Assoc#1 / \ Assoc#1 295 / \ 296 v v 297 +-----+ LSP1 +-----+ 298 | S |------------>| D | 299 | |<------------| | 300 +-----+ LSP2 +-----+ 301 303 Figure 1: PCE-Initiated Double-sided Bidirectional SR Path 305 5.2. PCC Initiated SR Paths 307 As specified in [I-D.ietf-pce-association-group] Bidirectional SR 308 Association Group can also be created by a PCC. 310 o PCC can create and update the forward and reverse SR paths 311 independently for Double-sided Bidirectional SR Path Association 312 Groups. 314 o PCC can establish and remove the association relationship on a per 315 SR path basis. 317 o PCC MUST report the change in the association group of an SR path 318 to PCE(s) via PCRpt message. 320 o PCC can report the forward and reverse SR paths independently to 321 PCE(s) via PCRpt message. 323 o PCC can delegate the forward and reverse SR paths independently to 324 a Stateful PCE, where PCE would control the SR paths. 326 o Stateful PCE can update the SR paths in the Double-sided 327 Bidirectional SR Path Association Group via PCUpd message, using 328 the procedures described in [I-D.ietf-pce-association-group]. 330 o The PATH-SEGMENT TLV MUST be handled as defined in 331 [I-D.li-pce-sr-path-segment]. 333 o The opposite direction SR path (LSP2(R) at S, LSP1(F) at D ) 334 SHOULD be informed via PCInitiate message with the matching 335 association group. 337 +-----+ 338 | PCE | 339 +-----+ 340 Reports/Delegates: ^ ^ Reports/Delegates 341 Tunnel 1 (F) / \ Tunnel 2 (R) 342 (LSP1 (F)) / \ (LSP2 (R)) 343 / \ 344 / \ 345 / \ 346 +-----+ LSP1 +-----+ 347 | S |------------>| D | 348 | |<------------| | 349 +-----+ LSP2 +-----+ 351 Figure 2a: PCC-Initiated Double-sided Bidirectional SR Path 353 +-----+ 354 | PCE | 355 +-----+ 356 PCUpd/PCInitiate / \ PCUpd/PCInitiate 357 Tunnel 1 (F) / \ Tunnel 2 (R) 358 (LSP1 (F), LSP2 (R)) / \ (LSP2 (R), LSP1 (F)) 359 Assoc#1 / \ Assoc#1 360 / \ 361 v v 362 +-----+ LSP1 +-----+ 363 | S |------------>| D | 364 | |<------------| | 365 +-----+ LSP2 +-----+ 367 Figure 2b: PCC-Initiated Double-sided Bidirectional SR Path 368 along with opposite direction SR path 370 5.3. Error Handling 372 The error handling as described in section 5.5 of 373 [I-D.ietf-pce-association-bidir] continue to apply. 375 The Path Setup Type (PST) MUST be set to SR for the LSP belonging to 376 the 'Double-sided Bidirectional SR Path Association Group', in case a 377 PCEP speaker receives a different PST value, it MUST send an PCErr 378 message with Error-Type = 29 (Early allocation by IANA) (Association 379 Error) and Error-Value = TBD2 (Bidirectional LSP Association - PST 380 Mismatch). 382 6. IANA Considerations 384 6.1. Association Type 386 This document defines a new Association Type for the Association 387 Object defined [I-D.ietf-pce-association-group]. IANA is requested 388 to make the assignment of a value for the sub-registry "ASSOCIATION 389 Type Field" (to be created in [I-D.ietf-pce-association-group]), as 390 follows: 392 Value Name Reference 393 ------------------------------------------------------------------- 394 TBD1 Double-sided Bidirectional This document 395 SR Path Association Group 397 6.2. PCEP Errors 399 This document defines new Error value for Error Type 29 (Association 400 Error). IANA is requested to allocate new Error value within the 401 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 402 Numbers registry, as follows: 404 Error Type Description Reference 405 ------------------------------------------------------------------- 406 29 Association Error 408 Error value: TBD2 This document 409 Bidirectional LSP Association - PST Mismatch 411 7. Security Considerations 413 The security considerations described in [RFC5440], [RFC8231], 414 [RFC8281], and [I-D.ietf-pce-segment-routing] apply to the extensions 415 defined in this document as well. 417 A new Association Type for the Association Object, Double-sided 418 Associated Bidirectional SR Path Association Group is introduced in 419 this document. Additional security considerations related to LSP 420 associations due to a malicious PCEP speaker is described in 421 [I-D.ietf-pce-association-group] and apply to this Association Type. 422 Hence, securing the PCEP session using Transport Layer Security (TLS) 423 [RFC8253] is recommended. 425 8. Acknowledgments 427 9. References 429 9.1. Normative References 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, 433 DOI 10.17487/RFC2119, March 1997, 434 . 436 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 437 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 438 DOI 10.17487/RFC5440, March 2009, 439 . 441 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 442 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 443 May 2017, . 445 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 446 Computation Element Communication Protocol (PCEP) 447 Extensions for Stateful PCE", RFC 8231, 448 DOI 10.17487/RFC8231, September 2017, 449 . 451 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 452 Computation Element Communication Protocol (PCEP) 453 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 454 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 455 . 457 [I-D.ietf-pce-association-group] 458 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 459 Dhody, D., and Y. Tanaka, "PCEP Extensions for 460 Establishing Relationships Between Sets of LSPs", draft- 461 ietf-pce-association-group-06 (work in progress), June 462 2018. 464 [I-D.ietf-pce-association-bidir] 465 Barth, C., Gandhi, R., and B. Wen, "PCEP Extensions for 466 Associated Bidirectional Label Switched Paths (LSPs)", 467 draft-ietf-pce-association-bidir-01 (work in progress), 468 May 2018. 470 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 471 Zhang, X., Lee, Y., Zhang, F., Casellas, R., Dios, O., and 472 Z. Ali, "Path Computation Element (PCE) Protocol 473 Extensions for Stateful PCE Usage in GMPLS-controlled 474 Networks", draft-ietf-pce-pcep-stateful-pce-gmpls-08 (work 475 in progress), February 2018. 477 [I-D.negi-pce-segment-routing-ipv6] 478 Negi, M., Dhody, D., Sivabalan, S., and P. Kaladharan, 479 "PCEP Extensions for Segment Routing leveraging the IPv6 480 data plane", draft-negi-pce-segment-routing-ipv6-03 (work 481 in progress), October 2018. 483 [I-D.li-pce-sr-path-segment] 484 Li, C., Chen, M., Dhody, D., Cheng, W., Dong, J., Li, Z., 485 and R. Gandhi, "Path Computation Element Communication 486 Protocol (PCEP) Extension for Path Identification in 487 Segment Routing (SR)", draft-li-pce-sr-path-segment-02 488 (work in progress), September 2018. 490 [I-D.li-spring-srv6-path-segment] 491 Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. 492 Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", 493 draft-li-spring-srv6-path-segment-00 (work in progress), 494 October 2018. 496 9.2. Informative References 498 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 499 Element (PCE) Communication Protocol Generic 500 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 501 2006, . 503 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 504 "PCEPS: Usage of TLS to Provide a Secure Transport for the 505 Path Computation Element Communication Protocol (PCEP)", 506 RFC 8253, DOI 10.17487/RFC8253, October 2017, 507 . 509 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 510 Decraene, B., Litkowski, S., and R. Shakir, "Segment 511 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 512 July 2018, . 514 [I-D.ietf-pce-segment-routing] 515 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 516 and J. Hardwick, "PCEP Extensions for Segment Routing", 517 draft-ietf-pce-segment-routing-14 (work in progress), 518 October 2018. 520 [I-D.ietf-mpls-bfd-directed] 521 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 522 "Bidirectional Forwarding Detection (BFD) Directed Return 523 Path", draft-ietf-mpls-bfd-directed-10 (work in progress), 524 September 2018. 526 [I-D.cheng-spring-mpls-path-segment] 527 Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler, 528 R., and S. Zhan, "Path Segment in MPLS Based Segment 529 Routing Network", draft-cheng-spring-mpls-path-segment-03 530 (work in progress), October 2018. 532 Authors' Addresses 534 Cheng Li 535 Huawei Technologies 536 Huawei Campus, No. 156 Beiqing Rd. 537 Beijing 100095 538 China 540 Email: chengli13@huawei.com 542 Mach(Guoyi) Chen 543 Huawei Technologies 544 Huawei Campus, No. 156 Beiqing Rd. 545 Beijing 100095 546 China 548 Email: Mach.chen@huawei.com 550 Dhruv Dhody 551 Huawei Technologies 552 Divyashree Techno Park, Whitefield 553 Bangalore, Karnataka 560066 554 India 556 Email: dhruv.ietf@gmail.com 557 Weiqiang Cheng 558 China Mobile 559 China 561 Email: chengweiqiang@chinamobile.com 563 Zhenbin Li 564 Huawei Technologies 565 Huawei Campus, No. 156 Beiqing Rd. 566 Beijing 100095 567 China 569 Email: lizhenbin@huawei.com 571 Jie Dong 572 Huawei Technologies 573 Huawei Campus, No. 156 Beiqing Rd. 574 Beijing 100095 575 China 577 Email: jie.dong@huawei.com 579 Rakesh Gandhi 580 Cisco Systems, Inc. 581 Canada 583 Email: rgandhi@cisco.com