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