idnits 2.17.1 draft-ali-spring-network-slicing-building-blocks-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 20 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([I-D.draft-ietf-spring-segment-routing-policy], [RFC5340], [RFC3630], [RFC2328], [I-D.ietf-spring-segment-routing-policy], [3GPP23501], [I-D.ietf-spring-segment-routing-central-epe], [RFC7471], [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 (November 16, 2020) is 1250 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 91 looks like a reference -- Missing reference section? 'I-D.ietf-spring-segment-routing-policy' on line 446 looks like a reference -- Missing reference section? 'I-D.draft-filsfils-spring-sr-policy-considerations' on line 459 looks like a reference -- Missing reference section? 'RFC1195' on line 154 looks like a reference -- Missing reference section? 'RFC2328' on line 154 looks like a reference -- Missing reference section? 'RFC5340' on line 154 looks like a reference -- Missing reference section? 'RFC5305' on line 154 looks like a reference -- Missing reference section? 'RFC3630' on line 155 looks like a reference -- Missing reference section? 'RFC7810' on line 155 looks like a reference -- Missing reference section? 'RFC7471' on line 156 looks like a reference -- Missing reference section? 'I-D.ietf-lsr-flex-algo' on line 451 looks like a reference -- Missing reference section? 'RFC8402' on line 454 looks like a reference -- Missing reference section? 'I-D.draft-bashandy-rtgwg-segment-routing-ti-lfa' on line 306 looks like a reference -- Missing reference section? 'I-D.draft-gandhi-spring-udp-pm' on line 373 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 15 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: May 16, 2021 Cisco Systems 5 D. Voyer 6 Bell Canada 7 November 16, 2020 9 Building blocks for Slicing in Segment Routing Network 10 draft-ali-spring-network-slicing-building-blocks-03.txt 12 Abstract 14 This document describes how to build network slice using the 15 Segment Routing based technology. It explains how the existing 16 building blocks specified for the Segment Routing can be used for 17 this purpose. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 16, 2021. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Internet-Draft Network Slicing Using SR 53 Table of Contents 55 1 Introduction...................................................2 56 2 Segment Routing Policy.........................................3 57 2.1 Flex-Algorithm Based SR Policies .........................4 58 2.2 On-demand SR policy ......................................5 59 2.3 Automatic Steering .......................................6 60 2.4 Inter-domain Considerations ..............................6 61 3 TI-LFA and Microloop Avoidance.................................7 62 4 SR VPN.........................................................7 63 5 Stateless Service Programming..................................7 64 6 Operations, Administration, and Maintenance (OAM)..............8 65 7 QoS............................................................8 66 8 Orchestration at the Controller................................9 67 9 Illustration...................................................9 68 10 Security Considerations .....................................9 69 11 IANA Considerations ........................................10 70 12 References .................................................10 71 12.1 Normative References ..................................10 72 7.2...........................................................10 73 13 Acknowledgments ............................................10 74 14 Contributors ...............................................10 76 1 Introduction 78 As more and more Service Providers and Enterprises operate a 79 single network infrastructure to support an ever-increasing 80 number of services, the ability to custom fit transport to 81 application needs is critically important. This includes 82 creating network slices with different characteristics can 83 coexist on top of the shared network infrastructure. 85 Network Slicing is meant to create (end-to-end) partitioned 86 network infrastructure that can be used to provide 87 differentiated connectivity behaviors to fulfill the 88 requirements of a diverse set of services. Services belonging to 89 different Network slices can be wholly disjoint or can share 90 different parts of the network infrastructure. Network Slicing 91 is one of the requirements in 5G [3GPP 23501]. 93 Segment Routing enables Service Providers to support Network 94 Slicing without any additional protocol, other than the SR IGP 95 extensions. The network as a whole, in a distributed and 96 entirely automated manner, can share a single infrastructure 97 resource along multiple virtual services (slices). For example, 98 one slice is optimized continuously for low-cost transport; a 99 second Slice is optimized continuously for low-latency 100 Internet-Draft Network Slicing Using SR 102 services, etc. The optimization objective of each of these 103 slices is programmable by the operator. 105 The Segment Routing specification already contains the various 106 building blocks required to create network slices. This includes 107 the following. 109 . SR Policy with or without Flexible Algorithm. 110 . TI-LFA with O(50 msec) protection in the slice underlay. 111 . SR VPN. 112 . SR Service Programming (NFV, SFC). 113 . Operation, Administration and Management (OAM) and 114 Performance Management (PM). 115 . QoS using DiffServ. 116 . Orchestration at the Controller. 118 Each of these building blocks works independently of each other. 119 Their functionality can be combined to satisfy service 120 provider's requirement for the Network Slicing. An external 121 controller plays an important role to orchestrate these building 122 blocks into a Slicing service. 124 This document elaborates on the attributes of each of these 125 building blocks for Network Slicing. The document also highlights 126 how services in each Slice can benefit from traffic engineering, 127 network function virtualization/ service chaining (service 128 programming), OAM, performance management, SDN readiness, O (50 msec) 129 TI-LFA protection, etc. features of SR while respecting resource 130 partitioning employed over the common networking infrastructure. 132 The document equally applicable to the MPLS and SRv6 133 instantiations of segment routing. 135 The following subsection elaborates on each of these build 136 blocks. 138 2 Segment Routing Policy 140 Segment Routing (SR) allows a headend node to steer a packet 141 flow along any path without creating intermediate per-flow 142 states [I-D.ietf-spring-segment-routing-policy]. The headend 143 node steers a flow into a Segment Routing Policy (SR Policy). 144 I.e., the SR Policy can be used to steer traffic along any 145 arbitrary path in the network. This allows operators to enforce 146 low-latency and / or disjoint paths, regardless of the normal 147 forwarding paths. 149 Internet-Draft Network Slicing Using SR 151 The SR policy is able to support various optimization objectives 152 [I-D.draft-filsfils-spring-sr-policy-considerations]. The 153 optimization objectives can be instantiated for the IGP metric 154 ([RFC1195] [RFC2328] [RFC5340]) xor the TE metric ([RFC5305], 155 [RFC3630]) xor the latency extended TE metric ([RFC7810] 156 [RFC7471]). In addition, an SR policy is able to various 157 constraints, including inclusion and/or exclusion of TE 158 affinity, inclusion and/or exclusion of IP address, inclusion 159 and/or exclusion of SRLG, inclusion and/or exclusion of admin- 160 tag, maximum accumulated metric (IGP, TE, and latency), maximum 161 number of SIDs in the solution SID-List, maximum number of 162 weighted SID-Lists in the solution set, diversity to another 163 service instance (e.g., link, node, or SRLG disjoint paths 164 originating from different head-ends), etc. [I-D.draft-filsfils- 165 spring-sr-policy-considerations]. The supports for various 166 optimization objectives and constraints enables SR policy to 167 create Slices in the network. 169 SR policy can be instantiated with or without IGP Flexible 170 Algorithm feature. The following subsection describes the SR 171 Flexible Algorithm feature and how SR policy can utilize this 172 feature. 174 2.1 Flex-Algorithm Based SR Policies 176 Flexible Algorithm enriches the SR Policy solution by adding 177 additional segments having different properties than the IGP 178 Prefix segments. Flex Algo adds flexible, user-defined segments 179 to the SRTE toolbox. Specifically, it allows for association of 180 the "intent" to Prefix SIDs. [I-D.ietf-lsr-flex-algo] defines 181 the IGP based Flex-Algorithm 182 solution which allows IGPs themselves to compute paths 183 constraint by the "intent" represented by the Flex-Algorithm. 185 The Flex-Algorithm has the following attributes: 187 . Algorithm associate to the SID a specific TE intent 188 expressed as an optimization objective (an algorithm) [I- 189 D.ietf-lsr-flex-algo]. 190 . Flexibility includes the ability of network operators to 191 define the intent of each algorithm they implement. 192 . By design the mapping between the Flex-Algorithm and its 193 meaning is flexible and is defined by the user. 194 . Flexibility also includes ability for operators to make the 195 decision to exclude some specific links from the shortest 196 Internet-Draft Network Slicing Using SR 198 o operator 1 may define Algo 128 to compute the shortest 199 path for TE metric and exclude red affinity links. 200 o operator 2 may define Algo 128 to compute the shortest 201 path for latency metric and exclude blue affinity 202 links. 204 A Network Slice can be created by associating a Flexible- 205 Algorithm value with the Slice via provisioning. 207 Flex Alg leverages SR on-demand next hop (ODN) and Automated 208 Steering for intent-based instantiation of traffic engineered 209 paths described in the following sub-sections. Specifically, as 210 specified in [RFC8402] the IGP Flex Algo 211 Prefix SIDs can also be used as segments within SR Policies 212 thereby leveraging the underlying IGP Flex Algo solution. 214 2.2 On-demand SR policy 216 Segment Routing On-Demand Next-hop (ODN) functionality enables 217 on-demand creation of SR Policies for service traffic. Using a 218 Path Computation Element (PCE), end-to-end SR Policy paths can 219 be computed to provide end-to-end Segment Routing connectivity, 220 even in multi-domain networks running with or without IGP 221 Flexible-Algorithm [I-D.draft-ietf-spring-segment-routing- 222 policy]. 224 The On-Demand Next-hop functionality provides optimized service 225 paths to meet customer and application SLAs (such as latency, 226 disjointness) without any pre-configured TE tunnel and with the 227 automatic steering of the service traffic on the SR Policy 228 without a static route, autoroute-announce, or policy-based 229 routing. 231 With this functionality, a Network Service Orchestrator can 232 deploy the service based on their requirements. The service 233 head-end router requests the PCE to compute the path for the 234 service and then instantiates an SR Policy with the computed 235 path and steers the service traffic into that SR Policy. If the 236 topology changes, the stateful PCE updates the SR Policy path. 237 This happens seamlessly, while TI-LFA protects the traffic in 238 case the topology change happened due to a failure. 240 Internet-Draft Network Slicing Using SR 242 2.3 Automatic Steering 244 Automatically steering traffic into a Network Slice is one of 245 the fundamental requirement for Slicing. That is made possible 246 by the "Automated Steering" functionality of SR. Specifically, 247 SR policy can be used for traffic engineer paths 248 within a slice, "automatically steer" traffic to the right slice 249 and connect IGP Flex-Algorithm domains sharing the same 250 "intent". 252 A headend can steer a packet flow into a valid SR Policy within 253 a slice in various ways [I-D.draft-ietf-spring-segment-routing- 254 policy]: 255 . Incoming packets have an active SID matching a local 256 Binding SID (BSID) at the headend. 257 . Per-destination Steering: incoming packets match a 258 BGP/Service route which recurses on an SR policy. 259 . Per-flow Steering: incoming packets match or recurse on a 260 forwarding array of where some of the entries are SR 261 Policies. 262 . Policy-based Steering: incoming packets match a routing 263 policy which directs them on an SR policy. 265 2.4 Inter-domain Considerations 267 The network slicing needs to be extended across multiple domains 268 such that each domain can satisfy the intent consistently. SR 269 has native inter-domain mechanisms, e.g., SR policies are 270 designed to span multiple domains using a PCE based solution [I- 271 D.ietf-spring-segment-routing], [I-D.ietf-spring-segment- 272 routing-central-epe]. An edge router upon service configuration 273 automatically requests to the Segment Routing PCE an inter- 274 domain path to the remote service endpoint. The path can either 275 be for simple best-effort inter-domain reachability or for 276 reachability with an SLA contract and can be restricted to a 277 Network Slice. 279 The SR native mechanisms for inter-domain are easily extendable 280 to include the case when different IGP Flex-Algorithm values are 281 used to represent the same intent. E.g., in domain1 Service 282 Provider 1 (SP1) may use flex-algo 128 to indicate low latency 283 Slice and in domain2 Service Provider 2 (SP2) may use flex-algo 284 129 to indicate low latency Slice. When an automation system at 285 a PE1 in SP1 network configures a service with next hop (PE2) in 286 SP2 network, SP1 contacts a Path Computation Element (PCE) to 287 find a route to PE2. In the request, the PE1 also indicates the 288 intent (i.e., the Flex-Algo 128) in the PCEP message. As the PCE 289 has a complete understanding of both Domains, it can understand 290 the path computation in Domain1 needs to be performed for 291 Internet-Draft Network Slicing Using SR 293 performed for Algorithm 129 (i.e., in the Low Latency Network 294 Slice in both domains). 296 3 TI-LFA and Microloop Avoidance 298 The Segment Routing-based fast-reroute solution, TI-LFA, can 299 provide per-destination sub-50msec protection upon any single 300 link, node or SRLG failure regardless of the topology. The 301 traffic is rerouted straight to the post-convergence path, hence 302 avoiding any intermediate flap via an intermediate path. The 303 primary and backup path computation is completely automatic by 304 the IGP. 306 [I-D.draft-bashandy-rtgwg-segment-routing-ti-lfa] proposes a 307 Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), 308 aimed at protecting node and adjacency segments within O(50 309 msec) in the Segment Routing networks. Furthermore, [I-D. draft- 310 bashandy-rtgwg-segment-routing-uloop] provides a mechanism 311 leveraging Segment Routing to ensure loop-freeness during the 312 IGP reconvergence process following a link-state change event. 314 As mentioned earlier, Network Slicing in Segment Routing works 315 seamlessly with all the other components of the Segment Routing. 316 This, of course, includes TI-LFA and microloop avoidance within 317 a Slice, with the added benefit that backup path only uses 318 resources available to the Slice. For example, when Flexible 319 Algorithm is used, the TI-LFA backup path computation is 320 performed such that it is optimized per Flexible-Algorithm. The 321 backup path shares the same properties are the primary path. The 322 backup path does not use a resource outside the Slice of the 323 primary path it is protecting. 325 4 SR VPN 327 Virtual Private Networks (VPNs) provides a mean for creating a 328 logically separated network to a different set of users access 329 to a common network. Segment Routing is equipped with the rich 330 multi-service virtual private network (VPN) capabilities, 331 including Layer 3 VPN (L3VPN), Virtual Private Wire Service 332 (VPWS), Virtual Private LAN Service (VPLS), and Ethernet VPN 333 (EVPN). The ability of Segment Routing to support different VPN 334 technologies is one of the fundamental building blocks for 335 creating slicing an SR network. 337 5 Stateless Service Programming 338 Internet-Draft Network Slicing Using SR 340 An important part of the Network Slicing is the orchestration of 341 virtualized service containers. [I-D.draft-xuclad-spring-sr- 342 service-chaining] describes how to implement service segments 343 and achieve stateless service programming in SR-MPLS and SRv6 344 networks. It introduces the notion of service segments. The 345 ability of encoding the service segments along with the 346 topological segment enables service providers to forward packets 347 along a specific network path, but also steer them through VNFs 348 or physical service appliances available in the network. 350 In an SR network, each of the service, running either on a 351 physical appliance or in a virtual environment, is associated 352 with a segment identifier (SID) for the service. These service 353 SIDs are then leveraged as part of a SID-list to steer packets 354 through the corresponding services. Service SIDs may be 355 combined with topological SIDs to achieve service programming 356 while steering the traffic through a specific topological path 357 in the network. In this fashion, SR provides a fully integrated 358 solution for overlay, underlay and service programming building 359 blocks needed to satisfy network slicing requirements. 361 6 Operations, Administration, and Maintenance (OAM) 363 There are various OAM elements that are critical to satisfy 364 Network Slicing requirements. These includes but not limited to 365 the following: 367 . Measuring per-link TE Matric. 368 . Flooding per-link TE Matric. 369 . Taking TE Matric into account during path calculation. 370 . Taking TE Matric bound into account during path calculation. 371 . SLA Monitoring: Service Provider can monitor each SR Policy 372 in a Slice to Monitor SLA offered by the Policy using 373 technique described in [I-D.draft-gandhi-spring-udp-pm]. 374 This includes monitoring end-to-end delays on all ECMP 375 paths of the Policy as well as monitoring traffic loss on a 376 Policy. Remedial mechanisms can be used to ensure that the 377 SR policy conforms to the SLA contract. 379 7 QoS 381 Segment Routing relies on MPLS and IP Differentiated Services. 382 Differentiated services enhancements are intended to enable 383 scalable service discrimination in the Internet without the need 384 Internet-Draft Network Slicing Using SR 386 an architecture for implementing scalable service 387 differentiation in the Internet. This architecture is composed 388 of many functional elements implemented in network nodes, 389 including a small set of per-hop forwarding behaviors, packet 390 classification functions, and traffic conditioning functions 391 including metering, marking, shaping, and policing. 393 The DiffServ architecture achieves scalability by implementing 394 complex classification and conditioning functions only at 395 network boundary nodes, and by applying per-hop behaviors to 396 aggregates of traffic depending on the traffic marker. 397 Specifically, the node at the ingress of the DiffServ domain 398 conditions, classifies and marks the traffic into a limited 399 number of traffic classes. The function is used to ensure that 400 the slice's traffic conforms to the contract associated with the 401 slice. 403 Per-hop behaviors are defined to permit a reasonably granular 404 means of allocating buffer and bandwidth resources at each node 405 among competing traffic streams. Specifically, per class 406 scheduling and queuing control mechanisms are applied at each IP 407 hop to the traffic classes depending on packet's marking. 408 Techniques such as queue management and a variety of scheduling 409 mechanisms are used to get the required packet behavior to meet 410 the slice's SLA. 412 8 Orchestration at the Controller 414 A controller plays a vital role in orchestrating the SR building 415 blocks discussed above to create Network Slices. The controller also 416 performs admission control and traffic placement for slice 417 management at the transport layer. The SDN friendliness of the 418 SR technology becomes handy to realize the orchestration. The 419 controller may use PCEP or Netconf to interact with the routers. 420 The router implements Yang model for SR-based network slicing. 422 Specification of the controller technology for orchestrating 423 Network Slices, services and admission control for the services 424 is outside the scope of this draft. 426 9 Illustration 428 To be added in a later revision. 430 10 Security Considerations 432 This document does not impose any additional security 433 Internet-Draft Network Slicing Using SR 435 11 IANA Considerations 437 This document does not define any new protocol or any extension 438 to an existing protocol. 440 12 References 442 12.1 Normative References 444 7.2. Informative References 446 [I-D.ietf-spring-segment-routing-policy] 447 Filsfils, C., Sivabalan, et al, "Segment Routing Policy 448 For Traffic Engineering", draft-ietf-spring-segment- 449 routing-policy (work in progress). 451 [I-D.ietf-lsr-flex-algo] P. Psenak, et al, 452 draft-ietf-lsr-flex-algo, work in progress. 454 [RFC8402] 455 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 456 Litkowski, S., and R. Shakir, "Segment Routing 457 Architecture", RFC8402. 459 [I-D.draft-filsfils-spring-sr-policy-considerations] 460 Filsfils, C., et al. draft-filsfils-spring-sr-policy- 461 considerations (work in progress) 463 13 Acknowledgments 465 14 Contributors 466 Internet-Draft Network Slicing Using SR 468 Authors' Addresses 470 Zafar Ali 471 Cisco Systems, Inc. 472 Email: zali@cisco.com 474 Clarence Filsfils 475 Cisco Systems, Inc. 477 Pablo Camarillo Garvia 478 Cisco Systems, Inc. 480 Daniel Voyer 481 Bell Canada 482 Email: daniel.voyer@bell.ca