idnits 2.17.1 draft-quinn-nsc-problem-statement-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 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 (June 13, 2013) is 3969 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'L3VPN' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'LISP' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'NVO3' is defined on line 356, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Guichard 3 Internet-Draft S. Kumar 4 Intended status: Informational P. Quinn 5 Expires: December 15, 2013 Cisco Systems, Inc. 6 M. Smith 7 N. Yadav 8 Insieme Networks 9 June 13, 2013 11 Network Service Chaining Problem Statement 12 draft-quinn-nsc-problem-statement-00.txt 14 Abstract 16 This document provides an overview of the issues associated with the 17 deployment of network services (such as firewalls, load balancers) in 18 large-scale environments. The term service chaining is used to 19 describe the deployment of such services, and the ability of a 20 network operator to specify an ordered list of services that should 21 be applied to a deterministic set of traffic flows. Such service 22 chains require integration of service policy alongside the deployment 23 of applications, while maintaining optimal use of available network 24 capacity and resources. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 15, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 62 2. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Service Chaining for Adding Network Services . . . . . . . . . 8 64 4. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 New data center (DC) network and Internet cloud architectures require 76 more flexible deployment models that are able to support many 77 different forms of applications and related network services. 78 Network services include traditional services such as firewalls and 79 server load balancer, as well as applications and features that 80 operate on network data. Additionally, these services must be 81 delivered in the context of multi-tenancy where each individual 82 tenant is an isolated client organization attached to the data 83 center, and may require unique capabilities with the ability to 84 tailor service characteristics on a per-tenant basis. 86 The current network service deployment models are relatively static, 87 and bound to topology for insertion and policy selection. 88 Furthermore, they do not adapt well to elastic service environments 89 enabled by virtualization. Additionally, the transition to virtual 90 platforms requires an agile service insertion model that supports 91 elastic service delivery; supports the movement of service functions 92 and application workloads in the network while retaining the network 93 and service policies and the ability to easily bind service policy to 94 granular information such as per-subscriber state. 96 This document outlines the problems encountered with existing service 97 deployment models for service chaining, as well as the problems of 98 service chain creation/deletion, policy selection integration with 99 service chains, and policy enforcement within the network 100 infrastructure. 102 1.1. Definition of Terms 104 Classification: Locally instantiated policy and customer/network/ 105 service profile matching of traffic flows for identification of 106 appropriate outbound forwarding actions. 108 Network Overlay: Logical network built on top of existing network 109 (the underlay). Packets are encapsulated or tunneled to create 110 the overlay network topology. 112 Service Chain: A service chain defines the services required 113 (e.g.FW), and their order (service1 --> service2) that must be 114 applied to packets and/or frames. 116 Service Function: A L4-L7 service function (NAT, FW, DPI, IDS, 117 application based packet treatment), application, compute 118 resource, storage, or content used singularly or in collaboration 119 with other service functions to enable a service offered by a 120 network operator. 122 Service Node: Physical or virtual element providing one or more 123 service functions. 125 Network Service: An externally visible service offered by a network 126 operator; a service may consist of a single service function or a 127 composite built from several service functions executed in one or 128 more pre-determined sequences. 130 2. Problem Areas 132 The following points describe aspects of existing service deployment 133 techniques that are problematic, and are being addressed by the 134 network service chaining effort. 136 1. Topological Dependencies: Network service deployments are often 137 coupled to the physical network topology creating artificial 138 constraints on delivery and inhibiting the network operator from 139 sharing service resources and scale capacity/redundancy across 140 multiple network devices. These topologies serve only to 141 "insert" the service function; they are not required from a 142 native packet delivery perspective. For example, firewalls 143 often require an "in" and "out" layer-2 segment and adding a new 144 firewall requires changing the topology (i.e. adding new L2 145 segments). As more services are required - often with strict 146 ordering - topology changes are needed before and after each 147 service resulting in complex network changes and device 148 configuration. In such topologies, all traffic, whether a 149 service needs to be applied or not, often passes through the 150 same strict order. A common example is web servers using a 151 server load balancer as the default gateway. When the web 152 service responds to non-load balanced traffic (e.g. 153 administrative or backup operations) all traffic from the server 154 must traverse the load balancer forcing network administrators 155 to create complex routing schemes or create additional 156 interfaces to provide an alternate topology. 158 2. Configuration complexity: A direct consequence of topological 159 dependencies is the complexity of the entire configuration, 160 specifically in deploying service chains. Simple actions such 161 as changing the order of the service functions in a service 162 chain require changes to the topology. Changes to the topology 163 is avoided by the network operator once installed, configured 164 and deployed in production environments fearing misconfiguration 165 and downtime. All of this leads to very static service delivery 166 models. 168 3. Constrained High Availability: An effect of topological 169 dependency is constrained service high availability. Since 170 traffic reaches services based on network topology, alternate, 171 or redundant service functions must be placed in the same 172 topology as the primary service. 174 4. Consistent Ordering of Service Functions: Service functions are 175 typically independent; service function_1 (SF1)...service 176 function_n (SFn) are unrelated and there is no notion at the 177 service layer that SF1 occurs before SF2. However, to an 178 administrator many service functions have a strict ordering that 179 must be in place, yet the administrator has no consistent way to 180 impose and verify the deployed service ordering. 182 5. Service Chain Construction: Service chains today are most 183 typically built through manual configuration processes. With 184 the advent of newer service deployment models the control plane 185 will provide not only connectivity state and membership 186 distribution across tenants, but will also be increasingly 187 utilized for the formation of services. Such a control plane 188 could be centrally controlled and managed, or be distributed 189 between a subset of end-systems. Formation of closed user 190 groups that are able to maintain separation of forwarding and 191 connectivity state, while at the same time be independently 192 identified and directed through appropriate services, requires 193 the ability to create "zones" of awareness and "chained" 194 services. 196 6. Application of Service Policy: Service functions rely on 197 topology information such as VLANs or packet (re) classification 198 to determine service policy selection, i.e. the service action 199 taken. Topology information is increasingly less viable due to 200 scaling, tenancy and complexity reasons. Per-service function 201 packet classification is inefficient and prone to errors, 202 duplicating functionality across services. Furthermore packet 203 classification is often too coarse lacking the ability to 204 determine class of traffic with enough detail. 206 7. Transport Dependence: Services can and will be deployed in 207 networks with a range of transports, including under and 208 overlays. The coupling of services to topology requires 209 services to support many transports or for a transport gateway 210 function to be present. 212 8. Elastic Service Delivery: Given the current state of the art for 213 adding/removing services largely centers around VLANs and 214 routing changes, rapid changes to the service layer can be hard 215 to realize due to the risk and complexity of such changes. 217 9. Traffic Selection Criteria: Traffic selection is coarse, that 218 is, all traffic on a particular segment is sent to a service 219 whether the traffic requires service enforcement or not. This 220 lack of traffic selection is largely due to the topological 221 nature of service deployment since the forwarding topology 222 dictates how (and what) data traverses the service(s). In some 223 deployments, more granular traffic selection is achieved using 224 policy routing or access control filtering. This results in 225 operationally complex configurations and is still relatively 226 inflexible. 228 10. Limited End-to-End Service Visibility: Troubleshooting service 229 related issues is a complex process that involve network and 230 service expertise. 232 11. Per-Service (re)Classification: Classification occurs at each 233 service, independently from previous service functions. These 234 unrelated classification events consume resources per service. 235 More importantly, the classification functionality often differs 236 per service and services cannot leverage the results from other 237 deployed network or service. 239 12. Symmetric Traffic Flows: Service chains may be unidirectional or 240 bidirectional; unidirectional is one where traffic is passed 241 through a set of service functions in one forwarding direction 242 only. Bidirectional is one where traffic is passed through a 243 set of service functions in both forwarding directions. 244 Existing service deployment models provide a static approach to 245 realizing forward and reverse service chain association most 246 often requiring complex configuration of each network device 247 throughout the forwarding path. 249 3. Service Chaining for Adding Network Services 251 Service chaining provides a framework to address the aforementioned 252 problems associated with service deployments: 254 1. Service Overlay: Service chaining utilizes a service specific 255 overlay that creates the service topology: the overlay creates a 256 path between service nodes. The service overlay is independent 257 of the network topology and allows operators to use whatever 258 overlay or underlay they prefer and to place services in the 259 network as needed. Within the service topology, services can be 260 viewed as resources for consumption and an arbitrary topology 261 constructed to connect those resources in a required order. 262 Furthermore, additional service instances, for redundancy or load 263 distribution, can be added or removed to the service topology as 264 required. Lastly, the service overlay can provide service 265 specific information needed for troubleshooting service-related 266 issues. 268 2. Generic Service Control Plane (GSCP): GSCP provides information 269 about the available services on a network. The information 270 provided by the control plane includes service network location 271 (for topology creation), service type (e.g. firewall vs. load 272 balancer) and, optionally, administrative information about the 273 services such as load, capacity and operating status. GSCP 274 allows for the formulation of service chains and disseminates the 275 service chains to the network. 277 3. Service Classification: Classification is used to select which 278 traffic enters a service overlay. The granularity of the 279 classification varies based on device capabilities, customer 280 requirements, and service functionality. Initial classification 281 is used to start the service chain. Subsequent classification 282 can be used within a given service chain to alter the sequence of 283 services applied. Symmetric classification ensures that forward 284 and reverse chains are in place. 286 4. Dataplane Metadata: Dataplane metadata provides the ability to 287 exchange information between the network and services, services 288 and services and services and the network. Metadata can include 289 the result of antecedent classification, information from 290 external sources or forwarding related data. For example, 291 services utilize metadata, as required, for localized policy 292 decision. 294 4. Related IETF Work 296 The following subsections discuss related IETF work and are provided 297 for reference. This section is not exhaustive, rather it provides an 298 overview of the various initiatives and how they relate to network 299 service chaining. 301 1. L3VPN: The L3VPN working group is responsible for defining, 302 specifying and extending BGP/MPLS IP VPNs solutions. Although 303 BGP/MPLS IP VPNs can be used as transport for service chaining 304 deployments, the service chaining WG focuses on the service 305 specific protocols, not the general case of VPNs. Furthermore, 306 BGP/MPLS IP VPNs do not address the requirements for service 307 chaining. 309 2. LISP: LISP provides locator and ID separation. LISP can be used 310 as an L3 overlay to transport service chaining data but does not 311 address the specific service chaining problems highlighted in 312 this document. 314 3. NVO3: The NVO3 working group is chartered with creation of 315 problem statement and requirements documents for multi-tenant 316 network overlays. NVO3 WG does not address service chaining 317 protocols. 319 5. Summary 321 This document highlights problems associated with network service 322 deployment today and identifies several key areas that will be 323 addressed by the service chaining working group. Furthermore, this 324 document identifies four components that are the basis for serice 325 chaining. These components will form the areas of focus for the 326 working group. 328 6. Security Considerations 330 Security considerations are not addressed in this problem statement 331 only document. Given the scope of service chaining, and the 332 implications on data and control planes, security considerations are 333 clearly important and will be addressed in the specific protocol and 334 deployment documents created by the service chaining working group. 336 7. Acknowledgments 338 The authors would like to thank David Ward and Rex Fernando for their 339 contributions. 341 8. References 343 8.1. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 8.2. Informative References 350 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)", 351 . 353 [LISP] "Locator/ID Separation Protocol (lisp)", 354 . 356 [NVO3] "Network Virtualization Overlays (nvo3)", 357 . 359 Authors' Addresses 361 Jim Guichard 362 Cisco Systems, Inc. 364 Email: jguichar@cisco.com 366 Surendra Kumar 367 Cisco Systems, Inc. 369 Email: smkumar@cisco.com 371 Paul Quinn 372 Cisco Systems, Inc. 374 Email: paulq@cisco.com 376 Michael Smith 377 Insieme Networks 379 Email: michsmit@insiemenetworks.com 381 Navindra Yadav 382 Insieme Networks 384 Email: nyadav@insiemenetworks.com