ovn/TODO

   1 * ovn-controller
   2
   3 ** ovn-controller parameters and configuration.
   4
   5 *** SSL configuration.
   6
   7     Can probably get this from Open_vSwitch database.
   8
   9 ** Security
  10
  11 *** Limiting the impact of a compromised chassis.
  12
  13     Every instance of ovn-controller has the same full access to the central
  14     OVN_Southbound database.  This means that a compromised chassis can
  15     interfere with the normal operation of the rest of the deployment.  Some
  16     specific examples include writing to the logical flow table to alter
  17     traffic handling or updating the port binding table to claim ports that are
  18     actually present on a different chassis.  In practice, the compromised host
  19     would be fighting against ovn-northd and other instances of ovn-controller
  20     that would be trying to restore the correct state.  The impact could include
  21     at least temporarily redirecting traffic (so the compromised host could
  22     receive traffic that it shouldn't) and potentially a more general denial of
  23     service.
  24
  25     There are different potential improvements to this area.  The first would be
  26     to add some sort of ACL scheme to ovsdb-server.  A proposal for this should
  27     first include an ACL scheme for ovn-controller.  An example policy would
  28     be to make Logical_Flow read-only.  Table-level control is needed, but is
  29     not enough.  For example, ovn-controller must be able to update the Chassis
  30     and Encap tables, but should only be able to modify the rows associated with
  31     that chassis and no others.
  32
  33     A more complex example is the Port_Binding table.  Currently, ovn-controller
  34     is the source of truth of where a port is located.  There seems to be  no
  35     policy that can prevent malicious behavior of a compromised host with this
  36     table.
  37
  38     An alternative scheme for port bindings would be to provide an optional mode
  39     where an external entity controls port bindings and make them read-only to
  40     ovn-controller.  This is actually how OpenStack works today, for example.
  41     The part of OpenStack that manages VMs (Nova) tells the networking component
  42     (Neutron) where a port will be located, as opposed to the networking
  43     component discovering it.
  44
  45 * ovsdb-server
  46
  47   ovsdb-server should have adequate features for OVN but it probably
  48   needs work for scale and possibly for availability as deployments
  49   grow.  Here are some thoughts.
  50
  51   Andy Zhou is looking at these issues.
  52
  53 *** Reducing amount of data sent to clients.
  54
  55     Currently, whenever a row monitored by a client changes,
  56     ovsdb-server sends the client every monitored column in the row,
  57     even if only one column changes.  It might be valuable to reduce
  58     this only to the columns that changes.
  59
  60     Also, whenever a column changes, ovsdb-server sends the entire
  61     contents of the column.  It might be valuable, for columns that
  62     are sets or maps, to send only added or removed values or
  63     key-values pairs.
  64
  65     Currently, clients monitor the entire contents of a table.  It
  66     might make sense to allow clients to monitor only rows that
  67     satisfy specific criteria, e.g. to allow an ovn-controller to
  68     receive only Logical_Flow rows for logical networks on its hypervisor.
  69
  70 *** Reducing redundant data and code within ovsdb-server.
  71
  72     Currently, ovsdb-server separately composes database update
  73     information to send to each of its clients.  This is fine for a
  74     small number of clients, but it wastes time and memory when
  75     hundreds of clients all want the same updates (as will be in the
  76     case in OVN).
  77
  78     (This is somewhat opposed to the idea of letting a client monitor
  79     only some rows in a table, since that would increase the diversity
  80     among clients.)
  81
  82 *** Multithreading.
  83
  84     If it turns out that other changes don't let ovsdb-server scale
  85     adequately, we can multithread ovsdb-server.  Initially one might
  86     only break protocol handling into separate threads, leaving the
  87     actual database work serialized through a lock.
  88
  89 ** Increasing availability.
  90
  91    Database availability might become an issue.  The OVN system
  92    shouldn't grind to a halt if the database becomes unavailable, but
  93    it would become impossible to bring VIFs up or down, etc.
  94
  95    My current thought on how to increase availability is to add
  96    clustering to ovsdb-server, probably via the Raft consensus
  97    algorithm.  As an experiment, I wrote an implementation of Raft
  98    for Open vSwitch that you can clone from:
  99
 100        https://github.com/blp/ovs-reviews.git raft
 101
 102 ** Reducing startup time.
 103
 104    As-is, if ovsdb-server restarts, every client will fetch a fresh
 105    copy of the part of the database that it cares about.  With
 106    hundreds of clients, this could cause heavy CPU load on
 107    ovsdb-server and use excessive network bandwidth.  It would be
 108    better to allow incremental updates even across connection loss.
 109    One way might be to use "Difference Digests" as described in
 110    Epstein et al., "What's the Difference? Efficient Set
 111    Reconciliation Without Prior Context".  (I'm not yet aware of
 112    previous non-academic use of this technique.)
 113
 114 ** Support multiple tunnel encapsulations in Chassis.
 115
 116    So far, both ovn-controller and ovn-controller-vtep only allow
 117    chassis to have one tunnel encapsulation entry.  We should extend
 118    the implementation to support multiple tunnel encapsulations.
 119
 120 ** Update learned MAC addresses from VTEP to OVN
 121
 122    The VTEP gateway stores all MAC addresses learned from its
 123    physical interfaces in the 'Ucast_Macs_Local' and the
 124    'Mcast_Macs_Local' tables.  ovn-controller-vtep should be
 125    able to update that information back to ovn-sb database,
 126    so that other chassis know where to send packets destined
 127    to the extended external network instead of broadcasting.
 128
 129 ** Translate ovn-sb Multicast_Group table into VTEP config
 130
 131    The ovn-controller-vtep daemon should be able to translate
 132    the Multicast_Group table entry in ovn-sb database into
 133    Mcast_Macs_Remote table configuration in VTEP database.
 134
 135 * Use BFD as tunnel monitor.
 136
 137    Both ovn-controller and ovn-contorller-vtep should use BFD to
 138    monitor the tunnel liveness.  Both ovs-vswitchd schema and
 139    VTEP schema supports BFD.