idnits 2.17.1 draft-ietf-spring-resource-aware-segments-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (6 March 2022) is 779 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) == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 477, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-14 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group J. Dong 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track S. Bryant 5 Expires: 7 September 2022 Futurewei Technologies 6 T. Miyasaka 7 KDDI Corporation 8 Y. Zhu 9 China Telecom 10 F. Qin 11 Z. Li 12 China Mobile 13 F. Clad 14 Cisco Systems 15 6 March 2022 17 Introducing Resource Awareness to SR Segments 18 draft-ietf-spring-resource-aware-segments-04 20 Abstract 22 This document describes the mechanism to associate network resource 23 attributes to Segment Routing Identifiers (SIDs). Such SIDs are 24 referred to as resource-aware SIDs in this document. The resource- 25 aware SIDs retain their original forwarding semantics, but with the 26 additional semantics to identify the set of network resources 27 available for the packet processing and forwarding action. The 28 resource-aware SIDs can therefore be used to build SR paths or 29 virtual networks with a set of reserved network resources. The 30 proposed mechanism is applicable to both segment routing with MPLS 31 data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). 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 7 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 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 (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2. Segments with Resource Awareness . . . . . . . . . . . . . . 3 69 2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Control Plane Considerations . . . . . . . . . . . . . . . . 7 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 84 through an ordered list of segments. A segment is referred to by its 85 Segment Identifier (SID). With SR, explicit source routing can be 86 achieved without introducing per-path state into the network. 87 Compared with RSVP-TE [RFC3209], currently SR does not have the 88 capability of reserving network resources or identifying a set of 89 network resources reserved for an individual or a group of services 90 or customers. Although a centralized controller can have a global 91 view of network state and can provision different services using 92 different SR paths, in data packet forwarding it still relies on 93 traditional DiffServ QoS mechanism [RFC2474] [RFC2475] to provide 94 coarse-grained traffic differentiation in the network. While such 95 kind of mechanism may be sufficient for some types of services, some 96 customers or services may require to have a set of dedicated network 97 resources allocated in the network to achieve resource isolation from 98 other customers/services in the same network. Also note the number 99 of such customers or services can be larger than the number of 100 traffic classes available with DiffServ QoS. 102 Without the need of defining new SID types, this document extends the 103 SR paradigm by associating SIDs with network resource attributes. 104 These resource-aware SIDs retain their original functionality, with 105 the additional semantics of identifying the set of network resources 106 available for the packet processing action. Typical types of the 107 network resources include link bandwidth, buffers, and queues that 108 are associated with class of service, scheduling weights or time 109 cycles, and it is also possible to associate SR SIDs with other types 110 of resources (e.g., the processing and storage resources). On a 111 particular network segment, multiple resource-aware SIDs can be 112 allocated, each of which represents a subset of network resources 113 allocated in the network to meet the requirement of an individual or 114 a group of customers or services. The allocation of network 115 resources on network segments can be done either via local 116 configuration or via a centralized controller. Other approaches are 117 possible such as use of a control protocol signaling, but they are 118 out of the scope of this document. Each set of network resources can 119 be associated with one or multiple resource-aware SIDs. The 120 resource-aware SIDs can be used to build SR paths with a set of 121 reserved network resources, which can be used to carry service 122 traffic which requires dedicated network resources along the path. 123 The resource-aware SIDs can also be used to build SR based virtual 124 networks with the required network topology and resource attributes. 125 The proposed mechanism is applicable to SR with both MPLS data plane 126 (SR-MPLS) and IPv6 data plane (SRv6). 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 BCP14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 134 appear in all capitals, as shown here. 136 2. Segments with Resource Awareness 138 In segment routing architecture [RFC8402], several types of segments 139 are defined to represent either topological or service instructions. 140 A topological segment can be a node segment or an adjacency segment. 141 A service segment may be associated with specific service functions 142 for service chaining purpose. This document introduces additional 143 resource semantics to these existing types of SIDs, so that the 144 resource-aware SIDs can be used to identify not only the topology or 145 service functions, but also the set of network resources allocated on 146 the network segments for packet processing. 148 This section describes the mechanisms of using SR SIDs to identify 149 the additional resource information associated with the SR paths or 150 virtual networks based on the two SR data plane instantiations: SR- 151 MPLS and SRv6. The mechanisms to identify the forwarding path or 152 network topology with SIDs as defined in [RFC8402] can be reused, and 153 the control plane can be based on [RFC4915], [RFC5120] and 154 [I-D.ietf-lsr-flex-algo]. 156 2.1. SR-MPLS 158 As specified in [RFC8402], an IGP Adjacency Segment (Adj-SID) is an 159 SR segment attached to a unidirectional adjacency or a set of 160 unidirectional adjacencies. An IGP Prefix Segment (Prefix-SID) is an 161 SR segment attached to an IGP prefix, which identifies an instruction 162 to forward the packet along the path computed using the routing 163 algorithm in the associated topology. An IGP node segment is an IGP- 164 Prefix segment that identifies a specific router (e.g., a loopback). 165 As described in [RFC9086] and [RFC9087], BGP PeerAdj SID is used as 166 an instruction to steer over a local interface towards a specific 167 peer node in a peering Autonomous System (AS). These types of SIDs 168 can be extended to represent both the topological instructions and 169 the set of network resources allocated for packet processing 170 following the instruction. The MPLS instantiation of Segment Routing 171 is specified in [RFC8660]. 173 A resource-aware Adj-SID represents a subset of the resources (e.g. 174 bandwidth, buffer and queuing resources) of a given link, thus each 175 resource-aware Adj-SID is associated with its own set of TE 176 attributes. 178 For one IGP link, multiple resource-aware Adj-SIDs SHOULD be 179 allocated, each of which is associated with a subset of the link 180 resources allocated on the link. For one inter-domain link, multiple 181 BGP PeerAdj SIDs MAY be allocated, each of which is associated with a 182 subset of the link resources allocated on the inter-domain link. The 183 resource-aware Adj-SIDs MAY be associated with a specific network 184 topology and/or algorithm, so that it is used only for resource-aware 185 SR paths computed within the topology and/or algorithm. 187 Note this per-segment resource allocation complies to the SR 188 paradigm, which avoids introducing per-path state into the network. 189 Several approaches can be used to partition and reserve the link 190 resources, such as [FLEXE], Layer-2 logical sub-interfaces, dedicated 191 queues, etc. The detailed mechanism of link resource partitioning is 192 out of scope of this document. 194 A resource-aware Prefix-SID is associated with a network topology 195 and/or algorithm in which the attached node participates, and in 196 addition, a resource-aware prefix-SID is associated with a set of 197 network resources (e.g. bandwidth, buffer and queuing resources) 198 allocated on each node and link participating in the same topology 199 and/or algorithm. Such set of network resources can be used for 200 forwarding packets which are encapsulated with this resource-aware 201 prefix-SID along the paths computed in the associated topology and/or 202 algorithm. 204 Although it is possible that each resource-aware prefix-SID is 205 associated with a set of dedicated resources in the network, this 206 implies the overhead with per-prefix resource reservation in both 207 control plane signaling and data plane states, and if network 208 resources are allocated for one prefix on all the possible paths, it 209 is likely some resources will be wasted. A practical approach is 210 that a common set of network resources are allocated by each network 211 node and link participating in a topology and/or algorithm, and are 212 associated with a group of resource-aware prefix-SIDs of the same 213 topology and/or algorithm. Such common set of network resources 214 constitutes a network resource group. For a given tuple, there can be one or multiple network resource 216 groups, the resource-aware prefix-SIDs which are associated with the 217 same tuple shares the path computation result. 219 This helps to reduce the dynamics in per-prefix resource allocation 220 and adjustment, so that the network resource can be allocated based 221 on planning and does not have to rely on dynamic signaling. While 222 when the set of nodes and links participate in a tuple changes, the set of network resources allocated on 224 specific nodes and links may need to be adjusted. This means that 225 the resources allocated to resource-aware Adj-SIDs on those links may 226 have to be adjusted and new TE attributes for the associated Adj-SIDs 227 re-advertised. 229 For one IGP prefix, multiple resource-aware prefix-SIDs SHOULD be 230 allocated. Each resource-aware prefix-SID MAY be associated with a 231 unique tuple, in this case different tuples can be used to distinguish the resource-aware 233 prefix-SIDs of the same prefix. In another case, for one IGP prefix, 234 multiple resource-aware prefix-SIDs MAY be associated with the same 235 tuple, then an additional control plane 236 distinguisher needs to be introduced to distinguish different 237 resource-aware prefix-SIDs associated with the same but different groups of network resources. 240 A group of resource-aware Adj-SID and resource-aware Prefix-SIDs can 241 be used to construct the SID lists, which are used to steer the 242 traffic to be forwarded along the explicit paths (either strict or 243 loose) and processed using the set of network resources identified by 244 the resource-aware SIDs. 246 In data packet forwarding, each resource-aware Adj-SID identifies 247 both the next-hop and the set of resources used for packet processing 248 on the outgoing interface. Each resource-aware Prefix-SID identifies 249 the path to the node which the prefix is attached to, and the common 250 set of network resources used for packet forwarding on network nodes 251 along the path. The transit nodes use the resource-aware prefix-SIDs 252 to determine the next-hop of the packet and the set of associated 253 local resources, then forward the packet to the next-hop using the 254 set of local resources. 256 When the set of network resources allocated on the egress node also 257 needs to be determined, It is RECOMMENDED that Penultimate Hop 258 Popping (PHP) [RFC3031] be disabled, or the inner service label needs 259 to be used to infer the set of resources to be used for packet 260 processing on the egress node of the SR path. 262 This mechanism requires to allocate additional prefix-SIDs or adj- 263 SIDs for network segments to identify different set of network 264 resources. As the number of resource groups increases, the number of 265 SIDs would increase accordingly, while it should be noted that there 266 is no per-path state introduced into the network. 268 2.2. SRv6 270 As specified in [RFC8986], an SRv6 Segment Identifier (SID) is a 271 128-bit value which consists of a locator (LOC) and a function 272 (FUNCT), optionally it may also contain additional arguments (ARG) 273 immediately after the FUNCT. The Locator part of the SID is routable 274 and leads to the node which instantiates that SID, which means the 275 Locator can be parsed by all nodes in the network. The FUNCT part of 276 the SID is an opaque identification of a local function bound to the 277 SID, and the ARG bits of the SID can be used to encode additional 278 information for the processing of the behavoir bound to the SID. 279 Thus the FUNCT and ARG parts can only be parsed by the node which 280 instantiates the SRv6 SID. 282 For one SRv6 node, multiple resource-aware SRv6 LOCs SHOULD be 283 allocated. A resource-aware LOC is associated with a network 284 topology and/or algorithm in which the node participates, and in 285 addition, a resource-aware LOC is associated with a set of local 286 resources (e.g. bandwidth, buffer and queueing resources) on each 287 node participating in the same topology and/or algorithm. Such set 288 of network resources are used to forward the packets with SIDs which 289 has the resource-aware LOC as its prefix, along the path computed 290 with the associated topology and/or algorithm. Similar to the 291 resource-aware prefix-SIDs in SR-MPLS, a practical approach is that a 292 common set of network resources are allocated by each network node 293 and link participating in a topology and/or algorithm, and are 294 associated with a group of resource-aware LOCs of the same topology 295 and/or algorithm. 297 For one IGP link, multiple resource-aware SRv6 End.X SIDs SHOULD be 298 allocated to identify different set of link resources. Each 299 resource-aware End.X SID SHOULD use a resource-aware LOC as its 300 prefix. SRv6 SIDs for other types of functions MAY also be assigned 301 as resource-aware SIDs, which can identify the set of network 302 resources allocated by the node for executing the behavoir. 304 A group of resource-aware SRv6 SIDs can be used to construct the SID 305 lists, which are used to steer the traffic to be forwarded along the 306 explicit paths (either strict or loose) and processed using the set 307 of network resources identified by the resource-aware SIDs and 308 Locators. 310 In data packet forwarding, each resource-aware End.X SID identifies 311 both the next-hop and the set of resources used for packet processing 312 on the outgoing interface. Each resource-aware Locator identifies 313 the path to the node which the Locator is assigned to, and the set of 314 network resources used for packet forwarding on network nodes along 315 the path. The transit nodes use the resource-aware Locators to 316 determine the next-hop of the packet and the set of associated local 317 resources, then forward the packet to the next-hop using the set of 318 local resources. 320 This mechanism requires to allocate additional SRv6 Locators and SIDs 321 for network segments to identify different set of network resources. 322 As the number of resource groups increases, the number of SRv6 323 Locators and SIDs would increase accordingly, while it should be 324 noted that there is no per-path state introduced into the network. 326 3. Control Plane Considerations 328 The mechanism described in this document makes use of a centralized 329 controller to collect the information about the network 330 (configuration, state, routing databases, etc.) as well as the 331 service information (traffic matrix, performance statistics, etc.) 332 for the planning of network resources based on the service 333 requirement. Then the centralized controller instructs the network 334 nodes to allocate the network resources and associate the resources 335 with the resource-aware SIDs. The resource-aware SIDs can be either 336 explicitly provisioned by the controller, or dynamically allocated by 337 network nodes then reported to the controller. The controller is 338 also responsible for the centralized computation and optimization of 339 the SR paths taking the topology, algorithm and network resource 340 constraints into consideration. The interaction between the 341 controller and the network nodes can be based on Netconf/YANG 342 [RFC6241] [RFC7950], BGP-LS [RFC7752], BGP SR Policy 343 [I-D.ietf-idr-segment-routing-te-policy] or PCEP [RFC5440]. In some 344 scenarios, extensions to some of these protocols are needed, which 345 are out of the scope of this document. In some cases, a centralized 346 controller may not be used, but this would complicate the operations 347 and planning therefore not suggested. 349 The distributed control plane is complementary to the centralized 350 controller. A distributed control plane can be used for the 351 collection and distribution of the network topology and resource 352 information associated with the resource-aware SIDs among network 353 nodes, then some of the nodes can distribute the collected 354 information to the centralized controller. Distributed route 355 computation for services with topology and/or resource constraints 356 may also be needed on network nodes. The distributed control plane 357 may be based on [RFC4915], [RFC5120], [I-D.ietf-lsr-flex-algo] with 358 necessary extensions. 360 On network nodes, the support for a resource group and the 361 information to associate packets with that resource group needs to be 362 advertised in the control plane, so that all the nodes have a 363 consistent view of the resource group. Given that resource 364 management is a central function, the knowledge of the exact 365 resources provided to a resource group needs to be known accurately 366 by the relevant central control components (e.g. PCE) and the 367 network nodes. This may be done by configuration, alternative 368 protocols, or by advertisements in the IGP for collection by BGP-LS. 369 If there are related link advertisements, then consistency must be 370 assured across that set of advertisements. To advertise its support 371 for a given resource group, a node needs to advertise the identifier 372 of the resource group, the associated topology and algorithm, the 373 resource-aware SIDs and potentially a set of TE attributes 374 representing the common resources allocated to it. The details are 375 out of the scope of this document and are described in other 376 documents. 378 4. IANA Considerations 380 This document makes no request of IANA. 382 Note to RFC Editor: this section may be removed on publication as an 383 RFC. 385 5. Security Considerations 387 The security considerations of segment routing are applicable to this 388 document. 390 The resource-aware SIDs may be used for provisioning of SR paths or 391 virtual networks to carry traffic with latency as one of the SLA 392 parameters. By disrupting the latency of such traffic an attack can 393 be directly targeted at the customer application, or can be targeted 394 at the network operator by causing them to violate their SLA, 395 triggering commercial consequences. Dynamic attacks of this sort are 396 not something that networks have traditionally guarded against, and 397 networking techniques need to be developed to defend against this 398 type of attack. By rigorously policing ingress traffic and carefully 399 provisioning the resources provided to such services, this type of 400 attack can be prevented. However care needs to be taken when 401 providing shared resources, and when the network needs to be 402 reconfigured as part of ongoing maintenance or in response to a 403 failure. 405 The details of the underlay network MUST NOT be exposed to third 406 parties, to prevent attacks aimed at exploiting shared network 407 resources. 409 6. Contributors 411 Zhenbin Li 412 Email: lizhenbin@huawei.com 414 Zhibo Hu 415 Email: huzhibo@huawei.com 417 Joel Halpern 418 Email: jmh@joelhalpern.com 420 7. Acknowledgements 422 The authors would like to thank Mach Chen, Stefano Previdi, Charlie 423 Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein and John 424 Drake for the valuable discussion and suggestions to this document. 426 8. References 428 8.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, 432 DOI 10.17487/RFC2119, March 1997, 433 . 435 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 436 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 437 May 2017, . 439 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 440 Decraene, B., Litkowski, S., and R. Shakir, "Segment 441 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 442 July 2018, . 444 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 445 Decraene, B., Litkowski, S., and R. Shakir, "Segment 446 Routing with the MPLS Data Plane", RFC 8660, 447 DOI 10.17487/RFC8660, December 2019, 448 . 450 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 451 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 452 (SRv6) Network Programming", RFC 8986, 453 DOI 10.17487/RFC8986, February 2021, 454 . 456 8.2. Informative References 458 [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, 459 . 462 [I-D.ietf-idr-segment-routing-te-policy] 463 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 464 Jain, D., and S. Lin, "Advertising Segment Routing 465 Policies in BGP", Work in Progress, Internet-Draft, draft- 466 ietf-idr-segment-routing-te-policy-14, 10 November 2021, 467 . 470 [I-D.ietf-lsr-flex-algo] 471 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 472 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 473 Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 474 2021, . 477 [I-D.ietf-spring-segment-routing-policy] 478 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 479 P. Mattes, "Segment Routing Policy Architecture", Work in 480 Progress, Internet-Draft, draft-ietf-spring-segment- 481 routing-policy-18, 17 February 2022, 482 . 485 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 486 "Definition of the Differentiated Services Field (DS 487 Field) in the IPv4 and IPv6 Headers", RFC 2474, 488 DOI 10.17487/RFC2474, December 1998, 489 . 491 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 492 and W. Weiss, "An Architecture for Differentiated 493 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 494 . 496 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 497 Label Switching Architecture", RFC 3031, 498 DOI 10.17487/RFC3031, January 2001, 499 . 501 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 502 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 503 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 504 . 506 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 507 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 508 RFC 4915, DOI 10.17487/RFC4915, June 2007, 509 . 511 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 512 Topology (MT) Routing in Intermediate System to 513 Intermediate Systems (IS-ISs)", RFC 5120, 514 DOI 10.17487/RFC5120, February 2008, 515 . 517 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 518 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 519 DOI 10.17487/RFC5440, March 2009, 520 . 522 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 523 and A. Bierman, Ed., "Network Configuration Protocol 524 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 525 . 527 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 528 S. Ray, "North-Bound Distribution of Link-State and 529 Traffic Engineering (TE) Information Using BGP", RFC 7752, 530 DOI 10.17487/RFC7752, March 2016, 531 . 533 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 534 RFC 7950, DOI 10.17487/RFC7950, August 2016, 535 . 537 [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., 538 Ray, S., and J. Dong, "Border Gateway Protocol - Link 539 State (BGP-LS) Extensions for Segment Routing BGP Egress 540 Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 541 2021, . 543 [RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E., 544 and D. Afanasiev, "Segment Routing Centralized BGP Egress 545 Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August 546 2021, . 548 Authors' Addresses 550 Jie Dong 551 Huawei Technologies 552 Email: jie.dong@huawei.com 554 Stewart Bryant 555 Futurewei Technologies 556 Email: stewart.bryant@gmail.com 558 Takuya Miyasaka 559 KDDI Corporation 560 Email: ta-miyasaka@kddi.com 562 Yongqing Zhu 563 China Telecom 564 Email: zhuyq8@chinatelecom.cn 565 Fengwei Qin 566 China Mobile 567 Email: qinfengwei@chinamobile.com 569 Zhenqiang Li 570 China Mobile 571 Email: li_zhenqiang@hotmail.com 573 Francois Clad 574 Cisco Systems 575 Email: fclad@cisco.com