Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 15 Dec 2014 15:14:47 +0000

Dear WG:

This note begins a 2-week WG LC on draft-ietf-sfc-long-lived-flow-use-cases.01.txt.

The document authors have indicated that they have addressed all known comments and that there are no open issues with the current version of the document.

Substantive comments to the list please, editorial comments can go directly to the document editors.

Jim & Thomas

---

From: Qin Wu <[email-masked]>
Date: Fri, 19 Dec 2014 02:42:46 +0000

Hi, authors:
I have read draft-ietf-sfc-long-lived-flow-use-cases-01. This draft discusses three use cases.
I can understand the first case and the third case, but I am not sure I understand the second case, i.e., CDN case.
Without service function chain, if we have a popular content that attracts a large number of users, we can
Choose one or several CDN caches that are close to the users, push that content to these CDN caches.

Now we have service function chain, if we have a popular content that is interest to a large number of users, we choose
to add a CDN cache to a service chain for that content, I am not sure how this case is related to service function chain?
If we have five popular movies that are interests to the users, we can add these five movies to the same CDN cache or distributed CDN caches that are close to the users,
Why should we retrieve popular movies from the service chain?
If we have five TV episodes and three popular movies, we also can add these different type of contents to the closest CDN cache, why should we bother the service function chain?
Do we need to form a service chain with a set of CDN caches that cache different type of contents?

When we say adding a CDN caches to a service chain, do we mean adding a new CDN caches to the existing service chain that comprises of a set of other type of service functions(e.g., firewall, DPI),
if the answer is yes, which position is the CDN cache inserted into the existing service function chain? In the middle of service function chain or at the end of service function chain?
In order to not break the existing service function chain, I think the service function that is preceding the CDN cache needs to know who is inserted after itself and the service function that is following the CDN cache need to know who is inserted before itself. This is something not clear in the use case.

Unlike the first case and the third case, in the second case, control plane application doesn’t need to inform SFC edge switch/router about the change to the existing service chain since it is still
a same service function chain. But control plane application needs to communicate with the service functions that is preceding the CDN cache and one that is following the CDN cache about forwarding change. Let me know if my understanding is correct.

Regards!
-Qin
发件人: sfc [mailto:[email-masked]] 代表 Jim Guichard (jguichar)
发送时间: 2014年12月15日 23:15
收件人: [email-masked]
主题: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Dear WG:

Jim & Thomas

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 20 Dec 2014 04:01:19 +0000

Comments:

1) Section 2 (Transparent firewall use case)

Comment> Firewalls have to look into the entire file to determine that there is no malicious content. For example if it's a zip file then firewall has to get the complete file, unzip, inspect all the files and then determine if the file is infected or not. It's not clear how FW determines a file is safe without inspecting its entire content.

2)
Section 2.1 (Event sequence)

   1. The firewall examines packets of a flow and deems that it is
     benign. This can be based on many factors such as

        a.  The packets are encrypted packets which cannot be decrypted
          and examined further

Comment> Bots(malware) communication is typically over an encrypted channel. Encryption does not necessarily mean that FW will skip inspection.

3)

Section 3 (Long-tail Content CDN Use Case)

Comment> Content could also be split into chunks (span of 2-3 minutes) and each chunk can also be downloaded using a different HTTP(S) connection. Long-lived content does not mean long-lived flow.

4)

Section 4 (IPsec Management in Mobile Environments)

Comment1> HTTP/2.0 uses TLS and how will the service provider perform DPI in such cases ?
Comment2> If traffic is encrypted then how is critical traffic identified ?
Comment3> Is eNodeB having multiple IPSEC tunnels with multiple SecGW ?
Comment4> Will eNodeB be dynamically programmed to forward traffic through different SecWG ?

-Tiru

---

From: Ramki Krishnan <[email-masked]>
Date: Sun, 21 Dec 2014 14:36:35 +0000

Hi Qin,

Please find inline.

Thanks,
Ramki

From: sfc [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Friday, December 19, 2014 8:13 AM
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Hi, authors:

Ramki: The scope of this draft is CDN caching in the presence of a service chain.

Ramki: The position of insertion in the service function chain is managed by SFC control plane application (this is typically specified by the user through a policy). This is true for other use cases too.

Ramki: Your statement is confusing. The chain needs to be manipulated for all the use cases.

Regards!
-Qin
发件人: sfc [mailto:[email-masked]] 代表 Jim Guichard (jguichar)
发送时间: 2014年12月15日 23:15
收件人: [email-masked]<mailto:[email-masked]>
主题: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Dear WG:

Jim & Thomas

---

From: Qin Wu <[email-masked]>
Date: Mon, 22 Dec 2014 02:47:38 +0000

发件人: Ramki Krishnan [mailto:[email-masked]]
发送时间: 2014年12月21日 22:37
收件人: Qin Wu; Jim Guichard (jguichar); [email-masked]
主题: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Hi Qin,

Please find inline.

Thanks,
Ramki

From: sfc [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Friday, December 19, 2014 8:13 AM
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Hi, authors:

[Qin]: If there is a content that is interest to more users, Why should we add a new CDN cache associated with this content into a service chain? Why not just simply add a new content to a existing CDN cache that is part of a service chain? Do you assume that the user only can retrieve content from a service chain?

[Qin]: In the CDN case, the SFC edge switch/router as Classifier doesn’t need to know whether or not you add a new service function into the existing service chain since traffic flow still corresponds to the same chain. But in the transparent firewall case and IPSEC Gateway case, the flow should be switched from one service chain to another new chain, the SFC edge switch/router MUST know binding change between the traffic flow and the service chain. Does this clarify?

Regards!
-Qin

Dear WG:

Jim & Thomas

---

From: Ramki Krishnan <[email-masked]>
Date: Mon, 22 Dec 2014 09:35:49 +0000

Please find inline.

Thanks,
Ramki

From: Qin Wu [mailto:[email-masked]]
Sent: Monday, December 22, 2014 8:18 AM
To: Ramki Krishnan; Jim Guichard (jguichar); [email-masked]
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

发件人: Ramki Krishnan [mailto:[email-masked]]
发送时间: 2014年12月21日 22:37
收件人: Qin Wu; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
主题: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Hi Qin,

Please find inline.

Thanks,
Ramki

Hi, authors:

[Qin]: If there is a content that is interest to more users, Why should we add a new CDN cache associated with this content into a service chain?

Why not just simply add a new content to a existing CDN cache that is part of a service chain?

Ramki1: This is exactly what is described. The presence/absence of a CDN cache in the service chain is on a long-lived content (or long-lived flow in the network) which dynamically switches from most popular to long-tail and vice versa. In essence, there are 2 service chains, one with the CDN cache and one without the CDN cache. This is described in detail in the Long-tail content CDN event sequence.

Do you assume that the user only can retrieve content from a service chain?
Ramki1: No. The assumption is that the user traffic is always subject to service chain processing.

Ramki1: You are mistaken in the CDN case. Please look at my previous answers and I would suggest you to carefully read section 3.1, the Long-tail content CDN event sequence.

Regards!
-Qin

Dear WG:

Jim & Thomas

---

From: Qin Wu <[email-masked]>
Date: Mon, 22 Dec 2014 10:42:34 +0000

Ramki:
please see inline.

Regards!
-Qin
发送时间: 2014年12月22日 17:36

Please find inline.

Thanks,
Ramki

From: Qin Wu [mailto:[email-masked]]
Sent: Monday, December 22, 2014 8:18 AM
To: Ramki Krishnan; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Hi Qin,

Please find inline.

Thanks,
Ramki

Hi, authors:

[Qin]: Really?, my confusion is you add one more new CDN cache into the service chain each time you identify new popular content and associate the content with that new CDN cache, but this is not true.
Also it is not clear in the text you maintain two service chains for the same traffic flow or the same content.
Step 2 of section 3.1 said you dynamically add a CDN Cache to the service chain for that content when the number of users viewing the same content exceeds a pre-programmed threshold
Step 3 of section 3.2 said you dynamically remove a CDN Cache from the service chain for the content when the number of users viewing the same content fall below a pre-programmed threshold.
I think the right rephrase is
“
when the number of users viewing the same content exceeds a pre-programmed threshold, switch to a service chain A that have a CDN cache which could cache that content.
When the number of users viewing the same content fall below a pre-programmed threshold, then switch to another service chain B that doesn’t have a CDN cache for that content but
has the same other service functions and also has the order of the other service functions as the service chain A.
“
From the current text in the step 2 and 3, it is not clear to me you are talking about the same service chain or two service chains, one is for popular content, one is for long tail content,
Or Maybe you are talking about four service chains, two are used to switch chain for poplar content, two are used to switch chain for long tail content.

[Qin]: maybe I misunderstand what it proposed in the CDN case, but I think CDN case did bring some confusing as I described above.

Regards!
-Qin

Dear WG:

Jim & Thomas

---

From: Qin Wu <[email-masked]>
Date: Mon, 22 Dec 2014 10:53:06 +0000

Ramki:
One additional comment is
Is a pre-programmed threshold in the step2 of section 3.1 same as the pre-programmed threshold in the step 3 of section 3.1?
I think section 3.1 describe two threshold value, one is for popular content, one is for long tailed content,
But from the current text, this is not clear.

Regards!
-Qin

Please find inline.

Thanks,
Ramki

Hi Qin,

Please find inline.

Thanks,
Ramki

Hi, authors:

Regards!
-Qin

Dear WG:

Jim & Thomas

---

From: Ramki Krishnan <[email-masked]>
Date: Mon, 22 Dec 2014 14:24:38 +0000

Sure, we will add some additional clarifying text to address your comments.

Thanks,
Ramki

From: Qin Wu [mailto:[email-masked]]
Sent: Monday, December 22, 2014 4:23 PM
To: Ramki Krishnan; Jim Guichard (jguichar); [email-masked]
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Ramki:

Regards!
-Qin

Please find inline.

Thanks,
Ramki

Hi Qin,

Please find inline.

Thanks,
Ramki

Hi, authors:

Regards!
-Qin

Dear WG:

Jim & Thomas