ovn/TODO

   1 -*- outline -*-
   2
   3 * L3 support
   4
   5 ** OVN_Northbound schema
   6
   7 *** Needs to support extra routes
   8
   9 Currently a router port has a single route associated with it, but
  10 presumably we should support multiple routes.  For connections from
  11 one router to another, this doesn't seem to matter (just put more than
  12 one connection between them), but for connections between a router and
  13 a switch it might matter because a switch has only one router port.
  14
  15 ** New OVN logical actions
  16
  17 *** arp
  18
  19 Generates an ARP packet based on the current IPv4 packet and allows it
  20 to be processed as part of the current pipeline (and then pop back to
  21 processing the original IPv4 packet).
  22
  23 TCP/IP stacks typically limit the rate at which ARPs are sent, e.g. to
  24 one per second for a given target.  We might need to do this too.
  25
  26 We probably need to buffer the packet that generated the ARP.  I don't
  27 know where to do that.
  28
  29 *** icmp4 { action... }
  30
  31 Generates an ICMPv4 packet based on the current IPv4 packet and
  32 processes it according to each nested action (and then pops back to
  33 processing the original IPv4 packet).  The intended use case is for
  34 generating "time exceeded" and "destination unreachable" errors.
  35
  36 ovn-sb.xml includes a tentative specification for this action.
  37
  38 Tentatively, the icmp4 action sets a default icmp_type and icmp_code
  39 and lets the nested actions override it.  This means that we'd have to
  40 make icmp_type and icmp_code writable.  Because changing icmp_type and
  41 icmp_code can change the interpretation of the rest of the data in the
  42 ICMP packet, we would want to think this through carefully.  If it
  43 seems like a bad idea then we could instead make the type and code a
  44 parameter to the action: icmp4(type, code) { action... }
  45
  46 It is worth considering what should be considered the ingress port for
  47 the ICMPv4 packet.  It's quite likely that the ICMPv4 packet is going
  48 to go back out the ingress port.  Maybe the icmp4 action, therefore,
  49 should clear the inport, so that output to the original inport won't
  50 be discarded.
  51
  52 *** tcp_reset
  53
  54 Transforms the current TCP packet into a RST reply.
  55
  56 ovn-sb.xml includes a tentative specification for this action.
  57
  58 *** Other actions for IPv6.
  59
  60 IPv6 will probably need an action or actions for ND that is similar to
  61 the "arp" action, and an action for generating
  62
  63 *** ovn-controller translation to OpenFlow
  64
  65 The following two translation strategies come to mind.  Some of the
  66 new actions we might want to implement one way, some of them the
  67 other, depending on the details.
  68
  69 *** Implementation strategies
  70
  71 One way to do this is to define new actions as Open vSwitch extensions
  72 to OpenFlow, emit those actions in ovn-controller, and implement them
  73 in ovs-vswitchd (possibly pushing the implementations into the Linux
  74 and DPDK datapaths as well).  This is the only acceptable way for
  75 actions that need high performance.  None of these actions obviously
  76 need high performance, but it might be necessary to have fairness in
  77 handling e.g. a flood of incoming packets that require these actions.
  78 The main disadvantage of this approach is that it ties ovs-vswitchd
  79 (and the Linux kernel module) to supporting these actions essentially
  80 forever, which means that we'd want to make sure that they are
  81 general-purpose, well designed, maintainable, and supportable.
  82
  83 The other way to do this is to send the packets across an OpenFlow
  84 channel to ovn-controller and have ovn-controller process them.  This
  85 is acceptable for actions that don't need high performance, and it
  86 means that we don't add anything permanently to ovs-vswitchd or the
  87 kernel (so we can be more casual about the design).  The big
  88 disadvantage is that it becomes necessary to add a way to resume the
  89 OpenFlow pipeline when it is interrupted in the middle by sending a
  90 packet to the controller.  This is not as simple as doing a new flow
  91 table lookup and resuming from that point.  Instead, it is equivalent
  92 to the (very complicated) recirculation logic in ofproto-dpif-xlate.c.
  93 Much of this logic can be translated into OpenFlow actions (e.g. the
  94 call stack and data stack), but some of it is entirely outside
  95 OpenFlow (e.g. the state of mirrors).  To implement it properly, it
  96 seems that we'll have to introduce a new Open vSwitch extension to
  97 OpenFlow, a "send-to-controller" action that causes extra data to be
  98 sent to the controller, where the extra data packages up the state
  99 necessary to resume the pipeline.  Maybe the bits of the state that
 100 can be represented in OpenFlow can be embedded in this extra data in a
 101 controller-readable form, but other bits we might want to be opaque.
 102 It's also likely that we'll want to change and extend the form of this
 103 opaque data over time, so this should be allowed for, e.g. by
 104 including a nonce in the extra data that is newly generated every time
 105 ovs-vswitchd starts.
 106
 107 *** OpenFlow action definitions
 108
 109 Define OpenFlow wire structures for each new OpenFlow action and
 110 implement them in lib/ofp-actions.[ch].
 111
 112 *** OVS implementation
 113
 114 Add code for action translation.  Possibly add datapath code for
 115 action implementation.  However, none of these new actions should
 116 require high-bandwidth processing so we could at least start with them
 117 implemented in userspace only.  (ARP field modification is already
 118 userspace-only and no one has complained yet.)
 119
 120 ** IPv6
 121
 122 *** ND versus ARP
 123
 124 *** IPv6 routing
 125
 126 *** ICMPv6
 127
 128 ** Dynamic IP to MAC bindings
 129
 130 Some bindings from IP address to MAC will undoubtedly need to be
 131 discovered dynamically through ARP requests.  It's straightforward
 132 enough for a logical L3 router to generate ARP requests and forward
 133 them to the appropriate switch.
 134
 135 It's more difficult to figure out where the reply should be processed
 136 and stored.  It might seem at first that a first-cut implementation
 137 could just keep track of the binding on the hypervisor that needs to
 138 know, but that can't happen easily because the VM that sends the reply
 139 might not be on the same HV as the VM that needs the answer (that is,
 140 the VM that sent the packet that needs the binding to be resolved) and
 141 there isn't an easy way for it to know which HV needs the answer.
 142
 143 Thus, the HV that processes the ARP reply (which is unknown when the
 144 ARP is sent) has to tell all the HVs the binding.  The most obvious
 145 place for this in the OVN_Southbound database.
 146
 147 Details need to be worked out, including:
 148
 149 *** OVN_Southbound schema changes.
 150
 151 Possibly bindings could be added to the Port_Binding table by adding
 152 or modifying columns.  Another possibility is that another table
 153 should be added.
 154
 155 *** Logical_Flow representation
 156
 157 It would be really nice to maintain the general-purpose nature of
 158 logical flows, but these bindings might have to include some
 159 hard-coded special cases, especially when it comes to the relationship
 160 with populating the bindings into the OVN_Southbound table.
 161
 162 *** Tracking queries
 163
 164 It's probably best to only record in the database responses to queries
 165 actually issued by an L3 logical router, so somehow they have to be
 166 tracked, probably by putting a tentative binding without a MAC address
 167 into the database.
 168
 169 *** Renewal and expiration.
 170
 171 Something needs to make sure that bindings remain valid and expire
 172 those that become stale.
 173
 174 ** MTU handling (fragmentation on output)
 175
 176 ** Ratelimiting.
 177
 178 *** ARP.
 179
 180 *** ICMP error generation, TCP reset, UDP unreachable, protocol unreachable, ...
 181
 182 As a point of comparison, Linux doesn't ratelimit TCP resets but I
 183 think it does everything else.
 184
 185 * ovn-controller
 186
 187 ** ovn-controller parameters and configuration.
 188
 189 *** SSL configuration.
 190
 191     Can probably get this from Open_vSwitch database.
 192
 193 ** Security
 194
 195 *** Limiting the impact of a compromised chassis.
 196
 197     Every instance of ovn-controller has the same full access to the central
 198     OVN_Southbound database.  This means that a compromised chassis can
 199     interfere with the normal operation of the rest of the deployment.  Some
 200     specific examples include writing to the logical flow table to alter
 201     traffic handling or updating the port binding table to claim ports that are
 202     actually present on a different chassis.  In practice, the compromised host
 203     would be fighting against ovn-northd and other instances of ovn-controller
 204     that would be trying to restore the correct state.  The impact could include
 205     at least temporarily redirecting traffic (so the compromised host could
 206     receive traffic that it shouldn't) and potentially a more general denial of
 207     service.
 208
 209     There are different potential improvements to this area.  The first would be
 210     to add some sort of ACL scheme to ovsdb-server.  A proposal for this should
 211     first include an ACL scheme for ovn-controller.  An example policy would
 212     be to make Logical_Flow read-only.  Table-level control is needed, but is
 213     not enough.  For example, ovn-controller must be able to update the Chassis
 214     and Encap tables, but should only be able to modify the rows associated with
 215     that chassis and no others.
 216
 217     A more complex example is the Port_Binding table.  Currently, ovn-controller
 218     is the source of truth of where a port is located.  There seems to be  no
 219     policy that can prevent malicious behavior of a compromised host with this
 220     table.
 221
 222     An alternative scheme for port bindings would be to provide an optional mode
 223     where an external entity controls port bindings and make them read-only to
 224     ovn-controller.  This is actually how OpenStack works today, for example.
 225     The part of OpenStack that manages VMs (Nova) tells the networking component
 226     (Neutron) where a port will be located, as opposed to the networking
 227     component discovering it.
 228
 229 * ovsdb-server
 230
 231   ovsdb-server should have adequate features for OVN but it probably
 232   needs work for scale and possibly for availability as deployments
 233   grow.  Here are some thoughts.
 234
 235   Andy Zhou is looking at these issues.
 236
 237 *** Reducing amount of data sent to clients.
 238
 239     Currently, whenever a row monitored by a client changes,
 240     ovsdb-server sends the client every monitored column in the row,
 241     even if only one column changes.  It might be valuable to reduce
 242     this only to the columns that changes.
 243
 244     Also, whenever a column changes, ovsdb-server sends the entire
 245     contents of the column.  It might be valuable, for columns that
 246     are sets or maps, to send only added or removed values or
 247     key-values pairs.
 248
 249     Currently, clients monitor the entire contents of a table.  It
 250     might make sense to allow clients to monitor only rows that
 251     satisfy specific criteria, e.g. to allow an ovn-controller to
 252     receive only Logical_Flow rows for logical networks on its hypervisor.
 253
 254 *** Reducing redundant data and code within ovsdb-server.
 255
 256     Currently, ovsdb-server separately composes database update
 257     information to send to each of its clients.  This is fine for a
 258     small number of clients, but it wastes time and memory when
 259     hundreds of clients all want the same updates (as will be in the
 260     case in OVN).
 261
 262     (This is somewhat opposed to the idea of letting a client monitor
 263     only some rows in a table, since that would increase the diversity
 264     among clients.)
 265
 266 *** Multithreading.
 267
 268     If it turns out that other changes don't let ovsdb-server scale
 269     adequately, we can multithread ovsdb-server.  Initially one might
 270     only break protocol handling into separate threads, leaving the
 271     actual database work serialized through a lock.
 272
 273 ** Increasing availability.
 274
 275    Database availability might become an issue.  The OVN system
 276    shouldn't grind to a halt if the database becomes unavailable, but
 277    it would become impossible to bring VIFs up or down, etc.
 278
 279    My current thought on how to increase availability is to add
 280    clustering to ovsdb-server, probably via the Raft consensus
 281    algorithm.  As an experiment, I wrote an implementation of Raft
 282    for Open vSwitch that you can clone from:
 283
 284        https://github.com/blp/ovs-reviews.git raft
 285
 286 ** Reducing startup time.
 287
 288    As-is, if ovsdb-server restarts, every client will fetch a fresh
 289    copy of the part of the database that it cares about.  With
 290    hundreds of clients, this could cause heavy CPU load on
 291    ovsdb-server and use excessive network bandwidth.  It would be
 292    better to allow incremental updates even across connection loss.
 293    One way might be to use "Difference Digests" as described in
 294    Epstein et al., "What's the Difference? Efficient Set
 295    Reconciliation Without Prior Context".  (I'm not yet aware of
 296    previous non-academic use of this technique.)
 297
 298 ** Support multiple tunnel encapsulations in Chassis.
 299
 300    So far, both ovn-controller and ovn-controller-vtep only allow
 301    chassis to have one tunnel encapsulation entry.  We should extend
 302    the implementation to support multiple tunnel encapsulations.
 303
 304 ** Update learned MAC addresses from VTEP to OVN
 305
 306    The VTEP gateway stores all MAC addresses learned from its
 307    physical interfaces in the 'Ucast_Macs_Local' and the
 308    'Mcast_Macs_Local' tables.  ovn-controller-vtep should be
 309    able to update that information back to ovn-sb database,
 310    so that other chassis know where to send packets destined
 311    to the extended external network instead of broadcasting.
 312
 313 ** Translate ovn-sb Multicast_Group table into VTEP config
 314
 315    The ovn-controller-vtep daemon should be able to translate
 316    the Multicast_Group table entry in ovn-sb database into
 317    Mcast_Macs_Remote table configuration in VTEP database.
 318
 319 * Use BFD as tunnel monitor.
 320
 321    Both ovn-controller and ovn-contorller-vtep should use BFD to
 322    monitor the tunnel liveness.  Both ovs-vswitchd schema and
 323    VTEP schema supports BFD.
 324
 325 * ACL
 326
 327 ** Support FTP ALGs.
 328
 329 ** Support reject action.
 330
 331 ** Support log option.