idnits 2.17.1 draft-bestbar-spring-scalable-ns-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 (February 22, 2021) is 1159 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) -- No information found for draft-bestbar-lsr-spring-sa - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.bestbar-lsr-spring-sa' == Outdated reference: A later version (-10) exists of draft-bestbar-teas-ns-packet-01 ** Downref: Normative reference to an Informational draft: draft-bestbar-teas-ns-packet (ref. 'I-D.bestbar-teas-ns-packet') == Outdated reference: A later version (-05) exists of draft-decraene-mpls-slid-encoded-entropy-label-id-00 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-srv6-stateless-slice-id-02 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group T. Saad 3 Internet-Draft V. Beeram 4 Intended status: Standards Track Juniper Networks 5 Expires: August 26, 2021 R. Chen 6 S. Peng 7 ZTE Corporation 8 B. Wen 9 Comcast 10 D. Ceccarelli 11 Ericsson 12 February 22, 2021 14 Scalable Network Slicing over SR Networks 15 draft-bestbar-spring-scalable-ns-01 17 Abstract 19 Multiple network slices can be realized on top of a single shared 20 network. A router that requires forwarding of a packet that belongs 21 to a slice aggregate may have to decide on the forwarding action to 22 take based on selected next-hop(s), and the forwarding treatment 23 (e.g., scheduling and drop policy) to enforce based on the slice 24 aggregate per-hop behavior. Segment Routing is a technology that 25 enables the steering of packets in a network by encoding pre- 26 established segments within the network into the packet header. This 27 document introduces mechanisms to enable forwarding of packets over a 28 specific slice aggregate along a Segment Routing (SR) path. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 26, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Forwarding over SR Network Slices . . . . . . . . . . . . . . 3 67 2.1. Path Selection . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Network Slice Selection . . . . . . . . . . . . . . . . . 4 69 2.2.1. Segment Range as Slice Selector . . . . . . . . . . . 4 70 2.2.2. Global Identifier as Slice Selector . . . . . . . . . 7 71 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 74 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 7.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Network slicing allows a service provider, or a network operator to 83 create independent and isolated logical networks on top of a common 84 or shared physical network infrastructure. 86 When logical network slices are realized on top of a shared physical 87 network, it is important to forward traffic using only the specific 88 resource(s) allocated to the network slice. 90 The definition of a network slice for use within the IETF and the 91 characteristics of IETF network slice are specified in 92 [I-D.nsdt-teas-ietf-network-slice-definition]. A framework for 93 reusing IETF VPN and traffic-engineering technologies to realize IETF 94 network slices is discussed in [I-D.nsdt-teas-ns-framework]. 96 [I-D.bestbar-teas-ns-packet] introduces the notion of a Slice 97 Aggregate as the construct that comprises of one of more IETF network 98 slice traffic streams. A slice policy can be used to realize a slice 99 aggregate by instantiating specific control and data plane resources 100 on select topological elements in an IP/MPLS network. The packets 101 belonging to a specific slice aggregate MAY require to be identified 102 so that a specific forwarding treatment (e.g., scheduling and drop 103 policy) is enforced. 105 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 106 through a network by carrying an ordered list of segments. A segment 107 is referred to by its Segment Identifier (SID). 109 This document introduces two approaches applicable to SR networks 110 that enable forwarding of packet(s) that belong to a slice aggregate 111 over a SR Path. 113 The first approach extends the SR paradigm by defining a new SID type 114 (slice SID) that, in addition to defining the forwarding action 115 (next-hop selection), associates a SID to slice aggregate and allows 116 enforcing the associated forwarding treatment. The extensions to 117 IGPs for slice aggregate SIDs are defined in 118 [I-D.bestbar-lsr-spring-sa]. 120 The second approach relies on a separate field that is carried in the 121 packet (e.g., MPLS label) to identify the slice aggregate and uses 122 another field (e.g., existing SR segments) for the path selection for 123 the packet. 125 1.1. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 2. Forwarding over SR Network Slices 135 A router that receives a packet that belongs to a slice aggregate has 136 to decide on the set of eligible next-hop(s) to forward the packet on 137 (path selection), and on the forwarding treatment (scheduling and 138 drop policy) that needs to be enforced for a specific slice aggregate 139 (slice aggregate selection). 141 2.1. Path Selection 143 The segment routing architecture [RFC8402] defines a number of 144 topological segments that may be advertised in routing protocols to 145 allow for a flexible definition of end-to-end paths. For example, an 146 SR-capable IGP router may advertise SIDs for its attached prefixes 147 and adjacencies. 149 The IGP-Adjacency segment represents the strict path over a specific 150 adjacency between two routers, while the IGP-Prefix segment 151 represents the path to a prefix that is computed over a specific 152 topology and algorithm. 154 For an IGP-Prefix segment, the IGP uses the topology and algorithm to 155 compute the primary, and optionally alternate (backup) next-hop(s) 156 for a destination prefix. SR allows the use of multiple routing 157 algorithms (e.g., Flexible Algorithms) that enable IGPs on a router 158 to compute paths for Prefix-SIDs whose topology may be constrained 159 and whose paths optimized for additional metric types other than the 160 default IGP cost (e.g., delay metric). 162 Multiple slice aggregates may overlap over the same topology and 163 require paths for prefixes to be optimized for the same Algorithm. 164 In such case, the IGP selected path for the slice aggregate Prefix- 165 SIDs can share the same IGP computed path (including the primary and 166 backup next-hop(s)). This enables the IGP to optimize the path 167 computation and path programming for such SA Prefix-SIDs. 169 2.2. Network Slice Selection 171 The routers in network that forward traffic over links that are 172 shared by multiple slice aggregates need to identify the slice 173 aggregate that the packet belongs to in order to enforce the 174 associated forwarding treatment on it. 176 [I-D.bestbar-teas-ns-packet] introduces the slice policy as a means 177 to realize a slice aggregate by instantiating specific control and/or 178 data plane resources on select topological elements in the network. 179 In order to enforce a forwarding treatment associated with a slice 180 aggregate, the packets traversing a router MUST be identified as part 181 of a slice aggregate (for example, by using field(s) carried in the 182 packet). 184 2.2.1. Segment Range as Slice Selector 186 It is possible to derive the forwarding action (next-hop selection) 187 and the per-hop forwarding treatment from a single field (e.g. SR 188 segment) carried inside a packet that is traversing the SR network. 190 For example, one way to achieve this is leverage the SR Flexible- 191 Algorithm [I-D.ietf-lsr-flex-algo] to assign SR SID per slice 192 aggregate. A router can can assign and advertise SR Prefix-SIDs per 193 Flex-Algorithm for a prefix to enable reachability over multiple 194 slice aggregates. 196 For a specific Flexible Algorithm, the range of Prefix-SIDs of all 197 prefixes in the network can be used as a slice selector mapping to a 198 specific slice aggregate. This approach does not require protocol 199 extensions to be realized; however, it poses serious IGP scalability 200 concerns when realizing a large number of slice aggregates. 202 Alternatively, this document proposes to extend the IGP SR Prefix-SID 203 and Adjacency-SID sub-TLVs defined in [RFC8667] and [RFC8665] to 204 carry an additional distinguisher (Slice Aggregate identifier) to 205 allow multiple SIDs to be assigned (and advertised) for the same 206 topological element for the same Flexible-Algorithm and topology. In 207 such a case, a transit router can use the SR slice aggregate SID 208 carried in the packet to identify the slice aggregate, as well as to 209 determine the forwarding next-hop. 211 Multiple Slice Aggregate Prefix-SIDs (SA Prefix-SIDs) can be assigned 212 to the same prefix, while they share the same topology and Algorithm. 213 The SA Prefix-SIDs can also share the same IGP computed paths 214 (primary and backup). Similarly, multiple Slice Aggregate Adjacency- 215 SIDs (SA Adjacency-SIDs) can be allocated for the same adjacency 216 between the two routers to distinguish forwarding over the same 217 adjacency for each slice aggregate. The extensions for IGPs to 218 advertise SA Prefix-SIDs and SA Adjacency-SIDs are defined in 219 [I-D.bestbar-lsr-spring-sa]. 221 The same forwarding treatment MUST be enforced on all packets 222 belonging to a slice aggregate but destined to different topological 223 elements in the network. In this case, a range of SA (Prefix and 224 Adjacency) SIDs is used to select the slice aggregate, and hence 225 enforce the same forwarding treatment on them. 227 Note that this approach requires maintaining per slice aggregate 228 state for each topological element on every router in the network in 229 both the control and data plane. For example, a network composed of 230 'N' routers, where each router has up to 'K' adjacencies to its 231 neighbors, a router would have to assign and advertise 'M' SA Prefix- 232 SIDs and 'M' SA Slice Adjacency-SID(s) to each of it 'K' adjacencies. 233 Consequently, a router will have to maintain up to (N+K)*M SIDs in 234 the control plane, and an equal number of labeled routes in its 235 forwarding plane. 237 Consider a network shown in Figure 1 that is enabled for SR. The 238 Segment Routing Global Block (SRGB) on all routers is assumed to 239 start from 16000. We assume the links in the network are partitioned 240 amongst two network slice aggregates: SA1, and SA2. 242 o Node R5 assigns two Algorithm 0 SA Prefix-SIDs, index=105, and 243 index=205 to represent the shortest IGP to R5 for slice aggregates 244 SA1 and SA2 respectively. 246 o A Flexible Algorithm Definition (FAD) for Algorithm 128 is defined 247 by the user such that the FAD Metric-Type is 1 (Min Unidirectional 248 Link Delay). 250 o Node R5 assigns two Algorithm 128 SA Prefix-SIDs, index=815, and 251 index=825 to represent the least delay path to R5 for slice 252 aggregates SA1 and SA2 respectively. 254 o All routers in the network participate and advertise their 255 capability to compute FAD 128 Prefix-SID paths. 257 Using the approach described in this section, R1 is able to forward 258 packets that traverse slices aggregates SA1 and SA2 along the least 259 delay path by imposing the MPLS SR SID 16815, and 16825 respectively. 261 In addition, R1 is able to forward packets that traverse slice 262 aggregate SA1 and SA2 along the IGP shortest path to R5 by imposing 263 the MPLS SR SID 16015, and 16025 respectively. 265 SLICE | ALG(0) | Path 266 AGG | SA Prefix-SID(R5) | Symbol 267 ======================================= 268 SA1 | 16015 | + 269 SA2 | 16025 | @ 270 .. 271 SAn | .. | 273 SLICE | ALG(128) | Path 274 AGG | SA Prefix-SID(R5) | Symbol 275 ======================================= 276 SA1 | 16815 | . 277 SA2 | 16825 | * 278 .. 279 SAn | .. | 281 + + + + + + + + + + + + + 282 + @ @ @ @ @ @ @ @ @ @ @ @ + 283 + @ +----+ @ + 284 + @ +-------| R2 |------+ @ + 285 +@ / +----+ \ @ + 286 +----+ / \ +----+ 287 | R1 | | R5 | 288 +----+ \ / +----+ 289 .* \+----+ +----+/ *. 290 .* | R3 |---------| R4 | *. 291 .* +----+ +----+ *. 292 .* * * * * * * * * * * * * *. 293 . . . . . . . . . . . . . . 295 Figure 1: Example of forwarding over slice aggregates using SR Paths. 297 2.2.2. Global Identifier as Slice Selector 299 It is possible that the forwarding action and the per-hop behavior 300 treatment is derived from different fields carried in a packet. For 301 example, a packet can carry a global slice selector field that can be 302 used to define the forwarding treatment while the forwarding next-hop 303 relies on the SR topological SIDs. This makes the slice aggregate 304 identification independent of the topology or the destination of the 305 packet, and thus, allows for scalable slice aggregates. 307 The Slice aggregate Selector (SS) is carried in each packet destined 308 to any topological element and that is to be steered over the slice 309 aggregate. For example, the slice aggregate SS can be carried in an 310 MPLS label that is present in an MPLS packet's label stack. It is 311 possible, also, to have a range of MPLS labels to represent the SS 312 associated with slice aggregate. 314 When the slice aggregate is realized over an IPv6 dataplane, the SS 315 can be encoded in the IP header. For example, the SS can be encoded 316 in a portion of the IPv6 Flow Label field as described in 317 [I-D.filsfils-spring-srv6-stateless-slice-id]. 319 Routers within the network use the topological SR segment SIDs to 320 determine the forwarding action (next-hop selection), and use the 321 slice aggregate selector to enforce the dataplane policy (e.g., as 322 defined by the slice policy in [I-D.bestbar-teas-ns-packet]). 324 The SS label may be embedded at different positions in the MPLS label 325 stack. For example, the SS label MAY be located at the top of the 326 MPLS packet label stack and maintained, by each hop, while the packet 327 is forwarded along the SR path. However, since assigning a global 328 MPLS label on all nodes for the SS may not be always feasible, an 329 alternative is to assign a global Index for a Slice Aggregate 330 Selector (SA Selector Index). In this case, the SA Selector Index is 331 used to determine the actual MPLS label value (e.g., from the router 332 Global Label Block) on a given router. 334 The SS label can also reside at the bottom of the label stack. For 335 example, a range of VPN service labels may also serve as a SS to map 336 traffic from multiple VPNs to the same slice aggregate. 338 Another option is to encode the SS as part of a well-known label such 339 as Entropy Label (EL) as suggested in 340 [I-D.decraene-mpls-slid-encoded-entropy-label-id]. This optimizes 341 the number of the MPLS labels needed in the stack and provides an 342 ease incremental deployment. 344 Lastly, a new Special Purpose Label- e.g., Slice Selector Indicator 345 (SSI)- from the MPLS the Base Special-Purpose MPLS Label, or Extended 346 Special-Purpose MPLS Label spaces can be used to indicate that a SS 347 label immediately follows the SSI. In this case, the ingress router 348 of slice aggregate boundary will impose at least two additional MPLS 349 labels (SSI + SS) to identify the packets that belong to the slice 350 aggregate. 352 This approach reduces the amount of state required to be stored on a 353 router to allow forwarding over slice aggregates since it does not 354 require a Prefix-SID state per slice aggregate in the control plane, 355 nor in the forwarding plane. 357 To illustrate forwarding over slice aggregates using a SS label, we 358 consider the same network described earlier in Figure 1, but with 359 some changes in the configuration: 361 o Node R5 assigns an Algorithm 0 Prefix-SID of index=5 to represent 362 the shortest IGP path from any router to R5. 364 o Node R5 assigns Algorithm 128 Prefix-SID of index=805 to represent 365 the least delay path from any router to R5. 367 o All routers in the network participate and advertise their 368 capability to compute FAD 128 Prefix-SID paths. 370 o The SS labels 1001 and 1002 are used for packets that require to 371 be forwarded over slice aggregates SA1 and SA2 respectively. 373 Using the approach described in this section, R1 is able to forward 374 packets that traverse slice aggregate SA1 and SA2 along the least 375 delay path by imposing the following labels {16805, SSI, 1001} and 376 {16805, SSI, 1002} respectively. 378 Similarly, R1 is able to forward packets that traverse over slice 379 aggregates SA1 and SA2 along the IGP shortest path to R5 by imposing 380 the following labels {16005, SSI, 1001} and {16005, SSI, 1002} 381 respectively. The path that the packets traverse in each of the 382 above case remains as described in Figure 1. 384 3. IANA Considerations 386 This document has no IANA actions. 388 4. Security Considerations 390 The main goal of network slicing is to allow for some level of 391 isolation for traffic from multiple different network slices that are 392 utilizing a common network infrastructure and to allow for different 393 levels of services to be provided for traffic traversing a single 394 slice aggregate resource(s). 396 A variety of techniques may be used to achieve this, but the end 397 result will be that some packets may be mapped to specific 398 resource(s) and may receive different (e.g., better) service 399 treatment than others. The mapping of network traffic to a specific 400 slice is indicated primarily by the SS, and hence an adversary may be 401 able to utilize resource(s) allocated to a specific network slice by 402 injecting packets carrying the same SS field in their packets. 404 Such theft-of-service may become a denial-of-service attack when the 405 modified or injected traffic depletes the resources available to 406 forward legitimate traffic belonging to a specific slice aggregate. 408 The defense against this type of theft and denial-of-service attacks 409 consists of the combination of traffic conditioning at network 410 slicing domain boundaries with security and integrity of the network 411 infrastructure within a network slicing domain. 413 5. Acknowledgement 415 The authors would like to thank Krzysztof Szarkowicz, Swamy SRK, 416 Navaneetha Krishnan, and Prabhu Raj Villadathu Karunakaran for their 417 review of this document, and for providing valuable feedback on it. 419 6. Contributors 421 The following individuals contributed to this document: 423 Colby Barth 424 Juniper Networks 425 Email: cbarth@juniper.net 427 Srihari R. Sangli 428 Juniper Networks 429 Email: ssangli@juniper.net 431 Chandra Ramachandran 432 Juniper Networks 433 Email: csekar@juniper.net 435 7. References 437 7.1. Normative References 439 [I-D.bestbar-lsr-spring-sa] 440 Saad, T., Beeram, V., Chen, R., Peng, S., Wen, B., and D. 441 Ceccarelli, "IGP Extensions for SR Slice Aggregate SIDs", 442 February 2021. 444 [I-D.bestbar-teas-ns-packet] 445 Saad, T., Beeram, V., Wen, B., Ceccarelli, D., Halpern, 446 J., Peng, S., Chen, R., and X. Liu, "Realizing Network 447 Slices in IP/MPLS Networks", draft-bestbar-teas-ns- 448 packet-01 (work in progress), December 2020. 450 [I-D.decraene-mpls-slid-encoded-entropy-label-id] 451 Decraene, B., Filsfils, C., Henderickx, W., Saad, T., and 452 V. Beeram, "Using Entropy Label for Network Slice 453 Identification in MPLS networks.", draft-decraene-mpls- 454 slid-encoded-entropy-label-id-00 (work in progress), 455 December 2020. 457 [I-D.filsfils-spring-srv6-stateless-slice-id] 458 Filsfils, C., Clad, F., Camarillo, P., and K. Raza, 459 "Stateless and Scalable Network Slice Identification for 460 SRv6", draft-filsfils-spring-srv6-stateless-slice-id-02 461 (work in progress), January 2021. 463 [I-D.ietf-lsr-flex-algo] 464 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 465 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 466 algo-13 (work in progress), October 2020. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 474 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 475 May 2017, . 477 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 478 Decraene, B., Litkowski, S., and R. Shakir, "Segment 479 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 480 July 2018, . 482 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 483 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 484 Extensions for Segment Routing", RFC 8665, 485 DOI 10.17487/RFC8665, December 2019, 486 . 488 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 489 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 490 Extensions for Segment Routing", RFC 8667, 491 DOI 10.17487/RFC8667, December 2019, 492 . 494 7.2. Informative References 496 [I-D.nsdt-teas-ietf-network-slice-definition] 497 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 498 Tantsura, "Definition of IETF Network Slices", draft-nsdt- 499 teas-ietf-network-slice-definition-02 (work in progress), 500 December 2020. 502 [I-D.nsdt-teas-ns-framework] 503 Gray, E. and J. Drake, "Framework for Transport Network 504 Slices", draft-nsdt-teas-ns-framework-04 (work in 505 progress), July 2020. 507 Authors' Addresses 509 Tarek Saad 510 Juniper Networks 512 Email: tsaad@juniper.net 514 Vishnu Pavan Beeram 515 Juniper Networks 517 Email: vbeeram@juniper.net 519 Ran Chen 520 ZTE Corporation 522 Email: chen.ran@zte.com.cn 524 Shaofu Peng 525 ZTE Corporation 527 Email: peng.shaofu@zte.com.cn 529 Bin Wen 530 Comcast 532 Email: Bin_Wen@cable.comcast.com 533 Daniele Ceccarelli 534 Ericsson 536 Email: daniele.ceccarelli@ericsson.com