[sfc-dev] [groupbasedpolicy-dev] The required Changes on GBP side for SFC integration

Reinaldo Penno rapenno at gmail.com
Tue Mar 10 16:48:21 UTC 2015

Yi recently finished the RPC API and now is working on a generic API that
allows GBP to ask a path/chain based on a generic list of service types.
But last I talked with Thomas he was preparing a final patch so we could
test basic integration between projects.

I think having this final patch so we can start doing basic testing will
allow us to get some experience and feedback into the next phases.

From:  Keith Burns <alagalah at noironetworks.com>
Date:  Tuesday, March 10, 2015 at 9:13 AM
To:  Yi Y Yang <yi.y.yang at intel.com>
Cc:  <sfc-dev at lists.opendaylight.org>,
<groupbasedpolicy-dev at lists.opendaylight.org>
Subject:  Re: [groupbasedpolicy-dev] The required Changes on GBP side for
SFC integration


On reflection, since the integration is more "black box" for this iteration
(lithium) it MAY mean that for flows that GBP writes we have a GBP action
and IFF SFC supports rate limiting "inside the black box" it would need to
be passed and your suggestion of putting rate in chain maybe the best

Sorry for not thinking about this end to end. Good call out.

Brady/Thomas/ Reinaldo should we set up a status call for folks who want to
contribute to the POC Lithium and beyond before Thursday?

On Mar 10, 2015 9:01 AM, "Keith Burns" <alagalah at noironetworks.com> wrote:
> Yi,
> I know Reinaldo and Thomas have already done a lot of work already on the GBP
> side, but I know they would love some help.
> For GBP we are tracking this on Trello
> https://trello.com/c/yPGqrAUV/90-sfc-integration and we give an update in our
> team meeting each week
> (see https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:STATUS for
> meeting minutes).
> There's actually quite a bit to getting even the basic "Chain:Foo" action
> going in terms of conflict avoidance, avoiding dot-product flow explosion etc
> that Thomas is working on.
> As for the scope for Li POC, at this stage, we have committed to doing
> "chain:foo" i.e. asking for chain by name.
> I think if you wanted to address #2, it would be great to touch base with them
> on how this may be achieved.
> We would need to discuss "rate" .. I think we are overloading the CHAIN
> action. Rate limiting in GBP should be a separate action, as remember, the
> resolution process is "ALL CLASSIFIERS MUST BE TRUE (logical AND) AND ACTIONS
> APPLIED IN ORDER" ... rate limiting would be one of those actions.... from a
> high level.
> Perhaps a meeting would be in order before either SFC or GBPs team meeting....
> On Tue, Mar 10, 2015 at 7:28 AM, Yang, Yi Y <yi.y.yang at intel.com> wrote:
>> Hi, all
>> As you knew, we have done some work for SFC + GBP integration, this wiki page
>> https://wiki.opendaylight.org/view/Service_Function_Chaining:Group_Based_Poli
>> cy_Integration tracked the changes. Now we need to do some work on GBP side,
>> two necessary things are:
>> #1. Add a new action ³chain².
>> #2. Enhance GBP policy semantics to support SFC policy, SFC policy looks like
>> ³ID: DPI->FW->LB, rate², ID is an identifier for a specific flow, rate is
>> used to limit bandwidth.
>> I¹m not sure anybody is working on them. I know Thomas Bachman did SFC
>> Manager as a start point, Reinaldo Penno added SFC API calls. I believe we
>> need to do much more on GBP side. I look forward to seeing ideas from GBP
>> experts here, I can start doing them if nobody is doing them, but obviously
>> GBP experts¹ input is very important, I¹m a newbie for GBP.
>> _______________________________________________
>> groupbasedpolicy-dev mailing list
>> groupbasedpolicy-dev at lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/groupbasedpolicy-dev
_______________________________________________ groupbasedpolicy-dev mailing
list groupbasedpolicy-dev at lists.opendaylight.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150310/31c833d4/attachment-0001.html>

More information about the sfc-dev mailing list