idnits 2.17.1 draft-ietf-sfc-problem-statement-02.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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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: August 18, 2014 Brocade 6 February 14, 2014 8 Service Function Chaining Problem Statement 9 draft-ietf-sfc-problem-statement-02.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 such service functions, and the subsequent "steering" of traffic 18 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 August 18, 2014. 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 3. Service Function Chaining . . . . . . . . . . . . . . . . . . 9 62 4. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 11 63 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 67 9. Informative References . . . . . . . . . . . . . . . . . . . . 17 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 70 1. Introduction 72 The delivery of end-to-end services often require various Service 73 Functions (SF) including traditional network service functions (for 74 example firewalls and server load balancers), as well as application- 75 specific features. Service functions may be delivered within the 76 context of an isolated user group, or shared amongst many users/user 77 groups 79 Current service function deployment models are relatively static in 80 that they are tightly coupled to network topology and physical 81 resources. The result of that static nature of existing deployments 82 greatly reduces, and in many cases, limits the ability of an operator 83 to introduce new services and/or service functions. Furthermore 84 there is a cascading effect: service changes affect other services. 86 This document outlines the problems encountered with existing service 87 deployment models for Service Function Chaining (SFC) (often referred 88 to simply as service chaining; in this document the terms will be 89 used interchangeably), as well as the problems of service chain 90 creation/ deletion, policy integration with service chains, and 91 policy enforcement within the network infrastructure. 93 1.1. Definition of Terms 95 Classification: Locally instantiated policy that results in matching 96 of traffic flows for identification of appropriate outbound 97 forwarding actions. 99 Network Overlay: A logical network built, via virtual links or 100 packet encapsulation, over an existing network (the underlay). 102 Service Function Chain (SFC): A service Function chain defines an 103 ordered set of service functions that must be applied to packets 104 and/or frames selected as a result of classification. The implied 105 order may not be a linear progression as nodes may copy to more 106 than one branch. The term service chain is often used as 107 shorthand for service function chain. 109 Service Function: A function that is responsible for specific 110 treatment of received packets. A Service Function can act at the 111 network layer or other OSI layers. A Service Function can be a 112 virtual instance or be embedded in a physical network element. 113 One of multiple Service Functions can be embedded in the same 114 network element. Multiple instances of the Service Function can 115 be enabled in the same administrative domain. 117 A non-exhaustive list of Service Functions includes: firewalls, 118 WAN and application acceleration, Deep Packet Inspection (DPI), 119 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 120 injection [RFC6967], HTTP Header Enrichment functions, TCP 121 optimizer, etc. 123 The generic term "L4-L7 services" is often used to describe many 124 service functions. 126 Service Node: Service Node (SN): Physical or virtual element that 127 hosts one or more service functions. 129 Network Service: An externally visible service offered by a network 130 operator; a service may consist of a single service function or a 131 composite built from several service functions executed in one or 132 more pre-determined sequences and delivered by one or more service 133 nodes. 135 2. Problem Space 137 The following points describe aspects of existing service deployments 138 that are problematic, and are being addressed by the Service Function 139 Chaining effort. 141 1. Topological Dependencies: Network service deployments are often 142 coupled to network topology. Such dependency imposes 143 constraints on the service delivery, potentially inhibiting the 144 network operator from optimally utilizing service resources, and 145 reduces the flexibility. This limits scale, capacity, and 146 redundancy across network resources. 148 These topologies serve only to "insert" the service function 149 (i.e., ensure that traffic traverses a service function); they 150 are not required from a native packet delivery perspective. For 151 example, firewalls often require an "in" and "out" layer-2 152 segment and adding a new firewall requires changing the topology 153 (i.e., adding new layer-2 segments). 155 As more service functions are required - often with strict 156 ordering - topology changes are needed before and after each 157 service function resulting in complex network changes and device 158 configuration. In such topologies, all traffic, whether a 159 service function needs to be applied or not, often passes 160 through the same strict order. 162 The topological coupling limits placement and selection of 163 service functions: service functions are "fixed" in place by 164 topology and therefore placement and service function selection 165 taking into account network topology information is not viable. 167 A common example is web servers using a server load balancer as 168 the default gateway. When the web service responds to non-load 169 balanced traffic (e.g., administrative or backup operations) all 170 traffic from the server must traverse the load balancer forcing 171 network administrators to create complex routing schemes or 172 create additional interfaces to provide an alternate topology. 174 2. Configuration complexity: A direct consequence of topological 175 dependencies is the complexity of the entire configuration, 176 specifically in deploying service function chains. Simple 177 actions such as changing the order of the service functions in a 178 service function chain require changes to the topology. Changes 179 to the topology are avoided by the network operator once 180 installed, configured and deployed in production environments 181 fearing misconfiguration and downtime. All of this leads to 182 very static service delivery deployments. Furthermore, the 183 speed at which these topological changes can be made is not 184 rapid or dynamic enough as it often requires manual 185 intervention, or use of slow provisioning systems. 187 The service itself can contribute to the complexity: it may 188 require an intricate combination of very different capabilities, 189 regardless of the underlying topology. QoS-based, resilient VPN 190 service offerings are a typical example of such complex service 191 offerings. 193 3. Constrained High Availability: An effect of topological 194 dependency is constrained service function high availability. 195 Worse, when modified, inadvertent non-high availability or 196 downtime can result. 198 Since traffic reaches many service functions based on network 199 topology, alternate, or redundant service functions must be 200 placed in the same topology as the primary service. 202 4. Consistent Ordering of Service Functions: Service functions are 203 typically independent; service function_1 (SF1)...service 204 function_n (SFn) are unrelated and there is no notion at the 205 service layer that SF1 occurs before SF2. However, to an 206 administrator many service functions have a strict ordering that 207 must be in place, yet the administrator has no consistent way to 208 impose and verify the ordering of the functions that are used to 209 deliver a given service. 211 5. Service Chain Construction: Service function chains today are 212 most typically built through manual configuration processes. 213 These are slow and error prone. With the advent of newer 214 service deployment models the control/management planes provide 215 not only connectivity state, but will also be increasingly 216 utilized for the creation of network services. Such a control/ 217 management planes could be centralized, or be distributed. 219 6. Application of Service Policy: Service functions rely on 220 topology information such as VLANs or packet (re) classification 221 to determine service policy selection, i.e. the service function 222 specific action taken. Topology information is increasingly 223 less viable due to scaling, tenancy and complexity reasons. The 224 topological information is often stale, providing the operator 225 with inaccurate placement that can result in suboptimal resource 226 utilization. Furthermore topology-centric information often 227 does not convey adequate information to the service functions, 228 forcing functions to individually perform more granular 229 classification. 231 7. Transport Dependence: Service functions can and will be deployed 232 in networks with a range of transports, including under and 233 overlays. The coupling of service functions to topology 234 requires service functions to support many transports or for a 235 transport gateway function to be present. 237 8. Elastic Service Delivery: Given the current state of the art for 238 adding/removing service functions largely centers around VLANs 239 and routing changes, rapid changes to the service deployment can 240 be hard to realize due to the risk and complexity of such 241 changes. 243 9. Traffic Selection Criteria: Traffic selection is coarse, that 244 is, all traffic on a particular segment traverse service 245 functions whether the traffic requires service enforcement or 246 not. This lack of traffic selection is largely due to the 247 topological nature of service deployment since the forwarding 248 topology dictates how (and what) data traverses service 249 function(s). In some deployments, more granular traffic 250 selection is achieved using policy routing or access control 251 filtering. This results in operationally complex configurations 252 and is still relatively inflexible. 254 10. Limited End-to-End Service Visibility: Troubleshooting service 255 related issues is a complex process that involve both network- 256 specific and service-specific expertise. This is especially the 257 case when service function chains span multiple DCs, or across 258 administrative boundaries. Furthermore, the physical and 259 virtual environments (network and service), can be highly 260 divergent in terms of topology and that topological variance 261 adds to these challenges. 263 11. Per-Service (re)Classification: Classification occurs at each 264 service function independent from previously applied service 265 functions. More importantly, the classification functionality 266 often differs per service function and service functions may not 267 leverage the results from other service functions. 269 12. Symmetric Traffic Flows: Service function chains may be 270 unidirectional or bidirectional; unidirectional is one where 271 traffic is passed through a set of service functions in one 272 forwarding direction only. Bidirectional is one where traffic 273 is passed through a set of service functions in both forwarding 274 directions. Existing service deployment models provide a static 275 approach to realizing forward and reverse service function chain 276 association most often requiring complex configuration of each 277 network device throughout the forwarding path. 279 13. Multi-vendor Service Functions: Deploying service functions from 280 multiple vendors often require per-vendor expertise: insertion 281 models differ, there are limited common attributes and inter- 282 vendor service functions do not share information. 284 3. Service Function Chaining 286 Service Function Chaining aims to address the aforementioned problems 287 associated with service deployment. Concretely, SFC will investigate 288 solutions that address the following elements: 290 1. Service Overlay: Service function chaining utilizes a service 291 specific overlay that creates the service topology. The service 292 overlay is independent of the network topology and allows 293 operators to use whatever overlay or underlay they prefer to 294 create a path between service functions, and to locate service 295 functions in the network as needed. 297 Within the service topology, service functions can be viewed as 298 resources for consumption and an arbitrary topology constructed 299 to connect those resources in a required order. Adding new 300 service functions to the topology is easily accomplished, and no 301 underlying network changes are required. 303 Lastly, the service overlay can provide service specific 304 information needed for troubleshooting service-related issues. 306 2. Control Plane: Service aware control plane(s) provide information 307 about the available service functions on a network. The 308 information provided by the control plane includes service 309 network location (for topology creation), service type (e.g. 310 firewall, load balancer, etc.) and, optionally, administrative 311 information about the service functions such as load, capacity 312 and operating status. The service aware control plane allows for 313 the formulation of service function chains and exchanges 314 requisite information needed to instantiate the service function 315 chains in the network. 317 Furthermore, the service aware control plane may interact with 318 the topology aware control plane (if separate) to ensure optimal 319 selection (and possibly placement) of service function within a 320 service path. 322 3. Service Classification: Classification is used to select which 323 traffic enters a service overlay. The granularity of the 324 classification varies based on device capabilities, customer 325 requirements, and service offered. Initial classification is 326 used to start the service function chain. Subsequent 327 classification can be used within a given service function chain 328 to alter the sequence of service functions applied. Symmetric 329 classification ensures that forward and reverse chains are in 330 place. 332 4. Dataplane Metadata: Data plane metadata provides the ability to 333 exchange information between the network and service functions, 334 between service functions, and service functions and the network. 335 Metadata can include the result of antecedent classification, 336 information from external sources or forwarding related data. 337 For example, service functions utilize metadata, as required, for 338 localized policy decisions. 340 In addition to sharing of information, the use of metadata 341 addresses several of the issues raised in section 2, most notably 342 the de-coupling of policy from the topology, and the need for 343 per-service classification (and re-classification). 345 A common approach to service metadata creates a common foundation 346 for interoperability between service functions, regardless of 347 vendor. 349 4. Related IETF Work 351 The following subsections discuss related IETF work and are provided 352 for reference. This section is not exhaustive, rather it provides an 353 overview of the various initiatives and how they relate to network 354 service chaining. 356 1. [L3VPN]: The L3VPN working group is responsible for defining, 357 specifying and extending BGP/MPLS IP VPNs solutions. Although 358 BGP/MPLS IP VPNs can be used as transport for service chaining 359 deployments, the service chaining WG focuses on the service 360 specific protocols, not the general case of VPNs. Furthermore, 361 BGP/MPLS IP VPNs do not address the requirements for service 362 chaining. 364 2. [LISP]: LISP provides locator and ID separation. LISP can be 365 used as an L3 overlay to transport service chaining data but does 366 not address the specific service chaining problems highlighted in 367 this document. 369 3. [NVO3]: The NVO3 working group is chartered with creation of 370 problem statement and requirements documents for multi-tenant 371 network overlays. NVO3 WG does not address service chaining 372 protocols. 374 4. [ALTO]: The Application Layer Traffic Optimization Working Group 375 is chartered to provide topological information at a higher 376 abstraction layer, which can be based upon network policy, and 377 with application-relevant service functions located in it. The 378 mechanism for ALTO obtaining the topology can vary and policy can 379 apply to what is provided or abstracted. This work could be 380 leveraged and extended to address the need for services 381 discovery. 383 5. [I2RS]: The Interface to the Routing System Working Group is 384 chartered to investigate the rapid programming of a device's 385 routing system, as well as the service of a generalized, multi- 386 layered network topology. This work could be leveraged and 387 extended to address some of the needs for service chaining in the 388 topology and device programming areas. 390 5. Summary 392 This document highlights problems associated with network service 393 deployment today and identifies several key areas that will be 394 addressed by the service chaining working group. Furthermore, this 395 document identifies four components that are the basis for serice 396 chaining. These components will form the areas of focus for the 397 working group. 399 6. Security Considerations 401 Security considerations are not addressed in this problem statement 402 only document. Given the scope of service chaining, and the 403 implications on data and control planes, security considerations are 404 clearly important and will be addressed in the specific protocol and 405 deployment documents created by the service chaining working group. 407 7. Contributors 409 The following people are active contributors to this document and 410 have provided review, content and concepts (listed alphabetically by 411 surname): 413 Puneet Agarwal 414 Broadcom 415 Email: pagarwal@broadcom.com 417 Mohamed Boucadair 418 France Telecom 419 Email: mohamed.boucadair@orange.com 421 Abhishek Chauhan 422 Citrix 423 Email: Abhishek.Chauhan@citrix.com 425 Uri Elzur 426 Intel 427 Email: uri.elzur@intel.com 429 Kevin Glavin 430 Riverbed 431 Email: Kevin.Glavin@riverbed.com 433 Ken Gray 434 Cisco Systems 435 Email: kegray@cisco.com 437 Jim Guichard 438 Cisco Systems 439 Email:jguichar@cisco.com 441 Christian Jacquenet 442 France Telecom 443 Email: christian.jacquenet@orange.com 445 Surendra Kumar 446 Cisco Systems 447 Email: smkumar@cisco.com 449 Nic Leymann 450 Deutsche Telekom 451 Email: n.leymann@telekom.de 453 Darrel Lewis 454 Cisco Systems 455 Email: darlewis@cisco.com 457 Rajeev Manur 458 Broadcom 459 Email:rmanur@broadcom.com 461 Brad McConnell 462 Rackspace 463 Email: bmcconne@rackspace.com 465 Carlos Pignataro 466 Cisco Systems 467 Email: cpignata@cisco.com 469 Michael Smith 470 Cisco Systems 471 Email: michsmit@cisco.com 473 Navindra Yadav 474 Cisco Systems 475 Email: nyadav@cisco.com 477 8. Acknowledgments 479 The authors would like to thank David Ward, Rex Fernando and Jim 480 French for their reviews and comments. 482 9. Informative References 484 [ALTO] "Application-Layer Traffic Optimization (alto)", 485 . 487 [I2RS] "Interface to the Routing System (i2rs)", 488 . 490 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)", 491 . 493 [LISP] "Locator/ID Separation Protocol (lisp)", 494 . 496 [NVO3] "Network Virtualization Overlays (nvo3)", 497 . 499 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 500 Address Translator (Traditional NAT)", RFC 3022, 501 January 2001. 503 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 504 NAT64: Network Address and Protocol Translation from IPv6 505 Clients to IPv4 Servers", RFC 6146, April 2011. 507 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 508 "Analysis of Potential Solutions for Revealing a Host 509 Identifier (HOST_ID) in Shared Address Deployments", 510 RFC 6967, June 2013. 512 Authors' Addresses 514 Paul Quinn (editor) 515 Cisco Systems, Inc. 517 Email: paulq@cisco.com 519 Thomas Nadeau (editor) 520 Brocade 522 Email: tnadeau@lucidvision.com