Open Stack

Howdy!

Our feature "Snabb NFV mech driver" has become controversial on Gerrit.
Mark and Maru suspect that it is fundamentally ill-conceived. This mail is
to explain the background and advertise that we are available for
discussion. (No pressure, I just want to volunteer relevant information.)

Blueprint:
https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver

This feature represents the work that myself and other independent open
source developers are doing to support Deutsche Telekom's TeraStream NFV
project. TeraStream is a new design for national ISPs and they have
revisited every layer of the network all the way down to the optics.
TeraStream hosts all network services inside an OpenStack cluster. Our job
is to make Neutron support TeraStream's next round of requirements.

We have been talking about this in great detail with everybody we can find
at the summits in Hong Kong and in Atlanta, and we will be in Paris too.
Still, the Neutron community is big, so probably most people have no idea
what we are trying to accomplish.

The main requirement is performance. On each compute node we want to do
around 25 million packets per second of processing, and we want to do that
within virtual machines using Virtio-net and with OpenStack's L2 networking
features available. This will allow us to host applications like Address
Family Translation (~NAT) inside VMs even when the need to process all the
traffic for a national ISP.

We have solved the performance problem by developing the vhost-user feature
in QEMU 2.1 and exploiting it in Snabb Switch. That work is upstream now
and we are eager to add support in OpenStack too. We think this is
important work and we want to share it with the community.

Our other requirement is robustness. We need a really simple control layer
that has predictable failure modes, no performance surprises, and is easy
to troubleshoot. People have advised us against using the
LinuxBridge/OVSPlugin management layer at this time. So we have created an
expedient short-term solution, which we don't propose to bring in tree and
I needn't bore you with the details of, to use until we find a good in-tree
solution.

Our goal in submitting this code to Juno is to make it easily available to
other NFV enthusiasts who may want to adopt it too.

The reason we didn't promote this work early in the cycle is that we have
only recently had the breakthrough of getting upstream into QEMU + Libvirt
and that had been a gating requirement for the Nova (VIF_VHOSTUSER) to be
taken seriously.

Thanks for reading such a long message!

More on TeraStream:
Short:
http://blog.ipspace.net/2013/11/deutsche-telekom-terastream-designed.html
Long: https://ripe67.ripe.net/archives/video/3/

More on the relationship to NFV use cases in the NFV subgroup wiki page:
https://wiki.openstack.org/wiki/Teams/NFV

Cheers,
-Luke (lukego)

P.S. Happy for a video chat on Skype or Hangout to explain more if that
helps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140731/56c44ace/attachment.html>