On Sep 19, 2012, at 1:59 PM, Jesse Gross wrote: > 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.
This looks great to me Jesse, thanks for sending out this note. I was going to send an email asking about the strategy, so your timing was perfect. I'm in the bay area this week, but plan to pickup item #1 above and hope to finish it next week to keep the ball rolling on this work. Thanks! Kyle _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
