ovn: Update TODO for items that have been completed.

I think that all of these items are either done now or just simply don't
need this level of detail.

Signed-off-by: Ben Pfaff <blp@ovn.org>

1 files changed, 10 insertions, 102 deletions

diff --git a/ovn/TODO b/ovn/TODO
index dab86481e..3e69927e7 100644
--- a/ovn/TODO
+++ b/ovn/TODO
@@ -2,69 +2,16 @@
 
 * L3 support
 
-** New OVN logical actions
+** Logical routers should send RST replies to TCP packets.
 
-*** icmp4 { action... }
+** IPv6 router ports should periodically send ND Router Advertisements.
 
-Generates an ICMPv4 packet based on the current IPv4 packet and
-processes it according to each nested action (and then pops back to
-processing the original IPv4 packet).  The intended use case is for
-generating "time exceeded" and "destination unreachable" errors.
-
-ovn-sb.xml includes a tentative specification for this action.
-
-Tentatively, the icmp4 action sets a default icmp_type and icmp_code
-and lets the nested actions override it.  This means that we'd have to
-make icmp_type and icmp_code writable.  Because changing icmp_type and
-icmp_code can change the interpretation of the rest of the data in the
-ICMP packet, we would want to think this through carefully.  If it
-seems like a bad idea then we could instead make the type and code a
-parameter to the action: icmp4(type, code) { action... }
-
-It is worth considering what should be considered the ingress port for
-the ICMPv4 packet.  It's quite likely that the ICMPv4 packet is going
-to go back out the ingress port.  Maybe the icmp4 action, therefore,
-should clear the inport, so that output to the original inport won't
-be discarded.
-
-*** tcp_reset
-
-Transforms the current TCP packet into a RST reply.
-
-ovn-sb.xml includes a tentative specification for this action.
-
-*** Other actions for IPv6.
-
-IPv6 will probably need an action or actions for ND that is similar to
-the "arp" action, and an action for generating
-
-** IPv6
-
-*** Drop invalid source IPv6 addresses
-
-*** Don't forward non-routable addresses
-
-*** ICMPv6 action
-
-Similar to the ICMPv4 action, ICMPv6 messages should be generated.
-
-*** Neighbor Discovery
-
-**** ND Router Advertisements
-
-The router ports should periodically send out ND Router Advertisements
-and respond to Router Solicitations.
-
-**** Learn MAC bindings on ND Solicitations
-
-**** Properly set RSO flags
-
-** Dynamic IP to MAC bindings
+* Dynamic IP to MAC binding enhancements.
 
 OVN has basic support for establishing IP to MAC bindings dynamically,
 using ARP.
 
-*** Ratelimiting.
+** Ratelimiting.
 
 From casual observation, Linux appears to generate at most one ARP per
 second per destination.
@@ -72,14 +19,14 @@ second per destination.
 This might be supported by adding a new OVN logical action for
 rate-limiting.
 
-*** Tracking queries
+** Tracking queries
 
 It's probably best to only record in the database responses to queries
 actually issued by an L3 logical router, so somehow they have to be
 tracked, probably by putting a tentative binding without a MAC address
 into the database.
 
-*** Renewal and expiration.
+** Renewal and expiration.
 
 Something needs to make sure that bindings remain valid and expire
 those that become stale.
@@ -87,24 +34,16 @@ those that become stale.
 One way to do this might be to add some support for time to the
 database server itself.
 
-*** Table size limiting.
+** Table size limiting.
 
 The table of MAC bindings must not be allowed to grow unreasonably
 large.
 
 ** MTU handling (fragmentation on output)
 
-* ovn-controller
-
-** ovn-controller parameters and configuration.
+* Security
 
-*** SSL configuration.
-
-    Can probably get this from Open_vSwitch database.
-
-** Security
-
-*** Limiting the impact of a compromised chassis.
+** Limiting the impact of a compromised chassis.
 
     Every instance of ovn-controller has the same full access to the central
     OVN_Southbound database.  This means that a compromised chassis can
@@ -144,38 +83,7 @@ large.
   needs work for scale and possibly for availability as deployments
   grow.  Here are some thoughts.
 
-  Andy Zhou is looking at these issues.
-
-*** Reducing amount of data sent to clients.
-
-    Currently, whenever a row monitored by a client changes,
-    ovsdb-server sends the client every monitored column in the row,
-    even if only one column changes.  It might be valuable to reduce
-    this only to the columns that changes.
-
-    Also, whenever a column changes, ovsdb-server sends the entire
-    contents of the column.  It might be valuable, for columns that
-    are sets or maps, to send only added or removed values or
-    key-values pairs.
-
-    Currently, clients monitor the entire contents of a table.  It
-    might make sense to allow clients to monitor only rows that
-    satisfy specific criteria, e.g. to allow an ovn-controller to
-    receive only Logical_Flow rows for logical networks on its hypervisor.
-
-*** Reducing redundant data and code within ovsdb-server.
-
-    Currently, ovsdb-server separately composes database update
-    information to send to each of its clients.  This is fine for a
-    small number of clients, but it wastes time and memory when
-    hundreds of clients all want the same updates (as will be in the
-    case in OVN).
-
-    (This is somewhat opposed to the idea of letting a client monitor
-    only some rows in a table, since that would increase the diversity
-    among clients.)
-
-*** Multithreading.
+** Multithreading.
 
     If it turns out that other changes don't let ovsdb-server scale
     adequately, we can multithread ovsdb-server.  Initially one might