X-Git-Url: http://git.cascardo.eti.br/?a=blobdiff_plain;f=ovn%2FTODO;h=2c696a0749efdbdbc7d8176758710b689c912aa0;hb=d0a46cb4608e632f5028034762f0adde2ce947a0;hp=10c3adff3e47dc4f79e306069787f38812b9a761;hpb=9975d7beb36ab3aadfd07c9d566f8d3d1d340fc4;p=cascardo%2Fovs.git diff --git a/ovn/TODO b/ovn/TODO index 10c3adff3..2c696a074 100644 --- a/ovn/TODO +++ b/ovn/TODO @@ -2,51 +2,6 @@ * 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 @@ -95,63 +50,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 @@ -261,6 +159,12 @@ think it does everything else. (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 @@ -351,11 +255,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. + + 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