-* Flow match expression handling library.
-
- ovn-controller is the primary user of flow match expressions, but
- the same syntax and I imagine the same code ought to be useful in
- ovn-nbd for ACL match expressions.
-
-** Definition of data structures to represent a match expression as a
- syntax tree.
-
-** Definition of data structures to represent variables (fields).
-
- Fields need names and prerequisites. Most fields are numeric and
- thus need widths. We need also need a way to represent nominal
- fields (currently just logical port names). It might be
- appropriate to associate fields directly with OXM/NXM code points;
- we have to decide whether we want OVN to use the OVS flow structure
- or work with OXM more directly.
-
- Probably should be defined so that the data structure is also
- useful for references to fields in action parsing.
-
-** Lexical analysis.
-
- Probably should be defined so that the lexer can be reused for
- parsing actions.
-
-** Parsing into syntax tree.
-
-** Semantic checking against variable definitions.
-
-** Applying prerequisites.
-
-** Simplification into conjunction-of-disjunctions (CoD) form.
-
-** Transformation from CoD form into OXM matches.
-
* ovn-controller
** Flow table handling in ovn-controller.
It's also possible we could use struct flow without struct
classifier.
-*** Assembling conjunctive flows from flow match expressions.
-
- This transformation explodes logical datapath flows into multiple
- OpenFlow flow table entries, since a flow match expression in CoD
- form requires several OpenFlow flow table entries. It also
- requires merging together OpenFlow flow tables entries that contain
- "conjunction" actions (really just concatenating their actions).
-
-*** Translating logical datapath port names into port numbers.
-
- Logical ports are specified by name in logical datapath flows, but
- OpenFlow only works in terms of numbers.
-
*** Translating logical datapath actions into OpenFlow actions.
Some of the logical datapath actions do not have natural
The split pipeline processing split will influence how tunnel keys
are encoded.
-** Interaction with Open_vSwitch and OVN databases:
-
-*** Monitor Chassis table in OVN.
-
- Populate Port records for tunnels to other chassis into
- Open_vSwitch database. As a scale optimization later on, one can
- populate only records for tunnels to other chassis that have
- logical networks in common with this one.
-
*** Monitor Pipeline table in OVN, trigger flow table recomputation on change.
** ovn-controller parameters and configuration.
-*** Tunnel encapsulation to publish.
-
- Default: VXLAN? Geneve?
-
*** SSL configuration.
Can probably get this from Open_vSwitch database.
-* ovn-nbd
-
-** Monitor OVN_Northbound database, trigger Pipeline recomputation on change.
-
-** Translate each OVN_Northbound entity into Pipeline logical datapath flows.
-
- We have to first sit down and figure out what the general
- translation of each entity is. The original OVN architecture
- description at
- http://openvswitch.org/pipermail/dev/2015-January/050380.html had
- some sketches of these, but they need to be completed and
- elaborated.
-
- Initially, the simplest way to do this is probably to write
- straight C code to do a full translation of the entire
- OVN_Northbound database into the format for the Pipeline table in
- the OVN Southbound database. As scale increases, this will probably
- be too inefficient since a small change in OVN_Northbound requires a
- full recomputation. At that point, we probably want to adopt a more
- systematic approach, such as something akin to the "nlog" system used
- in NVP (see Koponen et al. "Network Virtualization in Multi-tenant
- Datacenters", NSDI 2014).
-
-** Push logical datapath flows to Pipeline table.
-
-** Monitor OVN Southbound database Bindings table.
-
- Sync rows in the OVN Bindings table to the "up" column in the
- OVN_Northbound database.
-
* ovsdb-server
ovsdb-server should have adequate features for OVN but it probably
* Miscellaneous:
-** Write ovn-nbctl utility.
-
- The idea here is that we need a utility to act on the OVN_Northbound
- database in a way similar to a CMS, so that we can do some testing
- without an actual CMS in the picture.
-
- No details yet.
-
-** Init scripts for ovn-controller (on HVs), ovn-nbd, OVN DB server.
+** Init scripts for ovn-controller (on HVs), ovn-northd, OVN DB server.
** Distribution packaging.
This is being developed on OpenStack's development infrastructure
to be along side most of the other Neutron plugins.
- http://git.openstack.org/cgit/stackforge/networking-ovn
-
- http://git.openstack.org/cgit/stackforge/networking-ovn/tree/doc/source/todo.rst
+ http://git.openstack.org/cgit/openstack/networking-ovn
** Gateways.