| 2016-05-03 14:05:26 |
Miguel Angel Ajo |
bug |
|
|
added bug |
| 2016-05-03 14:07:12 |
Miguel Angel Ajo |
description |
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 buillt 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.
input tagging / output_stage / and ingress deflector would be shared common logic.
+----------+ +-------------+
|br int | | br xxx |
+---------^+ +^------------+
+-------+ | | +-------+
| TAP a <--------+ | | +---->TAP b |
+--+----+ | | | | +-------+
| | | | |
0+-----------v-----+ 255+--+-+----+--+--+
| input tagging | + output_stage |
+-----------+-----+ +--------^--------+
| |
+-----------v-----+ +--------+--------+
| | | |
+-----------+-----+ +--------^--------+
| |
+-----------v-----+ +--------+--------+
| egress filter | | ingress filter |
+-----------+-----+ +--------^--------+
| |
+-----------v-----+ +--------+--------+
| | ^ |
+-----------+-----+ /+--------^--------+
| / |
127-----------v-----+ 0+--------+--------+
|ingress deflector| | input tagging |
+----------+------+ +^--------^-------+
| | |
255+--------v------+ | |
+ output_stage +------+ |
+-----------+-----+ | | |
| | | |
+v--------++ +v-----+-+
| br int | |br xxx |
+---------+ +--------+ |
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.
Diagram: http://paste.openstack.org/show/495967/
input tagging / output_stage / and ingress deflector would be shared common logic. |
|
| 2016-05-03 14:13:52 |
Miguel Angel Ajo |
description |
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.
Diagram: http://paste.openstack.org/show/495967/
input tagging / output_stage / and ingress deflector would be shared common logic. |
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. |
|
| 2016-05-03 14:22:54 |
Miguel Angel Ajo |
bug |
|
|
added subscriber Rossella Sblendido |
| 2016-05-03 14:23:03 |
Miguel Angel Ajo |
bug |
|
|
added subscriber David Shaughnessy |
| 2016-05-03 14:23:11 |
Miguel Angel Ajo |
bug |
|
|
added subscriber Jakub Libosvar |
| 2016-05-03 14:23:24 |
Miguel Angel Ajo |
bug |
|
|
added subscriber Kevin Benton |
| 2016-05-03 14:23:36 |
Miguel Angel Ajo |
bug |
|
|
added subscriber cathy Hong Zhang |
| 2016-05-03 14:24:12 |
Miguel Angel Ajo |
tags |
|
ovs rfe |
|
| 2016-05-03 15:39:58 |
Ryan Moats |
neutron: importance |
Undecided |
Wishlist |
|
| 2016-05-03 15:40:07 |
Ryan Moats |
neutron: importance |
Wishlist |
Undecided |
|
| 2016-05-03 15:40:15 |
Ryan Moats |
neutron: importance |
Undecided |
Wishlist |
|
| 2016-05-03 17:54:00 |
Sridhar Gaddam |
bug |
|
|
added subscriber Sridhar Gaddam |
| 2016-05-04 09:53:44 |
Miguel Angel Ajo |
bug |
|
|
added subscriber YAMAMOTO Takashi |
| 2016-05-06 11:10:40 |
Igor D.C. |
bug |
|
|
added subscriber Igor Duarte Cardoso |
| 2016-05-06 11:53:48 |
Bence Romsics |
bug |
|
|
added subscriber Bence Romsics |
| 2016-05-06 19:44:11 |
Slawek Kaplonski |
bug |
|
|
added subscriber Slawek Kaplonski |
| 2016-05-09 13:39:35 |
OpenStack Infra |
neutron: status |
New |
In Progress |
|
| 2016-05-09 13:39:35 |
OpenStack Infra |
neutron: assignee |
|
Miguel Angel Ajo (mangelajo) |
|
| 2016-05-09 20:22:21 |
Stephen Wong |
bug |
|
|
added subscriber Stephen Wong |
| 2016-05-12 18:13:08 |
Armando Migliaccio |
neutron: status |
In Progress |
Confirmed |
|
| 2016-05-12 21:55:11 |
Armando Migliaccio |
marked as duplicate |
|
1563967 |
|
| 2016-05-13 14:47:13 |
OpenStack Infra |
neutron: status |
Confirmed |
In Progress |
|
