idnits 2.17.1 draft-peng-pce-te-constraints-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 (September 1, 2020) is 1332 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 (-22) exists of draft-ietf-idr-tunnel-encaps-17 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-10 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE S. Peng 3 Internet-Draft Q. Xiong 4 Intended status: Standards Track ZTE Corporation 5 Expires: March 5, 2021 F. Qin 6 China Mobile 7 September 1, 2020 9 PCE TE Constraints for Network Slicing 10 draft-peng-pce-te-constraints-04 12 Abstract 14 This document proposes a set of extensions for PCEP to support the TE 15 constraints of network slicing during path computation, e.g, IGP 16 instance, virtual network, specific application, color template and 17 FA-id etc. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 5, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 3 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. PCEP Extensions for TE Constraints in Network Slicing . . . . 3 58 3.1. Source Protocol TLV . . . . . . . . . . . . . . . . . . . 3 59 3.2. Multi-topology TLV . . . . . . . . . . . . . . . . . . . 4 60 3.3. The AII TLV . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Application Specific TLV . . . . . . . . . . . . . . . . 6 62 3.5. The Color TLV . . . . . . . . . . . . . . . . . . . . . . 7 63 3.6. The FA-id TLV . . . . . . . . . . . . . . . . . . . . . . 8 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 [RFC5440] describes the Path Computation Element Protocol (PCEP) 73 which is used between a Path Computation Element (PCE) and a Path 74 Computation Client (PCC) (or other PCE) to enable computation of 75 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 76 Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model 77 [RFC8231] describes a set of extensions to PCEP to enable active 78 control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. As depicted 79 in [RFC4655], a PCE MUST be able to compute the path of a TE LSP by 80 operating on the TED and considering bandwidth and other constraints 81 applicable to the TE LSP service request. The constraint parameters 82 are provided such as metric, bandwidth, delay, affinity, etc. 83 However these parameters can't meet the network slicing requirements. 85 According to 5G context, network slicing is the collection of a set 86 of technologies to support network service differentiation and 87 meeting the diversified requirements from vertical industries. The 88 slices may be seen as virtual networks and partition the network 89 resources into sub-topologies in transport network. Multiple 90 existing identifiers could be used to identify the virtual network 91 resource and viewed as constraints of network slicing when PCE is 92 deployed. 94 A PCE always perform path computation based on the network topology 95 information collected through BGP-LS [RFC7752]. BGP-LS can get 96 multiple link-state data from multiple IGP instance, or multiple 97 virtual topologies from a single IGP instance. It is necessary to 98 restrict the PCE to a small topology scope during path computation 99 for some special purpose. BGP-LS can also get application specific 100 TE attributes for a link, it is also necessary to restrict PCE to use 101 TE attributes of specific application. The PCE MUST take the 102 identifier of slicing into consideration during path computation. 104 This document proposes a set of extensions for PCEP to support the TE 105 constraints for network slicing during path computation, e.g, IGP 106 instance, virtual network, specific application, color template and 107 FA-id etc. 109 2. Conventions used in this document 111 2.1. Terminology 113 The terminology is defined as [RFC5440] and [RFC7752]. 115 2.2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. PCEP Extensions for TE Constraints in Network Slicing 125 As defined in [RFC5440] , the LSPA object is used to specify the LSP 126 attributes to be taken into account by the PCE during path 127 computation such as TE constraints. This document proposes several 128 new TLVs for the LSPA object to carry TE constraints in Network 129 Slicing. 131 3.1. Source Protocol TLV 133 The Source Protocol TLV is optional and is defined to carry the 134 source protocol constraint. 136 In a PCReq message, a PCC MAY insert one Source Protocol TLV to 137 indicate the source protocol that MUST be considered by the PCE. The 138 PCE will perform path computation based on the sub-topology 139 identified by the specific source protocol. The absence of the 140 Source Protocol TLV MUST be interpreted by the PCE as a path 141 computation request for which no constraints need be applied to any 142 of the source protocols. 144 In a PCRep/PCInit/PCUpd message, the Source Protocol TLV MAY be 145 carried so as to provide the source protocol information for the 146 computed path. 148 The format of the Source Protocol TLV is shown as Figure 1: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type=TBD1 | Length=12 | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Protocol-ID | Reserved | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Identifier | 158 | (64 bits) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: Source Protocol TLV 163 The code point for the TLV type is TBD1. The TLV length is 12 164 octets. 166 Protocol-ID (8 bits): defined in [RFC7752] section 3.2. 168 Reserved (24 bits): This field MUST be set to zero on transmission 169 and MUST be ignored on receipt. 171 Identifier (64 bits): defined in [RFC7752] section 3.2. 173 3.2. Multi-topology TLV 175 The Multi-topology TLV is optional and is defined to carry the multi- 176 topology protocol constraint. 178 In a PCReq message, a PCC MAY insert one Multi-topology TLV to 179 indicate the sub-topology of an IGP instance that MUST be considered 180 by the PCE. The PCE will perform path computation based on the sub- 181 topology identified by the specific Multi-Topology ID within a source 182 protocol. The absence of the Multi-topology TLV MUST be interpreted 183 by the PCE as a path computation request for which no constraints 184 need be applied to any of the multi-topologies. 186 In a PCRep/PCInit/PCUpd message, the Multi-topology TLV MAY be 187 carried so as to provide the Multi-topology information for the 188 computed path. 190 The Multi-topology TLV MUST be carried after a Source Protocol TLV, 191 if not it MUST be ignored. 193 The format of the Multi-topology TLV is shown as Figure 2: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type=TBD2 | Length=4 | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |R R R R| Multi-Topology ID | Reserved | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 2: Multi-topology TLV 205 The code point for the TLV type is TBD2. The TLV length is 4 octets. 207 Multi-Topology ID (12 bits): Semantics of the IS-IS MT-ID are defined 208 in Section 7.2 of [RFC5120]. Semantics of the OSPF MT-ID are defined 209 in Section 3.7 of [RFC4915]. If the value is derived from OSPF, then 210 the upper 9 bits MUST be set to 0. Bits R are reserved and SHOULD be 211 set to 0 when originated and ignored on receipt. 213 Reserved (16 bits): This field MUST be set to zero on transmission 214 and MUST be ignored on receipt. 216 3.3. The AII TLV 218 Administrative Instance Identifier (AII) is provided to specify the 219 TE purpose within a virtual network as per 220 [I-D.peng-lsr-network-slicing]. The AII TLV is optional and is 221 defined to carry the AII constraint. 223 In a PCReq message, a PCC MAY insert one AII TLV to indicate the 224 global virtual network that MUST be considered by the PCE. The PCE 225 will perform path computation based on the intra-domain or inter- 226 domain sub-topology identified by the specific AII, which is 227 independent of routing protocols such as IGP/BGP. The absence of the 228 AII TLV MUST be interpreted by the PCE as a path computation request 229 for which no constraints need be applied to any of the virtual 230 network, i.e, a default AII (0) will be applied. 232 In a PCRep/PCInit/PCUpd message, the AII TLV MAY be carried so as to 233 provide the network slicing information for the computed path. 235 The format of the AII TLV is shown as Figure 3: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type=TBD3 | Length=4 | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | AII | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 3: AII TLV 247 The code point for the TLV type is TBD3. The TLV length is 4 octets. 249 AII (32 bits): indicate the AII information as defined in 250 [I-D.peng-lsr-network-slicing]. 252 3.4. Application Specific TLV 254 The Application Specific TLV is optional and is defined to carry the 255 application specific constraints. 257 In a PCReq message, a PCC MAY insert one Application Specific TLV to 258 indicate the application that MUST be considered by the PCE. The PCE 259 will perform path computation using the specific application 260 attributes. The absence of the Application Specific TLV MUST be 261 interpreted by the PCE as a path computation request for which no 262 constraints need be applied to any of the Application Specific 263 attributes. 265 In a PCRep/PCInit/PCUpd message, the Application Specific TLV MAY be 266 inserted so as to provide the Application Specific information for 267 the computed path. 269 The format of the Application Specific TLV is shown as Figure 4: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type=TBD4 | Length=8 | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Standard Application ID | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | User Defined Application ID | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 4: Application Specific TLV 283 The code point for the TLV type is TBD4. The TLV length is 8 octets. 285 Standard Application ID: Represents a bit-position value for a single 286 STANDARD application that is defined in the IANA "IGP Parameters" 287 registries under the "Link Attribute Applications" registry 288 [I-D.ietf-isis-te-app]. 290 User Defined Application ID: Represents a single user defined 291 application which is a specific implementation. 293 3.5. The Color TLV 295 The Color TLV is optional and is defined to carry the color 296 constraints. 298 In a PCReq message, a PCC MAY insert one Color TLV to indicate the 299 traffic engineering purpose that is recognized by both PCE and PCC 300 with no conflict meaning. The PCE will perform path computation 301 based on the color template. The same color template may be also 302 defined at PCC and the existing constraints (i.e, metric, bandwidth, 303 delay, etc) carried in the message MUST be ignored. The absence of 304 the Color TLV MUST be interpreted by the PCE as a path computation 305 request for which traditional constraints that are contained in 306 message need be applied. 308 In a PCRep/PCInit/PCUpd message, the Color TLV MAY be inserted so as 309 to provide the TE purpose information for the computed path, the PCC 310 recognize the color value that match a local color-template. 312 The format of the Color TLV is shown as Figure 5: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type=TBD5 | Length=4 | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Color | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 5: Color TLV 324 The code point for the TLV type is TBD5. The TLV length is 4 octets. 326 Color (32 bits): indicate a TE template, 0 is invalid value. It is 327 consistent with the Color Extended Community defined in 329 [I-D.ietf-idr-tunnel-encaps], and color of SR policy defined in 330 [I-D.ietf-spring-segment-routing-policy]. 332 Note that Color TLV defined in this document is used to represent a 333 TE template, it can be suitable for any TE instance such as RSVP-TE, 334 SR-TE, SR-policy. [I-D.ietf-pce-segment-routing-policy-cp] has 335 proposed the SR policy KEY (that also includes a color information) 336 as an association group KEY to associate many candidate paths, 337 however it is only for association purpose but not constraint purpose 338 for path computation. 340 A color template can be defined to contain existing constraints such 341 as metric, bandwidth, delay, affinity parameters, and the sub- 342 topology constraints above defined in this document. 344 3.6. The FA-id TLV 346 FA-id defined in [I-D.ietf-lsr-flex-algo] is a short mapping of SR 347 policy color to optimize segment stack depth for the IGP area partial 348 of the entire SR policy. The overlay service that want to be carried 349 over a particular SR-FA path must firstly let the SR policy supplier 350 know that requirement. There are two possible ways to map a color to 351 an FA-id. One is explicit mapping configuration within color 352 template, the other is dynamicly replacing a long segment list to 353 short FA segment by headend or controller once the constraints 354 contained in the color-template equal to that contained in FAD. 356 In addition to the above mapping behavior, it is also possible to 357 merge the constraints contained in the color-template and constraints 358 contained in FAD. The merging behavior can be used to compute SR-TE 359 path within a Flex-algo plane. 361 In a PCReq message, a PCC MAY insert one FA-id TLV to indicate the 362 above explicit FA-id mapping or merging. 364 For mapping case, the PCE will perform path computation based on the 365 FA-id. In detailed, The PCE will check if there are connectivity 366 within the corresponding Flex-algo plane to the destination. If yes, 367 the path computation result will be represented as segment list with 368 a single prefix-SID@FA for intra-domain case, or several prefix- 369 SID@FA for inter-domain case. 371 For merging case, the PCE will perform path computation based on the 372 total constraints combinded with the ones contained in FAD identified 373 by FA-id and other ones contained in PCReq message. The later 374 constraints can get from color template or directly represent by a 375 color. In this case the computed path will be limited in the 376 specific Flex-algo plane determined by link resource Including/ 377 Excluding rules of FAD, and at the same time the path will also meet 378 other constraints for the TE purpose within the Flex-algo plane. The 379 PCE can optimize the strictly path to a loosely path when a part of 380 the strictly path is consistent with the algorithm based path, i.e, 381 some consecutive adjacency SIDs can be replaced with a single 382 algorithm based prefix Sid. 384 In a PCRep/PCInit/PCUpd message, the FA-id TLV MAY be inserted so as 385 to provide the FA plane information for the computed path. 387 In general, the FA-id TLV is only meaningful for the domain (ingress 388 domain) that headend node belongs to. For inter-domain case, 389 operator SHOULD ensure the FA-id configuration of different domain 390 are same for an E2E slice, when he want to explicitly indicate FA-id 391 in PCEP message, otherwise the PCE has to choose different FA-id for 392 other domain as long as the contents of FAD is consistent with the 393 one of ingress domain. 395 The format of the FA-id TLV is shown as Figure 6: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type=TBD6 | Length=4 | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | FA-id |M| Flags | Reserved | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 6: FA-id TLV 407 The code point for the TLV type is TBD6. The TLV length is 4 octets. 409 FA-id (8 bits): indicate an explicit FA-id information. 411 Flags (8 bits): Currently only one flag, Flag-M, is defined. 413 Flag-M: Indicate mapping behavior when unset, and merging behavior 414 when set. 416 4. Security Considerations 418 TBA 420 5. Acknowledgements 422 TBA 424 6. IANA Considerations 426 IANA is requested to make allocations from the registry, as follows: 428 +-------+---------------------------+------------------+ 429 | Type | TLV | Reference | 430 +-------+---------------------------+------------------+ 431 | TBD1 | Source Protocol TLV | [this document] | 432 | TBD2 | Multi-topology TLV | [this document] | 433 | TBD3 | AII TLV | [this document] | 434 | TBD4 | Application Specific TLV | [this document] | 435 | TBD5 | Color TLV | [this document] | 436 | TBD6 | FA-id TLV | [this document] | 437 +-------+---------------------------+------------------+ 439 Table 1 441 7. Normative References 443 [I-D.ietf-idr-tunnel-encaps] 444 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 445 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 446 encaps-17 (work in progress), July 2020. 448 [I-D.ietf-isis-te-app] 449 Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 450 J. Drake, "IS-IS Application-Specific Link Attributes", 451 draft-ietf-isis-te-app-19 (work in progress), June 2020. 453 [I-D.ietf-lsr-flex-algo] 454 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 455 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 456 algo-10 (work in progress), August 2020. 458 [I-D.ietf-pce-segment-routing-policy-cp] 459 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 460 Bidgoli, "PCEP extension to support Segment Routing Policy 461 Candidate Paths", draft-ietf-pce-segment-routing-policy- 462 cp-00 (work in progress), June 2020. 464 [I-D.ietf-spring-segment-routing-policy] 465 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 466 P. Mattes, "Segment Routing Policy Architecture", draft- 467 ietf-spring-segment-routing-policy-08 (work in progress), 468 July 2020. 470 [I-D.peng-lsr-network-slicing] 471 Peng, S., Chen, R., and G. Mirsky, "Packet Network Slicing 472 using Segment Routing", draft-peng-lsr-network-slicing-00 473 (work in progress), February 2019. 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, 477 DOI 10.17487/RFC2119, March 1997, 478 . 480 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 481 Element (PCE)-Based Architecture", RFC 4655, 482 DOI 10.17487/RFC4655, August 2006, 483 . 485 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 486 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 487 RFC 4915, DOI 10.17487/RFC4915, June 2007, 488 . 490 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 491 Topology (MT) Routing in Intermediate System to 492 Intermediate Systems (IS-ISs)", RFC 5120, 493 DOI 10.17487/RFC5120, February 2008, 494 . 496 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 497 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 498 DOI 10.17487/RFC5440, March 2009, 499 . 501 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 502 S. Ray, "North-Bound Distribution of Link-State and 503 Traffic Engineering (TE) Information Using BGP", RFC 7752, 504 DOI 10.17487/RFC7752, March 2016, 505 . 507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 508 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 509 May 2017, . 511 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 512 Computation Element Communication Protocol (PCEP) 513 Extensions for Stateful PCE", RFC 8231, 514 DOI 10.17487/RFC8231, September 2017, 515 . 517 Authors' Addresses 519 Shaofu Peng 520 ZTE Corporation 521 No.50 Software Avenue 522 Nanjing, Jiangsu 210012 523 China 525 Email: peng.shaofu@zte.com.cn 527 Quan Xiong 528 ZTE Corporation 529 No.6 Huashi Park Rd 530 Wuhan, Hubei 430223 531 China 533 Email: xiong.quan@zte.com.cn 535 Fengwei Qin 536 China Mobile 537 Beijing 538 China 540 Email: qinfengwei@chinamobile.com