yahoo-eng-team team mailing list archive

[Miguel Angel Ajo <majopela@xxxxxxxxxx>]

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
         Status: New

** Description changed:

  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.
+ 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
+ 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.
- 
- 
-                     +----------+  +-------------+
-                     |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  |
-              +---------+  +--------+

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1577791

Title:
  [RFE] Openflow pipeline modeling and API for OVS extensions

Status in neutron:
  New

Bug 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.

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1577791/+subscriptions