Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

From: Dave Dolson <[email-masked]>
Date: Tue, 4 Feb 2014 19:22:33 +0000

Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement of mobility architecture, it neglects to show the role of the Traffic Detection Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12).

I don't want to argue with the use cases, just the implied network architecture.

In all of the network diagrams and examples, it should be understood that the P-GW is not the only location from which a policy-based service chain could be initiated; the standard TDF function can also initiate service chains selected by policy and traffic type.

Section 2.1 should show an optional TDF element between the P-GW and the (S)Gi-LAN.

A TDF communicates with a PCRF using the Sd interface, from which it receives Application Detection and Control (ADC) rules, similar to the rules deployed to the P-GW via the Gx interface.

Aside from the APN classification scheme mentioned in section 2.3 of the draft, ADC rules can cause decisions based on application type (not just based on APN or UDP/TCP port classification).

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

I wanted to raise your attention to the below quoted draft, as it wasn't 
posted to the SFC list.

The draft outlines very well the use cases in mobile networks.

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

         Title           : Service Function Chaining Use Cases in Mobile 
Networks
         Authors         : Walter Haeffner
                           Jeffrey Napper
	Filename        : draft-haeffner-sfc-use-case-mobility-00.txt
	Pages           : 17
	Date            : 2014-01-28

Abstract:
    This document provides some exemplary use cases for service function
    chaining in mobile service provider networks.  The objective of this
    draft is not to cover all conceivable service chains in detail.
    Rather, the intention is to localize and explain the application
    domain of service chaining within mobile networks as far as it is
    required to complement the problem statement and framework statements
    of the working group.

    Service function chains typically reside in a LAN segment which links
    the mobile access network to the actual application platforms located
    in the carrier's datacenters or somewhere else in the Internet.
    Service function chains ensure a fair distribution of network
    resources according to agreed service policies, enhance the
    performance of service delivery, take care of security and privacy or
    support application and business support platforms.  General
    considerations and specific use cases are presented in this document
    to demonstrate the different technical requirements of these goals
    for service function chaining in mobile service provider networks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Thu, 6 Feb 2014 01:21:08 +0000

Hi Dave,
Thanks for your comment. We are going to include a Rel.11 TDF  paragraph in -01. Possibly we will consider 2 sections: most simple case (with APN), actual most advanced case (with TDF). 
Regards,
Walter

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

I wanted to raise your attention to the below quoted draft, as it wasn't posted to the SFC list.

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Abstract:

---

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

Hi all,

Would you please consider my thoughts below in the Draft.

1-The TDF is an inline function which inspects user payload at application layer i.e. inspect HTTP headers. With the trend in adoption of encryption (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the capability of the TDF to be able to inspect at application may be diminished.

2- The use of a DPI function in place of the TDF which may or may have an interface to the PCRF. This DPI for many traffic cases, do not have to be deployed in line with customer traffic. It can be deployed in an out-of-path fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information for traffic steering/service chaining actions. The only use case where the DPI is required to be in line is when it acts as an enforcement Service Function however in this mode, it needs to be treated as a Service Function, not a traffic steering device.

3- Section 6.2 current has this paragraph:
"...Service chain behavior and output should additionally depend on
   actual network conditions.  For example, the selection of a video
   compression format could dependent on the actual load of the mobile
   network segment a mobile user is attached to..."

I agreed with paragraph and therefore we could include something to the effect of an "actionable intelligence" function which receives inputs from sources such as the network and the traffic, derive traffic steering decisions and communicate with the service chaining function.

Examples: 
-Receive from the Mobile network the list of user's ip addresses who are at the present located in the congested cells so that new video sessions are steered to a video optimisation platform.
- Inspect network traffic (in out-of-path mode) and derive a heat map of problematic TCP flows which may be benefited from TCP Optimiser and steer traffic to this device.
- Inspect network traffic and derive a heat map of popular content remotely located and steer traffic to a local Web Cache so that content is made available locally for the current and future users.

Regards,
Chuong

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]] 
Sent: Thursday, 6 February 2014 12:21 PM
To: Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Dave,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Chris Frederick <[email-masked]>
Date: Thu, 6 Feb 2014 15:51:06 +0000

Hi Chuong,
As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps not ideal for traffic steering/service chaining; devices that receive only an offline copy of a flow cannot themselves redirect/steer that flow. So, I wouldn't necessarily agree that the only case where the DPI is required to be inline is when it acts as a service function; there is also the case where the DPI actually determines the chain + steers the flow through the SFC, bidirectionally. I'd further argue that this is actually ideal as it obviates some unnecessary signaling overhead.
Of course, it's possible to deploy offline as you note, with the implicit assumption that the offline DPI would then be signaling back to inline devices (either directly or circuitously through a PCRF), perhaps with inherent race conditions, etc. 
Thanks,
/c

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 05, 2014 9:24 PM
To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Examples: 

Regards,
Chuong

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]] 
Sent: Thursday, 6 February 2014 12:21 PM
To: Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Dave,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

---

From: "Pham, Chuong D" <[email-masked]>
Date: Fri, 7 Feb 2014 10:10:48 +1100

Hi Chris,

It depends on how you look at the issue.

In this comment " there is also the case where the DPI actually determines the chain + steers the flow through the SFC, bidirectionally.", there are two separate functions, "determines" and "steers". The determination function could be inline or offline. The steer function needs to be inline but this function could be provided for by the SFC, not necessarily the DPI. 

I agree that we should generalise and include both offline and inline modes as equally valid (as in ITU-T Rec. Y.2770 (11/2012).

There are cases where offline mode is beneficial. For example, to determine a heat map (list of IP addresses) of popular but problematic video servers, only one DPI in a major region (can combine with sampling technique to reduce load on this DPI) may be adequate, assumed that as these videos are wanted by users in other regions as well as they are popular. Another advantage is when the DPI is offline (for the right use cases), the risk to customer traffic is significantly reduced.

Regards,
Chuong
-----Original Message-----
From: Chris Frederick [mailto:[email-masked]] 
Sent: Friday, 7 February 2014 2:51 AM
To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chuong,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 05, 2014 9:24 PM
To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Examples: 

Regards,
Chuong

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]] 
Sent: Thursday, 6 February 2014 12:21 PM
To: Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Dave,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

---

From: Ron Parker <[email-masked]>
Date: Fri, 7 Feb 2014 01:47:18 +0000

The use case of the offline (mirrored feed) DPI interacting with the SFC is an interesting one.    Wrt the inline DPI case, since we've said that any service function can reclassify, at first glance it isn't any different than any other service function.

Putting the 2 cases together, do we want to portray the flow recognition entity separately from the per-flow decision making entity?     This is somewhat analogous to the 3gpp PCEF/PCRF split, although in practice, there are severe scaling constraints to actually engage the PCRF on a per-flow basis.   Of course, choosing to portray these as separate entities means that a protocol needs to be defined between them.   By assuming that the flow recognition entity is also the decision making entity (i.e., the policy decision point in some of the drafts), the complexity of the problem is reduced.

Thoughts?

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Thursday, February 06, 2014 6:11 PM
To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chris,

Regards,
Chuong
-----Original Message-----
From: Chris Frederick [mailto:[email-masked]] 
Sent: Friday, 7 February 2014 2:51 AM
To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chuong,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 05, 2014 9:24 PM
To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Examples: 

Regards,
Chuong

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]] 
Sent: Thursday, 6 February 2014 12:21 PM
To: Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Dave,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

---

From: Chris Frederick <[email-masked]>
Date: Fri, 7 Feb 2014 16:55:32 +0000

I agree that PCRF signaling on a per-flow basis in this context seems impractical; also that consolidating the flow recognition + decision-making entity in a single node reduces the complexity (that's how we do our SFC implementation).
Fwiw, I have a supplemental comment on the idea of service function reclassification, in general.
I know the working group has been contemplating this for some time. "Per-Service Reclassification" is one of the items in the Problem Statement, but the problem seems to be framed more in terms of the resource overhead incurred by the classification + sharing of metadata between service functions in this context (which are valid concerns). 
However, imo, there is also an inherent assumption of 'flow stickiness' that is important; therefore, service function reclassification should be the exception rather than the rule, I would think. 
It's conceivable that permitting service functions to play a role in reclassification might be desirable, in certain cases, but once a service chain is selected, it should generally not be changed, because modification of the flow path by a service function within the chain could result in a 'breaking' of the chain or flow. 
If there is not bidirectional symmetry in the flow and service function elements in the chain can make routing decisions, this is a recipe for problems. 
Each service function in the chain should be agnostic about its upstream and downstream nodes. Allowing service functions within a chain to second-guess the ordering can break bidirectional flows. 
I would think that any service function re-classification must necessarily be limited in scope viz the output chains it can select; it shouldn't be possible for a downstream service function to be bypassed. Therefore, any re-classification would need to be constrained to sub-chains that return to the original chain, I would think. Thx,
/c

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, February 06, 2014 8:47 PM
To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Thoughts?

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Thursday, February 06, 2014 6:11 PM
To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chris,

Regards,
Chuong
-----Original Message-----
From: Chris Frederick [mailto:[email-masked]] 
Sent: Friday, 7 February 2014 2:51 AM
To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chuong,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 05, 2014 9:24 PM
To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Examples: 

Regards,
Chuong

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]] 
Sent: Thursday, 6 February 2014 12:21 PM
To: Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Dave,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

---

From: Ron Parker <[email-masked]>
Date: Fri, 7 Feb 2014 17:21:14 +0000

Hi, Chris.

I think that the service function reclassification is more to achieve branching within the overall service function graph, but I do agree that it will in practice be the exception rather than the rule in many typical deployments.

You raise the issue of bidirectional chains and I think that will be the rule rather than the exception in many typical deployments.   Bidirectional, perhaps, could also be addressed more generally as directionally correlated flows.   That is, for a given "forward" chain X, there exists a "reverse" chain Y that is not necessarily an exact inverse sequence of X.

I feel the group should give much attention to the important topic of how to achieve (but not require) directionally correlated chains.

    Ron

-----Original Message-----
From: Chris Frederick [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 11:56 AM
To: Ron Parker; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

I would think that any service function re-classification must necessarily be limited in scope viz the output chains it can select; it shouldn't be possible for a downstream service function to be bypassed. Therefore, any re-classification would need to be constrained to sub-chains that return to the original chain, I would think. Thx, /c

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, February 06, 2014 8:47 PM
To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Thoughts?

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Thursday, February 06, 2014 6:11 PM
To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chris,

Regards,
Chuong
-----Original Message-----
From: Chris Frederick [mailto:[email-masked]]
Sent: Friday, 7 February 2014 2:51 AM
To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chuong,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 05, 2014 9:24 PM
To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Examples: 

Regards,
Chuong

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]]
Sent: Thursday, 6 February 2014 12:21 PM
To: Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Dave,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 7 Feb 2014 17:31:10 +0000

Chris,

If you take the stance that a reclassification of a flow along an original
chain (that forces said flow away from the original chain) forwards the
flow into a *new* chain, then in the reverse direction of the *new* chain
there may or may not be a need for symmetry (for either the *new* or
*original* chain). In the case where symmetry is required for the
*original* chain then presumably it is true that a correlation between the
*original* and the *new* chains is necessary and there are several ways in
which that could be achieved.

On 2/7/14, 11:55 AM, "Chris Frederick" <[email-masked]> wrote:

>I agree that PCRF signaling on a per-flow basis in this context seems
>impractical; also that consolidating the flow recognition +
>decision-making entity in a single node reduces the complexity (that's
>how we do our SFC implementation).
>I know the working group has been contemplating this for some time.
>"Per-Service Reclassification" is one of the items in the Problem
>Statement, but the problem seems to be framed more in terms of the
>resource overhead incurred by the classification + sharing of metadata
>between service functions in this context (which are valid concerns).
>However, imo, there is also an inherent assumption of 'flow stickiness'
>that is important; therefore, service function reclassification should be
>the exception rather than the rule, I would think.
>It's conceivable that permitting service functions to play a role in
>reclassification might be desirable, in certain cases, but once a service
>chain is selected, it should generally not be changed, because
>modification of the flow path by a service function within the chain
>could result in a 'breaking' of the chain or flow.
>If there is not bidirectional symmetry in the flow and service function
>elements in the chain can make routing decisions, this is a recipe for
>problems. 
>Each service function in the chain should be agnostic about its upstream
>and downstream nodes. Allowing service functions within a chain to
>second-guess the ordering can break bidirectional flows.
>I would think that any service function re-classification must
>necessarily be limited in scope viz the output chains it can select; it
>shouldn't be possible for a downstream service function to be bypassed.
>Therefore, any re-classification would need to be constrained to
>sub-chains that return to the original chain, I would think. Thx,
>/c
>
>
>To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave
>Dolson; Martin Stiemerling;
>[email-masked]; [email-masked]
>Subject: RE: [sfc] Fwd: I-D Action:
>draft-haeffner-sfc-use-case-mobility-00.txt
>
>The use case of the offline (mirrored feed) DPI interacting with the SFC
>is an interesting one.    Wrt the inline DPI case, since we've said that
>any service function can reclassify, at first glance it isn't any
>different than any other service function.
>
>Putting the 2 cases together, do we want to portray the flow recognition
>entity separately from the per-flow decision making entity?     This is
>somewhat analogous to the 3gpp PCEF/PCRF split, although in practice,
>there are severe scaling constraints to actually engage the PCRF on a
>per-flow basis.   Of course, choosing to portray these as separate
>entities means that a protocol needs to be defined between them.   By
>assuming that the flow recognition entity is also the decision making
>entity (i.e., the policy decision point in some of the drafts), the
>complexity of the problem is reduced.
>
>Thoughts?
>
>   Ron
>
>
>
>To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin
>Stiemerling; [email-masked];
>[email-masked]
>Subject: Re: [sfc] Fwd: I-D Action:
>draft-haeffner-sfc-use-case-mobility-00.txt
>
>Hi Chris,
>
>In this comment " there is also the case where the DPI actually
>determines the chain + steers the flow through the SFC,
>bidirectionally.", there are two separate functions, "determines" and
>"steers". The determination function could be inline or offline. The
>steer function needs to be inline but this function could be provided for
>by the SFC, not necessarily the DPI.
>
>I agree that we should generalise and include both offline and inline
>modes as equally valid (as in ITU-T Rec. Y.2770 (11/2012).
>
>There are cases where offline mode is beneficial. For example, to
>determine a heat map (list of IP addresses) of popular but problematic
>video servers, only one DPI in a major region (can combine with sampling
>technique to reduce load on this DPI) may be adequate, assumed that as
>these videos are wanted by users in other regions as well as they are
>popular. Another advantage is when the DPI is offline (for the right use
>cases), the risk to customer traffic is significantly reduced.
>
>Regards,
>Chuong
>To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin
>Stiemerling; [email-masked];
>[email-masked]
>Subject: Re: [sfc] Fwd: I-D Action:
>draft-haeffner-sfc-use-case-mobility-00.txt
>
>Hi Chuong,
>As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps
>not ideal for traffic steering/service chaining; devices that receive
>only an offline copy of a flow cannot themselves redirect/steer that
>flow. So, I wouldn't necessarily agree that the only case where the DPI
>is required to be inline is when it acts as a service function; there is
>also the case where the DPI actually determines the chain + steers the
>flow through the SFC, bidirectionally. I'd further argue that this is
>actually ideal as it obviates some unnecessary signaling overhead.
>Of course, it's possible to deploy offline as you note, with the implicit
>assumption that the offline DPI would then be signaling back to inline
>devices (either directly or circuitously through a PCRF), perhaps with
>inherent race conditions, etc.
>Thanks,
>/c
>
>To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;
>[email-masked]; [email-masked]
>Subject: Re: [sfc] Fwd: I-D Action:
>draft-haeffner-sfc-use-case-mobility-00.txt
>
>Hi all,
>
>1-The TDF is an inline function which inspects user payload at
>application layer i.e. inspect HTTP headers. With the trend in adoption
>of encryption (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing
>30% etc.), the capability of the TDF to be able to inspect at application
>may be diminished.
>
>2- The use of a DPI function in place of the TDF which may or may have an
>interface to the PCRF. This DPI for many traffic cases, do not have to be
>deployed in line with customer traffic. It can be deployed in an
>out-of-path fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent
>information for traffic steering/service chaining actions. The only use
>case where the DPI is required to be in line is when it acts as an
>enforcement Service Function however in this mode, it needs to be treated
>as a Service Function, not a traffic steering device.
>
>I agreed with paragraph and therefore we could include something to the
>effect of an "actionable intelligence" function which receives inputs
>from sources such as the network and the traffic, derive traffic steering
>decisions and communicate with the service chaining function.
>
>Examples: 
>-Receive from the Mobile network the list of user's ip addresses who are
>at the present located in the congested cells so that new video sessions
>are steered to a video optimisation platform.
>- Inspect network traffic (in out-of-path mode) and derive a heat map of
>problematic TCP flows which may be benefited from TCP Optimiser and steer
>traffic to this device.
>- Inspect network traffic and derive a heat map of popular content
>remotely located and steer traffic to a local Web Cache so that content
>is made available locally for the current and future users.
>
>Regards,
>Chuong
>
> 
>
>To: Dave Dolson; Martin Stiemerling;
>[email-masked]; [email-masked]
>Subject: Re: [sfc] Fwd: I-D Action:
>draft-haeffner-sfc-use-case-mobility-00.txt
>
>Hi Dave,
>Thanks for your comment. We are going to include a Rel.11 TDF  paragraph
>in -01. Possibly we will consider 2 sections: most simple case (with
>APN), actual most advanced case (with TDF).
>Regards,
>Walter
>
>An: Martin Stiemerling;
>[email-masked]; [email-masked]
>Betreff: Re: [sfc] Fwd: I-D Action:
>draft-haeffner-sfc-use-case-mobility-00.txt
>
>Although draft-haeffner-sfc-use-case-mobility-00 describes one
>arrangement of mobility architecture, it neglects to show the role of the
>Traffic Detection Function (TDF), also described in the cited 3GPP TS
>23.203 (Version 12).
>
>In all of the network diagrams and examples, it should be understood that
>the P-GW is not the only location from which a policy-based service chain
>could be initiated; the standard TDF function can also initiate service
>chains selected by policy and traffic type.
>
>A TDF communicates with a PCRF using the Sd interface, from which it
>receives Application Detection and Control (ADC) rules, similar to the
>rules deployed to the P-GW via the Gx interface.
>
>Aside from the APN classification scheme mentioned in section 2.3 of the
>draft, ADC rules can cause decisions based on application type (not just
>based on APN or UDP/TCP port classification).
>
>
>
>
>Subject: [sfc] Fwd: I-D Action:
>draft-haeffner-sfc-use-case-mobility-00.txt
>
>Hi all,
>
>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.
>
>Internet-Draft directories: http://www.ietf.org/shadow.html or
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>

---

From: Chris Frederick <[email-masked]>
Date: Fri, 7 Feb 2014 18:06:59 +0000

Jim,
I'm not sure I understand.
Are the "several ways" to share metadata + correlate between chains in this way elucidated somewhere? 
I'm thinking of v simple, v common, real-world deployments (like say, a commercial network video streaming case w/ autonomous service funtions for video optimization/compression + caching) wherein those service functions would have reclassification abilities. Thx,

Chris Frederick
Director, Technology Partnerships
Sandvine Incorporated
www.sandvine.com
Mobile: +1.519.500.5016 

----- Original Message -----
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Friday, February 07, 2014 12:31 PM
To: Chris Frederick; Ron Parker <[email-masked]>; Pham, Chuong D <[email-masked]>; Haeffner, Walter, Vodafone DE <[email-masked]>; Dave Dolson; Martin Stiemerling <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: Jeffrey Napper (jenapper) <[email-masked]>
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Chris,

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 7 Feb 2014 19:34:32 +0000

Hi Chris,

Metadata is one option (using whatever service encapsulation we as a WG define) but it is also possible through direct control plane interactions (as yet to be determined).

Sent from my iPhone

> On Feb 7, 2014, at 1:07 PM, "Chris Frederick" <[email-masked]> wrote:
> 
> Jim,

---

From: Thomas Narten <[email-masked]>
Date: Fri, 07 Feb 2014 14:52:46 -0500

One thing that might help is if someone would produce a concrete
example where they think reclassification is needed.

And does it happen a lot for a flow? (I assume not.) Once at the very
beginning? Anytime while packets are flowing?

A couple of concrete example might help. We've had this discussion a
number of times, but its mostly been in the abstract, which makes it
hard to understand how open-ended the requirements for
reclassification are.

Thomas

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 7 Feb 2014 21:49:35 +0000

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

    Ron

[Linda] For flows that need Firewall on both directions, the outgoing direction traffic might go through Firewall Instance #1, and the reverse direction traffic go through Firewall Instance #3. If the Firewall instance #1 and #3 are attached to different Service Function Forwarder nodes, is it considered bi-directional service chain? There are way too many permutations. 
Maybe SFC WG should let external entity (controller or scheduler) to correlate the chains at different directions. 

My two cents. 

Linda

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, February 06, 2014 8:47 PM
To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Thoughts?

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Thursday, February 06, 2014 6:11 PM
To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chris,

Regards,
Chuong
-----Original Message-----
From: Chris Frederick [mailto:[email-masked]]
Sent: Friday, 7 February 2014 2:51 AM
To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chuong,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 05, 2014 9:24 PM
To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Examples: 

Regards,
Chuong

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]]
Sent: Thursday, 6 February 2014 12:21 PM
To: Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Dave,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 7 Feb 2014 22:14:32 +0000

Walter, et al, 

While it is interesting to show all the components of 3GPP for GiLAN, but I don't think it is necessary to have all of them in the SFC use case draft. 

For example, on your Section 2.3 ("The Most common classification scheme"), it is very confusing to have the Table 1 & Table 2 listing "User name & Password". Does it mean that the "User Name & Password" have to associated with data packets? Or to be detected by the Classification nodes? 

Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Wednesday, February 05, 2014 7:21 PM
To: Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Dave,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

---

From: Ron Parker <[email-masked]>
Date: Fri, 7 Feb 2014 22:15:19 +0000

Linda,

For firewall, due to stateful processing, it would be required that both directions of the flow be processed by the same instance.  In practice, all flows to or from the same subscriber would typically need to be handled at the same instance.    An acceptable requirement to achieve this might be that both directions of the flow are processed by the same SFC classifier. 

    Ron

> On Feb 7, 2014, at 4:49 PM, "Linda Dunbar" <[email-masked]> wrote:
> 
> 
>

---

From: Dave Dolson <[email-masked]>
Date: Fri, 7 Feb 2014 23:02:00 +0000

It also seems to me that there are many use cases in which both ends of a service chain (one instance) must be terminated by the same Classifier.

Consistent selection of chains is one reason. E.g., picking the same firewall in the example below. In fact, picking a chain that is the exact inverse with respect to all Service Functions within it.

In other cases, the Classifier has some function it needs to do after traffic exits the chain. E.g., accounting.

And in other cases, the Classifier needs to return the traffic to the context it was extracted from. E.g., return the traffic to the correct VLAN or VPN.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 5:15 PM
To: Linda Dunbar
Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]; Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Linda,

    Ron

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 7 Feb 2014 23:19:45 +0000

That are all valid cases. In addition, there are stateless firewalls (many cases if not the majority).

IMHO, the directional correlation of service chain should be out of the scope of SFC WG. Let an external controller/scheduler/etc determine the chains in each direction and the policies for the chain. 

Linda

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 5:15 PM
To: Linda Dunbar
Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]; Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Linda,

    Ron

---

From: Ron Parker <[email-masked]>
Date: Fri, 7 Feb 2014 23:51:54 +0000

Linda, to the extent that some classifier implementations could be based on locally provisioned policy, it is very much within scope how chains can be correlated.   This may impact the yang management model, too. 

   Ron

> On Feb 7, 2014, at 6:20 PM, "Linda Dunbar" <[email-masked]> wrote:
>

---

From: "Pham, Chuong D" <[email-masked]>
Date: Sat, 8 Feb 2014 12:54:32 +1100

I think direction correlation aka traffic symmetry is important. I have not seen many stateless firewall. Both directions of the flows need to traverse the same firewall. Even with the most basic firewall, TCP flows and UDP pseudo flows states are maintained in the firewall. The so called stateless firewall is a special configuration to turn off the need to enforce correct states, which in a way, defeats the purpose of the firewall. The NAT function is another service function which needs to see traffic symmetry. There are service functions such as Parental Control which may not mandate returned traffic to go through it but there are also types of PC which require traffic symmetry when inspection of the returned traffic is required.

I personally think symmetry should be the default case with a configurable option to turn it off. This will require state replication between multiple classifiers in a "cluster" of classifiers.

Regards,
Chuong

From: Linda Dunbar [mailto:[email-masked]]
Sent: Saturday, 8 February 2014 10:20 AM
To: Dave Dolson; Ron Parker
Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Martin Stiemerling; [email-masked]; [email-masked]; Jeffrey Napper (jenapper) ([email-masked])
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Linda

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Friday, February 07, 2014 5:15 PM
To: Linda Dunbar
Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]; Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Linda,

    Ron

---

From: Sumandra Majee <[email-masked]>
Date: Sat, 8 Feb 2014 01:51:46 +0000

Most  current implementation of load balancer, firewall or steering devices do require both directions of a given flow be processed at the same instance. However this is forced at network level, making sure that default route points back to the same device or by nating. 

However it has performance penalty and modern data center has been designed to bypass processing device on the return path.  

I think this WG has to consider both scenarios but it should not be mandating one or other. 

Sideband channel e.g. ICAP is another consideration. Interestingly ICAP does allow a steering device to pick a portion of a flow (think http transaction) and select service endpoint for that portion. In this case the the flow path is a mix of both.

Sumandra
________________________________________
From: sfc [[email-masked]] on behalf of Ron Parker [[email-masked]]
Sent: Friday, February 07, 2014 3:51 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]; Chris Frederick; Martin Stiemerling; Haeffner, Walter, Vodafone DE; Jeffrey Napper (jenapper) ([email-masked]); Pham, Chuong D; Dave Dolson
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

   Ron

---

From: "Pham, Chuong D" <[email-masked]>
Date: Sat, 8 Feb 2014 13:06:47 +1100

The option to have separation of flow recognition i.e. an out-of-path/inline DPI/TDF etc. from flow decision i.e. an OpenFlow controller and flow steering i.e. an OpenFlow switch or a normal switch with API or a DPI, allows for flexibility i.e. combining multiple flow recognition mechanisms to input into a common flow controller. I think the DPI is not a typical example of what a SFC should look like. It is more of a stand-alone service function which capability to steer traffic. With encryption, a lot of traffic cannot be inspected at the application layer and this would severely affect how the DPI works which in turn, will affect how the "black box" perform the function of a all-in-one-box SFC. If the two functions are separate then we could use different methods for flow recognition while retaining the flow steering mechanism intact, or via versa.

Regards,
Chuong

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, February 06, 2014 8:47 PM
To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Thoughts?

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Thursday, February 06, 2014 6:11 PM
To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chris,

Regards,
Chuong
-----Original Message-----
From: Chris Frederick [mailto:[email-masked]]
Sent: Friday, 7 February 2014 2:51 AM
To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chuong,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 05, 2014 9:24 PM
To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Examples:

Regards,
Chuong

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]]
Sent: Thursday, 6 February 2014 12:21 PM
To: Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Dave,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

---

From: "Pham, Chuong D" <[email-masked]>
Date: Sat, 8 Feb 2014 13:59:21 +1100

Hi Ron, 

In my comment I just wanted to point out that there is an option to deploy an actionable intelligence box in an off-line mode (it is a DPI in this discussion), in respond to Chris's suggestion about an TDF function to be placed in-line to recognise application flows (the TDF is simply a DPI with Sd interface with the PCRF). My point was that to "recognise traffic to be steered", an offline DPI is a valid source of inputs into the steering decision. 

I am not sure a protocol is needed to be developed. In our current work, we use SOAP interface between the offline actionable intelligence box and the steering decision device.

My comment is more in the context of steering traffic at layer 1/2/3 level i.e. using OpenFlow rather than steering at layer 4-7 level. Steering at layer 4-7 can be provided for as a service function and already available today in devices such as LB, ADC and DPI. Traffic is steered to the service functions at layer1/2/3.

Regards,
Chuong 

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Friday, 7 February 2014 12:47 PM
To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Thoughts?

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Thursday, February 06, 2014 6:11 PM
To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chris,

Regards,
Chuong
-----Original Message-----
From: Chris Frederick [mailto:[email-masked]] 
Sent: Friday, 7 February 2014 2:51 AM
To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Chuong,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Pham, Chuong D
Sent: Wednesday, February 05, 2014 9:24 PM
To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Examples: 

Regards,
Chuong

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]] 
Sent: Thursday, 6 February 2014 12:21 PM
To: Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Dave,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, January 29, 2014 9:46 AM
To: [email-masked]
Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi all,

Thanks,

   Martin

-------- Original Message --------
Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt
Date: Tue, 28 Jan 2014 14:26:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

---

From: Sumandra Majee <[email-masked]>
Date: Sat, 8 Feb 2014 03:45:26 +0000

>> My point was that to "recognise traffic to be steered", an offline DPI
>>is a valid source of inputs into the steering decision.

 It would be too late to steer at that point. A typical DPI needs multiple
pkt before classification so the options are a) buffer the stream or b)
use http redirect (only in http context). Redirect would add more latency
to the overall user experience.

On 2/7/14, 6:59 PM, "Pham, Chuong D" <[email-masked]>
wrote:

>Hi Ron, 
>
>In my comment I just wanted to point out that there is an option to
>deploy an actionable intelligence box in an off-line mode (it is a DPI in
>this discussion), in respond to Chris's suggestion about an TDF function
>to be placed in-line to recognise application flows (the TDF is simply a
>DPI with Sd interface with the PCRF). My point was that to "recognise
>traffic to be steered", an offline DPI is a valid source of inputs into
>the steering decision.
>
>I am not sure a protocol is needed to be developed. In our current work,
>we use SOAP interface between the offline actionable intelligence box and
>the steering decision device.
>
>My comment is more in the context of steering traffic at layer 1/2/3
>level i.e. using OpenFlow rather than steering at layer 4-7 level.
>Steering at layer 4-7 can be provided for as a service function and
>already available today in devices such as LB, ADC and DPI. Traffic is
>steered to the service functions at layer1/2/3.
>
>Regards,
>Chuong 
>

---

From: "Pham, Chuong D" <[email-masked]>
Date: Sat, 8 Feb 2014 14:56:38 +1100

Hi,

I've mentioned before, the idea is to compute a heat map of interesting IP destinations and continue doing so on a continual basis. Yes, I agree it would be too late to steer if you only are thinking about traditional flow recognition mechanism, which as I said, is seen as on the declination with encryption trend and also the "price to pay" in the sense that the customer traffic is "held back" for the DPI to make a decision. That would affect QoE and impose capacity constraint on the DPI.

Even steering with HTTP redirect is better than holding back TCP and HTTP waiting to make a decision like the way DPI is doing today. That case is only ok for the traditional throttling traffic management use case.

One example of how a heat map may be computed is gather traffic and work out TCP flows with high RTT. Those flows will be benefited from TCP Optimisation. Once the heat map has been stable enough in given time window, supply the map to the flow steering control device which will instruct the switch to start steering the new flows to those destinations to the TCP Optimiser.

There are many other examples similar like the ones above.

Regards,
Chuong

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]]
Sent: Saturday, 8 February 2014 2:45 PM
To: Pham, Chuong D; Ron Parker; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]
Cc: Jeffrey Napper (jenapper) ([email-masked])
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

>> My point was that to "recognise traffic to be steered", an offline
>>DPI is a valid source of inputs into the steering decision.

 It would be too late to steer at that point. A typical DPI needs multiple pkt before classification so the options are a) buffer the stream or b) use http redirect (only in http context). Redirect would add more latency to the overall user experience.

On 2/7/14, 6:59 PM, "Pham, Chuong D" <[email-masked]>
wrote:

>deploy an actionable intelligence box in an off-line mode (it is a DPI
>in this discussion), in respond to Chris's suggestion about an TDF
>function to be placed in-line to recognise application flows (the TDF
>is simply a DPI with Sd interface with the PCRF). My point was that to
>"recognise traffic to be steered", an offline DPI is a valid source of
>inputs into the steering decision.
>
>I am not sure a protocol is needed to be developed. In our current
>work, we use SOAP interface between the offline actionable intelligence
>box and the steering decision device.
>
>To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE;
>Dave Dolson; Martin Stiemerling;
>steer function needs to be inline but this function could be provided
>for by the SFC, not necessarily the DPI.
>
>video servers, only one DPI in a major region (can combine with
>sampling technique to reduce load on this DPI) may be adequate, assumed
>that as these videos are wanted by users in other regions as well as
>they are popular. Another advantage is when the DPI is offline (for the
>right use cases), the risk to customer traffic is significantly reduced.
>
>Regards,
>Chuong
>As a comment on item 2) below, I'd offer that out-of-path DPI is
>perhaps not ideal for traffic steering/service chaining; devices that
>receive only an offline copy of a flow cannot themselves redirect/steer
>that flow. So, I wouldn't necessarily agree that the only case where
>the DPI is required to be inline is when it acts as a service function;
>there is also the case where the DPI actually determines the chain +
>steers the flow through the SFC, bidirectionally. I'd further argue
>that this is actually ideal as it obviates some unnecessary signaling overhead.
>Of course, it's possible to deploy offline as you note, with the
>implicit assumption that the offline DPI would then be signaling back
>to inline devices (either directly or circuitously through a PCRF),
>perhaps with inherent race conditions, etc.
>Thanks,
>/c
>
>of encryption (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are
>seeing 30% etc.), the capability of the TDF to be able to inspect at
>application may be diminished.
>
>2- The use of a DPI function in place of the TDF which may or may have
>an interface to the PCRF. This DPI for many traffic cases, do not have
>to be deployed in line with customer traffic. It can be deployed in an
>enforcement Service Function however in this mode, it needs to be
>treated as a Service Function, not a traffic steering device.
>
>from sources such as the network and the traffic, derive traffic
>steering decisions and communicate with the service chaining function.
>
>Examples:
>-Receive from the Mobile network the list of user's ip addresses who
>are at the present located in the congested cells so that new video
>sessions are steered to a video optimisation platform.
>- Inspect network traffic (in out-of-path mode) and derive a heat map
>of problematic TCP flows which may be benefited from TCP Optimiser and
>steer traffic to this device.
>Thanks for your comment. We are going to include a Rel.11 TDF
>paragraph in -01. Possibly we will consider 2 sections: most simple
>case (with APN), actual most advanced case (with TDF).
>Regards,
>Walter
>
>arrangement of mobility architecture, it neglects to show the role of
>the Traffic Detection Function (TDF), also described in the cited 3GPP
>TS
>23.203 (Version 12).
>
>In all of the network diagrams and examples, it should be understood
>that the P-GW is not the only location from which a policy-based
>service chain could be initiated; the standard TDF function can also
>initiate service chains selected by policy and traffic type.
>
>Aside from the APN classification scheme mentioned in section 2.3 of
>the draft, ADC rules can cause decisions based on application type (not
>just based on APN or UDP/TCP port classification).
>
>
>
>

---

From: "Jeffrey Napper (jenapper)" <[email-masked]>
Date: Sun, 9 Feb 2014 19:43:36 +0000

Hi Linda,

First, thanks for the feedback. While it may look like a lot of
components, we still have simplified 3GPP quite a lot. For example, in the
first draft we left out the TDF that appears in recent standards. We¹ll be
adding that in response to other comments. I believe the overview section
is still quite short, but we will try to shorten it a bit further if it is
too long. If you feel anything in particular is missing or extraneous,
please let us know.

Yes, it is probably overkill to have two example APNs. The User & Pass are
important for example in cases of hot-lining where the user must first be
authenticated (for various reasons) before data services are
provided/continued. It is just another example of the important
relationship between Classification (in an SFC sense) and Policy and
Charging (in a 3GPP sense).

Cheers,
Jeff

-----Original Message-----
From: Linda Dunbar <[email-masked]>
Date: Friday, February 7, 2014 at 11:14 PM
To: "Haeffner, Walter, Vodafone DE" <[email-masked]>, Dave
Dolson <[email-masked]>, Martin Stiemerling <[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Cc: Jeffrey Napper <[email-masked]>
Subject: RE: [sfc] Fwd: I-D Action:
draft-haeffner-sfc-use-case-mobility-00.txt

>Walter, et al, 
>
>While it is interesting to show all the components of 3GPP for GiLAN, but
>I don't think it is necessary to have all of them in the SFC use case
>draft. 
>
>For example, on your Section 2.3 ("The Most common classification
>scheme"), it is very confusing to have the Table 1 & Table 2 listing
>"User name & Password". Does it mean that the "User Name & Password" have
>to associated with data packets? Or to be detected by the Classification
>nodes? 
>
>Linda
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Feb 2014 22:13:12 +0000

Jeffrey and Walter, 

Here are some suggestions to your draft:

Section 2.2: 
- your draft states "The Gi-LAN service functions may use subscriber and service related metadata delivered from mobile control plane function like PCRF to process the flows according to service related policies"

Since PCRF usually only interfaces with the GGSN (via Diameter), not the service functions, do you mean "for the GGSN (or the flow classifier) to carry the data passed down from PCRF to packets' metadata field to service functions on the chain"?
Since the policies passed down by PCRF usually can't be understood by service functions, I suggest changing to the following text:

"The (S)Gi-LAN service functions may use subscriber and service related information, that are either embedded in packets as metadata or passed down from control plane, to  process the flows according to service related policies"

Section 2.3 The most common classification scheme

I think this section is very confusing. How is "APN for P-GW IP address" used in traffic classification? 

Are you saying that traffic are grouped to specific P-GW? And each APN has a VLAN-ID? 

I understand that some common classification scheme could be encoding a certain QoS to a specific flow, applying some security functions to some flows, etc. The classification node can use simple VLAN-ID to mark different classification. 

P-GW is the ingress node to the Gi-LAN Service Chain, isn't it?  

I think the Wireless Service Chain example given by Walter at Berlin SFC BOF is very good. 

Walter's wireless example is described in the Section 3.2 of https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/

Maybe you can use the text to replace your Section 2.3? Here is the suggested text:
-----------------
The P-GW/PCEF (per 3GPP terminology) determines the desired service treatment, i.e. desired sequence of service functions, to specific flows based on the policies from PCRF. 
The P-GW in the figure acts as the Service Chain Classification Node. P-GW separates the traffic into different categories (or flows) based on the policies from PCRF. The traffic in each category (or flow) is mapped to a unique interface (a physical or virtual port) or a tunnel that is connected to the needed sequence of service functions. 
 
                    |       Mobile backhaul Network        
        +-----+     |          +---+---+   
        |PCRF |     |          |Network|   
        |     |  < ---- >      |Ctrller|   
        +-----+     |          +----+--+ 
           |        |                       
           |        |              
    +---------+  |  +--------+   +----+      +---------+
-- >| P-GW    | --> |LB      |---| FW |-->   | Web     | ------>
    |         |  |  |        |   |    |      | Proxy   |
--->|         |  |  +--------+   +----+      +---------+
--->|         |  |  +---------+   +----+     
-- >|         | --> |Video    |---| FW |-->  ----------- ------>
    |   [PCEF]|  |  |Optimizer|   |    | 
    |         |  |  +---------+   +----+
--->|         |  |  +--------+   +-----+     
-- >|         | --> |SBC     |---| ACL |-->  ----------- ------>
    |         |  |  |        |   |     | 
    +---------+  |  +--------+   +-----+

Figure 1	Service Chain for Mobile Network

Linda

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]] 
Sent: Sunday, February 09, 2014 1:44 PM
To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Linda,

First, thanks for the feedback. While it may look like a lot of components, we still have simplified 3GPP quite a lot. For example, in the first draft we left out the TDF that appears in recent standards. We¹ll be adding that in response to other comments. I believe the overview section is still quite short, but we will try to shorten it a bit further if it is too long. If you feel anything in particular is missing or extraneous, please let us know.

Yes, it is probably overkill to have two example APNs. The User & Pass are important for example in cases of hot-lining where the user must first be authenticated (for various reasons) before data services are provided/continued. It is just another example of the important relationship between Classification (in an SFC sense) and Policy and Charging (in a 3GPP sense).

Cheers,
Jeff

-----Original Message-----
From: Linda Dunbar <[email-masked]>
Date: Friday, February 7, 2014 at 11:14 PM
To: "Haeffner, Walter, Vodafone DE" <[email-masked]>, Dave Dolson <[email-masked]>, Martin Stiemerling <[email-masked]>, "[email-masked]"

>Walter, et al,
>
>While it is interesting to show all the components of 3GPP for GiLAN, 
>but I don't think it is necessary to have all of them in the SFC use 
>case draft.
>
>"User name & Password". Does it mean that the "User Name & Password" 
>have to associated with data packets? Or to be detected by the 
>Classification nodes?
>
>Linda
>

---

From: Alla Goldner <[email-masked]>
Date: Thu, 13 Feb 2014 06:17:32 +0000

Deal Linda, 

The 3GPP architecture picture described below is not accurate. 
Starting from R11, PCRF interacts also with TDF (Traffic Detection Function) for providing ADC (Application Detection and Control) Rules for application detection, enforcement and also charging starting from R12. Please see architecture diagram for your reference in the 3GPP TS 23.203.

Therefore, we can't assume that "Since PCRF usually only interfaces with the GGSN (via Diameter), not the service functions, do you mean "for the GGSN (or the flow classifier) to carry the data passed down from PCRF to packets' metadata field to service functions on the chain"?"

Furthermore, also the claim that 
"The P-GW/PCEF (per 3GPP terminology) determines the desired service treatment, i.e. desired sequence of service functions, to specific flows based on the policies from PCRF. 
The P-GW in the figure acts as the Service Chain Classification Node. P-GW separates the traffic into different categories (or flows) based on the policies from PCRF. The traffic in each category (or flow) is mapped to a unique interface (a physical or virtual port) or a tunnel that is connected to the needed sequence of service functions." is not correct as well as PGW/PCEF is not the only element which enforces different support per different flows based on policies received from PCRF, but also TDF!

My general feeling is that we are getting here deeply into 3GPP architecture and make assumptions and conclusions about potential 3GPP elements functionality which are not in scope of IETF. If we want to define use cases for 3GPP networks, then we should  show correct picture of 3GPP architecture without redesigning it and leave 3GPP Network Elements functionality potential extensions to 3GPP.

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 Linda Dunbar
Sent: Thursday, February 13, 2014 12:13 AM
To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Jeffrey and Walter, 

Section 2.2: 

 

Linda

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]]
Sent: Sunday, February 09, 2014 1:44 PM
To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Linda,

Cheers,
Jeff

-----Original Message-----
From: Linda Dunbar <[email-masked]>
Date: Friday, February 7, 2014 at 11:14 PM
To: "Haeffner, Walter, Vodafone DE" <[email-masked]>, Dave Dolson <[email-masked]>, Martin Stiemerling <[email-masked]>, "[email-masked]"

_______________________________________________
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: Jerome Moisand <[email-masked]>
Date: Thu, 13 Feb 2014 15:26:39 +0000

Alla & folks,

Well... I don't know... Getting deep in network architectures and the role of the various network elements is indeed crucial. Both 3GPP and BBF (Broadband Forum) did a lot of work in the past decade to define architecture & nodal requirements, which shaped in turn the deployment of all major Service Providers worldwide. So quite clearly, service chaining have to build on that and find a good way to insert itself into such architectures while extending them.

Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate for service classification/enforcement, as it... already does it for its own purpose! This is BY NATURE a highly scalable subscriber & service management system, classifying and enforcing policies (usually L3, occasionally higher), and fully integrated with the HSS/PCRF chain which holds the subscriber/service authentication & authorization data. As such, service classification *and* service enforcement (and service accounting) is already there. For 100% of the mobile (data) subscribers. Sure enough, a TDF system may also do its own form of service classification (and processing too), but let's not forget this is an OPTIONAL system on the data path on the recently defined 3GPP architectures you referred to. For many use cases, there is just no point going through a DPI function. While for other use cases, there is clearly such a point, but only when it brings clear value for a given service construct, only applicable to corresponding subscribers.

In the same vein, in fixed-broadband architectures, a BNG is the primary subscriber management system on the data path, fully integrated with a AAA system, and already doing service classification *and* service processing at scale for 100% of the subscribers. Any classification/enforcement system behind it is optional and only applicable to a subset of services & subscribers.

Bottomline: sure, use cases with TDF should be described, but PGW-centric use cases remain the rule, not the exception. And double-clicking on existing standardized network architectures (e.g. 3GPP and BBF) and related deployments is crucial for our SFC endeavor.

Jerome Moisand.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Thursday, February 13, 2014 1:18 AM
To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Deal Linda, 

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 Linda Dunbar
Sent: Thursday, February 13, 2014 12:13 AM
To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Jeffrey and Walter, 

Section 2.2: 

 

Linda

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]]
Sent: Sunday, February 09, 2014 1:44 PM
To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Linda,

Cheers,
Jeff

---

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

Dear Jerome,

Yes, TDF is an optional element in mobile networks. As a such, Sd interface is also optional. However, the GGSN/PGW-PCRF (Gx) interface is optional in exactly the same way. The whole 3GPP PCC architecture is optional. Therefore, the claim about 100% of mobile data subscribers may not be fully correct. And with regards to the features required for service classification and service enforcement  that you describe below - they are present at both GGSN/PGW and TDF.

The bottom line is that use cases where PGW is considered as classifier OF COURSE should be considered, same as use cases where TDF is considered as a classifier. And, once describing those use cases, the existing 3GPP architecture should be assumed.

Best regards,

Alla Goldner

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 5:27 PM
To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Alla & folks,

Jerome Moisand.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Thursday, February 13, 2014 1:18 AM
To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Deal Linda, 

Best regards,

Alla Goldner

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, February 13, 2014 12:13 AM
To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Jeffrey and Walter, 

Section 2.2: 

 

Linda

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]]
Sent: Sunday, February 09, 2014 1:44 PM
To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Linda,

Cheers,
Jeff

---

From: Jerome Moisand <[email-masked]>
Date: Thu, 13 Feb 2014 16:29:37 +0000

I don't know if the whole PCC architecture is truly optional in 3GPP theory (I've never seen it expressed that way, but I'll take your word for it), but one would be hard-pressed to find a 3G/LTE mobile broadband network without it. So in practice my 100% statement remains true (I'll give you 99.9% if you wish!). 

So I have a bit of an issue putting PGW and TDF at the same level. This simply doesn't reflect any reality, nor the spirit of the 3GPP specs.

And in the fixed-broadband world in BBF terms, yeah, the BNG IS mandatory (I took a very active role in several of those specs, e.g. TR-101). While a DPI function is truly optional (and not that many subscribers in absolute % go through it in practice) and not standardized.

Anyway, I agree with you that mobile use cases with or without TDF should be considered. A case without PGW would seem much more dubious to me. We may be saying more or the same thing, overall.

-----Original Message-----
From: Alla Goldner [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 11:15 AM
To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Dear Jerome,

Best regards,

Alla Goldner

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 5:27 PM
To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Alla & folks,

Jerome Moisand.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Thursday, February 13, 2014 1:18 AM
To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Deal Linda, 

Best regards,

Alla Goldner

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, February 13, 2014 12:13 AM
To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Jeffrey and Walter, 

Section 2.2: 

 

Linda

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]]
Sent: Sunday, February 09, 2014 1:44 PM
To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Linda,

Cheers,
Jeff

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 13 Feb 2014 23:16:35 +0000

Alla, Jerome, 

Since 3GPP has defined many components and are still involving, can we use a simplified box to represent an entity associated with P-GW that classifies the traffic based on PCRF rules, TDF, and/or PCEF? Such as:

                    |       Mobile backhaul Network        
        +-----+     |          +---+---+   
        |PCRF/|     |          |Network|   
        |rules|  < ---- >      |Ctrller|   
        +-----+     |          +----+--+ 
           |        |                       
           V        |              
    +---------+  |  +--------+   +----+      +---------+
-- >| P-GW    | --> |LB      |---| FW |-->   | Web     | ------>
    |         |  |  |        |   |    |      | Proxy   |
--->|  & or   |  |  +--------+   +----+      +---------+
--->|         |  |  +---------+   +----+     
-- >|         | --> |Video    |---| FW |-->  ----------- ------>
    |TDF/PCEF |  |  |Optimizer|   |    | 
    |         |  |  +---------+   +----+
--->|         |  |  +--------+   +-----+     
-- >|         | --> |SBC     |---| ACL |-->  ----------- ------>
    |         |  |  |        |   |     | 
    +---------+  |  +--------+   +-----+

As for the description of metadata used by Gi-LAN service function, we don't have to specifically say which elements defined by 3GPP encoded them in. 

Linda

-----Original Message-----
From: Alla Goldner [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 11:15 AM
To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Dear Jerome,

Best regards,

Alla Goldner

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 5:27 PM
To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Alla & folks,

Jerome Moisand.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Thursday, February 13, 2014 1:18 AM
To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Deal Linda, 

Best regards,

Alla Goldner

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, February 13, 2014 12:13 AM
To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Jeffrey and Walter, 

Section 2.2: 

 

Linda

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]]
Sent: Sunday, February 09, 2014 1:44 PM
To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Linda,

Cheers,
Jeff

---

From: "Pham, Chuong D" <[email-masked]>
Date: Fri, 14 Feb 2014 11:40:28 +1100

Hi all,

I am not sure but I feel this draft is discussing more on potential solutions rather than use cases specific to Mobile? I think we should include more use cases and less potential solutions. For example, many use cases in the draft provide details on today's some specific implementations which may not applicable to the majority of Operators.

When the draft touches upon candidate for a classifier, I think we should not exclude anything: PGw, DPI, TDF, LB, Switches etc. as potential classifier but leave this open for another specification draft. Note that the classifier may reside in a data centre, common to and away from multiple access technologies run by the same Operator so it may as well be an independent function. It may also be a function of a MVNO which does not own the physical 3GPP infrastructure i.e. PGw, TDF, PCRF.

Regards,
Chuong

-----Original Message-----
From: Alla Goldner [mailto:[email-masked]]
Sent: Friday, 14 February 2014 3:15 AM
To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Dear Jerome,

Best regards,

Alla Goldner

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 5:27 PM
To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Alla & folks,

Jerome Moisand.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Thursday, February 13, 2014 1:18 AM
To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Deal Linda,

Best regards,

Alla Goldner

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, February 13, 2014 12:13 AM
To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Jeffrey and Walter,

Section 2.2:

Linda

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]]
Sent: Sunday, February 09, 2014 1:44 PM
To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Linda,

Cheers,
Jeff

---

From: Alla Goldner <[email-masked]>
Date: Fri, 14 Feb 2014 06:42:34 +0000

Dear Linda, all,

I think this presentation is more correct, thank you.

One thing though may need to be corrected: PCEF is an integral part of PGW as defined by 3GPP standards. Therefore, we may, as an option,  mention "PCEF/TDF" without "PGW", and then put a note that PCEF resides in PGW.

Best regards,

Alla Goldner

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, February 14, 2014 1:17 AM
To: Jerome Moisand; Alla Goldner; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Alla, Jerome, 

Linda

-----Original Message-----
From: Alla Goldner [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 11:15 AM
To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Dear Jerome,

Best regards,

Alla Goldner

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 5:27 PM
To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Alla & folks,

Jerome Moisand.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Thursday, February 13, 2014 1:18 AM
To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Deal Linda, 

Best regards,

Alla Goldner

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, February 13, 2014 12:13 AM
To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Jeffrey and Walter, 

Section 2.2: 

 

Linda

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]]
Sent: Sunday, February 09, 2014 1:44 PM
To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Linda,

Cheers,
Jeff

---

From: Jerome Moisand <[email-masked]>
Date: Fri, 14 Feb 2014 15:28:50 +0000

Linda,

A PGW is a PCEF for sure (hence is more than a classifier). So this part of your proposed drawing would have to be improved.

Now in the TDF case, a better drawing would show PGW(PCEF) and TDF(PCEF) in sequence. As this is the reality of things, a TDF does not replace a PGW, it (optionally) complements it.

Anyhoo, I feel we're going a bit in circles here. Why not letting the authors of this draft (who obviously know the 3GPP constructs very well) improve it as they see fit based on the feedback?

Tx
Jerome

-----Original Message-----
From: Alla Goldner [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 1:43 AM
To: Linda Dunbar; Jerome Moisand; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Dear Linda, all,

Best regards,

Alla Goldner

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, February 14, 2014 1:17 AM
To: Jerome Moisand; Alla Goldner; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Alla, Jerome, 

Linda

-----Original Message-----
From: Alla Goldner [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 11:15 AM
To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Dear Jerome,

Best regards,

Alla Goldner

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 5:27 PM
To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Alla & folks,

Jerome Moisand.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Thursday, February 13, 2014 1:18 AM
To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Deal Linda, 

Best regards,

Alla Goldner

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, February 13, 2014 12:13 AM
To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Jeffrey and Walter, 

Section 2.2: 

 

Linda

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]]
Sent: Sunday, February 09, 2014 1:44 PM
To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi Linda,

Cheers,
Jeff

---

From: "Jeffrey Napper (jenapper)" <[email-masked]>
Date: Tue, 18 Feb 2014 18:15:57 +0000

Hi guys,

Yes, we have submitted a revision that includes discussion of the TDF.

The changes from the previous draft include a short comparison of fixed
networks that are similar to 3GPP, introduction of the TDF, additional
co-authors Martin and Diego, and some other tidying up.

I hope that the new text addresses your concerns. Please let us know if
there are still problems with the text. I think Walter will present some
slides over the draft in London.

Cheers,
Jeff

-----Original Message-----
From: Jerome Moisand <[email-masked]>
Date: Friday, February 14, 2014 at 4:28 PM
To: Alla Goldner <[email-masked]>, Linda Dunbar
<[email-masked]>, Jeffrey Napper <[email-masked]>, "Haeffner,
Walter, Vodafone DE" <[email-masked]>, Dave Dolson
<[email-masked]>, Martin Stiemerling <[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: [sfc] Fwd: I-D
Action:	draft-haeffner-sfc-use-case-mobility-00.txt

>Linda,
>
>A PGW is a PCEF for sure (hence is more than a classifier). So this part
>of your proposed drawing would have to be improved.
>
>Now in the TDF case, a better drawing would show PGW(PCEF) and TDF(PCEF)
>in sequence. As this is the reality of things, a TDF does not replace a
>PGW, it (optionally) complements it.
>
>Anyhoo, I feel we're going a bit in circles here. Why not letting the
>authors of this draft (who obviously know the 3GPP constructs very well)
>improve it as they see fit based on the feedback?
>
>Tx
>Jerome
>
>To: Linda Dunbar; Jerome Moisand; Jeffrey Napper (jenapper); Haeffner,
>Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;
>One thing though may need to be corrected: PCEF is an integral part of
>PGW as defined by 3GPP standards. Therefore, we may, as an option,
>mention "PCEF/TDF" without "PGW", and then put a note that PCEF resides
>in PGW.
>
>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
>
>
>
>
>To: Jerome Moisand; Alla Goldner; Jeffrey Napper (jenapper); Haeffner,
>Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;
>Since 3GPP has defined many components and are still involving, can we
>use a simplified box to represent an entity associated with P-GW that
>classifies the traffic based on PCRF rules, TDF, and/or PCEF? Such as:
>
>
>As for the description of metadata used by Gi-LAN service function, we
>don't have to specifically say which elements defined by 3GPP encoded
>them in. 
>
>
>Linda
>To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,
>Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;
>I don't know if the whole PCC architecture is truly optional in 3GPP
>theory (I've never seen it expressed that way, but I'll take your word
>for it), but one would be hard-pressed to find a 3G/LTE mobile broadband
>network without it. So in practice my 100% statement remains true (I'll
>give you 99.9% if you wish!).
>
>So I have a bit of an issue putting PGW and TDF at the same level. This
>simply doesn't reflect any reality, nor the spirit of the 3GPP specs.
>
>And in the fixed-broadband world in BBF terms, yeah, the BNG IS mandatory
>(I took a very active role in several of those specs, e.g. TR-101). While
>a DPI function is truly optional (and not that many subscribers in
>absolute % go through it in practice) and not standardized.
>
>Anyway, I agree with you that mobile use cases with or without TDF should
>be considered. A case without PGW would seem much more dubious to me. We
>may be saying more or the same thing, overall.
>
>To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,
>Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;
>Yes, TDF is an optional element in mobile networks. As a such, Sd
>interface is also optional. However, the GGSN/PGW-PCRF (Gx) interface is
>optional in exactly the same way. The whole 3GPP PCC architecture is
>optional. Therefore, the claim about 100% of mobile data subscribers may
>not be fully correct. And with regards to the features required for
>service classification and service enforcement  that you describe below -
>they are present at both GGSN/PGW and TDF.
>
>The bottom line is that use cases where PGW is considered as classifier
>OF COURSE should be considered, same as use cases where TDF is considered
>as a classifier. And, once describing those use cases, the existing 3GPP
>architecture should be assumed.
>
>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
>
>
>
>
>
>To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,
>Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;
>Well... I don't know... Getting deep in network architectures and the
>role of the various network elements is indeed crucial. Both 3GPP and BBF
>(Broadband Forum) did a lot of work in the past decade to define
>architecture & nodal requirements, which shaped in turn the deployment of
>all major Service Providers worldwide. So quite clearly, service chaining
>have to build on that and find a good way to insert itself into such
>architectures while extending them.
>
>Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate for
>service classification/enforcement, as it... already does it for its own
>purpose! This is BY NATURE a highly scalable subscriber & service
>management system, classifying and enforcing policies (usually L3,
>occasionally higher), and fully integrated with the HSS/PCRF chain which
>holds the subscriber/service authentication & authorization data. As
>such, service classification *and* service enforcement (and service
>accounting) is already there. For 100% of the mobile (data) subscribers.
>Sure enough, a TDF system may also do its own form of service
>classification (and processing too), but let's not forget this is an
>OPTIONAL system on the data path on the recently defined 3GPP
>architectures you referred to. For many use cases, there is just no point
>going through a DPI function. While for other use cases, there is clearly
>such a point, but only when it brings clear value for a given service
>construct, only applicable to corresponding subscribers.
>
>In the same vein, in fixed-broadband architectures, a BNG is the primary
>subscriber management system on the data path, fully integrated with a
>AAA system, and already doing service classification *and* service
>processing at scale for 100% of the subscribers. Any
>classification/enforcement system behind it is optional and only
>applicable to a subset of services & subscribers.
>
>Bottomline: sure, use cases with TDF should be described, but PGW-centric
>use cases remain the rule, not the exception. And double-clicking on
>existing standardized network architectures (e.g. 3GPP and BBF) and
>related deployments is crucial for our SFC endeavor.
>
>Jerome Moisand.
>
>To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone
>DE; Dave Dolson; Martin Stiemerling;
>Starting from R11, PCRF interacts also with TDF (Traffic Detection
>Function) for providing ADC (Application Detection and Control) Rules for
>application detection, enforcement and also charging starting from R12.
>Please see architecture diagram for your reference in the 3GPP TS 23.203.
>
>Therefore, we can't assume that "Since PCRF usually only interfaces with
>the GGSN (via Diameter), not the service functions, do you mean "for the
>GGSN (or the flow classifier) to carry the data passed down from PCRF to
>packets' metadata field to service functions on the chain"?"
>
>"The P-GW/PCEF (per 3GPP terminology) determines the desired service
>treatment, i.e. desired sequence of service functions, to specific flows
>based on the policies from PCRF.
>The P-GW in the figure acts as the Service Chain Classification Node.
>P-GW separates the traffic into different categories (or flows) based on
>the policies from PCRF. The traffic in each category (or flow) is mapped
>to a unique interface (a physical or virtual port) or a tunnel that is
>connected to the needed sequence of service functions." is not correct as
>well as PGW/PCEF is not the only element which enforces different support
>per different flows based on policies received from PCRF, but also TDF!
>
>My general feeling is that we are getting here deeply into 3GPP
>architecture and make assumptions and conclusions about potential 3GPP
>elements functionality which are not in scope of IETF. If we want to
>define use cases for 3GPP networks, then we should  show correct picture
>of 3GPP architecture without redesigning it and leave 3GPP Network
>Elements functionality potential extensions to 3GPP.
>
>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
>
>
>
>
>
>To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave
>- your draft states "The Gi-LAN service functions may use subscriber and
>service related metadata delivered from mobile control plane function
>like PCRF to process the flows according to service related policies"
>
>Since PCRF usually only interfaces with the GGSN (via Diameter), not the
>service functions, do you mean "for the GGSN (or the flow classifier) to
>carry the data passed down from PCRF to packets' metadata field to
>service functions on the chain"?
>Since the policies passed down by PCRF usually can't be understood by
>service functions, I suggest changing to the following text:
>
>"The (S)Gi-LAN service functions may use subscriber and service related
>information, that are either embedded in packets as metadata or passed
>down from control plane, to  process the flows according to service
>related policies"
>
>
>I understand that some common classification scheme could be encoding a
>certain QoS to a specific flow, applying some security functions to some
>flows, etc. The classification node can use simple VLAN-ID to mark
>different classification.
>
>Walter's wireless example is described in the Section 3.2 of
>https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-archi
>tecture/
>
>The P-GW/PCEF (per 3GPP terminology) determines the desired service
>treatment, i.e. desired sequence of service functions, to specific flows
>based on the policies from PCRF.
>The P-GW in the figure acts as the Service Chain Classification Node.
>P-GW separates the traffic into different categories (or flows) based on
>the policies from PCRF. The traffic in each category (or flow) is mapped
>to a unique interface (a physical or virtual port) or a tunnel that is
>connected to the needed sequence of service functions.
> 
>To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin
>components, we still have simplified 3GPP quite a lot. For example, in
>the first draft we left out the TDF that appears in recent standards.
>We¹ll be adding that in response to other comments. I believe the
>overview section is still quite short, but we will try to shorten it a
>bit further if it is too long. If you feel anything in particular is
>missing or extraneous, please let us know.
>
>Yes, it is probably overkill to have two example APNs. The User & Pass
>are important for example in cases of hot-lining where the user must
>first be authenticated (for various reasons) before data services are
>This message is intended only for the designated recipient(s).It may
>contain confidential or proprietary information.
>This message is intended only for the designated recipient(s).It may
>contain confidential or proprietary information.
>This message is intended only for the designated recipient(s).It may
>contain confidential or proprietary information.

---

From: Alla Goldner <[email-masked]>
Date: Tue, 18 Feb 2014 18:22:38 +0000

Hi,

Thanks a lot for this update!

There are two things which needs to be corrected:

1. The related 3GPP specification should be TS 23.203 and not TS 29.212 (29.212 is protocol level description only while TS 23.203 defines general PCC architecture).

2. The sentence "The Traffic Detection Function (TDF) [TS.29.212] is currently under standardization within 3GPP." is not correct, as TDF was standardized back in R11 of 3GPP and this is an existing entity for the last couple of years thus should be described as a such.

Best regards,

Alla Goldner

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]] 
Sent: Tuesday, February 18, 2014 8:16 PM
To: Jerome Moisand; Alla Goldner; Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi guys,

The changes from the previous draft include a short comparison of fixed networks that are similar to 3GPP, introduction of the TDF, additional co-authors Martin and Diego, and some other tidying up.

I hope that the new text addresses your concerns. Please let us know if there are still problems with the text. I think Walter will present some slides over the draft in London.

Cheers,
Jeff

-----Original Message-----
From: Jerome Moisand <[email-masked]>
Date: Friday, February 14, 2014 at 4:28 PM
To: Alla Goldner <[email-masked]>, Linda Dunbar <[email-masked]>, Jeffrey Napper <[email-masked]>, "Haeffner, Walter, Vodafone DE" <[email-masked]>, Dave Dolson <[email-masked]>, Martin Stiemerling <[email-masked]>, "[email-masked]"

>Linda,
>
>A PGW is a PCEF for sure (hence is more than a classifier). So this 
>part of your proposed drawing would have to be improved.
>
>Now in the TDF case, a better drawing would show PGW(PCEF) and 
>TDF(PCEF) in sequence. As this is the reality of things, a TDF does not 
>replace a PGW, it (optionally) complements it.
>
>authors of this draft (who obviously know the 3GPP constructs very 
>well) improve it as they see fit based on the feedback?
>
>Tx
>Jerome
>
>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 
>[email-masked]
>www.allot.com
>
>
>
>
>for it), but one would be hard-pressed to find a 3G/LTE mobile 
>broadband network without it. So in practice my 100% statement remains 
>true (I'll give you 99.9% if you wish!).
>
>And in the fixed-broadband world in BBF terms, yeah, the BNG IS 
>mandatory (I took a very active role in several of those specs, e.g. 
>TR-101). While a DPI function is truly optional (and not that many 
>subscribers in absolute % go through it in practice) and not standardized.
>
>Anyway, I agree with you that mobile use cases with or without TDF 
>should be considered. A case without PGW would seem much more dubious 
>to me. We may be saying more or the same thing, overall.
>
>interface is also optional. However, the GGSN/PGW-PCRF (Gx) interface 
>is optional in exactly the same way. The whole 3GPP PCC architecture is 
>optional. Therefore, the claim about 100% of mobile data subscribers 
>may not be fully correct. And with regards to the features required for 
>service classification and service enforcement  that you describe below 
>- they are present at both GGSN/PGW and TDF.
>
>OF COURSE should be considered, same as use cases where TDF is 
>considered as a classifier. And, once describing those use cases, the 
>existing 3GPP architecture should be assumed.
>
>Best regards,
>
>
>Alla Goldner
>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 
>[email-masked]
>www.allot.com
>
>
>
>
>
>role of the various network elements is indeed crucial. Both 3GPP and 
>BBF (Broadband Forum) did a lot of work in the past decade to define 
>architecture & nodal requirements, which shaped in turn the deployment 
>of all major Service Providers worldwide. So quite clearly, service 
>chaining have to build on that and find a good way to insert itself 
>into such architectures while extending them.
>
>Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate 
>for service classification/enforcement, as it... already does it for 
>its own purpose! This is BY NATURE a highly scalable subscriber & 
>service management system, classifying and enforcing policies (usually 
>L3, occasionally higher), and fully integrated with the HSS/PCRF chain 
>which holds the subscriber/service authentication & authorization data. 
>As such, service classification *and* service enforcement (and service
>architectures you referred to. For many use cases, there is just no 
>point going through a DPI function. While for other use cases, there is 
>clearly such a point, but only when it brings clear value for a given 
>service construct, only applicable to corresponding subscribers.
>
>In the same vein, in fixed-broadband architectures, a BNG is the 
>primary subscriber management system on the data path, fully integrated 
>with a AAA system, and already doing service classification *and* 
>service processing at scale for 100% of the subscribers. Any 
>Bottomline: sure, use cases with TDF should be described, but 
>PGW-centric use cases remain the rule, not the exception. And 
>double-clicking on existing standardized network architectures (e.g. 
>3GPP and BBF) and related deployments is crucial for our SFC endeavor.
>
>Jerome Moisand.
>
>Function) for providing ADC (Application Detection and Control) Rules 
>for application detection, enforcement and also charging starting from R12.
>Therefore, we can't assume that "Since PCRF usually only interfaces 
>with the GGSN (via Diameter), not the service functions, do you mean 
>"for the GGSN (or the flow classifier) to carry the data passed down 
>from PCRF to packets' metadata field to service functions on the chain"?"
>
>treatment, i.e. desired sequence of service functions, to specific 
>flows based on the policies from PCRF.
>P-GW separates the traffic into different categories (or flows) based 
>on the policies from PCRF. The traffic in each category (or flow) is 
>mapped to a unique interface (a physical or virtual port) or a tunnel 
>that is connected to the needed sequence of service functions." is not 
>correct as well as PGW/PCEF is not the only element which enforces 
>different support per different flows based on policies received from PCRF, but also TDF!
>
>define use cases for 3GPP networks, then we should  show correct 
>picture of 3GPP architecture without redesigning it and leave 3GPP 
>Network Elements functionality potential extensions to 3GPP.
>
>Best regards,
>
>Alla Goldner
>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 
>[email-masked]
>www.allot.com
>
>
>
>
>
>- your draft states "The Gi-LAN service functions may use subscriber 
>and service related metadata delivered from mobile control plane 
>function like PCRF to process the flows according to service related policies"
>
>Since PCRF usually only interfaces with the GGSN (via Diameter), not 
>the service functions, do you mean "for the GGSN (or the flow 
>classifier) to carry the data passed down from PCRF to packets' 
>metadata field to service functions on the chain"?
>certain QoS to a specific flow, applying some security functions to 
>some flows, etc. The classification node can use simple VLAN-ID to mark 
>treatment, i.e. desired sequence of service functions, to specific 
>flows based on the policies from PCRF.
>P-GW separates the traffic into different categories (or flows) based 
>on the policies from PCRF. The traffic in each category (or flow) is 
>mapped to a unique interface (a physical or virtual port) or a tunnel 
>that is connected to the needed sequence of service functions.
> 
>To: "Haeffner, Walter, Vodafone DE" <[email-masked]>, 
>Dave Dolson <[email-masked]>, Martin Stiemerling 
><[email-masked]>, "[email-masked]"
>>the draft, ADC rules can cause decisions based on application type 
>>(not just based on APN or UDP/TCP port classification).
>>
>>
>>
>>
>#######################################################################
>###
>####################
>If you have mistakenly received this message, please notify the sender 
>by a reply e-mail and delete this message.
>Thank you.
>#######################################################################
>###
>####################
>
>#######################################################################
>###
>####################
>If you have mistakenly received this message, please notify the sender 
>by a reply e-mail and delete this message.
>Thank you.
>#######################################################################
>###
>####################
>
>
>
>#######################################################################
>###
>####################
>If you have mistakenly received this message, please notify the sender 
>by a reply e-mail and delete this message.
>Thank you.
>#######################################################################
>###
>####################
>
>
>

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Tue, 18 Feb 2014 18:29:11 +0000

Hi Alla, 
Thanks for your support. We will correct the 3GPPP doc reference and well, you are right, TDF came with Rel. 11 (as I remarked in an earlier mail).
Regards, 
Walter  

-----Ursprüngliche Nachricht-----
Von: Alla Goldner [mailto:[email-masked]] 
Gesendet: Dienstag, 18. Februar 2014 19:23
An: Jeffrey Napper (jenapper); Jerome Moisand; Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi,

Best regards,

Alla Goldner

-----Original Message-----
From: Jeffrey Napper (jenapper) [mailto:[email-masked]] 
Sent: Tuesday, February 18, 2014 8:16 PM
To: Jerome Moisand; Alla Goldner; Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt

Hi guys,

Cheers,
Jeff

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 21 Feb 2014 16:37:49 +0200

Hi,

While we are at this, correcting 3GPP details, few additional comments:

   The radio-based IP traffic between the UE and the eNB is encrypted
   according 3GPP standards.  Between eNB, S-GW, P-GW user IP packets as

Since control plane is referred below, I would add MME to the list.

   well as control plane packets are encapsulated in 3GPP-specific
   tunnels.  In some mobile carrier networks the 3GPP specific tunnels

Which control signalling is actually meant here that is both 3GPP-specific
tunnelled and between eNB & some other node? Do you mean control'ish extension
headers carried in GTP-U or something else? If S1-MME between eNB and
MME is referred here that would be directly over SCTP (like X2 between
eNBs). And whether GTP-C is actually "tunnelling" is debatable but lets
not go there.

   between eNB and S-GW are even additionally IPSec-encrypted.  For more

Traffic is IPsec ESP encrypted between eNB and the Security Gateway, not
SGW.

   details see [TS.29.281] and [TS.29.274].

A good reference for the security part would be NDS spec TS33.210.

- JOuni