Open Stack

Hi,


On Sun, Nov 30, 2014 at 8:35 AM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:
> On 27 November 2014 at 12:11, Mohammad Hanif <mhanif at brocade.com> wrote:
>>
>> Folks,
>>
>> 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:
>>
>> Edge-Id: https://review.openstack.org/#/c/136555/
>> Edge-VPN: https://review.openstack.org/#/c/136929 .  This is a resubmit of
>> https://review.openstack.org/#/c/101043/ 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 :-(
>
>
> Per the summit discussions, the difference is one of approach.
>
> 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.
>
> 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.

This is not entirely true, as soon as a reference implementation,
based on existing Neutron components (L2agent/L3agent...) can exist.
But even if it were true, this could at least give a standardized API
to Operators that want to connect their Neutron networks to external
VPNs, without coupling their cloud solution with whatever SDN
controller. And to me, this is the main issue that we want to solve by
proposing some neutron specs.

> 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
> https://review.openstack.org/#/c/87825/ .  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.
>
> 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.
> --
> Ian.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>