idnits 2.17.1 draft-ali-teas-spring-ns-building-blocks-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 1) being 87 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1 Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 10 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 11 IANA Considerations' ) ** There are 32 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([RFC8754], [RFC2475], [I-D.draft-ietf-spring-segment-routing-policy], [RFC5340], [I-D.ietf-teas-ietf-network-slices], [RFC3630], [RFC2328], [I-D.ietf-spring-segment-routing-policy], [RFC2119], [I-D.draft-filsfils-spring-srv6-stateless-slice-id], [I-D.ietf-spring-segment-routing-central-epe], [RFC7471], [I-D.draft-decraene-mpls-slid-encoded-entropy-label-id], [RFC8402], [I-D.draft-filsfils-spring-sr-policy-considerations], [I-D.draft-bashandy-rtgwg-segment-routing-ti-lfa], [RFC1195], [I-D.draft-gandhi-spring-udp-pm], [I-D.ietf-lsr-flex-algo], [I-D.draft-xuclad-spring-sr-service-chaining], [I-D.ietf-spring-segment-routing], [I-D.ietf-teas-ietf-network-slice-definition], [RFC7810], [RFC5305]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 3, 2022) is 805 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'I-D.ietf-teas-ietf-network-slice-definition' on line 543 looks like a reference -- Missing reference section? 'I-D.ietf-teas-ietf-network-slices' on line 539 looks like a reference -- Missing reference section? 'I-D.ietf-spring-segment-routing-policy' on line 548 looks like a reference -- Missing reference section? 'I-D.draft-filsfils-spring-sr-policy-considerations' on line 561 looks like a reference -- Missing reference section? 'RFC1195' on line 179 looks like a reference -- Missing reference section? 'RFC2328' on line 179 looks like a reference -- Missing reference section? 'RFC5340' on line 179 looks like a reference -- Missing reference section? 'RFC5305' on line 179 looks like a reference -- Missing reference section? 'RFC3630' on line 180 looks like a reference -- Missing reference section? 'RFC7810' on line 180 looks like a reference -- Missing reference section? 'RFC7471' on line 181 looks like a reference -- Missing reference section? 'I-D.ietf-lsr-flex-algo' on line 553 looks like a reference -- Missing reference section? 'RFC8402' on line 556 looks like a reference -- Missing reference section? 'I-D.draft-bashandy-rtgwg-segment-routing-ti-lfa' on line 332 looks like a reference -- Missing reference section? 'I-D.draft-gandhi-spring-udp-pm' on line 400 looks like a reference -- Missing reference section? 'RFC2475' on line 411 looks like a reference -- Missing reference section? 'I-D.draft-filsfils-spring-srv6-stateless-slice-id' on line 571 looks like a reference -- Missing reference section? 'RFC8754' on line 565 looks like a reference -- Missing reference section? 'I-D.draft-decraene-mpls-slid-encoded-entropy-label-id' on line 574 looks like a reference -- Missing reference section? 'RFC2119' on line 532 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Z. Ali 2 Internet-Draft C. Filsfils 3 Intended status: Informational P. Camarillo 4 Expires: August 2, 2022 Cisco Systems 5 D. Voyer 6 Bell Canada 7 S. Matsushima 8 Softbank 9 R. Rokui 10 Ciena 11 A. Dhamija 12 Rakuten 13 P. Maheshwari 14 Airtel 15 February 3, 2022 17 Building blocks for Network Slice Realization 18 in Segment Routing Network 20 draft-ali-teas-spring-ns-building-blocks-02.txt 22 Abstract 24 This document describes how to realize the IETF network slice using the 25 Segment Routing based technology. It explains how the 26 building blocks specified for the Segment Routing can be used for 27 this purpose. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 2, 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Internet-Draft Network Slice Realization in SR Network 63 Table of Contents 65 1 Introduction...................................................2 66 2 Segment Routing Policy.........................................3 67 2.1 Flex-Algorithm Based SR Policies .........................4 68 2.2 On-demand SR policy ......................................5 69 2.3 Automatic Steering .......................................6 70 2.4 Inter-domain Considerations ..............................6 71 3 TI-LFA and Microloop Avoidance.................................7 72 4 SR VPN.........................................................7 73 5 Stateless Service Programming..................................7 74 6 Operations, Administration, and Maintenance (OAM)..............8 75 7 QoS............................................................8 76 8 Stateless Network Slice Identification.........................9 77 8.1 Stateless Slice Identification in SRv6....................9 78 8.2 Stateless Slice Identification in SR-MPLS................10 79 8 IETF Network Slice Controller (NSC)...........................10 80 9 Illustration..................................................10 81 10 Security Considerations ....................................10 82 11 IANA Considerations ........................................11 83 12 References .................................................11 84 12.1 Normative References ..................................11 85 13 Acknowledgments ............................................11 86 14 Contributors ...............................................11 88 1 Introduction 90 As more and more Service Providers and Enterprises operate a 91 single network infrastructure to support an ever-increasing 92 number of services, the ability to custom fit transport to 93 application needs is critically important. This includes 94 creating network slices with different characteristics can 95 coexist on top of the shared network infrastructure. 97 Network Slicing is meant to create (end-to-end) partitioned 98 network infrastructure that can be used to provide 99 differentiated connectivity behaviors to fulfill the 100 requirements of a diverse set of services. Services belonging to 101 different Network slices can be wholly disjoint or can share 102 different parts of the network infrastructure. 104 The definition of network slice for use within the IETF and the 105 characteristics of IETF network slice are specified in 106 [I-D.ietf-teas-ietf-network-slice-definition]. A framework for 107 reusing IETF VPN and traffic-engineering technologies to realize 108 IETF network slices is discussed in 109 [I-D.ietf-teas-ietf-network-slices]. 110 These documents also discuss the function of an IETF Network Slice 111 Controller and the requirements on its northbound and southbound 112 interfaces. 114 Segment Routing enables Service Providers to support realization 115 of the Network Slicing in IP/MPLS transport network. 116 The network as a whole, in a distributed and 117 entirely automated manner, can share a single infrastructure 118 resource along multiple virtual services (slices). For example, 119 one IETF network slice is optimized continuously for low-cost 120 transport; a second one is optimized continuously for low-latency 121 transport; a third one is orchestrated to support disjoint 122 Internet-Draft Network Slice Realization in SR Network 124 services, etc. The optimization objective of each of these 125 slices is programmable by the operator. 127 The Segment Routing specification already contains the various 128 building blocks required to create network slices. This includes 129 the following. 131 . SR Policy with or without Flexible Algorithm. 132 . TI-LFA with O(50 msec) protection in the slice underlay. 133 . SR VPN. 134 . SR Service Programming (NFV, SFC). 135 . Operation, Administration and Management (OAM) and 136 Performance Management (PM). 137 . QoS using DiffServ. 138 . Stateless Network Slice Identification 139 . Orchestration at the Controller. 141 Each of these building blocks works independently of each other. 142 Their functionality can be combined to satisfy service 143 provider's requirement for the Network Slicing. An external 144 controller plays an important role to orchestrate these building 145 blocks into a Slicing service 146 (see I-D.ietf-teas-ietf-network-slice-definition]). 148 This document elaborates on the attributes of each of these 149 building blocks for Network Slicing in IP and/or MPLS underlay 150 network. The document also highlights how each IETF network Slice 151 can benefit from traffic engineering, network function 152 virtualization/ service chaining (service programming), 153 OAM, performance management, SDN readiness, O (50 msec) 154 TI-LFA protection, etc. features of SR while respecting resource 155 partitioning employed over the common networking infrastructure. 157 The document equally applicable to the SR-MPLS and SRv6 158 instantiations of segment routing. 160 The following subsection elaborates on each of these build 161 blocks. 163 2 Segment Routing Policy 165 Segment Routing (SR) allows a headend node to steer a packet 166 flow along any path without creating intermediate per-flow 167 states [I-D.ietf-spring-segment-routing-policy]. The headend 168 node steers a flow into a Segment Routing Policy (SR Policy). 169 I.e., the SR Policy can be used to steer traffic along any 170 arbitrary path in the network. This allows operators to enforce 171 low-latency and / or disjoint paths, regardless of the normal 172 forwarding paths. 174 Internet-Draft Network Slice Realization in SR Network 176 The SR policy is able to support various optimization objectives 177 [I-D.draft-filsfils-spring-sr-policy-considerations]. The 178 optimization objectives can be instantiated for the IGP metric 179 ([RFC1195] [RFC2328] [RFC5340]) xor the TE metric ([RFC5305], 180 [RFC3630]) xor the latency extended TE metric ([RFC7810] 181 [RFC7471]). In addition, an SR policy is able to various 182 constraints, including inclusion and/or exclusion of TE 183 affinity, inclusion and/or exclusion of IP address, inclusion 184 and/or exclusion of SRLG, inclusion and/or exclusion of admin- 185 tag, maximum accumulated metric (IGP, TE, and latency), maximum 186 number of SIDs in the solution SID-List, maximum number of 187 weighted SID-Lists in the solution set, diversity to another 188 service instance (e.g., link, node, or SRLG disjoint paths 189 originating from different head-ends), etc. [I-D.draft-filsfils- 190 spring-sr-policy-considerations]. The supports for various 191 optimization objectives and constraints enables SR policy to 192 create Slices in the network. 194 SR policy can be instantiated with or without IGP Flexible 195 Algorithm feature. The following subsection describes the SR 196 Flexible Algorithm feature and how SR policy can utilize this 197 feature. 199 2.1 Flex-Algorithm 201 Flexible Algorithm enriches the SR Policy solution by adding 202 additional segments having different properties than the IGP 203 Prefix segments. Flex Algo adds flexible, user-defined segments 204 to the SRTE toolbox. Specifically, it allows for association of 205 the "intent" to Prefix SIDs. [I-D.ietf-lsr-flex-algo] defines 206 the IGP based Flex-Algorithm 207 solution which allows IGPs themselves to compute paths 208 constraint by the "intent" represented by the Flex-Algorithm. 210 The Flex-Algorithm has the following attributes: 212 . Algorithm associate to the SID a specific TE intent 213 expressed as an optimization objective (an algorithm) [I- 214 D.ietf-lsr-flex-algo]. 215 . Flexibility includes the ability of network operators to 216 define the intent of each algorithm they implement. 217 . By design the mapping between the Flex-Algorithm and its 218 meaning is flexible and is defined by the user. 219 . Flexibility also includes ability for operators to make the 220 decision to exclude some specific links from the shortest 221 Internet-Draft Network Slice Realization in SR Network 223 o operator 1 may define Algo 128 to compute the shortest 224 path for TE metric and exclude red affinity links. 225 o operator 2 may define Algo 128 to compute the shortest 226 path for latency metric and exclude blue affinity 227 links. 229 An IETF Network Slice can be realized by associating of a 230 Flexible-Algorithm value with the Slice via IETF network slice 231 controller (NSC). 233 Flex Alg leverages SR on-demand next hop (ODN) and Automated 234 Steering for intent-based instantiation of traffic engineered 235 paths described in the following sub-sections. Specifically, as 236 specified in [RFC8402] the IGP Flex Algo 237 Prefix SIDs can also be used as segments within SR Policies 238 thereby leveraging the underlying IGP Flex Algo solution. 240 2.2 On-demand SR policy 242 Segment Routing On-Demand Next-hop (ODN) functionality enables 243 on-demand creation of SR Policies for service traffic. Using a 244 Path Computation Element (PCE), end-to-end SR Policy paths can 245 be computed to provide end-to-end Segment Routing connectivity, 246 even in multi-domain networks running with or without IGP 247 Flexible-Algorithm [I-D.draft-ietf-spring-segment-routing- 248 policy]. 250 The On-Demand Next-hop functionality provides optimized service 251 paths to meet customer and application SLAs (such as latency, 252 disjointness) without any pre-configured TE tunnel and with the 253 automatic steering of the service traffic on the SR Policy 254 without a static route, autoroute-announce, or policy-based 255 routing. 257 With this functionality, the IETF Network Slice Controller can 258 realize the IETF network slice based on their requirements. The 259 head-end router requests the PCE to compute the path for the 260 service and then instantiates an SR Policy with the computed 261 path and steers the service traffic into that SR Policy. If the 262 topology changes, the stateful PCE updates the SR Policy path. 263 This happens seamlessly, while TI-LFA protects the traffic in 264 case the topology change happened due to a failure. 266 Internet-Draft Network Slice Realization in SR Network 268 2.3 Automatic Steering 270 Automatically steering traffic into an IETF Network Slice is one of 271 the fundamental requirement for Slicing. That is made possible 272 by the "Automated Steering" functionality of SR. Specifically, 273 SR policy can be used for traffic engineer paths 274 within a slice, "automatically steer" traffic to the right slice 275 and connect IGP Flex-Algorithm domains sharing the same 276 "intent". 278 A headend can steer a packet flow into a valid SR Policy within 279 a slice in various ways [I-D.draft-ietf-spring-segment-routing- 280 policy]: 281 . Incoming packets have an active SID matching a local 282 Binding SID (BSID) at the headend. 283 . Per-destination Steering: incoming packets match a 284 BGP/Service route which recurses on an SR policy. 285 . Per-flow Steering: incoming packets match or recurse on a 286 forwarding array of where some of the entries are SR 287 Policies. 288 . Policy-based Steering: incoming packets match a routing 289 policy which directs them on an SR policy. 291 2.4 Inter-domain Considerations 293 The network slicing needs to be extended across multiple domains 294 such that each domain can satisfy the intent consistently. SR 295 has native inter-domain mechanisms, e.g., SR policies are 296 designed to span multiple domains using a PCE based solution [I- 297 D.ietf-spring-segment-routing], [I-D.ietf-spring-segment- 298 routing-central-epe]. An edge router upon service configuration 299 automatically requests to the Segment Routing PCE an inter- 300 domain path to the remote service endpoint. The path can either 301 be for simple best-effort inter-domain reachability or for 302 reachability with an SLA contract and can be restricted to a 303 Network Slice. 305 The SR native mechanisms for inter-domain are easily extendable 306 to include the case when different IGP Flex-Algorithm values are 307 used to represent the same intent. E.g., in domain1 Service 308 Provider 1 (SP1) may use flex-algo 128 to indicate low latency 309 Slice and in domain2 Service Provider 2 (SP2) may use flex-algo 310 129 to indicate low latency Slice. When an automation system at 311 a PE1 in SP1 network configures a service with next hop (PE2) in 312 SP2 network, SP1 contacts a Path Computation Element (PCE) to 313 find a route to PE2. In the request, the PE1 also indicates the 314 intent (i.e., the Flex-Algo 128) in the PCEP message. As the PCE 315 has a complete understanding of both Domains, it can understand 316 the path computation in Domain1 needs to be performed for 317 Internet-Draft Network Slice Realization in SR Network 319 performed for Algorithm 129 (i.e., in the Low Latency Network 320 Slice in both domains). 322 3 TI-LFA and Microloop Avoidance 324 The Segment Routing-based fast-reroute solution, TI-LFA, can 325 provide per-destination sub-50msec protection upon any single 326 link, node or SRLG failure regardless of the topology. The 327 traffic is rerouted straight to the post-convergence path, hence 328 avoiding any intermediate flap via an intermediate path. The 329 primary and backup path computation is completely automatic by 330 the IGP. 332 [I-D.draft-bashandy-rtgwg-segment-routing-ti-lfa] proposes a 333 Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), 334 aimed at protecting node and adjacency segments within O(50 335 msec) in the Segment Routing networks. Furthermore, [I-D. draft- 336 bashandy-rtgwg-segment-routing-uloop] provides a mechanism 337 leveraging Segment Routing to ensure loop-freeness during the 338 IGP reconvergence process following a link-state change event. 340 As mentioned earlier, Network Slicing in Segment Routing works 341 seamlessly with all the other components of the Segment Routing. 342 This, of course, includes TI-LFA and microloop avoidance within 343 a Slice, with the added benefit that backup path only uses 344 resources available to the Slice. For example, when Flexible 345 Algorithm is used, the TI-LFA backup path computation is 346 performed such that it is optimized per Flexible-Algorithm. The 347 backup path shares the same properties are the primary path. The 348 backup path does not use a resource outside the Slice of the 349 primary path it is protecting. 351 4 SR VPN 353 Virtual Private Networks (VPNs) provides a mean for creating a 354 logically separated network to a different set of users access 355 to a common network. Segment Routing is equipped with the rich 356 multi-service virtual private network (VPN) capabilities, 357 including Layer 3 VPN (L3VPN), Virtual Private Wire Service 358 (VPWS), Virtual Private LAN Service (VPLS), and Ethernet VPN 359 (EVPN). The ability of Segment Routing to support different VPN 360 technologies is one of the fundamental building blocks for 361 creating slicing an SR network. 363 Internet-Draft Network Slice Realization in SR Network 365 5 Stateless Service Programming 367 An important part of an IETF Network Slicing is the orchestration 368 of virtualized service containers. [I-D.draft-xuclad-spring-sr- 369 service-chaining] describes how to implement service segments 370 and achieve stateless service programming in SR-MPLS and SRv6 371 networks. It introduces the notion of service segments. The 372 ability of encoding the service segments along with the 373 topological segment enables service providers to forward packets 374 along a specific network path, but also steer them through VNFs 375 or physical service appliances available in the network. 377 In an SR network, each of the service, running either on a 378 physical appliance or in a virtual environment, is associated 379 with a segment identifier (SID) for the service. These service 380 SIDs are then leveraged as part of a SID-list to steer packets 381 through the corresponding services. Service SIDs may be 382 combined with topological SIDs to achieve service programming 383 while steering the traffic through a specific topological path 384 in the network. In this fashion, SR provides a fully integrated 385 solution for overlay, underlay and service programming building 386 blocks needed to satisfy network slicing requirements. 388 6 Operations, Administration, and Maintenance (OAM) 390 There are various OAM elements that are critical to satisfy 391 Network Slicing requirements. These includes but not limited to 392 the following: 394 . Measuring per-link TE Matric. 395 . Flooding per-link TE Matric. 396 . Taking TE Matric into account during path calculation. 397 . Taking TE Matric bound into account during path calculation. 398 . SLA Monitoring: Service Provider can monitor each SR Policy 399 in a Slice to Monitor SLA offered by the Policy using 400 technique described in [I-D.draft-gandhi-spring-udp-pm]. 401 This includes monitoring end-to-end delays on all ECMP 402 paths of the Policy as well as monitoring traffic loss on a 403 Policy. Remedial mechanisms can be used to ensure that the 404 SR policy conforms to the SLA contract. 406 7 QoS 408 Segment Routing relies on MPLS and IP Differentiated Services. 409 Differentiated services enhancements are intended to enable 410 scalable service discrimination in the Internet without the need 411 for per-flow state and signaling at every hop. [RFC2475] defines 412 Internet-Draft Network Slice Realization in SR Network 414 an architecture for implementing scalable service 415 differentiation in the Internet. This architecture is composed 416 of many functional elements implemented in network nodes, 417 including a small set of per-hop forwarding behaviors, packet 418 classification functions, and traffic conditioning functions 419 including metering, marking, shaping, and policing. 421 The DiffServ architecture achieves scalability by implementing 422 complex classification and conditioning functions only at 423 network boundary nodes, and by applying per-hop behaviors to 424 aggregates of traffic depending on the traffic marker. 425 Specifically, the node at the ingress of the DiffServ domain 426 conditions, classifies and marks the traffic into a limited 427 number of traffic classes. The function is used to ensure that 428 the slice's traffic conforms to the contract associated with the 429 slice. 431 Per-hop behaviors are defined to permit a reasonably granular 432 means of allocating buffer and bandwidth resources at each node 433 among competing traffic streams. Specifically, per class 434 scheduling and queuing control mechanisms are applied at each IP 435 hop to the traffic classes depending on packet's marking. 436 Techniques such as queue management and a variety of scheduling 437 mechanisms are used to get the required packet behavior to meet 438 the slice's SLA. 440 8 Stateless Network Slice Identification 442 Some use-cases require a slice identifier (SLID) in the packet 443 to provide differentiated treatment of the packets belonging 444 to different network slices. 446 The network slice instantiation using the SLID in the packet 447 is required to work with the building blocks described in the 448 previous sections. For example, the QoS/ DiffServ needs to be 449 observed on a per slice basis. The slice identification needs 450 to be topologically independent and stateless. 452 8.1 Stateless Slice Identification in SRv6 454 [I-D.draft-filsfils-spring-srv6-stateless-slice-id] describes 455 a stateless encoding of slice identification in the outer IPv6 456 the header of an SRv6 domain. As defined in RFC8754 [RFC8754], 457 when an ingress PE receives a packet that traverses the SR domain, 458 it encapsulates the packet in an outer IPv6 header and an optional 459 SRH. Based on a local policy of the SR domain, the Flow Label field 460 of the outer IPv6 header carries the SLID. Specifically, the SLID 461 is added in the 8 most significant bits of the Flow Label field 462 of the outer IPv6 header. The remaining 12 bits of the Flow Label 463 field are set as described in section 5.5 of [RFC8754] for 464 inter-domain packets. Based on the local policy of the SR domain, 465 the draft also uses one of the bits in the Traffic Class field of 466 the outer IPv6 header to indicate that the entropy label contains 467 the SLID. 469 The network slicing mechanism described in 470 [I-D.draft-filsfils-spring-srv6-stateless-slice-id] works seamlessly 471 with the building blocks described in the previous sections. For 472 example, the slice identification is independent of topology and 473 the network's QoS/DiffServ policy. It enables scalable network 474 slicing for SRv6 overlays. 476 8.2 Stateless Slice Identification in SR-MPLS 478 [I-D.draft-decraene-mpls-slid-encoded-entropy-label-id] describes a 479 similar stateless encoding of slice identification in the SR-MPLS domain. 480 Specifically, the document extends the use of the Entropy Label to carry 481 the SLID. The number of bits to be used for encoding the SLID in the 482 Entropy Label is governed by a local policy of the SR domain. Based on 483 the local policy of the SR domain, the draft uses one of the bits in the 484 TTL field of the Entropy Label to indicate that the Entropy Label contains 485 the SLID. 487 The network slicing mechanism described in 488 [I-D.draft-decraene-mpls-slid-encoded-entropy-label-id] works seamlessly 489 with the building blocks described in the previous sections. For 490 example, the slice identification is independent of topology and 491 the network's QoS/DiffServ policy. It enables scalable network 492 slicing for SR-MPLS overlays. 494 Internet-Draft Network Slice Realization in SR Network 496 8 IETF Network Slice Controller (NSC) 498 The role of IETF Network Slice Controller (NSC) is described in 499 I-D.ietf-teas-ietf-network-slice-definition]. 500 It plays a vital role in realization the IETF network slice 501 using the SR building blocks discussed above. The NSC also 502 performs admission control and traffic placement for slice 503 management at the transport layer. 505 The SDN friendliness of the SR technology becomes handy to realize the 506 orchestration. The controller may use PCEP or Netconf to interact with 507 the routers. The router implements Yang model for SR-based network 508 slicing. 510 Specification of the controller technology for orchestrating 511 Network Slices, services and admission control for the services 512 is outside the scope of this draft. 514 9 Illustration 516 To be added in a later revision. 518 10 Security Considerations 520 This document does not impose any additional security 521 Internet-Draft Network Slice Realization in SR Network 523 11 IANA Considerations 525 This document does not define any new protocol or any extension 526 to an existing protocol. 528 12 References 530 12.1 Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, 534 DOI 10.17487/RFC2119, March 1997, 535 . 537 7.2. Informative References 539 [I-D.ietf-teas-ietf-network-slices] Farrel, A., et al, 540 "Framework for IETF Network Slices", 541 draft-ietf-teas-ietf-network-slices (work in progress) 543 [I-D.ietf-teas-ietf-network-slice-definition] Rokui, R. et al, 544 "Definition of IETF Network Slices", 545 draft-ietf-teas-ietf-network-slice-definition 546 (work in progress). 548 [I-D.ietf-spring-segment-routing-policy] 549 Filsfils, C., Sivabalan, et al, "Segment Routing Policy 550 For Traffic Engineering", draft-ietf-spring-segment- 551 routing-policy (work in progress). 553 [I-D.ietf-lsr-flex-algo] P. Psenak, et al, 554 draft-ietf-lsr-flex-algo, work in progress. 556 [RFC8402] 557 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 558 Litkowski, S., and R. Shakir, "Segment Routing 559 Architecture", RFC8402. 561 [I-D.draft-filsfils-spring-sr-policy-considerations] 562 Filsfils, C., et al. draft-filsfils-spring-sr-policy- 563 considerations (work in progress) 565 [RFC8754] 566 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 567 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 568 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 569 progress), February 2019. 571 [I-D.draft-filsfils-spring-srv6-stateless-slice-id] Filsfils, C., et al. 572 draft-filsfils-spring-srv6-stateless-slice-id, work in progress. 574 [I-D.draft-decraene-mpls-slid-encoded-entropy-label-id] Decraene B., 575 Filsfils, C., Henderickx W., Saad T., Beeram V., 576 work in progress. 578 13 Acknowledgments 580 14 Contributors 581 Francois Clad 582 Cisco Systems, Inc. 583 fclad@cisco.com 584 Internet-Draft Network Slice Realization in SR Network 586 Authors' Addresses 588 Zafar Ali 589 Cisco Systems, Inc. 590 Email: zali@cisco.com 592 Clarence Filsfils 593 Cisco Systems, Inc. 595 Pablo Camarillo Garvia 596 Cisco Systems, Inc. 598 Daniel Voyer 599 Bell Canada 600 Email: daniel.voyer@bell.ca 602 Satoru Matsushima 603 Softbank 604 Email: satoru.matsushima@g.softbank.co.jp 606 Reza Rokui 607 Ciena 608 Canada 609 Email: rrokui@Ciena.com 611 Amit Dhamija 612 Rakuten 613 Email: amit.dhamija@rakuten.com 615 Praveen Maheshwari 616 Airtel 617 Email: Praveen.Maheshwari@airtel.com