<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">To address a point or two that Armando has raised here that weren't covered in my other mail:<br><br>On 28 October 2014 11:00, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><font color="#000000" face="arial, helvetica, sans-serif"></font><font color="#000000" face="arial, helvetica, sans-serif">- </font><font color="#000000" face="arial, helvetica, sans-serif">Core Neutron changes: what needs to happen to the core of Neutron, if anything, so that we can implement this NFV-enabling constructs successfully? Are there any changes to the core L2 API? Are there any changes required to the core framework (scheduling, policy, notifications, data model etc)?<br></font></div></blockquote><div><br></div><div>In the L2 API, I think this involves <br>- adding capability flag for trunking on networks and propagating that into ML2's drivers (for what it's worth, this needs solving anyway; MTUs need propagation as well)<br></div><div>- adding the trunk ports API and somehow implementing that in ML2<br><br></div><div>The L2GW block is in fact a new service and a reference implemenation can be made with a namepsace, independently of the L2 plugin.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><font color="#000000" face="arial, helvetica, sans-serif"></font><div class="gmail_extra"></div><div class="gmail_extra">- Add support to the existing plugin backends: the openvswitch reference implementation is an obvious candidate,</div></div></blockquote><div><br></div><div>Actually, it isn't.  The LB reference implementation is the obvious candidate.  Because of the way it's implemented, it's easiest if the OVS implementation refuses to make trunk networks (and therefore couldn't use an L2GW block), but that's fine: we need one reference implementation and it doesn't have to be OVS.<br><br>OVS may still be suitable to show off a trunk port reference implementation; trunk ports would need addressing in the L2 plugin  (in that they're VM-to-network connectivity, which falls under its responsibility).</div><br></div></div></div>