<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 20 November 2014 02:19, Sukhdev Kapur <span dir="ltr"><<a href="mailto:sukhdevkapur@gmail.com" target="_blank">sukhdevkapur@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Folks, <div><br></div><div>Like Ian, I am jumping in this very late as well - as I decided to travel Europe after the summit, just returned back and  catching up :-):-)</div><div><br></div><div>I have noticed that this thread has gotten fairly convoluted and painful to read. </div><div><br></div><div>I think Armando summed it up well in the beginning of the thread. There are basically three written proposals (listed in Armando's email - I pasted them again here).</div><span class=""><div><br></div><div><div style="font-family:arial,sans-serif;font-size:13px">[1] <a href="https://review.openstack.org/#/c/134179/" target="_blank">https://review.openstack.org/#/c/134179/</a></div><div style="font-family:arial,sans-serif;font-size:13px">[2] <a href="https://review.openstack.org/#/c/100278/" target="_blank">https://review.openstack.org/#/c/100278/</a></div><div style="font-family:arial,sans-serif;font-size:13px">[3] <a href="https://review.openstack.org/#/c/93613/" target="_blank">https://review.openstack.org/#/c/93613/</a></div><div><br></div></div></span></div></blockquote><div><br></div><div>In this thread I have seen other specs being mentioned as "related".</div><div>Namely:</div><div>1) <a href="https://review.openstack.org/#/c/93329/" target="_blank" style="font-family:arial,sans-serif;font-size:13px">https://review.openstack.org/#/c/93329/</a><span style="font-family:arial,sans-serif;font-size:13px"> (BGP VPN)</span><br style="font-family:arial,sans-serif;font-size:13px">2) <a href="https://review.openstack.org/#/c/101043/" target="_blank" style="font-family:arial,sans-serif;font-size:13px">https://review.openstack.org/#/c/101043/</a><span style="font-family:arial,sans-serif;font-size:13px"> (MPLS vpn)</span><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">3) </span><a href="https://review.openstack.org/#/c/87825/" target="_blank" style="font-size:13px;font-family:arial,sans-serif">https://review.openstack.org/#/c/87825/</a> (external device integration)</div><div><span style="font-family:arial,sans-serif;font-size:13px">Note that I am not saying they should be put as well in the mix. I'm only listing them here as a "recap".</span></div><div>There are probably other "ideas" not yet put in the form of a concrete specification. In order to avoid further confusion, I would just blindly ignore proposals which do not exist in the form a specification.<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><div><div></div></div></span><div>On this thread I see that the authors of first two proposals have already agreed to consolidate and work together. This leaves with two proposals. Both Ian and I were involved with the third proposal [3] and have reasonable idea about it. IMO, the use cases addressed by the third proposal are very similar to use cases addressed by proposal [1] and [2]. I can volunteer to  follow up with Racha and Stephen from Ericsson to see if their use case will be covered with the new combined proposal. If yes, we have one converged proposal. If no, then we modify the proposal to accommodate their use case as well. Regardless, I will ask them to review and post their comments on [1].</div></div></blockquote><div><br></div><div>One thing that I've noticed in the past is that contributors are led to think that the owner of the specification will also be the lead for the subsequent work. There nothing farther from truth. Sometimes I write specs with the exact intent of having somebody else lead the implementation. So don't feel bad to abandon a spec if you realize your use cases can be completely included in another specification.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Having said that, this covers what we discussed during the morning session on Friday in Paris. Now, comes the second part which Ian brought up in the afternoon session on Friday. </div><div>My initial reaction was, when heard his use case, that this new proposal/API should cover that use case as well (I am being bit optimistic here :-)). If not, rather than going into the nitty gritty details of the use case, let's see what modification is required to the proposed API to accommodate Ian's use case and adjust it accordingly. </div></div></blockquote><div><br></div><div>Unfortunately I did not attend that discussion. Possibly 90% of the people reading this thread did not attend it. It would be nice if Ian or somebody else posted a write-up, adding more details to what has already been shared in this thread. If you've already done so please share a link as my google-fu is not that good these days.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Now, the last point (already brought up by Salvatore as well as Armando) - the abstraction of the API, so that it meets the Neutron API criteria. I think this is the critical piece. I also believe the API proposed by [1] is very close. We should clean it up and take out references to ToR's or physical vs virtual devices. The API should work at an abstract level so that it can deal with both physical as well virtual devices. If we can agree to that, I believe we can have a solid solution. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Having said that I would like to request the community to review the proposal submitted by Maruti in [1] and post comments on the spec with the intent to get a closure on the API. I see lots of good comments already on the spec. Lets get this done so that we can have a workable (even if not perfect) version of API in Kilo cycle. Something which we can all start to play with. We can always iterate over it, and make change as we get more and more use cases covered. </div></div></blockquote><div><br></div><div>"Iterate" is the key here I believe. As long as we pretend to achieve the perfect API at the first attempt we'll just keep having this discussion. I think the first time a L2 GW API was proposed, it was for Grizzly.</div><div>For instance, it might relatively easy to define an API which can handle both physical and virtual devices. The user workflow for a ToR terminated L2 GW is different from the workflow for a virtual appliance owned by tenant, and this will obviously reflected in the API. On the other hand, a BGP VPN might be a completely different use case, and therefore have a completely different set of APIs.</div><div><br></div><div>Beyond APIs there are two more things to mention.</div><div>First, we need some sort of open source reference implementation for every use case. For hardware VTEP obviously this won't be possible, but perhaps [1] can be used for integration tests.</div><div>The complexity of providing this implementation might probably drive the roadmap for supporting L2 GW use cases.</div><div>Second, I still believe this is an "advanced service" and therefore a candidate for being outside of neutron's main repo (which, if you're following the discussions does not mean "outside of neutron"). The arguments I've seen so far do not yet convince me this thing has to be tightly integrated into the core neutron.</div><div><br></div><div><br></div><div>Salvatore</div><div><br></div><div><br></div><div>[1] <a href="http://openvswitch.org/pipermail/dev/2013-October/032530.html">http://openvswitch.org/pipermail/dev/2013-October/032530.html</a></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Make sense? </div><div><br></div><div>cheers..</div><span class=""><font color="#888888"><div>-Sukhdev</div><div><br></div></font></span></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 18, 2014 at 6:44 PM, 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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 18 November 2014 16:22, Ian Wells <span dir="ltr"><<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Sorry I'm a bit late to this, but that's what you get from being on holiday...  (Which is also why there are no new MTU and VLAN specs yet, but I swear I'll get to them.)<br></div></blockquote><div><br></div></span><div>Ah! I hope it was good at least :)</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On 17 November 2014 01:13, Mathieu Rohon <span dir="ltr"><<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br></span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi<br>
<span><br>
On Fri, Nov 14, 2014 at 6:26 PM, Armando M. <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>> wrote:<br>
> Last Friday I recall we had two discussions around this topic. One in the<br>
> morning, which I think led to Maruti to push [1]. The way I understood [1]<br>
> was that it is an attempt at unifying [2] and [3], by choosing the API<br>
> approach of one and the architectural approach of the other.<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/134179/" target="_blank">https://review.openstack.org/#/c/134179/</a><br>
> [2] <a href="https://review.openstack.org/#/c/100278/" target="_blank">https://review.openstack.org/#/c/100278/</a><br>
> [3] <a href="https://review.openstack.org/#/c/93613/" target="_blank">https://review.openstack.org/#/c/93613/</a><br>
><br>
> Then there was another discussion in the afternoon, but I am not 100% of the<br>
> outcome.<br>
<br>
</span>Me neither, that's why I'd like ian, who led this discussion, to sum<br>
up the outcome from its point of view.<br></blockquote><div><br></div></span><div>So, the gist of what I said is that we have three, independent, use cases:<br><br></div><div>- connecting two VMs that like to tag packets to each other (VLAN clean networks)<br></div><div>- connecting many networks to a single VM (trunking ports)<br></div><div>- connecting the outside world to a set of virtual networks<br><br></div><div>We're discussing that last use case here.  The point I was made was that:<br><br></div><div>- there are more encaps in the world than just VLANs<br></div><div>- they can all be solved in the same way using an edge API<br></div></div></div></div></blockquote><div><br></div></span><div>No disagreement all the way up to this point, assumed that I don't worry about what this edge API really is.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>- if they are solved using an edge API, the job of describing the network you're trying to bring in (be it switch/port/vlan, or MPLS label stack, or l2tpv3 endpoint data) is best kept outside of Neutron's API, because Neutron can't usefully do anything with it other than validate it and hand it off to whatever network control code is being used.  (Note that most encaps will likely *not* be implemented in Neutron's inbuilt control code.)<br></div></div></div></div></blockquote><div><br></div></span><div>This is where the disagreement begins, as far as I am concerned; in fact we already have a well defined way of describing what a network entity in Neutron is, namely an L2 broadcast domain abstraction. An L2 gateway API that is well defined and well scoped should just express how one can be connected to another, nothing more, at least as a starting point.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div>Now, the above argument says that we should keep this out of Neutron.  The problem with that is that people are using the OVS mechanism driver and would like a solution that works with that, implying something that's *inside* Neutron.  For that case, it's certainly valid to consider another means of implementation, but it wouldn't be my personal choice.  (For what it's worth I'm looking at ODL based controller implementations, so this isn't an issue for me personally.)<br><br>If one were to implement the code in the Neutron API, even as an extension, I would question whether it's a sensible thing to attempt before the RPC server/REST server split is done, since it also extends the API between them.<br><br></div><span><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span>> All this churn makes me believe that we probably just need to stop<br>
> pretending we can achieve any sort of consensus on the approach and let the<br>
> different alternatives develop independently, assumed they can all develop<br>
> independently, and then let natural evolution take its course :)<br>
<br>
</span>I tend to agree, but I think that one of the reason why we are looking<br>
for a consensus, is because API evolutions proposed through<br>
Neutron-spec are rejected by core-dev, because they rely on external<br>
components (sdn controller, proprietary hardware...) or they are not a<br>
high priority for neutron core-dev.<br>
By finding a consensus, we show that several players are interested in<br>
such an API, and it helps to convince core-dev that this use-case, and<br>
its API, is missing in neutron.<br></blockquote><br></div></span><div class="gmail_quote">There are lots of players interested in an API, that much is clear, and all the more so if you consider that this feature has strong analogies with use cases such as switch port exposure and MPLS.  The problem is that it's clearly a fairly complex API with some variety of ways to implement it, and both of these things work against its acceptance.  Additionally, per the above discussion, I would say it's not essential for it to be core Neutron functionality. </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><div class="gmail_quote"><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Now, if there is room for easily propose new API in Neutron, It make<br>
sense to leave new API appear and evolve, and then " let natural<br>
evolution take its course ", as you said.<br></blockquote><div><br></div></span><div>Natural selection works poorly on APIs because once they exist they're hard to change and/or retire, due to backward compatibility requirements.<br></div></div></div></div></blockquote><div><br></div></span><div>Well, that is true assumed that someone can or is willing to use them :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
To me, this is in the scope of the "advanced services" project.<br></blockquote><div><br></div></span><div>Advanced services or no, the point I was making is that this is not something that should fit under the Neutron API endpoint.  Since it's not really related to any of the other advanced services it's not particularly necessary that it fit under the Advanced Services API endpoint either, although it could.  My Unix design leanings say to me that if things are not related they shouldn't be combined, though - the simplest thing that does the job is the right answer.<span><font color="#888888"><br>-- <br></font></span></div><span><font color="#888888"><div>Ian.<br></div></font></span></div></div></div>
<br></span><span>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></span></blockquote></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</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></div>