Subject: [sfc] Some concerns about draft-ietf-sfc-architecture

From: Stewart Bryant <[email-masked]>
Date: Wed, 12 Nov 2014 20:05:17 +0000

SB> This document lacks the precision and that I would have hoped for
SB> in an architecture. I understand that the this was deliberate
SB> in order to allow implementation flexibility, but I don't
SB> buy that.
SB>
SB> What we have here is a type of layered network, and whilst
SB> verbal discussions have refuted that, you have many references
SB> to overlay topologies.
SB>
SB> This would be better understood if you described it as a layered
SB> system, if you only used generalized the components with fully
SB> functionality, and then explained which could be NULL. In the
SB> case of sub-functional components they should not be part of the
SB> core architecture, but the techniques used to create a full function
SB> component by assistance (the proxy) described outside the main
SB> architecture.
SB>
SB> I understand that in part the approach used here was to allow
SB> a mixture of implementation styles - the concept of explicit
SB> and implicit SFE - with network layer constructs supplying the
SB> implicit SFE. However it would be better to think of the use
SB> of implicit SFE as a type of network recursion in which the
SB> the encapsulator (which I think is distinct from the classifier)
SB> chooses how to encode the SFP on the packet.
SB>
SB> I have a nagging concern about the way that the terms packets is
SB> used in this text. The way it is used one would expect that there
SB> is a one for one mapping between input and output packets, but that
SB> is surely not the case. A trivial point is the case where an SF
SB> needs to defragment. Although at the physical layer the units are
SB> packets, there may surely be higher order constructs traveling
SB> between SFs.

  Service Function Chaining (SFC) Architecture
                      draft-ietf-sfc-architecture-02

Abstract

    This document describes an architecture for the specification,
sb> an arch or THE arch?
    creation, and ongoing maintenance of Service Function Chains (SFC) in
    a network.  It includes architectural concepts, principles, and
    components used in the construction of composite services through
    deployment of SFCs.  This document does not propose solutions,
    protocols, or extensions to existing protocols.

1.  Introduction

    This document describes an architecture used for the creation and
sb> and or THE
    ongoing maintenance of Service Function Chains (SFC) in a network.
    It includes architectural concepts, principles, and components.

    An overview of the issues associated with the deployment of end-to-
    end service function chains, abstract sets of service functions and
    their ordering constraints that create a composite service and the
    subsequent "steering" of traffic flows through said service
    functions, is described in [I-D.ietf-sfc-problem-statement].

    This architecture presents a model addressing the problematic aspects
    of existing service deployments, including topological independence
    and configuration complexity.

    Service function chains enable composite services that are
    constructed from one or more service functions.

1.1.  Scope

    This document defines a framework to realize Service Function
    Chaining (SFC) with minimum requirements on the physical topology of
    the network.  The proposed solution relies on initial packet
    classification.  Packets initially classified for handling by a set
    of Service Functions (SFs) in the SFC-enabled domain are then
    forwarded to that set of SFs for processing.

SB> Are you allowed to reclassify, or do staged classification?
SB> Yes you are - you say so later - but that is not implied
SB> by the above.

    This document does not make any assumption on the deployment context.
    The proposed framework covers both fixed and mobile networks.

SB> Given that you make no deployment context assumption, surely
SB> the followup mobile/fixed specific is not relevant.

    The architecture described herein is assumed to be applicable to a
    single network administrative domain.  While it is possible for the
    architectural principles and components to be applied to inter-domain
    SFCs, these are left for future study.

1.2.  Assumptions

    The following assumptions are made:

    o  Not all SFs can be characterized with a standard definition in
       terms of technical description, detailed specification,
       configuration, etc.

    o  There is no global or standard list of SFs enabled in a given
       administrative domain.  The set of SFs varies as a function of the
       service to be provided and according to the networking
       environment.

    o  There is no global or standard SF chaining logic.  The ordered set
       of SFs that needs to be enabled to deliver a given service is
       specific to each administrative entity.

SB> Surely it is application specific even within an admistration?

  o  The chaining of SFs and the criteria to invoke them are specific
       to each administrative entity that operates an SF-enabled domain.

SB? see previous

Halpern & Pignataro      Expires March 24, 2015                 [Page 3]

Internet-Draft              SFC Architecture              September 2014

    o  Several SF chaining policies can be simultaneously applied within
       an administrative domain to meet various business requirements.

    o  No assumption is made on how FIBs and RIBs of involved nodes are
       populated.

    o  How to bind traffic to a given SF chain is policy-based.

1.3.  Definition of Terms

    Network Service:  An offering provided by an operator that is
         delivered using one or more service functions.  This may also be
         referred to as a composite service.  The term "service" is used
         to denote a "network service" in the context of this document.

         Note: Beyond this document, the term "service" is overloaded
         with varying definitions.  For example, to some a service is an
         offering composed of several elements within the operator's
         network, whereas for others a service, or more specifically a
         network service, is a discrete element such as a firewall.
         Traditionally, such services (in the latter sense) host a set of
         service functions and have a network locator where the service
         is hosted.

SB> I think that you probably need an explicit definition of service.
SB> I find the text in the definition of NS self referential which is
SB> not helpful.

  Classification:  Locally instantiated policy and customer/network/
         service profile matching of traffic flows for identification of
         appropriate outbound forwarding actions.

SB> Isn't it really

SB> Locally instantiated matching of traffic flows against policy for
SB> subsequent application of the required set of network service functions.
SB> The policy may be ustomer/network/service specific.

  Classifier:  An element that performs Classification.

SB> A network element perhaps?

  Service Function Chain (SFC):  A service function chain defines a set
         of abstract service functions and ordering constraints that must

SB> Isn't the SFC also ordered?

         be applied to packets and/or frames selected as a result of
         classification.
SB> Packets, or higher order constructs like flows? You cannot
SB> do some of the SFs packet by packet

         The implied order may not be a linear
         progression as the architecture allows for SFCs that copy to
         more than one branch, and also allows for cases where there is
         flexibility in the order in which service functions need to be
         applied.  The term service chain is often used as shorthand for
         service function chain.

SB> See my earlier not about the apparently more restricted definition
SB> I think that you need to make the generalization clearer earlier.

  Service Function (SF):  A function that is responsible for specific
         treatment of received packets.  A Service Function can act at
         various layers of a protocol stack (e.g., at the network layer
         or other OSI layers).  As a logical component, a Service
         Function can be realized as a virtual element or be embedded in
         a physical network element.  One or multiple Service Functions
SB> multiple or more?
        can be embedded in the same network element.  Multiple

Halpern & Pignataro      Expires March 24, 2015                 [Page 4]

Internet-Draft              SFC Architecture              September 2014

         occurrences of the Service Function can exist in the same
         administrative domain.

         One or more Service Functions can be involved in the delivery of
         added-value services.  A non-exhaustive list of abstract Service
         Functions includes: firewalls, WAN and application acceleration,
         Deep Packet Inspection (DPI), LI (Lawful Intercept), server load
         balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296],
         HOST_ID injection, HTTP Header Enrichment functions, TCP
         optimizer.

SB> Not sure those are abstract SFs, surely they are explicit?

         An SF may be SFC encapsulation aware, that is it receives and
         acts on information in the SFC encapsulation, or unaware, in
         which case data forwarded to the SF does not contain the SFC
         encapsulation.

    Service Function Forwarder (SFF):  A service function forwarder is
         responsible for delivering traffic received from the network to
         one or more connected service functions according to information
         carried in the SFC encapsulation, as well as handling traffic
         coming back from the SF.  Additionally, a service function
         forwarder is responsible for delivering traffic to a classifier
         when needed and supported, mapping out traffic to another SFF
         (in the same or different type of overlay), and terminating the
         SFP.

SB> In these days of NFV it may not be received from the network.
SB> Surely the traffic is native until it gets to a classifier. The
SB> way you have it here it looks like the first element is the SFF
SB> but I am not sure that is the case.
SB> Perhaps: A service function forwarder is responsible for forwarding
SB> traffic between service functions.

  Metadata:  provides the ability to exchange context information
         between classifiers and SFs and among SFs.

SB> I think the first noun is missing in the above, but in any case
SB> I think a more complete definition is needed.

  Service Function Path (SFP):  The SFP provides a level of indirection
         between the fully abstract notion of service chain as a sequence
         of abstract service functions to be delivered, and the fully
         specified notion of exactly which SFF/SFs the packet will visit
         when it actually traverses the network.  By allowing the control
         components to specify this level of indirection, the operator
         may control the degree of SFF/SF selection authority that is
         delegated to the network.

SB> You have not defined control components.
SB> I think "notion" is a redundant term.
SB> I am somewhat confused by your definition.
SB> Is this really about the mapping of packets between an arbitrary
SB> member of an SF to a specific instance of the SF?

  SFC Encapsulation:  The SFC Encapsulation provides at a minimum SFP
         identification, and is used by the SFC-aware functions, such as
         the SFF and SFC-aware SFs.  The SFC Encapsulation is not used
         for network packet forwarding.  In addition to SFP
         identification, the SFC encapsulation carries data plane context
         information, also referred to as metadata.

SB> Surely the "SFC E is used to attach the information needed to
SB> direct the packet through the ordered set of SFs, together with
SB> associated metadata. An additional  network layer encapsulation is needed
SB> to carry the packet over the physical network.

  Rendered Service Path (RSP):  The Service Function Path is a
         constrained specification of where packets using a certain
         service chain must go.  While it may be so constrained as to

Halpern & Pignataro      Expires March 24, 2015                 [Page 5]

Internet-Draft              SFC Architecture              September 2014

         identify the exact locations, it can also be less specific.
         Packets themselves are of course transmitted from and to
         specific places in the network, visiting a specific sequence of
         SFFs and SFs.  This sequence of actual visits by a packet to
         specific SFFs and SFs in the network is known as the Rendered
         Service Path (RSP).  This definition is included here for use by
         later documents, such as when solutions may need to discuss the
         actual sequence of locations the packets visit.

SB> Not sure of the wisdom of including a definition for the future, since
SB> when you use it you may need to tune the definition.

  SFC-enabled Domain:  A network or region of a network that implements
         SFC.  An SFC-enabled Domain is limited to a single network
         administrative domain.

    SFC Proxy:  Removes and inserts SFC encapsulation on behalf of an
         SFC-unaware service function.  SFC proxies are logical elements.

SB> Not sure considering then as logical is quite right. It depends
SB> on the mapping of the operation to the physical. I could see
SB> cases where they are physical. Surely the point is that they
SB> may be co-located with another network function such as a router
SB> an operating system component such as a hypervisor.

  2.  Architectural Concepts

    The following sections describe the foundational concepts of service
    function chaining and the SFC architecture.

    Service Function Chaining enables the creation of composite (network)
    services that consist of an ordered set of Service Functions (SF)
    that must be applied to packets and/or frames selected as a result of
    classification.  Each SF is referenced using an identifier that is
    unique within an SF-enabled domain.  No IANA registry is required to
    store the identity of SFs.

SB> I am still worried about using packets. Obviously we operate on
SB> pkts, but the operation may require the reconstuction of some
SB> packet grouping typically some element of a flow before the operation
SB> can be performed. A trivial example is defragmenting a packet group
SB> but since we are dealing with abstract SFs we cannot specify the
SB> the unit of operation.

     Service Function Chaining is a concept that provides for more than
    just the application of an ordered set of SFs to selected traffic;
    rather, it describes a method for deploying SFs in a way that enables
    dynamic ordering and topological independence of those SFs as well as
    the exchange of metadata between participating entities.

SB> The above is a bit late in the text. I think it needs to go earlier.

  2.1.  Service Function Chains

    In most networks, services are constructed as abstract sequences of
SB> I don't think that are abstract in this context.
SB> Are you talking about traditional (current physically instantiated
SB> SFCs in the previous sentence?

    SFs that represent SFCs.  At a high level, an SFC is an abstracted
    view of a service that specifies the set of required SFs as well as
    the order in which they must be executed.

SB> Again I am not sure "abstrated view" is right here

    Graphs, as illustrated in
    Figure 1, define an SFC, where each graph node represents the
    required existence of at least one abstract SF.  Such graph nodes
    (SFs) can be part of zero, one, or many SFCs.  A given graph node
    (SF) can appear one time or multiple times in a given SFC.

SB> Not sure that graphs is right, since you only show the case
SB> of a linear chain. The construct you are going to use is
SB> graph, but that is not what the figure shows.

    SFCs can start from the origination point of the service function
    graph (i.e.: node 1 in Figure 1), or from any subsequent node in the
    graph.

SB> OK so are you trying to distinguish between physically and
SB> SFC (the new technology) instantiated SFCS?

    SFs may therefore become branching nodes in the graph, with

Halpern & Pignataro      Expires March 24, 2015                 [Page 6]

Internet-Draft              SFC Architecture              September 2014

    those SFs selecting edges that move traffic to one or more branches.
    An SFC can have more than one terminus.

SB> Again that is not what your figure shows.

      ,-+-.         ,---.          ,---.          ,---.
     /     \       /     \        /     \        /     \
    (   1   )+--->(   2   )+---->(   6   )+---->(   8   )
     \     /       \     /        \     /        \     /
      `---'         `---'          `---'          `---'

      ,-+-.         ,---.          ,---.          ,---.          ,---.
     /     \       /     \        /     \        /     \        /     \
    (   1   )+--->(   2   )+---->(   3   )+---->(   7   )+---->(   9   )
     \     /       \     /        \     /        \     /        \     /
      `---'         `---'          `---'          `---'          `---'

      ,-+-.         ,---.          ,---.          ,---.          ,---.
     /     \       /     \        /     \        /     \        /     \
    (   1   )+--->(   7   )+---->(   8   )+---->(   4   )+---->(   7   )
     \     /       \     /        \     /        \     /        \     /
      `---'         `---'          `---'          `---'          `---'

                   Figure 1: Service Function Chain Graphs

2.2.  Service Function Chain Symmetry

    SFCs may be unidirectional or bidirectional.  A unidirectional SFC
    requires that traffic be forwarded through the ordered SFs in one
    direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a
    symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), and in
    which the SF instances are the same in opposite directions.  A hybrid
    SFC has attributes of both unidirectional and bidirectional SFCs;
    that is to say some SFs require symmetric traffic, whereas other SFs
    do not process reverse traffic or are independent of the
    corresponding forward traffic.

    SFCs may contain cycles; that is traffic may need to traverse one or
    more SFs within an SFC more than once.  Solutions will need to ensure
    suitable disambiguation for such situations.

    The architectural allowance that is made for SFPs that delegate
    choice to the network for which SFs and/or SFFs a packet will visit
    creates potential issues here.  A solution that allows such
    delegation needs to also describe how the solution ensures that those
    service chains that require service function chain symmetry can
    achieve that.

    Further, there are state tradeoffs in symmetry.  Symmetry may be
    realized in several ways depending on the SFF and classifier

Halpern & Pignataro      Expires March 24, 2015                 [Page 7]

Internet-Draft              SFC Architecture              September 2014

    functionality.  In some cases, "mirrored" classification (i.e., from
    Source to Destination and from Destination to Source) policy may be
    deployed, whereas in others shared state between classifiers may be
    used to ensure that symmetric flows are correctly identified, then
    steered along the required SFP.  At a high level, there are various
    common cases.  In a non-exhaustive way, there can be for example: a
    single classifier (or a small number of classifiers), in which case
    both incoming and outgoing flows could be recognized at the same
    classifier, so the synchronization would be feasible by internal
    mechanisms internal to the classifier.  Another case is the one of
    stateful classifiers where several classifiers may be clustered and
    share state.  Lastly, another case entails fully distributed
    classifiers, where synchronization needs to be provided through
    unspecified means.  This is a non-comprehensive list of common cases.

SB> Isn't an important class of classifiers one that learns state from the
SB> egress packets/flows that is then used to provide state for the
SB> return packets/flow

  2.3.  Service Function Paths

    A service function path (SFP) is a mechanism used by service chaining
    to express the result of applying more granular policy and
SB> Not sure "more granular" is needed.

    operational constraints to the abstract requirements of a service
SB> Not sure they are abstract requirements. When you apply them they
SB> are explicit.

    chain (SFC).  This architecture does not mandate the degree of
    specificity of the SFP.  Architecturally, within the same SFC-enabled
    domain, some SFPs may be fully specified, selecting exactly which SFF
    and which SF are to be visited by packets using that SFP, while other
    SFPs may be quite vague, deferring to the SFF the decisions about the
    exact sequence of steps to be used to realize the SFC.  The
    specificity may be anywhere in between these extremes.

    As an example of such an intermediate specificity, there may be two
    SFPs associated with a given SFC, where one SFP says essentially that

SB> "says essentially is not a tight definition"

    any order of SFF and SF may be used as long as it is within data
    center 1, and where the second SFP allows the same latitude, but only
    within data center 2.

    Thus, the policies and logic of SFP selection or creation (depending
    upon the solution) produce what may be thought of as a constrained
    version of the original SFC.  Since multiple policies may apply to
    different traffic that uses the same SFC, it also follows that there
    may be multiple SFPs may be associated with a single SFC.

SB> So a SFP is a specific instance of a member of the set of available SFCs
SB> chosen as a result of applying policy at one or points along the SFC?

    The architecture allows for the same SF to be reachable through
    multiple SFFs.  In these cases, some SFPs may constrain which SFF is
    used to reach which SF, while some SFPs may leave that decision to
    the SFF itself.

    Further, the architecture allows for two or more SFs to be attached
    to the same SFF, and possibly connected via internal means allowing
    more effective communication.  In these cases, some solutions or

Halpern & Pignataro      Expires March 24, 2015                 [Page 8]

Internet-Draft              SFC Architecture              September 2014

    deployments may choose to use some form of internal inter-process or
    inter-VM messaging (communication behind the virtual switching
    element) that is optimized for such an environment.  This must be
    coordinated with the SFF so that the service function forwarding can
    properly perform its job.  Implementation details of such mechanisms
    are considered out of scope for this document, and can include a
    spectrum of methods: for example situations including all next-hops
    explicitly, others where a list of possible next-hops is provided and
    the selection is local, or cases with just an identifier, where all
    resolution is local.

    This architecture also allows the same SF to be part of multiple
    SFPs.

SB> Didn't you just say that?

  3.  Architecture Principles

    Service function chaining is predicated on several key architectural
    principles:

    1.  Topological independence: no changes to the underlay network
        forwarding topology - implicit, or explicit - are needed to
        deploy and invoke SFs or SFCs.

    2.  Plane separation: dynamic realization of SFPs is separated from
        packet handling operations (e.g., packet forwarding).

    3.  Classification: traffic that satisfies classification rules is
        forwarded according to a specific SFP.  For example,
        classification can be as simple as an explicit forwarding entry
        that forwards all traffic from one address into the SFP.
        Multiple classification points are possible within an SFC (i.e.
        forming a service graph) thus enabling changes/updates to the SFC
        by SFs.

        Classification can occur at varying degrees of granularity; for
        example, classification can use a 5-tuple, a transport port or
        set of ports, part of the packet payload, or it can come from
        external systems.

SB> I think that it can surely be as a result of higher level inspections?

  4.  Shared Metadata: Metadata/context data can be shared amongst SFs
        and classifiers, between SFs, and between external systems and
        SFs (e.g., orchestration).

        Generally speaking, metadata can be thought of as providing and
        sharing the result of classification

SB> Just classifications, or classifications and processing operations?
SB> There is gray zone between a packet forwarding system and
SB> a distributed computing system and I am not sure where SFC fits,
SB> nor am I sure that it makes sense to be specific at this stage.
SB> It is entirely possible that an SFC consumes the packet/flow
SB> rather than only having the capability to forward it between
SB> in ingress and egress.

       (that occurs within the SFC-
        enabled domain, or external to it) along an SFP.  For example, an
        external repository might provide user/subscriber information to
        a service chain classifier.  This classifier could in turn impose

Halpern & Pignataro      Expires March 24, 2015                 [Page 9]

Internet-Draft              SFC Architecture              September 2014

        that information in the SFC encapsulation for delivery to the
        requisite SFs.  The SFs could in turn utilize the user/subscriber
        information for local policy decisions.

    5.  Service definition independence: The SFC architecture does not
        depend on the details of SFs themselves.  Additionally, no IANA
        registry is required to store the list of SFs.

SB> Yes, but you should be careful not to preclude it.

   6.  Service function chain independence: The creation, modification,
        or deletion of an SFC has no impact on other SFCs.  The same is
        true for SFPs.

SB> Yes and no. What about the resource implications?

  7.  Heterogeneous control/policy points: The architecture allows SFs
        to use independent mechanisms (out of scope for this document) to
        populate and resolve local policy and (if needed) local
        classification criteria.

4.  Core SFC Architecture Components

    At a very high level, the logical architecture of an SFC-enabled
    Domain comprises:

SB> A list would be handy rather than just a figure, and you need
SB> some text to expand on the figure.

       o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
       .  +--------------+                  +------------------~~~
       .  |   Service    |       SFC        |  Service  +---+   +---+
       .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
    +---->|   Function   |+---------------->|   Path    +---+   +---+
       .  +--------------+                  +------------------~~~
       . SFC-enabled Domain
       o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

                Figure 2: Service Function Chain Architecture

SB> This is a very confusing diagram
SB> Surely the SFC encap is attached to the packet
SB> The fig seems to confuse the the packets and the path.

    The following sub-sections provide details on each logical component
    that form the basis of the SFC architecture.  A detailed overview of
    how each of these architectural components interact is provided in
    Figure 3:

SB> Well maybe, but it's not quite obvious what you are showing.
SB> some overview text would help before you get into the detail.

Halpern & Pignataro      Expires March 24, 2015                [Page 10]

Internet-Draft              SFC Architecture              September 2014

          +----------------+                        +----------------+
          |   SFC-aware    |                        |  SFC-unaware   |
          |Service Function|                        |Service Function|
          +-------+--------+                        +-------+--------+
                  |                                         |
            SFC Encapsulation                       No SFC Encapsulation
                  |                  SFC                    |
     +---------+  +----------------+ Encapsulation     +---------+
     |SFC-Aware|-----------------+  \     +------------|SFC Proxy|
     |    SF   | ... ----------+  \  \   /             +---------+
     +---------+                \  \  \ /
                               +-------+--------+
                               |   SF Forwarder |
                               |      (SFF)     |
                               +-------+--------+
                                       |
                               SFC Encapsulation
                                       |
                           ... SFC-enabled Domain ...
                                       |
                           Network Overlay Transport
                                       |
                                   _,....._
                                ,-'        `-.
                               /              `.
                              |     Network    |
                              `.              /
                                `.__     __,-'
                                    `''''

          Figure 3: Service Function Chain Architecture Components

SB> Coming back here after reading a bit more. Is the SFF to be considered the
SB> hub in a hub and spoke processing model for a set of SFs? If so it would
SB> be useful to say that up front. However that raises the issue of whether
SB> the single network attachment point that you show is desirable. A standard
SB> firewall design would not mix dirty and clean traffic, and yet that is
SB> what the above appears to show.

  4.1.  SFC Encapsulation

    The SFC encapsulation enables service function path selection.  It
    also enables the sharing of metadata/context information when such
    metadata exchange is required.

SB> I don't think that is quite right. Surely the
SB> SFC encapsulation enables <some component> to select the next
SB> element of the path?
  
    The SFC encapsulation provides explicit information used to identify
SB> Provides or carries?
    the SFP.  However, the SFC encapsulation is not a transport
    encapsulation itself: it is not used to forward packets within the
    network fabric.
SB> ... but surely it is a shim layer of some sort?

    If packets need to flow between separate physical
    platforms, the SFC encapsulation therefore relies on an outer network
    transport.
SB> Surely it is network layer header specific to the inter SFC
SB> transport?

    Transit forwarders -- such as router and switches --
    simply forward SFC encapsulated packets based on the outer (non-SFC)
    encapsulation.

SB> d/simply/

Halpern & Pignataro      Expires March 24, 2015                [Page 11]

Internet-Draft              SFC Architecture              September 2014

    One of the key architecture principles of SFC is that the SFC
    encapsulation remain transport independent.  As such any network
    transport protocol may be used to carry the SFC encapsulated traffic.

SB> Not sure I like "network transport protocol" since this is going
SB> to be confused with transport layer and I am not sure whether
SB> you would require a transport layer, indeed the SFE might will
SB> be considered a transport layer in the classical sense.

  4.2.  Service Function (SF)

    The concept of an SF evolves; rather than being viewed as a bump in
    the wire, an SF becomes a resource within a specified administrative
    domain that is available for consumption as part of a composite
    service.  SFs send/receive data to/from one or more SFFs.  SFC-aware
    SFs receive this traffic with the SFC encapsulation.

SB> I do not understand the above para.

    While the SFC architecture defines a new encapsulation - the SFC
    encapsulation -

SB> no it does not - it is not defined in this memo. You introduce
SB> the concept and define some of the characteristics of it.

    and several logical components for the construction
    of SFCs, existing SF implementations may not have the capabilities to
    act upon or fully integrate with the new SFC encapsulation.  In order
    to provide a mechanism for such SFs to participate in the
    architecture, an SFC proxy function is defined (see Section 4.6).
    The SFC proxy acts as a gateway between the SFC encapsulation and
    SFC-unaware SFs.  The integration of SFC-unaware service functions is
    discussed in more detail in the SFC proxy section.

SB> The above is confusing. Do they participate in the architecture (this
SB> text)? I think that you mean that in order to employ SF instances
SB> that do not understand the SFE, a proxy as a gateway between the
SB> the SFE aware domain and the non-SFE aware domain. Now if it is
SB> a gateway why is it not called a gateway rather than a proxy which
SB> is something that does something on behalf of something else.
SB> I would think that it might be a SFE proxy, but that is not quite
SB> right either.

  This architecture allows an SF to be part of multiple SFPs and SFCs.

SB> I am sure you said that before.

  4.3.  Service Function Forwarder (SFF)

    The SFF is responsible for forwarding packets and/or frames received
    from the network to one or more SFs associated with a given SFF using
    information conveyed in the SFC encapsulation.  Traffic from SFs
    eventually returns to the same SFF, which is responsible for
    injecting traffic back onto the network.

SB> It is not clear why it needs to be the exact same SFF

    The collection of SFFs and associated SFs creates a service plane
    overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside.
    Within this service plane, the SFF component connects different SFs
    that form a service function path.

SB> This conceptual model seems quite fundamental and this I
SB> am surprised that it is not much earlier in the document.
SB> I have been wondering why the SFC system was not considered
SB> an overlay network of some sort, and was told by the authors
SB> that this was not possible. The above seems at odds with that
Sb> statement.

    SFFs maintain the requisite SFP forwarding information.
SB> Maintain - as in being the control plane for this, or
SB> maintain as in store?
    SFP
    forwarding information is associated with a service path identifier
    that is used to uniquely identify an SFP.  The service forwarding
    state enables an SFF to identify which SFs of a given SFP should be
    applied, and in what order, as traffic flows through the associated
    SFP.  While there may appear to the SFF to be only one available way
    to deliver the given SF, there may also be multiple choices allowed
    by the constraints of the SFP.

    If there are multiple choices, the SFF needs to preserve the property
    that all packets of a given flow are handled the same way, since the

Halpern & Pignataro      Expires March 24, 2015                [Page 12]

Internet-Draft              SFC Architecture              September 2014

    SF may well be stateful.  Additionally, the SFF may preserve the
    handling of packets based on other properties on top of a flow, such
    as a subscriber, session, or application instance identification.

SB> I feel that the issue of handing higher order objects needs to have
SB> been introduced much earlier in the architecture.

    The SFF also has the information to allow it to forward packets to
    the next SFF after applying local service functions.  Again, while
    there may be only a single choice available, the architecture allows
    for multiple choices for the next SFF.  As with SFs, the solution
    needs to operate such that the behavior with regard to specific flows
    (see the Rendered Service Path) is stable.  The selection of
    available SFs and next SFFs may be interwoven when an SFF supports
    multiple distinct service functions and the same service function is
    available at multiple SFFs.  Solutions need to be clear about what is
    allowed in these cases.

    Even when the SFF supports and utilizes multiple choices, the
    decision as to whether to use flow-specific mechanisms or coarser
    grained means to ensure that the behavior of specific flows is stable
    is a matter for specific solutions and specific implementations.

    The SFF component has the following primary responsibilities:

    1.  SFP forwarding : Traffic arrives at an SFF from the network.  The
        SFF determines the appropriate SF the traffic should be forwarded
        to via information contained in the SFC encapsulation.  Post-SF,
        the traffic is returned to the SFF, and if needed forwarded to
        another SF associated with that SFF.  If there is another non-
        local (i.e., different SFF) hop in the SFP, the SFF further
        encapsulates the traffic in the appropriate network transport
        protocol and delivers it to the network for delivery to the next
        SFF along the path.  Related to this forwarding responsibility,
        an SFF should be able to interact with metadata.

    2.  Terminating SFPs : An SFC is completely executed when traffic has
        traversed all required SFs in a chain.  When traffic arrives at
        the SFF after the last SF has finished processing it, the final
        SFF knows from the service forwarding state that the SFC is
        complete.  The SFF removes the SFC encapsulation and delivers the
        packet back to the network for forwarding.

    3.  Maintaining flow state: In some cases, the SFF may be stateful.
        It creates flows and stores flow-centric information.  This state
        information may be used for a range of SFP-related tasks such as
        ensuring consistent treatment of all packets in a given flow,
        ensuring symmetry or for state-aware SFC Proxy functionality (see
        Section 4.8).

Halpern & Pignataro      Expires March 24, 2015                [Page 13]

Internet-Draft              SFC Architecture              September 2014

4.3.1.  Transport Derived SFF

    Service function forwarding, as described above, directly depends
    upon the use of the service path information contained in the SFC
    encapsulation.  However, existing implementations may not be able to
    act on the SFC encapsulation.  These platforms may opt to use
    existing transport information if it can be arranged to provide
    explicit service path information.

    This results in the same architectural behavior and meaning for
    service function forwarding and service function paths.  It is the
    responsibility of the control components to ensure that the transport
    path executed in such a case is fully aligned with the path
    identified by the information in the service chaining encapsulation.

SB> The title does not seem quite right. What I think you have
SB> is a system in which you map an SFC onto an explicit path
SB> of some sort in the lower layers (I was going to say network layer
SB> but I am not sure if that is what you intend). So I am not sure
SB> derived is the correct word. It would be closer to say "emulation
SB> of SFF using explicit network paths. Noting that these paths may
SB> be encoded in the packet or encoded in the FIB.

  4.4.  SFC-Enabled Domain

    Specific features may need to be enforced at the boundaries of an
    SFC-enabled domain, for example to avoid leaking SFC information.
    Using the term node to refer generically to an entity that is
    performing a set of functions, in this context, an SFC Boundary Node
    denotes a node that connects one SFC-enabled domain to a node either
    located in another SFC-enabled domain or in a domain that is SFC-
    unaware.

    An SFC Boundary node can act as egress or ingress.
SB> do you mean or or and/or i.e. can it be both at the same time.
    An SFC Egress
    Node denotes a SFC Boundary Node that handles traffic leaving the
    SFC-enabled domain the Egress Node belongs to.  Such a node is
    required to remove any information specific to the SFC Domain,
    typically the SFC Encapsulation.  An SFC Ingress Node denotes an SFC
    Boundary Node that handles traffic entering the SFC-enabled domain.
    In most solutions and deployments this will need to include a
    classifier, and will be responsible for adding the SFC encapsulation
    to the packet.

SB> Logically doesn't it always include the classifier, where the set of
SB> classifier types includes the null classifier? The only exception
SB> I suppose is when you are receiving traffic from a trusted
SB> SFC aware peer, but it might be better to be more explicit
SB> about the normal case and then introduce the exception

  4.5.  Network Overlay and Network Components

    Underneath the SFF there are components responsible for performing
    the transport (overlay) forwarding.  They do not consult the SFC
    encapsulation or inner payload for performing this forwarding.  They
    only consult the outer-transport encapsulation for the transport
    (overlay) forwarding.

SB> This layer model needs to be brought out much earlier instead of
SB> having the reader deduce it up to this point.
SB> Indeed the layering model makes for a better way of explaining
SB> the operation of the system.

  4.6.  SFC Proxy

    In order for the SFC architecture to support SFC-unaware SFs (e.g.,
    legacy service functions) a logical SFC proxy function may be used.

SB> Is it a logical proxy or a real proxy, and why only may, surely
SB> it *is* used.

Halpern & Pignataro      Expires March 24, 2015                [Page 14]

Internet-Draft              SFC Architecture              September 2014

    This function sits between an SFF and one or more SFs to which the
    SFF is directing traffic.

    The proxy accepts packets from the SFF on behalf of the SF.  It
    removes the SFC encapsulation, and then uses a local attachment
    circuit to deliver packets to SFC unaware SFs.  It also receives
    packets back from the SF, reapplies the SFC encapsulation, and
    returns them to the SFF for processing along the service function
    path.

    Thus, from the point of view of the SFF, the SFC proxy appears to be
    part of an SFC aware SF.

    Communication details between the SFF and the SFC Proxy are the same
    as those between the SFF and an SFC aware SF.  The details of that
    are not part of this architecture.  The details of the communication
    methods over the local attachment circuit between the SFC proxy and
    the SFC-unaware SF are dependent upon the specific behaviors and
    capabilities of that SFC-unaware SF, and thus are also out of scope
    for this architecture.

    Specifically, for traffic received from the SFF intended for the SF
    the proxy is representing, the SFC proxy:

    o  Removes the SFC encapsulation from SFC encapsulated packets.

    o  Identifies the required SF to be applied based on available
       information including that carried in the SFC encapsulation.

    o  Selects the appropriate outbound local attachment circuit through
       which the next SF for this SFP is reachable.  This is derived from
       the identification of the SF carried in the SFC encapsulation, and
       may include local techniques.  Examples of a local attachment
       circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3,
       GRE, VXLAN.

    o  Forwards the original payload via the selected local attachment
       circuit to the appropriate SF.

SB> I think you have missed the storage of the SFE and I am not
SB> sure how this gets back to the specific packet. This causes me
SB> wonder if it is the original payload or not since it may by
SB> now be SFC modified. It is surely the SFE payload that gets
SB> passed up, and to re-attach the correct SFE afterwards, might
SB> you not have to modify it?

  When traffic is returned from the SF:

    o  Applies the required SFC encapsulation.  The determination of the
       encapsulation details may be inferred by the local attachment
       circuit through which the packet and/or frame was received, or via
       packet classification, or other local policy.  In some cases,
       packet ordering or modification by the SF may necessitate
       additional classification in order to re-apply the correct SFC
       encapsulation.

SB> This function is surely split between the outbound and inbound
SB> proxy functions.

  Halpern & Pignataro      Expires March 24, 2015                [Page 15]

Internet-Draft              SFC Architecture              September 2014

    o  Delivers the packet with the SFC Encapsulation to the SFF, as
       would happen with packets returned from an SFC-aware SF.

    Alternatively, a service provider may decide to exclude legacy
    service functions from an SFC domain.

SB> This might have been better expressed earlier in the text my noting
SB> that the proxy was optional, making the afterthought above redundant.

  4.7.  Classification

    Traffic from the network that satisfies classification criteria is
    directed into an SFP and forwarded to the requisite service
    function(s).  Classification is handled by a service classification
    function; initial classification occurs at the ingress to the SFC
    domain.  The granularity of the initial classification is determined
    by the capabilities of the classifier and the requirements of the SFC
    policy.  For instance, classification might be relatively coarse: all
    packets from this port are subject to SFC policy X and directed into
    SFP A, or quite granular: all packets matching this 5-tuple are
    subject to SFC policy Y and directed into SFP B.

    As a consequence of the classification decision, the appropriate SFC
    encapsulation is imposed on the data, and a suitable SFP is selected
    or created.  Classification results in attaching the traffic to a
    specific SFP.

SB> How about:

SFC domain ingress traffic is first processed by a classifier which
either rejects the traffic or prepares it for processing by the required
SFs. The classifier applies policy to the packet to determine the required
SFC, and then to map that to the required SFP. The classifier applies
the corresponding SFE and if necessary the appropriate network layer
encapsulation and forwards the packet to the first SFF on the chain.

  4.8.  Re-Classification and Branching

    The SFC architecture supports re-classification (or non-initial
    classification) as well.

SB> This is interesting, surely the packet only enters the
SB> SFC when it has been been classified (including the null classification)
SB> and has the SFE applied?

    As packets traverse an SFP, re-
    classification may occur - typically performed by a classification
    function co-resident with a service function.
SB> Architecturally you may always want to include a reclassifier
SB> on exit (and may be entry) to every SF. It may be null, but it's
SB> probably better that it is there.

    Reclassification may
    result in the selection of a new SFP, an update of the associated
    metadata, or both.  This is referred to as "branching".

    For example, an initial classification results in the selection of
    SFP A: DPI_1 --> SLB_8.  However, when the DPI service function is
    executed, attack traffic is detected at the application layer.  DPI_1
    re-classifies the traffic as attack and alters the service path to
    SFP B, to include a firewall for policy enforcement: dropping the
    traffic: DPI_1 --> FW_4.  Subsequent to FW_4, surviving traffic would
    be returned to the original SFF.  In this simple example, the DPI
    service function re-classifies the traffic based on local application
    layer classification capabilities (that were not available during the
    initial classification step).

    When traffic arrives after being steered through an SFC-unaware SF,
    the SFC Proxy must perform re-classification of traffic to determine
    the SFP.  The SFC Proxy is concerned with re-attaching information

SB> This should have been part of the earlier proxy functional definition.
SB> Maybe if you moved this up earlier before proxy it would all be clearer.

  Halpern & Pignataro      Expires March 24, 2015                [Page 16]

Internet-Draft              SFC Architecture              September 2014

    for SFC-unaware SFs, and a stateful SFC Proxy simplifies such
    classification to a flow lookup.

4.9.  Shared Metadata

SB> Isn't metadata always shared? If no one else sees it, there is
SB> no point in generating it.

    Sharing metadata allows the network to provide network-derived
    information to the SFs, SF-to-SF information exchange and the sharing
    of service-derived information to the network.  Some SFCs may not
    require metadata exchange.  SFC infrastructure enables the exchange
    of this shared data along the SFP.  The shared metadata serves
    several possible roles within the SFC architecture:

    o  Allows elements that typically operate as ships in the night to
       exchange information.

SB> That is a sort of tautology. If they share MD they are not true
SB> SITN. Surely this is about in band and outband state sharing.

    o  Encodes information about the network and/or data for post-
       service forwarding.

    o  Creates an identifier used for policy binding by SFs.

    Context information can be derived in several ways:

SB> This list does not scan properly from the intro fragment above.

    o  External sources

    o  Network node classification

    o  Service function classification

  5.  Additional Architectural Concepts

    There are a number of issues which solutions need to address, and
    which the architecture informs but does not determine.  This section
    lays out some of those concepts.

5.1.  The Role of Policy

    Much of the behavior of service chains is driven by operator and per-
    customer policy.  This architecture is structured to isolate the
    policy interactions from the data plane and control logic.

    Specifically, it is assumed that the service chaining control plane
    creates the service paths.  The service chaining data plane is used
    to deliver the classified packets along the service chains to the
    intended service functions.

    Policy, in contrast, interacts with the system in other places.
    Policies and policy engines may monitor service functions to decide
    if additional (or fewer) instances of services are needed.

SB> This seems to be conflating policy and resource management, and
SB> I am not sure this is wise. The resource manager should consult
SB> policy, but the problems are distinct.

    When

Halpern & Pignataro      Expires March 24, 2015                [Page 17]

Internet-Draft              SFC Architecture              September 2014

    applicable, those decisions may in turn result in interactions that
    direct the control logic to change the SFP placement or packet
    classification rules.

    Similarly, operator service policy, often managed by operational or
    business support systems (OSS or BSS), will frequently determine what
    service functions are available.  Operator service policies also
    determine which sequences of functions are valid and are to be used
    or made available.

    The offering of service chains to customers, and the selection of
    which service chain a customer wishes to use, are driven by a
    combination of operator and customer policies using appropriate
    portals in conjunction with the OSS and BSS tools.  These selections
    then drive the service chaining control logic, which in turn
    establishes the appropriate packet classification rules.

SB> Didn't you just say the above. In any case it might be better in
SB> the form of an intro rather than a conclusion.

  5.2.  SFC Control Plane

    This is part of the overall architecture but outside the scope of
    this document.

SB> The specifics of the architecture of the CP may be out of scope
SB> but I cannot see how it can be out of scope of the main
SB> architecture, unless you want to reclassify this as the SFC packet
SB> plane architecture.
SB>
SB> As I read more of this text I am unclear why this in not promoted
SB> to the main body of the text.

     The SFC control plane is responsible for constructing SFPs,
    translating SFCs to forwarding paths and propagating path information
    to participating nodes to achieve requisite forwarding behavior to
    construct the service overlay.  For instance, an SFC construction may
    be static; selecting exactly which SFFs and which SFs from those SFFs
    are to be used, or it may be dynamic, allowing the network to perform
    some or all of the choices of SFF or SF to use to deliver the
    selected service chain within the constraints represented by the
    service path.

    In the SFC architecture, SFs are resources;

SB> SFs or SF instances? I don't think it becomes an accountable
SB> resource until it is instantiated.

    the control plane manages
    and communicates their capabilities, availability and location in
    fashions suitable for the transport and SFC operations in use.  The
    control plane is also responsible for the creation of the context
    (see below).  The control plane may be distributed (using new or
    existing control plane protocols), or be centralized, or a
    combination of the two.

    The SFC control plane provides the following functionality:

    1.  An SFC-enabled domain wide view of all available service function
        resources as well as the network locators through which they are
        reachable.

    2.  Uses SFC policy to construct service function chains, and
        associated service function paths.

Halpern & Pignataro      Expires March 24, 2015                [Page 18]

Internet-Draft              SFC Architecture              September 2014

    3.  Selection of specific SFs for a requested SFC, either statically
        (using specific SFs) or dynamically (using service explicit SFs
        at the time of delivering traffic to them).

    4.  Provides requisite SFC data plane information to the SFC
        architecture components, most notably the SFF.

    5.  Allocation of metadata associated with a given SFP and
        propagation of the metadata to relevant SFs and/or SFC
        encapsulation-proxies or their respective policy planes.

SB> I am not sure what it means to allocate metadata. Do you mean
SB> MD storage, or MD packet space?

  5.3.  Resource Control

    The SFC system may be responsible for managing all resources
    necessary for the SFC components to function.  This includes network
    constraints used to plan and choose network path(s) between service
    function forwarders, network communication paths between service
    function forwarders and their attached service functions,
    characteristics of the nodes themselves such as memory, number of
    virtual interfaces, routes, and instantiation, configuration, and
    deletion of SFs.

    The SFC system will also be required to reflect policy decisions
    about resource control, as expressed by other components in the
    system.

    While all of these aspects are part of the overall system, they are
    beyond the scope of this architecture.

SB> The relationship between the RC/RM and the CP seems unclear.

  5.4.  Infinite Loop Detection and Avoidance

    This SFC architecture is predicated on topological independence from
    the underlying forwarding topology.  Consequently, a service topology
    is created by Service Function Paths or by the local decisions of the
    Service Function Forwarders based on the constraints expressed in the
    SFP.

SB> The concept of service topologies and overlays would be useful much earlier in the text.

    Due to the overlay constraints, the packet-forwarding path may
    need to visit the same SFF multiple times, and in some less common
    cases may even need to visit the same SF more than once.  The Service
    Chaining solution needs to permit these limited and policy-compliant
    loops.  At the same time, the solutions must ensure that indefinite
    and unbounded loops cannot be formed, as such would consume unbounded
    resources without delivering any value.

    In other words, this architecture prevents infinite Service Function
    Loops, even when Service Functions may be invoked multiple times in
    the same SFP.

SB> You say it does, but I don't see how it does it. Do you anticipate
SB> it happening in the CP or the DP or both?
SB>

  Halpern & Pignataro      Expires March 24, 2015                [Page 19]

Internet-Draft              SFC Architecture              September 2014

5.5.  Load Balancing Considerations

    Supporting function elasticity and high-availability should not
    overly complicate SFC or lead to unnecessary scalability problems.

    In the simplest case, where there is only a single function in the
    SFP (the next hop is either the destination address of the flow or
    the appropriate next hop to that destination), one could argue that
    there may be no need for SFC.

SB> It is unusual to lead with the dejenerate case (i.e. no SFC)

    In the cases where the classifier is separate from the single
    function or a function at the terminal address may need sub-prefix or
    per-subscriber metadata, a single SFP exists (the metadata changes
    but the SFP does not), regardless of the number of potential terminal
    addresses for the flow.  This is the case of the simple load
    balancer.  See Figure 4.

                             +---+    +---++--->web server
                   source+-->|sff|+-->|sf1|+--->web server
                             +---+    +---++--->web server

                       Figure 4: Simple Load Balancing

    By extrapolation, in the case where intermediary functions within a
    chain had similar "elastic" behaviors, we do not need separate chains
    to account for this behavior - as long as the traffic coalesces to a
    common next-hop after the point of elasticity.

    In Figure 5, we have a chain of five service functions between the
    traffic source and its destination.

                 +---+ +---+ +---+   +---+ +---+ +---+
                 |sf2| |sf2| |sf3|   |sf3| |sf4| |sf4|
                 +---+ +---+ +---+   +---+ +---+ +---+
                   |     |     |       |     |     |
                   +-----+-----+       +-----+-----+
                         |                   |
                         +                   +
              +---+    +---+     +---+     +---+    +---+
    source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination
              +---+    +---+     +---+     +---+    +---+
                +                  +                  +
                |                  |                  |
              +---+              +---+              +---+
              |sf1|              |sf3|              |sf5|
              +---+              +---+              +---+

                          Figure 5: Load Balancing

Halpern & Pignataro      Expires March 24, 2015                [Page 20]

Internet-Draft              SFC Architecture              September 2014

    This would be represented as one service function path:
    sf1->sf2->sf3->sf4->sf5.  The SFF is a logical element, which may be
    made up of one or multiple components.  In this architecture, the SFF
    may handle load distribution based on policy.

    It can also be seen in the above that the same service function may
    be reachable through multiple SFFs, as discussed earlier.  The
    selection of which SFF to use to reach SF3 may be made by the control
    logic in defining the SFP, or may be left to the SFFs themselves,
    depending upon policy, solution, and deployment constraints.  In the
    latter case, it needs to be assured that exactly one SFF takes
    responsibility to steer traffic through SF3.

SB> Shouldn't the architecture lead with the general case and note
SB> that any function can be replaced with the null function.

  5.6.  MTU and Fragmentation Considerations

    This architecture prescribes additional information being added to
    packets to identify service function paths and often to represent
    metadata.  It also envisions adding transport information to carry
    packets along service function paths, at least between service
    function forwarders.  This added information increases the size of
    the packet to be carried by service chaining.  Such additions could
    potentially increase the packet size beyond the MTU supported on some
    or all of the media used in the service chaining domain.

    Such packet size increases can thus cause operational MTU problems.
    Requiring fragmentation and reassembly in an SFF would be a major
    processing increase, and might be impossible with some transports.

SB> Sure but the SFE is teh network layer of the SFC plane and could
SB> do this.

    Expecting service functions to deal with packets fragmented by the
    SFC function might be onerous even when such fragmentation was
    possible.  Thus, at the very least, solutions need to pay attention
    to the size cost of their approach.  There may be alternative or
    additional means available, although any solution needs to consider
    the tradeoffs.

    These considerations apply to any generic architecture that increases
    the header size.  There are also more specific MTU considerations:
    Effects on Path MTU Discovery (PMTUD) as well as deployment
    considerations.  Deployments within a single administrative control
    or even a single Data Center complex can afford more flexibility in
    dealing with larger packets, and deploying existing mitigations that
    decrease the likelihood of fragmentation or discard.

5.7.  SFC OAM

    Operations, Administration, and Maintenance (OAM) tools are an
    integral part of the architecture.  These serve various purposes,
    including fault detection and isolation, and performance management.
    For example, there are many advantages of SFP liveness detection,

Halpern & Pignataro      Expires March 24, 2015                [Page 21]

Internet-Draft              SFC Architecture              September 2014

    including status reporting, support for resiliency operations and
    policies, and an enhanced ability to balance load.

    Service Function Paths create a services topology, and OAM performs
    various functions within this service layer.  Furthermore, SFC OAM
    follows the same architectural principles of SFC in general.  For
    example, topological independence (including the ability to run OAM
    over various overlay technologies) and classification-based policy.

    We can subdivide the SFC OAM architecture in two parts:

    o  In-band: OAM packets follow the same path and share fate with user
       packets, within the service topology.  For this, they also follow
       the architectural principle of consistent policy identifiers, and
       use the same path IDs as the service chain data packets.  Load
       balancing and SFC encapsulation with packet forwarding are
       particularly important here.

    o  Out-of-band: reporting beyond the actual data plane.  An
       additional layer beyond the data-plane OAM allows for additional
       alerting and measurements.

    This architecture prescribes end-to-end SFP OAM functions, which
    implies SFF understanding of whether an in-band packet is an OAM or
    user packet.  However, service function validation is outside of the
    scope of this architecture, and application-level OAM is not what
    this architecture prescribes.

    Some of the detailed functions performed by SFC OAM include fault
    detection and isolation in a Service Function Path or a Service
    Function, verification that connectivity using SFPs is both effective
    and directing packets to the intended service functions, service path
    tracing, diagnostic and fault isolation, alarm reporting, performance
    measurement, locking and testing of service functions, validation
    with the control plane (see Section 5.2), and also allow for vendor-
    specific as well as experimental functions.  SFC should leverage, and
    if needed extend relevant existing OAM mechanisms.

5.8.  Resilience and Redundancy

    As a practical operational requirement, any service chaining solution
    needs to be able to respond effectively, and usually very quickly, to
    failure conditions.  These may be failures of connectivity in the
    network between SFFs, failures of SFFs, or failures of SFs.  Per-SF
    state, as for example stateful-firewall state, is the responsibility
    of the SF, and not addressed by this architecture.

Halpern & Pignataro      Expires March 24, 2015                [Page 22]

Internet-Draft              SFC Architecture              September 2014

    Multiple techniques are available to address this issue.  Solutions
    can describe both what they require and what they allow to address
    failure.  Solutions can make use of flexible specificity of service
    function paths, if the SFF can be given enough information in a
    timely fashion to do this.  Solutions can also make use of MAC or IP
    level redundancy mechanisms such as VRRP.  Also, particularly for SF
    failures, load balancers co-located with the SFF or as part of the
    service function delivery mechanism can provide such robustness.

    Similarly, operational requirements imply resilience in the face of
    load changes.  While mechanisms for managing (e.g., monitoring,
    instantiating, loading images, providing configuration to service
    function chaining control, deleting, etc.) virtual machines are out
    of scope for this architecture, solutions can and are aided by
    describing how they can make use of scaling mechanisms.

SB> Given that we are introducing a new network layer construct including
SB> something that is or is a very close cousin to a network layer, surely
SB> we are missing an opportunity by not including this on day one.

  6.  Security Considerations

    This document does not define a new protocol and therefore creates no
    new security issues.

    Security considerations apply to the realization of this
    architecture.  Such realization ought to provide means to protect the
    SFC-enabled domain and its borders against various forms of attacks,
    including DDoS attacks.  Further, SFC OAM Functions need to not
    negatively affect the security considerations of an SFC-enabled
    domain.  Additionally, all entities (software or hardware)
    interacting with the service chaining mechanisms need to provide
    means of security against malformed, poorly configured (deliberate or
    not) protocol constructs and loops.  These considerations are largely
    the same as those in any network, particularly an overlay network.

SB> I just don't buy this for a security analysis. The Architecture needs
SB> direct the compenent designers to look at security issues associated
SB> with the new components and functionality being introduced.
SB> For example the SFE will have special considerations, so will the
SB> the path changes that you talk about earlier. Then there is resource
SB> conflicts and their impact as a security problem. Then there is the
SB> issue of privacy. Really each component of the ach needs to be looked
SB> at from a security PoV and guidance provided to the component designer.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 12 Nov 2014 20:17:01 +0000

Correcting an error in the to list.

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 13 Nov 2014 00:44:48 +0000

Stewart,

Thanks for a very long set of comments right after WGLC finished :-)

This is a top-post response only, to Ack your email and to make a couple high-level comments about it. Neither Joel nor I will have immediate time this/early next week to respond to each individual comment (although we will as soon as we can), and we did not want your note to go unanswered.

First, many of your comments are conclusions from trying to model the SFC architecture as a layer network, where in fact that is not what we are doing or how things operate in this context. This architecture is not creating hard demarcations or modeling SFCs as a layer network.

And second, much of what you call 'lack of precision' is a feature and not a bug -- the realm of applications, deployments is rich in diversity and hence flexibility is a higher goal, while surgical doctoral precision would make the architecture brittle and would effectively make real deployment cases not be covered or represented by the architecture.

That said, you do make some points that are valid and we need to address -- we will be responding point-by-point soon.

Thanks again for taking the time to review and sending these detailed comments!

Carlos.

On Nov 12, 2014, at 10:17 AM, Stewart Bryant (stbryant) <[email-masked]<mailto:[email-masked]>> wrote:

Abstract

1.  Introduction

1.1.  Scope

1.2.  Assumptions

SB? see previous

1.3.  Definition of Terms

SB> Isn't it really

     ,-+-.         ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \

 4.1.  SFC Encapsulation

SB> d/simply/

 4.4.  SFC-Enabled Domain

 4.6.  SFC Proxy

 4.7.  Classification

SB> How about:

   Reclassification may

4.9.  Shared Metadata

   o  External sources

5.1.  The Role of Policy

   When

 5.2.  SFC Control Plane

 5.3.  Resource Control

                         Figure 5: Load Balancing

5.7.  SFC OAM

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 18 Nov 2014 18:39:43 +0000

> Thanks for a very long set of comments right after WGLC finished :-)
SB> Please consider them as early IETF LC comments, or pre-telechat
SB> comments direct to the IESG if you prefer :)
>
> This is a top-post response only, to Ack your email and to make a 
> couple high-level comments about it. Neither Joel nor I will have 
> immediate time this/early next week to respond to each individual 
> comment (although we will as soon as we can), and we did not want your 
> note to go unanswered.
>
> First, many of your comments are conclusions from trying to model the 
> SFC architecture as a layer network, where in fact that is not what we 
> are doing or how things operate in this context. This architecture is 
> not creating hard demarcations or modeling SFCs as a layer network.

SB> So I am curious as to what the right model is then. Certainly in 
practice
SB> appliances are usually connected together via cables an VLANs to
SB> set up service flow and from an applications perspective there is
SB> a topology. I am sure you use that expression in your text.
SB>
SB> Anyway it would be useful to me and many other readers if you shared the
SB> correct mental model of an SFC. Hopefully this is something more ordered
SB> than a plate of spaghetti.
>
> And second, much of what you call 'lack of precision' is a feature and 
> not a bug -- the realm of applications, deployments is rich in 
> diversity and hence flexibility is a higher goal, while surgical 
> doctoral precision would make the architecture brittle and would 
> effectively make real deployment cases not be covered or represented 
> by the architecture.
SB> Good architectures are usually crisp. They go soft when the you are
SB> working with the wrong model and need to put stuff in to fix it up.
SB> It therefore worries me that you have a soft model as a feature since
SB> it is going to be very hard to determine the invariants necessary to
SB> independently design the components in such a way that it fits
SB> together as a whole.
SB>
SB> Does the softness perhaps occur as a result of a lack of agreement
SB> on the invariants?

- Stewart

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 1 Dec 2014 03:52:10 +0000

Hi Stewart,

Thanks again for your comments, and apologies for the delay — please find some responses inline.

On Nov 12, 2014, at 3:17 PM, Stewart Bryant (stbryant) <[email-masked]<mailto:[email-masked]>> wrote:

SB> system,

As mentioned before (and verbally in your reference above), that’s what we do not want to do. More below.

 if you only used generalized the components with fully

Within the context of SFC, it is important that the architecture describes the proxy — as we are living in a world in which we want to include legacy and not craft an fully functional architecture that ignores it.

SB>

We can overcomplicate it in many different ways, but let’s not. We can think of it differently, I agree; but this is the way the WG thought about it.

I think this is a good point, more inline.

Abstract

Updated to “the”. Thanks.

1.  Introduction

Ditto.

1.1.  Scope

Trying to explain branching here would likely create more confusion to the reader.

I disagree — it is very relevant to be explicit about the scope for both fixed and mobile. It’s not redundant with no deployment context assumption, it is just a more explicit and precise set of details. This is, again, because these details are relevant to real SFC deployments based on this architecture.

1.2.  Assumptions

What is “application specific” in the context of a chained set of applications?

SB? see previous

See previous.

1.3.  Definition of Terms

It is not self-referential, but yes, the WG struggled a bit with how to define something so overloaded. I did at least. You can check the SFC charter for a different way of dancing around it.

If you have specific text suggestions, by all means, please do share.

SB> Isn't it really

Yes, I think this is a good change.

WG, any concerns?

An element sounds good to me. Any particular reason why you’d constrain it?

I agree with adding “flows”.

See above.

I guess “one or more”.

A firewall is an abstract SF, specific rules / policy makes it specific/concrete/explicit.

“The network” is not “the network” that you are thinking, I suspect.

I think the proposed change removes important detail — we could remove “from the network”.

Text?

This one took the WG a lot of editing…

What is wrong with the current definition? Again, the WG invested much (on list and in person) time to get to these.

I am happy to make changes that improve the document, but I am not sure I understand the guiding force other than personal preference.

OK, thanks. We want to capture the definition as part of the architecture — not sure of the wisdom if we do not capture it.

If they are physical, the logical-physical mapping is 1:1.

SB> I am still worried about using packets.

Need to fix this as well — part of the same comment. Thanks.

 Obviously we operate on

It’s in the architectural concepts.

See above.

The figure does show a graph.

     ,-+-.         ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \

Isn’t that a way to provide synchronization?

abstract
adjective
1. thought of apart from concrete realities, specific objects, or actual instances.

SB> "says essentially is not a tight definition”

Substituted with “specifies”.

OK, added.

Nothing is precluding it.

It could be the reader that is confusing a nice figure :-)

I am not sure I see what you see — suggestions?

 4.1.  SFC Encapsulation

Carries.

SB> d/simply/

OK

OK, fixed.

Because otherwise the SF would be an SFF.

I agree it would help — do you have a specific text addition and location?

Derived is not as precise as desired perhaps, but I think ‘emulation’ is worst. Others?

 4.4.  SFC-Enabled Domain

Yes.

   An SFC Egress

Better for readers that think in terms of and are used to seeing layer models. As explained, that’s not how we want to limit this architecture.

 4.6.  SFC Proxy

 4.7.  Classification

SB> How about:

This seems to leave out and awful set of details. And why first either rejects or prepares?

   Reclassification may

4.9.  Shared Metadata

It describes a key characteristic. Like saying “differentiated strategy” — isn’t it always? This improves the text with appropriate qualifiers.

I think you missed the “typically”.

   o  External sources

5.1.  The Role of Policy

   When

 5.2.  SFC Control Plane

Neither — defining what is relevant MD for a given SFP.

 5.3.  Resource Control

Both.

Noted. It’s going from simple to complex.

                         Figure 5: Load Balancing

5.7.  SFC OAM

Text?

Thanks,

Carlos.

- Stewart