Peri, There is indeed the concept of a Service Function Groups data model and a corresponding listener in the code base, but that code is way out of date. There never was a CSIT implemented for the functionality. It was implemented in Lithium and hasnt been maintained since. The original authors havent been heard from since Lithium. So effectively its dead code that should be removed. Also, as you mention, the SF Group was only on one SFF, which isnt an effective fail over nor load balancing design.
The main idea the Ericsson folks had for Load Balancing Service Functions was to use the Logical SFF to Load Balance across Service Functions that are located on different OVS bridges. Im sure if you ask internally, you can find the related studies and documents, since those were never published to the community. I dont have the resources to do this currently nor for Oxygen, and its out of scope for Nitrogen. If you're interested in moving this forward in the future, let us know and we can discuss it in a weekly call. Regards, Brady On Thu, Jul 6, 2017 at 7:54 AM Periyasamy Palanisamy < [email protected]> wrote: > Hi Brady, > > > > I would like to understand the gaps in implementing LB/FF/Replication > across service functions for netvirt classifiers. > > Looks like this is being realized using service-function-group by > associating it with SFP (or) RSP. > > In fact there is an event listener for service-function-group which > programs the group on a particular SFF (right now sfg is supported with > only one sff) . > > > > I think we need to address the following: > > 1. SF can be attached to any SFFs and corresponding groups should get > programmed in all SFFs in which RSP footprint is present. > 2. Honor service-function-group-name in RSP so that SFC OF pipeline > can be programmed to make use these groups for packet steering. > > > > Please let us know your thoughts about taking it forward. > > > > Thanks, > > Periyasamy > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Brady Johnson > *Sent:* Thursday, July 06, 2017 12:59 AM > *To:* Miguel Gonzalez <[email protected]>; > [email protected] > *Subject:* Re: [sfc-dev] Load Balancing > > > > Miguel, > > At one point the folks from Ericsson had plans for load balancing across > service functions once the logical service function forwarder was > implemented. > > They are no longer contributing to SFC, so I don't know of any concrete > plans to implement a load balancer. > > Regards, > > Brady > > > > On Wed, Jul 5, 2017, 16:18 Miguel Gonzalez <[email protected]> > wrote: > > Hi everyone, > > I would like to ask about status and plans for having load balancers > in a service chain. I have heard this was somehow in the roadmap but has > been put on hold. > > Will it support dynamic scaling of the Service Functions allocated > withing a group? I mean "scaling out": increasing the number of service > functions in the cluster without losing traffic within the service chain? > > Thanks, > Miguel. > > > > > > > *** Please note that this message and any attachments may contain > confidential and proprietary material and information and are intended only > for the use of the intended recipient(s). If you are not the intended > recipient, you are hereby notified that any review, use, disclosure, > dissemination, distribution or copying of this message and any attachments > is strictly prohibited. If you have received this email in error, please > immediately notify the sender and destroy this e-mail and any attachments > and all copies, whether electronic or printed. Please also note that any > views, opinions, conclusions or commitments expressed in this message are > those of the individual sender and do not necessarily reflect the views of > Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and > only a writing manually signed by Fortinet's General Counsel can be a > binding commitment of Fortinet to Fortinet's customers or partners. Thank > you. *** > > > _______________________________________________ > sfc-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > >
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
