idnits 2.17.1 draft-ietf-spring-resource-aware-segments-02.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 (February 22, 2021) is 1157 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 469, 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) Summary: 0 errors (**), 0 flaws (~~), 5 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: August 26, 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 February 22, 2021 17 Introducing Resource Awareness to SR Segments 18 draft-ietf-spring-resource-aware-segments-02 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 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 August 26, 2021. 50 Copyright Notice 52 Copyright (c) 2021 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 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 2. Segments with Resource Awareness . . . . . . . . . . . . . . 3 70 2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Control Plane Considerations . . . . . . . . . . . . . . . . 7 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 8.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 85 through an ordered list of segments. A segment is referred to by its 86 Segment Identifier (SID). With SR, explicit source routing can be 87 achieved without introducing per-path state into the network. 88 Compared with RSVP-TE [RFC3209], currently SR does not have the 89 capability of reserving network resources or identifying a set of 90 network resources reserved for individual services or customers. 91 Although a centralized controller can have a global view of network 92 state and can provision different services using different SR paths, 93 in data packet forwarding it still relies on traditional DiffServ QoS 94 mechanism [RFC2474] [RFC2475] to provide coarse-grained traffic 95 differentiation in the network. While such kind of mechanism may be 96 sufficient for some types of services, some customers or services may 97 require a set of dedicated network resources to be allocated in the 98 network to achieve resource isolation from other customers/services 99 in the same network. Also note the number of such customers or 100 services can be larger than the number of traffic classes available 101 with DiffServ QoS. 103 This document extends the SR paradigm without the need of defining 104 new SID types by associating SIDs with network resource attributes. 105 These resource-aware SIDs retain their original functionality, with 106 the additional semantics of identifying the set of network resources 107 available for the packet processing action. One typical type of the 108 network resource is the link bandwidth and the associated 109 buffer/queuing/scheduling resources, but it is also possible to 110 associate SR SIDs with other types of resources (e.g., processing or 111 storage resources). On a particular network segment, multiple 112 resource-aware SIDs can be allocated, each of which represents a 113 subset of network resources allocated in the network to meet the 114 requirement of individual customers or services. The allocation of 115 network 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 for further study. Each set of network resources can be associated 119 with one or multiple resource-aware SIDs. These resource-aware SIDs 120 can be used to build SR paths with a set of reserved network 121 resources, which can be used to carry service traffic which requires 122 dedicated network resources along the path. The resource-aware SIDs 123 can also be used to build SR based virtual networks for services with 124 the required network topology and resource attributes. The proposed 125 mechanism is applicable to SR with both MPLS data plane (SR-MPLS) and 126 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 SIDs 144 can be used to identify the topology or service functions, and also 145 the set of network resources allocated on the network segments for 146 packet processing. 148 This section describes the mechanisms of using SR SIDs to identify 149 the additional resource information associated with 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 [I-D.ietf-spring-segment-routing-central-epe] and 166 [I-D.ietf-idr-bgpls-segment-routing-epe], BGP PeerAdj SID is used as 167 an instruction to steer over a local interface towards a specific 168 peer node in a peering Autonomous System (AS). These types of SIDs 169 can be extended to represent both topological instructions and the 170 set of network resources allocated for packet processing following 171 the instruction. The MPLS instantiation of Segment Routing is 172 specified in [RFC8660]. 174 A resource-aware Adj-SID represents a subset of the resources (e.g. 175 bandwidth and the associated buffer/queuing/scheduling resources) of 176 a given link, thus each resource-aware Adj-SID is associated with its 177 own set of TE attributes. 179 For one IGP link, multiple resource-aware Adj-SIDs SHOULD be 180 allocated, each of which is associated with a subset of the link 181 resources allocated on the link. For one inter-domain link, multiple 182 BGP PeerAdj SIDs MAY be allocated, each of which is associated with a 183 subset of the link resources allocated on the inter-domain link. The 184 resource-aware Adj-SIDs MAY be associated with a specific network 185 topology and/or algorithm, so that it is used only for resource-aware 186 SR paths computed within the topology and/or algorithm. 188 Note this per-segment resource allocation complies to the SR 189 paradigm, which avoids introducing per-path state into the network. 190 Several approaches can be used to partition the link resource, such 191 as [FLEXE], Layer-2 logical sub-interfaces, dedicated queues, etc. 193 The detailed mechanism of link resource partitioning is out of scope 194 of this document. 196 A resource-aware Prefix-SID is associated with a network topology 197 and/or algorithm in which the attached node participates, and in 198 addition, a resource-aware prefix-SID is associated with a set of 199 network resources (e.g. bandwidth and the associated buffer/queuing/ 200 scheduling resources) allocated on each node and link participating 201 in the same topology and/or algorithm. Such set of network resources 202 can be used for forwarding packets with this resource-aware prefix- 203 SID along the paths computed in the associated topology and/or 204 algorithm. 206 Although it is possible that each resource-aware prefix-SID is 207 associated with a set of dedicated resources in the network, this 208 implies the overhead with per-prefix resource reservation in both 209 control plane signaling and data plane states, and if network 210 resources are allocated for one prefix on all the possible paths, it 211 is likely some resources will be wasted. A practical approach is 212 that a common set of network resources are allocated by each network 213 node and link participating in a topology and/or algorithm, and are 214 associated with a group of resource-aware prefix-SIDs of the same 215 topology and/or algorithm. Such a common set of network resources 216 constitutes a resource group. For a given 217 tuple, there can be one or multiple resource groups, the resource 218 groups which are associated with the same tuple 219 shares the SPF computation result. 221 This helps to reduce the dynamics in per-prefix resource allocation 222 and adjustment, so that the network resource can be allocated based 223 on planning and does not have to rely on dynamic signaling. While 224 when the set of nodes and links participate in a tuple changes, the set of network resources allocated on 226 specific nodes and links may need to be adjusted. This means that 227 the resources allocated to resource-aware Adj-SIDs on those links may 228 have to be adjusted and new TE metrics for the associated Adj-SIDs 229 re-advertised. 231 For one IGP prefix, multiple resource-aware prefix-SIDs SHOULD be 232 allocated. Each resource-aware prefix-SID can be associated with a 233 unique tuple, in this case different tuples can be used to distinguish the resource-aware 235 prefix-SIDs for the same prefix. In another case, for one IGP 236 prefix, multiple resource-aware prefix-SIDs can be associated with 237 the same tuple, then an additional 238 distinguisher needs to be introduced to distinguish different 239 resource-aware prefix-SIDs associated with the same but different groups of network resources. 242 A group of resource-aware Adj-SID and resource-aware Prefix-SIDs can 243 be used to construct the SID lists to steer the traffic along the 244 explicit paths (either strict or loose) and be processed using the 245 set of network resources identified by the SIDs. 247 In data packet forwarding, each resource-aware Adj-SID identifies 248 both the next-hop and the set of resources used for packet processing 249 on the outgoing interface. Each resource-aware Prefix-SID identifies 250 a path to the node which the prefix is attached to, and the common 251 set of network resources used for packet forwarding on network nodes 252 along the path. The transit nodes determine the next-hop of the 253 packet and the set of associated local resources based on the 254 resource-aware prefix-SID, then forward the packet to the next-hop 255 using the set of local resources. 257 When the set of network resources allocated on the egress node also 258 needs to be determined, It is RECOMMENDED that Penultimate Hop 259 Popping (PHP) [RFC3031] be disabled, or the inner service label is 260 used to infer the set of resources to be used for packet processing 261 on the egress node of the SR path. 263 This mechanism requires to allocate additional prefix-SIDs or adj- 264 SIDs for network segments to identify different set of network 265 resources. As the number of resource groups increases, the number of 266 SIDs would increase accordingly, while it should be noted that there 267 is no per-path state introduced into the network. 269 2.2. SRv6 271 As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6 272 Segment Identifier (SID) is a 128-bit value which consists of a 273 locator (LOC) and a function (FUNCT), optionally it may also contain 274 additional arguments (ARG) immediately after the FUNCT. The Locator 275 part of the SID is routable and leads to the node which instantiates 276 that SID, which means the Locator can be parsed by all nodes in the 277 network. The FUNCT part of the SID is an opaque identification of a 278 local function bound to the SID, and the ARG bits of the SID can be 279 used to encode additional information for the processing of the 280 behavoir bound to the SID. The FUNCT and ARG parts can only be 281 parsed by the node which instantiates the SRv6 SID. 283 For one SRv6 node, multiple resource-aware SRv6 LOCs SHOULD be 284 allocated. A resource-aware LOC is associated with a network 285 topology and/or algorithm in which the node participates, and in 286 addition, a resource-aware LOC is associated with a set of local 287 resources (e.g. bandwidth, processing and storage resources) on each 288 node participating in the same topology and/or algorithm. Such set 289 of network resources are used to forward the packets with SIDs which 290 has the resource-aware LOC as its prefix, along the path computed 291 with the associated topology and/or algorithm. Similar to the 292 resource-aware prefix-SIDs in SR-MPLS, a practical approach is that a 293 common set of network resources are allocated by each network node 294 and link participating in a topology and/or algorithm, and are 295 associated with a group of resource-aware LOC of the same topology 296 and/or algorithm. 298 For one IGP link, the resource-aware SRv6 End.X SIDs are used to 299 identify different set of link resources allocated. Each resource- 300 aware End.X SID SHOULD use a resource-aware LOC as its prefix. SRv6 301 SIDs for other types of functions MAY also be assigned as resource- 302 aware SIDs, which can identify the set of network resources allocated 303 by the node for executing the function. 305 A group of resource-aware SRv6 SIDs can be used to construct the SID 306 lists to steer the traffic along the explicit paths (either strict or 307 loose) and be processed using the set of network resources identified 308 by the SRv6 SIDs and 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 determine the next-hop of the packet and 316 the set of associated local resources based on the resource-aware 317 Locator, 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 service requirement. 333 Then the centralized controller instructs the network nodes to 334 allocate the network resources and associate the resources with the 335 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 with the topology, algorithm and network resource 340 constraints. The interaction between the controller and the network 341 nodes can be based on PCEP [RFC5440], Netconf/YANG [RFC6241] 342 [RFC7950] and BGP-LS [RFC7752]. In some scenarios, extensions to 343 some of these protocols is needed, which are out of the scope of this 344 document and will be specified in separate documents. In some cases, 345 a centralized controller may not be used, but this would complicate 346 the operations and planning therefore not suggested. 348 The distributed control plane is complementary to the centralized 349 controller. A distributed control plane can be used for the 350 collection and distribution of the network topology and resource 351 information associated with SIDs among network nodes, then some of 352 the nodes can distribute the collected information to the centralized 353 controller. Distributed route computation for services with topology 354 and/or resource constraints may also be needed on network nodes. The 355 distributed control plane may be based on [RFC4915], [RFC5120], 356 [I-D.ietf-lsr-flex-algo] or the combination of some of them with 357 necessary extensions. 359 On network nodes, the support for a resource group and the 360 information to associate packets with that resource group needs to be 361 advertised in the control plane, so that all nodes have a consistent 362 view of the resource group. Given that resource management is a 363 central function, the knowledge of the exact resources provided to a 364 resource group needs to be known accurately by the relevant central 365 control components (e.g. PCE) and the network nodes. This may be 366 done by configuration, alternative protocols, or by advertisements in 367 the IGP for collection by BGP-LS. If there are related link 368 advertisements, then consistency must be assured across that set of 369 advertisements. To advertise its support for a given resource group, 370 a node would advertise the identifier of the resource group, the 371 associated topology and algorithm, and potentially a set of TE 372 metrics representing the common resources allocated to it. The 373 details will be described in a separate document. 375 4. IANA Considerations 377 This document makes no request of IANA. 379 Note to RFC Editor: this section may be removed on publication as an 380 RFC. 382 5. Security Considerations 384 The security considerations of segment routing are applicable to this 385 document. 387 The Resource-aware SIDs may be used for provisioning of SR paths or 388 virtual networks to carry traffic with latency as one of the SLA 389 parameters. By disrupting the latency of such traffic an attack can 390 be directly targeted at the customer application, or can be targeted 391 at the network operator by causing them to violate their SLA, 392 triggering commercial consequences. Dynamic attacks of this sort are 393 not something that networks have traditionally guarded against, and 394 networking techniques need to be developed to defend against this 395 type of attack. By rigorously policing ingress traffic and carefully 396 provisioning the resources provided to such services, this type of 397 attack can be prevented. However care needs to be taken when 398 providing shared resources, and when the network needs to be 399 reconfigured as part of ongoing maintenance or in response to a 400 failure. 402 The details of the underlay network MUST NOT be exposed to third 403 parties, to prevent attacks aimed at exploiting a shared resource. 405 6. Contributors 407 Zhenbin Li 408 Email: lizhenbin@huawei.com 410 Zhibo Hu 411 Email: huzhibo@huawei.com 413 Joel Halpern 414 Email: jmh@joelhalpern.com 416 7. Acknowledgements 418 The authors would like to thank Mach Chen, Stefano Previdi, Charlie 419 Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein and John 420 Drake for the valuable discussion and suggestions to this document. 422 8. References 424 8.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 432 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 433 May 2017, . 435 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 436 Decraene, B., Litkowski, S., and R. Shakir, "Segment 437 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 438 July 2018, . 440 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 441 Decraene, B., Litkowski, S., and R. Shakir, "Segment 442 Routing with the MPLS Data Plane", RFC 8660, 443 DOI 10.17487/RFC8660, December 2019, 444 . 446 8.2. Informative References 448 [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, 449 . 452 [I-D.ietf-idr-bgpls-segment-routing-epe] 453 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 454 S., and J. Dong, "BGP-LS extensions for Segment Routing 455 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 456 segment-routing-epe-19 (work in progress), May 2019. 458 [I-D.ietf-lsr-flex-algo] 459 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 460 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 461 algo-13 (work in progress), October 2020. 463 [I-D.ietf-spring-segment-routing-central-epe] 464 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 465 Afanasiev, "Segment Routing Centralized BGP Egress Peer 466 Engineering", draft-ietf-spring-segment-routing-central- 467 epe-10 (work in progress), December 2017. 469 [I-D.ietf-spring-segment-routing-policy] 470 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 471 P. Mattes, "Segment Routing Policy Architecture", draft- 472 ietf-spring-segment-routing-policy-09 (work in progress), 473 November 2020. 475 [I-D.ietf-spring-srv6-network-programming] 476 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 477 Matsushima, S., and Z. Li, "SRv6 Network Programming", 478 draft-ietf-spring-srv6-network-programming-28 (work in 479 progress), December 2020. 481 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 482 "Definition of the Differentiated Services Field (DS 483 Field) in the IPv4 and IPv6 Headers", RFC 2474, 484 DOI 10.17487/RFC2474, December 1998, 485 . 487 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 488 and W. Weiss, "An Architecture for Differentiated 489 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 490 . 492 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 493 Label Switching Architecture", RFC 3031, 494 DOI 10.17487/RFC3031, January 2001, 495 . 497 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 498 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 499 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 500 . 502 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 503 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 504 RFC 4915, DOI 10.17487/RFC4915, June 2007, 505 . 507 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 508 Topology (MT) Routing in Intermediate System to 509 Intermediate Systems (IS-ISs)", RFC 5120, 510 DOI 10.17487/RFC5120, February 2008, 511 . 513 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 514 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 515 DOI 10.17487/RFC5440, March 2009, 516 . 518 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 519 and A. Bierman, Ed., "Network Configuration Protocol 520 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 521 . 523 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 524 S. Ray, "North-Bound Distribution of Link-State and 525 Traffic Engineering (TE) Information Using BGP", RFC 7752, 526 DOI 10.17487/RFC7752, March 2016, 527 . 529 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 530 RFC 7950, DOI 10.17487/RFC7950, August 2016, 531 . 533 Authors' Addresses 535 Jie Dong 536 Huawei Technologies 538 Email: jie.dong@huawei.com 540 Stewart Bryant 541 Futurewei Technologies 543 Email: stewart.bryant@gmail.com 545 Takuya Miyasaka 546 KDDI Corporation 548 Email: ta-miyasaka@kddi.com 550 Yongqing Zhu 551 China Telecom 553 Email: zhuyq8@chinatelecom.cn 555 Fengwei Qin 556 China Mobile 558 Email: qinfengwei@chinamobile.com 560 Zhenqiang Li 561 China Mobile 563 Email: li_zhenqiang@hotmail.com 564 Francois Clad 565 Cisco Systems 567 Email: fclad@cisco.com