* 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
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
** 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
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
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
** 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.