Internet DRAFT - draft-ietf-sfc-dc-use-cases

draft-ietf-sfc-dc-use-cases







Service Function Chaining                                       S. Kumar
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Informational                                 M. Tufail
Expires: August 26, 2017                                            Citi
                                                                S. Majee
                                                             F5 Networks
                                                              C. Captari
                                                     Telstra Corporation
                                                                S. Homma
                                                                     NTT
                                                       February 22, 2017


          Service Function Chaining Use Cases In Data Centers
                     draft-ietf-sfc-dc-use-cases-06

Abstract

   Data center operators deploy a variety of layer 4 through layer 7
   service functions in both physical and virtual form factors.  Most
   traffic originating, transiting, or terminating in the data center is
   subject to treatment by multiple service functions.

   This document describes use cases that demonstrate the applicability
   of Service Function Chaining (SFC) within a data center environment
   and provides SFC requirements for data center centric use cases, with
   primary focus on Enterprise data centers.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 26, 2017.







Kumar, et al.            Expires August 26, 2017                [Page 1]

Internet-Draft              SFC DC Use Cases               February 2017


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Definition Of Terms . . . . . . . . . . . . . . . . . . . . .   4
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Traffic Types . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  North-South Traffic . . . . . . . . . . . . . . . . . . .   6
       3.2.1.  Sample north-south service function chains  . . . . .   8
       3.2.2.  Sample north-south SFC description  . . . . . . . . .   8
     3.3.  East-West Traffic . . . . . . . . . . . . . . . . . . . .   9
       3.3.1.  Sample east-west service function chains  . . . . . .  10
       3.3.2.  Sample east-west SFC description  . . . . . . . . . .  10
     3.4.  Multi-tenancy . . . . . . . . . . . . . . . . . . . . . .  11
     3.5.  SFCs in data centers  . . . . . . . . . . . . . . . . . .  11
     3.6.  Inter-datacenter SFCs . . . . . . . . . . . . . . . . . .  13
       3.6.1.  Methods for inter-datacenter SFCs . . . . . . . . . .  13
       3.6.2.  Considerations for inter-datacenter SFCs  . . . . . .  16
   4.  Drawbacks Of Existing Service Chaining Methods  . . . . . . .  17
   5.  General Requirements  . . . . . . . . . . . . . . . . . . . .  20
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  21
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     10.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22








Kumar, et al.            Expires August 26, 2017                [Page 2]

Internet-Draft              SFC DC Use Cases               February 2017


1.  Introduction

   Data centers -- enterprise, cloud or service provider -- deploy
   service nodes at various points in the network topology.  These nodes
   provide a range of service functions and the set of service functions
   hosted at a given service node may overlap with service functions
   hosted at other service nodes.

   Often, data center topologies follow a hierarchical design with core,
   aggregation, access and virtual access layers of network devices.  In
   such topologies service nodes are deployed either in the aggregation
   or access layers.  More recent data center designs utilize a folded
   CLOS topology to improve scale, performance and resilience while
   ensuring deterministic hop count between end points.  In such spine-
   leaf topologies, service nodes are often deployed at compute or
   virtual access layers as well as physical access layers.

   In large scale networks, such as carrier networks, there are many
   data centers distributed across large geographies.  Each data center
   deploys service nodes and service functions of varied types on a
   range of hardware.

   The primary purpose of deploying service functions at different
   points in the network is to apply service functions to different
   types of traffic:

   a.  Traffic originating at physical or virtual workloads in the data
       center and destined to physical or virtual workloads in the data
       center; for example three-tiered deployment of applications: web,
       application, and database tiers, with traffic flowing between the
       adjacent tiers.

   b.  Traffic originating at a location remote to the data center and
       destined to physical or virtual workloads in the data center; for
       example traffic originating at a branch or regional office,
       destined to one of the primary data centers in an Enterprise, or
       traffic originating at one of the tenants of a Service Provider
       destined to that tenants applications in the Service Provider
       data center.  Yet another variant of this type of traffic
       includes third party vendors and partners of the data center
       operator remotely accessing their applications in the data center
       over secure connections.

   c.  Traffic that is originating at a location remote to the data
       center and destined to a location remote to the data center but
       transiting through the data center; for example traffic
       originating at a mobile device destined to servers in the
       Internet routed through the data center in order to service it.



Kumar, et al.            Expires August 26, 2017                [Page 3]

Internet-Draft              SFC DC Use Cases               February 2017


   Servicing of traffic involves directing the traffic through a series
   of service functions that may be located at different places in the
   network or within a single device connected to the network or any
   combination in between.  Delivery of multiple service functions in a
   sequence, in a datacenter or among multiple data centers, thus
   creates many requirements on the overall service delivery
   architecture.  Such architectures may be termed service function
   chaining architectures while the list of service functions applied to
   the traffic is a Service Function Chain (SFC).

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Definition Of Terms

   Additional terms are defined in [I-D.ietf-sfc-problem-statement],
   which the reader may find helpful.

   End Point (EP):  A device or an application that is the ultimate
       origination or destination entity of specific traffic.  Mobile
       devices, desktop or server computers and applications running on
       them are some examples.

   Workload (WL):  A physical or virtual machine performing a dedicated
       task that consumes compute, storage, network and other resources.
       This may include web servers, database servers, storage servers
       and a variety of application servers.

   Service Function (SF):  A function that is responsible for specific
       treatment of received packets.  A Service Function can act at the
       network layer or other OSI layers.  A Service Function can be a
       virtual instance or be embedded in a physical network element.
       One of multiple Service Functions can be embedded in the same
       network element.  Multiple instances of the Service Function can
       be enabled in the same administrative domain.  A non-exhaustive
       list of Service Functions includes: firewalls, WAN and
       application acceleration, Deep Packet Inspection (DPI), server
       load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID
       injection, HTTP Header Enrichment functions, TCP optimizer, etc.

   Service Node (SN):  A virtual or physical device that hosts one or
       more service functions, which can be accessed via the network
       location associated with it.





Kumar, et al.            Expires August 26, 2017                [Page 4]

Internet-Draft              SFC DC Use Cases               February 2017


   Classifier (CF):  The entity responsible for selecting traffic as
       well as a service chain, based on policy, and forwarding the
       selected traffic on the service chain.

   Deep Packet Inspection (DPI):  Service Function that performs
       stateful inspection of traffic, identification of applications
       and policy enforcement, among others.

   Intrusion Detection and/or Prevention System (IDS/IPS):  DPI SN with
       additional capabilities to recognize malware and other threats
       and take corrective action.

   Edge Firewall (EdgeFW):  SN hosting service functions such as VPN,
       DHCP, NAT, IP-Audit, Protocol Inspection, DPI etc., with policies
       primarily focusing on threats external to the data center.

   Segment Firewall (SegFW):  SN hosting a subset of the functions in
       the EdgeFW not including VPN and is deployed to protect traffic
       crossing segments, such as VLANs.

   Application Firewall (AppFW):  Service Function that isolates traffic
       within a segment or protects from application specific threats.
       This falls into the same class as DPI but deployed much closer to
       the applications.  It is an intra-segment firewall.

   Application Delivery Controller (ADC):  Service Function that
       distributes traffic across a pool of servers (applications) for
       efficient resource utilization, application scaling as well as to
       provide high availability among others.

   Web Optimization Control (WOC):  SN hosting service functions to
       optimize the use of WAN link bandwidth, improve effective user
       throughput and latencies leading to overall improved user
       experience.  WOC includes various optimizers such as compression,
       de-duplication, congestion control, application specific
       optimizers, etc.  WOC requires peers at either end of the WAN
       link to perform optimizations.  The scope of this document is
       limited to the DC side of the WAN link.

   Monitoring (MON):  SN hosting service functions to obtain operational
       visibility into the network to characterize network and
       application performance, troubleshoot performance issues,
       optimize resource utilization, etc.

   Note: The above definitions are generalized.  Actual implementations
   may vary in scope and in a lot of cases the actual service functions
   hosted on SNs may overlap.  For instance, DPI function is not only
   implemented as a standalone service function but is also implemented



Kumar, et al.            Expires August 26, 2017                [Page 5]

Internet-Draft              SFC DC Use Cases               February 2017


   in EdgeFWs.  Likewise EdgeFw functions, such as VPN, are implemented
   in routers.  The terms used are representative of common usage and
   not absolute deployment.

3.  Use Cases

   The following sections highlight some of the most common data center
   use case scenarios and are in no way exhaustive.

3.1.  Traffic Types

   IT assets in an enterprise are consolidated into few data centers
   located centrally.  This consolidation stems from regulatory
   compliance regarding security, control on the enterprise assets,
   operational cost savings, disaster recovery strategies, etc.  The
   data center resources are accessible from any geographic location
   whether inside or outside the enterprise network.  Further,
   enterprise data centers may be organized along the lines of
   businesses, with each business treated as a tenant, thereby
   supporting multi-tenancy.

   Service provider data centers have similar requirements as the
   enterprise.  Data centers may be distributed regionally and globally
   to support the needs of their tenants.  Multi-tenancy underlines
   every consideration in such data centers: resources and assets are
   organized & managed on tenant boundaries, policies are organized
   along tenant boundaries, traffic is segregated and policies enforced
   on tenant boundaries, etc.  This is true in all "as a service"
   models: IaaS, PaaS and SaaS.

   This leads to two primary types of traffic: North-South and East-
   West, each with different service requirements.

3.2.  North-South Traffic

   North-South traffic originates from outside the data center and is
   typically associated with users - onsite, remote and VPN - conducting
   their jobs.  The traffic may also be associated with consumers
   accessing news, email, social media and other websites.  This traffic
   is typically destined to applications or resources hosted in the data
   centers.  Increasing adoption of BYOD and social networking
   applications requires traffic be analyzed, application and users be
   identified, transactions be authorized, and at the same time security
   threats be mitigated or eliminated.  To this end, various service
   functions, as illustrated in Figure 1, are deployed in different SNs
   and in many instances of those SNs, at various topological locations
   in the network.  The SNs are selected based on the policy required
   for the specific use case.



Kumar, et al.            Expires August 26, 2017                [Page 6]

Internet-Draft              SFC DC Use Cases               February 2017


                 [ End Point ] --------+
                                       |
                                       |
                                       |
                                     Border
                             +------ Router
                             |         |
                             |         |
                             +------- WOC
                             |         |
                             |         |
                             +------ EdgeFW
                             |         |
                             |         |
                             +------- MON
                             |         |
                             |         |
                             +------- ADC
                             |         |
                             |         |
                             +------ AppFW
                                       |
                                       |
                                       |
                                       +-------- [ Workload ]


        Figure 1: Service functions applied to North-South traffic

   Figure 1 shows the ordered list of SNs, from top to bottom,
   representing the flow of traffic from End Point to Workload and vice
   versa.  Traffic does not always strictly flow through all the SNs in
   that order.  Traffic flows through various permutations, of the
   subsets, of the SNs.  The connections from each of the service nodes
   to every other service node (as depicted by the vertical line to the
   left) represents the network topology required to achieve such
   traffic flows.  Each permutation represents a service function chain.

   Certain ordering of the SNs naturally exists due to the nature of the
   functions applied.  For instance, WOC is not effective on VPN traffic
   - requires VPN termination prior to WOC.  Likewise EdgeFW may not be
   effective on WOC traffic.  Vendor implementations of SNs enable
   choices for various deployments and ordering.  For instance EdgeFW
   detects the presence of WOC through TCP options or explicit
   configuration and hence WOC may even be deployed on the traffic that
   has passed through the EdgeFW.  Constructing service function chains
   in the underlay network thus requires complex topology.




Kumar, et al.            Expires August 26, 2017                [Page 7]

Internet-Draft              SFC DC Use Cases               February 2017


3.2.1.  Sample north-south service function chains

   SFC-1.  EdgeFW

   SFC-2.  EdgeFW : ADC

   SFC-3.  EdgeFW : ADC : AppFW

   SFC-4.  WOC : EdgeFW : ADC : AppFW

   SFC-5.  WOC : EdgeFW : MON : ADC : AppFW

3.2.2.  Sample north-south SFC description

   Sample service chains numbered SFC-1 through SFC-5 capture the
   essence of services required on the north-south traffic.

   SFC-1:  This represents the simplest of use cases where a remote or
       mobile worker accesses a specific data center server.  Traffic
       comes into the data center on VPN and is terminated on the
       EdgeFW.  EdgeFW subjects the traffic to its policies, which may
       in turn select other service functions such as DPI, IPS/IDS,
       hosted on the EdgeFW.  As an alternative deployment, some of
       these service functions may be hosted outside the EdgeFW and
       reachable via VLAN segments.  EdgeFW policy permitting, traffic
       is allowed to its destination.

   SFC-2:  This is an extension of SFC-1.  Unlike SFC-1, traffic is
       destined to a data center application that is front-ended by an
       ADC.  The EdgeFW performs its function as before and the traffic
       is allowed, policy permitting.  This traffic reaches its virtual
       destination, the ADC.  ADC, based on local policy, which includes
       among other things predictors to select the real destination,
       determines the appropriate application instance.  ADCs are
       stateful and ensure the return traffic passes through them by
       performing source NAT.  Since many applications require the
       original source address, ADC preserves the original address in
       extension headers of the HTTP protocol.  Traffic is then
       forwarded on to the ultimate destination - the real application
       workload.

   SFC-3:  This extends SFC-2.  The segment where the application server
       resides may be shared with other applications and resources.  To
       segregate these applications and resources further, fine grain
       policies may be required and are enforced via a security
       appliance such as the AppFW.  As a consequence AppFW first
       services the traffic from the load balancer before it is
       forwarded to its ultimate destination, the application server.



Kumar, et al.            Expires August 26, 2017                [Page 8]

Internet-Draft              SFC DC Use Cases               February 2017


   SFC-4:  This is a variant of SFC-3 with WOC being part of the chain.
       This represents the use case where users at a branch office
       access the data center resources.  The WOC SNs located at either
       end of the WAN optimize the traffic first.  The WOC located in
       the datacenter requires a mechanism to steer traffic to it while
       not deployed inline with the traffic.  This is achieved either
       with PBR or VLAN stitching.  WOC treated traffic is subject to
       firewall policies, which may lead to the application of SFs such
       as protocol inspection, DPI, IDS/IPS and then forwarded to its
       virtual destination, the ADC.

   SFC-5:  This is similar to SFC-4.  An additional service - MON, is
       used to collect and analyze traffic entering and leaving the data
       center.  This monitoring and analysis of traffic helps maintain
       performance levels of the infrastructure to achieve service level
       agreements, particularly in SP data centers.

3.3.  East-West Traffic

   This is the predominant traffic in data centers today.  Server
   virtualization has led to the new paradigm where virtual machines can
   migrate from one server to another across the datacenter.  This
   explosion in east-west traffic is leading to newer data center
   network fabric architectures that provide consistent latencies from
   one point in the fabric to another.

   The key difference with east-west from the north-south traffic is in
   the kind of threats and the security needs thereof.  Unlike north-
   south traffic where security threats may come from outside the data
   center, any threat to this traffic comes from within the data center.



          +-- ADC1 --- MON1 --- AppFW1 --- Workload1(Web)
         /
   SegFW ---- ADC2 --- MON2 --- AppFW2 --- Workload2(App)
         \
          +-- ADC3 --- MON3 --- AppFW3 --- Workload3(DB)


         Figure 2: Service functions applied to East-West traffic

   Service functions applied on the east-west traffic is captured in a
   generalized fashion in Figure 2.  ADCs, although shown as isolated
   SNs in each of the tiers, is often consolidated into a smaller number
   of ADC SNs shared among the different tiers.  Virtual IP addresses or
   VIPs in such ADCs represent the individual ADC instances.  Flows are




Kumar, et al.            Expires August 26, 2017                [Page 9]

Internet-Draft              SFC DC Use Cases               February 2017


   terminated at the VIPs and re-initiated towards the load balanced
   workloads.

   As an example, HTTP GET request arriving at ADC1 is load balanced on
   to a webserver pool represented as Workload1.  In order to respond to
   the GET request, Workload1 generates traffic to an application server
   in a pool represented as Workload2 through ADC2, which load balances
   the webserver initiated traffic.  Likewise, the application server,
   as part of processing the webserver's request generates traffic to a
   DB server pool represented as Workload3 through ADC3, which load
   balances the application server initiated traffic.  The traffic
   arriving at different ADCs, in this example, can be arriving at
   different VIPs, instead, each corresponding to its tier but belonging
   to the same ADC.  In this sense, traffic flow across the tiers is VIP
   centric as opposed to device instance.

   Traffic traversing between the ADC and the selected server in each
   tier, is subject to monitoring and one or more application firewalls
   specializing in different kinds and aspects of threats.  These again
   can be shared just as the ADC due to steering mechanisms although it
   adds complexity in network configuration.

3.3.1.  Sample east-west service function chains

   SFC-6.  SegFW : ADC : MON : AppFW

3.3.2.  Sample east-west SFC description

   SFC-6:  In a typical three tiered architecture, requests coming to a
       webserver trigger interaction with application servers, which in
       turn trigger interaction with the database servers.  It has to be
       noted that each of these tiers are deployed in their own segments
       or zones for isolation, optimization and security.  SegFW
       enforces the security policies between the tiers and facilitates
       isolation at the segment level or address space re-use via NAT
       deployment.  ADC provides the distribution, scale and resiliency
       to the applications while the AppFW protects and isolates traffic
       within the segment in addition to enforcing application specific
       security policies.  Finally, monitoring service enables
       visibility into application traffic, which in turn is used to
       maintain application performance levels.










Kumar, et al.            Expires August 26, 2017               [Page 10]

Internet-Draft              SFC DC Use Cases               February 2017


3.4.  Multi-tenancy

   Multi-tenancy is relevant in both enterprise as well as service
   provider data centers although it is the primary differentiator
   between service provider (SP) and enterprise datacenter.  Enterprises
   treat organizations or business units within the enterprise as
   tenants and thus require tenant aware service models.

   Multi-tenant service delivery is achieved in two primary ways: a) SNs
   themselves are tenant aware - every SN is built to support multiple
   tenants. b) SN instances are dedicated for each tenant.  In both the
   cases, the SP manages the SNs.

   To support multi-tenant aware service functions or SNs, traffic being
   serviced by a service function chain has to be identified by a tenant
   identifier.  A tenant identifier has to be carried along with the
   traffic to be serviced.  It is typical of tenant assets to be
   deployed in an isolated layer2 or layer3 domain such as VLAN, VXLAN
   or VRF.  It has to be noted that the SNs themselves maybe deployed in
   different domains to suit the deployment needs of the SP and hence
   using the domain in which the SN is deployed is not an option.
   Although such a model is feasible it removes the deployment
   flexibility for the service providers.

3.5.  SFCs in data centers


























Kumar, et al.            Expires August 26, 2017               [Page 11]

Internet-Draft              SFC DC Use Cases               February 2017


                                   [ EP/WL ]
                                       |
                                       |
                                       |
                                     Border                       -
                             +------ Router                       |
                             |         |
                             |         |
                             +------- WOC                         A
                             |         |                          C  S
                             |         |                          C  F
                             +------ EdgeFW                       E  C
                             |         |                          S  s
                             |         |                          S
                             +------- MON
                             |         |
                             |         |                          |
                             +------ SegFW                        -
                                    /  |  \                       |
                                   /   |   \
                          +-------+    |    +-------+             A
                          |            |            |             P
                          |            |            |             P
                         ADC          ADC          ADC            L
                          |            |            |             I  S
                          |            |            |             C  F
                         MON          MON          MON            A  C
                          |            |            |             T  s
                          |            |            |             I
                        AppFW        AppFW        AppFW           O
                          |            |            |             N
                          |            |            |
                          |            |            |             |
                     [ WL/Web ]   [ WL/App ]    [ WL/DB ]         -



             Figure 3: Service function chains in data center

   Figure 3 shows the global view of SFCs applied in an enterprise or
   service provider data center.  At a high level the SFCs can be
   broadly categorized into two types:

   1.  Access SFCs

   2.  Application SFCs





Kumar, et al.            Expires August 26, 2017               [Page 12]

Internet-Draft              SFC DC Use Cases               February 2017


   Access SFCs are focused on servicing traffic entering and leaving the
   data center while Application SFCs are focused on servicing traffic
   destined to applications.

   Service providers deploy a single "Access SFC" and multiple
   "Application SFCs" for each tenant.  Enterprise data center operators
   on the other hand may not have a need for Access SFCs depending on
   the size and requirements of the enterprise.  Where such Access SFCs
   are indeed needed, such as large enterprises, the operator may deploy
   a bare minimum Access SFC instead.  Such simple Access SFCs include
   WOC and VPN SFs to support the branch and mobile user traffic while
   at the same time utilizing the security policies in the application
   SFCs.  The latter is the case in de-perimetrized network
   architectures where security policies are enforced close to the
   resources and applications as opposed to the WAN edge.

3.6.  Inter-datacenter SFCs

   In carrier networks, operators may deploy multiple data centers
   dispersed geographically.  Each data center may host different types
   of service functions.  For example, latency sensitive or high usage
   service functions are deployed in regional data centers while other
   latency tolerant, low usage service functions are deployed in global
   or central data centers.  In such deployments, SFCs may span multiple
   data centers and enable operators to deploy services in a flexible
   and inexpensive way.  These SFCs are referred to as the inter-
   datacenter SFCs in this draft.

3.6.1.  Methods for inter-datacenter SFCs

   The following are two methods to construct inter-datacenter SFCs:

   1.  Inter-datacenter SFCs with multiple SFC domains

   2.  Inter-datacenter SFCs with a single SFC domain
















Kumar, et al.            Expires August 26, 2017               [Page 13]

Internet-Draft              SFC DC Use Cases               February 2017


                   -----+
     [ Workload ]----+  | incoming
                     |  V      traffic
                   .--.
                  (    )-.
                .'        )
               (  Internet )
                (        -'
                 '-(     )
                    '---'
                     |
                +----|--------------------+
                |    |         SFC domain |
                |    |      +---------+   |
                | +-----+   |         |   |
                | | C F |---+   DC    |   |
                | +-----+   |         |   |
                |    |      +---------+   |
                +----|--------------------+
                     |
                +----|--------------------+
                |    |         SFC domain |
                |    |      +---------+   |
                | +-----+   |         |   |
                | | C F |---+   DC    |   |
                | +-----+   |         |   |
                |    |      +---------+   |
                +----|--------------------+
                     |
                  A  |
      outgoing    |  +-----------[ End Point ]
          traffic +------


         Figure 4: Inter-datacenter SFC with multiple SFC domains

   Figure 4 shows inter-datacenter SFC with multiple SFC domains.  In
   this method, services are provided by SFCs spanning multiple
   independent SFC domains.  SFC management is limited to each domain:
   control plane is constrained to its SFC domain and SFCs are
   fragmented and initiated in each SFC domain.  If both data centers
   are located in-line, a method of forwarding packets between data
   centers is required.








Kumar, et al.            Expires August 26, 2017               [Page 14]

Internet-Draft              SFC DC Use Cases               February 2017


                   -----+
     [ Workload ]----+  | incoming
                     |  V      traffic
                   .--.
                  (    )-.
                .'        )
               (  Internet )
                (        -'
                 '-(     )
                    '---'
                     |
                  +-----+
     +------------| C F |-------------+
     | SFC domain +-----+             |
     |               |                |
     |        +-------------+         |
     |        |             |         |
     |        |     D C     |         |
     |        |             |         |
     |        +-------------+         |
     |               |                |
     |               |                |
     |               |                |
     |        +-------------+         |
     |        |             |         |
     |        |     D C     |         |
     |        |             |         |
     |        +-------------+         |
     |               |                |
     |            +-----+             |
     +------------| C F |-------------+
                  +-----+
                     |
                  A  |
      outgoing    |  +-----------[ End Point ]
          traffic +------


          Figure 5: Inter-datacenter SFC with single SFC domains

   Figure 5 shows inter datacenter SFC with a single SFC domain.  In
   this method, services are provided across multiple data centers,
   which are connected with virtualized paths and grouped into a single
   SFC domain.

   In multiple SFC domain case, it is simple to control and manage the
   SFC domain.  However, it is difficult to hand over context data
   between data centers, whether context data are conveyed out of band -



Kumar, et al.            Expires August 26, 2017               [Page 15]

Internet-Draft              SFC DC Use Cases               February 2017


   in the control plane or, in band - with traffic.  In addition, the
   cost of classification is high, as it is performed twice in each SFC
   domain - once in each direction.  On the other hand, in the single
   SFC domain case, it is easy to hand over context data between data
   centers, but control of SFC domains becomes complex as integrated
   operation across multiple data centers is required.

3.6.2.  Considerations for inter-datacenter SFCs

   Inter-datacenter SFC must consider many design aspects, two important
   among them are :

   1.  Handing over context data

   2.  Multiple classification points

   Handing over context data :  Metadata sharing among SFC components
       enables many use cases and services.  If context data cannot be
       passed across data centers, some services provided by SFC would
       be restricted.  For example, it is difficult to create SFCs
       across multiple data centers because service functions cannot
       simply share information, with each other, between the data
       centers.

   Multiple classification points :  In a large SFC domain containing
       multiple datacenters distributed over large geographies,
       classification of incoming traffic and outgoing traffic may
       happen at different points, depending on the deployment model.
       If classification of incoming traffic and outgoing traffic are
       forced to happen at the same point, as shown in Figure 6, all
       traffic may traverse long distances leading to inefficient
       resource consumption and increased latencies.



















Kumar, et al.            Expires August 26, 2017               [Page 16]

Internet-Draft              SFC DC Use Cases               February 2017


   <Network Structure>


                         +----+
    [ EP ]---------------+ CF +-----------------[ WL ]
                         ++--++
                          |  |
                 +--------+  +--------+
                 |                    |
            +----+----+          +----+----+
            |         |          |         |
            |   DC    |          |    DC   |
            |         |          |         |
            +---------+          +---------+

                  <-- long distance -->

   =========================================================

   <Traffic Flow>

    [ EP ]    [ DC ]     [ CF ]     [ DC ]      [ WL ]

      *--------------------+
                           |
                +----------+
                |
                +---------------------+
                                      |
                                      +----------->

                |<-------->|
              traffic turn back


      Figure 6: Inter-datacenter SFC with single classification point

4.  Drawbacks Of Existing Service Chaining Methods

   The above use cases are realized in a traditional fashion and are not
   viable in the evolving hybrid data centers with virtual and physical
   assets.  The following are some of the obvious short comings of
   existing SFC methods exposed by the above use cases.

   DB-1.   Policy based purely on VLANs is no longer sufficient.
           Connecting SNs to each other to construct a service chain
           thus makes it very static and removes deployment flexibility.
           As can be seen from the sample north-south service chains, a



Kumar, et al.            Expires August 26, 2017               [Page 17]

Internet-Draft              SFC DC Use Cases               February 2017


           large number of VLANs not only have to be stitched in a
           certain fashion to achieve a basic SFC, it is simply not
           flexible to share the SNs among different SFCs as even simple
           sharing among a few SNs becomes intractable from basic
           configuration perspective let alone future changes or
           manageability aspects.

   DB-2.   Traffic does not always have to be steered through all the
           SNs of a traditional VLAN stitched service chain.  In
           Figure 1, traffic from the border router is not always
           necessary to flow through the WOC as remote or mobile worker
           may not have a WOC peer deployed.  Connecting multiple VLANs
           among service nodes to overcome to achieve this only
           aggravates the problem of deployment and manageability.
           Truly, there exists a need for dynamically determining the
           next sub SFC at such branching points to avoid forcing all
           traffic through the same SFC.

   DB-3.   Virtual environments require the virtual SNs be migration
           capable just like the compute workloads.  As a consequence it
           is simply not feasible to continue VLAN stitching in the
           hybrid data centers.  Every time a virtual SN migrates, such
           as the AppFW in Figure 1 and Figure 2, the operator has to
           ensure the VLANs are provisioned in the destination.
           Further, stretching the VLANs across the network may not be
           an option for the operator or even worse the virtual SN may
           be L3 hop away from the previous SN.

   DB-4.   Policy Based Routing (PBR) can be used to move traffic to
           SNs.  Although it provides a much better granularity than
           VLAN stitching it suffers from the requirement to configure
           such policies all along the path to the SNs.  In Figure 1, if
           WOC is multiple hops away from the border router, all network
           elements in between border router and WOC need to be
           configured with consistent policies.

   DB-5.   Source NAT (SNAT) is required by some SNs, such as ADC in
           Figure 1, in order to ensure traffic sent to the load
           balanced servers pass through the ADC in reverse direction.
           However, SNAT removes the ability to detect the originator of
           the traffic.  Using HTTP extension header to pass originator
           information is not only an overhead but addresses only one
           specific protocol.

   DB-6.   Static service chains do not allow for modifying the SFCs as
           they require the ability to add SNs or remove SNs to scale up
           and down the service capacity.  Likewise the ability to
           dynamically pick one among the many SN instance is not



Kumar, et al.            Expires August 26, 2017               [Page 18]

Internet-Draft              SFC DC Use Cases               February 2017


           available.  For instance, WOC must scale to support the high
           data rate of traffic flowing to the data center.  Likewise,
           AppFWs must scale up to not impact the workload throughput.
           Further they may be required to scale within tenant
           boundaries.

   DB-7.   Static SFCs constructed over the under lay network cannot
           pass metadata to the SNs.  Border Router in Figure 1 cannot
           pass policy based tags derived locally at the start of the
           SFC all the way through the SFC.  Such metadata is necessary
           to enforce consistent security policies across the network,
           as one example.

   DB-8.   In multi-tenant deployments, the segment on which the SN is
           deployed may not correspond to the segment assigned to the
           tenant in which the workloads are hosted.  In Figure 2, AppFW
           may be deployed on a different segment than the Workload.  As
           a consequence, it is not viable to derive the tenant segment
           simply based on the tag associated with the incoming traffic
           at the AppFW.  This ultimately prevents the ability to have
           the same SN serve multiple tenants.  Forcing the SN to be on
           the same segment as the tenants' workload limits deployment
           flexibility.

   DB-9.   Traffic may originate in a physical or virtual network or
           transit these networks before being delivered to the SNs for
           servicing.  The following is very complex to achieve with the
           existing SFC mechanism, primarily due to very conflicting
           nature of their environments: physical and static vs. virtual
           and dynamic.

           A.  Physical SN servicing traffic originating in the virtual
               access network.

           B.  Virtual SN servicing traffic originating in the physical
               network.

   DB-10.  Although SNs are purpose built service appliances, it is
           neither a requirement nor an indication of how service
           functions are implemented in emerging data centers with
           commodity compute and storage capabilities.  AppFW in
           Figure 1, for instance, may be built and deployed as a
           virtual SN.  Further, SFCs are limited to exclusively
           physical or virtual SNs and not a mix.  This excludes the
           ability to combine the benefits offered by physical SNs with
           the flexibility and agility of the virtual SNs.  The EdgeFW
           in Figure 1, for instance, may be a purpose built SN to take
           advantage of SFs implemented in hardware while the AppFW may



Kumar, et al.            Expires August 26, 2017               [Page 19]

Internet-Draft              SFC DC Use Cases               February 2017


           be a virtual SN deployed to be close to the virtual workload
           and may even move with the workload in the virtual
           environment.

   DB-11.  Troubleshooting is one of the predominant issues plaguing SFC
           deployments.  The reasons range from misconfiguration at
           different elements in the network that are responsible for
           directing traffic to the service nodes, to, tracking the
           traffic paths starting from the point of entry into the DC to
           the point of exit to the application through various SNs.
           When desired services are not effective on certain traffic,
           determining the reason is simply not viable in a large scale
           deployment.  Figure 3 provides a view of the complexity in
           terms of the permutations of the SFCs, their paths in the
           network and the configuration in the network elements
           required and managed for proper operation.

5.  General Requirements

   The above use cases and the drawbacks thereof lead to the following
   general requirements in today's evolving hybrid datacenters to apply
   SFCs to traffic.

   GR1.   SFC polices MUST be applicable at the edges - network elements
          as well as the workloads.

   GR2.   SFC policies MUST be applicable to either Ingress or Egress
          traffic at network elements as well as workloads.

   GR3.   SFC MUST support virtual as well as physical SNs.

   GR4.   SFC SHOULD support the ability to mix virtual and physical SNs
          in the same SFC.

   GR5.   SFC SNs MUST be deployable L2 or L3 hop away from the SFC
          application points - network elements or workloads.

   GR6.   SFC traffic MUST be allowed to follow paths not constrained by
          the underlying static network topology.

   GR7.   SFC SNs MUST be able identify tenant traffic without being
          tied to the underlying topology

   GR8.   SFCs MUST support the ability to pass metadata among the SNs
          or between the SNs and the network elements.

   GR9.   A composite SFC SHOULD be achievable by way of joining sub
          SFCs, branching to sub SFCs where necessary.



Kumar, et al.            Expires August 26, 2017               [Page 20]

Internet-Draft              SFC DC Use Cases               February 2017


   GR10.  SFCs SHOULD NOT require SNAT inside the SFs to attract traffic
          back to them

   GR11.  SFCs SHOULD have the ability to choose SN instances
          dynamically, prior to forwarding traffic to them.

   GR12.  An OAM mechanism to easily troubleshoot as well as validate
          the paths traversed by the SFCs SHOULD be supported.

6.  Acknowledgements

   The authors would like to thank Paul Quinn, Jim Guichard, Jim French,
   Larry Kreeger and Nagaraj Bagepalli for their review and comments.

   A special thanks to Abhijit Patra for his guidance.

7.  Contributors

   The following people are active contributors to this draft, they have
   provided content and review feedback :

   Cesar Obediente
   Cisco Systems, Inc.
   Email: cobedien@cisco.com

   Kengo Naito
   NTT
   Email: naito.kengo@lab.ntt.co.jp

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

   Security of traffic being serviced is very important in the use cases
   described in this document.  The SNs deployed as part of the SFC are
   expected to include SFs specifically addressing the security aspect
   either individually or in concert with other SFs.  In this regard
   organizational security policies are expected to drive the security
   posture adapted in the SFCs.  However, securing the traffic moving
   between the SFs or SNs is not a consideration beyond the methods used
   for moving such traffic.








Kumar, et al.            Expires August 26, 2017               [Page 21]

Internet-Draft              SFC DC Use Cases               February 2017


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

10.2.  Informative References

   [I-D.ietf-sfc-problem-statement]
              Quinn, P. and T. Nadeau, "Service Function Chaining
              Problem Statement", draft-ietf-sfc-problem-statement-13
              (work in progress), February 2015.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              DOI 10.17487/RFC3022, January 2001,
              <http://www.rfc-editor.org/info/rfc3022>.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011, <http://www.rfc-editor.org/info/rfc6146>.

Authors' Addresses

   Surendra Kumar
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA  95134

   Email: smkumar@cisco.com


   Mudassir Tufail
   Citi
   238 King George Rd
   Warren, NJ  07059-5153

   Email: mudassir.tufail@citi.com









Kumar, et al.            Expires August 26, 2017               [Page 22]

Internet-Draft              SFC DC Use Cases               February 2017


   Sumandra Majee
   F5 Networks
   90 Rio Robles
   San Jose, CA  95134

   Email: S.Majee@f5.com


   Claudiu Captari
   Telstra Corporation
   Level 15, 525 Collins Street
   Melbourne  3000

   Email: Claudiu.Captari@team.telstra.com


   Shunsuke Homma
   NTT
   3-9-11, Midori-cho Musashino-shi
   Tokyo  180-8585
   Japan

   Email: homma.shunsuke@lab.ntt.co.jp




























Kumar, et al.            Expires August 26, 2017               [Page 23]