idnits 2.17.1 draft-bestbar-spring-scalable-ns-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 (December 16, 2020) is 1226 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) == Outdated reference: A later version (-10) exists of draft-bestbar-teas-ns-packet-00 ** Downref: Normative reference to an Informational draft: draft-bestbar-teas-ns-packet (ref. 'I-D.draft-bestbar-teas-ns-packet-00') == Outdated reference: A later version (-09) exists of draft-filsfils-spring-srv6-stateless-slice-id-01 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: June 19, 2021 December 16, 2020 7 Scalable Network Slicing over SR Networks 8 draft-bestbar-spring-scalable-ns-00 10 Abstract 12 Multiple network slices can be realized on top of a single shared 13 network. A router that requires forwarding of a packet that belongs 14 to a network slice may have to decide on the forwarding action to 15 take based on selected next-hop(s), and the forwarding treatment 16 (e.g. scheduling and drop policy) to enforce based on the slice 17 aggregate per-hop behavior. Segment Routing is a technology that 18 enables the steering of packets in a network by encoding pre- 19 established segments within the network into the packet header. This 20 document introduces mechanisms to enable forwarding of packets over a 21 specific network slice along a Segment Routing (SR) path. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 19, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Forwarding over SR Network Slices . . . . . . . . . . . . . . 3 60 2.1. Path Selection . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Network Slice Selection . . . . . . . . . . . . . . . . . 4 62 2.2.1. Segment Range as Slice Selector . . . . . . . . . . . 4 63 2.2.2. Global Identifier as Slice Selector . . . . . . . . . 6 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 Network slicing allows a service provider, or a network operator to 74 create independent and isolated logical networks on top of a common 75 or shared physical network infrastructure. 77 When logical network slices are realized on top of a shared physical 78 network, it is important to forward traffic using only the specific 79 resource(s) allocated for the network slice. Packets that traverse a 80 network slice MAY be identified by specific field(s) carried within 81 the packet. 83 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 84 through a network by carrying an ordered list of segments. A segment 85 is referred to by its Segment Identifier (SID). 87 This document introduces two approaches applicable to SR networks 88 that enable forwarding of packet(s) that belong to a network slice 89 over a SR Path. 91 The first approach extends the SR paradigm by defining a new SID type 92 (slice SID) that, in addition to defining the forwarding action 93 (next-hop selection), associates a SID to the network slice and 94 allows enforcing the specified forwarding treatment. 96 The second approach relies on a separate field carried in the packet 97 (e.g. MPLS label) to identify the network slice and relies on 98 another field (e.g. existing SR segments) for the path selection for 99 the packet. 101 1.1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. Forwarding over SR Network Slices 111 A router that receives a packet that belongs to a network slice has 112 to decide on the set of eligible next-hop(s) to forward the packet on 113 (path selection), and on the forwarding treatment (scheduling and 114 drop policy) that needs to be enforced for a specific slice (network 115 slice selection). 117 2.1. Path Selection 119 The segment routing architecture [RFC8402] defines a number of 120 topological segments that may be advertised in routing protocols to 121 allow for a flexible definition of end-to-end paths. For example, an 122 SR-capable IGP node may advertise SIDs for its attached prefixes and 123 adjacencies. 125 The IGP-Adjacency segment represents the strict path over a specific 126 adjacency between two routers, while the IGP-Prefix segment 127 represents the path to a prefix that is computed over a specific 128 topology and algorithm. 130 For an IGP-Prefix segment, the IGP uses the topology and algorithm to 131 compute the primary, and optionally alternate (backup) next-hop(s) 132 for a destination prefix. SR allows the use of multiple routing 133 algorithms (e.g. Flexible Algorithms) that enable IGPs on a router 134 to compute paths for Prefix-SIDs whose topology may be constrained 135 and whose paths optimized for additional metric types other than the 136 default IGP cost (e.g. delay metric). 138 Multiple network slice(s) may overlap over the same topology and may 139 require paths to prefixes be optimized for the same metric. In such 140 case, the IGP prefix selected path (including the primary and backup 141 computed next-hop(s)) can be shared for all the per slice Prefix- 142 SIDs. The IGP, then, can maintain a single topology for N network 143 slices, which allows for optimizing SPF computation(s) for multiple 144 Slice SIDs and improves convergence. 146 2.2. Network Slice Selection 148 Routers that forward packets over links shared by multiple network 149 slices need to identify to which network slice the packet belongs so 150 that the associated forwarding treatment can be enforced. 152 In [I-D.draft-bestbar-teas-ns-packet-00], a Slice Per Hop Definition 153 (Slice-PHD) is introduced that carries a number of policies related 154 to a network slice, including a slice selector that can be used to 155 identify packets belonging to a slice, and a dataplane policy that 156 defines the forwarding treatment that is enforced on network slice 157 packets. 159 2.2.1. Segment Range as Slice Selector 161 It is possible to derive the forwarding action (next-hop selection) 162 and the per-hop forwarding treatment from a single field (e.g. SR 163 segment) carried inside a packet that is traversing the SR network. 165 For example, one way to achieve this is leverage the SR Flexible 166 Algorithm [I-D.ietf-lsr-flex-algo] to assign multiple SR Prefix-SIDs 167 for a prefix and map all Prefix-SIDs of the same FAD to a network 168 slice. While this approach does not require any protocol extension 169 to realize, it does pose some IGP scalability concerns when realizing 170 a large number of network slices (and consequently, the number of 171 FADs that need to be advertised and managed by the IGP in a network). 173 Another approach, is to add a new distinguisher to existing IGP 174 segments (e.g. Prefix-SID and Adjacency-SID) to allow multiple SIDs 175 to be assigned (and advertised) for the same topological element 176 within the same FAD. This approach requires extending the IGP 177 segment Prefix-SID and Adjacency-SID TLVs to carry a new 178 distinguisher field (e.g. network slice identifier). In such a case, 179 the traffic that belongs to different network slices, but destined to 180 the same topological element, carries the specific per slice SID, and 181 a transit node can use the active (top) SID to derive both the 182 forwarding action and forwarding treatment from the slice SID. 184 For example, multiple per slice Prefix-SIDs (Slice Prefix-SIDs) can 185 be assigned for the same prefix such that they all share the same IGP 186 computed path over one topology and optimized for one algorithm to 187 allow the steering of traffic to the same prefix along a path but 188 over different network slices. 190 Similarly, multiple Adjacency-SIDs can be allocated for the same 191 adjacency between the two routers to distinguish forwarding over the 192 same adjacency on each network slice. 194 The same forwarding treatment MUST be enforced on all packets 195 belonging to the network slice but could be destined to any 196 topological element in the network. In this case, a range of Slice 197 SIDs are used to select the same network slice and any packet steered 198 with such Slice SIDs will be subject to the dataplane policy defined 199 in the Slice-PHD. 201 Notably, this approach requires maintaining per slice state for each 202 topological element on every router in the network in both the 203 control and data plane. For example, a network composed of 'N' 204 nodes, where each node has up to 'K' adjacencies to its neighbors, a 205 node would have to assign and advertise 'M' Slice Prefix-SIDs and 'M' 206 Slice Adjacency-SID(s) to each of it 'K' adjacencies. Consequently, 207 a router will have to maintain up to (N+K)*M SIDs in the control 208 plane, and an equal number of label routes in its forwarding plane. 210 Consider a network shown in Figure 1 that is enabled for SR. The 211 Segment Routing Global Block (SRGB) on all nodes is assumed to start 212 from 16000. We assume the links in the network are partitioned 213 amongst two network slices: SLC1, and SLC2. 215 o Node R5 assigns Slice Prefix-SIDs for Algorithm 0 of index=105, 216 and index=205 for network slice SLC1 and SLC2 respectively to 217 represent the shortest IGP path from any node to R5. 219 o A Flexible Algorithm Definition (FAD) number 128 is user-defined 220 such that the FAD Metric-Type is 1 (Min Unidirectional Link 221 Delay). 223 o Node R5 assigns Slice Prefix-SIDs for Algorithm 128 of index=815, 224 and index=825 for network slices SLC1 and SLC2 respectively to 225 represent the least delay path from any node to R5. 227 o All nodes in the network participate and advertise their 228 capability to compute FAD 128 Prefix-SID paths. 230 Using the approach described in this section, R1 is able to forward 231 packets that traverse network slices SLC1 and SLC2 along the least 232 delay path by imposing the MPLS SR SID 16815, and 16825 respectively. 234 Alternatively, R1 is able to forward packets that traverse network 235 slices SLC1 and SLC2 along the IGP shortest path to R5 by imposing 236 the MPLS SR SID 16015, and 16025 respectively. 238 SLICE | ALG(0) | Path 239 | Slice Prefix-SID(R5) | Symbol 240 ======================================= 241 SLC1 | 16015 | + 242 SLC2 | 16025 | @ 243 .. 244 SLCn | .. | 246 SLICE | ALG(128) | Path 247 | Slice Prefix-SID(R5) | Symbol 248 ======================================= 249 SLC1 | 16815 | . 250 SLC2 | 16825 | * 251 .. 252 SLCn | .. | 254 + + + + + + + + + + + + + 255 + @ @ @ @ @ @ @ @ @ @ @ @ + 256 + @ +----+ @ + 257 + @ +-------| R2 |------+ @ + 258 +@ / +----+ \ @ + 259 +----+ / \ +----+ 260 | R1 | | R5 | 261 +----+ \ / +----+ 262 .* \+----+ +----+/ *. 263 .* | R3 |---------| R4 | *. 264 .* +----+ +----+ *. 265 .* * * * * * * * * * * * * *. 266 . . . . . . . . . . . . . . 268 Figure 1: Example of forwarding over network slices using SR Paths. 270 2.2.2. Global Identifier as Slice Selector 272 It is possible that the forwarding action and the per-hop behavior 273 treatment are derived from different fields carried in a packet. For 274 example, a packet can carry a global slice selector field that can be 275 used to define the forwarding treatment while the forwarding next-hop 276 selection relies on the SR topological SIDs. The makes the slice 277 identification independent of the topology or the destination of the 278 packet, and thus, allows for scalable network slicing. 280 The global Slice Selector (SS) is carried in each packet destined to 281 any topological element and that is to be steered over the network 282 slice. For example, a global slice selector can be represented as a 283 global MPLS label that is carried in an MPLS packet's label stack. 285 It is possible, also, to have multiple SS label(s) associated with 286 the same network slice resources. When the slice is realized over an 287 IPv6 dataplane, the SS can be encoded in the IP header. For example, 288 the SS can be encoded in portion of the IPv6 Flow Label field as 289 described in [I-D.draft-filsfils-spring-srv6-stateless-slice-id-01]. 291 Routers within the network use the topological SR segment SIDs to 292 determine the forwarding action (next-hop selection), and use the 293 global slice selector to enforce the dataplane policy (e.g. as 294 defined by the Slice-PHD). 296 The Slice Selector Label (SSL) may appear in several positions in the 297 MPLS label stack. For example, the SSL MAY be located at the top of 298 the MPLS packet label stack and maintained, by each hop, while the 299 packet is forwarded along the SR path. Alternatively, the SSL could 300 also reside at the bottom of the label stack. For example, the VPN 301 service label may also serve as an SSL which allows steering of 302 traffic towards one or more egress PEs over the same network slice. 303 In such a case, it MAY be desirable to have one or more service 304 labels be mapped to the same network slice. The same VPN label may 305 also be allocated on all Egress PEs so it can serve as a single SSL 306 for a specific network slice. Alternatively, a range of SSL (VPN 307 labels) may be mapped to a single network slice to allow carrying 308 multiple VPN(s) over the same network slice. 310 In other cases, the position of the SSL may not be at a fixed place 311 in the MPLS label header. In this case, transit routers cannot 312 expect the SSL at a fixed place in the MPLS label stack. This can be 313 addressed by introducing a new Special Purpose Label from the label 314 reserved space called a Slice Selector Label Indicator (SSLI). The 315 slice network ingress boundary node, in this case, will need to 316 impose at least two additional MPLS labels (SSLI + SSL) to identify 317 the packets that belong to the network slice. 319 It should be noted that this approach minimizes the amount of state 320 required to be stored on a node to allow network slice forwarding 321 since it does not require a Prefix-SID state per network slice in the 322 control plane, nor in the forwarding plane. 324 To illustrate forwarding over network slices using a global slice 325 label, we consider the same network described earlier in Figure 1, 326 but with some changes in the configuration: 328 o Node R5 assigns a Prefix-SID for Algorithm 0 (default) of index=5 329 to represent the shortest IGP path from any node to R5. 331 o Node R5 assigns a Prefix-SID for Algorithm 128 of index=805 to 332 represent the least delay path from any node to R5. 334 o All nodes in the network participate and advertise their 335 capability to compute FAD 128 Prefix-SID paths. 337 o The global labels 1001 and 1002 are used as a slice selectors for 338 packets that require to be forwarded over network slices SLC1 and 339 SLC2 respectively. 341 Using the approach described in this section, R1 is able to forward 342 packets that traverse network slices SLC1 and SLC2 along the least 343 delay path by imposing the following labels {1001,16805} and 344 {1002,16805} respectively. 346 Similarly, R1 is able to forward packets that traverse network slices 347 SLC1 and SLC2 along the IGP shortest path to R5 by imposing the 348 following labels {1001,16005} and {1002,16005} respectively. The 349 path that the packets traverse in each of the above case remains as 350 described in Figure 1. 352 3. IANA Considerations 354 This document has no IANA actions. 356 4. Security Considerations 358 The main goal of network slicing is to allow for some level of 359 isolation for traffic from multiple different network slices that are 360 utilizing a common network infrastructure and to allow for different 361 levels of services to be provided for traffic traversing a single 362 network slice resource(s). 364 A variety of techniques may be used to achieve this, but the end 365 result will be that some packets may be mapped to specific 366 resource(s) and may receive different (e.g., better) service 367 treatment than others. The mapping of network traffic to a specific 368 slice is indicated primarily by the SS, and hence an adversary may be 369 able to utilize resource(s) allocated to a specific network slice by 370 injecting packets carrying the same SS field in their packets. 372 Such theft-of-service may become a denial-of-service attack when the 373 modified or injected traffic depletes the resources available to 374 forward legitmiate traffic belonging to a specific network slice. 376 The defense against this type of theft and denial-of-service attacks 377 consists of the combination of traffic conditioning at network 378 slicing domain boundaries with security and integrity of the network 379 infrastructure within a network slicing domain. 381 5. Acknowledgement 383 The authors would like to thank Krzysztof Szarkowicz, Swamy SRK, 384 Navaneetha Krishnan, and Prabhu Raj Villadathu Karunakaran for their 385 review of this document, and for providing valuable feedback on it. 387 6. Contributors 389 The following individuals contributed to this document: 391 Colby Barth 392 Juniper Networks 393 Email: cbarth@juniper.net 395 Srihari R. Sangli 396 Juniper Networks 397 Email: ssangli@juniper.net 399 Chandra Ramachandran 400 Juniper Networks 401 Email: csekar@juniper.net 403 7. Normative References 405 [I-D.draft-bestbar-teas-ns-packet-00] 406 Saad, T. and V. Beeram, "Realizing Network Slices in IP/ 407 MPLS Networks", draft-bestbar-teas-ns-packet-00 (work in 408 progress), October 2020. 410 [I-D.draft-filsfils-spring-srv6-stateless-slice-id-01] 411 Filsfils, C., Clad, F., Camarillo, P., and K. Raza, 412 "Stateless and Scalable Network Slice Identification for 413 SRv6", draft-filsfils-spring-srv6-stateless-slice-id-01 414 (work in progress), July 2020. 416 [I-D.ietf-lsr-flex-algo] 417 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 418 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 419 algo-13 (work in progress), October 2020. 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, 423 DOI 10.17487/RFC2119, March 1997, 424 . 426 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 427 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 428 May 2017, . 430 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 431 Decraene, B., Litkowski, S., and R. Shakir, "Segment 432 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 433 July 2018, . 435 Authors' Addresses 437 Tarek Saad 438 Juniper Networks 440 Email: tsaad@juniper.net 442 Vishnu Pavan Beeram 443 Juniper Networks 445 Email: vbeeram@juniper.net