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