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