* 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.
-
-*** Logical router port names in ACLs
-
-Currently the ACL table documents that the logical router port is
-always named "ROUTER". This can't work directly using logical patch
-ports to connect a logical switch to its logical router, because every
-row in the Logical_Port table must have a unique name. This probably
-means that we should change the convention for the ACL table so that
-the logical router port name is unique; for example, we could change
-the Logical_Router_Port table to require the 'name' column to be
-unique, and then use that name in the ACL table.
-
-Another alternative would be to add a way to have aliases for logical
-ports, but I'm not sure that's a rathole we really want to go down.
-
-** 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.
-
-** ovn-northd
-
-*** What flows should it generate?
-
-See description in ovn-northd(8).
-
** 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
*** ICMPv6
-** IP to MAC binding
-
-Somehow it has to be possible for an L3 logical router to map from an
-IP address to an Ethernet address. This can happen statically or
-dynamically. Probably both cases need to be supported eventually.
-
-*** Static IP to MAC binding
-
-Commonly, for a VM, the binding of an IP address to a MAC is known
-statically. The Logical_Port table in the OVN_Northbound schema can
-be revised to make these bindings known. Then ovn-northd can
-integrate the bindings into the logical router flow table.
-(ovn-northd can also integrate them into the logical switch flow table
-to terminate ARP requests from VIFs.)
-
-*** Dynamic IP to MAC bindings
+** 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
Details need to be worked out, including:
-**** OVN_Southbound schema changes.
+*** 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
+*** 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.
-**** 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.
-*** MTU handling (fragmentation on output)
+** MTU handling (fragmentation on output)
** Ratelimiting.
(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