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

From: "Liushucheng (Will)" <[email-masked]>
Date: Tue, 11 Feb 2014 09:18:09 +0000

Hi all,

We've just updated our use case draft. The main change is in the section of Use Case of Service Function Chain in Mobile Core Network. Looking forward to your comments.

Regards,
Shucheng (Will)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 11, 2014 5:14 PM
To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; Huangyong (Oliver)
Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt

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

Name:		draft-liu-sfc-use-cases
Revision:	01
Title:		Service Function Chaining (SFC) Use Cases
Document date:	2014-02-11
Group:		Individual Submission
Pages:		15
URL:            http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-01.txt
Status:         https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/
Htmlized:       http://tools.ietf.org/html/draft-liu-sfc-use-cases-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-liu-sfc-use-cases-01

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.

The IETF Secretariat

---

From: Alla Goldner <[email-masked]>
Date: Tue, 11 Feb 2014 10:52:57 +0000

Dear Shucheng,

With regard to this use case description, it would be useful, in my opinion, referring to the existing 3GPP architecture as per 3GPP TS 23.203 where Traffic Detection Function (TDF) is a standardized element residing on Gi/SGi which implements DPI (detection) functionality along with enforcement and charging of the corresponding detected applications. This is missing from your use case description. I think such a comment was already provided in a different email thread.

Best Regards,

Alla Goldner
Director of Mobile Technologies and Standards
Allot Communications
Tel +972 9 7619251
Cell +972 54 2493985
Fax +972 9 7443626
[email-masked] 
www.allot.com

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Liushucheng (Will)
Sent: Tuesday, February 11, 2014 11:18 AM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Hi all,

Regards,
Shucheng (Will)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 11, 2014 5:14 PM
To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; Huangyong (Oliver)
Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt

Abstract:

The IETF Secretariat

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc
##############################################################################################
This message is intended only for the designated recipient(s).It may contain confidential or proprietary information.
If you are not the designated recipient, you may not review, copy or distribute this message.
If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. 
Thank you.
##############################################################################################

---

From: "Pham, Chuong D" <[email-masked]>
Date: Wed, 12 Feb 2014 12:58:40 +1100

Hi Liushucheng,

There is also the case where a service function is selected based on user subscription. For example, steering traffic to a Parental Control (PC) only for the flows belonging to users who have PC subscription. One way of doing it is for the PCRF to notify the classifier about the correct flows to expect prior to the arrival of these flows. 

Other example is steering traffic to a DPI based on users with QoS subscriptions for the purpose of reporting and optionally enforcement.

Another example is when a user wants to opt-out of service functions such as an Operator-mandate video optimisation platform for reasons such as the user is a Gold user with QoS and requirements for high resolution video.

To me, user subscription based traffic steering/servicing chaining is important for Mobile and at the same time, it poses great challenge on scalability therefore it is worthwhile to be included in your draft.

Regards,
Chuong

-----Original Message-----
From: Alla Goldner [mailto:[email-masked]] 
Sent: Tuesday, 11 February 2014 9:53 PM
To: Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Shucheng,

Best Regards,

Alla Goldner
Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 [email-masked] www.allot.com

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Liushucheng (Will)
Sent: Tuesday, February 11, 2014 11:18 AM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Hi all,

Regards,
Shucheng (Will)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 11, 2014 5:14 PM
To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; Huangyong (Oliver)
Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt

Abstract:

The IETF Secretariat

---

From: <[email-masked]>
Date: Wed, 12 Feb 2014 10:22:41 +0100

Dear Chuong,

Thank you for the inputs. The draft will be updated to reflect most of your points. 

As for the per-subscriber SFC, the scalability discussion is already recorded here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-6. Beside considerations on scalability, what is really helpful is to identify *** concrete *** use cases that would require such per-subscriber SFCs (that would lead to instantiating millions of SFCs in a domain): i.e., are there real business motivations to configure customized service chains for each subscriber? Wouldn't be realistic to assume chains for groups of subscribers?

Cheers,
Med

>-----Message d'origine-----
>De : sfc [mailto:[email-masked]] De la part de Pham, Chuong D
>Envoyé : mercredi 12 février 2014 02:59
>À : Alla Goldner; Liushucheng (Will); [email-masked]
>Objet : Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-
>01.txt
>
>Hi Liushucheng,
>
>There is also the case where a service function is selected based on user
>subscription. For example, steering traffic to a Parental Control (PC) only
>for the flows belonging to users who have PC subscription. One way of doing
>it is for the PCRF to notify the classifier about the correct flows to
>expect prior to the arrival of these flows.
>
>Other example is steering traffic to a DPI based on users with QoS
>subscriptions for the purpose of reporting and optionally enforcement.
>
>Another example is when a user wants to opt-out of service functions such
>as an Operator-mandate video optimisation platform for reasons such as the
>user is a Gold user with QoS and requirements for high resolution video.
>
>To me, user subscription based traffic steering/servicing chaining is
>important for Mobile and at the same time, it poses great challenge on
>scalability therefore it is worthwhile to be included in your draft.
>
>
>Regards,
>Chuong
>
>With regard to this use case description, it would be useful, in my
>opinion, referring to the existing 3GPP architecture as per 3GPP TS 23.203
>where Traffic Detection Function (TDF) is a standardized element residing
>on Gi/SGi which implements DPI (detection) functionality along with
>enforcement and charging of the corresponding detected applications. This
>is missing from your use case description. I think such a comment was
>already provided in a different email thread.
>
>Best Regards,
>
>
>Alla Goldner
>Director of Mobile Technologies and Standards Allot Communications Tel +972
>9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 [email-masked]
>www.allot.com
>
>
>
>
>We've just updated our use case draft. The main change is in the section of
>Use Case of Service Function Chain in Mobile Core Network. Looking forward
>to your comments.
>
>Regards,
>Shucheng (Will)
>
>
>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;
>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leymann;
>Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu;
>Huangyong (Oliver)
>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been successfully
>submitted by Will(Shucheng) Liu and posted to the IETF repository.
>
>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.
>
>The IETF Secretariat
>
>This message is intended only for the designated recipient(s).It may
>contain confidential or proprietary information.

---

From: "Pham, Chuong D" <[email-masked]>
Date: Thu, 13 Feb 2014 09:09:52 +1100

Hi Med,

Actually the scalability issue is pertaining to the need to have subscriber-awareness so that subscribers are assigned to the correct groups. For example, subscriber-A belongs to Parental Control group, subscriber-B belongs to QoS-enabled group, subscriber-C belongs to a group which has both Parental Control and QoS-enabled.

The number of SFCs will be the same (permutation of service functions are the same), however the need to have visibility of subscriber's IP address (dynamically assigned in Mobile network), subscriber identity i.e. the phone number and the services that the subscriber have subscribed to is where the scalability concern is IMHO. 

So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-6 is still valid and my input adds the ability to recognise flows from individual mobile users and assign them to a correct group of subscribers who share a same SFC.

Regards,
Chuong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, 12 February 2014 8:23 PM
To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Chuong,

Cheers,
Med

>Envoyé : mercredi 12 février 2014 02:59 À : Alla Goldner; Liushucheng 
>(Will); [email-masked] Objet : Re: [sfc] FW: New Version Notification for 
>draft-liu-sfc-use-cases- 01.txt
>
>Hi Liushucheng,
>
>There is also the case where a service function is selected based on 
>user subscription. For example, steering traffic to a Parental Control 
>(PC) only for the flows belonging to users who have PC subscription. 
>One way of doing it is for the PCRF to notify the classifier about the 
>correct flows to expect prior to the arrival of these flows.
>
>Another example is when a user wants to opt-out of service functions 
>such as an Operator-mandate video optimisation platform for reasons 
>such as the user is a Gold user with QoS and requirements for high resolution video.
>
>opinion, referring to the existing 3GPP architecture as per 3GPP TS 
>23.203 where Traffic Detection Function (TDF) is a standardized element 
>residing on Gi/SGi which implements DPI (detection) functionality along 
>with enforcement and charging of the corresponding detected 
>applications. This is missing from your use case description. I think 
>such a comment was already provided in a different email thread.
>
>Best Regards,
>
>
>Alla Goldner
>Subject: [sfc] FW: New Version Notification for 
>draft-liu-sfc-use-cases- 01.txt
>
>Hi all,
>
>We've just updated our use case draft. The main change is in the 
>section of Use Case of Service Function Chain in Mobile Core Network. 
>Looking forward to your comments.
>
>Regards,
>Shucheng (Will)
>
>
>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai 
>Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie 
>Hu; Huangyong (Oliver)
>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been 
>successfully submitted by Will(Shucheng) Liu and posted to the IETF repository.
>
>#######################################################################
>####
>###################
>If you have mistakenly received this message, please notify the sender 
>by a reply e-mail and delete this message.
>Thank you.
>#######################################################################
>####
>###################
>
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 12 Feb 2014 22:29:46 +0000

Chuong,

In your example, I would expect 3 chains:

Chain_Child = { content-filter }
Chain_Qos = { qos }
Chain_Child_Qos { content-filter, qos }

The classifier, using packet fields like source-ip and dest-ip, or using some out-of-band knowledge, would assign all of the flows to/from the child subscribers to Chain_Child, all flows to/from the child_qos subscribers to Chain_Child_Qos, etc.

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 12, 2014 5:10 PM
To: [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Hi Med,

Regards,
Chuong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, 12 February 2014 8:23 PM
To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Chuong,

Cheers,
Med

---

From: "Pham, Chuong D" <[email-masked]>
Date: Thu, 13 Feb 2014 09:44:13 +1100

Ron,
Yes, your interpretation of my example is correct. Did you agree that in this example, there will not be million's of SFCs?
The classifier however will need to classify flows from million's of subscribers. It needs to use packet fields AND out-of-band knowledge. In Mobile network, the IP address is allocated dynamically therefore it cannot be used to identify users and associated services.
Regards,
Chuong

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, 13 February 2014 9:30 AM
To: Pham, Chuong D; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Chuong,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 12, 2014 5:10 PM
To: [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Hi Med,

Regards,
Chuong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, 12 February 2014 8:23 PM
To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Chuong,

Cheers,
Med

---

From: Ron Parker <[email-masked]>
Date: Wed, 12 Feb 2014 22:54:49 +0000

Chuong,

Agree that there could be huge number of flows from huge number of subscribers.   The classifier's job is to figure out how to map each and every one of them.    

I'd like to make a distinction between the abstract chain, the actual chain, and the ultimate path (I could use help on terminology, here).

For a particular subscriber, the classifier has determined, using local means, that the subscriber shall be subject, in a general manner, to {SF-A, SF-B, SF-C}.    This is my "abstract chain" using my poor terminology.    The classifier has additional policy to say that SF-A need only be invoked for UDP, SF-B for TCP and SF-C for TCP/80 (this being one of the benefits of SFC -- eliminate the need to bypass at the service function).   So, we get the following possibilities after the classifier identifies the subscriber AND looks at the flow:

UDP:  { SF-A }
TCP/80:  {SF-B, SF-C}
TCP/!80:  {SF-C}

Then, we consult the locator table and find that SF-A is located with IP-A, SF-B with IP-B1 and IP-B2, SF-C with IP-C1 and IP-C2.

When we finally reduce this to a set of paths, we get:

{ SF-A (IP-A) }
{SF-B (IP-B1), SF-C (IP-C1)}
{SF-B (IP-B2), SF-C (IP-C1)}
{SF-B (IP-B1), SF-C (IP-C2)}
{SF-B (IP-B2), SF-C (IP-C2)}
{SF-C (IP-C1)}
{SF-C (IP-C2)}

Thoughts on the above?

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 12, 2014 5:44 PM
To: Ron Parker; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Ron,

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, 13 February 2014 9:30 AM
To: Pham, Chuong D; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Chuong,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 12, 2014 5:10 PM
To: [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Hi Med,

Regards,
Chuong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, 12 February 2014 8:23 PM
To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Chuong,

Cheers,
Med

---

From: "Pham, Chuong D" <[email-masked]>
Date: Thu, 13 Feb 2014 10:07:14 +1100

Ron,
I only wanted to discuss the requirement for per-subscriber awareness in Mobile network. I guess you are taking this discussion further to aspects such as how to apply local application-awareness, how to resolve SFs to IP addresses in the classifier etc?
I am not in a best position to comment on this as I believe the front-end classifier should not have that much intelligence aka approaching the functionality of a DPI. The front-end should be simple, fast and scalable. Further application layer classification should be carried out in a SF node i.e. forking etc.
Regards,
Chuong

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, 13 February 2014 9:55 AM
To: Pham, Chuong D; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Chuong,

UDP:  { SF-A }
TCP/80:  {SF-B, SF-C}
TCP/!80:  {SF-C}

{ SF-A (IP-A) }

Thoughts on the above?

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 12, 2014 5:44 PM
To: Ron Parker; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Ron,

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, 13 February 2014 9:30 AM
To: Pham, Chuong D; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Chuong,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 12, 2014 5:10 PM
To: [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Hi Med,

Regards,
Chuong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, 12 February 2014 8:23 PM
To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Chuong,

Cheers,
Med

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Feb 2014 23:32:20 +0000

On the contrary, a device that is subscriber-aware and capable of DPI is very good to have in the role of Classifier.

----- Original Message -----
From: Pham, Chuong D [mailto:[email-masked]]
Sent: Wednesday, February 12, 2014 06:07 PM
To: Ron Parker <[email-masked]>; [email-masked] <[email-masked]>; Alla Goldner <[email-masked]>; Liushucheng (Will) <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [sfc]	FW:	New	Version	Notification	for	draft-liu-sfc-use-cases-01.txt

Ron,

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, 13 February 2014 9:55 AM
To: Pham, Chuong D; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Chuong,

UDP:  { SF-A }
TCP/80:  {SF-B, SF-C}
TCP/!80:  {SF-C}

{ SF-A (IP-A) }

Thoughts on the above?

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 12, 2014 5:44 PM
To: Ron Parker; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Ron,

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, 13 February 2014 9:30 AM
To: Pham, Chuong D; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Chuong,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 12, 2014 5:10 PM
To: [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Hi Med,

Regards,
Chuong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, 12 February 2014 8:23 PM
To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Chuong,

Cheers,
Med

---

From: "Pham, Chuong D" <[email-masked]>
Date: Thu, 13 Feb 2014 10:40:12 +1100

Ron,
Correction on my comment:
Your discussion was not necessarily about application layer intelligence as such. I think you were discussing additional local policies in the classifier (layer 4 information in your email below but I am not sure if you have layer 7 in mind as well) in addition to subscription information which all together will be used to steer traffic to the correct SFC. I don't have any issue with your suggestion.

Additionally I see three distinct "categories" of services (or more in the future). Category A is subscription-based services such as Parental Control, category B is traffic management based such as TCP optimisation or video optimisation, category C is Service Provider's mandate SF such Gi FW. How to take flows through services in these three categories is tricky and your example of using layer 4 information in steering seems to indicate to me you were thinking about category B?

Regards,
Chuong    

-----Original Message-----
From: Pham, Chuong D 
Sent: Thursday, 13 February 2014 10:07 AM
To: 'Ron Parker'; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Ron,

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, 13 February 2014 9:55 AM
To: Pham, Chuong D; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Chuong,

UDP:  { SF-A }
TCP/80:  {SF-B, SF-C}
TCP/!80:  {SF-C}

{ SF-A (IP-A) }

Thoughts on the above?

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 12, 2014 5:44 PM
To: Ron Parker; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Ron,

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, 13 February 2014 9:30 AM
To: Pham, Chuong D; [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Chuong,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 12, 2014 5:10 PM
To: [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Hi Med,

Regards,
Chuong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, 12 February 2014 8:23 PM
To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Chuong,

Cheers,
Med

---

From: Ron Parker <[email-masked]>
Date: Thu, 13 Feb 2014 00:20:46 +0000

Chuong, 

My example was based on out of band subscriber knowledge plus shallow packet inspection.   In general, steering via layer 7 heuristic DPI conclusions doesn't work because the conclusions come on packet n of the flow (I'm not talking about history-based heuristic steering mechanisms here). However, you should look at the recently posted draft-ma-sfc for a discussion of transaction oriented SFC which I feel is a very important (and complex) aspect that has not received discussion yet. 

Regarding your categorization of service functions, I think that is outside of SFC scope -- the classifier is free to incorporate any knowledge it has and apply any business logic it is capable of. 

   Ron

> On Feb 12, 2014, at 6:40 PM, "Pham, Chuong D" <[email-masked]> wrote:
> 
> Ron,

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 10:20:47 +0100

Hi Chuong,

Please see inline.

Cheers,
Med

>Envoyé : mercredi 12 février 2014 23:10
>À : BOUCADAIR Mohamed IMT/OLN; Alla Goldner; Liushucheng (Will);
>[email-masked]
>Actually the scalability issue is pertaining to the need to have
>subscriber-awareness so that subscribers are assigned to the correct
>groups.

[Med] I see; you are referring to the classification rules not the set of SFC themselves. 

 For example, subscriber-A belongs to Parental Control group,
>subscriber-B belongs to QoS-enabled group, subscriber-C belongs to a group
>which has both Parental Control and QoS-enabled.

[Med] This is what I have in mind too: limited number of SFCs but classifications rules can be triggered by per-subscriber info. That's really different that allowing customized set of SFC on a per-subscriber basis. This subtlety should be recorded in one of existing drafts.

>
>The number of SFCs will be the same (permutation of service functions are
>the same),

[Med] Agree.

 however the need to have visibility of subscriber's IP address
>(dynamically assigned in Mobile network), subscriber identity i.e. the
>phone number and the services that the subscriber have subscribed to is
>where the scalability concern is IMHO.

[Med] Fair enough.

>
>So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-6
>is still valid and my input adds the ability to recognise flows from
>individual mobile users and assign them to a correct group of subscribers
>who share a same SFC.

[Med] Feel free to propose text to the requirement draft. 

>As for the per-subscriber SFC, the scalability discussion is already
>recorded here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-
>02#section-6. Beside considerations on scalability, what is really helpful
>is to identify *** concrete *** use cases that would require such per-
>subscriber SFCs (that would lead to instantiating millions of SFCs in a
>domain): i.e., are there real business motivations to configure customized
>service chains for each subscriber? Wouldn't be realistic to assume chains
>for groups of subscribers?
>
>Cheers,
>Med
>

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 14:16:07 +0100

Dear Alla,

The new version cites now TS 23.203. You can check the diff available at: 

http://www.ietf.org/rfcdiff?url2=draft-liu-sfc-use-cases-02 

Cheers,
Med

>De : sfc [mailto:[email-masked]] De la part de Alla Goldner
>Envoyé : mardi 11 février 2014 11:53
>À : Liushucheng (Will); [email-masked]

---

From: Alla Goldner <[email-masked]>
Date: Thu, 13 Feb 2014 13:58:35 +0000

Dear Mohamed,

Thanks a lot for your kind consideration of my comment!

I still have 3 comments in this regard: 

1. It would be useful to mention within the newly introduced text that TDF resides on Gi/SGi interface
2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network Architecture in order to outline it correctly (Figure 2 and Figure 4); also correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture
3. It makes sense to reference latest available 3GPP TS 23.203 version (R12)  - December 2013

Best regards and thanks in advance,

Alla Goldner

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 3:16 PM
To: Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Alla,

Cheers,
Med

>Envoyé : mardi 11 février 2014 11:53 À : Liushucheng (Will); 
>[email-masked] Objet : Re: [sfc] FW: New Version Notification for 
>Director of Mobile Technologies and Standards Allot Communications Tel 
>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 
>[email-masked] www.allot.com
>
>
>
>

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 15:21:57 +0100

Re-,

Please see inline.

Cheers,
Med

>De : Alla Goldner [mailto:[email-masked]]
>Envoyé : jeudi 13 février 2014 14:59
>À : BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); [email-masked]
>Objet : RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-
>01.txt
>
>Dear Mohamed,
>
[Med] All the functions listed in this section resides in the Gi interface. The TDF text is just after a paragraph starting with "Gi Interface ...". We can repeat it also for TDF but we thought it is redundant. 

>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network
>Architecture in order to outline it correctly (Figure 2 and Figure 4);
[Med] As you know there are DPI boxes in operational mobile networks that are not compliant with 3GPP specifications. Instead of updating existing figures, adding a NEW figure with TDF can be considered. 

 also
>correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture
[Med] Will do. Thanks.

>3. It makes sense to reference latest available 3GPP TS 23.203 version
[Med] OK.

>>##########################################################################
>#
>>###################
>>If you have mistakenly received this message, please notify the sender by
>a
>>reply e-mail and delete this message.
>>Thank you.
>>##########################################################################
>#
>>###################
>>

---

From: Alla Goldner <[email-masked]>
Date: Thu, 13 Feb 2014 14:42:57 +0000

Dear Mohamed,

Thanks a lot for your kind response.

I don't think I agree with such a view. As long as we present standardized Mobile Network (defined by a different SDO i.e. 3GPP and not within a scope of IETF) it is very important to reference the existing well-defined Network Elements. DPI functionality in mobile network is fulfilled by the TDF.

Best regards,

Alla Goldner

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 4:22 PM
To: Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Re-,

Please see inline.

Cheers,
Med

>De : Alla Goldner [mailto:[email-masked]] Envoyé : jeudi 13 février 
>2014 14:59 À : BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); 
>[email-masked] Objet : RE: [sfc] FW: New Version Notification for 

 also
[Med] Will do. Thanks.

[Med] OK.

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 15:50:48 +0100

Re-,

I hear your argument, but the point is we cannot ignore existing deployments that are not relying on such functional element. We should reflect both situations IMHO. 

Cheers,
Med

>Envoyé : jeudi 13 février 2014 15:43
>[Med] As you know there are DPI boxes in operational mobile networks that
>are not compliant with 3GPP specifications. Instead of updating existing
>figures, adding a NEW figure with TDF can be considered.
>
>
>I don't think I agree with such a view. As long as we present standardized
>Mobile Network (defined by a different SDO i.e. 3GPP and not within a scope
>of IETF) it is very important to reference the existing well-defined
>Network Elements. DPI functionality in mobile network is fulfilled by the
>TDF.
>
>Best regards,
>
>
>Alla Goldner
>[Med] All the functions listed in this section resides in the Gi interface.
>The TDF text is just after a paragraph starting with "Gi Interface ...". We
>can repeat it also for TDF but we thought it is redundant.
>
>[Med] As you know there are DPI boxes in operational mobile networks that
>are not compliant with 3GPP specifications. Instead of updating existing
>figures, adding a NEW figure with TDF can be considered.
>
> also
>Leymann;
>successfully

---

From: Alla Goldner <[email-masked]>
Date: Thu, 13 Feb 2014 14:57:56 +0000

Dear Mohamed,

Before TDF was part of 3GPP standard (R11), it was indeed the case. However, starting from R11, for mobile networks, DPI equipment is nothing else but "TDF". 

Best regards,

Alla Goldner

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 4:51 PM
To: Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Re-,

Cheers,
Med

>2014 15:43 À : BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); 
>[Med] As you know there are DPI boxes in operational mobile networks 
>that are not compliant with 3GPP specifications. Instead of updating 
>existing figures, adding a NEW figure with TDF can be considered.
>
>
>I don't think I agree with such a view. As long as we present 
>standardized Mobile Network (defined by a different SDO i.e. 3GPP and 
>not within a scope of IETF) it is very important to reference the 
>existing well-defined Network Elements. DPI functionality in mobile 
>network is fulfilled by the TDF.
>
>Best regards,
>
>
>Alla Goldner

---

From: Ron Parker <[email-masked]>
Date: Thu, 13 Feb 2014 15:06:07 +0000

In a generic sense, yes, all DPI's are "Traffic Detection Functions".   But, I think that TDF in the 3gpp sense implies support of the DIAMETER Sd interface, too.,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Thursday, February 13, 2014 9:58 AM
To: [email-masked]; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Mohamed,

Best regards,

Alla Goldner

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 4:51 PM
To: Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Re-,

Cheers,
Med

---

From: Alla Goldner <[email-masked]>
Date: Thu, 13 Feb 2014 15:35:45 +0000

Dear Ron, all,

Yes, the standardized means to define TDF (DPI) in mobile network within 3GPP specifications is to define Sd interface between the TDF and the PCRF.

Best Regards,

Alla Goldner

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 5:06 PM
To: Alla Goldner; [email-masked]; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Thursday, February 13, 2014 9:58 AM
To: [email-masked]; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Dear Mohamed,

Best regards,

Alla Goldner

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 4:51 PM
To: Alla Goldner; Liushucheng (Will); [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Re-,

Cheers,
Med

>The TDF text is just after a paragraph starting with "Gi Interface 
>...". We can repeat it also for TDF but we thought it is redundant.
>
>>>23.203 where Traffic Detection Function (TDF) is a standardized 
>>>element residing on Gi/SGi which implements DPI (detection) 
>>>functionality along with enforcement and charging of the 
>>>corresponding detected applications. This is missing from your use 
>>>case description. I think such a comment was already provided in a different email thread.
>>>
>>>Best Regards,
>>>
>>>
>>>Alla Goldner
>>>section
>>of
>>>#####################################################################
>>>####
>#
>>#
>>>###################
>>>#####################################################################
>>>####
>#
>>#
>>>###################
>>>
>>by

---

From: "Pham, Chuong D" <[email-masked]>
Date: Fri, 14 Feb 2014 16:34:32 +1100

I support Med's opinion that we should not exclude all existing methods of classifying flows which include the TDF, DPI, LB, Openflow switch, Grid computer, PGw etc.

Due to constraint obviously we cannot include all of these candidate methods in the draft but there is no reason to explicitly remove any of them in the draft which have been chosen to be included as examples of typical current deployments.

Regards,
Chuong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, 14 February 2014 1:51 AM
To: Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Re-,

Cheers,
Med

---

From: Ron Parker <[email-masked]>
Date: Fri, 14 Feb 2014 13:50:19 +0000

Why do we need to pin down the location of the classifier?   The classifier is a logical function that may use out-of-band data, local policy, delivered policy, local state, and the packets, themselves, to intelligently steer packets through a sequence of midboxes.   By keeping the definition high level, implementors can innovate on useful and practical compositions of functions.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Friday, February 14, 2014 12:35 AM
To: [email-masked]; Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Regards,
Chuong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, 14 February 2014 1:51 AM
To: Alla Goldner; Liushucheng (Will); [email-masked]
Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt

Re-,

Cheers,
Med

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 14 Feb 2014 14:01:08 +0000

I completely agree Ron.

On 2/14/14, 8:50 AM, "Ron Parker" <[email-masked]> wrote:

>Why do we need to pin down the location of the classifier?   The
>classifier is a logical function that may use out-of-band data, local
>policy, delivered policy, local state, and the packets, themselves, to
>intelligently steer packets through a sequence of midboxes.   By keeping
>the definition high level, implementors can innovate on useful and
>practical compositions of functions.
>
>   Ron
>
>
>I support Med's opinion that we should not exclude all existing methods
>of classifying flows which include the TDF, DPI, LB, Openflow switch,
>Grid computer, PGw etc.
>
>Due to constraint obviously we cannot include all of these candidate
>methods in the draft but there is no reason to explicitly remove any of
>them in the draft which have been chosen to be included as examples of
>typical current deployments.
>
>Regards,
>Chuong
>
>
>
>
>
>I hear your argument, but the point is we cannot ignore existing
>deployments that are not relying on such functional element. We should
>reflect both situations IMHO.
>
>Cheers,
>Med
>
>>>>Status:        
>>>>https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/
>>>>Diff:          
>>>>http://www.ietf.org/rfcdiff?url2=draft-liu-sfc-use-cases-
>>>01
>>>>
>>>>Abstract: