ovn: Apply ACL changes to existing connections.
[cascardo/ovs.git] / ovn / TODO
index 7f69508..fd15f5d 100644 (file)
--- a/ovn/TODO
+++ b/ovn/TODO
@@ -2,30 +2,8 @@
 
 * L3 support
 
-** OVN_Northbound schema
-
-*** Needs to support extra routes
-
-Currently a router port has a single route associated with it, but
-presumably we should support multiple routes.  For connections from
-one router to another, this doesn't seem to matter (just put more than
-one connection between them), but for connections between a router and
-a switch it might matter because a switch has only one router port.
-
 ** New OVN logical actions
 
-*** arp
-
-Generates an ARP packet based on the current IPv4 packet and allows it
-to be processed as part of the current pipeline (and then pop back to
-processing the original IPv4 packet).
-
-TCP/IP stacks typically limit the rate at which ARPs are sent, e.g. to
-one per second for a given target.  We might need to do this too.
-
-We probably need to buffer the packet that generated the ARP.  I don't
-know where to do that.
-
 *** icmp4 { action... }
 
 Generates an ICMPv4 packet based on the current IPv4 packet and
@@ -60,63 +38,6 @@ ovn-sb.xml includes a tentative specification for this action.
 IPv6 will probably need an action or actions for ND that is similar to
 the "arp" action, and an action for generating
 
-*** ovn-controller translation to OpenFlow
-
-The following two translation strategies come to mind.  Some of the
-new actions we might want to implement one way, some of them the
-other, depending on the details.
-
-*** Implementation strategies
-
-One way to do this is to define new actions as Open vSwitch extensions
-to OpenFlow, emit those actions in ovn-controller, and implement them
-in ovs-vswitchd (possibly pushing the implementations into the Linux
-and DPDK datapaths as well).  This is the only acceptable way for
-actions that need high performance.  None of these actions obviously
-need high performance, but it might be necessary to have fairness in
-handling e.g. a flood of incoming packets that require these actions.
-The main disadvantage of this approach is that it ties ovs-vswitchd
-(and the Linux kernel module) to supporting these actions essentially
-forever, which means that we'd want to make sure that they are
-general-purpose, well designed, maintainable, and supportable.
-
-The other way to do this is to send the packets across an OpenFlow
-channel to ovn-controller and have ovn-controller process them.  This
-is acceptable for actions that don't need high performance, and it
-means that we don't add anything permanently to ovs-vswitchd or the
-kernel (so we can be more casual about the design).  The big
-disadvantage is that it becomes necessary to add a way to resume the
-OpenFlow pipeline when it is interrupted in the middle by sending a
-packet to the controller.  This is not as simple as doing a new flow
-table lookup and resuming from that point.  Instead, it is equivalent
-to the (very complicated) recirculation logic in ofproto-dpif-xlate.c.
-Much of this logic can be translated into OpenFlow actions (e.g. the
-call stack and data stack), but some of it is entirely outside
-OpenFlow (e.g. the state of mirrors).  To implement it properly, it
-seems that we'll have to introduce a new Open vSwitch extension to
-OpenFlow, a "send-to-controller" action that causes extra data to be
-sent to the controller, where the extra data packages up the state
-necessary to resume the pipeline.  Maybe the bits of the state that
-can be represented in OpenFlow can be embedded in this extra data in a
-controller-readable form, but other bits we might want to be opaque.
-It's also likely that we'll want to change and extend the form of this
-opaque data over time, so this should be allowed for, e.g. by
-including a nonce in the extra data that is newly generated every time
-ovs-vswitchd starts.
-
-*** OpenFlow action definitions
-
-Define OpenFlow wire structures for each new OpenFlow action and
-implement them in lib/ofp-actions.[ch].
-
-*** OVS implementation
-
-Add code for action translation.  Possibly add datapath code for
-action implementation.  However, none of these new actions should
-require high-bandwidth processing so we could at least start with them
-implemented in userspace only.  (ARP field modification is already
-userspace-only and no one has complained yet.)
-
 ** IPv6
 
 *** ND versus ARP
@@ -127,37 +48,16 @@ userspace-only and no one has complained yet.)
 
 ** Dynamic IP to MAC bindings
 
-Some bindings from IP address to MAC will undoubtedly need to be
-discovered dynamically through ARP requests.  It's straightforward
-enough for a logical L3 router to generate ARP requests and forward
-them to the appropriate switch.
-
-It's more difficult to figure out where the reply should be processed
-and stored.  It might seem at first that a first-cut implementation
-could just keep track of the binding on the hypervisor that needs to
-know, but that can't happen easily because the VM that sends the reply
-might not be on the same HV as the VM that needs the answer (that is,
-the VM that sent the packet that needs the binding to be resolved) and
-there isn't an easy way for it to know which HV needs the answer.
+OVN has basic support for establishing IP to MAC bindings dynamically,
+using ARP.
 
-Thus, the HV that processes the ARP reply (which is unknown when the
-ARP is sent) has to tell all the HVs the binding.  The most obvious
-place for this in the OVN_Southbound database.
+*** Ratelimiting.
 
-Details need to be worked out, including:
+From casual observation, Linux appears to generate at most one ARP per
+second per destination.
 
-*** OVN_Southbound schema changes.
-
-Possibly bindings could be added to the Port_Binding table by adding
-or modifying columns.  Another possibility is that another table
-should be added.
-
-*** Logical_Flow representation
-
-It would be really nice to maintain the general-purpose nature of
-logical flows, but these bindings might have to include some
-hard-coded special cases, especially when it comes to the relationship
-with populating the bindings into the OVN_Southbound table.
+This might be supported by adding a new OVN logical action for
+rate-limiting.
 
 *** Tracking queries
 
@@ -171,16 +71,15 @@ into the database.
 Something needs to make sure that bindings remain valid and expire
 those that become stale.
 
-** MTU handling (fragmentation on output)
-
-** Ratelimiting.
+One way to do this might be to add some support for time to the
+database server itself.
 
-*** ARP.
+*** Table size limiting.
 
-*** ICMP error generation, TCP reset, UDP unreachable, protocol unreachable, ...
+The table of MAC bindings must not be allowed to grow unreasonably
+large.
 
-As a point of comparison, Linux doesn't ratelimit TCP resets but I
-think it does everything else.
+** MTU handling (fragmentation on output)
 
 * ovn-controller
 
@@ -316,11 +215,18 @@ think it does everything else.
    the Multicast_Group table entry in ovn-sb database into
    Mcast_Macs_Remote table configuration in VTEP database.
 
-* Use BFD as tunnel monitor.
+* Consider the use of BFD as tunnel monitor.
+
+  The use of BFD for hypervisor-to-hypervisor tunnels is probably not worth it,
+  since there's no alternative to switch to if a tunnel goes down.  It could
+  make sense at a slow rate if someone does OVN monitoring system integration,
+  but not otherwise.
 
-   Both ovn-controller and ovn-contorller-vtep should use BFD to
-   monitor the tunnel liveness.  Both ovs-vswitchd schema and
-   VTEP schema supports BFD.
+  When OVN gets to supporting HA for gateways (see ovn/OVN-GW-HA.md), BFD is
+  likely needed as a part of that solution.
+
+  There's more commentary in this ML post:
+  http://openvswitch.org/pipermail/dev/2015-November/062385.html
 
 * ACL
 
@@ -329,3 +235,9 @@ think it does everything else.
 ** Support reject action.
 
 ** Support log option.
+
+** We currently use ct_label[0] to mark connections that have been blocked
+   by an ACL.  It would be nice in the logical flow syntax to have a
+   symbolic name like "ct_label.blocked" to make things more clear, as
+   well as to change the implementation of "blocked" in the future
+   if needed.