[ovs-dev] Upstream tunneling and VXLAN

[Jesse Gross]

There's been quite a bit of interest in plans for getting tunneling
upstream and supporting VXLAN.  Since I know that both end users and
developers are curious I thought that I would send out the current
plan for making this happen.  If anyone has comments or suggestions on
the plan, please let me know.

The reason why tunneling wasn't submitted upstream together with the
rest of the kernel code is because the userspace/kernel interfaces as
they exist today aren't sufficiently future-proof that we would want
to freeze them.  An example of where they break down is with VXLAN
multicast learning since it's necessary to be able to discover new
tunnel endpoints dynamically.  It would be possible to implement this
entirely in the kernel but userspace has a much richer set of
information and it's preferable to move complexity there anyways.  As
a result, the idea is to give userspace control over the tunnel
headers on a per-flow basis which it can use to implement the existing
tunnel ports, VXLAN learning, and likely more sophisticated controls
through OpenFlow in the future.  With that in place we can quickly
push tunneling upstream and add support for VXLAN.

Here are the rough components:

OVS kernel module (Kyle) - Add support for matching and setting tunnel
outer headers via flows.

Upstream tunnel abstraction (Pravin) - Currently there are a number of
tunnel implementations upstream with both a control plane for talking
to userspace, maintaining devices, etc. and a data plane for the
actual protocol handling.  My hope is that we can abstract the control
planes out into common code that drive the various data plane
implementations.  Once that happens OVS can become an alternate
control plane using the same data plane implementations.

Decouple userspace ports from kernel (Justin) - To maintain current
tunnel port abstractions userspace will need to have a notion of ports
and datapaths that no longer maps directly to that of the kernel since
tunnel ports will be backed entirely by flows.

Port tunnel code from kernel to userspace (Jesse) - One of the
benefits of this approach is that much of the current tunnel code in
the kernel can now be implemented in userspace in such a way that is
both simpler and happens on a per-flow basis rather than per-packet.

VXLAN implementation - Once the above components are in, the existing
VXLAN patch (plus optional use of a multicast control plane) can be
updated to support the new model and integrated.

The names that I listed above are just based on people who have
expressed interest in doing the work.  If you would like to help out
let me know and we can find a project.