Anyone is welcome to work on anything relevant to Open vSwitch at the hackathon. For those who are looking for something to do, here is a list of specific project ideas. I will bring this list, broken down into individual printed items, to Cisco with me in the morning, so consider this a preview to scan through and provoke thoughts if you happen to read it before the hackathon begins.
Most of this list is from me, with contributions from others, so feel free to direct questions toward me. Programming Project Ideas ========================= Each of these projects would ideally result in a patch or a short series of them posted to ovs-dev. Please read SubmittingPatches and CodingStyle in the top of the source tree before you begin work. The OPENFLOW-1.1+ file also has an introduction to how OpenFlow is implemented in Open vSwitch. It is also a good idea to look around the source tree for related code, and back through the Git history for commits on related subjects, to allow you to follow existing patterns and conventions. Improve linking speed --------------------- Changing one of the files in the Open vSwitch ``lib'' directory causes 43 binaries to be relinked, which takes a lot of time even with parallel ``make''. 31 of those binaries are in the ``tests'' directory. This project would combine most of those binaries into a single test program that just takes a subcommand name as its first command-line argument, because linking one larger program or even half a dozen would be much faster than linking 31 small programs. (Some of the test programs already take a subcommand name.) One would not want to combine the source code for all the programs into a single C file, however. Meters ------ Open vSwitch has OpenFlow protocol support for meters, but it does not have an implementation in the kernel or userspace datapaths. An implementation was proposed some time ago (I recommend looking for the discussion in the ovs-dev mailing list archives), but for a few different reasons it was not accepted. Some of those reasons apply only to a kernel implementation of meters. At the time, a userspace implementation wasn't as interesting, because the userspace switch did not perform at a production speed, but with the advent of multithreaded forwarding and, now, DPDK support, userspace-only meters would be a great way to get started. This project might take longer than two days. Improve SSL/TLS Security ------------------------ Open vSwitch allows some weak ciphers to be used for its secure connections. Security audits often suggest that the project remove those ciphers, but there's not a clean way to modify the acceptable ciphers. At the very least, the cipher list should be audited, but it would be nice to make it configurable. Open vSwitch does not insist on perfect forward security via ephemeral Diffie-Hellman key exchange when it establishes an SSL/TLS connection. Given the wiretapping revelations over the last year, it seems wise to turn this on. (This would probably amount to finding the right OpenSSL function to call or just reducing the acceptable ciphers further.) These changes might have backward-compatibility implications; one would have to test the behavior of the reduced cipher list OVS against older versions. Improve ovs-vsctl error reporting --------------------------------- ovs-vsctl is a command-line interface to the Open vSwitch database, and as such it just modifies the desired Open vSwitch configuration in the database. ovs-vswitchd, on the other hand, monitors the database and implements the actual configuration specified in the database. This can lead to surprises when the user makes a change to the database, with ovs-vsctl, that ovs-vswitchd cannot actually implement. In such a case, the ovs-vsctl command silently succeeds (because the database was successfully updated) but its desired effects don't actually take place. One good example of such a change is attempting to add a port with a misspelled name (e.g. ``ovs-vsctl add-port br0 fth0'', where fth0 should be eth0); another is creating a bridge or a port whose name is longer than supported (e.g. ``ovs-vsctl add-br'' with a 16-character bridge name on Linux). It can take users a long time to realize the error, because it requires looking through the ovs-vswitchd log. One way to improve the situation would be for ovs-vsctl to check whether operations that it executes succeed and report an error when they do not. ovs-vsctl can do this for add-br and add-port operations, for example, by examining the ``ofport'' value that ovs-vswitchd stores into the database record for the newly created interface. Until ovs-vswitchd finishes implementing the new configuration, this column is empty, and after it finishes it is either -1 (on failure) or a positive number (on success). One tricky part of this project is that the database can change asynchronously. For example, it is possible that some other database client deletes a port that ovs-vsctl adds before ovs-vswitchd finishes configuring. For that matter, a single ovs-vsctl run can both add and delete a port or a bridge (e.g. ``ovs-vsctl add-br br0 -- del-br br0''). The new code will have to act sensibly in both of these cases. ovs-vsctl doesn't always wait for ovs-vswitchd to finish configuring, if given the --no-wait command line option. In these cases one would not expect ovs-vsctl to attempt to report these errors. OpenFlow Group Bucket Stats --------------------------- When OpenFlow group support was added, we forgot to support statistics for individual buckets. xlate_group_bucket() in ofproto/ofproto-dpif-xlate.c appears to be where we need to increment the counters, in the case where ctx->xin->resubmit_stats is nonnull. See the ovs-dev thread starting here: http://openvswitch.org/pipermail/dev/2014-January/036107.html Bash Command Completion ----------------------- ovs-vsctl and other programs would be easier to use if bash command completion (with ``tab'', etc.) were supported. Alex Wang <al...@nicira.com> is planning to lead a team for this project. Auxiliary Connections --------------------- Auxiliary connections are a feature of OpenFlow 1.3 and later that allow OpenFlow messages to be carried over datagram channels such as UDP or DTLS. One place to start would be to implement a datagram abstraction library for OVS analogous to the ``stream'' library that already abstracts TCP, SSL, and other stream protocols. Python Logging Formatting Improvements -------------------------------------- The Open vSwitch daemons written in C support user-configured logging patterns as described in ovs-appctl(8). The Python daemons don't support configuring the logging pattern. This project would be to add support for the same options in Python as are already supported in C. Controller connection logging to pcap file ------------------------------------------ http://patchwork.openvswitch.org/patch/2249/ is an RFC patch that allows the switch to record the traffic on OpenFlow controller connections to a pcap file for later analysis. The patch lacks a good way to enable and disable the feature. The task here would be to add that and repost the patch. Basic OpenFlow 1.4 support -------------------------- Some basic support for OpenFlow 1.4 is missing and needs to be implemented. These can be found by looking through lib/ofp-util.c for mentions of OFP14_VERSION followed by a call to OVS_NOT_REACHED (which aborts the program). OpenFlow 1.4: Flow monitoring ----------------------------- OpenFlow 1.4 introduces OFPMP_FLOW_MONITOR for notifying a controller of changes to selected flow tables. This feature is based on NXST_FLOW_MONITOR that is already part of Open vSwitch, so to implement this feature would be to extend that code to handle the OpenFlow 1.4 wire protocol. OpenFlow 1.3 also includes this feature as a ONF-defined extension, so ideally OVS would support that too. OpenFlow 1.4 Role Status Message -------------------------------- OpenFlow 1.4 section 7.4.4 ``Controller Role Status Message'' defines a new message sent by a switch to notify the controller that its role (whether it is a master or a slave) has changed. OVS should implement this. OpenFlow 1.3 also includes this feature as a ONF-defined extension, so ideally OVS would support that too. OpenFlow 1.4 Vacancy Events --------------------------- OpenFlow 1.4 section 7.4.5 ``Table Status Message'' defines a new message sent by a switch to notify the controller that a flow table is close to filling up (or that it is no longer close to filling up). OVS should implement this. OpenFlow 1.3 also includes this feature as a ONF-defined extension, so ideally OVS would support that too. OpenFlow 1.4 Group and Meter Change Notification ------------------------------------------------ OpenFlow 1.4 adds a feature whereby a controller can ask the switch to send it copies of messages that change groups and meters. (This is only useful in the presence of multiple controllers.) OVS should implement this. OpenFlow 1.3 also includes this feature as a ONF-defined extension, so ideally OVS would support that too. Discussion Topics ================= Each of these topics are suitable for detailed discussion. The goal is to come up with a solid design, but are likely too complicated to result in code during the hackathon. Support for L4-L7 ----------------- Open vSwitch has good support for L2 and L3 functionality, but is lacking comprehensive support for higher level protocols. One particular area of interest is support for a truly stateful firewall. Other areas include load balancing and DPI classification. Developers with experience with the Linux conntrack module would be appreciated. Support for roots other than Ethernet ------------------------------------- Open vSwitch and OpenFlow expect to deal with Ethernet traffic. There are proposals at the ONF to support roots other than Ethernet. Additionally, protocols such as LISP carry L3 traffic, which creates issues when Open vSwitch terminates them. This group would discuss how to break Open vSwitch's expectation of only handling Ethernet traffic. Testing Project Ideas ===================== Each of these projects would ideally result in confirmation that features work or bug reports explaining how they do not. Please sent bug reports to dev@openvswitch.org, with as many details as you have. ONF Plugfest Results Analysis ----------------------------- Ben Pfaff has a collection of files reporting Open vSwitch conformance to OpenFlow 1.3 provided by one of the vendors at the ONF plugfest last year. Some of the reported failures have been fixed, some of the other failures probably result from differing interpretations of OpenFlow 1.3, and others are probably genuine bugs in Open vSwitch. Open vSwitch has also improved in the meantime. Ben can provide the results, privately, to some person or team who wishes to check them out and try to pick out the genuine bugs. RSTP Implementation Testing --------------------------- A patch implementing support for RSTP (Rapid Spanning Tree Protocol) was posted to the Open vSwitch mailing list some time ago. It is currently under review. In the meantime, it would be nice to get in some testing. A team could test it against the existing Open vSwitch STP implementation, against the Linux kernel bridge implementation of STP, possibly against hardware implementations of (R)STP if one can be obtained during the hackathon, and possibly try out some test cases specified by the various (R)STP conformance tests one can find online. OpenFlow Fuzzer --------------- Build a ``fuzzer'' for the OpenFlow protocol (or use an existing one, if there is one) and run it against the Open vSwitch implementation. One could also build a fuzzer for the OSVDB protocol. Ryu Certification Tests Analysis -------------------------------- The Ryu controller comes with a suite of ``certification tests'' that check the correctness of a switch's implementation of various OpenFlow 1.3 features. The INSTALL file in the OVS source tree has a section that explains how to easily run these tests against an OVS source tree. Run the tests and figure out whether any tests fail but should pass. (Some tests fail and should fail because OVS does not implement the particular feature; for example, OVS does not implement PBB encapsulation, so related tests fail.) OFTest Results Analysis ----------------------- OFTest is a test suite for OpenFlow 1.0 compliance. The INSTALL file in the OVS source tree has a section that explains how to easily run these tests against an OVS source tree. Run the tests and figure out whether any tests fail but should pass, and ideally why. OFTest is not particularly well vetted--in the past, at least, some tests have failed against OVS due to bugs in OFTest, not in OVS--so some care is warranted. Documentation Project Ideas =========================== Each of these projects would ideally result in creating some new documentation for users. Some documentation might be suitable to accompany Open vSwitch as part of its source tree most likely either in plain text or ``nroff'' (manpage) format. OpenFlow Basics Tutorial ------------------------ Open vSwitch has a tutorial that covers its advanced features, but it does not have a basic tutorial. There are several tutorials on the Internet already, so a new tutorial would have to distinguish itself in some way. One way would be to use the Open vSwitch ``sandbox'' environment already used in the advanced tutorial. The sandbox does not require any real network or even supervisor privilege on the machine where it runs, and thus it is easy to use with hardly any up-front setup, so it is a gentle way to get started. FlowVisor via patch ports ------------------------- FlowVisor is a proxy that sits between OpenFlow controllers and a switch. It divides up switch resources, allowing each controller to control a ``slice'' of the network. For example, it can break up a network based on VLAN, allowing different controllers to handle packets with different VLANs. It seems that Open vSwitch has features that allow it to implement at least simple forms of FlowVisor control without any need for FlowVisor. Consider an Open vSwitch instance with three bridges. Bridge br0 has physical ports eth0 and eth1. Bridge v9 has no physical ports, but it has two ``patch ports'' that connect it to br0. Bridge v11 has the same setup. Flows in br0 match packets received on vlan 9, strip the vlan header, and direct them to the appropriate patch port leading to v9. Additional flows in br0 match packets received from v9, attach a VLAN 9 tag to them, and direct them out eth0 or eth1 as appropriate. Other flows in br0 treat packets on VLAN 11 similarly. Controllers attached to bridge v9 or v11 may thus work as if they had full control of a network. It seems to me that this is a good example of the power of OpenFlow and Open vSwitch. The point of this project is to explain how to do this, with detailed examples, in case someone finds it handy and to open eyes toward the generality of Open vSwitch usefulness. ``Cookbooks'' ------------- The Open vSwitch website has a few ``cookbook'' entries that describe how to use Open vSwitch in a few scenarios. There are only a few of these and all of them are dated. It would be a good idea to come up with ideas for some more and write them. These could be added to the Open vSwitch website or the source tree or somewhere else. Demos ----- Record a demo of Open vSwitch functionality in use (or something else relevant) and post it to youtube or another video site so that we can link to it from openvswitch.org OVSDB protocol documentation update ----------------------------------- The OVSDB protocol is documented in ovsdb/SPECS in the Open vSwitch source tree. A few months ago, RFC 7047 was released to also document the protocol. RFC 7047 is better edited but essentially the same. It would be a good idea to read them both side by side, then rewrite ovsdb/SPECS to refer to RFC 7047 and describe any differences between the two specifications. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
