3 ** ovn-controller parameters and configuration.
7 Can probably get this from Open_vSwitch database.
11 *** Limiting the impact of a compromised chassis.
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
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.
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
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.
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.
51 Andy Zhou is looking at these issues.
53 *** Reducing amount of data sent to clients.
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.
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
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.
70 *** Reducing redundant data and code within ovsdb-server.
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
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
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.
89 ** Increasing availability.
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.
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:
100 https://github.com/blp/ovs-reviews.git raft
102 ** Reducing startup time.
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.)
114 ** Support multiple tunnel encapsulations in Chassis.
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.
120 ** Update learned MAC addresses from VTEP to OVN
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.
129 ** Translate ovn-sb Multicast_Group table into VTEP config
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.
135 * Use BFD as tunnel monitor.
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.
145 ** Support reject action.
147 ** Support log option.