ovn/TODO

   1 -*- outline -*-
   2
   3 * L3 support
   4
   5 ** New OVN logical actions
   6
   7 *** icmp4 { action... }
   8
   9 Generates an ICMPv4 packet based on the current IPv4 packet and
  10 processes it according to each nested action (and then pops back to
  11 processing the original IPv4 packet).  The intended use case is for
  12 generating "time exceeded" and "destination unreachable" errors.
  13
  14 ovn-sb.xml includes a tentative specification for this action.
  15
  16 Tentatively, the icmp4 action sets a default icmp_type and icmp_code
  17 and lets the nested actions override it.  This means that we'd have to
  18 make icmp_type and icmp_code writable.  Because changing icmp_type and
  19 icmp_code can change the interpretation of the rest of the data in the
  20 ICMP packet, we would want to think this through carefully.  If it
  21 seems like a bad idea then we could instead make the type and code a
  22 parameter to the action: icmp4(type, code) { action... }
  23
  24 It is worth considering what should be considered the ingress port for
  25 the ICMPv4 packet.  It's quite likely that the ICMPv4 packet is going
  26 to go back out the ingress port.  Maybe the icmp4 action, therefore,
  27 should clear the inport, so that output to the original inport won't
  28 be discarded.
  29
  30 *** tcp_reset
  31
  32 Transforms the current TCP packet into a RST reply.
  33
  34 ovn-sb.xml includes a tentative specification for this action.
  35
  36 *** Other actions for IPv6.
  37
  38 IPv6 will probably need an action or actions for ND that is similar to
  39 the "arp" action, and an action for generating
  40
  41 ** IPv6
  42
  43 *** ND versus ARP
  44
  45 *** IPv6 routing
  46
  47 *** ICMPv6
  48
  49 ** Dynamic IP to MAC bindings
  50
  51 OVN has basic support for establishing IP to MAC bindings dynamically,
  52 using ARP.
  53
  54 *** Ratelimiting.
  55
  56 From casual observation, Linux appears to generate at most one ARP per
  57 second per destination.
  58
  59 This might be supported by adding a new OVN logical action for
  60 rate-limiting.
  61
  62 *** Tracking queries
  63
  64 It's probably best to only record in the database responses to queries
  65 actually issued by an L3 logical router, so somehow they have to be
  66 tracked, probably by putting a tentative binding without a MAC address
  67 into the database.
  68
  69 *** Renewal and expiration.
  70
  71 Something needs to make sure that bindings remain valid and expire
  72 those that become stale.
  73
  74 One way to do this might be to add some support for time to the
  75 database server itself.
  76
  77 *** Table size limiting.
  78
  79 The table of MAC bindings must not be allowed to grow unreasonably
  80 large.
  81
  82 ** MTU handling (fragmentation on output)
  83
  84 * ovn-controller
  85
  86 ** ovn-controller parameters and configuration.
  87
  88 *** SSL configuration.
  89
  90     Can probably get this from Open_vSwitch database.
  91
  92 ** Security
  93
  94 *** Limiting the impact of a compromised chassis.
  95
  96     Every instance of ovn-controller has the same full access to the central
  97     OVN_Southbound database.  This means that a compromised chassis can
  98     interfere with the normal operation of the rest of the deployment.  Some
  99     specific examples include writing to the logical flow table to alter
 100     traffic handling or updating the port binding table to claim ports that are
 101     actually present on a different chassis.  In practice, the compromised host
 102     would be fighting against ovn-northd and other instances of ovn-controller
 103     that would be trying to restore the correct state.  The impact could include
 104     at least temporarily redirecting traffic (so the compromised host could
 105     receive traffic that it shouldn't) and potentially a more general denial of
 106     service.
 107
 108     There are different potential improvements to this area.  The first would be
 109     to add some sort of ACL scheme to ovsdb-server.  A proposal for this should
 110     first include an ACL scheme for ovn-controller.  An example policy would
 111     be to make Logical_Flow read-only.  Table-level control is needed, but is
 112     not enough.  For example, ovn-controller must be able to update the Chassis
 113     and Encap tables, but should only be able to modify the rows associated with
 114     that chassis and no others.
 115
 116     A more complex example is the Port_Binding table.  Currently, ovn-controller
 117     is the source of truth of where a port is located.  There seems to be  no
 118     policy that can prevent malicious behavior of a compromised host with this
 119     table.
 120
 121     An alternative scheme for port bindings would be to provide an optional mode
 122     where an external entity controls port bindings and make them read-only to
 123     ovn-controller.  This is actually how OpenStack works today, for example.
 124     The part of OpenStack that manages VMs (Nova) tells the networking component
 125     (Neutron) where a port will be located, as opposed to the networking
 126     component discovering it.
 127
 128 * ovsdb-server
 129
 130   ovsdb-server should have adequate features for OVN but it probably
 131   needs work for scale and possibly for availability as deployments
 132   grow.  Here are some thoughts.
 133
 134   Andy Zhou is looking at these issues.
 135
 136 *** Reducing amount of data sent to clients.
 137
 138     Currently, whenever a row monitored by a client changes,
 139     ovsdb-server sends the client every monitored column in the row,
 140     even if only one column changes.  It might be valuable to reduce
 141     this only to the columns that changes.
 142
 143     Also, whenever a column changes, ovsdb-server sends the entire
 144     contents of the column.  It might be valuable, for columns that
 145     are sets or maps, to send only added or removed values or
 146     key-values pairs.
 147
 148     Currently, clients monitor the entire contents of a table.  It
 149     might make sense to allow clients to monitor only rows that
 150     satisfy specific criteria, e.g. to allow an ovn-controller to
 151     receive only Logical_Flow rows for logical networks on its hypervisor.
 152
 153 *** Reducing redundant data and code within ovsdb-server.
 154
 155     Currently, ovsdb-server separately composes database update
 156     information to send to each of its clients.  This is fine for a
 157     small number of clients, but it wastes time and memory when
 158     hundreds of clients all want the same updates (as will be in the
 159     case in OVN).
 160
 161     (This is somewhat opposed to the idea of letting a client monitor
 162     only some rows in a table, since that would increase the diversity
 163     among clients.)
 164
 165 *** Multithreading.
 166
 167     If it turns out that other changes don't let ovsdb-server scale
 168     adequately, we can multithread ovsdb-server.  Initially one might
 169     only break protocol handling into separate threads, leaving the
 170     actual database work serialized through a lock.
 171
 172 ** Increasing availability.
 173
 174    Database availability might become an issue.  The OVN system
 175    shouldn't grind to a halt if the database becomes unavailable, but
 176    it would become impossible to bring VIFs up or down, etc.
 177
 178    My current thought on how to increase availability is to add
 179    clustering to ovsdb-server, probably via the Raft consensus
 180    algorithm.  As an experiment, I wrote an implementation of Raft
 181    for Open vSwitch that you can clone from:
 182
 183        https://github.com/blp/ovs-reviews.git raft
 184
 185 ** Reducing startup time.
 186
 187    As-is, if ovsdb-server restarts, every client will fetch a fresh
 188    copy of the part of the database that it cares about.  With
 189    hundreds of clients, this could cause heavy CPU load on
 190    ovsdb-server and use excessive network bandwidth.  It would be
 191    better to allow incremental updates even across connection loss.
 192    One way might be to use "Difference Digests" as described in
 193    Epstein et al., "What's the Difference? Efficient Set
 194    Reconciliation Without Prior Context".  (I'm not yet aware of
 195    previous non-academic use of this technique.)
 196
 197 ** Support multiple tunnel encapsulations in Chassis.
 198
 199    So far, both ovn-controller and ovn-controller-vtep only allow
 200    chassis to have one tunnel encapsulation entry.  We should extend
 201    the implementation to support multiple tunnel encapsulations.
 202
 203 ** Update learned MAC addresses from VTEP to OVN
 204
 205    The VTEP gateway stores all MAC addresses learned from its
 206    physical interfaces in the 'Ucast_Macs_Local' and the
 207    'Mcast_Macs_Local' tables.  ovn-controller-vtep should be
 208    able to update that information back to ovn-sb database,
 209    so that other chassis know where to send packets destined
 210    to the extended external network instead of broadcasting.
 211
 212 ** Translate ovn-sb Multicast_Group table into VTEP config
 213
 214    The ovn-controller-vtep daemon should be able to translate
 215    the Multicast_Group table entry in ovn-sb database into
 216    Mcast_Macs_Remote table configuration in VTEP database.
 217
 218 * Consider the use of BFD as tunnel monitor.
 219
 220   The use of BFD for hypervisor-to-hypervisor tunnels is probably not worth it,
 221   since there's no alternative to switch to if a tunnel goes down.  It could
 222   make sense at a slow rate if someone does OVN monitoring system integration,
 223   but not otherwise.
 224
 225   When OVN gets to supporting HA for gateways (see ovn/OVN-GW-HA.md), BFD is
 226   likely needed as a part of that solution.
 227
 228   There's more commentary in this ML post:
 229   http://openvswitch.org/pipermail/dev/2015-November/062385.html
 230
 231 * ACL
 232
 233 ** Support FTP ALGs.
 234
 235 ** Support reject action.
 236
 237 ** Support log option.