Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt

From: <[email-masked]>
Date: Fri, 15 Nov 2013 10:01:25 +0100

Hi Behcet,

We have added that sentence on purpose. Instantiating differentiated chains on a per-subscriber basis is not justified given the current use cases we have identified so far. The parental control filters are not designed for each individual subscriber but are generic ones (few profiles can be enabled in the service function providing such function).

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Behcet Sarikaya
Envoyé : mardi 15 octobre 2013 17:45
À : Liushucheng (Will)
Cc : [email-masked]
Objet : Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt

Hi Shucheng,
In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in the network.
      Deployments cases that would require per-subscriber SFCs are out
      of scope.
However you have at least three parental control use cases. How would it be possible to have parental control not being per-subscriber?
Regards,
Behcet

On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

We've uploaded the updated and renamed use case draft. Looking forward to your comments.

Regards,
Shucheng LIU (Will)

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt

A new version of I-D, draft-liu-sfc-use-cases-00.txt
has been successfully submitted by Will(Shucheng) Liu and posted to the
IETF repository.

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cases
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/draft-liu-sfc-use-cases-00

Abstract:
   The delivery of value-added services relies on the invocation of
   advanced Service Functions in a sequential order.  This mechanism is
   called Service Function Chaining (SFC).  The set of involved Service
   Functions and their order depends on the service context.

   This document presents a set of use cases of Service Function
   Chaining (SFC).

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

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

---

From: <[email-masked]>
Date: Fri, 15 Nov 2013 10:08:09 +0100

Hi Behcet,

Which requirements document are you referring to? This one http://tools.ietf.org/html/draft-boucadair-sfc-requirements-00?

We should make a distinction between classification rules and the set of SFCs themselves. Classification rules may be subscriber-inferred while I'm still not convinced the set of SFCs should be built on a per-subscriber basis.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Behcet Sarikaya
Envoyé : mercredi 16 octobre 2013 00:11
À : Ian Smith
Cc : [email-masked]; Jim Guichard (jguichar); Liushucheng (Will); Ron Parker
Objet : Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt

Folks, I checked and found out that in the requirements draft per-subscriber service issue is pretty clearly stated.
My suggestion is to remove the paragraph that starts with SFC are not per-subscriber. It is confusing.
Regards,
Behcet

On Tue, Oct 15, 2013 at 4:14 PM, Ian Smith <[email-masked]<mailto:[email-masked]>> wrote:
I'll see what I can do.
________________________________
From: Jim Guichard (jguichar) [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, October 15, 2013 5:14 PM
To: Ian Smith
Cc: Ron Parker; <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Liushucheng (Will)

Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt

Use cases from real operators would be a start.

Sent from my iPhone

On Oct 15, 2013, at 5:11 PM, "Ian Smith" <[email-masked]<mailto:[email-masked]>> wrote:
what do you need to make this reality driven?
________________________________
From: Jim Guichard (jguichar) [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, October 15, 2013 5:02 PM
To: Ron Parker
Cc: <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Liushucheng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt
Sure but we should deal in reality driven by use cases and I have yet to see anyone suggest they will build an individual service chain for every client. In fact the complete opposite seems true.

Sent from my iPhone

On Oct 15, 2013, at 4:52 PM, "Ron Parker" <[email-masked]<mailto:[email-masked]>> wrote:
Agree that is the typical usage of policy.   And, the degenerate case is that the world is comprised of subscriber groups that have exactly 1 subscriber.   Probably not practical, but why prevent it?

   Ron

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, October 15, 2013 4:48 PM
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Liushucheng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt

No, to me this is most certainly a per-subscriber-group.

Sent from my iPhone

On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" <[email-masked]<mailto:[email-masked]>> wrote:
 I was talking about something like parental control.
Do you qualify such an SFC as each mobile client getting its own SFC?
I think it is more like per-subscriber-group. It could be per subscriber as well but I can not think of an example at this moment.

On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ian,
If by subscriber you mean per-tenant or per-subscriber-group then I will agree that SFC's will be built for these but that's a far cry from per-subscriber which implies to me an individual broadband or mobile client.

Sent from my iPhone

On Oct 15, 2013, at 1:51 PM, "Ian Smith" <[email-masked]<mailto:[email-masked]>> wrote:
I don't think that is a foregone conclusion.

When you combine what is being done in IaaS environments for muti-tenant dynamic datacenters with what you can do with policy defined networking and IPv6, for an access provider to provision per-subscriber VAS LANs and default gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with service chains.  More to the point, you don't need to disaggregate anything when you know that all the traffic belongs to a single customer, and that the default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@1Gbps is trivial; what makes what we're talking about in this list hard is that you are trying to solve it for 10 million subscribers @100Gbps but in truth the only technology-based reason you do that is because of administrative challenges that the cloud world is solving (and may have solved before anything is produced in a WG) and that are squarely in the domain of things already proven to be better done by computers than people.

I tend to argue that per-subscriber provisioning of the access path triggered by identity-based authentication is the obvious and natural evolution of the technology being fielded today.

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Jim Guichard (jguichar) [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, October 15, 2013 1:34 PM
To: [email-masked]<mailto:[email-masked]>; Liushucheng (Will)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt
It seems very unlikely that one would opt for a solution whereby a separate SFC is required per-subscriber; clearly millions of SFC's is not desirable no matter how you cut it. IMHO, the support of services that require per-subscriber policy are more likely to be realized using something like the solution described in draft-quinn-sfc-nsh.

From: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt

Hi Shucheng,

Regards,
Shucheng LIU (Will)

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt

Abstract:

The IETF Secretariat

---

From: Ron Parker <[email-masked]>
Date: Fri, 15 Nov 2013 13:05:55 +0000

In subscriber-based networks, the classification rules will generally be applied to groups of subscribers.  Of course, the degenerate case is each is a group of one.

    Ron

On Nov 15, 2013, at 4:08 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Behcet,

We should make a distinction between classification rules and the set of SFCs themselves. Classification rules may be subscriber-inferred while I’m still not convinced the set of SFCs should be built on a per-subscriber basis.

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Behcet Sarikaya
Envoyé : mercredi 16 octobre 2013 00:11
À : Ian Smith
Cc : [email-masked]<mailto:[email-masked]>; Jim Guichard (jguichar); Liushucheng (Will); Ron Parker
Objet : Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt

Sent from my iPhone

Sent from my iPhone

   Ron

Sent from my iPhone

Sent from my iPhone

Hi Shucheng,

Regards,
Shucheng LIU (Will)

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt

Abstract:

The IETF Secretariat

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 Nov 2013 10:09:29 -0600

Hi Med,

I think that the parental control service is an example. Another example is
the traffic offloader service that we defined in draft-xue-aps-service
chaining-usecase-00.txt.

Regards,

Behcet

On Fri, Nov 15, 2013 at 3:08 AM, <[email-masked]> wrote:

> Hi Behcet,
>
>
>
> Which requirements document are you referring to? This one
> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-00?
>
>
>
> We should make a distinction between classification rules and the set of
> SFCs themselves. Classification rules may be subscriber-inferred while I’m
> still not convinced the set of SFCs should be built on a per-subscriber
> basis.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* [email-masked] [mailto:[email-masked]] *De la part de*Behcet Sarikaya
> *Envoyé :* mercredi 16 octobre 2013 00:11
> *À :* Ian Smith
> *Cc :* [email-masked]; Jim Guichard (jguichar); Liushucheng (Will); Ron
> Parker
> *Objet :* Re: [nsc] FW: New Version Notification for
> draft-liu-sfc-use-cases-00.txt
>
>
>
> Folks, I checked and found out that in the requirements draft
> per-subscriber service issue is pretty clearly stated.
>
> On Tue, Oct 15, 2013 at 4:14 PM, Ian Smith <[email-masked]> wrote:
>
> I'll see what I can do.
> ------------------------------
>
> *From:* Jim Guichard (jguichar) [[email-masked]]
>
> *Sent:* Tuesday, October 15, 2013 5:14 PM
> *To:* Ian Smith
> *Cc:* Ron Parker; <[email-masked]>; [email-masked]; Liushucheng (Will)
>
>
> *Subject:* Re: [nsc] FW: New Version Notification for
> draft-liu-sfc-use-cases-00.txt
>
>
>
> On Oct 15, 2013, at 5:11 PM, "Ian Smith" <[email-masked]> wrote:
>
> ------------------------------
>
> *From:* Jim Guichard (jguichar) [[email-masked]]
> *Sent:* Tuesday, October 15, 2013 5:02 PM
> *To:* Ron Parker
> *Cc:* <[email-masked]>; [email-masked]; Liushucheng (Will); Ian Smith
> *Subject:* Re: [nsc] FW: New Version Notification for
> draft-liu-sfc-use-cases-00.txt
>
> Sure but we should deal in reality driven by use cases and I have yet to
> see anyone suggest they will build an individual service chain for every
> client. In fact the complete opposite seems true.
>
> Sent from my iPhone
>
>
> On Oct 15, 2013, at 4:52 PM, "Ron Parker" <[email-masked]>
> wrote:
>
> Agree that is the typical usage of policy.   And, the degenerate case is
> that the world is comprised of subscriber groups that have exactly 1
> subscriber.   Probably not practical, but why prevent it?
>
>
>
>    Ron
>
>
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Jim Guichard (jguichar)
> *Sent:* Tuesday, October 15, 2013 4:48 PM
> *To:* <[email-masked]>
> *Cc:* [email-masked]; Liushucheng (Will); Ian Smith
> *Subject:* Re: [nsc] FW: New Version Notification for
> draft-liu-sfc-use-cases-00.txt
>
>
>
> On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" <[email-masked]>
> wrote:
>
> I think it is more like per-subscriber-group. It could be per subscriber
> as well but I can not think of an example at this moment.
>
>
>
> On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) <
> [email-masked]> wrote:
>
> Hi Ian,
>
> If by subscriber you mean per-tenant or per-subscriber-group then I will
> agree that SFC's will be built for these but that's a far cry from
> per-subscriber which implies to me an individual broadband or mobile client.
>
> Sent from my iPhone
>
>
> On Oct 15, 2013, at 1:51 PM, "Ian Smith" <[email-masked]> wrote:
>
> When you combine what is being done in IaaS environments for muti-tenant
> dynamic datacenters with what you can do with policy defined networking and
> IPv6, for an access provider to provision per-subscriber VAS LANs and
> default gateways takes away a lot of the big problems caused by aggregation
> that you're trying to solve with service chains.  More to the point, you
> don't need to disaggregate anything when you know that all the traffic
> belongs to a single customer, and that the default gateway of each node is
> the next hop in the service chain.  Solving the problem for 1
> subscriber@1Gbps is trivial; what makes what we're talking about in this
> list hard is that you are trying to solve it for 10 million subscribers
> @100Gbps but in truth the only technology-based reason you do that is
> because of administrative challenges that the cloud world is solving (and
> may have solved before anything is produced in a WG) and that are squarely
> in the domain of things already proven to be better done by computers than
> people.
>
> I tend to argue that per-subscriber provisioning of the access path
> triggered by identity-based authentication is the obvious and natural
> evolution of the technology being fielded today.
>
>
> ------------------------------
>
> *From:* [email-masked] [[email-masked]] on behalf of Jim
> Guichard (jguichar) [[email-masked]]
> *Sent:* Tuesday, October 15, 2013 1:34 PM
> *To:* [email-masked]; Liushucheng (Will)
> *Cc:* [email-masked]
> *Subject:* Re: [nsc] FW: New Version Notification for
> draft-liu-sfc-use-cases-00.txt
>
> It seems very unlikely that one would opt for a solution whereby a
> separate SFC is required per-subscriber; clearly millions of SFC's is not
> desirable no matter how you cut it. IMHO, the support of services that
> require per-subscriber policy are more likely to be realized using
> something like the solution described in draft-quinn-sfc-nsh.
>
>
>
> *From: *Behcet Sarikaya <[email-masked]>
> *Reply-To: *"[email-masked]" <[email-masked]>
> *Date: *Tuesday, October 15, 2013 11:44 AM
> *To: *"Liushucheng (Will)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [nsc] FW: New Version Notification for
> draft-liu-sfc-use-cases-00.txt
>
>
>
> Hi Shucheng,
>
> However you have at least three parental control use cases. How would it
> be possible to have parental control not being per-subscriber?
>
> Regards,
>
> Behcet
>
>
>
> On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) <
> [email-masked]> wrote:
>
> Folks,
>
> From: [email-masked] [mailto:[email-masked]]
> To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver);
> Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
> URL:
> http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> [email-masked]

---

From: Ken Gray <[email-masked]>
Date: Wed, 20 Nov 2013 17:58:06 +0000

To me the difference is between making decisions within a chain based on user-data (which could be metadata placed by the initial classifier at the head of the chain) versus establishing a new chain per-user.  These examples (so far) don't illustrate the latter.

A separate chain would be required "per user" because the service required a separate, per-subscriber interface (e.g. for some non-common/unshared configuration ... like on a FW ... or some treatment within the function that can't be handled solely by the metadata) on at least one of the SF in the chain.

Clearly, there are cases where a particular service might branch based on user-id and some pre-condition at the decision point.  But I still don't see a separate per-user chain beyond that point.

Arguably, when I come up with an example of a per-user chain, it's normally at a fan-out point at the terminus of the chain - which may still not qualify as an example we'd want to chase, since you'd be racing the scalability of placing some stateless LB function in the NNH of the chain against the scalability of per-user chain state management for that last step steering (LB in the central chain-building process).

My .02

________________________________
From: nsc <[email-masked]> on behalf of Behcet Sarikaya <[email-masked]>
Sent: Wednesday, November 20, 2013 11:09 AM
To: Mohamed Boucadair
Cc: [email-masked]; Jim Guichard (jguichar); Ron Parker; Liushucheng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt

Hi Med,

I think that the parental control service is an example. Another example is the traffic offloader service that we defined in draft-xue-aps-service chaining-usecase-00.txt.

Regards,

Behcet

On Fri, Nov 15, 2013 at 3:08 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Behcet,

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Behcet Sarikaya
Envoyé : mercredi 16 octobre 2013 00:11
À : Ian Smith
Cc : [email-masked]<mailto:[email-masked]>; Jim Guichard (jguichar); Liushucheng (Will); Ron Parker
Objet : Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt

Sent from my iPhone

Sent from my iPhone

   Ron

Sent from my iPhone

Sent from my iPhone

Hi Shucheng,

Regards,
Shucheng LIU (Will)

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cases
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt<https://wf-access.juniper.net/internet-drafts/,DanaInfo=www.ietf.org+draft-liu-sfc-use-cases-00.txt>
Status:          http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases<https://wf-access.juniper.net/doc/,DanaInfo=datatracker.ietf.org+draft-liu-sfc-use-cases>
Htmlized:        http://tools.ietf.org/html/draft-liu-sfc-use-cases-00<https://wf-access.juniper.net/html/,DanaInfo=tools.ietf.org+draft-liu-sfc-use-cases-00>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://wf-access.juniper.net/,DanaInfo=tools.ietf.org+>.

The IETF Secretariat

_______________________________________________
nsc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nsc<https://wf-access.juniper.net/mailman/listinfo/,DanaInfo=www.ietf.org,SSL+nsc>