<div dir="ltr">I have no problem with standardising the API, and I would suggest that a service that provided nothing but endpoints could be begun as the next phase of 'advanced services' broken out projects to standardise that API. I just don't want it in Neutron itself.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 December 2014 at 00:33, Erik Moe <span dir="ltr"><<a href="mailto:erik.moe@ericsson.com" target="_blank">erik.moe@ericsson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">One reason for trying to get an more complete API into Neutron is to have a standardized API. So users know what to expect and for providers to have something
to comply to. Do you suggest we bring this standardization work to some other forum, OPNFV for example? Neutron provides low level hooks and the rest is defined elsewhere. Maybe this could work, but there would probably be other issues if the actual implementation
is not on the edge or outside Neutron.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">/Erik<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Ian Wells [mailto:<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>]
<br>
<b>Sent:</b> den 4 december 2014 20:19<span class=""><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
</span><span class=""><b>Subject:</b> Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id<u></u><u></u></span></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On 1 December 2014 at 21:26, Mohammad Hanif <<a href="mailto:mhanif@brocade.com" target="_blank">mhanif@brocade.com</a>> wrote:<u></u><u></u></p><div><div class="h5">
<div>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">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:<u></u><u></u></span></p>
</div>
<ol start="1" type="1">
<li class="MsoNormal" style="color:black">
<span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">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) .<u></u><u></u></span></li><li class="MsoNormal" style="color:black">
<span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">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.<u></u><u></u></span></li></ol>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">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? <u></u><u></u></span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">How else one introduces a network service in OpenStack if it is not through a service plugin? <u></u><u></u></span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">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.<u></u><u></u></span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Agreed. I'm suggesting it should be a separate service endpoint.<br>
-- <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Ian.<u></u><u></u></p>
</div>
</div>
</div>
</div></div></div>
</div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>