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 ** Gratuitous ARP generation
 129
 130    ovn-controller should generate a GARP when a port is bound to a chassis.
 131    This is needed when ports are migrated from one chassis to another, such
 132    as live migrating a VM.
 133
 134 * ovsdb-server
 135
 136   ovsdb-server should have adequate features for OVN but it probably
 137   needs work for scale and possibly for availability as deployments
 138   grow.  Here are some thoughts.
 139
 140   Andy Zhou is looking at these issues.
 141
 142 *** Reducing amount of data sent to clients.
 143
 144     Currently, whenever a row monitored by a client changes,
 145     ovsdb-server sends the client every monitored column in the row,
 146     even if only one column changes.  It might be valuable to reduce
 147     this only to the columns that changes.
 148
 149     Also, whenever a column changes, ovsdb-server sends the entire
 150     contents of the column.  It might be valuable, for columns that
 151     are sets or maps, to send only added or removed values or
 152     key-values pairs.
 153
 154     Currently, clients monitor the entire contents of a table.  It
 155     might make sense to allow clients to monitor only rows that
 156     satisfy specific criteria, e.g. to allow an ovn-controller to
 157     receive only Logical_Flow rows for logical networks on its hypervisor.
 158
 159 *** Reducing redundant data and code within ovsdb-server.
 160
 161     Currently, ovsdb-server separately composes database update
 162     information to send to each of its clients.  This is fine for a
 163     small number of clients, but it wastes time and memory when
 164     hundreds of clients all want the same updates (as will be in the
 165     case in OVN).
 166
 167     (This is somewhat opposed to the idea of letting a client monitor
 168     only some rows in a table, since that would increase the diversity
 169     among clients.)
 170
 171 *** Multithreading.
 172
 173     If it turns out that other changes don't let ovsdb-server scale
 174     adequately, we can multithread ovsdb-server.  Initially one might
 175     only break protocol handling into separate threads, leaving the
 176     actual database work serialized through a lock.
 177
 178 ** Increasing availability.
 179
 180    Database availability might become an issue.  The OVN system
 181    shouldn't grind to a halt if the database becomes unavailable, but
 182    it would become impossible to bring VIFs up or down, etc.
 183
 184    My current thought on how to increase availability is to add
 185    clustering to ovsdb-server, probably via the Raft consensus
 186    algorithm.  As an experiment, I wrote an implementation of Raft
 187    for Open vSwitch that you can clone from:
 188
 189        https://github.com/blp/ovs-reviews.git raft
 190
 191 ** Reducing startup time.
 192
 193    As-is, if ovsdb-server restarts, every client will fetch a fresh
 194    copy of the part of the database that it cares about.  With
 195    hundreds of clients, this could cause heavy CPU load on
 196    ovsdb-server and use excessive network bandwidth.  It would be
 197    better to allow incremental updates even across connection loss.
 198    One way might be to use "Difference Digests" as described in
 199    Epstein et al., "What's the Difference? Efficient Set
 200    Reconciliation Without Prior Context".  (I'm not yet aware of
 201    previous non-academic use of this technique.)
 202
 203 ** Support multiple tunnel encapsulations in Chassis.
 204
 205    So far, both ovn-controller and ovn-controller-vtep only allow
 206    chassis to have one tunnel encapsulation entry.  We should extend
 207    the implementation to support multiple tunnel encapsulations.
 208
 209 ** Update learned MAC addresses from VTEP to OVN
 210
 211    The VTEP gateway stores all MAC addresses learned from its
 212    physical interfaces in the 'Ucast_Macs_Local' and the
 213    'Mcast_Macs_Local' tables.  ovn-controller-vtep should be
 214    able to update that information back to ovn-sb database,
 215    so that other chassis know where to send packets destined
 216    to the extended external network instead of broadcasting.
 217
 218 ** Translate ovn-sb Multicast_Group table into VTEP config
 219
 220    The ovn-controller-vtep daemon should be able to translate
 221    the Multicast_Group table entry in ovn-sb database into
 222    Mcast_Macs_Remote table configuration in VTEP database.
 223
 224 * Consider the use of BFD as tunnel monitor.
 225
 226   The use of BFD for hypervisor-to-hypervisor tunnels is probably not worth it,
 227   since there's no alternative to switch to if a tunnel goes down.  It could
 228   make sense at a slow rate if someone does OVN monitoring system integration,
 229   but not otherwise.
 230
 231   When OVN gets to supporting HA for gateways (see ovn/OVN-GW-HA.md), BFD is
 232   likely needed as a part of that solution.
 233
 234   There's more commentary in this ML post:
 235   http://openvswitch.org/pipermail/dev/2015-November/062385.html
 236
 237 * ACL
 238
 239 ** Support FTP ALGs.
 240
 241 ** Support reject action.
 242
 243 ** Support log option.