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

From: Ron Parker <[email-masked]>
Date: Mon, 1 Dec 2014 14:46:27 +0000

Carlos,

A few comments regarding your responses...

regarding:

 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.

Yes, I think this is a good change.

WG, any concerns?

I agree that the suggested change is good.

Regarding:

 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

I agree with adding "flows".

I like "flows" here, too.   Also agree that "ordered" is an important aspect.

Regarding:

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

Isn't that a way to provide synchronization?

I have a nagging feeling that the architecture doc should add a section on unidirectional vs. symmetrically bidirectional flows and the optimizations and/or simplifications that can be realized when the policy is such that symmetrically bidirectional flows are utilized.

From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Sunday, November 30, 2014 10:52 PM
To: Stewart Bryant (stbryant)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Some concerns about draft-ietf-sfc-architecture

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:

Correcting an error in the to list.

On 12/11/2014 20:05, Stewart Bryant wrote:

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,
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

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.
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>

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>
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.

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.

I think this is a good point, more inline.

 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?
Updated to "the". Thanks.

   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
Ditto.

   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.

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

   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.

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.

   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?

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

 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

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.
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.

 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.

Yes, I think this is a good change.

WG, any concerns?

 Classifier:  An element that performs Classification.

SB> A network element perhaps?

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

 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

I agree with adding "flows".

        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.

See above.

 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?
I guess "one 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?
A firewall is an abstract SF, specific rules / policy makes it specific/concrete/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.
"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".

 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.

Text?

 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?

This one took the WG a lot of editing...

 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.

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.

 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.

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

 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.

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

 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.

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

 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.

It's in the architectural concepts.

 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?

See above.

   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.

The figure does show a graph.

   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

Isn't that a way to provide synchronization?

 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.

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

   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"

Substituted with "specifies".

   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?

OK, added.

 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.

Nothing is precluding 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.

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

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

   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?

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/

OK

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.

OK, fixed.

   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
Because otherwise the SF would be an 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.

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

   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.
Derived is not as precise as desired perhaps, but I think 'emulation' is worst. Others?

 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.

Yes.

   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.

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

   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.

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

 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.

It describes a key characteristic. Like saying "differentiated strategy" - isn't it always? This improves the text with appropriate qualifiers.

   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.
I think you missed the "typically".

   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?

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

 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>

Both.

 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)

Noted. It's going from simple to complex.

   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.

Text?

Thanks,

Carlos.

- Stewart

--

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: Mon, 1 Dec 2014 15:14:16 +0000

Hi, Ron,

Thanks for the follow-up — please see inline.

On Dec 1, 2014, at 9:46 AM, Ron Parker <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

A few comments regarding your responses…

regarding:

SB> Isn't it really

WG, any concerns?

Ack. Thank you.

Regarding:

        classification.

I agree with adding “flows”.

I like “flows” here, too.   Also agree that “ordered” is an important aspect.

Ack. Thank you.

Regarding:

SB> return packets/flow

Isn’t that a way to provide synchronization?

Doesn’t Section 2.2 cover this already?

My point to Stewart was that I thought that the case he mentioned was covered in the sentence that starts with: “Lastly, another case entails fully distributed”.

However, what I think could be useful is to turn that paragraph into a bullet list and add the explicit case that Stewart mentioned as well as a fourth one.

Thanks!

Carlos.

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Stewart,

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

SB> buy that.

SB>

SB>

SB> system,

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

SB> architecture.

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>

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.

SB> between SFs.

Abstract

sb> an arch or THE arch?

Updated to “the”. Thanks.

1.  Introduction

sb> and or THE

Ditto.

1.1.  Scope

SB> by the above.

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

      configuration, etc.

      environment.

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

SB? see previous

See previous.

      populated.

1.3.  Definition of Terms

        is hosted.

SB> not helpful.

SB> Isn't it really

WG, any concerns?

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

        classification.

I agree with adding “flows”.

        service function chain.

See above.

SB> multiple or more?

I guess “one or more”.

        administrative domain.

        optimizer.

        encapsulation.

        SFP.

“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…

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

        administrative domain.

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

 Obviously we operate on

It’s in the architectural concepts.

See above.

   graph.

     ,-+-.         ,---.          ,---.          ,---.

    /     \       /     \        /     \        /     \

    \     /       \     /        \     /        \     /

     `---'         `---'          `---'          `---'

    /     \       /     \        /     \        /     \        /     \

    \     /       \     /        \     /        \     /        \     /

    /     \       /     \        /     \        /     \        /     \

    \     /       \     /        \     /        \     /        \     /

   achieve that.

SB> return packets/flow

Isn’t that a way to provide synchronization?

SB> are explicit.

abstract
adjective

SB> "says essentially is not a tight definition”

Substituted with “specifies”.

   within data center 2.

   the SFF itself.

   resolution is local.

   SFPs.

   principles:

       by SFs.

       external systems.

OK, added.

       true for SFPs.

       classification criteria.

   Domain comprises:

      . SFC-enabled Domain

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

   Figure 3:

                 |                                         |

                 |                  SFC                    |

    +---------+                \  \  \ /

                              +-------+--------+

                              |   SF Forwarder |

                              |      (SFF)     |

                              +-------+--------+

                                      |

                              SFC Encapsulation

                                      |

                                      |

                                      |

                                  _,....._

                               ,-'        `-.

                              /              `.

                             |     Network    |

                             `.              /

                               `.__     __,-'

                                   `''''

 4.1.  SFC Encapsulation

SB> element of the path?

SB> Provides or carries?

Carries.

   network fabric.

   transport.

SB> transport?

   encapsulation.

SB> d/simply/

OK

   encapsulation -

OK, fixed.

SB> right either.

Sb> statement.

   SFP

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

   allowed in these cases.

       Section 4.8).

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

 4.4.  SFC-Enabled Domain

   unaware.

Yes.

   An SFC Egress

   to the packet.

   (overlay) forwarding.

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

SB> it *is* used.

   path.

   part of an SFC aware SF.

   for this architecture.

      GRE, VXLAN.

      encapsulation.

SB> proxy functions.

 4.7.  Classification

   specific SFP.

SB> How about:

   classification) as well.

   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.

      exchange information.

I think you missed the “typically”.

      service forwarding.

   o  External sources

5.1.  The Role of Policy

   When

   classification rules.

   or made available.

 5.2.  SFC Control Plane

   this document.

SB> plane architecture.

SB>

   service path.

   combination of the two.

       reachable.

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

 5.3.  Resource Control

   deletion of SFs.

   system.

   SFP.

   the same SFP.

SB>

Both.

Noted. It’s going from simple to complex.

   balancer.  See Figure 4.

                  |     |     |       |     |     |

                        |                   |

                        +                   +

               +                  +                  +

               |                  |                  |

             +---+              +---+              +---+

             |sf1|              |sf3|              |sf5|

             +---+              +---+              +---+

                         Figure 5: Load Balancing

SB> do this.

   the tradeoffs.

5.7.  SFC OAM

   new security issues.

Text?

Thanks,

Carlos.

- Stewart

--