Open Stack

At Wed, 20 Apr 2016 14:12:07 +0200,
Miguel Angel Ajo Pelayo wrote:
> 
> I think this is an interesting topic.
> 
> What do you mean exactly by FC ? (feature chaining?)
> 
> I believe we have three things to look at:  (sorry for the TL)
> 
> 1) The generalization of traffic filters / traffic classifiers. Having
> common models, some sort of common API or common API structure
> available, and translators to convert those filters to iptables,
> openflow filters, etc..
> 
> 2) The enhancement of extensiblity of agents via Extension API.
> 
> 3) How we chain features in OpenFlow, which current approach of just
> inserting rules, renders into incompatible extensions. This becomes
> specially relevant for the new openvswitch firewall.
> 
> 2 and 3 are interlinked, and a good mechanism to enhance (3) should be
> provided in (2).
> 
> We need to resolve:
> 
>     a) The order of tables, and how openflow actions chain the
> different features in the pipeline.  Some naive thinking brings me
> into the idea that we need to identify different input/output stages
> of packet processing, and every feature/extension declares the point
> where it needs to be. And then when we have all features, every
> feature get's it's own table number, and the "next" action in
> pipeline.

Can we create an API that allocates flow insertion points and table
numbers?  How can we ensure correct ordering of flows?
IMHO, it might be a time to collect low-level flow operation functions
into a single repository and test interoperability there.

>     b) We need to have a way to request openflow registers to use in
> extensions, so one extension doesn't overwrite other's registers
> 
>    c) Those registers need to be given a logical names that other
> extensions can query for (for example "port_number", "local_zone",
> etc..) , and those standard registers should be filled in for all
> extensions at the input stage.
> 
>    and probably c,d,e,f,g,h.... what I didn't manage to think of.
> 
> On Fri, Apr 15, 2016 at 11:13 PM, Cathy Zhang <Cathy.H.Zhang at huawei.com> wrote:
> > Hi Reedip,
> >
> >
> >
> > Sure will include you in the discussion. Let me know if there are other
> > Tap-as-a-Service members who would like to join this initiative.
> >
> >
> >
> > Cathy
> >
> >
> >
> > From: reedip banerjee [mailto:reedip14 at gmail.com]
> > Sent: Thursday, April 14, 2016 7:03 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and
> > OVS Agent extension for Newton cycle
> >
> >
> >
> > Speaking on behalf of Tap-as-a-Service members, we would also be very much
> > interested in the following initiative.... :)
> >
> >
> >
> > On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka <ihrachys at redhat.com>
> > wrote:
> >
> > Cathy Zhang <Cathy.H.Zhang at huawei.com> wrote:
> >
> >
> > I think there is no formal spec or anything, just some emails around there.
> >
> > That said, I don’t follow why it’s a requirement for SFC to switch to l2
> > agent extension mechanism. Even today, with SFC maintaining its own agent,
> > there are no clear guarantees for flow priorities that would avoid all
> > possible conflicts.
> >
> > Cathy> There is no requirement for SFC to switch. My understanding is that
> > current L2 agent extension does not solve the conflicting entry issue if two
> > features inject the same priority table entry. I think this new L2 agent
> > effort is try to come up with a mechanism to resolve this issue. Of course
> > if each feature( SFC or Qos) uses its own agent, then there is no
> > coordination and no way to avoid conflicts.
> >
> >
> > Sorry, I probably used misleading wording. I meant, why do we consider the
> > semantic flow management support in l2 agent extension framework a
> > *prerequisite* for SFC to switch to l2 agent extensions? The existing
> > framework should already allow SFC to achieve what you have in the
> > subproject tree implemented as a separate agent (essentially a fork of OVS
> > agent). It will also set SFC to use standard extension mechanisms instead of
> > hacky inheritance from OVS agent classes. So even without the strict
> > semantic flow management, there is benefit for the subproject.
> >
> > With that in mind, I would split this job into 3 pieces:
> > * first, adopt l2 agent extension mechanism for SFC functionality (dropping
> > custom agent);
> > * then, work on semantic flow management support in OVS agent API class [1];
> > * once the feature emerges, switch SFC l2 agent extension to the new
> > framework to manage SFC flows.
> >
> > I would at least prioritize the first point and target it to Newton-1. Other
> > bullet points may take significant time to bake.
> >
> > [1]
> > https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py
> >
> >
> >
> > Ihar
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> > --
> >
> > Thanks and Regards,
> > Reedip Banerjee
> >
> > IRC: reedip
> >
> >
> >
> >
> >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev