<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 27 November 2014 at 12:11, Mohammad Hanif <span dir="ltr"><<a href="mailto:mhanif@brocade.com" target="_blank">mhanif@brocade.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 style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>Folks,</div>
<div><br>
</div>
<div>Recently, as part of the L2 gateway thread, there was some discussion on BGP/MPLS/Edge VPN and how to bridge any overlay networks to the neutron network.  Just to update everyone in the community, Ian and I have separately submitted specs which make an
 attempt to address the cloud edge connectivity.  Below are the links describing it:</div>
<div><br>
</div>
<div>Edge-Id: <a href="https://review.openstack.org/#/c/136555/" target="_blank">https://review.openstack.org/#/c/136555/</a></div>
<div>Edge-VPN: <a href="https://review.openstack.org/#/c/136929" target="_blank">https://review.openstack.org/#/c/136929</a> .  This is a resubmit of <a href="https://review.openstack.org/#/c/101043/" target="_blank">https://review.openstack.org/#/c/101043/</a> for the kilo release under
 the “Edge VPN” title.  “Inter-datacenter connectivity orchestration” was just too long and just too generic of a title to continue discussing about :-(</div></div></div></blockquote><div><br></div><div>Per the summit discussions, the difference is one of approach.<br><br>The Edge-VPN case addresses MPLS attachments via a set of APIs to be added to the core of Neutron.  Those APIs are all new objects and don't really change the existing API so much as extend it.  There's talk of making it a 'service plugin' but if it were me I would simply argue for a new service endpoint.  Keystone's good at service discovery, endpoints are pretty easy to create and I don't see why you need to fold it in.<br><br></div><div>The edge-id case says 'Neutron doesn't really care about what happens outside of the cloud at this point in time, there are loads of different edge termination types, and so the best solution would be one where the description of the actual edge datamodel does not make its way into core Neutron'.  This avoids us folding in the information about edges in the same way that we folded in the information about services and later regretted it.  The notable downside is that this method would work with an external network controller such as ODL, but probably will never make its way into the inbuilt OVS/ML2 network controller if it's implemented as described (explicitly *because* it's designed in such a way as to keep the functionality out of core Neutron).  Basically, it's not completely incompatible with the datamodel that the Edge-VPN change describes, but pushes that datamodel out to an independent service which would have its own service endpoint to avoid complicating the Neutron API with information that, likely, Neutron itself could probably only ever validate, store and pass on to an external controller.<br><br></div><div>Also, the Edge-VPN case is specified for only MPLS VPNs, and doesn't consider other edge cases such as Kevin's switch-based edges in <a href="https://review.openstack.org/#/c/87825/">https://review.openstack.org/#/c/87825/</a> .  The edge-ID one is agnostic of termination types (since it absolves Neutron of all of that responsibility) and would leave the edge type description to the determination of an external service.<br><br></div><div>Obviously, I'm biased, having written the competing spec; but I prefer the simple change that pushes complexity out of the core to the larger but comprehensive change that keeps it as a part of Neutron.  And in fact if you look at the two specs with that in mind, they do go together; the Edge-VPN model is almost precisely what you need to describe an endpoint that you could then associate with an Edge-ID to attach it to Neutron.<br>-- <br></div><div>Ian.<br></div></div></div></div>