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

From: [email-masked]
Date: Tue, 06 May 2014 07:21:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Service Function Chaining Working Group of the IETF.

        Title           : Service Function Chaining Use Cases in Mobile Networks
        Authors         : Walter Haeffner
                          Jeffrey Napper
                          Martin Stiemerling
                          Diego R. Lopez
                          Jim Uttaro
	Filename        : draft-ietf-sfc-use-case-mobility-00.txt
	Pages           : 23
	Date            : 2014-05-06

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 specification of service function chaining for mobile networks
   must take into account an interaction between service function chains
   and the 3GPP Policy and Charging Control (PCC) environment.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-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/

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 07 May 2014 09:24:20 +0300

Hi,

This is a small set of nits for Section 2.1 but I'd like to see them 
discussed & corrected. See the mail I sent earlier on the same topic 
when the document was still an individual I-D:
	http://www.ietf.org/mail-archive/web/sfc/current/msg01253.html

- Jouni

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Wed, 7 May 2014 10:59:13 +0000

Referring to your February 21st email link below:

Hi Jouni,

Sorry, I missed that part. Only added TDF function. To keep it simple I suggest:

1.) to delete  .... "as well as control plane"  and just refer to user plane, leaving away any control stuff and write

The radio-based IP traffic between the UE and the eNB is encrypted according 3GPP standards.  Between eNB, S-GW, P-GW user plane IP packets  are encapsulated in 3GPP-specific tunnels.  

2.) Accept. For the moment I propose to add a sentence for clarification:

In some mobile carrier networks the 3GPP specific tunnels between eNB and S-GW are even additionally IPSec-encrypted. More precisely, IPSec originates/terminates at the eNB and on the other side at an IPSec-GW often placed just in front of the S-GW.  For more details see [TS.29.281],  [TS.29.274] and [TS33.210].

Any suggestions for a better wording?

Kind regards, 
Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Jouni Korhonen
Gesendet: Mittwoch, 7. Mai 2014 08:24
An: [email-masked]
Betreff: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00

Hi,

This is a small set of nits for Section 2.1 but I'd like to see them discussed & corrected. See the mail I sent earlier on the same topic when the document was still an individual I-D:
	http://www.ietf.org/mail-archive/web/sfc/current/msg01253.html

- Jouni

> 	Filename        : draft-ietf-sfc-use-case-mobility-00.txt

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 7 May 2014 11:39:53 -0500

Also I had a comment at this message:

http://www.ietf.org/mail-archive/web/sfc/current/msg01906.html

Behcet

On Wed, May 7, 2014 at 1:24 AM, Jouni Korhonen <[email-masked]>wrote:

> discussed & corrected. See the mail I sent earlier on the same topic when
> the document was still an individual I-D:

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 08 May 2014 09:05:27 +0300

Walter,

Looks better now. I would propose the following wording, which only 
changes the place of GTP spec reference from what you proposed below:

    The radio-based IP traffic between the UE and the eNB is encrypted
    according 3GPP standards.  Between eNB, S-GW, P-GW user plane IP
    packets  are encapsulated in 3GPP-specific tunnels [TS.29.281],
    [TS.29.274]. In some mobile carrier networks the 3GPP specific
    tunnels between eNB and S-GW are even additionally IPSec-encrypted.
    More precisely, IPSec originates/terminates at the eNB and on the
    other side at an IPSec-GW often placed just in front of the S-GW.
    For more details see  and [TS33.210].

- Jouni

---

From: "Jeffrey Napper (jenapper)" <[email-masked]>
Date: Fri, 9 May 2014 08:02:34 +0000

Hello Behcet,

Sorry for not replying. I don't believe the spec specifically states that the NAT should be before the Gi-LAN, rather that it should be after P-GW. It would be difficult to correlate the IP-CAN session that identifies the subscriber session with the address after NAT as the TDF is supposed to.

Cheers,
Jeff

From: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 7, 2014 at 6:39 PM
To: Jouni Korhonen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00

Behcet

On Wed, May 7, 2014 at 1:24 AM, Jouni Korhonen <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

- Jouni

5/6/2014 5:21 PM, [email-masked]<mailto:[email-masked]> kirjoitti:

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

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Fri, 9 May 2014 08:32:24 +0000

Hi Behcet,

Agree with Jeff. Typically NAT/FW is combined and is placed at the boarder to the Internet (context).  The original picture (1) shouldn't suggest any sequential order of service functions but should only categorize them in three functional types. In the recent version we reformulated the wording to be more precise.

In DSL networks CG-NAT or v4v6-NAT is often placed one hop behind (or even within) the BNG because no further service function will follow.

Regards, Walter

Von: sfc [mailto:[email-masked]] Im Auftrag von Jeffrey Napper (jenapper)
Gesendet: Freitag, 9. Mai 2014 10:03
An: [email-masked]; Jouni Korhonen
Cc: [email-masked]
Betreff: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00

Hello Behcet,

Cheers,
Jeff

Hi,

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 9 May 2014 10:37:34 -0500

Hello Jeff,

On Fri, May 9, 2014 at 3:02 AM, Jeffrey Napper (jenapper) <
[email-masked]> wrote:

>  Hello Behcet,
>
>  Sorry for not replying. I don't believe the spec specifically states
> that the NAT should be before the Gi-LAN, rather that it should be after
> P-GW.
>

Yes, so both are possible.

> It would be difficult to correlate the IP-CAN session that identifies the
> subscriber session with the address after NAT as the TDF is supposed to.
>
>
Yes, so NAT should be the last service function to execute but that is a
solution, there are other solutions.

I discussed these in a recent draft:
http://tools.ietf.org/id/draft-sarikaya-sfc-address-sharing-in-sfc-00.txt

Regards,

Behcet

>  Cheers,
> Jeff
>
>   From: Behcet Sarikaya <[email-masked]>
> Reply-To: "[email-masked]" <[email-masked]>
> To: Jouni Korhonen <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>