-* Flow match expression handling library.
+-*- outline -*-
- ovn-controller is the primary user of flow match expressions, but
- the same syntax and I imagine the same code ought to be useful in
- ovn-nbd for ACL match expressions.
+* L3 support
-** Definition of data structures to represent a match expression as a
- syntax tree.
+** New OVN logical actions
-** Definition of data structures to represent variables (fields).
+*** arp
- Fields need names and prerequisites. Most fields are numeric and
- thus need widths. We need also need a way to represent nominal
- fields (currently just logical port names). It might be
- appropriate to associate fields directly with OXM/NXM code points;
- we have to decide whether we want OVN to use the OVS flow structure
- or work with OXM more directly.
+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).
- Probably should be defined so that the data structure is also
- useful for references to fields in action parsing.
+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.
-** Lexical analysis.
+We probably need to buffer the packet that generated the ARP. I don't
+know where to do that.
- Probably should be defined so that the lexer can be reused for
- parsing actions.
+*** icmp4 { action... }
-** Parsing into syntax tree.
+Generates an ICMPv4 packet based on the current IPv4 packet and
+processes it according to each nested action (and then pops back to
+processing the original IPv4 packet). The intended use case is for
+generating "time exceeded" and "destination unreachable" errors.
-** Semantic checking against variable definitions.
+ovn-sb.xml includes a tentative specification for this action.
-** Applying prerequisites.
+Tentatively, the icmp4 action sets a default icmp_type and icmp_code
+and lets the nested actions override it. This means that we'd have to
+make icmp_type and icmp_code writable. Because changing icmp_type and
+icmp_code can change the interpretation of the rest of the data in the
+ICMP packet, we would want to think this through carefully. If it
+seems like a bad idea then we could instead make the type and code a
+parameter to the action: icmp4(type, code) { action... }
-** Simplification into conjunction-of-disjunctions (CoD) form.
+It is worth considering what should be considered the ingress port for
+the ICMPv4 packet. It's quite likely that the ICMPv4 packet is going
+to go back out the ingress port. Maybe the icmp4 action, therefore,
+should clear the inport, so that output to the original inport won't
+be discarded.
-** Transformation from CoD form into OXM matches.
+*** tcp_reset
-* ovn-controller
-
-** Flow table handling in ovn-controller.
+Transforms the current TCP packet into a RST reply.
- ovn-controller has to transform logical datapath flows from the
- database into OpenFlow flows.
+ovn-sb.xml includes a tentative specification for this action.
-*** Definition (or choice) of data structure for flows and flow table.
+*** Other actions for IPv6.
- It would be natural enough to use "struct flow" and "struct
- classifier" for this. Maybe that is what we should do. However,
- "struct classifier" is optimized for searches based on packet
- headers, whereas all we care about here can be implemented with a
- hash table. Also, we may want to make it easy to add and remove
- support for fields without recompiling, which is not possible with
- "struct flow" or "struct classifier".
+IPv6 will probably need an action or actions for ND that is similar to
+the "arp" action, and an action for generating
- On the other hand, we may find that it is difficult to decide that
- two OXM flow matches are identical (to normalize them) without a
- lot of domain-specific knowledge that is already embedded in struct
- flow. It's also going to be a pain to come up with a way to make
- anything other than "struct flow" work with the ofputil_*()
- functions for encoding and decoding OpenFlow.
+** IPv6
- It's also possible we could use struct flow without struct
- classifier.
+*** ND versus ARP
-*** Assembling conjunctive flows from flow match expressions.
+*** IPv6 routing
- This transformation explodes logical datapath flows into multiple
- OpenFlow flow table entries, since a flow match expression in CoD
- form requires several OpenFlow flow table entries. It also
- requires merging together OpenFlow flow tables entries that contain
- "conjunction" actions (really just concatenating their actions).
+*** ICMPv6
-*** Translating logical datapath port names into port numbers.
+** Dynamic IP to MAC bindings
- Logical ports are specified by name in logical datapath flows, but
- OpenFlow only works in terms of numbers.
+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.
-*** Translating logical datapath actions into OpenFlow actions.
+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.
- Some of the logical datapath actions do not have natural
- representations as OpenFlow actions: they require
- packet-in/packet-out round trips through ovn-controller. The
- trickiest part of that is going to be making sure that the
- packet-out resumes the control flow that was broken off by the
- packet-in. That's tricky; we'll probably have to restrict control
- flow or add OVS features to make resuming in general possible. Not
- sure which is better at this point.
+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.
-*** OpenFlow flow table synchronization.
+Details need to be worked out, including:
- The internal representation of the OpenFlow flow table has to be
- synced across the controller connection to OVS. This probably
- boils down to the "flow monitoring" feature of OF1.4 which was then
- made available as a "standard extension" to OF1.3. (OVS hasn't
- implemented this for OF1.4 yet, but the feature is based on a OVS
- extension to OF1.0, so it should be straightforward to add it.)
+*** OVN_Southbound schema changes.
- We probably need some way to catch cases where OVS and OVN don't
- see eye-to-eye on what exactly constitutes a flow, so that OVN
- doesn't waste a lot of CPU time hammering at OVS trying to install
- something that it's not going to do.
+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/physical translation.
+*** Logical_Flow representation
- When a packet comes into the integration bridge, the first stage of
- processing needs to translate it from a physical to a logical
- context. When a packet leaves the integration bridge, the final
- stage of processing needs to translate it back into a physical
- context. ovn-controller needs to populate the OpenFlow flows
- tables to do these translations.
+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.
-*** Determine how to split logical pipeline across physical nodes.
+*** Tracking queries
- From the original OVN architecture document:
+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.
- The pipeline processing is split between the ingress and egress
- transport nodes. In particular, the logical egress processing may
- occur at either hypervisor. Processing the logical egress on the
- ingress hypervisor requires more state about the egress vif's
- policies, but reduces traffic on the wire that would eventually be
- dropped. Whereas, processing on the egress hypervisor can reduce
- broadcast traffic on the wire by doing local replication. We
- initially plan to process logical egress on the egress hypervisor
- so that less state needs to be replicated. However, we may change
- this behavior once we gain some experience writing the logical
- flows.
+*** Renewal and expiration.
- The split pipeline processing split will influence how tunnel keys
- are encoded.
+Something needs to make sure that bindings remain valid and expire
+those that become stale.
-** Interaction with Open_vSwitch and OVN databases:
+** MTU handling (fragmentation on output)
-*** Monitor Chassis table in OVN.
+** Ratelimiting.
- Populate Port records for tunnels to other chassis into
- Open_vSwitch database. As a scale optimization later on, one can
- populate only records for tunnels to other chassis that have
- logical networks in common with this one.
+*** ARP.
-*** Monitor Pipeline table in OVN, trigger flow table recomputation on change.
+*** ICMP error generation, TCP reset, UDP unreachable, protocol unreachable, ...
-** ovn-controller parameters and configuration.
+As a point of comparison, Linux doesn't ratelimit TCP resets but I
+think it does everything else.
-*** Tunnel encapsulation to publish.
+* ovn-controller
- Default: VXLAN? Geneve?
+** ovn-controller parameters and configuration.
*** SSL configuration.
Can probably get this from Open_vSwitch database.
-* ovn-nbd
-
-** Monitor OVN_Northbound database, trigger Pipeline recomputation on change.
-
-** Translate each OVN_Northbound entity into Pipeline logical datapath flows.
-
- We have to first sit down and figure out what the general
- translation of each entity is. The original OVN architecture
- description at
- http://openvswitch.org/pipermail/dev/2015-January/050380.html had
- some sketches of these, but they need to be completed and
- elaborated.
-
- Initially, the simplest way to do this is probably to write
- straight C code to do a full translation of the entire
- OVN_Northbound database into the format for the Pipeline table in
- the OVN Southbound database. As scale increases, this will probably
- be too inefficient since a small change in OVN_Northbound requires a
- full recomputation. At that point, we probably want to adopt a more
- systematic approach, such as something akin to the "nlog" system used
- in NVP (see Koponen et al. "Network Virtualization in Multi-tenant
- Datacenters", NSDI 2014).
-
-** Push logical datapath flows to Pipeline table.
-
-** Monitor OVN Southbound database Bindings table.
-
- Sync rows in the OVN Bindings table to the "up" column in the
- OVN_Northbound database.
+** Security
+
+*** Limiting the impact of a compromised chassis.
+
+ Every instance of ovn-controller has the same full access to the central
+ OVN_Southbound database. This means that a compromised chassis can
+ interfere with the normal operation of the rest of the deployment. Some
+ specific examples include writing to the logical flow table to alter
+ traffic handling or updating the port binding table to claim ports that are
+ actually present on a different chassis. In practice, the compromised host
+ would be fighting against ovn-northd and other instances of ovn-controller
+ that would be trying to restore the correct state. The impact could include
+ at least temporarily redirecting traffic (so the compromised host could
+ receive traffic that it shouldn't) and potentially a more general denial of
+ service.
+
+ There are different potential improvements to this area. The first would be
+ to add some sort of ACL scheme to ovsdb-server. A proposal for this should
+ first include an ACL scheme for ovn-controller. An example policy would
+ be to make Logical_Flow read-only. Table-level control is needed, but is
+ not enough. For example, ovn-controller must be able to update the Chassis
+ and Encap tables, but should only be able to modify the rows associated with
+ that chassis and no others.
+
+ A more complex example is the Port_Binding table. Currently, ovn-controller
+ is the source of truth of where a port is located. There seems to be no
+ policy that can prevent malicious behavior of a compromised host with this
+ table.
+
+ An alternative scheme for port bindings would be to provide an optional mode
+ where an external entity controls port bindings and make them read-only to
+ ovn-controller. This is actually how OpenStack works today, for example.
+ The part of OpenStack that manages VMs (Nova) tells the networking component
+ (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
Andy Zhou is looking at these issues.
-** Scaling number of connections.
-
- In typical use today a given ovsdb-server has only a single-digit
- number of simultaneous connections. The OVN Southbound database will
- have a connection from every hypervisor. This use case needs testing
- and probably coding work. Here are some possible improvements.
-
*** Reducing amount of data sent to clients.
Currently, whenever a row monitored by a client changes,
Currently, clients monitor the entire contents of a table. It
might make sense to allow clients to monitor only rows that
satisfy specific criteria, e.g. to allow an ovn-controller to
- receive only Pipeline rows for logical networks on its hypervisor.
+ receive only Logical_Flow rows for logical networks on its hypervisor.
*** Reducing redundant data and code within ovsdb-server.
Reconciliation Without Prior Context". (I'm not yet aware of
previous non-academic use of this technique.)
-* Miscellaneous:
+** Support multiple tunnel encapsulations in Chassis.
+
+ So far, both ovn-controller and ovn-controller-vtep only allow
+ chassis to have one tunnel encapsulation entry. We should extend
+ the implementation to support multiple tunnel encapsulations.
+
+** Update learned MAC addresses from VTEP to OVN
-** Write ovn-nbctl utility.
+ The VTEP gateway stores all MAC addresses learned from its
+ physical interfaces in the 'Ucast_Macs_Local' and the
+ 'Mcast_Macs_Local' tables. ovn-controller-vtep should be
+ able to update that information back to ovn-sb database,
+ so that other chassis know where to send packets destined
+ to the extended external network instead of broadcasting.
- The idea here is that we need a utility to act on the OVN_Northbound
- database in a way similar to a CMS, so that we can do some testing
- without an actual CMS in the picture.
+** Translate ovn-sb Multicast_Group table into VTEP config
- No details yet.
+ The ovn-controller-vtep daemon should be able to translate
+ the Multicast_Group table entry in ovn-sb database into
+ Mcast_Macs_Remote table configuration in VTEP database.
-** Init scripts for ovn-controller (on HVs), ovn-nbd, OVN DB server.
+* Consider the use of BFD as tunnel monitor.
-** Distribution packaging.
+ 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.
-* Not yet scoped:
+ When OVN gets to supporting HA for gateways (see ovn/OVN-GW-HA.md), BFD is
+ likely needed as a part of that solution.
-** Neutron plugin.
+ There's more commentary in this ML post:
+ http://openvswitch.org/pipermail/dev/2015-November/062385.html
- This is being developed on OpenStack's development infrastructure
- to be along side most of the other Neutron plugins.
+* ACL
- http://git.openstack.org/cgit/stackforge/networking-ovn
+** Support FTP ALGs.
- http://git.openstack.org/cgit/stackforge/networking-ovn/tree/doc/source/todo.rst
+** Support reject action.
-** Gateways.
+** Support log option.
projects / cascardo / ovs.git / blobdiff