Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 28 May 2014 21:24:15 +0000

+1 to Joel … the picture would be ugly at best.  We attempted a generic HA/LB slide to make a point and even it was ugly …such are the limitations of ASCII art.

In line …

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 28, 2014 3:34 PM
To: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Paul and Joel,

Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that SF1 is responsible for balancing traffic among the 3 instances of SF2, and SF3 is responsible for balancing traffic among the 3 instances of SF4?

<keg> Document text below the picture says "Either through an imbedded action in sf1 and sf3, or through external
control, the service functions sf2 and sf4 are elastically expanded and contracted dynamically."

Isn’t it a single point of failure?

<keg> Document text immediately subsequent to that picture and paragraph illustrates HA scenarios.

Some service functions are Stateful, i.e. they may require packets from same flows to traverse the same service function instance. For the Load Balancing scheme described by Figure 5, do you assume that SF1 and SF3 will be responsible for making sure that same flows go through the same service function instance?

<keg> Again, the aforementioned text deliberately allows this responsibility to be either imbedded in the elasticity-causing function or to be controlled externally or centrally.  We don't get into the mechanics as these can vary.  While stateful/bidirectional does add an additional burden, it can be accommodated without an explosion of discrete chains.  For example, it could be handled "at allocation time" if elasticity is managed via a separate entity and the individual allocations reflected through service chain control in the initial metadata bound to at the classification point in either direction.  OR, if the devices are working as a paired system (single vendor or ecosystem) with integrated elasticity, they could pass metadata between them when sf1 or sf3 does the initial dynamic allocation (affecting local forwarding on it's partner).  That's probably not an exhaustive list of ways to solve the problem.  8^)

<keg> The point of this section was that elasticity and HA should not cause an inordinate explosion of discrete chains without recommending a particular solution.  That is,  you shouldn't create unnecessary  complexity where it doesn't need to exist.

For the stateful service functions, if a flow is switched from SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize the states from SF-Instance-X. Who is responsible for those states maintenance for the Load Balancing described in Figure 5?

<keg> None of those entities exist in Figure 5.  Can you re-phrase your question from the figure?

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 28 May 2014 21:49:48 +0000

Joel, Eric, and Ken,

Thank you very much for the explanation.

Based on what you said, the description on how "control entity  push to the sf1 nodes ..." should be removed from the text, specifically:

"In this
   case, the control entity will push to the sf1 nodes, a table of
   sorts:[L1]  sf2 with a series of next hops, and if needed some weighted or
   other metrics (these could also be decided locally by some policy,
   but sf1 would need to be aware of expand/contract triggers and
   actions)."

Should also change the sentence after the Figure 5 to

"Either through an imbedded action in sf1 and sf3, the SFF nodes to which the multiple instances of SF2 or SF4 are attached, or through external
   control, the service functions sf2 and sf4 are elastically expanded
   and contracted dynamically."

Linda
From: Ken Gray (kegray) [mailto:[email-masked]]
Sent: Wednesday, May 28, 2014 4:24 PM
To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

+1 to Joel ... the picture would be ugly at best.  We attempted a generic HA/LB slide to make a point and even it was ugly ...such are the limitations of ASCII art.

In line ...

Paul and Joel,

Isn't it a single point of failure?

Linda

________________________________

 [L1]Require pushing policies to SF1 on how to load balance multiple instances of SF2.

SF1 may not have the capability to balance among multiple instances of SF2

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Thu, 29 May 2014 00:48:36 +0000

I don't see how you make the leap from the explanation of why it was irrelevant to go into more detail in the section to the elimination of the very generalized description accompanying the figure.  Please use your own argument to justify this and not infer any extra meaning from my answer to a different question.

As to the second change, i disagree.  Again, in general/broad strokes - from the drawing and the text, it is unlikely that any special action would be required on sf2 or sf4 - as they collapse in either direction to a single logical next hop.

Sent from my iPhone

On May 28, 2014, at 5:49 PM, "Linda Dunbar" <[email-masked]<mailto:[email-masked]>> wrote:

Joel, Eric, and Ken,

Based on what you said, the description on how “control entity  push to the sf1 nodes …” should be removed from the text, specifically:

“In this
   actions).”

“Either through an imbedded action in sf1 and sf3, the SFF nodes to which the multiple instances of SF2 or SF4 are attached, or through external
   control, the service functions sf2 and sf4 are elastically expanded
   and contracted dynamically.”

Linda
Cc: [email-masked]<mailto:[email-masked]>

In line …

Paul and Joel,

Linda

---

From: Qin Wu <[email-masked]>
Date: Thu, 29 May 2014 03:55:35 +0000

You are talking about service function scale up and down.
Since service node can host one or multiple service functions, why service node can not be used to control scale up or down of service functions it?
To avoid share risk failure, service node can be previous service node, e.g., it can be the one that hosts sf1 or sf3.
Also SFF is responsible for delivering traffic to any connected service functions, why not SFF can not be used to manage scale up or down of service function.
Also based on NFV MANO architecture, there is reference point between NFV and NFV manager, NFV manager also can control scale up or down of service function, I think this case has been covered by “through external control” in the draft.

Using sf1 that provide dedicated firewall service to provide load balancing functionality as well is a little bit weird to me.
Let me know if my understanding is correct?

Regards!
-Qin
发件人: sfc [mailto:[email-masked]] 代表 Ken Gray (kegray)
发送时间: 2014年5月29日 8:49
收件人: Linda Dunbar
抄送: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
主题: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Sent from my iPhone

“In this

Linda

In line …

Paul and Joel,

Linda

 Require pushing policies to SF1 on how to load balance multiple instances of SF2.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 29 May 2014 00:45:34 -0400

Ken,

I agree with Linda's second proposed change, because the control and
actions could be in sf1 and sf3, or they could be in SFF nodes that forward
packets from sf1 to sf2, and/or from sf3 to sf4.

Cheers,
Andy

On Wed, May 28, 2014 at 8:48 PM, Ken Gray (kegray) <[email-masked]> wrote:

>  I don't see how you make the leap from the explanation of why it was
> irrelevant to go into more detail in the section to the elimination of the
> very generalized description accompanying the figure.  Please use your own
> argument to justify this and not infer any extra meaning from my answer to
> a different question.
>
>  As to the second change, i disagree.  Again, in general/broad strokes -
> from the drawing and the text, it is unlikely that any special action would
> be required on sf2 or sf4 - as they collapse in either direction to a
> single logical next hop.
>
> Sent from my iPhone
>
> On May 28, 2014, at 5:49 PM, "Linda Dunbar" <[email-masked]>
> wrote:
>
>   Joel, Eric, and Ken,
>
>
>
> Based on what you said, the description on how “control entity  push to
> the sf1 nodes …” should be removed from the text, specifically:
>
>
>
> “In this
>
>    sorts:[L1] <#1464573527a48d1a__msocom_1>  sf2 with a series of next
> hops, and if needed some weighted or
>
> “Either through an imbedded action in sf1 and sf3, the SFF nodes to which
> the multiple instances of SF2 or SF4 are attached, or through external
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 29 May 2014 09:16:35 -0400

I am not following your question.
SFF can have a co-located load balancer.  Or the load balancer can be 
transparently behind the SFF, using any number of mechanisms.
We are not mandating where it is located.

Yours,
Joel

On 5/28/14, 11:55 PM, Qin Wu wrote:
> Since service node can host one or multiple service functions, why
> service node can not be used to control scale up or down of service
> functions it?
>
> To avoid share risk failure, service node can be previous service node,
> e.g., it can be the one that hosts sf1 or sf3.
>
> Also SFF is responsible for delivering traffic to any connected service
> functions, why not SFF can not be used to manage scale up or down of
> service function.
>
> Also based on NFV MANO architecture, there is reference point between
> NFV and NFV manager, NFV manager also can control scale up or down of
> service function, I think this case has been covered by “through
> external control” in the draft.
>
> Using sf1 that provide dedicated firewall service to provide load
> balancing functionality as well is a little bit weird to me.
>
> *发件人:*sfc [mailto:[email-masked]] *代表 *Ken Gray (kegray)
> *发送时间:*2014年5月29日8:49
> *收件人:*Linda Dunbar
> *抄送:*Joel M. Halpern; Paul Quinn (paulq); [email-masked]
> *主题:*Re: [sfc] questions of "load balancing considerations" in the
> draft-quinn-sfc-arch-05
>
> irrelevant to go into more detail in the section to the elimination of
> the very generalized description accompanying the figure.  Please use
> your own argument to justify this and not infer any extra meaning from
> my answer to a different question.
>
> from the drawing and the text, it is unlikely that any special action
> would be required on sf2 or sf4 - as they collapse in either direction
> to a single logical next hop.
>
> Sent from my iPhone
>
>
>     Based on what you said, the description on how “control entity  push
>     to the sf1 nodes …” should be removed from the text, specifically:
>
>     “In this
>
>         sorts:[L1] <#_msocom_1> sf2 with a series of next hops, and if
>     needed some weighted or
>
>     “Either through an imbedded action in sf1 and sf3, the SFF nodes to
>     which the multiple instances of SF2 or SF4 are attached, or through
>     external
>
>     *From:*Ken Gray (kegray) [mailto:[email-masked]]
>     *Sent:* Wednesday, May 28, 2014 4:24 PM
>     *To:* Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [sfc] questions of "load balancing considerations" in
>     the draft-quinn-sfc-arch-05
>
>     +1 to Joel … the picture would be ugly at best.  We attempted a
>     generic HA/LB slide to make a point and even it was ugly …such are
>     the limitations of ASCII art.
>
>     In line …
>
>     *From: *Linda Dunbar <[email-masked]
>     <mailto:[email-masked]>>
>     *Date: *Wednesday, May 28, 2014 3:34 PM
>     *To: *"Paul Quinn (paulq)" <[email-masked]
>     <mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *[sfc] questions of "load balancing considerations" in the
>     draft-quinn-sfc-arch-05
>
>     Paul and Joel,
>
>     Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume
>     that SF1 is responsible for balancing traffic among the 3 instances
>     of SF2, and SF3 is responsible for balancing traffic among the 3
>     instances of SF4?
>
>     <keg> Document text below the picture says "Either through an
>     imbedded action in sf1 and sf3, or through external
>
>     Some service functions are Stateful, i.e. they may require packets
>     from same flows to traverse the same service function instance. For
>     the Load Balancing scheme described by Figure 5, do you assume that
>     SF1 and SF3 will be responsible for making sure that same flows go
>     through the same service function instance?
>
>     <keg> Again, the aforementioned text deliberately allows this
>     responsibility to be either imbedded in the elasticity-causing
>     function or to be controlled externally or centrally.  We don't get
>     into the mechanics as these can vary.  While stateful/bidirectional
>     does add an additional burden, it can be accommodated without an
>     explosion of discrete chains.  For example, it could be handled "at
>     allocation time" if elasticity is managed via a separate entity and
>     the individual allocations reflected through service chain control
>     in the initial metadata bound to at the classification point in
>     either direction.  OR, if the devices are working as a paired system
>     (single vendor or ecosystem) with integrated elasticity, they could
>     pass metadata between them when sf1 or sf3 does the initial dynamic
>     allocation (affecting local forwarding on it's partner).  That's
>     probably not an exhaustive list of ways to solve the problem.  8^)
>
>     <keg> The point of this section was that elasticity and HA should
>     not cause an inordinate explosion of discrete chains without
>     recommending a particular solution.  That is,  you shouldn't create
>     unnecessary  complexity where it doesn't need to exist.
>
>     For the stateful service functions, if a flow is switched from
>     SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to
>     synchronize the states from SF-Instance-X. Who is responsible for
>     those states maintenance for the Load Balancing described in Figure 5?
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 29 May 2014 13:37:54 +0000

I agree with Linda's point.  The architecture should not direct to a particular solution.

Suggest replacing the paragraph  " Either through an imbedded action in sf1 and sf3, or through external control, the service functions sf2 and sf4 are elastically expanded and contracted dynamically.  This would be represented as one chain: s1->s2->s3->s4->s5,..."

with the following paragraph after figure 5.

Above figure would be represented as one chain: s1->s2->s3->s4->s5, but with multiple paths (not as a number of chains equal to the factorial combination of potential end-to-end paths). The service functions sf2 and sf4 may be elastically expanded and contracted dynamically. The load distribution decision toward sf2 and sf4 may be localized or be pushed from control entity into SFC network components or nodes. For example, s1, sff, or service node.

Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, May 28, 2014 4:50 PM
To: Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Joel, Eric, and Ken,

"In this

Linda

In line ...

Paul and Joel,

Linda

---

From: Lucy yong <[email-masked]>
Date: Thu, 29 May 2014 13:56:48 +0000

Hi Joel,

A load balancer is needed to support elastic expansion of a service function although a LB can be transparently to a SFC. 

It is good to mention this in section 6.

Lucy   

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Thursday, May 29, 2014 8:17 AM
To: Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

I am not following your question.
SFF can have a co-located load balancer.  Or the load balancer can be transparently behind the SFF, using any number of mechanisms.
We are not mandating where it is located.

Yours,
Joel

On 5/28/14, 11:55 PM, Qin Wu wrote:
> To avoid share risk failure, service node can be previous service 
> node, e.g., it can be the one that hosts sf1 or sf3.
>
> Also SFF is responsible for delivering traffic to any connected 
> service functions, why not SFF can not be used to manage scale up or 
> down of service function.
>
> As to the second change, i disagree.  Again, in general/broad strokes 
> - from the drawing and the text, it is unlikely that any special 
> action would be required on sf2 or sf4 - as they collapse in either 
> direction to a single logical next hop.
>
> Sent from my iPhone
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 29 May 2014 09:58:35 -0400

I do not know what you are trying to tell the reader by the "but with 
multiple paths" proposed text in your suggested replacement text.  The 
diagram is trying to show, and the text describes using a single service 
path.   You can also achieve the same effect with multiple paths.  Both 
approaches are currently supported by the architecture.

Yours,
Joel

On 5/29/14, 9:37 AM, Lucy yong wrote:
> I agree with Linda’s point.  The architecture should not direct to a
> particular solution.
>
> Suggest replacing the paragraph  “ Either through an imbedded action in
> sf1 and sf3, or through externalcontrol, the service functions sf2 and
> sf4 are elastically expandedand contracted dynamically.  This would be
> represented as one chain:s1->s2->s3->s4->s5,...”
>
> Above figure would be represented as one chain: s1->s2->s3->s4->s5, but
> with multiple paths (not as a number of chains equal to the factorial
> combination of potential end-to-end paths). The service functions sf2
> and sf4 may be elastically expandedand contracted dynamically. The load
> distribution decision toward sf2 and sf4 may be localized or be pushed
> from control entity into SFC network components or nodes. For example,
> s1, sff, or service node.
>
> Lucy
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Linda Dunbar
> *Sent:* Wednesday, May 28, 2014 4:50 PM
> *To:* Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern
> *Cc:* [email-masked]
> *Subject:* Re: [sfc] questions of "load balancing considerations" in the
> draft-quinn-sfc-arch-05
>
> Joel, Eric, and Ken,
>
> which the multiple instances of SF2 or SF4 are attached, or through external
>
> *Subject:* Re: [sfc] questions of "load balancing considerations" in the
> draft-quinn-sfc-arch-05
>
> +1 to Joel … the picture would be ugly at best.  We attempted a generic
> HA/LB slide to make a point and even it was ugly …such are the
> limitations of ASCII art.
>
> In line …
>
> *To: *"Paul Quinn (paulq)" <[email-masked] <mailto:[email-masked]>>,
> "Joel M. Halpern" <[email-masked] <mailto:[email-masked]>>
> that SF1 is responsible for balancing traffic among the 3 instances of
> SF2, and SF3 is responsible for balancing traffic among the 3 instances
> of SF4?
>
> <keg> Document text below the picture says "Either through an imbedded
> action in sf1 and sf3, or through external
>
> Some service functions are Stateful, i.e. they may require packets from
> same flows to traverse the same service function instance. For the Load
> Balancing scheme described by Figure 5, do you assume that SF1 and SF3
> will be responsible for making sure that same flows go through the same
> service function instance?
>
> responsibility to be either imbedded in the elasticity-causing function
> or to be controlled externally or centrally.  We don't get into the
> mechanics as these can vary.  While stateful/bidirectional does add an
> additional burden, it can be accommodated without an explosion of
> discrete chains.  For example, it could be handled "at allocation time"
> if elasticity is managed via a separate entity and the individual
> allocations reflected through service chain control in the initial
> metadata bound to at the classification point in either direction.  OR,
> if the devices are working as a paired system (single vendor or
> ecosystem) with integrated elasticity, they could pass metadata between
> them when sf1 or sf3 does the initial dynamic allocation (affecting
> local forwarding on it's partner).  That's probably not an exhaustive
> list of ways to solve the problem.  8^)
>
> <keg> The point of this section was that elasticity and HA should not
> cause an inordinate explosion of discrete chains without recommending a
> particular solution.  That is,  you shouldn't create unnecessary
>   complexity where it doesn't need to exist.
>
> SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize
> the states from SF-Instance-X. Who is responsible for those states
> maintenance for the Load Balancing described in Figure 5?
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 29 May 2014 14:04:43 +0000

Hi Joel,

I did not create that sentence. It is from current doc. please check.
IMO: it is a single SFC, but may be treated as one SFC path or multiple SFC paths depending on the solutions. Yes, the architecture should allow both.

Thanks,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, May 29, 2014 8:59 AM
To: Lucy yong; Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

I do not know what you are trying to tell the reader by the "but with multiple paths" proposed text in your suggested replacement text.  The diagram is trying to show, and the text describes using a single service 
path.   You can also achieve the same effect with multiple paths.  Both 
approaches are currently supported by the architecture.

Yours,
Joel

On 5/29/14, 9:37 AM, Lucy yong wrote:
> Suggest replacing the paragraph  " Either through an imbedded action 
> in
> represented as one chain:s1->s2->s3->s4->s5,..."
>
> Above figure would be represented as one chain: s1->s2->s3->s4->s5, 
> but with multiple paths (not as a number of chains equal to the 
> factorial combination of potential end-to-end paths). The service 
> functions sf2 and sf4 may be elastically expandedand contracted 
> dynamically. The load distribution decision toward sf2 and sf4 may be 
> localized or be pushed from control entity into SFC network components 
> or nodes. For example, s1, sff, or service node.
>
> Lucy
>
> Based on what you said, the description on how "control entity  push 
> to the sf1 nodes ..." should be removed from the text, specifically:
>
> "In this
>
> "Either through an imbedded action in sf1 and sf3, the SFF nodes to 
> +1 to Joel ... the picture would be ugly at best.  We attempted a 
> +generic
> HA/LB slide to make a point and even it was ugly ...such are the 
> SF2, and SF3 is responsible for balancing traffic among the 3 
> instances of SF4?
>
> explosion of discrete chains.  For example, it could be handled "at allocation time"
> metadata bound to at the classification point in either direction.  
> OR, if the devices are working as a paired system (single vendor or
> ecosystem) with integrated elasticity, they could pass metadata 
> between them when sf1 or sf3 does the initial dynamic allocation 
> (affecting local forwarding on it's partner).  That's probably not an 
> exhaustive list of ways to solve the problem.  8^)
>
> cause an inordinate explosion of discrete chains without recommending 
> a particular solution.  That is,  you shouldn't create unnecessary

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 29 May 2014 10:23:02 -0400

It looks like that text should be adjusted as you say.
Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 29 May 2014 14:24:42 +0000

Lucy,

Whether or not dynamic expansion requires a load balancer is specific to the architecture of that service function.   There are architectures that are internally load balanced.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, May 29, 2014 9:57 AM
To: Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi Joel,

Lucy   

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Thursday, May 29, 2014 8:17 AM
To: Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yours,
Joel

---

From: Eric Gray <[email-masked]>
Date: Thu, 29 May 2014 14:25:29 +0000

Linda,

	A few points:
1) probably better not to use MS Word (assuming that is what you used) to add 
comments to your mail (not sure many people will be able to read them); best
to simply include your comment(s) directly.
2) being careful about providing text to ensure that the right context is included
can help to understand your point.
3) your comments appear (as Ken pointed out in a separate response) not to be
     based on what any of us said; in fact, it looks like what you really mean is "based
     on my understanding of what you have said" as a way to make a separate (but
     related) point.

In your first point, a more complete context would be included if you quoted this:

"The load distribution decision will be localized (in general, although there might 
   be macro policy controlling that - which is out of scope for the sake of a simple 
   example).  In this case, the control entity will push to the sf1 nodes, a table of
   sorts: sf2 with a series of next hops, and if needed some weighted or other 
   metrics (these could also be decided locally by some policy, but sf1 would need 
   to be aware of expand/contract triggers and actions).  sf1 would use local logic -- 
   hash, state table, etc. -- to distribute the chained packets to sf2."

This is the entire paragraph, after the first two sentences.

I believe the issue with this text is that the authors have improperly parenthesized 
text, making the meaning of this paragraph self-contradictory and rather opaque
on first reading it.

In fact, grammatically speaking the entire paragraph is a mess - and that does not
help in understanding it.

The way I have puzzled it out, the text "[in] this case, the control entity will push
to the sf1 nodes, a table of [some sort: e.g.  - ] sf2 with a series of next hops, and 
[(if needed)] some weighted or other metrics" applies to the text in parentheses 
in the preceding sentence (i.e. - "in general, although there might be [a] macro 
policy controlling that - ...").  In other words, "this case" refers to the case where 
a macro policy is used to control the "local decision" process.

As you can see from the way I have hacked up the sentences in my effort to make
sense of them, and the amount of restructuring I think the text requires, it is my 
opinion that the text needs a major rework.

For one thing, the complex example given actually doesn't help and should not be
included.

Assuming I have the meaning correct, I would replace the quoted text above with:

"In the example shown in Figure 5, the load distribution decision for SF2 is localized 
  at SF1 (though the decision may be affected by a macro policy provided in some
 form by the control entity)."

The rest of the previous text only adds confusion as a result of over-stating the
example.

As a matter of personal preference, I would also use the word "embedded" as
the better-known spelling of the word "imbedded" used in the first sentence
(and possibly elsewhere in the draft).

I agree with Ken that your second suggested change is incorrect.

--
Eric

From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, May 28, 2014 5:50 PM
To: Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Joel, Eric, and Ken, 

Based on what you said, the description on how "control entity  push to the sf1 nodes ." should be removed from the text, specifically:

"In this
   case, the control entity will push to the sf1 nodes, a table of
   sorts:  sf2 with a series of next hops, and if needed some weighted or
   other metrics (these could also be decided locally by some policy,
   but sf1 would need to be aware of expand/contract triggers and
   actions)." 

Linda

+1 to Joel . the picture would be ugly at best.  We attempted a generic HA/LB slide to make a point and even it was ugly .such are the limitations of ASCII art.

In line .

From: Linda Dunbar <[email-masked]>
Date: Wednesday, May 28, 2014 3:34 PM
To: "Paul Quinn (paulq)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Paul and Joel, 

 

 

Linda

---

From: Lucy yong <[email-masked]>
Date: Thu, 29 May 2014 14:30:47 +0000

Joel,

Thanks.

Regarding transparency, it may be good to state that a LB may be transparently to a SFC or a SFC path. The former implies multiple SFC Paths; the latter is the single SFC path (of course a single SFC).

Lucy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, May 29, 2014 9:23 AM
To: Lucy yong; Linda Dunbar; Paul Quinn (paulq)
Cc: [email-masked]
Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

On 5/29/14, 10:04 AM, Lucy yong wrote:
>> sf4 are elastically expandedand contracted dynamically.  This would 
>> be represented as one chain:s1->s2->s3->s4->s5,..."
>>
>> localized or be pushed from control entity into SFC network 
>> components or nodes. For example, s1, sff, or service node.
>>
>> Lucy
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>
>> SF1 may not have the capability to balance among multiple instances 
>> of
>> SF2
>>
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 29 May 2014 14:39:27 +0000

Hi Ron,

I agree with what you said. If a service function dynamic expansion is implemented as completely internal, i.e. looks like one SF component in SFC networks, IMO: SFC architecture does not need step into that and just treat it as one SF instance in SFC networks. There are other scenarios where individual SF instances expose to the SFC network, SFC architecture needs to cover that.

Thanks,
Lucy

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, May 29, 2014 9:25 AM
To: Lucy yong; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: RE: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Lucy,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, May 29, 2014 9:57 AM
To: Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi Joel,

Lucy   

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Thursday, May 29, 2014 8:17 AM
To: Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yours,
Joel

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Thu, 29 May 2014 14:40:45 +0000

Yep, can see how it is a bit too "thick".  I'm okay with your suggested
simplification.

On 5/29/14 10:25 AM, "Eric Gray" <[email-masked]> wrote:

>other 
>Based on what you said, the description on how "control entity  push to
>the sf1 nodes ." should be removed from the text, specifically:
>
>"In this
>"Either through an imbedded action in sf1 and sf3, the SFF nodes to which
>+1 to Joel . the picture would be ugly at best.  We attempted a generic
>HA/LB slide to make a point and even it was ugly .such are the
>Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that
>SF1 is responsible for balancing traffic among the 3 instances of SF2,
>and SF3 is responsible for balancing traffic among the 3 instances of SF4?
>
>them when sf1 or sf3 does the initial dynamic allocation (affecting local
>forwarding on it's partner).  That's probably not an exhaustive list of
>ways to solve the problem.  8^)
>

---

From: Ron Parker <[email-masked]>
Date: Thu, 29 May 2014 14:49:04 +0000

Hi, Lucy.

I agree about the view of 1 service function vs. multiple service function instances.   In the latter case, perhaps we could describe it not as "service function expansion", but rather "service function instance selection".

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, May 29, 2014 10:39 AM
To: Ron Parker; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi Ron,

Thanks,
Lucy

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, May 29, 2014 9:25 AM
To: Lucy yong; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: RE: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Lucy,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, May 29, 2014 9:57 AM
To: Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi Joel,

Lucy   

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Thursday, May 29, 2014 8:17 AM
To: Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yours,
Joel

---

From: Sharon <[email-masked]>
Date: Thu, 29 May 2014 09:09:50 -0700

"the SFF nodes to which the multiple instances of SF2 or SF4 are attached"

Can't the SFF node make a load balancing decision on instances not attached to it?
In which case "the SFF node" is enough 

Location A                                                       Location B
Functions - SFF/NVE - Underlay - NVE/SFF - Functions

The load balancing KPI decisions (and the invariant that keeps states consistent)
May be known in Location A for SFs in location B where A/B are different racks or goes.
KPIs that are factored in can include both those of the Underlay network and the chain.

--szb

> On May 28, 2014, at 14:49, Linda Dunbar <[email-masked]> wrote:
> 
> Joel, Eric, and Ken,
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 29 May 2014 17:15:49 +0000

Eric and Ken:

The current text explicitly says " sf1 would use local logic --  hash, state table, etc. -- to distribute the chained packets to sf2.".  To me this is not generic description. Why it has to be sf1 to choose which instance of sf2 for the chain? What if the decision is on SFF node?

If you want to make the text generic, I suggest removing the text on how SF1 having local logic to choose SF2, like:

"In the example shown in Figure 5, the load distribution decision for SF2 can be localized at nodes to which SF2 is connected
(though the decision may be affected by a macro policy provided in some  form by the control entity)."

"The load distribution decision will be localized (in general, although there might
   be macro policy controlling that"

Linda

-----Original Message-----
From: Ken Gray (kegray) [mailto:[email-masked]]
Sent: Thursday, May 29, 2014 9:41 AM
To: Eric Gray; Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yep, can see how it is a bit too "thick".  I'm okay with your suggested simplification.

On 5/29/14 10:25 AM, "Eric Gray" <[email-masked]<mailto:[email-masked]>> wrote:

>Linda,
>
>       A few points:
>1) probably better not to use MS Word (assuming that is what you used)
>to add comments to your mail (not sure many people will be able to read
>them); best to simply include your comment(s) directly.
>2) being careful about providing text to ensure that the right context
>is included can help to understand your point.
>I believe the issue with this text is that the authors have improperly
>parenthesized text, making the meaning of this paragraph
>self-contradictory and rather opaque on first reading it.
>
>In fact, grammatically speaking the entire paragraph is a mess - and
>that does not help in understanding it.
>
>The way I have puzzled it out, the text "[in] this case, the control
>entity will push to the sf1 nodes, a table of [some sort: e.g.  - ] sf2
>with a series of next hops, and [(if needed)] some weighted or other
>metrics" applies to the text in parentheses in the preceding sentence
>(i.e. - "in general, although there might be [a] macro policy
>controlling that - ...").  In other words, "this case" refers to the
>case where a macro policy is used to control the "local decision"
>process.
>
>As you can see from the way I have hacked up the sentences in my effort
>to make sense of them, and the amount of restructuring I think the text
>requires, it is my opinion that the text needs a major rework.
>
>For one thing, the complex example given actually doesn't help and
>should not be included.
>
>  at SF1 (though the decision may be affected by a macro policy
>provided in some  form by the control entity)."
>
>The rest of the previous text only adds confusion as a result of
>over-stating the example.
>
>the better-known spelling of the word "imbedded" used in the first
>sentence (and possibly elsewhere in the draft).
>
>To: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern"
><[email-masked]<mailto:[email-masked]>>
>that
>action in sf1 and sf3, or through external control, the service
>functions sf2 and sf4 are elastically expanded and contracted
>dynamically."
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 29 May 2014 17:33:11 +0000

Hi Ron,

Agree. Hope that editors address that in next version.

In addition, the word "node" is used many times and inconsistently in current version. Hope that will be fixed as well.

Thanks,
Lucy

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, May 29, 2014 9:49 AM
To: Lucy yong; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: RE: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi, Lucy.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, May 29, 2014 10:39 AM
To: Ron Parker; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi Ron,

Thanks,
Lucy

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, May 29, 2014 9:25 AM
To: Lucy yong; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: RE: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Lucy,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, May 29, 2014 9:57 AM
To: Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi Joel,

Lucy   

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Thursday, May 29, 2014 8:17 AM
To: Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 29 May 2014 18:25:12 +0000

It would be so much easier to formally introduce the concept of "Service Function Instance" in SFC. For example:

"Service Function Instance: One instantiation of a service function.
One service function could have multiple identical instances.
 
For a service function with different functional instantiations, e.g. one instantiation applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), they are considered as two different service functions."

Some Service Function Instances are visible to Service Chain Path. Sometimes a collection of service function instances can appear as one single entity to the Service Chain Path."

Linda 

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, May 29, 2014 9:49 AM
To: Lucy yong; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: RE: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi, Lucy.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, May 29, 2014 10:39 AM
To: Ron Parker; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi Ron,

Thanks,
Lucy

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, May 29, 2014 9:25 AM
To: Lucy yong; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: RE: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Lucy,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, May 29, 2014 9:57 AM
To: Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi Joel,

Lucy   

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Thursday, May 29, 2014 8:17 AM
To: Qin Wu; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 29 May 2014 15:48:20 -0400

I am not at all sure I am following your diagram.
An SFF is concerned with forwarding packets to (and handling packets 
from) its attached SFs.  If you want the SFF to also affect downstream 
processing, for example by changing the service path the packet is on, 
then you need a classifier co-located with the SFF.

Yours,
Joel

On 5/29/14, 12:09 PM, Sharon wrote:
> On May 28, 2014, at 14:49, Linda Dunbar <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Joel, Eric, and Ken,
>>
>> generic HA/LB slide to make a point and even it was ugly …such are the
>> the individual allocations reflected through service chain control in
>> the initial metadata bound to at the classification point in either
>> direction.  OR, if the devices are working as a paired system (single
>> vendor or ecosystem) with integrated elasticity, they could pass
>> metadata between them when sf1 or sf3 does the initial dynamic
>> [L1] <#_msoanchor_1>Require pushing policies to SF1 on how to load
>> balance multiple instances of SF2.
>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 29 May 2014 15:57:43 -0400

the problem I have with the definition you propose for Service Function 
Instance is that what is an instance will depend upon where you look.
What management, and particularly what virtual machine monitoring and 
management, sees as an instance has to be a single image running on a 
single VM.
But what Service Chaining sees as an instance may be one such thing, or 
may be a cluster of such things organized in such a way as to present a 
single view to the service chaining infrastructure.

Thus, trying to define Service Function Instance, and then talk 
explicitly about such instances in service chaining, gets very 
difficult.  We are likely to end up with a definition that says that a 
service function instance may be made up of multiple software instances. 
  Such a definition seems likely to cause more confusion than it solves.

If we can come up with a definition that allows for the range of 
deployments, and does not itself further confuse the readers, then I am 
happy to add such a term definition and usage in the document.

Yours,
Joel

On 5/29/14, 2:25 PM, Linda Dunbar wrote:
> It would be so much easier to formally introduce the concept of
> "Service Function Instance" in SFC. For example:
>
> For a service function with different functional instantiations, e.g.
> one instantiation applies policy-set-A (NAT44-A) and other applies
> policy-set-B (NAT44-B), they are considered as two different service
> functions."
>
> Some Service Function Instances are visible to Service Chain Path.
> Sometimes a collection of service function instances can appear as
> one single entity to the Service Chain Path."
>
>
> Linda
>
>
>
>
> -----Original Message----- From: Ron Parker
> [mailto:[email-masked]] Sent: Thursday, May 29, 2014
> 9:49 AM To: Lucy yong; Joel Halpern Direct; Qin Wu; Ken Gray
> (kegray); Linda Dunbar Cc: Joel M. Halpern; Paul Quinn (paulq);
> [email-masked] Subject: RE: [sfc] 答复: questions of "load balancing
> considerations" in the draft-quinn-sfc-arch-05
>
> Hi, Lucy.
>
> I agree about the view of 1 service function vs. multiple service
> function instances.   In the latter case, perhaps we could describe
> it not as "service function expansion", but rather "service function
> instance selection".
>
> Ron
>
>
> -----Original Message----- From: sfc [mailto:[email-masked]] On
> Behalf Of Lucy yong Sent: Thursday, May 29, 2014 10:39 AM To: Ron
> Parker; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar
> Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked] Subject: Re:
> [sfc] 答复: questions of "load balancing considerations" in the
> draft-quinn-sfc-arch-05
>
> Hi Ron,
>
> I agree with what you said. If a service function dynamic expansion
> is implemented as completely internal, i.e. looks like one SF
> component in SFC networks, IMO: SFC architecture does not need step
> into that and just treat it as one SF instance in SFC networks. There
> are other scenarios where individual SF instances expose to the SFC
> network, SFC architecture needs to cover that.
>
> Thanks, Lucy
>
> -----Original Message----- From: Ron Parker
> [mailto:[email-masked]] Sent: Thursday, May 29, 2014
> 9:25 AM To: Lucy yong; Joel Halpern Direct; Qin Wu; Ken Gray
> (kegray); Linda Dunbar Cc: Joel M. Halpern; Paul Quinn (paulq);
> [email-masked] Subject: RE: [sfc] 答复: questions of "load balancing
> considerations" in the draft-quinn-sfc-arch-05
>
> Lucy,
>
> Whether or not dynamic expansion requires a load balancer is specific
> to the architecture of that service function.   There are
> architectures that are internally load balanced.
>
> Ron
>
>
> -----Original Message----- From: sfc [mailto:[email-masked]] On
> Behalf Of Lucy yong Sent: Thursday, May 29, 2014 9:57 AM To: Joel
> Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar Cc: Joel M.
> Halpern; Paul Quinn (paulq); [email-masked] Subject: Re: [sfc] 答复:
> questions of "load balancing considerations" in the
> draft-quinn-sfc-arch-05
>
> Hi Joel,
>
> A load balancer is needed to support elastic expansion of a service
> function although a LB can be transparently to a SFC.
>
> -----Original Message----- From: sfc [mailto:[email-masked]] On
> Behalf Of Joel Halpern Direct Sent: Thursday, May 29, 2014 8:17 AM
> To: Qin Wu; Ken Gray (kegray); Linda Dunbar Cc: Joel M. Halpern; Paul
> Quinn (paulq); [email-masked] Subject: Re: [sfc] 答复: questions of "load
> balancing considerations" in the draft-quinn-sfc-arch-05
>
> I am not following your question. SFF can have a co-located load
> balancer.  Or the load balancer can be transparently behind the SFF,
> using any number of mechanisms. We are not mandating where it is
> located.
>
> Yours, Joel
>
>> service node can not be used to control scale up or down of
>> service functions it?
>>
>> service functions, why not SFF can not be used to manage scale up
>> or down of service function.
>>
>> Also based on NFV MANO architecture, there is reference point
>> between NFV and NFV manager, NFV manager also can control scale up
>> or down of service function, I think this case has been covered by
>> “through external control” in the draft.
>>
>> *发件人:*sfc [mailto:[email-masked]] *代表 *Ken Gray (kegray) *发送时
>> 间:*2014年5月29日8:49 *收件人:*Linda Dunbar *抄送:*Joel M. Halpern; Paul
>> Quinn (paulq); [email-masked] *主题:*Re: [sfc] questions of "load
>> balancing considerations" in the draft-quinn-sfc-arch-05
>>
>> I don't see how you make the leap from the explanation of why it
>> was irrelevant to go into more detail in the section to the
>> elimination of the very generalized description accompanying the
>> figure.  Please use your own argument to justify this and not infer
>> any extra meaning from my answer to a different question.
>>
>> As to the second change, i disagree.  Again, in general/broad
>> strokes - from the drawing and the text, it is unlikely that any
>> special action would be required on sf2 or sf4 - as they collapse
>> in either direction to a single logical next hop.
>>
>> Sent from my iPhone
>>
>>
>> On May 28, 2014, at 5:49 PM, "Linda Dunbar"
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Joel, Eric, and Ken,
>>
>> Based on what you said, the description on how “control entity
>> push to the sf1 nodes …” should be removed from the text,
>> specifically:
>>
>> “In this
>>
>> “Either through an imbedded action in sf1 and sf3, the SFF nodes
>> to which the multiple instances of SF2 or SF4 are attached, or
>> through external
>>
>> *From:*Ken Gray (kegray) [mailto:[email-masked]] *Sent:*
>> Wednesday, May 28, 2014 4:24 PM *To:* Linda Dunbar; Paul Quinn
>> (paulq); Joel M. Halpern *Cc:* [email-masked] <mailto:[email-masked]>
>> *Subject:* Re: [sfc] questions of "load balancing considerations"
>> in the draft-quinn-sfc-arch-05
>>
>> <mailto:[email-masked]>> *Date: *Wednesday, May 28, 2014
>> 3:34 PM *To: *"Paul Quinn (paulq)" <[email-masked]
>> <mailto:[email-masked]>> *Cc: *"[email-masked]
>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> *Subject: *[sfc] questions of "load balancing considerations" in
>> Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05)
>> assume that SF1 is responsible for balancing traffic among the 3
>> instances of SF2, and SF3 is responsible for balancing traffic
>> among the 3 instances of SF4?
>>
>> from same flows to traverse the same service function instance.
>> For the Load Balancing scheme described by Figure 5, do you assume
>> that SF1 and SF3 will be responsible for making sure that same
>> flows go through the same service function instance?
>>
>> function or to be controlled externally or centrally.  We don't
>> get into the mechanics as these can vary.  While
>> stateful/bidirectional does add an additional burden, it can be
>> accommodated without an explosion of discrete chains.  For example,
>> it could be handled "at allocation time" if elasticity is managed
>> via a separate entity and the individual allocations reflected
>> through service chain control in the initial metadata bound to at
>> the classification point in either direction.  OR, if the devices
>> are working as a paired system (single vendor or ecosystem) with
>> integrated elasticity, they could pass metadata between them when
>> sf1 or sf3 does the initial dynamic allocation (affecting local
>> forwarding on it's partner).  That's probably not an exhaustive
>> recommending a particular solution.  That is,  you shouldn't
>> create unnecessary  complexity where it doesn't need to exist.
>>
>> ----------------------------------------------------------------------
>>
>>
--
>> of SF2
>> _______________________________________________ sfc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>
>
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 29 May 2014 16:06:03 -0400

Joel,

I disagree, I really don't see it as confusing at all. We're all in
agreement that there will be cases where a service function is split among
multiple hardware and/or software entities that can work in parallel, or
else there wouldn't be a section on load sharing. How else would one
describe these entities if not as "Service Function Instances"?

Cheers,
Andy

On Thu, May 29, 2014 at 3:57 PM, Joel M. Halpern <[email-masked]>wrote:

> Thus, trying to define Service Function Instance, and then talk explicitly
> about such instances in service chaining, gets very difficult.  We are
> likely to end up with a definition that says that a service function
> instance may be made up of multiple software instances.  Such a definition
> seems likely to cause more confusion than it solves.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 29 May 2014 16:13:29 -0400

If the service chain splits, that is one case.
But it is also quite acceptable and within what has been discussed for 
the service chain (or more specifically the service path) not to split 
at all.  Rather, what hangs off of the SFF is a suitable load balancer 
(or balancers) and multiple service function instances.  That balancing 
is not visible to service chaining (although it is certainly visible to 
management.  The point of such a deployment is that there is no change 
to the service paths as that collective service function scales in or 
out as direct by management, or as caused by failures, or ...

If we insist that the service paths within such a deployment are 
different, we are requiring larger scale visiblity of such events.

Yours,
Joel

On 5/29/14, 4:06 PM, Andrew G. Malis wrote:
> agreement that there will be cases where a service function is split
> among multiple hardware and/or software entities that can work in
> parallel, or else there wouldn't be a section on load sharing. How else
> would one describe these entities if not as "Service Function Instances"?
>
> Cheers,
> Andy
>
> On Thu, May 29, 2014 at 3:57 PM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     the problem I have with the definition you propose for Service
>     Function Instance is that what is an instance will depend upon where
>     you look.
>     What management, and particularly what virtual machine monitoring
>     and management, sees as an instance has to be a single image running
>     on a single VM.
>     But what Service Chaining sees as an instance may be one such thing,
>     or may be a cluster of such things organized in such a way as to
>     present a single view to the service chaining infrastructure.
>
>     difficult.  We are likely to end up with a definition that says that
>     a service function instance may be made up of multiple software
>     instances.  Such a definition seems likely to cause more confusion
>     than it solves.
>
>     deployments, and does not itself further confuse the readers, then I
>     am happy to add such a term definition and usage in the document.
>
>     Yours,
>     Joel
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 29 May 2014 16:24:24 -0400

Joel,

I think we're in violent agreement. There's no insistence that the multiple
instances need to be visible to the service chain path, indeed Linda's
definition includes "Some Service Function Instances are visible to Service
Chain Path. Sometimes a collection of service function instances can appear
as one single entity to the Service Chain Path." This part o the definition
might be better and more simply phrased as "A collection of Service
Function Instances may appear as one entity or as multiple entities in the
Service Chain Path."

Cheers,
Andy

On Thu, May 29, 2014 at 4:13 PM, Joel M. Halpern <[email-masked]>wrote:

> But it is also quite acceptable and within what has been discussed for the
> service chain (or more specifically the service path) not to split at all.
>  Rather, what hangs off of the SFF is a suitable load balancer (or
> balancers) and multiple service function instances.  That balancing is not
> visible to service chaining (although it is certainly visible to
> management.  The point of such a deployment is that there is no change to
> the service paths as that collective service function scales in or out as
> direct by management, or as caused by failures, or ...
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 29 May 2014 16:27:17 -0400

In that case, there would seem to be very few places, if any, in the 
document where we would use the term Service Function Instance.

Yours,
Joel

On 5/29/14, 4:24 PM, Andrew G. Malis wrote:
> Joel,
>
> I think we're in violent agreement. There's no insistence that the
> multiple instances need to be visible to the service chain path, indeed
> Linda's definition includes "Some Service Function Instances are visible
> to Service Chain Path. Sometimes a collection of service function
> instances can appear as one single entity to the Service Chain Path."
> This part o the definition might be better and more simply phrased as "A
> collection of Service Function Instances may appear as one entity or as
> multiple entities in the Service Chain Path."
>
> Cheers,
> Andy
>
>
> On Thu, May 29, 2014 at 4:13 PM, Joel M. Halpern <[email-masked]
>     But it is also quite acceptable and within what has been discussed
>     for the service chain (or more specifically the service path) not to
>     split at all.  Rather, what hangs off of the SFF is a suitable load
>     balancer (or balancers) and multiple service function instances.
>       That balancing is not visible to service chaining (although it is
>     certainly visible to management.  The point of such a deployment is
>     that there is no change to the service paths as that collective
>     service function scales in or out as direct by management, or as
>     caused by failures, or ...
>
>         On Thu, May 29, 2014 at 3:57 PM, Joel M. Halpern
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                  For a service function with different functional
>         instantiations,
>                  e.g.
>         _________________________________________________
>         sfc mailing list
>         https://www.ietf.org/mailman/__listinfo/sfc
>         <https://www.ietf.org/mailman/listinfo/sfc>
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 29 May 2014 16:45:00 -0400

Joel,

Again, we're in agreement. It would most likely be confined to sections 1.2
(initial definition) and 6 (load balancing).

Cheers,
Andy

---

From: Sharon <[email-masked]>
Date: Thu, 29 May 2014 14:32:50 -0700

Yes, I guess you are right Joel.
I assumed load-balancing inherently has classification ability.
Otherwise the chain hop is statically circuited, no HA/LB.
--szb

> On May 29, 2014, at 12:48, Joel Halpern Direct <[email-masked]> wrote:
> 
> An SFF is concerned with forwarding packets to (and handling packets from) its attached SFs.  If you want the SFF to also affect downstream processing, for example by changing the service path the packet is on, then you need a classifier co-located with the SFF.
> 
> Yours,
> Joel
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 30 May 2014 03:27:26 +0000

Hi, Joel:
Thank for your clarification. 
if load balancer is really needed and it is not a service function in the chain, I agree we should not mandate its location.
So the following description in the draft is very restrictive
"
Either through an imbedded action in sf1 and sf3, or through external
control
"
It seems excluding having load balancer on the SFF.
Also if  sf1 requires load balancer and sf1 itself provides firewall treatment,
It looks one sf supports two different treatments, one is firewall, the other is load balancer.

However if we move load balancer functionality to SFF or other box, it seems reasonable.
So the question is can one service function provide more than one service or treatment?

I may miss the earlier discussion, please correct me if I am wrong.

Regards!
-Qin
-----邮件原件-----
发件人: Joel Halpern Direct [mailto:[email-masked]] 
发送时间: 2014年5月29日 21:17
收件人: Qin Wu; Ken Gray (kegray); Linda Dunbar
抄送: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
主题: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Fri, 30 May 2014 13:40:47 +0000

Qin,

Regarding your question:

A service function can be thought of as a logical construct.   More than one such service function could be co-located at the same locator (i.e., IP address).   I.e., a single management entity with a single IP address could provide multiple service functions simultaneously.   In cases where the single managed entity was asked to perform multiple service functions that were consecutive in the service chain, as an optimization it should not be necessary to return the traffic to the SFF in between those service functions. 

Another aspect of your question was can the same logical service function provide more than one treatment?    There are at least 3 approaches to this.   In the first, each differentiated behavior is represented as a distinct logical service function -- i.e., content_filter_adult, content_filter_child.   In the second approach, a single service function (i.e., content_filter) has its own private mechanism to determine which behavior to apply (i.e., a mirrored RADIUS feed teaches it subscriber properties related to subscriber IP addresses).   A third approach is that the service function controller inserts metadata to the packet stream that the service function can interpret for purposes of providing a differentiated behavior (i.e., subscriber_type=child).

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, May 29, 2014 11:27 PM
To: Joel Halpern Direct; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: [sfc] 答复: 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi, Joel:
Thank for your clarification. 
if load balancer is really needed and it is not a service function in the chain, I agree we should not mandate its location.
So the following description in the draft is very restrictive "
Either through an imbedded action in sf1 and sf3, or through external control "
It seems excluding having load balancer on the SFF.
Also if  sf1 requires load balancer and sf1 itself provides firewall treatment, It looks one sf supports two different treatments, one is firewall, the other is load balancer.

Regards!
-Qin
-----邮件原件-----
发件人: Joel Halpern Direct [mailto:[email-masked]]
发送时间: 2014年5月29日 21:17
收件人: Qin Wu; Ken Gray (kegray); Linda Dunbar
抄送: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
主题: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yours,
Joel

---

From: Qin Wu <[email-masked]>
Date: Sat, 31 May 2014 01:08:20 +0000

Hi, Ron:
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
发送时间: 2014年5月30日 21:41
收件人: Qin Wu; Joel Halpern Direct; Ken Gray (kegray); Linda Dunbar
抄送: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
主题: Re: [sfc] 答复: 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Qin,

Regarding your question:

[Qin]: Yes, If one SFF hosts two service functions and these two service functions are consecutive in the same service chain, Sure, the traffic doesn't need to be returned to the SFF for each of service functions that are collocated at SFF. I fully agree.

[Qin]: My question actually is: Can firewall service function provide load balancer service?
In your example approaches, it looks a differentiated behaviors provided by one service function are quite similar, e.g., content_filer_adult and content_filer_child, both are content filer service.
I am wondering can one HTTP optimization service function providing differentiate behaviors also support load balancer service? Can two service functions providing different service and embedded in the same network element be combined into one service function?
If the answer is yes, the definition of service function in the problem statement draft needs to be revisited and changed since service function can be responsible for more than one treatments and each treatment provide different service.
"
I don't think this is correct.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, May 29, 2014 11:27 PM
To: Joel Halpern Direct; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: [sfc] 答复: 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi, Joel:

Regards!
-Qin
-----邮件原件-----
发件人: Joel Halpern Direct [mailto:[email-masked]]
发送时间: 2014年5月29日 21:17
收件人: Qin Wu; Ken Gray (kegray); Linda Dunbar
抄送: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
主题: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yours,
Joel

---

From: Qin Wu <[email-masked]>
Date: Sat, 31 May 2014 01:24:24 +0000

One point to add, in case several SFs are co-located in the same node or SFF, the packet is processed by
all SFs in the SFF, Once the packet is successfully handled by one SF, the packet is forwarded
to the next SF that is in the same SFF.

Regards!
-Qin
-----邮件原件-----
发件人: Qin Wu 
发送时间: 2014年5月31日 9:08
收件人: 'Ron Parker'; Joel Halpern Direct; Ken Gray (kegray); Linda Dunbar
抄送: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
主题: 答复: [sfc] 答复: 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi, Ron:
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
发送时间: 2014年5月30日 21:41
收件人: Qin Wu; Joel Halpern Direct; Ken Gray (kegray); Linda Dunbar
抄送: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
主题: Re: [sfc] 答复: 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Qin,

Regarding your question:

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, May 29, 2014 11:27 PM
To: Joel Halpern Direct; Ken Gray (kegray); Linda Dunbar
Cc: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
Subject: [sfc] 答复: 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Hi, Joel:

Regards!
-Qin
-----邮件原件-----
发件人: Joel Halpern Direct [mailto:[email-masked]]
发送时间: 2014年5月29日 21:17
收件人: Qin Wu; Ken Gray (kegray); Linda Dunbar
抄送: Joel M. Halpern; Paul Quinn (paulq); [email-masked]
主题: Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yours,
Joel