Miguel,

I don't think that RFC was taken into consideration in the original design,
and I'm not familiar with it. But, everything you propose sound very
reasonable.

I doubt I'll be able to host next week's meeting, but I'll send an email
the day before.

Regards,

Brady

On Fri, Jul 7, 2017, 19:11 Miguel Angel Muñoz <[email protected]>
wrote:

> Hi,
> thanks for the info. In any case if this gets done sooner or later SFC
> will follow SFC RFC 7655 [1], won't it?
>
>                  +---+ +---+ +---+     +---+ +---+ +---+
>                  |sf2| |sf2| |sf3|     |sf3| |sf4| |sf4|
>                  +---+ +---+ +---+     +---+ +---+ +---+
>                    |     |     |         |     |     |
>                    +-----+-----+         +-----+-----+
>                          |                     |
>                          +                     +
>              +----+    +----+     +----+     +----+    +----+
>    source+-->|sff1|+-->|sff2|+--->|sff3|+--->|sff4|+-->|sff5|+-->destination
>              +----+    +----+     +----+     +----+    +----+
>                +                    +                    +
>                |                    |                    |
>              +---+                +---+                +---+
>              |sf1|                |sf3|                |sf5|
>              +---+                +---+                +---+
>
>                          Figure 5: Load Balancing
>
>
> That is, the same service function (sf3) can be attached to different sffs
> and the traffic will be steered directly to each one. E.g. if a packet
> needs to reach sf3 it will be sent directly to sff4 and not go through sff2
> or sff3, correct?
>
> My impression is that it should be possible to add more SFs dynamically to
> a service chain (and not losing traffic). E.g. add another sf3 instance
> while traffic is already going through the service chain.
>
> I foresee this could be a big impact for development, 1 single experienced
> developer could take 2-3 months at least ¿opinions?
>
> I'll try to be at the weekly call next Wednesday if possible.
>
> Thanks,
> Best Regards,
> Miguel Ángel.
>
> [1] https://tools.ietf.org/html/rfc7665
>
>  On 07/07/17 12:43, Brady Johnson wrote:
>
> 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

Reply via email to