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

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:jmh@joelhalpern.com] 
Sent: Thursday, May 29, 2014 9:23 AM
To: Lucy yong; Linda Dunbar; Paul Quinn (paulq)
Cc: sfc@ietf.org
Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

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

On 5/29/14, 10:04 AM, Lucy yong wrote:
> 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:sfc-bounces@ietf.org] 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: sfc@ietf.org
> 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:
>> 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,..."
>>
>> 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 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:sfc-bounces@ietf.org] *On Behalf Of *Linda Dunbar
>> *Sent:* Wednesday, May 28, 2014 4:50 PM
>> *To:* Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern
>> *Cc:* sfc@ietf.org
>> *Subject:* Re: [sfc] questions of "load balancing considerations" in 
>> the
>> draft-quinn-sfc-arch-05
>>
>> 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:kegray@cisco.com]
>> *Sent:* Wednesday, May 28, 2014 4:24 PM
>> *To:* Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
>> *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
>> *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 <linda.dunbar@huawei.com 
>> <mailto:linda.dunbar@huawei.com>>
>> *Date: *Wednesday, May 28, 2014 3:34 PM
>> *To: *"Paul Quinn (paulq)" <paulq@cisco.com 
>> <mailto:paulq@cisco.com>>, "Joel M. Halpern" <jmh@joelhalpern.com 
>> <mailto:jmh@joelhalpern.com>>
>> *Cc: *"sfc@ietf.org <mailto:sfc@ietf.org>" <sfc@ietf.org 
>> <mailto:sfc@ietf.org>>
>> *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
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>