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

[Ron Parker <[e-mail]>]

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:[e-mail]] 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); [e-mail]
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. 

It is good to mention this in section 6.

Lucy   

-----Original Message-----
From: sfc [mailto:[e-mail]] 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); [e-mail]
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:
> 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:[e-mail]] *代表 *Ken Gray (kegray)
> *发送时间:*2014年5月29日8:49
> *收件人:*Linda Dunbar
> *抄送:*Joel M. Halpern; Paul Quinn (paulq); [e-mail]
> *主题:*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" <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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] <#_msocom_1> 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:[e-mail]]
>     *Sent:* Wednesday, May 28, 2014 4:24 PM
>     *To:* Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *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 <[e-mail]
>     <mailto:[e-mail]>>
>     *Date: *Wednesday, May 28, 2014 3:34 PM
>     *To: *"Paul Quinn (paulq)" <[e-mail]
>     <mailto:[e-mail]>>, "Joel M. Halpern" <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>
>     *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
>
> ----------------------------------------------------------------------
> --
>
> 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
>
>
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>

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