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

From: "Lizhong Jin" <[email-masked]>
Date: Mon, 5 Jan 2015 17:46:14 +0800

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.

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

[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?

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.

[Lizhong] actually I have similar understanding as Qin when reading section
3.1. The “service chain” in point 2 could be explained as the same
“service chain” implicitly said in point 1. We may change the description
of point 2 as below:

“the CDN Monitoring System instructs the SFC Control Plane Application to
dynamically establish the service chain with CDN cache for that content”

Regards

Lizhong

Regards!

-Qin

发件人: sfc [mailto:sfc-bounces at ietf.org <mailto:sfc-bounces%20at%20ietf.
org> ] 代表 Jim Guichard (jguichar)
发送时间: 2014年12月15日 23:15
收件人: sfc at ietf.org <mailto:sfc%20at%20ietf.org> 
主题: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

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: Ramki Krishnan <[email-masked]>
Date: Mon, 5 Jan 2015 10:15:18 +0000

Even in the second case, the SFC control plane application *does need* to inform the SFC edge switch/router about the change to the service chain. Perhaps the existing text does not express this aspect clearly. We will clarify this in the next revision of the document using text along the lines described below.

Event Sequence for CDN (modified version)

1. The CDN Monitoring System monitors the numbers of users and type of content being accessed. By default, we assume the CDN Cache is bypassed.
2.      If the number of users viewing the same content exceeds a pre-programmed up-threshold and the content is long-lived, the CDN Monitoring System instructs the SFC Control Plane Application to  dynamically switch from the existing service chain A to another service chain B which includes a CDN cache for caching the  content in addition to all of the service functions in service chain A in the same order. This is done by installing a rule for the flow corresponding to the content in the SFC edge switch/router.
3.      If the number of users viewing the same content falls below another pre-programmed down-threshold and the content is long-lived, the monitoring server instructs the SFC Control Plane Application to dynamically switch the flow from the existing service chain B (the one that was used in the previous event) to service chain A (again, which includes all of the service functions in service chain B other than the CDN cache). This is done by removing the previously installed rule for the flow corresponding to the content from the SFC edge switch/router.
Thanks,
Ramki

From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, January 05, 2015 3:16 PM
To: Ramki Krishnan
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

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.
Ramki: Your statement is confusing. The chain needs to be manipulated for all the use cases.
[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?
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.
[Lizhong] actually I have similar understanding as Qin when reading section 3.1. The “service chain” in point 2 could be explained as the same “service chain” implicitly said in point 1. We may change the description of point 2 as below:
“the CDN Monitoring System instructs the SFC Control Plane Application to dynamically establish the service chain with CDN cache for that content”

Regards
Lizhong

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

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: Ron Parker <[email-masked]>
Date: Mon, 5 Jan 2015 14:31:20 +0000

In order to effect dynamic changes in the service function chaining for long lived flows, there are 2 paradigms that come to mind.   One is that when a service function determines that it no longer needs to participate for a given flow, the flow is switched to a different service function chain (path) that does not include the affected service function.

An alternate paradigm is to consider that the affected service function is being dynamically bypassed – that is, the chain/path is still the same, but local state at the classifier and/or SFF’s manage the fact that the service function has withdrawn from the chain for that particular flow.    This second approach does indeed imply stateful SFF’s, but with the benefit of control plane simplification.     With this second approach, control plane involvement would be based on the desired level of optimization.    If it is sufficient that the packets continue to follow the original sequence of SFF’s, even though the SFF’s may no longer invoke any of their service function instances for that flow, then no control plane coordination is necessary.   If, however, it is desired even to avoid the “null” SFF’s for that flow, then coordination will be necessary.

In draft-zhang-sfc-sch-03, we include a “bypass” bit in the fixed portion of the SCH header to realize the second approach, above:

   B bit: The B (Bypass) bit, when set to 1, it is used by a Service
      Function to signal to its Service Function Forwarder that no
      further packets are to be sent to it for the flow specified in
      encapsulated packet.

Thanks.

    Ron

From: sfc [mailto:[email-masked]] On Behalf Of Ramki Krishnan
Sent: Monday, January 5, 2015 5:15 AM
To: Lizhong Jin
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, January 05, 2015 3:16 PM
To: Ramki Krishnan
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Regards
Lizhong

Regards!
-Qin

Dear WG:

Jim & Thomas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 05 Jan 2015 13:49:30 -0500

The bypass bit is clearly useful (which is why we already have a draft 
calling for it).  Thank you for including it in the SCH work.

There are clearly plenty of cases where that is not sufficient, and the 
control interactions will be needed to make the adjustments.

So I believe we need both tools.

Yours,
Joel

On 1/5/15 9:31 AM, Ron Parker wrote:
> In order to effect dynamic changes in the service function chaining for
> long lived flows, there are 2 paradigms that come to mind.   One is that
> when a service function determines that it no longer needs to
> participate for a given flow, the flow is switched to a different
> service function chain (path) that does not include the affected service
> function.
>
> An alternate paradigm is to consider that the affected service function
> is being dynamically bypassed – that is, the chain/path is still the
> same, but local state at the classifier and/or SFF’s manage the fact
> that the service function has withdrawn from the chain for that
> particular flow.    This second approach does indeed imply stateful
> SFF’s, but with the benefit of control plane simplification.     With
> this second approach, control plane involvement would be based on the
> desired level of optimization.    If it is sufficient that the packets
> continue to follow the original sequence of SFF’s, even though the SFF’s
> may no longer invoke any of their service function instances for that
> flow, then no control plane coordination is necessary.   If, however, it
> is desired even to avoid the “null” SFF’s for that flow, then
> coordination will be necessary.
>
> In draft-zhang-sfc-sch-03, we include a “bypass” bit in the fixed
> portion of the SCH header to realize the second approach, above:
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Ramki Krishnan
> *Sent:* Monday, January 5, 2015 5:15 AM
> *To:* Lizhong Jin
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01
>
> Even in the second case, the SFC control plane application **does need**
> to inform the SFC edge switch/router about the change to the service
> chain. Perhaps the existing text does not express this aspect clearly.
> We will clarify this in the next revision of the document using text
> along the lines described below.
>
> 1.The CDN Monitoring System monitors the numbers of users and type of
> content being accessed. By default, we assume the CDN Cache is bypassed.
>
> 2.If the number of users viewing the same content exceeds a
> pre-programmed up-threshold and the content is long-lived, the CDN
> Monitoring System instructs the SFC Control Plane Application to
> dynamically switch from the existing service chain A to another service
> chain B which includes a CDN cache for caching the  content in addition
> to all of the service functions in service chain A in the same order.
> This is done by installing a rule for the flow corresponding to the
> content in the SFC edge switch/router.
>
> 3.If the number of users viewing the same content falls below another
> pre-programmed down-threshold and the content is long-lived, the
> monitoring server instructs the SFC Control Plane Application to
> dynamically switch the flow from the existing service chain B (the one
> that was used in the previous event) to service chain A (again, which
> includes all of the service functions in service chain B other than the
> CDN cache). This is done by removing the previously installed rule for
> the flow corresponding to the content from the SFC edge switch/router.
>
> Thanks,
>
> Ramki
>
> *From:* Lizhong Jin [mailto:[email-masked]]
> *Sent:* Monday, January 05, 2015 3:16 PM
> *To:* Ramki Krishnan
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01
>
> 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
>
> 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.
>
> 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?
>
> 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.
>
> [Lizhong] actually I have similar understanding as Qin when reading
> section 3.1. The “service chain” in point 2 could be explained as the
> same “service chain” implicitly said in point 1. We may change the
> description of point 2 as below:
>
> “the CDN Monitoring System instructs the SFC Control Plane Application
> to dynamically establish the service chain with CDN cache for that content”
>
> Regards
>
> Lizhong
>
> Regards!
>
> -Qin
>
> *发件人**:*sfc [mailto:sfc-bounces at ietf.org
> <mailto:sfc-bounces%20at%20ietf.org>]*代表*Jim Guichard (jguichar)
> *发送时间:*2014年12月15日23:15
> *收件人:*sfc at ietf.org <mailto:sfc%20at%20ietf.org>
> *主题:*[sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01
>
> Dear WG:
>
> This note begins a 2-week WG LC on
> draft-ietf-sfc-long-lived-flow-use-cases.01.txt.
>
> comments and that there are no open issues with the current version of
> the document.
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Zarny, Myo" <[email-masked]>
Date: Tue, 6 Jan 2015 10:31:22 -0500

I get the use cases 1 and 3. I see the rationale for the CDN use case as well but I wonder how it’ll be done―if the use case is to insert a cache dynamically midstream during long-lived flows, as opposed to inserting the cache only for the new connections.

My questions are:

・         When you’re introducing the cache dynamically midstream, how would long-lived flows be handled? How does the (new) cache pick up where the original content server has just left off?

・         And are you assuming that the cache would have a VIP that represents the destination IP of the flows? I think it’ll have to since SFC can’t change the DNS cache of the client.

Myo

From: sfc [mailto:[email-masked]] On Behalf Of Ramki Krishnan
Sent: 5 January 2015 5:15 AM
To: Lizhong Jin
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Regards
Lizhong

Regards!
-Qin

Dear WG:

Jim & Thomas

---

From: Ramki Krishnan <[email-masked]>
Date: Sat, 10 Jan 2015 06:05:37 +0000

The CDN use case applies only for new flows; the existing flows follow the current service chain path. Additionally, the caching is transparent where the subscriber does not address the cache explicitly; it is not DNS based which is about telling the subscriber what VIP to use.

Thanks,
Ramki

From: Zarny, Myo [mailto:[email-masked]]
Sent: Tuesday, January 06, 2015 7:31 AM
To: Ramki Krishnan; 'Lizhong Jin'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

My questions are:

Myo

From: sfc [mailto:[email-masked]] On Behalf Of Ramki Krishnan
Sent: 5 January 2015 5:15 AM
To: Lizhong Jin
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Regards
Lizhong

Regards!
-Qin

Dear WG:

Jim & Thomas