idnits 2.17.1 draft-kumar-sfc-dc-use-cases-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 : ---------------------------------------------------------------------------- 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 (May 3, 2014) is 3640 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining S. Kumar 3 Internet-Draft C. Obediente 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: November 4, 2014 M. Tufail 6 Citi 7 S. Majee 8 F5 Networks 9 C. Captari 10 Telstra Corporation 11 May 3, 2014 13 Service Function Chaining Use Cases In Data Centers 14 draft-kumar-sfc-dc-use-cases-02 16 Abstract 18 Data center operators deploy a variety of layer 4 through layer 7 19 service functions in both physical and virtual form factors. Most 20 traffic originating, transiting, or terminating in the data center is 21 subject to treatment by multiple service functions. 23 This document describes use cases that demonstrate the applicability 24 of Service Function Chaining (SFC) within a data center environment 25 and provides SFC requirements for data center centric use cases, with 26 primary focus on Enterprise data centers. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 4, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 4 65 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Traffic Types . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. North-South Traffic . . . . . . . . . . . . . . . . . . . 6 68 3.2.1. Sample north-south service function chains . . . . . . 8 69 3.2.2. Sample north-south SFC description . . . . . . . . . . 8 70 3.3. East-West Traffic . . . . . . . . . . . . . . . . . . . . 9 71 3.3.1. Sample east-west service function chains . . . . . . . 10 72 3.3.2. Sample east-west SFC description . . . . . . . . . . . 10 73 3.4. Multi-tenancy . . . . . . . . . . . . . . . . . . . . . . 11 74 3.5. SFCs in data centers . . . . . . . . . . . . . . . . . . . 12 75 4. Drawbacks Of Existing Service Chaining Methods . . . . . . . . 13 76 5. General Requirements . . . . . . . . . . . . . . . . . . . . . 16 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 Data centers -- enterprise, cloud or service provider -- deploy 88 service nodes at various points in the network topology. These nodes 89 provide a range of service functions and the set of service functions 90 hosted at a given service node may overlap with service functions 91 hosted at other service nodes. 93 Often, data center topologies follow a hierarchical design with core, 94 aggregation, access and virtual access layers of network devices. In 95 such topologies service nodes are deployed either in the aggregation 96 or access layers. More recent data center designs utilize a folded 97 CLOS topology to improve scale, performance and resilience while 98 ensuring deterministic hop count between end points. In such spine- 99 leaf topologies, service nodes are often deployed at compute or 100 virtual access layers as well as physical access layers. 102 The primary purpose of deploying service functions at different 103 points in the network is to apply service functions to different 104 types of traffic: 106 a. Traffic originating at physical or virtual workloads in the data 107 center and destined to physical or virtual workloads in the data 108 center; for example three-tiered deployment of applications: web, 109 application, and database tiers, with traffic flowing between the 110 adjacent tiers. 112 b. Traffic originating at a location remote to the data center and 113 destined to physical or virtual workloads in the data center; for 114 example traffic originating at a branch or regional office, 115 destined to one of the primary data centers in an Enterprise, or 116 traffic originating at one of the tenants of a Service Provider 117 destined to that tenants applications in the Service Provider 118 data center. Yet another variant of this type of traffic 119 includes third party vendors and partners of the data center 120 operator remotely accessing their applications in the data center 121 over secure connections. 123 c. Traffic that is originating at a location remote to the data 124 center and destined to a location remote to the data center but 125 transiting through the data center; for example traffic 126 originating at a mobile device destined to servers in the 127 Internet routed through the data center to in order to service 128 it. 130 Servicing of traffic involves directing the traffic through a series 131 of service functions that may be located at different places in the 132 network or within a single device connected to the network or any 133 combination in between. Delivery of multiple service functions in a 134 sequence, in a datacenter, thus creates many requirements on the 135 overall service delivery architecture. Such architectures may be 136 termed service function chaining architectures while the list of 137 service functions applied to the traffic is a Service Function Chain 138 (SFC). 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 2. Definition Of Terms 148 Additional terms are defined in [I-D.ietf-sfc-problem-statement], 149 which the reader may find helpful. 151 End Point (EP): A device or an application that is the ultimate 152 origination or destination entity of specific traffic. Mobile 153 devices, desktop or server computers and applications running on 154 them are some examples. 156 Workload (WL): A physical or virtual machine performing a dedicated 157 task that consumes compute, storage, network and other resources. 158 This may include web servers, database servers, storage servers 159 and a variety of application servers. 161 Service Function (SF): A function that is responsible for specific 162 treatment of received packets. A Service Function can act at the 163 network layer or other OSI layers. A Service Function can be a 164 virtual instance or be embedded in a physical network element. 165 One of multiple Service Functions can be embedded in the same 166 network element. Multiple instances of the Service Function can 167 be enabled in the same administrative domain. A non-exhaustive 168 list of Service Functions includes: firewalls, WAN and 169 application acceleration, Deep Packet Inspection (DPI), server 170 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 171 injection, HTTP Header Enrichment functions, TCP optimizer, etc. 173 Service Node (SN): A virtual or physical device that hosts one or 174 more service functions, which can be accessed via the network 175 location associated with it. 177 Deep Packet Inspection (DPI): service function that performs 178 stateful inspection of traffic, identification of applications 179 and policy enforcement, among others. 181 Intrusion Detection and/or Prevention System (IDS/IPS): Is a DPI SN 182 with additional capabilities to recognize malware and other 183 threats and take corrective action. 185 Edge Firewall (EdgeFW): SN hosting service functions such as VPN, 186 DHCP, NAT, IP-Audit, Protocol Inspection, DPI etc. with policies 187 primarily focusing on threats external to the data center. 189 Segment Firewall (SegFW): SN hosting a subset of the functions in 190 the EdgeFW not including VPN and is deployed to protect traffic 191 crossing segments, such as VLANs. 193 Application Firewall (AppFW): service function that isolates traffic 194 within a segment or protects from application specific threats. 195 This falls into the same class as DPI but deployed much closer to 196 the applications. It is an intra-segment firewall. 198 Application Delivery Controller (ADC): service function that 199 distributes traffic across a pool of servers (applications) for 200 efficient resource utilization, application scaling as well as to 201 provide high availability among others. 203 Web Optimization Control (WOC): SN hosting service functions to 204 optimize the use of WAN link bandwidth, improve effective user 205 throughput and latencies leading to overall improved user 206 experience. WOC includes various optimizers such as compression, 207 de-duplication, congestion control, application specific 208 optimizers, etc. WOC requires peers at either end of the WAN 209 link to perform optimizations. The scope of this document is 210 limited to the DC side of the WAN link. 212 Monitoring (MON): SN hosting service functions to obtain operational 213 visibility into the network to characterize network and 214 application performance, troubleshoot performance issues, 215 optimize resource utilization, etc. 217 Note: The above definitions are generalized. Actual implementations 218 may vary in scope and in a lot of cases the actual service functions 219 hosted on SNs overlap. For instance, DPI function is not only 220 implemented as a standalone service function but is also implemented 221 in EdgeFWs. Likewise EdgeFw functions, such as VPN, are implemented 222 in routers. The terms used are representative of common usage and 223 not absolute deployment. 225 3. Use Cases 227 The following sections highlight some of the most common data center 228 use case scenarios and are in no way exhaustive. 230 3.1. Traffic Types 232 IT assets in an enterprise are consolidated into a few data centers 233 located centrally. This consolidation stems from regulatory 234 compliance regarding security, control on the enterprise assets, 235 operational cost savings, disaster recovery strategies, etc. The 236 data center resources are accessible from any geographic location 237 whether inside or outside the enterprise network. Further, 238 enterprise data centers may be organized along lines of businesses, 239 with each business treated as a tenant, thereby supporting multi- 240 tenancy. 242 Service provider data centers have similar requirements as the 243 enterprise. Data centers may be distributed regionally and globally 244 to support the needs of their tenants. Multi-tenancy underlines 245 every consideration in such data centers: resources and assets are 246 organized & managed on tenant boundaries, policies are organized 247 along tenant boundaries, traffic is segregated and policies enforced 248 on tenant boundaries, etc. This is true in all "as a service" 249 models: IaaS, PaaS and SaaS. 251 This leads to two primary types of traffic: North-South and East- 252 West, both with different service requirements. 254 3.2. North-South Traffic 256 North-South traffic originates from outside the data center and is 257 typically associated with users - onsite, remote and VPN - conducting 258 their jobs. The traffic may also be associated with consumers 259 accessing news, email, social media and other websites. This traffic 260 is typically destined to applications or resources hosted in the data 261 centers. Increasing adoption of BYOD and social networking 262 applications requires traffic be analyzed, application and users be 263 identified, transactions be authorized, and at the same time security 264 threats be mitigated or eliminated. To this end, various service 265 functions, as illustrated in Figure 1, are deployed in different SNs 266 and in many instances of those SNs, at various topological locations 267 in the network. The SNs are selected based on the policy required 268 for the specific use case. 270 [ End Point ] --------+ 271 | 272 | 273 | 274 Border 275 +------ Router 276 | | 277 | | 278 +------- WOC 279 | | 280 | | 281 +------ EdgeFW 282 | | 283 | | 284 +------- MON 285 | | 286 | | 287 +------- ADC 288 | | 289 | | 290 +------ AppFW 291 | 292 | 293 | 294 +-------- [ Workload ] 296 Figure 1: Service functions applied to North-South traffic 298 Figure 1 shows the ordered list of SNs, from top to bottom, 299 representing the flow of traffic from End Point to Workload and vice 300 versa. Traffic does not always strictly flow through all the SNs in 301 that order. Traffic flows through various permutations, of the 302 subsets, of the SNs. The connections from each of the service nodes 303 to every other service node (as depicted by the vertical line to the 304 left) represents the network topology required to achieve such 305 traffic flows. Each permutation represents a service function chain. 307 Certain ordering of the SNs naturally exists due to the nature of the 308 functions applied. For instance, WOC is not effective on VPN traffic 309 - requires VPN termination prior to WOC. Likewise EdgeFW may not be 310 effective on WOC traffic. Vendor implementations of SNs enable 311 choices for various deployments and ordering. For instance EdgeFW 312 detects the presence of WOC through TCP options or explicit 313 configuration and hence WOC may even be deployed on the traffic that 314 has passed through the EdgeFW. Constructing service function chains 315 in the underlay network thus requires complex topology. 317 3.2.1. Sample north-south service function chains 319 SFC-1. EdgeFW 321 SFC-2. EdgeFW : ADC 323 SFC-3. EdgeFW : ADC : AppFW 325 SFC-4. WOC : EdgeFW : ADC : AppFW 327 SFC-5. WOC : EdgeFW : MON : ADC : AppFW 329 3.2.2. Sample north-south SFC description 331 Sample service chains numbered SFC-1 through SFC-5 capture the 332 essence of services required on the north-south traffic. 334 SFC-1: This represents the simplest of use cases where a remote or 335 mobile worker accesses a specific data center server. Traffic 336 comes into the data center on VPN and is terminated on the 337 EdgeFW. EdgeFW subjects the traffic to its policies, which may 338 in turn select other service functions such as DPI, IPS/IDS, 339 hosted on the EdgeFW. As an alternative deployment, some of 340 these service functions may be hosted outside the EdgeFW and 341 reachable via VLAN stitching. EdgeFW policy permitting, traffic 342 is allowed to its destination. 344 SFC-2: This is an extension of SFC-1. Traffic instead of destined 345 to a specific server is destined to a data center application 346 that is front-ended by an ADC. The EdgeFW performs its function 347 as before and the traffic is allowed, policy permitting. This 348 traffic reaches its virtual destination, the ADC. ADC, based on 349 local policy, which includes among other things predictors to 350 select the real destination, determines the appropriate 351 application instance. ADCs are stateful and ensure the return 352 traffic pass through them by performing source NAT. Since many 353 applications require the original source address, ADC preserves 354 the original address in extension headers of the HTTP protocol. 355 Traffic is then forwarded on to the ultimate destination - the 356 real application workload. 358 SFC-3: This extends SFC-2. The segment where the application server 359 resides may be shared with other applications and resources. To 360 segregate these applications and resources further fine grain 361 policies may be required and are enforced via a security 362 appliance such as the AppFW. As a consequence AppFW first 363 services the traffic from the load balancer before it is 364 forwarded to its ultimate destination, the application server. 366 SFC-4: This is a variant of SFC-3 with WOC being part of the chain. 367 This represents the use case where users at a branch office 368 access the data center resources. The WOC SNs located at either 369 end of the WAN optimize the traffic first. The WOC located in 370 the datacenter requires a mechanism to steer traffic to it while 371 not deployed inline with the traffic. This is achieved either 372 with PBR or VLAN stitching. WOC treated traffic is subject to 373 firewall policies, which may lead to the application of SFs such 374 as protocol inspection, DPI, IDS/IPS and then forwarded to its 375 virtual destination, the ADC. 377 SFC-5: This is similar to SFC-4. An additional service - MON, is 378 used to collect and analyze traffic entering and leaving the data 379 center. This monitoring and analysis of traffic helps maintain 380 performance levels of the infrastructure to achieve service level 381 agreements, particularly in SP data centers. 383 3.3. East-West Traffic 385 This is the predominant traffic in data centers today. Server 386 virtualization has led to the new paradigm where virtual machines can 387 migrate from one server to another across the datacenter. This 388 explosion in east-west traffic is leading to newer data center 389 network fabric architectures that provide consistent latencies from 390 one point in the fabric to another. 392 The key difference with east-west from the north-south traffic is in 393 the kind of threats and the security needs thereof. Unlike north- 394 south traffic where security threats may come from outside the data 395 center, any threat to this traffic comes from within the data center. 397 +-- ADC1 --- MON1 --- AppFW1 --- Workload1(Web) 398 / 399 SegFW ---- ADC2 --- MON2 --- AppFW2 --- Workload2(App) 400 \ 401 +-- ADC3 --- MON3 --- AppFW3 --- Workload3(DB) 403 Figure 2: Service functions applied to East-West traffic 405 Service functions applied on the east-west traffic is captured in a 406 generalized fashion in Figure 2. ADCs, although shown as isolated 407 SNs in each of the tiers, is often consolidated into a smaller number 408 of ADC SNs shared among the different tiers. Virtual IPs in such 409 ADCs represent the individual ADC instances. Flows are terminated at 410 the VIPs and re-initiated towards the load balanced workloads. 412 As an example, HTTP GET request arriving at ADC1 is load balanced on 413 to a webserver pool represented as Workload1. In order to respond to 414 the GET request, Workload1 generates traffic to an application server 415 in a pool represented as Workload2 through ADC2, which load balances 416 the webserver initiated traffic. Likewise, the application server, 417 as part of processing the webserver's request generates traffic to a 418 DB server pool represented as Workload3 through ADC3, which load 419 balances the application server initiated traffic. The traffic 420 arriving at different ADCs, in this example, can be arriving at 421 different VIPs, instead, each corresponding to its tier but belonging 422 to the same ADC. In this sense, traffic flow across the tiers is VIP 423 centric as opposed to device instance. 425 Traffic traversing between the ADC and the selected server in each 426 tier, is subject to monitoring and one or more application firewalls 427 specializing in different kinds and aspects of threats. These again 428 can be shared just as the ADC due to steering mechanisms although it 429 adds complexity in network configuration. 431 3.3.1. Sample east-west service function chains 433 SFC-6. SegFW : ADC : MON : AppFW 435 3.3.2. Sample east-west SFC description 437 SFC-6: In a typical three tiered architecture, requests coming to a 438 webserver trigger interaction with application servers, which in 439 turn trigger interaction with the database servers. It has to be 440 noted that each of these tiers are deployed in their own segments 441 or zones for isolation, optimization and security. SegFW 442 enforces the security policies between the tiers and facilitates 443 isolation at the segment level or address space re-use via NAT 444 deployment. ADC provides the distribution, scale and resiliency 445 to the applications while the AppFW protects and isolates traffic 446 within the segment in addition to enforcing application specific 447 security policies. Finally, monitoring service enables 448 visibility into application traffic, which in turn is used to 449 maintain application performance levels. 451 3.4. Multi-tenancy 453 Multi-tenancy is relevant in both enterprise as well as service 454 provider data centers although it is the primary differentiator 455 between service provider (SP) and enterprise datacenter. Enterprises 456 treat organizations or business units within the enterprise as 457 tenants and thus require tenant aware service models. 459 Multi-tenant service delivery is achieved in two primary ways: a) SNs 460 themselves are tenant aware - every SN is built to support multiple 461 tenants. b) SN instances are dedicated for each tenant. In both the 462 cases, the SP manages the SNs. 464 To support multi-tenant aware service functions or SNs, traffic being 465 serviced by a service function chain has to be identified by a tenant 466 identifier. A tenant identifier has to be carried along with the 467 traffic to be serviced. It is typical of tenant assets to be 468 deployed in an isolated layer2 or layer3 domain such as VLAN, VXLAN 469 or VRF. It has to be noted that the SNs themselves maybe deployed in 470 different domains to suit the deployment needs of the SP and hence 471 using the domain in which the SN is deployed is not an option. 472 Although such a model is feasible it removes the deployment 473 flexibility for the service providers. 475 3.5. SFCs in data centers 477 [ EP/WL ] 478 | 479 | 480 | 481 Border - 482 +------ Router | 483 | | 484 | | 485 +------- WOC A 486 | | C 487 | | C S 488 +------ EdgeFW E F 489 | | S C 490 | | S 491 +------- MON 492 | | 493 | | | 494 +------ SegFW - 495 / | \ | 496 / | \ 497 +-------+ | +-------+ A 498 | | | P 499 | | | P 500 ADC ADC ADC L 501 | | | I S 502 | | | C F 503 MON MON MON A C 504 | | | T s 505 | | | I 506 AppFW AppFW AppFW O 507 | | | N 508 | | | 509 | | | | 510 [ WL/Web ] [ WL/App ] [ WL/DB ] - 512 Figure 3: Service function chains in data center 514 Figure 3 shows the global view of SFCs applied in an enterprise or 515 service provider data center. At a high level the SFCs can be 516 broadly categorized into two types: 518 1. Access SFCs 520 2. Application SFCs 522 Access SFCs are focused on servicing traffic entering and leaving the 523 data center while Application SFCs are focused on servicing traffic 524 destined to applications. 526 Service providers deploy a single "Access SFC" and multiple 527 "Application SFCs" for each tenant. Enterprise data center operators 528 on the other hand may not have a need for Access SFCs depending on 529 the size and requirements of the enterprise. Where such Access SFCs 530 are indeed needed, such as large enterprises, the operator may deploy 531 a bare minimum Access SFC instead. Such simple Access SFCs include 532 WOC and VPN SFs to support the branch and mobile user traffic while 533 at the same time utilizing the security policies in the application 534 SFCs. The latter is the case in de-perimetrized network 535 architectures where security policies are enforced close to the 536 resources and applications as opposed to the WAN edge. 538 4. Drawbacks Of Existing Service Chaining Methods 540 The above use cases are realized in a traditional fashion and are not 541 viable in the evolving hybrid data centers with virtual and physical 542 assets. The following are some of the obvious short comings of 543 existing SFC methods exposed by the above use cases. 545 DB-1. Policy based purely on VLANs is no longer sufficient. 546 Connecting SNs to each other to construct a service chain 547 thus makes it very static and removes deployment flexibility. 548 As can be seen from the sample north-south service chains, a 549 large number of VLANs not only have to be stitched in a 550 certain fashion to achieve a basic SFC, it is simply not 551 flexible to share the SNs among different SFCs as even simple 552 sharing among a few SNs becomes intractable from basic 553 configuration perspective let alone future changes or 554 manageability aspects. 556 DB-2. Traffic does not always have to be steered through all the 557 SNs of a traditional VLAN stitched service chain. In 558 Figure 1, traffic from the border router is not always 559 necessary to flow through the WOC as remote or mobile worker 560 may not have a WOC peer deployed. Connecting multiple VLANs 561 among service nodes to overcome to achieve this only 562 aggravates the problem of deployment and manageability. 563 Truly, there exists a need for dynamically determining the 564 next sub SFC at such branching points to avoid forcing all 565 traffic through the same SFC. 567 DB-3. Virtual environments require the virtual SNs be migration 568 capable just like the compute workloads. As a consequence it 569 is simply not feasible to continue VLAN stitching in the 570 hybrid data centers. Every time a virtual SN migrates, such 571 as the AppFW in Figure 1 and Figure 2, the operator has to 572 ensure the VLANs are provisioned in the destination. 573 Further, stretching the VLANs across the network may not be 574 an option for the operator or even worse the virtual SN may 575 be L3 hop away from the previous SN. 577 DB-4. Policy Based Routing (PBR) can be used to move traffic to 578 SNs. Although it provides a much better granularity than 579 VLAN stitching it suffers from the requirement to configure 580 such policies all along the path to the SNs. In Figure 1, if 581 WOC is multiple hops away from the border router, all network 582 elements in between border router and WOC need to be 583 configured with consistent policies. 585 DB-5. Source NAT (SNAT) is required by some SNs, such as ADC in 586 Figure 1, in order to ensure traffic sent to the load 587 balanced servers pass through the ADC in reverse direction. 588 However, SNAT removes the ability to detect the originator of 589 the traffic. Using HTTP extension header to pass originator 590 information is not only an overhead but addresses only one 591 specific protocol. 593 DB-6. Static service chains do not allow for modifying the SFCs as 594 they require the ability to add SNs or remove SNs to scale up 595 and down the service capacity. Likewise the ability to 596 dynamically pick one among the many SN instance is not 597 available. For instance, WOC must scale to support the high 598 data rate of traffic flowing to the data center. Likewise, 599 AppFWs must scale up to not impact the workload throughput. 600 Further they may be required to scale within tenant 601 boundaries. 603 DB-7. Static SFCs constructed over the under lay network cannot 604 pass metadata to the SNs. Border Router in Figure 1 cannot 605 pass policy based tags derived locally at the start of the 606 SFC all the way through the SFC. Such metadata is necessary 607 to enforce consistent security policies across the network, 608 as one example. 610 DB-8. In multi-tenant deployments, the segment on which the SN is 611 deployed may not correspond to the segment assigned to the 612 tenant in which the workloads are hosted. In Figure 2, AppFW 613 may be deployed on a different segment than the Workload. As 614 a consequence, it is not viable to derive the tenant segment 615 simply based on the tag associated with the incoming traffic 616 at the AppFW. This ultimately prevents the ability to have 617 the same SN serve multiple tenants. Forcing the SN to be on 618 the same segment as the tenants' workload limits deployment 619 flexibility. 621 DB-9. Traffic may originate in a physical or virtual network or 622 transit these networks before being delivered to the SNs for 623 servicing. The following is very complex to achieve with the 624 existing SFC mechanism, primarily due to very conflicting 625 nature of their environments: physical and static vs. virtual 626 and dynamic. 628 A. Physical SN servicing traffic originating in the virtual 629 access network. 631 B. Virtual SN servicing traffic originating in the physical 632 network. 634 DB-10. Although SNs are purpose built service appliances, it is 635 neither a requirement nor an indication of how service 636 functions are implemented in emerging data centers with 637 commodity compute and storage capabilities. AppFW in 638 Figure 1, for instance, may be built and deployed as a 639 virtual SN. Further, SFCs are limited to exclusively 640 physical or virtual SNs and not a mix. This excludes the 641 ability to combine the benefits offered by physical SNs with 642 the flexibility and agility of the virtual SNs. The EdgeFW 643 in Figure 1, for instance, may be a purpose built SN to take 644 advantage of SFs implemented in hardware while the AppFW may 645 be a virtual SN deployed to be close to the virtual workload 646 and may even move with the workload in the virtual 647 environment. 649 DB-11. Troubleshooting is one of the predominant issues plaguing SFC 650 deployments. The reasons range from misconfiguration at 651 different elements in the network that are responsible for 652 directing traffic to the service nodes, to, tracking the 653 traffic paths starting from the point of entry into the DC to 654 the point of exit to the application through various SNs. 655 When desired services are not effective on certain traffic, 656 determining the reason is simply not viable in a large scale 657 deployment. Figure 3 provides a view of the complexity in 658 terms of the permutations of the SFCs, their paths in the 659 network and the configuration in the network elements 660 required and managed for proper operation. 662 5. General Requirements 664 The above use cases and the drawbacks thereof lead to the following 665 general requirements in today's evolving hybrid datacenters to apply 666 SFCs to traffic. 668 GR1. SFC polices MUST be applicable at the edges - network elements 669 as well as the workloads. 671 GR2. SFC policies MUST be applicable to either Ingress or Egress 672 traffic. 674 GR3. SFC MUST support virtual as well as physical SNs. 676 GR4. SFC SHOULD support the ability to mix virtual and physical SNs 677 in the same SFC. 679 GR5. SFC SNs MUST be deployable L2 or L3 hop away from each other 680 or from the SFC starting entity. 682 GR6. SFC traffic MUST be allowed to follow paths not constrained by 683 the underlying static network topology. 685 GR7. SFC SNs MUST be able to derive the tenant identification 686 without being tied to the underlying topology 688 GR8. SFCs MUST support the ability to pass metadata among the SNs 689 or between the SNs and the network elements. 691 GR9. A composite SFC SHOULD be achievable by way of joining sub 692 SFCs, branching to sub SFCs where necessary. 694 GR10. SFCs SHOULD NOT require SNAT inside the SFs to attract traffic 695 back to them 697 GR11. SFCs SHOULD have the ability to choose SN instances 698 dynamically, at the time of forwarding traffic to them. 700 GR12. An OAM mechanism to easily troublshoot as well as validate the 701 paths traversed by the SFCs SHOULD be supported. 703 6. Acknowledgements 705 The authors would like to thank Paul Quinn, Jim Guichard, Jim French, 706 Larry Kreegar and Nagaraj Bagepalli for their review and comments. 708 A special thanks to Abhijit Patra for his guidance. 710 7. IANA Considerations 712 This memo includes no request to IANA. 714 8. Security Considerations 716 Security of traffic being serviced is very important in the use cases 717 described in this document. The SNs deployed as part of the SFC are 718 expected to include SFs specifically addressing the security aspect 719 either individually or in concert with other SFs. In this regard 720 organizational security policies are expected to drive the security 721 posture adapted in the SFCs. However, securing the traffic moving 722 between the SFs or SNs is not a consideration beyond the methods used 723 for moving such traffic. 725 9. References 727 9.1. Normative References 729 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 730 Requirement Levels", BCP 14, RFC 2119, March 1997. 732 9.2. Informative References 734 [I-D.ietf-sfc-problem-statement] 735 Quinn, P. and T. Nadeau, "Service Function Chaining 736 Problem Statement", draft-ietf-sfc-problem-statement-05 737 (work in progress), April 2014. 739 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 740 Address Translator (Traditional NAT)", RFC 3022, 741 January 2001. 743 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 744 NAT64: Network Address and Protocol Translation from IPv6 745 Clients to IPv4 Servers", RFC 6146, April 2011. 747 Authors' Addresses 749 Surendra Kumar 750 Cisco Systems, Inc. 751 170 W. Tasman Dr. 752 San Jose, CA 95134 754 Email: smkumar@cisco.com 756 Cesar Obediente 757 Cisco Systems, Inc. 758 7200-10 Kit Creek Rd. 759 Resarch Triangle Park, NC 27709-4987 761 Email: cobedien@cisco.com 763 Mudassir Tufail 764 Citi 765 238 King George Rd 766 Warren, NJ 07059-5153 768 Email: mudassir.tufail@citi.com 770 Sumandra Majee 771 F5 Networks 772 90 Rio Robles 773 San Jose, CA 95134 775 Email: S.Majee@f5.com 777 Claudiu Captari 778 Telstra Corporation 779 Level 15, 525 Collins Street 780 Melbourne, 3000 782 Email: Claudiu.Captari@team.telstra.com