<div dir="ltr"><div>Howdy!</div><div><br></div><div>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.)</div>
<div><br></div><div>Blueprint: <a href="https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver">https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver</a><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks for reading such a long message!</div><div><br></div><div>More on TeraStream:<br></div><div>Short: <a href="http://blog.ipspace.net/2013/11/deutsche-telekom-terastream-designed.html">http://blog.ipspace.net/2013/11/deutsche-telekom-terastream-designed.html</a></div>
<div>Long: <a href="https://ripe67.ripe.net/archives/video/3/">https://ripe67.ripe.net/archives/video/3/</a></div><div><br></div><div>More on the relationship to NFV use cases in the NFV subgroup wiki page:</div><div><a href="https://wiki.openstack.org/wiki/Teams/NFV">https://wiki.openstack.org/wiki/Teams/NFV</a><br>
</div><div><br></div><div>Cheers,<br></div><div>-Luke (lukego)</div><div><br></div><div>P.S. Happy for a video chat on Skype or Hangout to explain more if that helps</div><div><br></div><div><br></div></div>