idnits 2.17.1 draft-ietf-spring-resource-aware-segments-00.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 30, 2020) is 1366 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 331, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC5439' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'RFC6790' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC7471' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'RFC7810' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC8571' is defined on line 467, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 -- 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 (~~), 14 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: January 31, 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 July 30, 2020 17 Introducing Resource Awareness to SR Segments 18 draft-ietf-spring-resource-aware-segments-00 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 January 31, 2021. 56 Copyright Notice 58 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Control Plane Considerations . . . . . . . . . . . . . . . . 6 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 80 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 84 8.2. Informative References . . . . . . . . . . . . . . . . . 8 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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. On a particular network 113 segment, multiple resource-aware SIDs can be allocated, each of which 114 represents a subset of network resources allocated to meet the 115 requirement of individual customers or services. The allocation of 116 network resources on a network segment can be done via a controller 117 or via local configuration, then each set of resource is associated 118 with a resource-aware SID. These resource-aware SIDs can be used to 119 build SR paths with a set of reserved network resources, which can be 120 used in network scenarios which require to allocate a set of network 121 resources for the processing of groups of service traffic. The 122 resource-aware SIDs can also be used to build SR based virtual 123 networks with the required network topology and resource attributes. 124 The proposed mechanism is applicable to SR with both MPLS data plane 125 (SR-MPLS) and IPv6 data plane (SRv6). 127 2. Segments with Resource Awareness 129 In segment routing architecture [RFC8402], several types of segments 130 are defined to represent either topological or service instructions. 131 A topological segment can be a node segment or an adjacency segment. 132 A service segment may be associated with specific service functions 133 for service chaining purposes. This document introduces additional 134 resource semantics to these existing types of SIDs, so that the SIDs 135 can be used to identify the topology or service functions, and the 136 set of network resources allocated on the network segments for packet 137 processing. 139 This section describes the mechanisms of using SR SIDs to identify 140 the additional resource information of SR paths or virtual networks 141 with the two SR data plane instantiations: SR-MPLS and SRv6. The 142 mechanisms to identify the forwarding path or network topology with a 143 SID as defined in [RFC8402] are unchanged, and the control plane can 144 be based on [RFC4915], [RFC5120] and [I-D.ietf-lsr-flex-algo]. 146 2.1. SR-MPLS 148 As specified in [RFC8402], an IGP Adjacency Segment (Adj-SID) is an 149 IGP-segment attached to a unidirectional adjacency or a set of 150 unidirectional adjacencies. An IGP Prefix segment is an IGP segment 151 representing an IGP prefix, and IGP node segment is an IGP-Prefix 152 segment that identifies a specific router (e.g., a loopback). As 153 described in [I-D.ietf-spring-segment-routing-central-epe] and 154 [I-D.ietf-idr-bgpls-segment-routing-epe], BGP PeerAdj SID is used as 155 an instruction to steer over a specific local interface towards a 156 specific peer node in a peering Autonomous System (AS). These types 157 of SIDs can be extended to represent both topological elements and 158 the resources allocated on a network segment. The MPLS instantiation 159 of Segment Routing is specified in [RFC8660]. 161 For one IGP link, multiple Adj-SIDs SHOULD be allocated, each of 162 which is associated with a network topology the link participates, 163 and MAY represent a subset of link resources. Several approaches can 164 be used to partition the link resource, such as [FLEXE], Layer-2 165 logical sub-interfaces, dedicated queues, etc. The detailed 166 mechanism of resource partitioning is out of scope of this document. 168 Similarly, for one IGP node, multiple prefix-SIDs SHOULD be 169 allocated, each of which is associated with a network topology the 170 node participates, and MAY represent a subset of the node resource 171 (e.g. the processing resources). For one inter-domain link, multiple 172 BGP PeerAdj SIDs SHOULD be allocated, each of which is associated 173 with a specific network topology, which spans multiple domains, and 174 MAY represent a subset of link resource allocated on the inter-domain 175 link. Note that this per-segment resource allocation complies to the 176 SR paradigm, which avoids introducing per-path state into the 177 network. 179 A group of resource-aware SIDs associated with the same network 180 topology can be used to construct the SR paths (either strict or 181 loose) to steer traffic within the topology. Each SID in the SID- 182 list of the SR path MAY represent the set of network resources 183 reserved on the corresponding network segment. 185 In data packet forwarding, the SIDs are used to identify the topology 186 the packet belongs to, so that a topology specific next-hop can be 187 determined. In addition, the adj-SIDs MAY also be used to steer 188 traffic of different services into different set of link resources. 189 The prefix-SIDs MAY be used to steer traffic of different services 190 into different set of node resources. When a prefix-SID is used in 191 the SID-list to build an SR loose path, the transit nodes can use the 192 prefix-SID to identify the network topology and the associated group 193 of resource, and can process the packet using the local resources 194 allocated to the corresponding resource group. Note in this case, it 195 is RECOMMENDED that Penultimate Hop Popping (PHP) [RFC3031] be 196 disabled, otherwise the inner service label SHOULD be used to infer 197 the set of resources to be used on the egress node of the SR path. 199 This mechanism requires to allocate additional prefix-SIDs or adj- 200 SIDs for network segments to identify different set of network 201 resources. As the number of resource groups increases, the number of 202 SIDs would increase accordingly, while it should be noted that there 203 is no per-path state introduced into the network. 205 2.2. SRv6 207 As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6 208 Segment Identifier (SID) is a 128-bit value which consists of a 209 locator (LOC) and a function (FUNCT), optionally it may also contain 210 additional arguments (ARG) immediately after the FUNCT. The LOC of 211 the SID is routable and leads to the node which instantiates that 212 SID, which means the LOC can be parsed by all nodes in the network. 213 The FUNCT part of the SID is an opaque identification of a local 214 function bound to the SID, which means the FUNCT and ARG parts can 215 only be parsed by the node which instantiates that SID. 217 Taking the above into consideration, for a network node, multiple 218 SRv6 LOCs SHOULD be allocated, each of which is associated with a 219 network topology, and MAY represent a subset of the network resources 220 associated with a virtual network. The SRv6 SIDs of a particular 221 virtual network SHOULD be allocated from the SID space using the 222 resource-aware LOC as the prefix. These SRv6 SIDs can be used to 223 represent virtual network specific local functions. 225 A group of SRv6 SIDs associated with the same network topology can be 226 used to construct the SR paths (either strict or loose) to steer the 227 traffic of particular service within the topology. Each SID in the 228 SID-list of the SR path MAY also represent the set of network 229 resources on the corresponding network segment. 231 In data packet forwarding, the LOC part of SRv6 SID is used by 232 transit nodes to identify the topology the packet belongs to, so that 233 a topology specific next-hop can be determined. The LOC MAY also be 234 used to indicate the set of local network resources on the transit 235 nodes to be used for the forwarding of the received packet. The SRv6 236 segment endpoint nodes use the SRv6 SID to identify the topology the 237 packet belongs to, and the particular local function to perform on 238 the received packet. The local SRv6 SID MAY also be used to identify 239 the set of network resource to be used for executing the local 240 function. 242 This mechanism requires to allocate additional SRv6 Locators and SIDs 243 for network segments to identify different set of network resources. 244 As the number of resource groups increases, the number of Locators 245 and SIDs would increase accordingly, while it should be noted that 246 there is no per-path state introduced into the network. 248 3. Control Plane Considerations 250 The mechanism described in this document makes use of a centralized 251 controller to collect the information about the network 252 (configuration, state, routing databases, etc.) as well as the 253 service information (traffic matrix, performance statistics, etc.) 254 for the planning of network resources based on service requirement. 255 The controller is also responsible for the centralized computation 256 and optimization of the SR paths with both the topology and network 257 resource constraints. The resource-aware SIDs can be either 258 explicitly provisioned by the controller, or dynamically allocated by 259 network nodes then reported to the controller. The interaction 260 between the controller and the network nodes can be based on PCEP 261 [RFC5440], Netconf/YANG [RFC6241] [RFC7950] and BGP-LS [RFC7752]. In 262 some scenarios, extensions to some of these protocols is needed, 263 which are out of the scope of this document and will be specified in 264 separate documents. In some cases, a centralized controller may not 265 be used, but this would complicate the operations and planning 266 therefore not suggested. 268 The distributed control plane is complementary to the centralized 269 controller. A distributed control plane can be used for the 270 collection and distribution of the network topology and resource 271 information associated with SIDs among network nodes. Distributed 272 route computation for services with topology and resource constraints 273 may also be needed. The distributed control plane may be based on 274 [RFC4915], [RFC5120], [I-D.ietf-lsr-flex-algo] or the combination of 275 some of them with necessary extensions. The details are out of the 276 scope of this document. 278 4. IANA Considerations 280 This document makes no request of IANA. 282 Note to RFC Editor: this section may be removed on publication as an 283 RFC. 285 5. Security Considerations 287 The security considerations of segment routing are applicable to this 288 document. 290 The Resource-aware SIDs may be used for provisioning of SR paths or 291 virtual networks to carry traffic with latency as one of the SLA 292 parameters. By disrupting the latency of such traffic an attack can 293 be directly targeted at the customer application, or can be targeted 294 at the network operator by causing them to violate their SLA, 295 triggering commercial consequences. Dynamic attacks of this sort are 296 not something that networks have traditionally guarded against, and 297 networking techniques need to be developed to defend against this 298 type of attack. By rigorously policing ingress traffic and carefully 299 provisioning the resources provided to such services, this type of 300 attack can be prevented. However care needs to be taken when 301 providing shared resources, and when the network needs to be 302 reconfigured as part of ongoing maintenance or in response to a 303 failure. 305 The details of the underlay network MUST NOT be exposed to third 306 parties, to prevent attacks aimed at exploiting a shared resource. 308 6. Contributors 310 Zhenbin Li 311 Email: lizhenbin@huawei.com 313 Zhibo Hu 314 Email: huzhibo@huawei.com 316 7. Acknowledgements 318 The authors would like to thank Mach Chen, Stefano Previdi, Charlie 319 Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein and Joel 320 Halpern for the valuable discussion and suggestions to this document. 322 8. References 324 8.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 332 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 333 May 2017, . 335 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 336 Decraene, B., Litkowski, S., and R. Shakir, "Segment 337 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 338 July 2018, . 340 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 341 Decraene, B., Litkowski, S., and R. Shakir, "Segment 342 Routing with the MPLS Data Plane", RFC 8660, 343 DOI 10.17487/RFC8660, December 2019, 344 . 346 8.2. Informative References 348 [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, 349 . 352 [I-D.ietf-idr-bgpls-segment-routing-epe] 353 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 354 S., and J. Dong, "BGP-LS extensions for Segment Routing 355 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 356 segment-routing-epe-19 (work in progress), May 2019. 358 [I-D.ietf-lsr-flex-algo] 359 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 360 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 361 algo-08 (work in progress), July 2020. 363 [I-D.ietf-spring-segment-routing-central-epe] 364 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 365 Afanasiev, "Segment Routing Centralized BGP Egress Peer 366 Engineering", draft-ietf-spring-segment-routing-central- 367 epe-10 (work in progress), December 2017. 369 [I-D.ietf-spring-segment-routing-policy] 370 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 371 P. Mattes, "Segment Routing Policy Architecture", draft- 372 ietf-spring-segment-routing-policy-08 (work in progress), 373 July 2020. 375 [I-D.ietf-spring-srv6-network-programming] 376 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 377 Matsushima, S., and Z. Li, "SRv6 Network Programming", 378 draft-ietf-spring-srv6-network-programming-16 (work in 379 progress), June 2020. 381 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 382 "Definition of the Differentiated Services Field (DS 383 Field) in the IPv4 and IPv6 Headers", RFC 2474, 384 DOI 10.17487/RFC2474, December 1998, 385 . 387 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 388 and W. Weiss, "An Architecture for Differentiated 389 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 390 . 392 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 393 Label Switching Architecture", RFC 3031, 394 DOI 10.17487/RFC3031, January 2001, 395 . 397 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 398 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 399 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 400 . 402 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 403 (TE) Extensions to OSPF Version 2", RFC 3630, 404 DOI 10.17487/RFC3630, September 2003, 405 . 407 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 408 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 409 RFC 4915, DOI 10.17487/RFC4915, June 2007, 410 . 412 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 413 Topology (MT) Routing in Intermediate System to 414 Intermediate Systems (IS-ISs)", RFC 5120, 415 DOI 10.17487/RFC5120, February 2008, 416 . 418 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 419 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 420 2008, . 422 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 423 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 424 DOI 10.17487/RFC5439, February 2009, 425 . 427 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 428 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 429 DOI 10.17487/RFC5440, March 2009, 430 . 432 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 433 and A. Bierman, Ed., "Network Configuration Protocol 434 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 435 . 437 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 438 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 439 RFC 6790, DOI 10.17487/RFC6790, November 2012, 440 . 442 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 443 Previdi, "OSPF Traffic Engineering (TE) Metric 444 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 445 . 447 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 448 S. Ray, "North-Bound Distribution of Link-State and 449 Traffic Engineering (TE) Information Using BGP", RFC 7752, 450 DOI 10.17487/RFC7752, March 2016, 451 . 453 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 454 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 455 RFC 7810, DOI 10.17487/RFC7810, May 2016, 456 . 458 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 459 RFC 7950, DOI 10.17487/RFC7950, August 2016, 460 . 462 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 463 (IPv6) Specification", STD 86, RFC 8200, 464 DOI 10.17487/RFC8200, July 2017, 465 . 467 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 468 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 469 IGP Traffic Engineering Performance Metric Extensions", 470 RFC 8571, DOI 10.17487/RFC8571, March 2019, 471 . 473 Authors' Addresses 475 Jie Dong 476 Huawei Technologies 478 Email: jie.dong@huawei.com 480 Stewart Bryant 481 Futurewei Technologies 483 Email: stewart.bryant@gmail.com 485 Takuya Miyasaka 486 KDDI Corporation 488 Email: ta-miyasaka@kddi.com 490 Yongqing Zhu 491 China Telecom 493 Email: zhuyq8@chinatelecom.cn 495 Fengwei Qin 496 China Mobile 498 Email: qinfengwei@chinamobile.com 500 Zhenqiang Li 501 China Mobile 503 Email: li_zhenqiang@hotmail.com 505 Francois Clad 506 Cisco Systems 508 Email: fclad@cisco.com