ovn/TODO

   1 * ovn-controller
   2
   3 ** Flow table handling in ovn-controller.
   4
   5    ovn-controller has to transform logical datapath flows from the
   6    database into OpenFlow flows.
   7
   8 *** Definition (or choice) of data structure for flows and flow table.
   9
  10     It would be natural enough to use "struct flow" and "struct
  11     classifier" for this.  Maybe that is what we should do.  However,
  12     "struct classifier" is optimized for searches based on packet
  13     headers, whereas all we care about here can be implemented with a
  14     hash table.  Also, we may want to make it easy to add and remove
  15     support for fields without recompiling, which is not possible with
  16     "struct flow" or "struct classifier".
  17
  18     On the other hand, we may find that it is difficult to decide that
  19     two OXM flow matches are identical (to normalize them) without a
  20     lot of domain-specific knowledge that is already embedded in struct
  21     flow.  It's also going to be a pain to come up with a way to make
  22     anything other than "struct flow" work with the ofputil_*()
  23     functions for encoding and decoding OpenFlow.
  24
  25     It's also possible we could use struct flow without struct
  26     classifier.
  27
  28 *** Translating logical datapath actions into OpenFlow actions.
  29
  30     Some of the logical datapath actions do not have natural
  31     representations as OpenFlow actions: they require
  32     packet-in/packet-out round trips through ovn-controller.  The
  33     trickiest part of that is going to be making sure that the
  34     packet-out resumes the control flow that was broken off by the
  35     packet-in.  That's tricky; we'll probably have to restrict control
  36     flow or add OVS features to make resuming in general possible.  Not
  37     sure which is better at this point.
  38
  39 *** OpenFlow flow table synchronization.
  40
  41     The internal representation of the OpenFlow flow table has to be
  42     synced across the controller connection to OVS.  This probably
  43     boils down to the "flow monitoring" feature of OF1.4 which was then
  44     made available as a "standard extension" to OF1.3.  (OVS hasn't
  45     implemented this for OF1.4 yet, but the feature is based on a OVS
  46     extension to OF1.0, so it should be straightforward to add it.)
  47
  48     We probably need some way to catch cases where OVS and OVN don't
  49     see eye-to-eye on what exactly constitutes a flow, so that OVN
  50     doesn't waste a lot of CPU time hammering at OVS trying to install
  51     something that it's not going to do.
  52
  53 *** Logical/physical translation.
  54
  55     When a packet comes into the integration bridge, the first stage of
  56     processing needs to translate it from a physical to a logical
  57     context.  When a packet leaves the integration bridge, the final
  58     stage of processing needs to translate it back into a physical
  59     context.  ovn-controller needs to populate the OpenFlow flows
  60     tables to do these translations.
  61
  62 *** Determine how to split logical pipeline across physical nodes.
  63
  64     From the original OVN architecture document:
  65
  66     The pipeline processing is split between the ingress and egress
  67     transport nodes.  In particular, the logical egress processing may
  68     occur at either hypervisor.  Processing the logical egress on the
  69     ingress hypervisor requires more state about the egress vif's
  70     policies, but reduces traffic on the wire that would eventually be
  71     dropped.  Whereas, processing on the egress hypervisor can reduce
  72     broadcast traffic on the wire by doing local replication.  We
  73     initially plan to process logical egress on the egress hypervisor
  74     so that less state needs to be replicated.  However, we may change
  75     this behavior once we gain some experience writing the logical
  76     flows.
  77
  78     The split pipeline processing split will influence how tunnel keys
  79     are encoded.
  80
  81 ** Interaction with Open_vSwitch and OVN databases:
  82
  83 *** Monitor Chassis table in OVN.
  84
  85     Populate Port records for tunnels to other chassis into
  86     Open_vSwitch database.  As a scale optimization later on, one can
  87     populate only records for tunnels to other chassis that have
  88     logical networks in common with this one.
  89
  90 *** Monitor Pipeline table in OVN, trigger flow table recomputation on change.
  91
  92 ** ovn-controller parameters and configuration.
  93
  94 *** Tunnel encapsulation to publish.
  95
  96     Default: VXLAN? Geneve?
  97
  98 *** SSL configuration.
  99
 100     Can probably get this from Open_vSwitch database.
 101
 102 * ovsdb-server
 103
 104   ovsdb-server should have adequate features for OVN but it probably
 105   needs work for scale and possibly for availability as deployments
 106   grow.  Here are some thoughts.
 107
 108   Andy Zhou is looking at these issues.
 109
 110 ** Scaling number of connections.
 111
 112    In typical use today a given ovsdb-server has only a single-digit
 113    number of simultaneous connections.  The OVN Southbound database will
 114    have a connection from every hypervisor.  This use case needs testing
 115    and probably coding work.  Here are some possible improvements.
 116
 117 *** Reducing amount of data sent to clients.
 118
 119     Currently, whenever a row monitored by a client changes,
 120     ovsdb-server sends the client every monitored column in the row,
 121     even if only one column changes.  It might be valuable to reduce
 122     this only to the columns that changes.
 123
 124     Also, whenever a column changes, ovsdb-server sends the entire
 125     contents of the column.  It might be valuable, for columns that
 126     are sets or maps, to send only added or removed values or
 127     key-values pairs.
 128
 129     Currently, clients monitor the entire contents of a table.  It
 130     might make sense to allow clients to monitor only rows that
 131     satisfy specific criteria, e.g. to allow an ovn-controller to
 132     receive only Pipeline rows for logical networks on its hypervisor.
 133
 134 *** Reducing redundant data and code within ovsdb-server.
 135
 136     Currently, ovsdb-server separately composes database update
 137     information to send to each of its clients.  This is fine for a
 138     small number of clients, but it wastes time and memory when
 139     hundreds of clients all want the same updates (as will be in the
 140     case in OVN).
 141
 142     (This is somewhat opposed to the idea of letting a client monitor
 143     only some rows in a table, since that would increase the diversity
 144     among clients.)
 145
 146 *** Multithreading.
 147
 148     If it turns out that other changes don't let ovsdb-server scale
 149     adequately, we can multithread ovsdb-server.  Initially one might
 150     only break protocol handling into separate threads, leaving the
 151     actual database work serialized through a lock.
 152
 153 ** Increasing availability.
 154
 155    Database availability might become an issue.  The OVN system
 156    shouldn't grind to a halt if the database becomes unavailable, but
 157    it would become impossible to bring VIFs up or down, etc.
 158
 159    My current thought on how to increase availability is to add
 160    clustering to ovsdb-server, probably via the Raft consensus
 161    algorithm.  As an experiment, I wrote an implementation of Raft
 162    for Open vSwitch that you can clone from:
 163
 164        https://github.com/blp/ovs-reviews.git raft
 165
 166 ** Reducing startup time.
 167
 168    As-is, if ovsdb-server restarts, every client will fetch a fresh
 169    copy of the part of the database that it cares about.  With
 170    hundreds of clients, this could cause heavy CPU load on
 171    ovsdb-server and use excessive network bandwidth.  It would be
 172    better to allow incremental updates even across connection loss.
 173    One way might be to use "Difference Digests" as described in
 174    Epstein et al., "What's the Difference? Efficient Set
 175    Reconciliation Without Prior Context".  (I'm not yet aware of
 176    previous non-academic use of this technique.)
 177
 178 * Miscellaneous:
 179
 180 ** Init scripts for ovn-controller (on HVs), ovn-northd, OVN DB server.
 181
 182 ** Distribution packaging.
 183
 184 * Not yet scoped:
 185
 186 ** Neutron plugin.
 187
 188    This is being developed on OpenStack's development infrastructure
 189    to be along side most of the other Neutron plugins.
 190
 191    http://git.openstack.org/cgit/stackforge/networking-ovn
 192
 193    http://git.openstack.org/cgit/stackforge/networking-ovn/tree/doc/source/todo.rst
 194
 195 ** Gateways.