[RFE] Openflow pipeline modeling and API for OVS extensions

[Miguel Angel Ajo]

Problem statement
~~~~~~~~~~~~~~~~

OpenFlow can be really powerful for programming the dataplane, but when several features are hooked up into the same virtual switch they need knowledge of each other implementation (entry table, next table, used registers, conventions, etc).

Solution
~~~~~~~

Defining a model & extension api for features to describe their "OpenFlow functions", and their entry point in the processing pipeline (ingress prefiltering, ingress postfiltering, egress prefiltering, egress postfiltering), as well as the ability to allocate registers.

On a high level, each extension (and the Openvwitch firewall implementation) would expose a model of it's low level functions.

openvswitch_firewall would expose: ingress_filter & egress_filter.

tapas-a-service (as an example) could expose: taas_{ingress, egress}_{prefilter, postfilter}

Every extension would declare a set of "OFFunctions" which would be built of a number of "OFTables". Once all extensions are loaded, and order resolved, every function would get it's "next hop", and it's table numbers, dynamically.

We could have a predefine OFFunction priority table somewhere in neutron_lib, with spaces in between priorities for experimentation,
with the idea that extensions may request hook points into the pipeline,
and those hook points may be discussed upstream to allow interoperability.

If necessary, a configuration for admin defined ordering of OFFunctions
could be provided in a second step.

Diagram: http://paste.openstack.org/show/495967/

input tagging / output_stage / and ingress deflector would be shared common logic.

[Miguel Angel Ajo (mangelajo)]

This is not an user facing feature, more internal design for allowing inter operability of OVS/OF features: vlan aware, openvswitch firewall, sfc, tap as a service, *...

[Slawek Kaplonski (slaweq)]

Did You consider to order flows from different drivers by order drivers in config file? Like it is done in ML2 plugin with mechanism_drivers for example.

[Miguel Angel Ajo (mangelajo)]

@slawek, this needs an spec/devref to dig deeper into the details, I will start that right away (in a devref form for now).

Ideally, I believe that we should have community defined hook points for the features that request those hook points, so, in a per-feature evaluation we should pick the right spot in the pipeline.
We could put such thing into netronlib for example.

Another option could be, as you say, defining that order of hook points in a config file. So people could be able to introduce extra ones for out-of-community features, or for experimentation. I believe that should also be discussed and considered.

[Slawek Kaplonski (slaweq)]

ajo: ok, thx for answer. I only wanted to write my idea somewhere to not forget it :)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/314106

[cathy Hong Zhang (cathy-h-zhang)]

In "solution" section of this bug description, you mentioned processing pipeline (ingress prefiltering, ingress postfiltering, egress prefiltering, egress postfiltering). But the spec uses another set of terminology. It will make it easy for people to understand the spec if the spec diagram and associated description match what is described in this "solution" section.

[Armando Migliaccio (armando-migliaccio)]

Any chance this can be consolidated with https://bugs.launchpad.net/neutron/+bug/1563967? Marking dup for now, decouple if I misunderstood.

[Miguel Angel Ajo (mangelajo)]

It certainly is a dupe. moving.