Open Stack

AFAIK, there is proposal about adding a 'priority' option in the existing
flow classifier rule. This can ensure the rule ordering.


On Thu, Apr 21, 2016 at 12:58 PM, IWAMOTO Toshihiro <iwamoto at valinux.co.jp>
wrote:

> 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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160421/dd57e11e/attachment-0001.html>