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

Guo, Ruijing ruijing.guo at intel.com
Sat Aug 1 00:19:51 UTC 2015


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<mailto: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<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<mailto:groupbasedpolicy-dev at lists.opendaylight.org>; sfc-dev at lists.opendaylight.org<mailto: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<mailto: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<mailto:yi.y.yang at intel.com>>
Date: Thursday, July 30, 2015 at 6:34 PM
To: "Guo, Ruijing" <ruijing.guo at intel.com<mailto:ruijing.guo at intel.com>>, "sfc-dev at lists.opendaylight.org<mailto:sfc-dev at lists.opendaylight.org>" <sfc-dev at lists.opendaylight.org<mailto:sfc-dev at lists.opendaylight.org>>, "groupbasedpolicy-dev at lists.opendaylight.org<mailto:groupbasedpolicy-dev at lists.opendaylight.org>" <groupbasedpolicy-dev at lists.opendaylight.org<mailto: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> [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<mailto:sfc-dev at lists.opendaylight.org>; groupbasedpolicy-dev at lists.opendaylight.org<mailto: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_nsp:0x3
priority=64999,tcp,reg0=0x8,reg1=0x1,reg2=0x2,reg3=0x1,tp_dst=80,actions=group: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).

[cid:image001.png at 01D0CBB5.1A850A30]


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).

[cid:image002.png at 01D0CBB5.1A850A30]

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).
[cid:image003.png at 01D0CBB5.1A850A30]

Thanks,
-Ruijing
_______________________________________________ groupbasedpolicy-dev mailing list groupbasedpolicy-dev at lists.opendaylight.org<mailto:groupbasedpolicy-dev at lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/groupbasedpolicy-dev

_______________________________________________
sfc-dev mailing list
sfc-dev at lists.opendaylight.org<mailto: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/20150801/a2c30ce8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 38305 bytes
Desc: image001.png
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150801/a2c30ce8/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 21859 bytes
Desc: image002.png
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150801/a2c30ce8/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 35211 bytes
Desc: image003.png
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150801/a2c30ce8/attachment-0005.png>


More information about the sfc-dev mailing list