idnits 2.17.1 draft-ietf-spring-resource-aware-segments-01.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 (January 18, 2021) is 1193 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: 'RFC8174' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC5439' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC6790' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC7471' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC7810' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC8571' is defined on line 523, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 3 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: July 22, 2021 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 January 18, 2021 17 Introducing Resource Awareness to SR Segments 18 draft-ietf-spring-resource-aware-segments-01 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 action. The resource-aware SIDs 28 can therefore be used to build SR paths or virtual networks with a 29 set of reserved network resources. The proposed mechanism is 30 applicable to both segment routing with MPLS data plane (SR-MPLS) and 31 segment routing with IPv6 data plane (SRv6). 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on July 22, 2021. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Segments with Resource Awareness . . . . . . . . . . . . . . 3 75 2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Control Plane Considerations . . . . . . . . . . . . . . . . 7 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 8.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 90 through an ordered list of segments. A segment is referred to by its 91 Segment Identifier (SID). With SR, explicit source routing can be 92 achieved without introducing per-path state into the network. 93 Compared with RSVP-TE [RFC3209], currently SR does not have the 94 capability of reserving network resources or identifying a set of 95 network resources reserved for individual services or customers. 96 Although a centralized controller can have a global view of network 97 state and can provision different services using different SR paths, 98 in data packet forwarding it still relies on traditional DiffServ QoS 99 mechanism [RFC2474] [RFC2475] to provide coarse-grained traffic 100 differentiation in the network. While such kind of mechanism may be 101 sufficient for some types of services, some customers or services may 102 require a set of dedicated network resources to be allocated in the 103 network to achieve resource isolation from other customers/services 104 in the same network. Also note the number of such customers or 105 services can be larger than the number of traffic classes available 106 with DiffServ QoS. 108 This document extends the SR paradigm without the need of defining 109 new SID types by associating SIDs with network resource attributes. 110 These resource-aware SIDs retain their original functionality, with 111 the additional semantics of identifying the set of network resources 112 available for the packet processing action. One typical type of the 113 network resource is bandwidth, but it is also possible to associate 114 SR SIDs with other types of resources (e.g., processing or storage 115 resources). On a particular network segment, multiple resource-aware 116 SIDs can be allocated, each of which represents a subset of network 117 resources allocated in the network to meet the requirement of 118 individual customers or services. The allocation of network 119 resources on network segments can be done either via local 120 configuration or via a centralized controller. Other approaches are 121 possible such as use of a control protocol signaling, but they are 122 for further study. Each set of network resources can be associated 123 with one or multiple resource-aware SIDs. These resource-aware SIDs 124 can be used to build SR paths with a set of reserved network 125 resources, which can be used to carry service traffic which requires 126 dedicated network resources. The resource-aware SIDs can also be 127 used to build SR based virtual networks with the required network 128 topology and resource attributes. The proposed mechanism is 129 applicable to SR with both MPLS data plane (SR-MPLS) and IPv6 data 130 plane (SRv6). 132 2. Segments with Resource Awareness 134 In segment routing architecture [RFC8402], several types of segments 135 are defined to represent either topological or service instructions. 136 A topological segment can be a node segment or an adjacency segment. 137 A service segment may be associated with specific service functions 138 for service chaining purpose. This document introduces additional 139 resource semantics to these existing types of SIDs, so that the SIDs 140 can be used to identify the topology or service functions, and also 141 the set of network resources allocated on the network segments for 142 packet processing. 144 This section describes the mechanisms of using SR SIDs to identify 145 the additional resource information associated with SR paths or 146 virtual networks based on the two SR data plane instantiations: SR- 147 MPLS and SRv6. The mechanisms to identify the forwarding path or 148 network topology with SIDs as defined in [RFC8402] can be reused, and 149 the control plane can be based on [RFC4915], [RFC5120] and 150 [I-D.ietf-lsr-flex-algo]. 152 2.1. SR-MPLS 154 As specified in [RFC8402], an IGP Adjacency Segment (Adj-SID) is an 155 SR segment attached to a unidirectional adjacency or a set of 156 unidirectional adjacencies. An IGP Prefix Segment (Prefix-SID) is an 157 SR segment attached to an IGP prefix, which identifies an instruction 158 to forward the packet along the path computed using the routing 159 algorithm in the associated topology. An IGP node segment is an IGP- 160 Prefix segment that identifies a specific router (e.g., a loopback). 161 As described in [I-D.ietf-spring-segment-routing-central-epe] and 162 [I-D.ietf-idr-bgpls-segment-routing-epe], BGP PeerAdj SID is used as 163 an instruction to steer over a local interface towards a specific 164 peer node in a peering Autonomous System (AS). These types of SIDs 165 can be extended to represent both topological instructions and the 166 set of network resources allocated for packet processing following 167 the instruction. The MPLS instantiation of Segment Routing is 168 specified in [RFC8660]. 170 For one IGP link, multiple resource-aware Adj-SIDs SHOULD be 171 allocated, each of which is associated with a subset of the link 172 resources allocated on the link, e.g. the link bandwidth. For one 173 inter-domain link, multiple BGP PeerAdj SIDs SHOULD be allocated, 174 each of which is associated with a subset of the link resources 175 allocated on the inter-domain link. The resource-aware Adj-SIDs MAY 176 be associated with a specific network topology and/or algorithm, so 177 that it is used only for resource-aware SR paths computed within the 178 topology and/or algorithm. Note that this per-segment resource 179 allocation complies to the SR paradigm, which avoids introducing per- 180 path state into the network. Several approaches can be used to 181 partition the link resource, such as [FLEXE], Layer-2 logical sub- 182 interfaces, dedicated queues, etc. The detailed mechanism of link 183 resource partitioning is out of scope of this document. 185 For one IGP prefix, multiple resource-aware prefix-SIDs SHOULD be 186 allocated. A resource-aware prefix SID is associated with a network 187 topology and/or algorithm in which the attached node participates, 188 and in addition, each resource-aware prefix-SID is associated with a 189 set of local resources (e.g. bandwidth, processing and storage 190 resources) on each node participating in the same topology and/or 191 algorithm. Such set of network resources are used for forwarding the 192 packets with this resource-aware prefix-SID, along the path computed 193 with the associated topology and/or algorithm. 195 Although each resource-aware prefix-SID can be associated with a set 196 of dedicated resources, this implies additional overhead with per- 197 prefix resource reservation in both control plane signaling and data 198 plane states, and it is likely some resources will be wasted with 199 per-prefix resource allocation along all the possible paths. Thus it 200 is RECOMMENDED that a group of resource-aware prefix-SIDs be 201 associated with an aggregated set of network resources in the 202 network. This helps to reduce the dynamics in resource allocation, 203 so that the resource can be allocated based on network planning and 204 does not have to rely on dynamic signaling. 206 For one IGP prefix, each resource-aware prefix-SID can be associated 207 with a unique tuple, in this case different 208 tuples can be used to distinguish the resource- 209 aware prefix-SIDs for the same prefix. In another case, for one IGP 210 prefix, multiple resource-aware prefix-SIDs can be associated with 211 the same tuple, then an additional 212 distinguisher needs to be introduced to distinguish different 213 resource-aware prefix-SIDs associated with the same topology and 214 algorithm but different groups of network resources. More details 215 about the new distinguisher will be described in a future version. 217 A group of resource-aware SR-MPLS SIDs can be used to construct SID 218 lists to steer the traffic along the explicit paths (either strict or 219 loose) and be processed using the set of network resources identified 220 by the SIDs. 222 In data packet forwarding, each resource-aware Adj-SID identifies 223 both the next-hop and the set of resources used for packet processing 224 on the outgoing interface. Each resource-aware Prefix-SID identifies 225 a path to the node which the prefix is attached to, and the set of 226 network resources used for packet forwarding on network nodes along 227 the path. The transit nodes determine the next-hop of the packet and 228 the set of associated local resources based on the resource-aware 229 prefix-SID, then forward the packet to the next-hop using the set of 230 local resources. 232 When the set of network resources allocated on the egress node also 233 needs to be determined, It is RECOMMENDED that Penultimate Hop 234 Popping (PHP) [RFC3031] be disabled, or the inner service label is 235 used to infer the set of resources to be used for packet processing 236 on the egress node of the SR path. 238 This mechanism requires to allocate additional prefix-SIDs or adj- 239 SIDs for network segments to identify different set of network 240 resources. As the number of resource groups increases, the number of 241 SIDs would increase accordingly, while it should be noted that there 242 is no per-path state introduced into the network. 244 2.2. SRv6 246 As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6 247 Segment Identifier (SID) is a 128-bit value which consists of a 248 locator (LOC) and a function (FUNCT), optionally it may also contain 249 additional arguments (ARG) immediately after the FUNCT. The Locator 250 part of the SID is routable and leads to the node which instantiates 251 that SID, which means the Locator can be parsed by all nodes in the 252 network. The FUNCT part of the SID is an opaque identification of a 253 local function bound to the SID, and the ARG bits of the SID can be 254 used to encode additional information for the processing of the 255 behavoir bound to the SID. The FUNCT and ARG parts can only be 256 parsed by the node which instantiates the SRv6 SID. 258 For one SRv6 node, multiple resource-aware SRv6 LOCs SHOULD be 259 allocated. A resource-aware LOC is associated with a network 260 topology and/or algorithm in which the node participates, and in 261 addition, a resource-aware LOC is associated with a set of local 262 resources (e.g. bandwidth, processing and storage resources) on each 263 node participating in the same topology and/or algorithm. Such set 264 of network resources are used to forward the packets with SIDs which 265 has the resource-aware LOC as its prefix, along the path computed 266 with the associated topology and/or algorithm. Similar to the 267 resource-aware prefix-SIDs in SR-MPLS, the network resources used for 268 the forwarding instruction of a group of LOCs can be aggregated, this 269 helps to reduce the dynamics of resource allocation, so that the 270 resource can be allocated based on network planning and does not have 271 to rely on dynamic signaling. 273 For one IGP link, the resource-aware SRv6 End.X SIDs are used to 274 identify different set of link resources allocated. Each resource- 275 aware End.X SID SHOULD use a resource-aware LOC as its prefix. SRv6 276 SIDs for other types of functions MAY also be assigned as resource- 277 aware SIDs, which can identify the set of network resources allocated 278 by the node for executing the function. 280 A group of resource-aware SRv6 SIDs can be used to construct SID 281 lists to steer the traffic along the explicit paths (either strict or 282 loose) and be processed using the set of network resources identified 283 by the SRv6 SIDs and Locators. 285 In data packet forwarding, each resource-aware End.X SID identifies 286 both the next-hop and the set of resources used for packet processing 287 on the outgoing interface. Each resource-aware Locator identifies 288 the path to the node which the LOC is assigned to, and the set of 289 network resources used for packet forwarding on network nodes along 290 the path. The transit nodes determine the next-hop of the packet and 291 the set of associated local resources based on the resource-aware 292 Locator, then forward the packet to the next-hop using the set of 293 local resources. 295 This mechanism requires to allocate additional SRv6 Locators and SIDs 296 for network segments to identify different set of network resources. 297 As the number of resource groups increases, the number of SRv6 298 Locators and SIDs would increase accordingly, while it should be 299 noted that there is no per-path state introduced into the network. 301 3. Control Plane Considerations 303 The mechanism described in this document makes use of a centralized 304 controller to collect the information about the network 305 (configuration, state, routing databases, etc.) as well as the 306 service information (traffic matrix, performance statistics, etc.) 307 for the planning of network resources based on service requirement. 308 Then the centralized controller instructs network nodes to allocate 309 the network resources and associate the resources with resource-aware 310 SIDs. The resource-aware SIDs can be either explicitly provisioned 311 by the controller, or dynamically allocated by network nodes then 312 reported to the controller. The controller is also responsible for 313 the centralized computation and optimization of the SR paths with the 314 topology, algorithm and network resource constraints. The 315 interaction between the controller and the network nodes can be based 316 on PCEP [RFC5440], Netconf/YANG [RFC6241] [RFC7950] and BGP-LS 317 [RFC7752]. In some scenarios, extensions to some of these protocols 318 is needed, which are out of the scope of this document and will be 319 specified in separate documents. In some cases, a centralized 320 controller may not be used, but this would complicate the operations 321 and planning therefore not suggested. 323 The distributed control plane is complementary to the centralized 324 controller. A distributed control plane can be used for the 325 collection and distribution of the network topology and resource 326 information associated with SIDs among network nodes, then some of 327 the nodes can distribute the collected information to the centralized 328 controller. Distributed route computation for services with topology 329 and resource constraints may also be needed. The distributed control 330 plane may be based on [RFC4915], [RFC5120], [I-D.ietf-lsr-flex-algo] 331 or the combination of some of them with necessary extensions. The 332 details are out of the scope of this document. 334 4. IANA Considerations 336 This document makes no request of IANA. 338 Note to RFC Editor: this section may be removed on publication as an 339 RFC. 341 5. Security Considerations 343 The security considerations of segment routing are applicable to this 344 document. 346 The Resource-aware SIDs may be used for provisioning of SR paths or 347 virtual networks to carry traffic with latency as one of the SLA 348 parameters. By disrupting the latency of such traffic an attack can 349 be directly targeted at the customer application, or can be targeted 350 at the network operator by causing them to violate their SLA, 351 triggering commercial consequences. Dynamic attacks of this sort are 352 not something that networks have traditionally guarded against, and 353 networking techniques need to be developed to defend against this 354 type of attack. By rigorously policing ingress traffic and carefully 355 provisioning the resources provided to such services, this type of 356 attack can be prevented. However care needs to be taken when 357 providing shared resources, and when the network needs to be 358 reconfigured as part of ongoing maintenance or in response to a 359 failure. 361 The details of the underlay network MUST NOT be exposed to third 362 parties, to prevent attacks aimed at exploiting a shared resource. 364 6. Contributors 366 Zhenbin Li 367 Email: lizhenbin@huawei.com 369 Zhibo Hu 370 Email: huzhibo@huawei.com 372 7. Acknowledgements 374 The authors would like to thank Mach Chen, Stefano Previdi, Charlie 375 Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein and Joel 376 Halpern for the valuable discussion and suggestions to this document. 378 8. References 380 8.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 388 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 389 May 2017, . 391 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 392 Decraene, B., Litkowski, S., and R. Shakir, "Segment 393 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 394 July 2018, . 396 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 397 Decraene, B., Litkowski, S., and R. Shakir, "Segment 398 Routing with the MPLS Data Plane", RFC 8660, 399 DOI 10.17487/RFC8660, December 2019, 400 . 402 8.2. Informative References 404 [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, 405 . 408 [I-D.ietf-idr-bgpls-segment-routing-epe] 409 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 410 S., and J. Dong, "BGP-LS extensions for Segment Routing 411 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 412 segment-routing-epe-19 (work in progress), May 2019. 414 [I-D.ietf-lsr-flex-algo] 415 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 416 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 417 algo-13 (work in progress), October 2020. 419 [I-D.ietf-spring-segment-routing-central-epe] 420 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 421 Afanasiev, "Segment Routing Centralized BGP Egress Peer 422 Engineering", draft-ietf-spring-segment-routing-central- 423 epe-10 (work in progress), December 2017. 425 [I-D.ietf-spring-segment-routing-policy] 426 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 427 P. Mattes, "Segment Routing Policy Architecture", draft- 428 ietf-spring-segment-routing-policy-09 (work in progress), 429 November 2020. 431 [I-D.ietf-spring-srv6-network-programming] 432 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 433 Matsushima, S., and Z. Li, "SRv6 Network Programming", 434 draft-ietf-spring-srv6-network-programming-28 (work in 435 progress), December 2020. 437 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 438 "Definition of the Differentiated Services Field (DS 439 Field) in the IPv4 and IPv6 Headers", RFC 2474, 440 DOI 10.17487/RFC2474, December 1998, 441 . 443 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 444 and W. Weiss, "An Architecture for Differentiated 445 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 446 . 448 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 449 Label Switching Architecture", RFC 3031, 450 DOI 10.17487/RFC3031, January 2001, 451 . 453 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 454 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 455 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 456 . 458 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 459 (TE) Extensions to OSPF Version 2", RFC 3630, 460 DOI 10.17487/RFC3630, September 2003, 461 . 463 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 464 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 465 RFC 4915, DOI 10.17487/RFC4915, June 2007, 466 . 468 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 469 Topology (MT) Routing in Intermediate System to 470 Intermediate Systems (IS-ISs)", RFC 5120, 471 DOI 10.17487/RFC5120, February 2008, 472 . 474 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 475 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 476 2008, . 478 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 479 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 480 DOI 10.17487/RFC5439, February 2009, 481 . 483 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 484 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 485 DOI 10.17487/RFC5440, March 2009, 486 . 488 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 489 and A. Bierman, Ed., "Network Configuration Protocol 490 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 491 . 493 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 494 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 495 RFC 6790, DOI 10.17487/RFC6790, November 2012, 496 . 498 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 499 Previdi, "OSPF Traffic Engineering (TE) Metric 500 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 501 . 503 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 504 S. Ray, "North-Bound Distribution of Link-State and 505 Traffic Engineering (TE) Information Using BGP", RFC 7752, 506 DOI 10.17487/RFC7752, March 2016, 507 . 509 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 510 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 511 RFC 7810, DOI 10.17487/RFC7810, May 2016, 512 . 514 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 515 RFC 7950, DOI 10.17487/RFC7950, August 2016, 516 . 518 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 519 (IPv6) Specification", STD 86, RFC 8200, 520 DOI 10.17487/RFC8200, July 2017, 521 . 523 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 524 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 525 IGP Traffic Engineering Performance Metric Extensions", 526 RFC 8571, DOI 10.17487/RFC8571, March 2019, 527 . 529 Authors' Addresses 531 Jie Dong 532 Huawei Technologies 534 Email: jie.dong@huawei.com 536 Stewart Bryant 537 Futurewei Technologies 539 Email: stewart.bryant@gmail.com 541 Takuya Miyasaka 542 KDDI Corporation 544 Email: ta-miyasaka@kddi.com 546 Yongqing Zhu 547 China Telecom 549 Email: zhuyq8@chinatelecom.cn 551 Fengwei Qin 552 China Mobile 554 Email: qinfengwei@chinamobile.com 556 Zhenqiang Li 557 China Mobile 559 Email: li_zhenqiang@hotmail.com 561 Francois Clad 562 Cisco Systems 564 Email: fclad@cisco.com