idnits 2.17.1 draft-ietf-sfc-problem-statement-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 11, 2014) is 3540 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Quinn, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational T. Nadeau, Ed. 5 Expires: February 12, 2015 Brocade 6 August 11, 2014 8 Service Function Chaining Problem Statement 9 draft-ietf-sfc-problem-statement-10.txt 11 Abstract 13 This document provides an overview of the issues associated with the 14 deployment of service functions (such as firewalls, load balancers) 15 in large-scale environments. The term service function chaining is 16 used to describe the definition and instantiation of an ordered set 17 of instances of such service functions, and the subsequent "steering" 18 of traffic flows through those service functions. 20 The set of enabled service function chains reflect operator service 21 offerings and is designed in conjunction with application delivery 22 and service and network policy. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 12, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 60 2. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Topological Dependencies . . . . . . . . . . . . . . . . . 5 62 2.2. Configuration complexity . . . . . . . . . . . . . . . . . 5 63 2.3. Constrained High Availability . . . . . . . . . . . . . . 6 64 2.4. Consistent Ordering of Service Functions . . . . . . . . . 6 65 2.5. Application of Service Policy . . . . . . . . . . . . . . 6 66 2.6. Transport Dependence . . . . . . . . . . . . . . . . . . . 7 67 2.7. Elastic Service Delivery . . . . . . . . . . . . . . . . . 7 68 2.8. Traffic Selection Criteria . . . . . . . . . . . . . . . . 7 69 2.9. Limited End-to-End Service Visibility . . . . . . . . . . 7 70 2.10. Per-Service Function (re)Classification . . . . . . . . . 7 71 2.11. Symmetric Traffic Flows . . . . . . . . . . . . . . . . . 8 72 2.12. Multi-vendor Service Functions . . . . . . . . . . . . . . 8 73 3. Service Function Chaining . . . . . . . . . . . . . . . . . . 9 74 3.1. Service Overlay . . . . . . . . . . . . . . . . . . . . . 9 75 3.2. Service Classification . . . . . . . . . . . . . . . . . . 9 76 3.3. Dataplane Metadata . . . . . . . . . . . . . . . . . . . . 9 77 4. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 11 78 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 83 10. Informative References . . . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 The delivery of end-to-end services often require various service 89 functions including traditional network service functions (for 90 example firewalls and server load balancers), as well as application- 91 specific features. Service functions may be delivered within the 92 context of an isolated user group, or shared amongst many users/user 93 groups. 95 Current service function deployment models are relatively static in 96 that they are tightly coupled to network topology and physical 97 resources. The result of that static nature of existing deployments 98 greatly reduces, and in many cases, limits the ability of an operator 99 to introduce new services and/or service functions. Furthermore 100 there is a cascading effect: service changes affect other services. 102 This document outlines the problems encountered with existing service 103 deployment models for Service Function Chaining (SFC) (often referred 104 to simply as service chaining; in this document the terms will be 105 used interchangeably), as well as the problems of service chain 106 creation, deletion, modification/update, policy integration with 107 service chains, and policy enforcement within the network 108 infrastructure. 110 1.1. Definition of Terms 112 Classification: Locally instantiated policy that results in matching 113 of traffic flows for identification of appropriate outbound 114 forwarding actions. 116 Network Overlay: A logical network built, via virtual links or 117 packet encapsulation, over an existing network (the underlay). 119 Network Service: An offering provided by an operator that is 120 delivered using one or more service functions. This may also be 121 referred to as a composite service. The term "service" is used to 122 denote a "network service" in the context of this document. 124 Service Function: A function that is responsible for specific 125 treatment of received packets. A Service Function can act at the 126 network layer or other OSI layers. A Service Function can be a 127 virtual instance or be embedded in a physical network element. 128 One of multiple Service Functions can be embedded in the same 129 network element. Multiple instances of the Service Function can 130 be enabled in the same administrative domain. 132 A non-exhaustive list of Service Functions includes: firewalls, 133 WAN and application acceleration, Deep Packet Inspection (DPI), 134 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 135 injection [RFC6967], HTTP Header Enrichment functions, TCP 136 optimizer, etc. 138 The generic term "L4-L7 services" is often used to describe many 139 service functions. 141 Service Function Chain (SFC): A service Function chain defines an 142 abstract set of service functions and their ordering constraints 143 that must be applied to packets and/or frames selected as a result 144 of classification. The implied order may not be a linear 145 progression as the architecture allows for nodes that copy to more 146 than one branch, and also allows for cases where there is 147 flexibility in the order in which services need to be applied. 148 The term service chain is often used as shorthand for service 149 function chain. 151 Service Overlay: An overlay network created for the purpose of 152 forwarding data to required service functions. 154 Service Topology: The service overlay connectivity forms a service 155 topology. 157 2. Problem Space 159 The following points describe aspects of existing service deployments 160 that are problematic, and that the Service Function Chaining (SFC) 161 working group aims to address. 163 2.1. Topological Dependencies 165 Network service deployments are often coupled to network topology, 166 whether it be physical or virtualized, or a hybrid of the two. Such 167 dependency imposes constraints on the service delivery, potentially 168 inhibiting the network operator from optimally utilizing service 169 resources, and reduces the flexibility. This limits scale, capacity, 170 and redundancy across network resources. 172 These topologies serve only to "insert" the service function (i.e., 173 ensure that traffic traverses a service function); they are not 174 required from a native packet delivery perspective. For example, 175 firewalls often require an "in" and "out" layer-2 segment and adding 176 a new firewall requires changing the topology (i.e., adding new 177 layer-2 segments). 179 As more service functions are required - often with strict ordering - 180 topology changes are needed before and after each service function 181 resulting in complex network changes and device configuration. In 182 such topologies, all traffic, whether a service function needs to be 183 applied or not, often passes through the same strict order. 185 The topological coupling limits placement and selection of service 186 functions: service functions are "fixed" in place by topology and 187 therefore placement and service function selection taking into 188 account network topology information is not viable. Furthermore, 189 altering the services traversed, or their order, based on flow 190 direction is not possible. 192 A common example is web servers using a server load balancer as the 193 default gateway. When the web service responds to non-load balanced 194 traffic (e.g., administrative or backup operations) all traffic from 195 the server must traverse the load balancer forcing network 196 administrators to create complex routing schemes or create additional 197 interfaces to provide an alternate topology. 199 2.2. Configuration complexity 201 A direct consequence of topological dependencies is the complexity of 202 the entire configuration, specifically in deploying service function 203 chains. Simple actions such as changing the order of the service 204 functions in a service function chain require changes to the 205 topology. Changes to the topology are avoided by the network 206 operator once installed, configured and deployed in production 207 environments for fear of misconfiguration and consequent downtime. 208 All of this leads to very static service delivery deployments. 209 Furthermore, the speed at which these topological changes can be made 210 is not rapid or dynamic enough as it often requires manual 211 intervention, or use of slow provisioning systems. 213 2.3. Constrained High Availability 215 An effect of topological dependency is constrained service function 216 high availability. Worse, when modified, inadvertent non-high 217 availability or downtime can result. 219 Since traffic reaches many service functions based on network 220 topology, alternate, or redundant service functions must be placed in 221 the same topology as the primary service. 223 2.4. Consistent Ordering of Service Functions 225 Service functions are typically independent; service function_1 226 (SF1)...service function_n (SFn) are unrelated and there is no notion 227 at the service layer that SF1 occurs before SF2. However, to an 228 administrator many service functions have a strict ordering that must 229 be in place, yet the administrator has no consistent way to impose 230 and verify the ordering of the service functions that are used to 231 deliver a given service. 233 Service function chains today are most typically built through manual 234 configuration processes. These are slow and error prone. With the 235 advent of newer service deployment models the control and policy 236 planes provide not only connectivity state, but will also be 237 increasingly utilized for the creation of network services. Such 238 control/management planes could be centralized, or be distributed. 240 2.5. Application of Service Policy 242 Service functions rely on topology information such as VLANs or 243 packet (re) classification to determine service policy selection, 244 i.e. the service function specific action taken. Topology 245 information is increasingly less viable due to scaling, tenancy and 246 complexity reasons. The topological information is often stale, 247 providing the operator with inaccurate placement that can result in 248 suboptimal resource utilization. Furthermore topology-centric 249 information often does not convey adequate information to the service 250 functions, forcing functions to individually perform more granular 251 classification. 253 2.6. Transport Dependence 255 Service functions can and will be deployed in networks with a range 256 of transports, including under and overlays. The coupling of service 257 functions to topology requires service functions to support many 258 transport encapsulations or for a transport gateway function to be 259 present. 261 2.7. Elastic Service Delivery 263 Given that the current state of the art for adding/removing service 264 functions largely centers around VLANs and routing changes, rapid 265 changes to the service deployment can be hard to realize due to the 266 risk and complexity of such changes. 268 2.8. Traffic Selection Criteria 270 Traffic selection is coarse, that is, all traffic on a particular 271 segment traverse service functions whether the traffic requires 272 service enforcement or not. This lack of traffic selection is 273 largely due to the topological nature of service deployment since the 274 forwarding topology dictates how (and what) data traverses service 275 function(s). In some deployments, more granular traffic selection is 276 achieved using policy routing or access control filtering. This 277 results in operationally complex configurations and is still 278 relatively inflexible. 280 2.9. Limited End-to-End Service Visibility 282 Troubleshooting service related issues is a complex process that 283 involve both network-specific and service-specific expertise. This 284 is especially the case when service function chains span multiple 285 DCs, or across administrative boundaries. Furthermore, the physical 286 and virtual environments (network and service), can be highly 287 divergent in terms of topology and that topological variance adds to 288 these challenges. 290 2.10. Per-Service Function (re)Classification 292 Classification occurs at each service function independent from 293 previously applied service functions. More importantly, the 294 classification functionality often differs per service function and 295 service functions may not leverage the results from other service 296 functions. 298 2.11. Symmetric Traffic Flows 300 Service function chains may be unidirectional or bidirectional 301 depending on the state requirements of the service functions. In a 302 unidirectional chain traffic is passed through a set of service 303 functions in one forwarding direction only. Bidirectional chains 304 require traffic to be passed through a set of service functions in 305 both forwarding directions. Many common service functions such as 306 DPI and firewall often require bidirectional chaining in order to 307 ensure flow state is consistent. 309 Existing service deployment models provide a static approach to 310 realizing forward and reverse service function chain association most 311 often requiring complex configuration of each network device 312 throughout the SFC. 314 2.12. Multi-vendor Service Functions 316 Deploying service functions from multiple vendors often require per- 317 vendor expertise: insertion models differ, there are limited common 318 attributes and inter-vendor service functions do not share 319 information. 321 3. Service Function Chaining 323 Service Function Chaining aims to address the aforementioned problems 324 associated with service deployment. Concretely, the SFC working 325 group will investigate solutions that address the following elements: 327 3.1. Service Overlay 329 Service function chaining utilizes a service specific overlay that 330 creates the service topology. The service overlay provides service 331 function connectivity and is built "on top" of the existing network 332 topology and allows operators to use whatever overlay or underlay 333 they prefer to create a path between service functions, and to locate 334 service functions in the network as needed. 336 Within the service topology, service functions can be viewed as 337 resources for consumption and an arbitrary topology constructed to 338 connect those resources in a required order. Adding new service 339 functions to the topology is easily accomplished, and no underlying 340 network changes are required. 342 Lastly, the service overlay can provide service specific information 343 needed for troubleshooting service-related issues. 345 3.2. Service Classification 347 Classification is used to select which traffic enters a service 348 overlay. The granularity of the classification varies based on 349 device capabilities, customer requirements, and service offered. 350 Initial classification determines the service function chain required 351 to process the traffic. Subsequent classification can be used within 352 a given service function chain to alter the sequence of service 353 functions applied. Symmetric classification ensures that forward and 354 reverse chains are in place. Similarly, asymmetric -- relative to 355 required service function -- chains can be achieved via service 356 classification. 358 3.3. Dataplane Metadata 360 Data plane metadata provides the ability to exchange information 361 between logical classification points and service functions (and vice 362 versa) and between service functions. As such metadata is not used 363 as forwarding information to deliver packets along the service 364 overlay. 366 Metadata can include the result of antecedent classification and/or 367 information from external sources. Service functions utilize 368 metadata, as required, for localized policy decisions. 370 In addition to sharing of information, the use of metadata addresses 371 several of the issues raised in section 2, most notably the 372 decoupling of policy from the network topology, and the need for per- 373 service function classification (and re-classification). 375 A common approach to service metadata creates a common foundation for 376 interoperability between service functions, regardless of vendor. 378 4. Related IETF Work 380 The following subsections discuss related IETF work and are provided 381 for reference. This section is not exhaustive, rather it provides an 382 overview of the various initiatives and how they relate to network 383 service chaining. 385 1. [L3VPN]: The L3VPN working group is responsible for defining, 386 specifying and extending BGP/MPLS IP VPNs solutions. Although 387 BGP/MPLS IP VPNs can be used as transport for service chaining 388 deployments, the SFC WG focuses on the service specific 389 protocols, not the general case of VPNs. Furthermore, BGP/MPLS 390 IP VPNs do not address the requirements for service chaining. 392 2. [LISP]: LISP provides locator and ID separation. LISP can be 393 used as an L3 overlay to transport service chaining data but does 394 not address the specific service chaining problems highlighted in 395 this document. 397 3. [NVO3]: The NVO3 working group is chartered with creation of 398 problem statement and requirements documents for multi-tenant 399 network overlays. NVO3 WG does not address service chaining 400 protocols. 402 4. [ALTO]: The Application Layer Traffic Optimization Working Group 403 is chartered to provide topological information at a higher 404 abstraction layer, which can be based upon network policy, and 405 with application-relevant service functions located in it. The 406 mechanism for ALTO obtaining the topology can vary and policy can 407 apply to what is provided or abstracted. This work could be 408 leveraged and extended to address the need for services 409 discovery. 411 5. [I2RS]: The Interface to the Routing System Working Group is 412 chartered to investigate the rapid programming of a device's 413 routing system, as well as the service of a generalized, multi- 414 layered network topology. This work could be leveraged and 415 extended to address some of the needs for service chaining in the 416 topology and device programming areas. 418 6. [ForCES]: The ForCES working group has created a framework, 419 requirements, a solution protocol, a logical function block 420 library, and other associated documents in support of Forwarding 421 and Control Element Separation. The work done by ForCES may 422 provide a basis for both the separation of SFC elements, as well 423 as provide protocol and design guidance for those elements. 425 5. Summary 427 This document highlights problems associated with network service 428 deployment today and identifies several key areas that will be 429 addressed by the SFC working group. Furthermore, this document 430 identifies three components that are the basis for service function 431 chaining. These components will form the areas of focus for the 432 working group. 434 6. IANA Considerations 436 This document makes no request to IANA. 438 7. Security Considerations 440 Security considerations are not addressed in this problem statement 441 only document. Given the scope of service chaining, and the 442 implications on data and control planes, security considerations are 443 clearly important and will be addressed in the specific protocol and 444 deployment documents created by the SFC WG. 446 8. Contributors 448 The following people are active contributors to this document and 449 have provided review, content and concepts (listed alphabetically by 450 surname): 452 Puneet Agarwal 453 Broadcom 454 Email: pagarwal@broadcom.com 456 Mohamed Boucadair 457 France Telecom 458 Email: mohamed.boucadair@orange.com 460 Abhishek Chauhan 461 Citrix 462 Email: Abhishek.Chauhan@citrix.com 464 Uri Elzur 465 Intel 466 Email: uri.elzur@intel.com 468 Kevin Glavin 469 Riverbed 470 Email: Kevin.Glavin@riverbed.com 472 Ken Gray 473 Cisco Systems 474 Email: kegray@cisco.com 476 Jim Guichard 477 Cisco Systems 478 Email:jguichar@cisco.com 480 Christian Jacquenet 481 France Telecom 482 Email: christian.jacquenet@orange.com 484 Surendra Kumar 485 Cisco Systems 486 Email: smkumar@cisco.com 488 Nic Leymann 489 Deutsche Telekom 490 Email: n.leymann@telekom.de 492 Darrel Lewis 493 Cisco Systems 494 Email: darlewis@cisco.com 496 Rajeev Manur 497 Broadcom 498 Email:rmanur@broadcom.com 500 Brad McConnell 501 Rackspace 502 Email: bmcconne@rackspace.com 504 Carlos Pignataro 505 Cisco Systems 506 Email: cpignata@cisco.com 508 Michael Smith 509 Cisco Systems 510 Email: michsmit@cisco.com 512 Navindra Yadav 513 Cisco Systems 514 Email: nyadav@cisco.com 516 9. Acknowledgments 518 The authors would like to thank David Ward, Rex Fernando, David 519 Mcdysan, Jamal Hadi Salim, Charles Perkins, Andre Beliveau, Joel 520 Halpern and Jim French for their reviews and comments. 522 10. Informative References 524 [ALTO] "Application-Layer Traffic Optimization (alto)", 525 . 527 [ForCES] "Forwarding and Control Element Separation (forces)", 528 . 530 [I2RS] "Interface to the Routing System (i2rs)", 531 . 533 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)", 534 . 536 [LISP] "Locator/ID Separation Protocol (lisp)", 537 . 539 [NVO3] "Network Virtualization Overlays (nvo3)", 540 . 542 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 543 Address Translator (Traditional NAT)", RFC 3022, 544 January 2001. 546 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 547 NAT64: Network Address and Protocol Translation from IPv6 548 Clients to IPv4 Servers", RFC 6146, April 2011. 550 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 551 "Analysis of Potential Solutions for Revealing a Host 552 Identifier (HOST_ID) in Shared Address Deployments", 553 RFC 6967, June 2013. 555 Authors' Addresses 557 Paul Quinn (editor) 558 Cisco Systems, Inc. 560 Email: paulq@cisco.com 562 Thomas Nadeau (editor) 563 Brocade 565 Email: tnadeau@lucidvision.com