Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 21 Jan 2014 19:14:06 +0000

Thomas and I would like to remind you of the ongoing WG call for adoption of draft-quinn-sfc-problem-statement-02. We have received numerous positive responses to our original email and plan to formally close out the call for adoption this coming Friday (1/24/14). If folks have any additional comments or concerns please voice them before this Friday.

Jim & Thomas
SFC chairs.

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 22 Jan 2014 20:12:26 +0000

Hi Jim,

I have the following questions/comments:

1.      Definition of Service Function

It mentions that "Multiple instances of the Service Function can be enabled in the same administrative domain". There is also the case that multiple instances of the Service Function can be instantiated on the same Service Node. For example on a FW appliance, we can instantiate

multiple FW service instances with each FW service instance having its own filtering rules. Could we add this into the Definition?

2.      Service Overlay

AFAIK, there is a proposal for a new overlay mechanism. Shall we also explore and leverage existing overlay mechanism? I am thinking that we might also want to take current

prevailing overlay mechanism into our consideration for service function chaining, such as VXLAN overlay which is supported in many virtual/physical switches and

which has reserved fields that can be used to carry chain-ID and other metadata.

3.      "Enterprise Data Center Service Chaining" section is TBD. Is there a plan to compete this section?

Thanks,
Cathy

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: [email-masked]
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Jim & Thomas
SFC chairs.

---

From: Chris Frederick <[email-masked]>
Date: Wed, 22 Jan 2014 20:49:19 +0000

Hi Jim, Thomas,
I think the draft looks good.
My comment is that perhaps it doesn't consider all the challenges related to network asymmetry (i.e. where a flow's packets traverse different links).

I've read subsection 12 of the Problem Space ("Symmetric Traffic Flows") and agree with the issue, as stated.

However, we (Sandvine) take a somewhat different view of the challenges around symmetry. In our experience (residential broadband service networks), service chains are always bidirectional; the reason is that most applications manipulate the session state of the flow, which is impossible to do in only one direction.
We believe the primary challenge with symmetry - and one of the most important issues with service chaining in general - is the graceful handling of network asymmetry, to facilitate stateful inspection of bidirectional flows.
A redirected flow that needs to be chained (say, a Netflix flow for example) will often switch providers (+ network links) during its lifespan and this can present issues for SFC; there are different ways to address this challenge but they're not all equivalent in terms of efficacy and suitability. Best regards,
Chris

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Jim & Thomas
SFC chairs.

---

From: Ron Parker <[email-masked]>
Date: Wed, 22 Jan 2014 21:01:03 +0000

Hi, Chris.

I agree that symmetric traffic flows are very important from a practical perspective.    Draft-quinn-sfc-problem-statement-02 does acknowledge that they exist as part of the problem space.   Perhaps this is an area that deserves particular attention in free-standing drafts and/or in what becomes the final architecture spec.   Do you also feel that more should be said in the problem statement document?

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Chris Frederick
Sent: Wednesday, January 22, 2014 3:49 PM
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Hi Jim, Thomas,

Jim & Thomas
SFC chairs.

---

From: Ron Parker <[email-masked]>
Date: Wed, 22 Jan 2014 21:05:37 +0000

Hi, Cathy.

There was considerable discussion on the thread regarding a common service encapsulation to carry chain-id and other metadata inside of a choice of transport encapsulations, including VXLAN.    The reasons presented to keep these distinct and not try to introduce chain-id or other metadata into the subset of transports that could effectively carry such a thing was to enhance the universality and interoperability of the solution.     Such an approach lends itself well to current and perhaps future SDN techniques, but does not mandate them.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: Wednesday, January 22, 2014 3:12 PM
To: Jim Guichard (jguichar); [email-masked]; Cathy Zhang
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Hi Jim,

2.      Service Overlay

Thanks,
Cathy

Jim & Thomas
SFC chairs.

---

From: Chris Frederick <[email-masked]>
Date: Wed, 22 Jan 2014 21:10:14 +0000

Hi Ron,
>From our perspective this is one of the integral SFC challenges (at least in the SFC scenarios we encounter) and we'd welcome a more explicit examination in the problem statement document.
Failing that, inclusion in the final architecture spec is a viable alternative too, as you suggest. Either way, would be happy to have an open discussion and provide input for consideration. Best,
/c

From: Ron Parker [mailto:[email-masked]]
Sent: Wednesday, January 22, 2014 4:01 PM
To: Chris Frederick; Jim Guichard (jguichar); [email-masked]
Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02

Hi, Chris.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Chris Frederick
Sent: Wednesday, January 22, 2014 3:49 PM
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Hi Jim, Thomas,

Jim & Thomas
SFC chairs.

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 22 Jan 2014 21:39:13 +0000

I share Chris' perspective, most practical fixed-broadband use cases require symmetry (this is more than residential, btw, this also includes small/medium business and public sites) due to some form of state keeping. Same is probably true for mobile-broadband. There are clearly scenarios which do not, though, e.g. when video streaming is involved, or URL filtering. And I agree with Chris that (selective) symmetrical forwarding is one of the most vexing challenges we have with service chaining.

So a bit more emphasis wouldn't hurt. But we can always do that as we progress on the document, adoption by the work group isn't about freezing the document as is...

As a side note, IETF should expect some formal communication soon from the Broadband Forum (BBF) about service chaining, including some representative use cases.

Cheers,
Jerome

From: sfc [mailto:[email-masked]] On Behalf Of Chris Frederick
Sent: Wednesday, January 22, 2014 4:10 PM
To: Ron Parker; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Hi Ron,

From: Ron Parker [mailto:[email-masked]]
Sent: Wednesday, January 22, 2014 4:01 PM
To: Chris Frederick; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02

Hi, Chris.

   Ron

Hi Jim, Thomas,

Jim & Thomas
SFC chairs.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 22 Jan 2014 22:36:47 +0000

Hi Cathy,

From: Cathy Zhang <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 22, 2014 3:12 PM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Cathy Zhang <[email-masked]<mailto:[email-masked]>>
Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02

Hi Jim,

It mentions that “Multiple instances of the Service Function can be enabled in the same administrative domain”. There is also the case that multiple instances of the Service Function can be instantiated on the same Service Node. For example on a FW appliance, we can instantiate

Jim: as this question is directly related to the text of the draft I will let the document authors respond.

2.      Service Overlay

Jim: our charter is very clear on this point; we have a work item (with associated milestone) to produce a service-level data plane encapsulation that: [1] indicates the sequence of service functions that make up the service function chain, [2] specifies the service function path, and [3] communicates context information between nodes that implement service functions and service function chains. Further, our charter states that "the working group will consider using an existing encapsulation (with extensions as appropriate) if a suitable candidate is found".

3.      “Enterprise Data Center Service Chaining” section is TBD. Is there a plan to compete this section?

Jim: Thomas and I have been discussing how best to approach the subject of use cases within the working group; we will be starting a new thread on the mailing list shortly to detail our thoughts and to solicit input.

Thanks,
Cathy

Jim & Thomas
SFC chairs.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 23 Jan 2014 12:49:45 +0000

Hi,

On Jan 22, 2014, at 5:36 PM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Cathy,

Hi Jim,

PQ>  The defintion for service function has the following sentence: "One of multiple Service Functions can be embedded in the same network element."  I think that conveys what you are asking for, it places no limitations of the type of function instantiated.   Do you agree?  (I will fix the typo (of --> or) and remove the word network so the defn is more generic.)

2.      Service Overlay

Thanks,
Cathy

Jim & Thomas
SFC chairs.
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Cathy Zhang <[email-masked]>
Date: Thu, 23 Jan 2014 19:33:36 +0000

Hi Jim and Paul,

Thanks for your response! Please see inline.

Cathy

From: Paul Quinn (paulq) [mailto:[email-masked]]
Sent: Thursday, January 23, 2014 4:50 AM
To: Jim Guichard (jguichar); Cathy Zhang
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Hi,

Hi Cathy,

Hi Jim,

PQ>  The defintion for service function has the following sentence: "One of multiple Service Functions can be embedded in the same network element."  I think that conveys what you are asking for, it places no limitations of the type of function instantiated.   Do you agree?  (I will fix the typo (of --> or) and remove the word network so the defn is more generic.)
Cathy> Probably we need to clarify the meaning of Service Function and Service Instance in the spec? My understanding is that Service Instance is an instantiation of a type of Service Function.
So I see two cases here. One case is that one or multiple Service Functions, such as FW (one type of Service Function) and LB (another type of Service Function),
can be embedded in the same network element. The other case is that multiple instances of the same Service Function, e.g. multiple instances of FW Service Function
can be embedded in the same network element (different FW instances have different filtering rules). The document states that Multiple instances of the Service Function (eg. FW)
can be enabled in the same administrative domain. My suggestion is to add clarification that Multiple instances of the Service Function (eg. FW) can be enabled on the same network element too.
What do you think?

2.      Service Overlay

Thanks,
Cathy

Jim & Thomas
SFC chairs.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Jan 2014 16:16:32 -0500

In looking at the services, we need to be careful about who the service 
is for.  Using load balancing as an example, there are two different cases.

One case, common in  a data center, will bw where load balncing is part 
of the service being delivered to the tenant, to help manage the tenants 
application traffic.

A different situation is when load balancing is used internally to the 
service chaining to manage instances of the internal services (where 
cardinality is invisible to the tenant / user).

In the former case, LB is a service.  And has to be able to direct 
traffic to the correct tenant application instance.
In the latter case, the load balancing may well be bundled in with a 
collection of co-located service instances, with the whole looking like 
a service instance to service chaining and the end user.  (There appear 
to be a multiplicity of ways to deliver this behavior.  How much we need 
to specify in the architecture remains to be seen.)

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 24 Jan 2014 03:18:34 +0000

Joel,

Questions inserted below:

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, January 23, 2014 3:17 PM
To: Cathy Zhang; Paul Quinn (paulq); Jim Guichard (jguichar)
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

In looking at the services, we need to be careful about who the service is for.  Using load balancing as an example, there are two different cases.

One case, common in  a data center, will bw where load balncing is part of the service being delivered to the tenant, to help manage the tenants application traffic.

[Linda] do you mean when "Load Balancing" among cluster of servers for one  tenant application being offered as a service?
Isn't this kind of "load balancing" application specific? Like Oracle DB has its own Load Balancer among cluster of servers.

A different situation is when load balancing is used internally to the service chaining to manage instances of the internal services (where cardinality is invisible to the tenant / user).

In the former case, LB is a service.  And has to be able to direct traffic to the correct tenant application instance.
In the latter case, the load balancing may well be bundled in with a collection of co-located service instances, with the whole looking like a service instance to service chaining and the end user.  (There appear to be a multiplicity of ways to deliver this behavior.  How much we need to specify in the architecture remains to be seen.)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Jan 2014 22:35:44 -0500

For apps that have their own internal load balancer, I agree that there 
is no point in the tenant using the data center offered load balancer 
service.
But many apps do not have their own custom load balancer.  So a data 
center might well offer load balancing as a service for those tenants 
who want it.

My only point was to distinguish load balancing as a service selected by 
the customer from load balancing used by the oeprator internall;y to 
deliver some other service.

Yours,
Joel

On 1/23/14 10:18 PM, Linda Dunbar wrote:
> [Linda] do you mean when "Load Balancing" among cluster of servers for
> one tenant application being offered as a service?
> Isn't this kind of "load balancing" application specific? Like Oracle DB
> has its own Load Balancer among cluster of servers.
> [email-masked] <mailto:[email-masked]>

---

From: Ron Parker <[email-masked]>
Date: Fri, 24 Jan 2014 14:20:57 +0000

Hi, Joel.

I think you raise an excellent point on the ambiguity of load balancing.   I would propose that there are more than 2 cases of load balancing:

* mid-box service function (e.g., firewall) with internal load balancing
* mid-box service function (e.g., firewall) requiring external load balancing
* explicitly addressed service (e.g., DB server) with internal load balancing
* explicitly addressed service (e.g., Web HTTP server) requiring external load balancing

>From an SFC perspective, I think we can ignore the cases where the mid-box or explicit application is internally load balanced.   Such applications would typically present a single locator (i.e., IP address) to the outside world and manage redirection internally to the clustered application.    

I think the last bullet, external load balancing for an explicitly addressed service (e.g., Web HTTP server) lends itself to load balancing as an explicit service function from an SFC perspective.   That is, the service function in the service function chain is "load balancer".

The second bullet, external load balancing for mid-box service function (e.g., firewall), is slightly trickier.   From an SFC perspective, my view is that the service function that appears in the service function chain is still firewall and not load balancer.   However, I do think that SFC should explicitly embrace the concept of a "load-balanced service function".   I tried to address this in http://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/ and would appreciate any feedback.

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, January 23, 2014 10:36 PM
To: Linda Dunbar; Cathy Zhang; Paul Quinn (paulq); Jim Guichard (jguichar)
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

For apps that have their own internal load balancer, I agree that there is no point in the tenant using the data center offered load balancer service.
But many apps do not have their own custom load balancer.  So a data center might well offer load balancing as a service for those tenants who want it.

My only point was to distinguish load balancing as a service selected by the customer from load balancing used by the oeprator internall;y to deliver some other service.

Yours,
Joel

On 1/23/14 10:18 PM, Linda Dunbar wrote:
> In looking at the services, we need to be careful about who the 
> service is for.  Using load balancing as an example, there are two different cases.
> One case, common in  a data center, will bw where load balncing is 
> part of the service being delivered to the tenant, to help manage the 
> tenants application traffic.
> Isn't this kind of "load balancing" application specific? Like Oracle 
> DB has its own Load Balancer among cluster of servers.
> collection of co-located service instances, with the whole looking 
> like a service instance to service chaining and the end user.  (There 
> appear to be a multiplicity of ways to deliver this behavior.  How 
> much we need to specify in the architecture remains to be seen.) 
> Yours, Joel _______________________________________________
> sfc mailing list
[email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 24 Jan 2014 10:22:37 -0500

To avoid further confusion, should we refer to the selection of a service instance as "service distribution" instead of "load balancing" to clearly differentiate this from the "load balancer" service?

From: [email-masked]<[email-masked]>
To: Joel M. Halpern<[email-masked]>,Linda Dunbar<[email-masked]>,Cathy Zhang<[email-masked]>,Paul
 Quinn (paulq)<[email-masked]>,Jim Guichard (jguichar)<[email-masked]>
cc: [email-masked]<[email-masked]>
Sent: Friday, January 24, 2014
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Hi, Joel.

Thanks.

   Ron

-----Original Message-----

From: sfc [mailto:[email-masked]] On Behalf Of Joel M. HalpernSent: Thursday, January 23, 2014 10:36 PMTo: Linda Dunbar; Cathy Zhang; Paul Quinn (paulq); Jim Guichard (jguichar)Cc: [email-masked]: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02For apps that have their own internal load balancer, I agree that there is no point in the tenant using the data center offered load balancer service.But many apps do not have their own custom load balancer.  So a data center might well offer load balancing as a service for those tenants who want it.My only point was to distinguish load balancing as a service selected by the customer from load balancing used by the oeprator internall;y to deliver some other service.Yours,JoelOn 1/23/14 10:18 PM, Linda Dunbar wrote:> Joel,> Questions inserted below:> -----Original Message-----> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern> Sent: Thursday, January 23, 2014 3:17 PM> To: Cathy Zhang; Paul Quinn (paulq); Jim Guichard (jguichar)> Cc: [email-masked]> Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02> In looking at the services, we need to be careful about who the > service is for.  Using load balancing as an example, there are two different cases.> One case, common in  a data center, will bw where load balncing is > part of the service being delivered to the tenant, to help manage the > tenants application traffic.> [Linda] do you mean when "Load Balancing" among cluster of servers for > one tenant application being offered as a service?> Isn't this kind of "load balancing" application specific? Like Oracle > DB has its own Load Balancer among cluster of servers.> A different situation is when load balancing is used internally to the > service chaining to manage instances of the internal services (where > cardinality is invisible to the tenant / user).> In the former case, LB is a service.  And has to be able to direct > traffic to the correct tenant application instance.> In the latter case, the load balancing may well be bundled in with a > collection of co-located service instances, with the whole looking > like a service instance to service chaining and the end user.  (There > appear to be a multiplicity of ways to deliver this behavior.  How > much we need to specify in the architecture remains to be seen.) > Yours, Joel _______________________________________________> sfc mailing list> [email-masked] <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/sfc_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: Jerome Moisand <[email-masked]>
Date: Fri, 24 Jan 2014 15:33:41 +0000

Great idea, Mike.

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 24, 2014 10:23 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: Joel M. Halpern<[email-masked]<mailto:[email-masked]>>,Linda Dunbar<[email-masked]<mailto:[email-masked]>>,Cathy Zhang<[email-masked]<mailto:[email-masked]>>,Paul Quinn (paulq)<[email-masked]<mailto:[email-masked]>>,Jim Guichard (jguichar)<[email-masked]<mailto:[email-masked]>>
cc: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
Sent: Friday, January 24, 2014
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Hi, Joel.

Thanks.

  Ron

-----Original Message-----

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

Yours,
Joel

On 1/23/14 10:18 PM, Linda Dunbar wrote:
> Cc: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 24 Jan 2014 17:14:43 +0000

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>

[Linda] Do flows go through “Service Distribution Point” before going to individual instances? If the service chain path identify the individual instances, then the “service distribution” is more like “manager” role, i.e. the data flows don’t go through the “Service Distribution” point.

Linda

Hi, Joel.

Thanks.

  Ron

-----Original Message-----

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 24 Jan 2014 12:37:51 -0500

From: [email-masked]<[email-masked]>
To: Jerome Moisand<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,Cathy Zhang<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
cc: [email-masked]<[email-masked]>
Sent: Friday, January 24, 2014
Subject: RE: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

From: sfc [mailto:[email-masked]]
On Behalf Of [email-masked]

To avoid further confusion, should we refer to the selection of a service instance as "service distribution" instead of "load balancing" to clearly
 differentiate this from the "load balancer" service?
 
[Linda] Do flows go through “Service Distribution Point” before going to individual instances? If the service chain path identify
 the individual instances, then the “service distribution” is more like “manager” role, i.e. the data flows don’t go through the “Service Distribution” point.

Linda

Sure, whatever.  My point is to use the term "load balance" to refer to a service in the chain and not use the term when referring to multiple instances of a service in the chain (of which there are a number of implementation methods).
fwiw, you could comprise a service chain of all load-balancer services and let each of those distribute flows to the instances, such that the chain itself appears quite simple (LB1-LB2-LB3), hiding the fact that LB1 is a fwlb and lb2 is a natlb, etc.  But that, of course, is lunacy and still leaves open the question, "What if we want to balance the balancers?"

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Sun, 26 Jan 2014 08:10:48 +0000

Sorry for being late. I support the adoption and am looking forward to the upcoming detailed use case work starting from here.

Regards,
Shucheng (Will)

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, January 22, 2014 3:14 AM
To: [email-masked]
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Jim & Thomas
SFC chairs.