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