[sfc-dev] [groupbasedpolicy-dev] GBP/SFC Loadbalance

Reinaldo Penno rapenno at gmail.com
Fri Aug 7 15:31:52 UTC 2015


The distinction is in the IETF document.

   Service Function Path (SFP):  The Service Function Path is a
        constrained specification of where packets assigned to a certain
        service function path must go.  While it may be so constrained
        as to identify the exact locations, it can also be less
        specific.  The SFP provides a level of indirection between the
        fully abstract notion of service chain as a sequence of abstract
        service functions to be delivered, and the fully specified
        notion of exactly which SFF/SFs the packet will visit when it
        actually traverses the network.  By allowing the control
        components to specify this level of indirection, the operator
        may control the degree of SFF/SF selection authority that is
        delegated to the network.

   Rendered Service Path (RSP):  Within an SFP, packets themselves are
        of course transmitted from and to specific places in the
        network, visiting a specific sequence of SFFs and SFs.  This
        sequence of actual visits by a packet to specific SFFs and SFs
        in the network is known as the Rendered Service Path (RSP).
        This definition is included here for use by later documents,




Halpern & Pignataro     Expires January 25, 2016                [Page 6]

  <https://tools.ietf.org/html/draft-ietf-sfc-architecture-11#page-7>
Internet-Draft              SFC Architecture                   July 2015


        such as when solutions may need to discuss the actual sequence
        of locations the packets visit.

From:  Keith Burns <alagalah at gmail.com>
Date:  Friday, August 7, 2015 at 3:29 AM
To:  Joel Halpern <joel.halpern at ericsson.com>
Cc:  opendaylight sfc <sfc-dev at lists.opendaylight.org>,
<groupbasedpolicy-dev at lists.opendaylight.org>
Subject:  Re: [sfc-dev] [groupbasedpolicy-dev] GBP/SFC Loadbalance


Joel,

I agree 100% with you. It was never clear to me why there is a distinction
between SFP and RSP.

Surely it isn't for in chain path based load balancing, because that would
mean that deep in the chain an SFF would have to know the classifier policy
rules, and that makes no sense.

I'm also confused as to the role of the SFG. Surely this, if it's for SF
pooling abstraction, should be handled by a SF mgr (VNFM) or a front end
abstraction handled by the SF itself.

I'm all for simplicity. The less moving bits and bespoke additions to the
core models for corner cases the better.

 

On Aug 3, 2015 11:25 AM, "Joel Halpern" <joel.halpern at ericsson.com> wrote:
> 1)     Service Function Paths are uni-directional.  They may be paired, with a
> symmetry requirement between them, for traffic in opposite directions.  While
> some deployments may use the same device for ingress and egress, that is not
> required by anything I have seen in our work.
> 
> 2)     What does it take to get the distinction between SFP and RSP clear?
> What GBP gets is not the RSP.  It is the SFP.  If the code currently calls it
> the RSP, what does it take to change that?  Leaving it as RSP will cause a LOT
> of confusion down the road.
> 
>  
> Yours,
> Joel
>  
> From: sfc-dev-bounces at lists.opendaylight.org
> [mailto:sfc-dev-bounces at lists.opendaylight.org] On Behalf Of Keith Burns
> Sent: Saturday, August 01, 2015 2:49 PM
> To: Ruijing Guo
> Cc: sfc-dev at lists.opendaylight.org;
> groupbasedpolicy-dev at lists.opendaylight.org
> Subject: Re: [sfc-dev] [groupbasedpolicy-dev] GBP/SFC Loadbalance
>  
> Tail NSH is important, and I don't believe RSPs can be bidirectional.
> 
> On Jul 31, 2015 5:20 PM, "Guo, Ruijing" <ruijing.guo at intel.com> wrote:
> 
> What do you mean ³pre/post pend NSP/NSI²?
>  
> First SFF will redistribute to other SFFs.
>  
> Other SFFs should forward package according to NSP/NSI instead of original
> packet since original package may change src_ip, dest_ip, src_port, dest_port
>  
> Even if it is bidirectional RSP, it should go back to first SFF.
>  
> Thanks,
> -Ruijing
>  
> From: Keith Burns [mailto:alagalah at gmail.com]
> Sent: Friday, July 31, 2015 5:06 PM
> To: Guo, Ruijing
> Cc: Yang, Yi Y; Reinaldo Penno; sfc-dev at lists.opendaylight.org;
> groupbasedpolicy-dev at lists.opendaylight.org
> Subject: RE: [sfc-dev] [groupbasedpolicy-dev] GBP/SFC Loadbalance
>  
> Yep, but what GBP requests and gets back is the RSP. We need the first and
> last NSH header.
> 
> Hence pre/post pend might be a solution.
> 
> On Jul 31, 2015 4:47 PM, "Guo, Ruijing" <ruijing.guo at intel.com> wrote:
>> 
>> GBP classifier is not aware of RSP group. GBP just add NSH and sent to SFF.
>>  
>> First SFF will loadbalance traffic in RSP group.
>>  
>> From implementation, same hash(src_ip, dest_ip, src_port, dest_port) should
>> go to same path
>>  
>> Thanks,
>> -Ruijing
>>  
>>  
>> From: Keith Burns [mailto:alagalah at gmail.com]
>> Sent: Friday, July 31, 2015 4:20 PM
>> To: Reinaldo Penno
>> Cc: Yang, Yi Y; groupbasedpolicy-dev at lists.opendaylight.org;
>> sfc-dev at lists.opendaylight.org; Guo, Ruijing
>> Subject: Re: [sfc-dev] [groupbasedpolicy-dev] GBP/SFC Loadbalance
>> 
>>  
>> Interesting. As this notion of grouping plays into the VNFM resource pool
>> allocation idea a few of us were discussing after lunch.
>> 
>> Would the rsp returned to the classifier map to a set of rsps with a pre/post
>> pended NSP/NSI to ensure same ingress/egress SFF?
>> 
>> This would be really cool
>> 
>> On Jul 31, 2015 9:09 AM, "Reinaldo Penno" <rapenno at gmail.com> wrote:
>>> 
>>> I would prefer a solution that can be modeled in SFC and left to vendors on
>>> how to implement in hardware.  I would envision this to be something like a
>>> 'RSP Group' feature.
>>> 
>>>  
>>> 
>>> Classifier still receives a single path-id but this represented a group.
>>> Classifier sends packet to this RSP Group path-id and first SFF distributes
>>> to each member of the group or
>>> 
>>> Classifier understands RSP Group Yang construct and distributes to each
>>> member of the group.
>>> 
>>>  
>>> 
>>> If in OVS we use ope flow hash and vendor B uses something else it is really
>>> an implementation detail.
>>> 
>>>  
>>> 
>>> The advantage of this solution is that all config can be stored in modeled
>>> and stored in Yang. We can monitor things as a group, change, update the
>>> group, etc.
>>> 
>>>  
>>> 
>>> Thanks,
>>> 
>>>  
>>> 
>>>  
>>> 
>>> From: "Yang, Yi Y" <yi.y.yang at intel.com>
>>> Date: Thursday, July 30, 2015 at 6:34 PM
>>> To: "Guo, Ruijing" <ruijing.guo at intel.com>, "sfc-dev at lists.opendaylight.org"
>>> <sfc-dev at lists.opendaylight.org>,
>>> "groupbasedpolicy-dev at lists.opendaylight.org"
>>> <groupbasedpolicy-dev at lists.opendaylight.org>
>>> Subject: Re: [groupbasedpolicy-dev] GBP/SFC Loadbalance
>>> 
>>>  
>>> 
>>> Yet another feasible way is
>>>  
>>> SFG (Service Function Group), RSP is just the ordered SFG ID list, which SF
>>> in a SFG group identified by SFG ID will be selected depends on selection
>>> scheduler algorithm, it may be Round Robin, Load Balance, Random or the
>>> shortest path. In this way, it will be transparent to GBP, but Openflow
>>> programming will have a big challenge.
>>>  
>>> 
>>> From:sfc-dev-bounces at lists.opendaylight.org
>>> [mailto:sfc-dev-bounces at lists.opendaylight.org] On Behalf Of Guo, Ruijing
>>> Sent: Friday, July 31, 2015 7:43 AM
>>> To: sfc-dev at lists.opendaylight.org;
>>> groupbasedpolicy-dev at lists.opendaylight.org
>>> Subject: [sfc-dev] GBP/SFC Loadbalance
>>>  
>>> Hi,  GBPer, SFCer,
>>>  
>>> I¹d like to propose GBP/SFC load balancing.
>>>  
>>> Use Case:
>>>  
>>> GBP generates lots of traffic and SFC cannot handle all the traffic. In this
>>> case, GBP/SFC can load balance traffic to different RSPs.
>>>  
>>> Existing Implementation:
>>>  
>>> GBP calls SFC to return 1 RSP and gets SFF information. GBP adds NSH from
>>> SFF and sends traffic to SFF.
>>> The traffic goes along to ONLY 1 RSP.
>>>  
>>> Note: in the following solution, packet with same hash goes to same RSP. OVS
>>> already implemented select group.
>>> Same hash goes to same bucket as:
>>> group_id=5000,type=select,bucket=set_nsp:0x1,bucket=set_nsp:0x2,bucket=set_n
>>> sp:0x3
>>> priority=64999,tcp,reg0=0x8,reg1=0x1,reg2=0x2,reg3=0x1,tp_dst=80,actions=gro
>>> up:5000,set_nsi:255,goto_table:6
>>>  
>>> Solution 1: Load balance by GBP
>>> 1.      GBP call SFC to return RSP LIST.
>>> 
>>> 2.      GBP load balance traffic to RSP LIST according to hash(src_ip,
>>> dest_ip, src_port, dest_port).
>>> 
>>>  
>>>  
>>>  
>>> Solution 2: Load balance by SFF
>>> 1.      GBP call SFC to return RSP1
>>> 
>>> 2.      SFC create RSP LIST.
>>> 
>>> 3.      GBP send traffic to SFF
>>> 
>>> 4.      SFF load balance to RSP LIST according to hash(src_ip, dest_ip,
>>> src_port, dest_port).
>>> 
>>>  
>>>  
>>> Solution 3: Load balance by SF
>>> 1.      GBP call SFC to return RSP1
>>> 
>>> 2.      SFC create RSP LIST
>>> 
>>> 3.      SFC create SF to reclassify traffic to RSP LIST according to
>>> hash(src_ip, dest_ip, src_port, dest_port).
>>> 
>>>  
>>> Thanks,
>>> -Ruijing
>>> _______________________________________________ groupbasedpolicy-dev mailing
>>> list groupbasedpolicy-dev at lists.opendaylight.org
>>> https://lists.opendaylight.org/mailman/listinfo/groupbasedpolicy-dev
>>> <https://lists.opendaylight.org/mailman/listinfo/groupbasedpolicy-dev>
>>> 
>>> _______________________________________________
>>> sfc-dev mailing list
>>> sfc-dev at lists.opendaylight.org
>>> https://lists.opendaylight.org/mailman/listinfo/sfc-dev
_______________________________________________ sfc-dev mailing list
sfc-dev at lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150807/43a106d8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 21859 bytes
Desc: not available
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150807/43a106d8/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 38305 bytes
Desc: not available
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150807/43a106d8/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 35211 bytes
Desc: not available
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150807/43a106d8/attachment-0005.png>


More information about the sfc-dev mailing list