* 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.
-
-** OVN_SB schema
-
-*** Allow output to ingress port
-
-Sometimes when a packet ingresses into a router, it has to egress the
-same port. One example is a "one-armed" router that has multiple
-routes on a single port (or in which a host is (mis)configured to send
-every IP packet to the router, e.g. due to a bad netmask). Another is
-when a router needs to send an ICMP reply to an ingressing packet.
-
-To some degree this problem is layered, because there are two
-different notions of "ingress port". The first is the OpenFlow
-ingress port, essentially a physical port identifier. This is
-implemented as part of ovs-vswitchd's OpenFlow implementation. It
-prevents a reply from being sent across the tunnel on which it
-arrived. It is questionable whether this OpenFlow feature is useful
-to OVN. (OVN already has to override it to allow a packet from one
-nested container to be forwarded to a different nested container.)
-OVS make it possible to disable this feature of OpenFlow by setting
-the OpenFlow input port field to 0. (If one does this too early, of
-course, it means that there's no way to actually match on the input
-port in the OpenFlow flow tables, but one can work around that by
-instead setting the input port just before the output action, possibly
-wrapping these actions in push/pop pairs to preserve the input port
-for later.)
-
-The second is the OVN logical ingress port, which is implemented in
-ovn-controller as part of the logical abstraction, using an OVS
-register. Dropping packets directed to the logical ingress port is
-implemented through an OpenFlow table not directly visible to the
-logical flow table. Currently this behavior can't be disabled, but
-various ways to ensure it could be implemented, e.g. the same as for
-OpenFlow by allowing the logical inport to be zeroed, or by
-introducing a new action that ignores the inport.
-
** New OVN logical actions
*** arp
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
(Neutron) where a port will be located, as opposed to the networking
component discovering it.
+** Gratuitous ARP generation
+
+ ovn-controller should generate a GARP when a port is bound to a chassis.
+ This is needed when ports are migrated from one chassis to another, such
+ as live migrating a VM.
+
* ovsdb-server
ovsdb-server should have adequate features for OVN but it probably
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.
+
+ When OVN gets to supporting HA for gateways (see ovn/OVN-GW-HA.md), BFD is
+ likely needed as a part of that solution.
- Both ovn-controller and ovn-contorller-vtep should use BFD to
- monitor the tunnel liveness. Both ovs-vswitchd schema and
- VTEP schema supports BFD.
+ There's more commentary in this ML post:
+ http://openvswitch.org/pipermail/dev/2015-November/062385.html
* ACL
projects / cascardo / ovs.git / blobdiff