<div dir="ltr">On 1 December 2014 at 04:43, Mathieu Rohon <span dir="ltr"><<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br><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">This is not entirely true, as soon as a reference implementation,<br>
based on existing Neutron components (L2agent/L3agent...) can exist.<br></blockquote><div><br></div><div>The specific thing I was saying is that that's harder with an edge-id mechanism than one incorporated into Neutron, because the point of the edge-id proposal is to make tunnelling explicitly *not* a responsibility of Neutron.  So how do you get the agents to terminate tunnels when Neutron doesn't know anything about tunnels and the agents are a part of Neutron?  Conversely, you can add a mechanism to the OVS subsystem so that you can tap an L2 bridge into a network, which would probably be more straightforward.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But even if it were true, this could at least give a standardized API<br>
to Operators that want to connect their Neutron networks to external<br>
VPNs, without coupling their cloud solution with whatever SDN<br>
controller. And to me, this is the main issue that we want to solve by<br>
proposing some neutron specs.<br></blockquote><div><br></div><div>So the issue I worry about here is that if we start down the path of adding the MPLS datamodels to Neutron we have to add Kevin's switch control work.  And the L2VPN descriptions for GRE, L2TPv3, VxLAN, and EVPN.  And whatever else comes along.  And we get back to 'that's a lot of big changes that aren't interesting to 90% of Neutron users' - difficult to get in and a lot of overhead to maintain for the majority of Neutron developers who don't want or need it.<br></div><div>-- <br></div><div>Ian.<br></div></div></div></div>