idnits 2.17.1 draft-li-ldr-bgp-request-cp-sr-te-policy-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([I-D.ietf-idr-segment-routing-te-policy]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 08, 2019) is 1753 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) == Missing Reference: 'RFC8491' is mentioned on line 113, but not defined == Missing Reference: 'IEEE.754.1985' is mentioned on line 382, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-07 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft Li 4 Intended status: Standards Track Huawei 5 Expires: January 9, 2020 July 08, 2019 7 BGP Request for Advertising Candidate Path of Segment Routing TE 8 Policies 9 draft-li-ldr-bgp-request-cp-sr-te-policy-00 11 Abstract 13 An SR Policy is a set of candidate paths. The headend of an SR 14 Policy may learn multiple candidate paths for an SR Policy via a 15 number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. 16 BGP distribute candidate paths has been defined in 17 [I-D.ietf-idr-segment-routing-te-policy]. This document defines an 18 extension of BGP to request BGP speaker(controller) advertise the 19 candidate paths. The goal is to unify the protocol when the 20 candidate path of SR Policy provision is via BGP to reduce the 21 network complexity and potential bugs cause by different protocol 22 interactions. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 9, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Overview of BGP UPDATE Message for Request SR TE policy 67 candidate path advertising . . . . . . . . . . . . . . . . . 3 68 4. BGP request UPDATE Message Encoding . . . . . . . . . . . . . 4 69 4.1. Extention of SR Policy NLRI . . . . . . . . . . . . . . . 4 70 4.2. New SR Policy and Tunnel Encapsulation Attribute . . . . 5 71 4.3. New SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . 5 72 4.3.1. LSPA Sub-TLV . . . . . . . . . . . . . . . . . . . . 5 73 4.3.2. SVEC Sub-TLV . . . . . . . . . . . . . . . . . . . . 7 74 4.3.3. Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 8 75 4.3.4. Include Route Sub-TLV . . . . . . . . . . . . . . . . 9 76 4.3.5. Load-Balancing Sub-TLV . . . . . . . . . . . . . . . 10 77 5. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 An SR Policy defined in [I-D.ietf-spring-segment-routing-policy] is a 86 set of candidate paths. The headend of an SR Policy may be informed 87 by various means including: Configuration, PCEP[RFC8281] or 88 BGP[I-D.ietf-idr-segment-routing-te-policy] . All these mechanisms 89 are PCE/Controller initiated, but in some situations headend maybe 90 want pull one or a set of candidate paths from PCE/Controller rather 91 than get all information passively. Actually PCEP can use request 92 and reply messages defined in [RFC5440]to match this requirement but 93 the mechanism is not clear when controller advertise candidate path 94 via BGP protocol. 96 This document wants to define a way to request controller(BGP 97 speaker) advertise candidate path via BGP update message to let BGP 98 protocol can also get the similar mechanism with request and reply 99 like PCEP. 101 2. Terminology 103 RP: Request Parameters 105 LSPA: LSP Attributes 107 SVEC: Synchronization VECtor 109 IRO: Include Route Object 111 ERO: Explicit Route Object 113 MSD: Base MPLS Imposition Maximum SID Depth, as defined in [RFC8491] 115 NAI: Node or Adjacency Identifier 117 PCC: Path Computation Client 119 PCE: Path Computation Element 121 PCEP: Path Computation Element Communication Protocol 123 SID: Segment Identifier 125 SR: Segment Routing 127 SR-TE: Segment Routing Traffic Engineering 129 3. Overview of BGP UPDATE Message for Request SR TE policy candidate 130 path advertising 132 [I-D.ietf-idr-segment-routing-te-policy] defined the headend get 133 candidate paths by BGP from controller(BGP speaker). In some 134 situations headend just want get these candidate paths when some 135 special event occur (e.g receive a customer route (VPN route) with 136 special color or special BGP attribute). This document define the 137 mechanism when this special situation occurred how the headend 138 request controller to advertise the matched SR policy with the 139 candidate paths. 141 Step1. The headend decide to get a new candidate path from 142 controller based on some trigger event. This trigger mechanism is 143 out of scope of this document. 145 Step2. The headend create a new BGP request UPDATE message (defined 146 in this document) with constrains of TE, such as affinity, metric, 147 SRLG, and so on. This special request UPDATE message SHOULD NOT be 148 used for BGP best path selection. 150 Step3. The controller will calculate one or a set of segment list 151 based on the payload of BGP request message from headend. How to 152 calculate the path is out of scope of this document. 154 Step4. The controller advertise SR Policy with candidate path to 155 headend. How to advertise the policy is out of scope of this 156 document and defined in [I-D.ietf-idr-segment-routing-te-policy] 158 4. BGP request UPDATE Message Encoding 160 4.1. Extention of SR Policy NLRI 162 defined the SR Policy NLRI as follows: 164 +------------------+ 165 | NLRI Length | 1 octet 166 +------------------+ 167 | Distinguisher | 4 octets 168 +------------------+ 169 | Policy Color | 4 octets 170 +------------------+ 171 | Endpoint | 4 or 16 octets 172 +------------------+ 174 where: 176 o NLRI Length: 1 octet of length expressed in bits as defined in 177 [RFC4760]. 179 o Distinguisher: 4-octet value uniquely identifying the policy in 180 the context of tuple. The distinguisher has no 181 semantic value and is solely used by the SR Policy originator to 182 make unique (from an NLRI perspective) multiple occurrences of the 183 same SR Policy. 185 o Policy Color: 4-octet value identifying (with the endpoint) the 186 policy. The color is used to match the color of the destination 187 prefixes to steer traffic into the SR Policy 188 [I-D.ietf-spring-segment-routing-policy] 190 o Endpoint: identifies the endpoint of a policy. The Endpoint may 191 represent a single node or a set of nodes (e.g., an anycast 192 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 193 (16-octet) address according to the AFI of the NLRI. 195 NLRI Length, Policy Color, Endpoint field remains unchanged, while 196 the Distinguisher field will be set to FF:FF:FF:FF to signal the 197 request to controller. 199 4.2. New SR Policy and Tunnel Encapsulation Attribute 201 The content of the SR Policy is encoded in the Tunnel Encapsulation 202 Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a 203 new Tunnel-Type TLV (codepoint is 15, assigned by IANA. The SR 204 Policy Encoding structure is as follows: 206 SR Policy SAFI NLRI: 207 Attributes: 208 Tunnel Encaps Attribute (23) 209 Tunnel Type: SR Policy 210 212 Preference, Binding SID, Priority, Policy Name, ENLP, Segment- List, 213 Weight and Segment sub-TLVs are all defined in 214 [I-D.ietf-idr-segment-routing-te-policy] for SR Policy advertise to 215 headend. 217 Additional 6 new Sub-TLVs are defined in this document section 3.3 218 for request mechanism. 220 1. LSPA Sub-TLV 222 2. SVEC Sub-TLV 224 3. Metric Sub-TLV 226 4. Include Route Sub-TLV 228 5. Load-Balancing 230 4.3. New SR Policy Sub-TLVs 232 4.3.1. LSPA Sub-TLV 234 The LSPA(LSP Attributes) Sub-TLV carries the same content as LSPA 235 Object defined in [RFC5440] and [RFC3209]. 237 The LSPA Sub-TLV is optional and specifies various TE LSP attributes 238 to be taken for path computation. Most of the fields of the LSPA 239 Sub-TLV are identical to the fields of the SESSION-ATTRIBUTE object 240 (C-Type = 7) defined in [RFC3209] . See Section 4.7.4 of [RFC3209] 241 for a detailed description of the use of resource affinities. 243 The LSPA sub-TLV has following format: 245 0 1 2 3 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | Flags |L| Reserved | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Exclude-any sub-TLV | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Include-any sub-TLV | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Include-all sub-TLV | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 ~ Optional sub-TLVs ~ 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 where: 261 o Type: TBD1 263 o Length: specifies the length of the value field not including Type 264 and Length fields. 266 o Flags (8 bits) 268 * L flag: Corresponds to the "Local Protection Desired" bit 269 [RFC3209] of the SESSION-ATTRIBUTE Object. When set, this 270 means that the computed path must include links protected with 271 Fast Reroute as defined in [RFC4090]. 273 * Reserved (8 bits): This field MUST be set to zero on 274 transmission and MUST be ignored on receipt. 276 * Unassigned flags MUST be set to zero on transmission and MUST 277 be ignored on receipt. 279 o Optional TLVs may be defined in the future to carry additional TE 280 LSP attributes such as those defined in [RFC5420] 282 o Exclude-any, Include-any, Include-all sub-TLV's format is the same 283 as subobjects defined in[RFC3209] 285 4.3.2. SVEC Sub-TLV 287 The SVEC (Synchronization VECtor) Sub-TLV carries the same content as 288 SVEC Object defined in [RFC5440]. 290 The SVEC Sub-TLV allows headend to request the synchronization of a 291 set of dependent or independent segment list computation requests. 292 It's optional be carried. 294 The SVEC sub-TLV has following format: 296 0 1 2 3 297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Length | Flags |S|N|L| 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 where: 304 o Type: TBD2 306 o Length: the total length (not including the Type and Length 307 fields) of the sub-TLVs encoded 309 o Flags (24 bits): Defines the potential dependency between a set of 310 segment lists in one candidate path. 312 o 314 * L (Link diverse) bit: when set, this indicates that the 315 computed segment lists of the same candidate path MUST NOT have 316 any link in common. 318 * N (Node diverse) bit: when set, this indicates that the 319 computed segment lists of the same candidate path MUST NOT have 320 any node in common. 322 * S (SRLG diverse) bit: when set, this indicates that the 323 computed segment lists of the same candidate path MUST NOT 324 share any SRLG (Shared Risk Link Group). 326 In case of a set of segment lists synchronized independent path 327 computation, the bits L, N, and S are cleared. 329 Unassigned flags MUST be set to zero on transmission and MUST be 330 ignored on receipt. 332 4.3.3. Metric Sub-TLV 334 The Metric Sub-TLV carries the same content as Metric Object defined 335 in[RFC5440] and [I-D.ietf-pce-segment-routing]. The Metric sub-TLV 336 has following format: 338 0 1 2 3 339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type | Length | Flags |C|B| T | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | metric-value (4 octets) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 o Type: TBD3 348 o Length: specifies the length of the value field not including Type 349 and Length fields. 351 o Flags (8 bits): Two flags are currently defined: 353 * B (Bound - 1 bit): When set in a BGP UPDATE message, the 354 metric- value indicates a bound (a maximum) for the path metric 355 that must not be exceeded for the headend to consider the 356 computed path as acceptable. The path metric must be less than 357 or equal to the value specified in the metric-value field. 358 When the B flag is cleared, the metric-value field is not used 359 to reflect a bound constraint. 361 * C (Computed Metric - 1 bit): When set in a BGP UPDATE message, 362 this indicates that the controller MUST provide the computed 363 path metric value (should a path satisfying the constraints be 364 found) in the advertise message for the corresponding metric. 366 * Unassigned flags MUST be set to zero on transmission and MUST 367 be ignored on receipt. 369 o T (Type - 8 bits): Specifies the metric type 371 * Four values are currently defined: 373 * T=1: IGP metric 375 * T=2: TE metric 377 * T=3: Hop Counts 379 * T=11: Maximum SID Depth of the requested path 381 o Metric-value (32 bits): metric value encoded in 32 bits in IEEE 382 floating point format (see [IEEE.754.1985]). 384 4.3.4. Include Route Sub-TLV 386 TheThe Include Route Sub-TLV is optional and can be used to specify 387 that the computed candidate path MUST traverse a set of specified 388 network elements. The Include Route Sub-TLV carries the same content 389 as IRO Object defined in[RFC5440], [RFC3209] and SR-ERO defiend in 390 [I-D.ietf-pce-segment-routing] 392 The Include Route Sub-TLV has following format: 394 0 1 2 3 395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type | Length | NT | Flags | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 ~ SID (optional) ~ 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 ~ NAI (variable, optional) ~ 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Where: 406 o Type: TBD4 408 o Length: specifies the length of the value field not including Type 409 and Length fields. 411 o NAI Type (NT): Indicates the type and format of the NAI contained 412 in the Sub-TLV body, if any is present then the NT field has no 413 meaning and MUST be ignored by the receiver. This document 414 describes the following NT values: 416 * NT=0 The NAI is absent. 418 * NT=1 The NAI is an IPv4 node ID. 420 * NT=2 The NAI is an IPv6 node ID. 422 * NT=3 The NAI is an IPv4 adjacency. 424 * NT=4 The NAI is an IPv6 adjacency with global IPv6 addresses. 426 * NT=5 The NAI is an unnumbered adjacency with IPv4 node IDs. 428 * NT=6 The NAI is an IPv6 adjacency with link-local IPv6 429 addresses. 431 o SID and NAI are the same as SR-ERO defined in 432 [I-D.ietf-pce-segment-routing] 434 4.3.5. Load-Balancing Sub-TLV 436 The Load-Balancing Sub-TLV defined how many segment list should be 437 included in one candidate path. The Load-Balancing sub-TLV has 438 following format: 440 0 1 2 3 441 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type | Length | Flag | Max-Slist | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 ~ Option TLV ~ 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Where: 450 o Type: TBD5 452 o Length: specifies the length of the value field not including Type 453 and Length fields. 455 o Flags (8 bits):No flag is currently defined. The Flags field MUST 456 be set to zero on transmission and MUST be ignored on receipt. 458 o Max-Slist (8 bits): maximum number of S-Lists in the candidate 459 path. 461 o Option TLV: No Option TLV currently defined. If bandwidth can be 462 reserved in SR-Policy candidate path or different load-balancing 463 principle between segment lists for diferent weight here can 464 define additional TLVs. 466 5. IANA 468 This document defines new Sub-TLVs in following existing registries: 470 +------------+-----------------------+---------------------------+ 471 | Type Value | Sub-TLV | Description | 472 +----------------------------------------------------------------+ 473 | TBD1 | LSA-Sub-TLV | This document | 474 +----------------------------------------------------------------+ 475 | TBD2 | SVEC Sub-TLV | This document | 476 +----------------------------------------------------------------+ 477 | TBD3 | Metric Sub-TLV | This document | 478 +----------------------------------------------------------------+ 479 | TBD4 | Include Route Sub-TLV | This document | 480 +----------------------------------------------------------------+ 481 | TBD5 | Load-Balancing | This document | 482 +------------+-----------------------+---------------------------+ 484 6. Contributors 486 TBD 488 7. Acknowledgments 490 TBD 492 8. References 494 [I-D.ietf-idr-segment-routing-te-policy] 495 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain, 496 D., and S. Lin, "Advertising Segment Routing Policies in 497 BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in 498 progress), July 2019. 500 [I-D.ietf-idr-tunnel-encaps] 501 Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The 502 BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 503 tunnel-encaps-12 (work in progress), May 2019. 505 [I-D.ietf-pce-segment-routing] 506 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 507 and J. Hardwick, "PCEP Extensions for Segment Routing", 508 draft-ietf-pce-segment-routing-16 (work in progress), 509 March 2019. 511 [I-D.ietf-spring-segment-routing-policy] 512 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 513 bogdanov@google.com, b., and P. Mattes, "Segment Routing 514 Policy Architecture", draft-ietf-spring-segment-routing- 515 policy-03 (work in progress), May 2019. 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, 519 DOI 10.17487/RFC2119, March 1997, 520 . 522 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 523 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 524 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 525 . 527 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 528 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 529 DOI 10.17487/RFC4090, May 2005, 530 . 532 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 533 "Multiprotocol Extensions for BGP-4", RFC 4760, 534 DOI 10.17487/RFC4760, January 2007, 535 . 537 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 538 Ayyangarps, "Encoding of Attributes for MPLS LSP 539 Establishment Using Resource Reservation Protocol Traffic 540 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 541 February 2009, . 543 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 544 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 545 DOI 10.17487/RFC5440, March 2009, 546 . 548 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 549 Computation Element Communication Protocol (PCEP) 550 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 551 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 552 . 554 Authors' Addresses 556 Zhenbin Li 557 Huawei 558 156 Beiqing Road 559 Beijing, 100095 560 P.R. China 562 Email: lizhenbin@huawei.com 563 Lei Li 564 Huawei 565 156 Beiqing Road 566 Beijing, 100095 567 P.R. China 569 Email: lily.lilei@huawei.com