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

["Joel M. Halpern" <[e-mail]>]

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:
>
> "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:[e-mail]] 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);
> [e-mail] 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:[e-mail]] 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); [e-mail] 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:[e-mail]] 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);
> [e-mail] 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:[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
> _______________________________________________ sfc mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/sfc
>