<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div></div><div>I agree with henry here. <br></div><div>Armando, If we use your analogy with nova that doesn't build and deliver KVM, we can say that Neutron doesn't build or deliver OVS. It builds a driver and an agent which manage OVS, just like nova which provides a driver to manage libvirt/KVM.<br></div><div>Moreover, external SDN controllers are much more complex than Neutron with its reference drivers. I feel like forcing the cloud admin to deploy and maintain an external SDN controller would be a terrible experience for him if he just needs a simple way manage connectivity between VMs.<br>At the end of the day, it might be detrimental for the neutron project.<br></div><div><div><div> </div></div></div></div></div></div></blockquote><div><br></div><div>I don't think that anyone is saying that cloud admins are going to be forced to deploy and maintain an external SDN controller. There are plenty of deployment examples where people are just happy with network virtualization the way Neutron has been providing for years and we should not regress on that. To me it's mostly a matter of responsibilities of who develops what, and what that what is :)</div><div><br></div><div>The consumption model is totally a different matter.</div><div> </div></div></div></div>