<div dir="ltr">On 1 December 2014 at 21:26, Mohammad Hanif <span dir="ltr"><<a href="mailto:mhanif@brocade.com" target="_blank">mhanif@brocade.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">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>I hope we all understand how edge VPN works and what interactions are introduced as part of this spec.  I see references to neutron-network mapping to the tunnel which is not at all case and the edge-VPN spec doesn’t propose it.  At a very high level,
 there are two main concepts:</div>
<ol>
<li>Creation of a per tenant VPN “service” on a PE (physical router) which has a connectivity to other PEs using some tunnel (not known to tenant or tenant-facing).  An attachment circuit for this VPN service is also created which carries a “list" of tenant
 networks (the list is initially empty) .</li><li>Tenant “updates” the list of tenant networks in the attachment circuit which essentially allows the VPN “service” to add or remove the network from being part of that VPN.</li></ol>
<div>A service plugin implements what is described in (1) and provides an API which is called by what is described in (2).  The Neutron driver only “updates” the attachment circuit using an API (attachment circuit is also part of the service plugin’ data model).
   I don’t see where we are introducing large data model changes to Neutron?  </div></div></div></blockquote><div> <br></div><div>Well, you have attachment types, tunnels, and so on - these are all objects with data models, and your spec is on Neutron so I'm assuming you plan on putting them into the Neutron database - where they are, for ever more, a Neutron maintenance overhead both on the dev side and also on the ops side, specifically at upgrade.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div><div>How else one introduces a network service in OpenStack if it is not through a service plugin?  </div></div></div></blockquote><div><br></div><div>Again, I've missed something here, so can you define 'service plugin' for me?  How similar is it to a Neutron extension - which we agreed at the summit we should take pains to avoid, per Salvatore's session?<br><br></div><div>And the answer to that is to stop talking about plugins or trying to integrate this into the Neutron API or the Neutron DB, and make it an independent service with a small and well defined interaction with Neutron, which is what the edge-id proposal suggests.  If we do incorporate it into Neutron then there are probably 90% of Openstack users and developers who don't want or need it but care a great deal if it breaks the tests.  If it isn't in Neutron they simply don't install it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div><div>As we can see, tenant needs to communicate (explicit or otherwise) to add/remove its
 networks to/from the VPN.  There has to be a channel and the APIs to achieve this.</div></div></div></blockquote><div><br></div><div>Agreed.  I'm suggesting it should be a separate service endpoint.<br>-- <br></div><div>Ian.<br></div></div></div></div>