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