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

From: "[email-masked]" <[email-masked]>
Date: Fri, 24 Jan 2014 11:04:53 -0500

To contextualize my comments:
Assuming you needed to insert a CDN into a chain and had 8 equally viable instances (cdn1..cdn8), I see two primary methods of choosing which instance receives a particular flow:
1.  The chain includes either the pool of services (CDN) or a shim service (proxy, service lb) where the specific instance is selected on the fly
2. The specific instance is part of the chain (cdn1)

If the latter (instance in chain), should SFC include a mechanism for remapping the chain to use another instance?

In either case, should the selection of the instance ("service distribution"?  anyone?  anyone?) be part of SFC or left up to implementation?

Since we've already discussed dynamically inserting and removing services into or from a chain (long flow use cases draft), it seems that specifying the specific service instance in a chain (#1 above) for a flow would be simpler than introducing a shim proxyish service.  This approach might also simplify the requirements for stateful v non-stateful services.

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.

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. 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: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 24 Jan 2014 16:18:08 +0000

Hi Mike,

On Jan 24, 2014, at 11:04 AM, [email-masked]<mailto:[email-masked]> wrote:

It depends :)  In case #1, does the "shim service" present itself as a SF?  It might still have policy dependencies about being coupled with cdn, but is it externally "visible"?

________________________________
From: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[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]<mailto:[email-masked]><[email-masked]<mailto:[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]<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]<mailto:[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:
> Joel,
> Questions inserted below:
> From: sfc [mailto:[email-masked]<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]<mailto:[email-masked]>
> 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]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 24 Jan 2014 16:35:55 +0000

If a service function has a small number of instances, say less than 10, and they are relative stable, then it is doable for Service Chain to specify the specific instances.

But if there are large number of instances, say in hundreds, and those instances' location/presence change over time (e.g. in NFV environment), then it is not scalable to have Service Chain path to specify the specific instances. The instances selection should be left up to implementation, or at least out of the SFC WG scope.

Linda

From: Paul Quinn (paulq) [mailto:[email-masked]]

Hi, Joel.

Thanks.

Ron

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

Yours,
Joel

---

From: Chris Frederick <[email-masked]>
Date: Fri, 24 Jan 2014 17:09:45 +0000

Policy-based selection of a particular service function instance (path) can be useful in a number of scenarios (say, where there's a desire to send a particular app/protocol to cache1 vs. cache2, etc).
In the interest of sharing approaches, we lb on internal IP of each flow (ensuring the same flow goes to the same instance) across named instances, physical or virtualized.
This  approach obviously implies a need to health check not just the chain but individual instances as well, which we do w/ an inline health check, going both directions through the chain.
I think it makes sense to allow the specification of a set of equivalent chains, decided by the start of the chain. Thx,
/c

From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, January 24, 2014 11:36 AM
To: Paul Quinn (paulq); [email-masked]
Cc: Jim Guichard (jguichar); Cathy Zhang; <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Linda

Hi, Joel.

Thanks.

Ron

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

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 24 Jan 2014 17:14:01 +0000

You bring  good point, but it seems it still aligned with current proposal.

A Service Chain does not specify the actual stateless firewall (out of the
hundreds of function equivalent firewalls) that are going to be used in a
chain. Just that a firewall is present on a chain.

A Service Function Path is an instantiation of a Service Chain. It
specifies the actual firewall (say, firewall-3) that will be traversed by
the packets. The Service Path needs to be known before hand or stitched
run-time (given the dynamic LB decision) since a forwarding decision need
to be made regardless.

So, in your example there would one chain, many service paths. Other
combinations are possible of course depending on implementation strategy.

From:  Linda Dunbar <[email-masked]>
Date:  Friday, January 24, 2014 at 8:35 AM
To:  "Paul Quinn (paulq)" <[email-masked]>, "[email-masked]"
<[email-masked]>
Cc:  "Jim Guichard (jguichar)" <[email-masked]>, Cathy Zhang
<[email-masked]>, "<[email-masked]>" <[email-masked]>,
"<[email-masked]>" <[email-masked]>, "<[email-masked]>"
<[email-masked]>
Subject:  Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

If a service function has a small number of instances, say less than 10,
and they are relative stable, then it is doable for Service Chain to
specify the specific
 instances. 
 
But if there are large number of instances, say in hundreds, and those
instances¹ location/presence change over time (e.g. in NFV environment),
then it is not
 scalable to have Service Chain path to specify the specific instances.
The instances selection should be left up to implementation, or at least
out of the SFC WG scope.

Linda

Assuming you needed to insert a CDN into a chain and had 8 equally viable
instances (cdn1..cdn8), I see two primary methods of choosing which
instance receives a particular
 flow:

1.  The chain includes either the pool of services (CDN) or a shim service
(proxy, service lb) where the specific instance is selected on the fly

If the latter (instance in chain), should SFC include a mechanism for
remapping the chain to use another instance?

In either case, should the selection of the instance ("service
distribution"? anyone? anyone?) be part of SFC or left up to
implementation?

It depends :)  In case #1, does the "shim service" present itself as a SF?
 It might still have policy dependencies about being coupled with cdn, but
is it externally "visible"?

Since we've already discussed dynamically inserting and removing services
into or from a chain (long flow use cases draft), it seems that specifying
the specific service instance
 in a chain (#1 above) for a flow would be simpler than introducing a shim
proxyish service.  This approach might also simplify the requirements for
stateful v non-stateful services.

________________________________________

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.

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:
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Cc: [email-masked]
> [email-masked] <mailto:[email-masked]>

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Fri, 24 Jan 2014 17:17:59 +0000

> Assuming you needed to insert a CDN into a chain and had 8 equally viable instances (cdn1..cdn8), I see two primary methods
> of choosing which instance receives a particular flow:

Could this lead to "chaining chains"?

Let's take the example of load balancing traffic to transparent proxies for say, header insertion. (This is a classic case in Gi Networks).

  *   The load balancer should be part of the service chain if the balancing algorithm dynamically selects the specific proxy instance (think of IP source stickiness).  On its way in, the proxies need then not be part of the service chain.
  *   On the way out, the proxy could be part of a second chain, since it creates a new TCP connection, thus avoiding to have to reroute the traffic back to the load balancer.

So: chain1 :  GGSN - some services -LBS
      chain2:  Proxy-other services- Internet FW

In addition, the Proxy instances could have a responsibility to pass information (metadata?) from chain1 to chain 2. In particular when the second service chain should be selected based on the subscriber id, as there is no way to identify this subscriber based on the networking information held in the traffic going out to the internet.  How this would be possible is an open question.

Nicolas

To: Joel M. Halpern<[email-masked]>,Linda Dunbar<[email-masked]>,Cathy Zhang<[email-masked]>,Paul Quinn (paulq)<[email-masked]>,Jim Guichard (jguichar)<[email-masked]>

Hi, Joel.

Thanks.

Ron

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

Yours,
Joel

---

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

We might want to be able to chain chains if the chain needs to extend through multiple entities.  e.g. if you have one chain within the datacenter, but then want to signal the backbone provider (not you) to add services to the chain.  Could be one big dynamic chain.  Could be chained/sequential chains.

From: [email-masked]<[email-masked]>
To: [email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[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

> 1.  The chain includes either the pool of services (CDN) or a shim service (proxy, service lb) where the specific instance is

>      selected on the fly

The load balancer should be part of the service chain if the balancing algorithm dynamically selects the specific proxy instance (think of IP source stickiness).  On its way in, the proxies need then not be part of the service chain.On the way out, the proxy could be part of a second chain, since it creates a new TCP connection, thus avoiding to have to reroute the traffic back
 to the load balancer.

In addition, the Proxy instances could have a responsibility to pass information (metadata?) from chain1 to chain 2. In particular when the second service chain should be selected based on the subscriber id,
 as there is no way to identify this subscriber based on the networking information held in the traffic going out to the internet.  How this would be possible is an open question.

Nicolas

To: Joel M. Halpern<[email-masked]>,Linda Dunbar<[email-masked]>,Cathy Zhang<[email-masked]>,Paul Quinn (paulq)<[email-masked]>,Jim Guichard
 (jguichar)<[email-masked]>

Hi, Joel.

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

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 24 Jan 2014 17:35:45 +0000

I would say yes but not sure in the charter.

There was no explicit discussion if a long chain can be broken (always?) into chains of one service function each.  But that does not imply the reverse, i.e., if multiple chains can be contracted into one long chain.

From: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 24, 2014 at 9:17 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02