Subject: [nsc] Revised SFC Charter

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 18 Nov 2013 21:16:37 +0000

Greetings,

Thomas Narten and I have spent some time refining the SFC charter based upon discussion during the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have clarified the management vs. control plane text and added text around security. Please review the revised charter and provide comment.

Revised SFC WG Charter:

Service delivery is undergoing significant change with the introduction of virtualization, network overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge that involves significant modification to the network configuration thereby impacting the speed at which services can be deployed and increasing operational costs. Services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within a network. Today, a common deployment model has service functions physically inserted on the data-forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where service functions, whether physical or virtualized, are not required to reside on the direct data path and traffic is instead steered through service functions, wherever they are deployed.

For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated through selection of specific service function instances and the network nodes on which they are provided, thereby forming a service graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (network layer, application layer, etc.).

The SFC working group will document a new approach to service delivery and operation. It will produce an architecture for service function chaining that includes the necessary protocols or protocol extensions to convey the service path and service path information to nodes that are involved in the implementation of service functions and service function chains, as well as mechanisms for steering traffic through service functions. The working group will examine what information needs to be gathered from the network and service functions in support of service function chaining and how that information may be made available to the components of the service function chaining architecture. The SFC WG will closely consider the security implications when documenting these deliverables.

Specifically, the SFC WG is chartered to deliver the following:

  1.  Problem Statement: This document will provide a summary of the problem space to be addressed by the SFC working group including example high-level use cases. Additionally, the working group will normalize nomenclature and definitions for service function chaining.
  2.  Architecture: This document will provide a description of the SFC architectural building blocks and their relationship including interconnection, placement of SFC specific capabilities, management, diagnostics, design analysis, and security models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single administrative domain, keeping in mind that architectural decisions made for the intra-domain case may have implications for the inter-domain case.
  3.  Generic SFC Encapsulation: This document will describe a single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions and service function chains. It is intended that the encapsulation be agnostic to the layer at which is is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.
  4.  Control Plane Mechanisms: A document will be developed to describe requirements for conveying information between control or management elements and SFC implementation points. All protocol extension work resulting from these requirements should be carried out in the working group responsible for the protocol being modified in coordination with this working group, but may be done in this working group under a revised charter after agreement with all the relevant WG chairs and responsible ADs.
  5.  Manageability: Work on the management and configuration of SFC components related to the support of service function chaining will certainly be needed, but first needs to be better understood and scoped.

Proposed Milestones:

Apr 2014 Submit to IESG Informational document defining the SFC problem statement and core use cases
Apr 2014 Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of service function chaining
Jan 2015 Submit to IESG Informational document defining the architecture for SFC
Jan 2015 Submit to IESG Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points
Aug 2015 Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation

---

From: Ron Parker <[email-masked]>
Date: Tue, 19 Nov 2013 01:37:18 +0000

Hi, Jim.

The charter looks good.   I do have a minor comment regarding the following:
Generic SFC Encapsulation: This document will describe a single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions and service function chains. It is intended that the encapsulation be agnostic to the layer at which is is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.
Specifically, the 'and' in the following phrase could be more limiting than necessary:

for conveying the service function chain and the service function path

In draft-parker-sfc-chain-to-path (http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00), it is proposed that neither the classifier (Policy Decision Point) nor the service nodes be aware of the specific instances of a service function that is multiply instantiated.   Under this approach, the service header would need only the chain information and not the path information.

Thanks.

    Ron

From: nsc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 18, 2013 4:17 PM
To: [email-masked]
Subject: [nsc] Revised SFC Charter

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014
Submit to IESG Informational document defining the SFC problem statement and core use cases
Apr 2014
Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of service function chaining
Jan 2015
Submit to IESG Informational document defining the architecture for SFC
Jan 2015
Submit to IESG Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points
Aug 2015
Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 19 Nov 2013 01:25:45 -0500

Hi Jim,

  There is a typo in item 3.  "is is" -> "it is":

    "It is intended that the encapsulation be agnostic to the layer at which is is applied"

  Wrt to the following text:

    "the same encapsulation may be used on a service function path realized at the network layer or at any other layer"

  If the service function is an application layer service, and the
  encapsulation is at a lower layer (L2/L3), then presumably signaling
  would be required between the application layer and the lower layer
  responsible for encapsulation, so that individual packets for an
  application layer message may be properly encapsulated.  Has this
  been discussed and/or is it considered in scope?

  Though this sort of thing could be called an implementation detail,
 typically higher layers do not need to know the lower layer details,
 but in this particular case, if the higher layer is re-classifying,
 it likely wants/needs to know the ingress chain ID as it selects the
  egress chain ID, and then needs to tell the lower encapsulation layer
 what the new egress chain ID should be?

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 19 Nov 2013 14:33:05 +0000

Hi Ron,
I think the language used is meant to indicate that the service function path points to the intended service function chain so that the local node is able to identify which service function to apply and which is the next service function in the chain. Which instance of the next service function to apply is independent of this.

From: Ron Parker <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 18, 2013 8:37 PM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Revised SFC Charter

Hi, Jim.

The charter looks good.   I do have a minor comment regarding the following:
Generic SFC Encapsulation: This document will describe a single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions and service function chains. It is intended that the encapsulation be agnostic to the layer at which is is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.
Specifically, the ‘and’ in the following phrase could be more limiting than necessary:

Thanks.

    Ron

From: nsc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 18, 2013 4:17 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [nsc] Revised SFC Charter

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 19 Nov 2013 14:38:45 +0000

Hi Kevin,

From: Kevin J Ma <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 19, 2013 1:25 AM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Revised SFC Charter

Hi Jim,

Jim> yes, thank you, I corrected the text.

Jim> the point here was to show that the steering function is independent of the services layer. As packets traverse a service chain the encapsulation above the steering function is used to indicate what service function to apply and which service function comes next in the service function chain.

Jim> this would be part of the control plane which would make available to the service function (or proxy) information about inbound and outbound service function chain encapsulation.

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 19 Nov 2013 10:15:43 -0500

Personally, I am still unclear as to how this would work for application layer
services.  It's not a control plane issue if it's session data dependent?

I won't rehash the previous discussion on "packet-level" classification and
"packet-level" encapsulation, but IMO there are a number of issues cited in
the problem statement which are not solved by simply defining an encapsulation
header.  Yes, there are other informational documents on the list, but if they
do not address these questions on how the encapsulation may be used (and how
different levels of classification/re-classification will work), then the
encapsulation spec has to stand on its own.  The charter could be interpreted
either way.

thanx.

--  Kevin J. Ma

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Tuesday, November 19, 2013 9:39 AM
To: Kevin J Ma; [email-masked]
Subject: Re: Revised SFC Charter

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 19 Nov 2013 17:32:26 +0000

Hi Kevin,

On Nov 19, 2013, at 10:15 AM, Kevin J Ma <[email-masked]<mailto:[email-masked]>> wrote:

The control plane is responsible for the chaining/pathing aspect of SFC: conveying network locators for forwarding, allocating service header information and so on.  It is not responsible for function specifics (e.g. per SFC policy).

The encap format won't solve everything, however it creates a foundation to build upon.  Many of the problems will be solved at upper layers, leveraging the encap in the data plane.

thanx.

--  Kevin J. Ma

From: Jim Guichard (jguichar) [mailto:[email-masked]<http://cisco.com>]
Sent: Tuesday, November 19, 2013 9:39 AM
To: Kevin J Ma; [email-masked]<mailto:[email-masked]>
Subject: Re: Revised SFC Charter

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

_______________________________________________
nsc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nsc

---

From: Ron Parker <[email-masked]>
Date: Tue, 19 Nov 2013 18:05:32 +0000

Hi, Kevin.

Can you  explain your thinking on why service function chaining would be cognizant of the layer at which the service function operates?   As I see it, any service function is free to modify the original packet in a manner that suits it.   It also has the choice to allow the packet (modified or unmodified) to progress on the original service function chain or to intercede with the local service function chaining functionality such that it jumps onto a new chain.   In either case, the local service function chaining functionality will cause the packet to be properly encapsulated in order to be conveyed to the next service function (or forwarded off the end of the chain, if applicable).

   Ron

From: nsc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charter

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: Ron Parker <[email-masked]>
Date: Tue, 19 Nov 2013 18:13:45 +0000

Hi, Ken.

The approach proposed in draft-parker-sfc-chain-to-path does not assume a stateless load balancer.   In contrast, it argues that nearly all real-world load balancing is both stateful and service-function-specific.   For that reason, it is proposed that when the SFC is composed each abstract service function is located to a single entity (i.e., abstract SFC A-->B-->C corresponds 1:1 to a concretely located A'-->B'-->C').   That single entity could be any of a normal service function, a proxy service function, a stateful service-function-specific load balancer, or a proxy stateful service-function-specific load balancer.   A chain could be comprised of any combination of those types.

   Ron

From: Ken Gray [mailto:[email-masked]]
Sent: Tuesday, November 19, 2013 1:00 PM
To: Ron Parker; Jim Guichard (jguichar); [email-masked]
Subject: RE: Revised SFC Charter

Hi, Ron.

I would think that every node in the chain post-PDP would need to "know" the path (we can argue about the word "know").  So, in the case of a single "classifier" step, it's every node ... in the case where there are "proxies" or new classification steps, new PDP (whatever) you need to "know" the path on any intervening SF between PDP-N and PDP-N+1.

As a specific comment on your doc, I would think that stateless lb potentially goes away - an alternative implementation would just centralize this, distribute and update chains.

________________________________
From: nsc <[email-masked]<mailto:[email-masked]>> on behalf of Ron Parker <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 18, 2013 8:37 PM
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] Revised SFC Charter

Hi, Jim.

In draft-parker-sfc-chain-to-path (http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00<https://wf-access.juniper.net/html/,DanaInfo=tools.ietf.org+draft-parker-sfc-chain-to-path-00>), it is proposed that neither the classifier (Policy Decision Point) nor the service nodes be aware of the specific instances of a service function that is multiply instantiated.   Under this approach, the service header would need only the chain information and not the path information.

Thanks.

    Ron

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 20 Nov 2013 01:27:27 -0500

Hi Paul/Ron,

  My primary concern is with the word "packet".  If we are only considering
  network layer packets, with network layer classification and encapsulation,
  then that is one thing, but if we are talking about application layer
  classification, then network layer encapsulation poses and issue.  The data
  that comes out of a service function is not necessarily the same data that
 went into the service function.  At the application layer, a socket is not
  inherently service chain aware.

 If one builds a load balancer, AV scanner, etc. as an appliance (not part
 of a router), today we have mechanisms for getting the traffic in and out
 of those appliances by configuring VLANs and IP addresses (as noted in the
  problem statement, section 2, bullet 8).  If we want the service chain ID
  in the encapsulation header to be the new mechanism, then these appliances
 need to know the ingress chain ID and the be able to set the egress chain
 ID.  An off-the-shelf linux box can support the existing IP mechanism.  It
  seems to me that a new encapsulation layer might exclude existing appliance
  implementations and introduce a new barrier to entry.

  Let me try a more concrete example:

  Given a set of service chains that: optionally terminates client-side TLS,
 performs HTTP request routing, optionally performs AV checks for HTTP POST,
 does server load balancing, and optionally initiates back-end TLS:

  --> FE_TLS --> RR --> AV --> LB --> BE_TLS -->
             /      \          ^  \
            /        \        /    \
  ---------+          +------+      +---------->

  Assume RR, AV, and LB are all services provided by independent appliances,
 and FE_TLS and BE_TLS are different instances of the same TLS service
  provided by a fourth independent appliance.  The possible chains are:

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB
  chain 4: FE_TLS, RR, AV, LB
  chain 5:         RR,     LB, BE_TLS
  chain 6:         RR, AV, LB, BE_TLS
  chain 7: FE_TLS, RR,     LB, BE_TLS
  chain 8: FE_TLS, RR, AV, LB, BE_TLS

  Initial classification would always choose from either chain 1 or chain 3.
  (e.g., based on the TCP destination port).

  RR would then choose either chain (1, 2) or chain (3, 4), respectively.

  LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8),
 respectively.

  The decisions made by RR/LB seem unlikely to be made on an IP packet basis,
  yet still need to influence the chain ID encapsulation?

  Now, TLS/RR/LB might all be in the same appliance, but even so, the chain
  to AV still has the same issue.

  So, I guess my question is: Is this a valid DC use case for SFC?

thanx.

--  Kevin J. Ma

From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, November 19, 2013 1:06 PM
To: Paul Quinn (paulq); Kevin J Ma
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: RE: [nsc] Revised SFC Charter

Hi, Kevin.

   Ron

From: nsc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc: [email-masked]<mailto:[email-masked]>; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charter

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: Ron Parker <[email-masked]>
Date: Wed, 20 Nov 2013 14:02:39 +0000

Hi, Kevin.

Thanks for the thoughtful analysis.  Responses below.

   Ron

From: Kevin J Ma [mailto:[email-masked]]
Sent: Wednesday, November 20, 2013 1:27 AM
To: Ron Parker; Paul Quinn (paulq)
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: RE: [nsc] Revised SFC Charter

Hi Paul/Ron,

Ron>> I don't doubt that development is required to support the new mechanisms, natively.   In draft-parker-sfc-chain-to-path, section 3.1, an SFC proxy is introduced to front-end legacy implementations.   The SFC proxy could conceivably be co-located with the legacy service function or could stand alone.

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB

Ron>> I don't see a limitation here.   The RR/LB can use stateful flow analysis, local policy, or any other techniques to manage the selection of chain for any packets that are transmitted by the RR/LB.   Such packets are not limited to packets that are received by the RR/LB (i.e., it is entirely permissible to create new flows).

Ron>> The multiple logical service functions could each be located to the same IP address (which does, indeed have implications on the SFC service header - it needs to carry both the chain ID and the hop ID within the chain so that the composite service function may understand which is the initial service function to apply).

Ron>> I consider your use case entirely valid and exactly what I have in mind when I think about SFC.   Implementation issues will always exist, but that is why we are employed :).   I think your concerns may have been whether SFC is restricted to a packet-in-packet-out type of model.   In my opinion, it is not.   A service function is free to create new flows that have no exact correspondence to incoming flows and to subject those new flows to any service chain (or none) independently.

Ron>>  All of this does bring up an area, in my mind, that requires further attention by the group, and perhaps this was on your mind, too.   How to handle the reverse direction flows?   In the simple case, where we have a linear chain with no branching and no flow creation, we could conceivably arrange the single classifier to see the packets upon entry to the domain in both directions.   If the classifier is stateful, it can easily manage reverse propagation down the chains (i.e., upstream A, B, C; downstream C, B, A).   But, if new flows are created at a service function, and properly stamped by the service function with the correct chain information, the corresponding reverse flows don't enter the domain at the service function, so where is the logic to place those flows on the proper reverse chain?

thanx.

--  Kevin J. Ma

Hi, Kevin.

   Ron

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 20 Nov 2013 15:02:05 +0000

Kevin,

Comments inline.

From: Kevin J Ma <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 19, 2013 10:27 PM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] Revised SFC Charter

Hi Paul/Ron,

<SK> When a classification supports layer7, it has to look at the data stream. There is no assumption that it is L3 based.

<SK> Well, there is more it than just putting a service path id into the header/pkt. To construct service chains, you need a non-local view of service functions. A service controller provides such a view to enables the construction of service chains. In that sense, there is already a need for co-ordination of these service chain/path identifiers with a control entity. We've moved past VLAN stitching – reason we are on this list :)

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB

  So, I guess my question is: Is this a valid DC use case for SFC?
<SK> It is a valid use case.

Surendra.

thanx.

--  Kevin J. Ma

Hi, Kevin.

   Ron

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 20 Nov 2013 10:46:05 -0500

Hi Ron,

> Ron>>  ... I think your concerns may have been whether SFC is restricted to a packet-in-packet-out type of model.   In my opinion, it is not.   A service function is free to create new flows that have no exact correspondence to incoming flows and to subject those new flows to any service chain (or none) independently.

  The packet-based nature was my primary concern, yes.  Good to know its not
 just packet-based.  My secondary concern is whether or not these new flows
  that are created are really considered part of the same chain, or whether
  the new flows are just part of completely independent chains (the latter
 always being possible)?

  Using a single chain has the value of a defined path/order and the greater
  possibility of reuse (by AV/LB) of classification information (obtained
 initially by RR).  However, in this case, the first hop of FE_TLS or not is
  arguably of limited value to RR, and the chain past RR is arguably of limited
  value to the ingress node thats just classifying port (443 vs 80).  I assume
  that any/all combinations of single/multi chain would be allowed, and left
  up to the operator doing the deployment?

> Ron>> I don't doubt that development is required to support the new mechanisms, natively.

  This I'm not so sure about.  Something has to understand the encapsulation
  header?  Depending on where the header sits, a stock network stack may just
  throw the packet away?  It may end up being an "implementation detail", but
  I just bring up that for those running on a stock linux distribution, this
  is a concern/consideration that is hopefully not overlooked in the design
  of the encapsulation header.

> Ron>>  All of this does bring up an area, in my mind, that requires further attention by the group, and perhaps this was on your mind, too.   How to handle the reverse direction flows?

  With the scenario below, yes, I was also wondering about the return flows.
  The return flow needs to come back through BE_TLS and eventually FE_TLS,
  possibly through alternate middle service, but I guess I assumed it would
  be a completely independent chain, rather than the reverse path of the
  ingress chain (where in the degenerate case, the reverse path could be an
  independently defined set of chains)?

thanx.

--  Kevin J. Ma

From: Ron Parker [mailto:[email-masked]]
Sent: Wednesday, November 20, 2013 9:03 AM
To: Kevin J Ma; Paul Quinn (paulq)
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: RE: [nsc] Revised SFC Charter

Hi, Kevin.

   Ron

Hi Paul/Ron,

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB

thanx.

--  Kevin J. Ma

Hi, Kevin.

   Ron

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 20 Nov 2013 10:51:46 -0500

Hi Surendra,

> <SK> Well, there is more it than just putting a service path id into the header/pkt. To construct service chains, you need a non-local view of service functions. A service controller provides such a view to enables the construction of service chains. In that sense, there is already a need for co-ordination of these service chain/path identifiers with a control entity. We've moved past VLAN stitching - reason we are on this list :)

  Understood, but since the control plane function is not in the scope of the
  charter, and the only standards track document in the charter is the header
  encapsulation, my concern is how well the encapsulation spec will take into
  account the different deployment scenarios that need to be supported by the
  control plane functions.  The point of the example was that the application
  layer service is the data plane.  It terminates the TCP connection and then
  generates a new TCP connection, but that is still the same data plane for a
  given end user session.  I wanted to make sure this is not overlooked.

thanx.

--  Kevin J. Ma

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 20, 2013 10:02 AM
To: Kevin J Ma; Ron Parker; Paul Quinn (paulq)
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charter

Kevin,

Comments inline.

Hi Paul/Ron,

<SK> Well, there is more it than just putting a service path id into the header/pkt. To construct service chains, you need a non-local view of service functions. A service controller provides such a view to enables the construction of service chains. In that sense, there is already a need for co-ordination of these service chain/path identifiers with a control entity. We've moved past VLAN stitching - reason we are on this list :)

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB

Surendra.

thanx.

--  Kevin J. Ma

Hi, Kevin.

   Ron

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 20 Nov 2013 15:56:44 +0000

Hi Kevin,
It is not accurate to say that the control plane function is not part of the charter. We have a work item to produce control plane requirements and those should reflect the functions necessary in the data plane encapsulation. It is true that the charter does not support working on the control plane standards per-se.

From: Kevin J Ma <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 20, 2013 10:51 AM
To: "Surendra Kumar (smkumar)" <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, Paul Quinn <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jim Guichard <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nsc] Revised SFC Charter

Hi Surendra,

thanx.

--  Kevin J. Ma

Kevin,

Comments inline.

Hi Paul/Ron,

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB

Surendra.

thanx.

--  Kevin J. Ma

Hi, Kevin.

   Ron

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 20 Nov 2013 11:05:21 -0500

Hi Jim,

  Fair enough.  But, requirements tend to get revised as you do a more
  thorough consideration of an implementation.  I question whether we
  can really anticipate all of the control plane issues without doing
  the actual control plane standard.  I brought up my questions below
  as I try to think through how the control plane and encap will work,
  but I can't say I've thought of it all.  Writing a requirements doc
  with no implementations to vet it out concerns me.

thanx.

--  Kevin J. Ma

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Wednesday, November 20, 2013 10:57 AM
To: Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Paul Quinn (paulq)
Cc: [email-masked]
Subject: Re: [nsc] Revised SFC Charter

Hi Kevin,

Hi Surendra,

thanx.

--  Kevin J. Ma

Kevin,

Comments inline.

Hi Paul/Ron,

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB

Surendra.

thanx.

--  Kevin J. Ma

Hi, Kevin.

   Ron

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 20 Nov 2013 18:05:13 +0000

I share a similar concern. If the service function software takes good care of untagging incoming packets on the way in, and retagging outgoing packets (maybe the same packets as the incoming one or maybe something completely different as Kevin illustrated) with the appropriate metadata on the way out, then we should be fine. Whether the SF is an application proxy or a more simple L3-centric packet processor, it then shouldn't matter. Packet-centric devices (e.g. routers) are usually pretty good at keep some form of context on their internal data path when processing a packet in/out, but app-centric software may not be designed like that.

So... that is quite an assumption (*all* SF software will have to do so -untagging/retagging-, whether they are actively interested in the packet metadata or not), and indeed a possibly severe barrier to entry.

From: nsc [mailto:[email-masked]] On Behalf Of Kevin J Ma

Hi Paul/Ron,

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB

thanx.

--  Kevin J. Ma

Hi, Kevin.

   Ron

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 20 Nov 2013 18:17:29 +0000

>>A service function is free to create new flows that have no exact correspondence to incoming flows and to subject those new flows to any service chain (or none) independently.

That is quite possible. However what is the logic that says a new Flow F2 is actually part of the original flow (f0). The presence of header, possibly.  Let me provide two example,

   a) A caching server creates a new flow to bring in content from OWS, this is a new flow sip=cache_server_ip.  However this is not really the part of the original flow.
   b) A flow gets terminated by WAP proxy and creates a brand new flow on the internet side. This is definitely the part of the original flow f0.

In both cases some cooperation from actual service implementation may be required.

Sumandra
________________________________
From: nsc [[email-masked]] on behalf of Ron Parker [[email-masked]]
Sent: Wednesday, November 20, 2013 6:02 AM
To: Kevin J Ma; Paul Quinn (paulq)
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charter

Hi, Kevin.

   Ron

Hi Paul/Ron,

Ron>> I don’t doubt that development is required to support the new mechanisms, natively.   In draft-parker-sfc-chain-to-path, section 3.1, an SFC proxy is introduced to front-end legacy implementations.   The SFC proxy could conceivably be co-located with the legacy service function or could stand alone.

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB

Ron>> I don’t see a limitation here.   The RR/LB can use stateful flow analysis, local policy, or any other techniques to manage the selection of chain for any packets that are transmitted by the RR/LB.   Such packets are not limited to packets that are received by the RR/LB (i.e., it is entirely permissible to create new flows).

Ron>> The multiple logical service functions could each be located to the same IP address (which does, indeed have implications on the SFC service header – it needs to carry both the chain ID and the hop ID within the chain so that the composite service function may understand which is the initial service function to apply).

Ron>>  All of this does bring up an area, in my mind, that requires further attention by the group, and perhaps this was on your mind, too.   How to handle the reverse direction flows?   In the simple case, where we have a linear chain with no branching and no flow creation, we could conceivably arrange the single classifier to see the packets upon entry to the domain in both directions.   If the classifier is stateful, it can easily manage reverse propagation down the chains (i.e., upstream A, B, C; downstream C, B, A).   But, if new flows are created at a service function, and properly stamped by the service function with the correct chain information, the corresponding reverse flows don’t enter the domain at the service function, so where is the logic to place those flows on the proper reverse chain?

thanx.

--  Kevin J. Ma

Hi, Kevin.

   Ron

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Nov 2013 13:27:40 -0500

Unless we want to assume that SFs are single threaded (I very much hope 
not), then if the application modifies the packet, how does the SF know 
which metadata to re-attach to which packet?

Yours,
Joel

On 11/20/13 1:05 PM, Jerome Moisand wrote:
> I share a similar concern. If the service function software takes good
> care of untagging incoming packets on the way in, and retagging outgoing
> packets (maybe the same packets as the incoming one or maybe something
> completely different as Kevin illustrated) with the appropriate metadata
> on the way out, then we should be fine. Whether the SF is an application
> proxy or a more simple L3-centric packet processor, it then shouldn’t
> matter. Packet-centric devices (e.g. routers) are usually pretty good at
> keep some form of context on their internal data path when processing a
> packet in/out, but app-centric software may not be designed like that.
>
> So… that is quite an assumption (*all* SF software will have to do so
> –untagging/retagging-, whether they are actively interested in the
> packet metadata or not), and indeed a possibly severe barrier to entry.
>
> *From:*nsc [mailto:[email-masked]] *On Behalf Of *Kevin J Ma
> *Sent:* Wednesday, November 20, 2013 1:27 AM
> *To:* Ron Parker; Paul Quinn (paulq)
> *Cc:* [email-masked]; Jim Guichard (jguichar)
> *Subject:* Re: [nsc] Revised SFC Charter
>
> Hi Paul/Ron,
>
> *From:*Ron Parker [mailto:[email-masked]]
> *Sent:* Tuesday, November 19, 2013 1:06 PM
> *To:* Paul Quinn (paulq); Kevin J Ma
> *Cc:* [email-masked] <mailto:[email-masked]>; Jim Guichard (jguichar)
> *Subject:* RE: [nsc] Revised SFC Charter
>
> Hi, Kevin.
>
> Can you  explain your thinking on why service function chaining would be
> cognizant of the layer at which the service function operates?   As I
> see it, any service function is free to modify the original packet in a
> manner that suits it.   It also has the choice to allow the packet
> (modified or unmodified) to progress on the original service function
> chain or to intercede with the local service function chaining
> functionality such that it jumps onto a new chain.   In either case, the
> local service function chaining functionality will cause the packet to
> be properly encapsulated in order to be conveyed to the next service
> function (or forwarded off the end of the chain, if applicable).
>
>     Ron
>
> *From:*nsc [mailto:[email-masked]] *On Behalf Of *Paul Quinn (paulq)
> *Sent:* Tuesday, November 19, 2013 12:32 PM
> *To:* Kevin J Ma
> *Cc:* [email-masked] <mailto:[email-masked]>; Jim Guichard (jguichar)
> *Subject:* Re: [nsc] Revised SFC Charter
>
> Hi Kevin,
>
> On Nov 19, 2013, at 10:15 AM, Kevin J Ma <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Jim> this would be part of the control plane which would make
>     available to the service function (or proxy) information about
>     inbound and outbound service function chain encapsulation.
>
> The control plane is responsible for the chaining/pathing aspect of SFC:
> conveying network locators for forwarding, allocating service header
> information and so on.  It is not responsible for function specifics
> (e.g. per SFC policy).
>
> The encap format won't solve everything, however it creates a foundation
> to build upon.  Many of the problems will be solved at upper layers,
> leveraging the encap in the data plane.
>
>     thanx.
>
>     --  Kevin J. Ma
>
>     *From:*Jim Guichard (jguichar) [mailto:[email-masked]
>     <http://cisco.com>]
>     *Sent:*Tuesday, November 19, 2013 9:39 AM
>     *To:*Kevin J Ma;[email-masked] <mailto:[email-masked]>
>     *Subject:*Re: Revised SFC Charter
>
>     Hi Kevin,
>
>     *From:*Kevin J Ma <[email-masked]
>     <mailto:[email-masked]>>
>     *Date:*Tuesday, November 19, 2013 1:25 AM
>     *To:*Jim Guichard <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:*RE: Revised SFC Charter
>
>     Hi Jim,
>
>          "the same encapsulation may be used on a service function path
>     realized at the network layer or at any other layer"
>
>     Jim> the point here was to show that the steering function is
>     independent of the services layer. As packets traverse a service
>     chain the encapsulation above the steering function is used to
>     indicate what service function to apply and which service function
>     comes next in the service function chain.
>
>     Jim> this would be part of the control plane which would make
>     available to the service function (or proxy) information about
>     inbound and outbound service function chain encapsulation.
>
>     thanx.
>
>     --  Kevin J. Ma
>
>     *From:*nsc [mailto:[email-masked]]*On Behalf Of*Jim Guichard
>     (jguichar)
>     *Sent:*Monday, November 18, 2013 4:17 PM
>     *To:[email-masked] <mailto:[email-masked]>
>     *Subject:*[nsc] Revised SFC Charter
>
>     Greetings,
>
>     Thomas Narten and I have spent some time refining the SFC charter
>     based upon discussion during the SFC BOF and several emails to the
>     mailing list. We do not believe this is a substantive change; we
>     have clarified the management vs. control plane text and added text
>     around security. Please review the revised charter and provide comment.
>
>     _Revised SFC WG Charter:_
>
>     Service delivery is undergoing significant change with the
>     introduction of virtualization, network overlays, and orchestration.
>     Service delivery is currently both a technical and an organizational
>     challenge that involves significant modification to the network
>     configuration thereby impacting the speed at which services can be
>     deployed and increasing operational costs. Services are typically
>     implemented by the ordered combination of a number of service
>     functions that are deployed at different points within a network.
>     Today, a common deployment model has service functions physically
>     inserted on the data-forwarding path between communicating peers.
>     Going forward, however, there is a desire to move to a different
>     model, where service functions, whether physical or virtualized, are
>     not required to reside on the direct data path and traffic is
>     instead steered through service functions, wherever they are deployed.
>
>     For a given service, the abstracted view of the required service
>     functions and the order in which they are to be applied is called a
>     Service Function Chain (SFC). An SFC is instantiated through
>     selection of specific service function instances and the network
>     nodes on which they are provided, thereby forming a service graph:
>     this is called a Service Function Path (SFP). The service functions
>     may be applied at any layer within the network protocol stack
>     (network layer, application layer, etc.).
>
>     The SFC working group will document a new approach to service
>     delivery and operation. It will produce an architecture for service
>     function chaining that includes the necessary protocols or protocol
>     extensions to convey the service path and service path information
>     to nodes that are involved in the implementation of service
>     functions and service function chains, as well as mechanisms for
>     steering traffic through service functions. The working group will
>     examine what information needs to be gathered from the network and
>     service functions in support of service function chaining and how
>     that information may be made available to the components of the
>     service function chaining architecture. The SFC WG will closely
>     consider the security implications when documenting these deliverables.
>
>     1.Problem Statement: This document will provide a summary of the
>     problem space to be addressed by the SFC working group including
>     example high-level use cases. Additionally, the working group will
>     normalize nomenclature and definitions for service function chaining.
>
>     2.Architecture: This document will provide a description of the SFC
>     architectural building blocks and their relationship including
>     interconnection, placement of SFC specific capabilities, management,
>     diagnostics, design analysis, and security models, as well as
>     requirements on the protocol mechanisms. The initial scope is
>     restricted to a single administrative domain, keeping in mind that
>     architectural decisions made for the intra-domain case may have
>     implications for the inter-domain case.
>
>     3.Generic SFC Encapsulation: This document will describe a single
>     service-level data plane encapsulation format for conveying the
>     service function chain and the service function path, and for
>     communicating context information between nodes that implement
>     service functions and service function chains. It is intended that
>     the encapsulation be agnostic to the layer at which is is applied
>     and the service that is being constructed. That is, the same
>     encapsulation may be used on a service function path realized at the
>     network layer or at any other layer, and the same encapsulation will
>     apply for the construction of service function paths regardless of
>     the actual service.
>
>     4.Control Plane Mechanisms: A document will be developed to describe
>     requirements for conveying information between control or management
>     elements and SFC implementation points. All protocol extension work
>     resulting from these requirements should be carried out in the
>     working group responsible for the protocol being modified in
>     coordination with this working group, but may be done in this
>     working group under a revised charter after agreement with all the
>     relevant WG chairs and responsible ADs.
>
>     5.Manageability: Work on the management and configuration of SFC
>     components related to the support of service function chaining will
>     certainly be needed, but first needs to be better understood and scoped.
>
>     Proposed Milestones:
>
>     Apr 2014
>
>     Consult with OPS area on possible SFC charter modifications for
>     management and configuration of SFC components related to the
>     support of service function chaining
>
>     Jan 2015
>
>     Submit to IESG Informational document defining the control plane
>     requirements for conveying information between control or management
>     elements and SFC implementation points
>
>     Aug 2015
>
>     Submit to IESG Standards Track document specifying the generic
>     service function chaining header encapsulation
>
>     [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 20 Nov 2013 18:39:16 +0000

Well, it probably has its own flow/state tables where this can be stored and used when needs be on the way out. Making an assumption that for a given incoming flow (or collection of flows with affinity), the metadata is unlikely to change (which isn't entirely obvious in theory, but likely in practice). 

And yeah, this (weak?) answer just reinforces the barrier to entry problem. Sounds like quite an issue. Being bugging me (and other folks I know) for a while. 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, November 20, 2013 1:28 PM
To: Jerome Moisand; Kevin J Ma; Ron Parker; Paul Quinn (paulq)
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charter

Unless we want to assume that SFs are single threaded (I very much hope not), then if the application modifies the packet, how does the SF know which metadata to re-attach to which packet?

Yours,
Joel

On 11/20/13 1:05 PM, Jerome Moisand wrote:
> care of untagging incoming packets on the way in, and retagging 
> outgoing packets (maybe the same packets as the incoming one or maybe 
> something completely different as Kevin illustrated) with the 
> appropriate metadata on the way out, then we should be fine. Whether 
> the SF is an application proxy or a more simple L3-centric packet 
> processor, it then shouldn't matter. Packet-centric devices (e.g. 
> routers) are usually pretty good at keep some form of context on their 
> internal data path when processing a packet in/out, but app-centric software may not be designed like that.
>
> So... that is quite an assumption (*all* SF software will have to do so 
> -untagging/retagging-, whether they are actively interested in the 
> The encap format won't solve everything, however it creates a 
> foundation to build upon.  Many of the problems will be solved at 
> upper layers, leveraging the encap in the data plane.
>
>     thanx.
>
>     --  Kevin J. Ma
>

---

From: ramki Krishnan <[email-masked]>
Date: Wed, 20 Nov 2013 11:10:32 -0800

>> Well, it probably has its own flow/state tables where this can be stored and used when needs be on the way out. Making an assumption that for a given incoming flow (or collection of flows with aff…

I think it is the right assumption to make; the metadata should be invariant per flow (or group of flows). Else, things will start quickly falling apart.

Thanks,
Ramki

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Wednesday, November 20, 2013 1:28 PM
To: Jerome Moisand; Kevin J Ma; Ron Parker; Paul Quinn (paulq)
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charter

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 21 Nov 2013 03:59:38 +0000

Kevin,

--
  The point of the example was that the application
  layer service is the data plane.  It terminates the TCP connection and then
  generates a new TCP connection, but that is still the same data plane for a
  given end user session.  I wanted to make sure this is not overlooked.
--
Noted: A non-transparent proxy application and one that is stream packet based. I don't think the architecture prevents this. At the minimum an effect similar to VLAN stitching should be achievable by having the application not directly participate in service chaining. As an example, using proxy nodes as described in http://tools.ietf.org/html/draft-quinn-nsh-01

All the stuff that Jim/Thomas mentioned about Control plane still applies.
Surendra.

From: Kevin J Ma <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 20, 2013 7:51 AM
To: Surendra Kumar <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nsc] Revised SFC Charter

Hi Surendra,

thanx.

--  Kevin J. Ma

Kevin,

Comments inline.

Hi Paul/Ron,

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB

Surendra.

thanx.

--  Kevin J. Ma

Hi, Kevin.

   Ron

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 21 Nov 2013 07:05:17 +0000

I don't see it that way.

I'm assuming you are including L4-7 services (firewalls and load balancers, for instance) in the packet-centric devices, which are a considerable percentage and even a majority of the services. If an application software is not written that way, maybe it does not want to participate directly in SFC. As long as we don't make such applications worse, they can function the way they do today. At the same time, if they do participate then I don't see why they do not want to take advantage of the header. In the worst case it becomes a NOP and MTU is a non-issue in the current overlay world (assuming we are smart in service header size) while enabling it to be part of SFC.

For all I know, this could be an area of innovation. For even in such applications, the flow state exists (in the OS stack) although not used by the application directly.

Surendra.

From: Jerome Moisand <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 20, 2013 10:05 AM
To: Kevin J Ma <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] Revised SFC Charter

I share a similar concern. If the service function software takes good care of untagging incoming packets on the way in, and retagging outgoing packets (maybe the same packets as the incoming one or maybe something completely different as Kevin illustrated) with the appropriate metadata on the way out, then we should be fine. Whether the SF is an application proxy or a more simple L3-centric packet processor, it then shouldn’t matter. Packet-centric devices (e.g. routers) are usually pretty good at keep some form of context on their internal data path when processing a packet in/out, but app-centric software may not be designed like that.

So… that is quite an assumption (*all* SF software will have to do so –untagging/retagging-, whether they are actively interested in the packet metadata or not), and indeed a possibly severe barrier to entry.

Hi Paul/Ron,

  chain 1:         RR,     LB
  chain 2:         RR, AV, LB
  chain 3: FE_TLS, RR,     LB

thanx.

--  Kevin J. Ma

Hi, Kevin.

   Ron

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi Jim,

thanx.

--  Kevin J. Ma

Greetings,

Revised SFC WG Charter:

Proposed Milestones:

Apr 2014