idnits 2.17.1 draft-peng-pce-te-constraints-06.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 (July 11, 2021) is 1020 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-bestbar-teas-ns-packet-02 ** Downref: Normative reference to an Informational draft: draft-bestbar-teas-ns-packet (ref. 'I-D.bestbar-teas-ns-packet') == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-15 == Outdated reference: A later version (-11) exists of draft-ietf-pce-multipath-00 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slice-definition (ref. 'I-D.ietf-teas-ietf-network-slice-definition') ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) ** Obsolete normative reference: RFC 8919 (Obsoleted by RFC 9479) Summary: 5 errors (**), 0 flaws (~~), 6 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: January 12, 2022 F. Qin 6 China Mobile 7 M. Koldychev 8 Cisco Systems 9 S. Sivabalan 10 Ciena Corporation 11 July 11, 2021 13 PCE TE Constraints 14 draft-peng-pce-te-constraints-06 16 Abstract 18 This document proposes a set of extensions for PCEP to support the TE 19 constraints during path computation, e.g, IGP instance, virtual 20 network, Slice-id, specific application, color template and FA-id 21 etc. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 12, 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 3. PCEP Extensions for TE Constraints . . . . . . . . . . . . . 3 62 3.1. Source Protocol TLV . . . . . . . . . . . . . . . . . . . 3 63 3.2. Multi-topology TLV . . . . . . . . . . . . . . . . . . . 4 64 3.3. Slice-id TLV . . . . . . . . . . . . . . . . . . . . . . 5 65 3.4. Application Specific TLV . . . . . . . . . . . . . . . . 6 66 3.5. Color TLV . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.6. FA-id TLV . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 [RFC5440] describes the Path Computation Element Protocol (PCEP) 77 which is used between a Path Computation Element (PCE) and a Path 78 Computation Client (PCC) (or other PCE) to enable computation of 79 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 80 Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model 81 [RFC8231] describes a set of extensions to PCEP to enable active 82 control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. As depicted 83 in [RFC4655], a PCE MUST be able to compute the path of a TE LSP by 84 operating on the TED and considering bandwidth and other constraints 85 applicable to the TE LSP service request. The constraint parameters 86 are provided such as metric, bandwidth, delay, affinity, etc. 87 However these parameters can't meet the network slicing requirements. 89 A PCE always perform path computation based on the network topology 90 information collected through BGP-LS [RFC7752]. BGP-LS can get 91 multiple link-state data from multiple IGP instance, or multiple 92 virtual topologies from a single IGP instance. It is necessary to 93 restrict the PCE to a small topology scope during path computation 94 for some special purpose. BGP-LS can also get application specific 95 TE attributes for a link, it is also necessary to restrict PCE to use 96 TE attributes of specific application. The PCE MUST take the 97 identifier of slicing into consideration during path computation. 99 This document proposes a set of extensions for PCEP to support the TE 100 constraints during path computation, e.g, IGP instance, virtual 101 network, Slice-id, specific application, color template and FA-id 102 etc. 104 2. Conventions used in this document 106 2.1. Terminology 108 The terminology is defined as [RFC5440] and [RFC7752]. 110 2.2. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 3. PCEP Extensions for TE Constraints 120 As defined in [RFC5440] , the LSPA object is used to specify the LSP 121 attributes to be taken into account by the PCE during path 122 computation such as TE constraints. This document proposes several 123 new TLVs for the LSPA object to carry TE constraints in Network 124 Slicing. 126 3.1. Source Protocol TLV 128 The Source Protocol TLV is optional and is defined to carry the 129 source protocol constraint. 131 In a PCReq/PCRpt message, a PCC MAY insert one or more Source 132 Protocol TLVs to indicate the source protocol that MUST be considered 133 by the PCE. If more than one Source Protocol TLVs are carried, the 134 PCE may perform path computation based on the sub-topology identified 135 by the one of the source protocols. The absence of the Source 136 Protocol TLV MUST be interpreted by the PCE as a path computation 137 request for which no constraints need be applied to any of the source 138 protocols. 140 In a PCRep/PCInit/PCUpd message, the Source Protocol TLV MAY be 141 carried so as to provide the source protocol information for the 142 computed path. 144 The format of the Source Protocol TLV is shown as Figure 1: 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type=TBD1 | Length=12 | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Protocol-ID | Reserved | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Identifier | 154 | (64 bits) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Figure 1: Source Protocol TLV 159 The code point for the TLV type is TBD1. The TLV length is 12 160 octets. 162 Protocol-ID (8 bits): defined in [RFC7752] section 3.2. 164 Reserved (24 bits): This field MUST be set to zero on transmission 165 and MUST be ignored on receipt. 167 Identifier (64 bits): defined in [RFC7752] section 3.2. 169 3.2. Multi-topology TLV 171 The Multi-topology TLV is optional and is defined to carry the multi- 172 topology protocol constraint. 174 In a PCReq message, a PCC MAY insert one Multi-topology TLV to 175 indicate the sub-topology of an IGP instance that MUST be considered 176 by the PCE. The PCE will perform path computation based on the sub- 177 topology identified by the specific Multi-Topology ID within a source 178 protocol. The absence of the Multi-topology TLV MUST be interpreted 179 by the PCE as a path computation request for which no constraints 180 need be applied to any of the multi-topologies. 182 In a PCRep/PCInit/PCUpd message, the Multi-topology TLV MAY be 183 carried so as to provide the Multi-topology information for the 184 computed path. 186 The Multi-topology TLV MUST be carried after a Source Protocol TLV, 187 if not it MUST be ignored. 189 The format of the Multi-topology TLV is shown as Figure 2: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Type=TBD2 | Length=4 | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |R R R R| Multi-Topology ID | Reserved | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2: Multi-topology TLV 201 The code point for the TLV type is TBD2. The TLV length is 4 octets. 203 Multi-Topology ID (12 bits): Semantics of the IS-IS MT-ID are defined 204 in Section 7.2 of [RFC5120]. Semantics of the OSPF MT-ID are defined 205 in Section 3.7 of [RFC4915]. If the value is derived from OSPF, then 206 the upper 9 bits MUST be set to 0. Bits R are reserved and SHOULD be 207 set to 0 when originated and ignored on receipt. 209 Reserved (16 bits): This field MUST be set to zero on transmission 210 and MUST be ignored on receipt. 212 3.3. Slice-id TLV 214 PCEP message needs to carry Slice ID to let the scope of path 215 calculation to be limited in a specific slice. 217 There are many control plane technologies to realize slicing. Some 218 control plane technologies may directly maintain resources per slice 219 granularity in the link-state database, only for the case with small 220 slice scalability. [I-D.bestbar-teas-ns-packet] proposes a more 221 scalable slicing scheme. The resource information in link-state 222 database is identified by SA-ID to distinguish the logical topologies 223 corresponding to different slice-aggregate. Within the controller, a 224 slice-aggregate includes one or more slices mapped to it. If the 225 number of slices is small, the resources per slice granularity can be 226 maintained directly in the link-state database. In this case, 227 different slice may be mapped to different slice-aggregate. If the 228 number of slices is large, it is not recommended to maintain the 229 slice granularity resources in the link-state database, but the 230 aggregated SA-ID granularity. 232 In any case, the slice service (such as VPN service) perceives the 233 Slice ID (not others), so it is natural for the service to include a 234 Slice ID constraint in its TE purpose definition. For example, VPN 235 routes may have Color attribute (refer to 236 [I-D.ietf-idr-tunnel-encaps] and 237 [I-D.ietf-spring-segment-routing-policy]). Color represents a 238 specific TE purpose, which can contain a Slice ID. Thus it is 239 natural carry Slice ID in PCEP message. 241 When the controller receives the path computation request with a 242 Slice ID constraint, it can use the resources identified by specific 243 Slice in TED, or firstly look up the Slice ID to SA-ID mapping entry 244 and then use the resources of specific SA-ID in TED, to calculate the 245 path. 247 In a PCReq message, a PCC MAY insert one Slice-id TLV to indicate the 248 slice based virtual network that MUST be considered by the PCE. The 249 PCE will perform path computation based on the intra-domain or inter- 250 domain sub-topology identified by the specific Slice-id, which is 251 independent of routing protocols such as IGP/BGP. The absence of the 252 Slice-id TLV MUST be interpreted by the PCE as a path computation 253 request for which no constraints need be applied to any of slice, 254 i.e, a default Slice-id (0) will be applied. 256 In a PCRep/PCInit/PCUpd message, the Slice-id TLV MAY be carried so 257 as to provide the network slicing information for the computed path. 258 The headend may put the Slice-id to an encapsulated data packet. 260 The format of the Slice-id TLV is shown as Figure 3: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type=TBD3 | Length=4 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Slice-id | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 3: Slice-id TLV 272 The code point for the TLV type is TBD3. The TLV length is 4 octets. 274 Slice-id (32 bits): indicate the Slice-id information. The Slice-id 275 is also termed as AII defined in [I-D.peng-lsr-network-slicing] to 276 represent an IETF Network Slice that is defined in 277 [I-D.ietf-teas-ietf-network-slice-definition]. 279 3.4. Application Specific TLV 281 The Application Specific TLV is optional and is defined to carry the 282 application specific constraints. 284 In a PCReq message, a PCC MAY insert one Application Specific TLV to 285 indicate the application that MUST be considered by the PCE. The PCE 286 will perform path computation using the specific application 287 attributes. The absence of the Application Specific TLV MUST be 288 interpreted by the PCE as a path computation request for which no 289 constraints need be applied to any of the Application Specific 290 attributes. 292 In a PCRep/PCInit/PCUpd message, the Application Specific TLV MAY be 293 inserted so as to provide the Application Specific information for 294 the computed path. 296 The format of the Application Specific TLV is shown as Figure 4: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type=TBD4 | Length=8 | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Standard Application ID | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | User Defined Application ID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 4: Application Specific TLV 310 The code point for the TLV type is TBD4. The TLV length is 8 octets. 312 Standard Application ID: Represents a bit-position value for a single 313 STANDARD application that is defined in the IANA "IGP Parameters" 314 registries under the "Link Attribute Applications" registry 315 [RFC8919]. 317 User Defined Application ID: Represents a single user defined 318 application which is a specific implementation. 320 3.5. Color TLV 322 The Color TLV is optional and is defined to carry the color 323 constraints. 325 In a PCReq message, a PCC MAY insert one Color TLV to indicate the 326 traffic engineering purpose that is recognized by both PCE and PCC 327 with no conflict meaning. The PCE will perform path computation 328 based on the color template. The same color template may be also 329 defined at PCC and the existing constraints (i.e, metric, bandwidth, 330 delay, etc) carried in the message MUST be ignored. The absence of 331 the Color TLV MUST be interpreted by the PCE as a path computation 332 request for which traditional constraints that are contained in 333 message need be applied. 335 In a PCRep/PCInit/PCUpd message, the Color TLV MAY be inserted so as 336 to provide the TE purpose information for the computed path, the PCC 337 recognize the color value that match a local color-template. For 338 example, the COLOR TLV can be used to identify the Color of each 339 Candidate Path in the Composite Candidate Path as decribed in 340 [I-D.ietf-pce-multipath] 342 The format of the Color TLV is shown as Figure 5: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type=TBD5 | Length=4 | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Color | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 5: Color TLV 354 The code point for the TLV type is TBD5. The TLV length is 4 octets. 356 Color (32 bits): indicate a TE template, 0 is invalid value. It is 357 consistent with the Color Extended Community defined in 358 [I-D.ietf-idr-tunnel-encaps], and color of SR policy defined in 359 [I-D.ietf-spring-segment-routing-policy]. 361 Note that Color TLV defined in this document is used to represent a 362 TE template, it can be suitable for any TE instance such as RSVP-TE, 363 SR-TE, SR-policy. [I-D.ietf-pce-segment-routing-policy-cp] has 364 proposed the SR policy KEY (that also includes a color information) 365 as an association group KEY to associate many candidate paths, 366 however it is only for association purpose but not constraint purpose 367 for path computation. 369 A color template can be defined to contain existing constraints such 370 as metric, bandwidth, delay, affinity parameters, and the sub- 371 topology constraints above defined in this document. 373 3.6. FA-id TLV 375 FA-id defined in [I-D.ietf-lsr-flex-algo] is a short mapping of SR 376 policy color to optimize segment stack depth for the IGP area partial 377 of the entire SR policy. The overlay service that want to be carried 378 over a particular SR-FA path must firstly let the SR policy supplier 379 know that requirement. There are two possible ways to map a color to 380 an FA-id. One is explicit mapping configuration within color 381 template, the other is dynamicly replacing a long segment list to 382 short FA segment by headend or controller once the constraints 383 contained in the color-template equal to that contained in FAD. 385 In addition to the above mapping behavior, it is also possible to 386 merge the constraints contained in the color-template and constraints 387 contained in FAD. The merging behavior can be used to compute SR-TE 388 path within a Flex-algo plane. 390 In a PCReq message, a PCC MAY insert one FA-id TLV to indicate the 391 above explicit FA-id mapping or merging. For mapping case, the PCE 392 will perform path computation based on the FA-id mapping. In 393 detailed, The PCE will check if there are connectivity within the 394 corresponding Flex-algo plane to the destination. If yes, the path 395 computation result will be represented as segment list with a single 396 prefix-SID@FA for intra-domain case, or several prefix-SID@FA for 397 inter-domain case. 399 For merging case, the PCE will perform path computation based on the 400 total constraints combinded with the ones contained in FAD identified 401 by FA-id and other ones contained in PCReq message. The later 402 constraints can get from color template or directly represent by a 403 color. In this case the computed path will be limited in the 404 specific Flex-algo plane determined by link resource Including/ 405 Excluding rules of FAD, and at the same time the path will also meet 406 other constraints for the TE purpose within the Flex-algo plane. The 407 PCE can optimize the strictly path to a loosely path when a part of 408 the strictly path is consistent with the algorithm based path, i.e, 409 some consecutive adjacency SIDs can be replaced with a single 410 algorithm based Prefix-SID. 412 In a PCRep/PCInit/PCUpd message, the FA-id TLV MAY be inserted so as 413 to provide the FA plane information for the computed path. 415 In general, the FA-id TLV is only meaningful for the domain (ingress 416 domain) that headend node belongs to. For inter-domain case, 417 operator SHOULD ensure the FA-id configuration of different domain 418 are same for an E2E slice, when he want to explicitly indicate FA-id 419 in PCEP message, otherwise the PCE has to choose different FA-id for 420 other domain as long as the contents of FAD is consistent with the 421 one of ingress domain. 423 The format of the FA-id TLV is shown as Figure 6: 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type=TBD6 | Length=4 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | FA-id | Flags |M| Reserved | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 6: FA-id TLV 435 The code point for the TLV type is TBD6. The TLV length is 4 octets. 437 FA-id (8 bits): indicate an explicit FA-id mapping information. 439 Flags (8 bits): Currently only one flag, Flag-M, is defined. 441 Flag-M: Indicate mapping behavior when unset, and merging behavior 442 when set. 444 4. Security Considerations 446 TBA 448 5. Acknowledgements 450 TBA 452 6. IANA Considerations 454 IANA is requested to make allocations from the registry, as follows: 456 +--------+----------------------------+------------------+ 457 | Type | TLV | Reference | 458 +--------+----------------------------+------------------+ 459 | TBD1 | Source Protocol TLV | [this document] | 460 | TBD2 | Multi-topology TLV | [this document] | 461 | TBD3 | Slice-id TLV | [this document] | 462 | TBD4 | Application Specific TLV | [this document] | 463 | TBD5 | Color TLV | [this document] | 464 | TBD6 | FA-id TLV | [this document] | 465 +--------+----------------------------+------------------+ 467 Table 1 469 7. Normative References 471 [I-D.bestbar-teas-ns-packet] 472 Saad, T., Beeram, V. P., Wen, B., Ceccarelli, D., Halpern, 473 J., Peng, S., Chen, R., Liu, X., and L. M. Contreras, 474 "Realizing Network Slices in IP/MPLS Networks", draft- 475 bestbar-teas-ns-packet-02 (work in progress), February 476 2021. 478 [I-D.ietf-idr-tunnel-encaps] 479 Patel, K., Velde, G. V. D., Sangli, S. R., and J. Scudder, 480 "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 481 tunnel-encaps-22 (work in progress), January 2021. 483 [I-D.ietf-lsr-flex-algo] 484 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 485 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 486 algo-15 (work in progress), April 2021. 488 [I-D.ietf-pce-multipath] 489 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 490 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 491 Signaling Multipath Information", draft-ietf-pce- 492 multipath-00 (work in progress), May 2021. 494 [I-D.ietf-pce-segment-routing-policy-cp] 495 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 496 Bidgoli, "PCEP extension to support Segment Routing Policy 497 Candidate Paths", draft-ietf-pce-segment-routing-policy- 498 cp-04 (work in progress), March 2021. 500 [I-D.ietf-spring-segment-routing-policy] 501 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 502 P. Mattes, "Segment Routing Policy Architecture", draft- 503 ietf-spring-segment-routing-policy-11 (work in progress), 504 April 2021. 506 [I-D.ietf-teas-ietf-network-slice-definition] 507 Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and 508 J. Tantsura, "Definition of IETF Network Slices", draft- 509 ietf-teas-ietf-network-slice-definition-01 (work in 510 progress), February 2021. 512 [I-D.peng-lsr-network-slicing] 513 Peng, S., Chen, R., and G. Mirsky, "Packet Network Slicing 514 using Segment Routing", draft-peng-lsr-network-slicing-00 515 (work in progress), February 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 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 523 Element (PCE)-Based Architecture", RFC 4655, 524 DOI 10.17487/RFC4655, August 2006, 525 . 527 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 528 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 529 RFC 4915, DOI 10.17487/RFC4915, June 2007, 530 . 532 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 533 Topology (MT) Routing in Intermediate System to 534 Intermediate Systems (IS-ISs)", RFC 5120, 535 DOI 10.17487/RFC5120, February 2008, 536 . 538 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 539 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 540 DOI 10.17487/RFC5440, March 2009, 541 . 543 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 544 S. Ray, "North-Bound Distribution of Link-State and 545 Traffic Engineering (TE) Information Using BGP", RFC 7752, 546 DOI 10.17487/RFC7752, March 2016, 547 . 549 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 550 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 551 May 2017, . 553 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 554 Computation Element Communication Protocol (PCEP) 555 Extensions for Stateful PCE", RFC 8231, 556 DOI 10.17487/RFC8231, September 2017, 557 . 559 [RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 560 J. Drake, "IS-IS Application-Specific Link Attributes", 561 RFC 8919, DOI 10.17487/RFC8919, October 2020, 562 . 564 Authors' Addresses 566 Shaofu Peng 567 ZTE Corporation 568 No.50 Software Avenue 569 Nanjing, Jiangsu 210012 570 China 572 Email: peng.shaofu@zte.com.cn 574 Quan Xiong 575 ZTE Corporation 576 No.6 Huashi Park Rd 577 Wuhan, Hubei 430223 578 China 580 Email: xiong.quan@zte.com.cn 582 Fengwei Qin 583 China Mobile 584 Beijing 585 China 587 Email: qinfengwei@chinamobile.com 589 Mike Koldychev 590 Cisco Systems 591 Canada 593 Email: mkoldych@cisco.com 594 Siva Sivabalan 595 Ciena Corporation 596 Canada 598 Email: ssivabal@ciena.com