Open Stack

hi henry,

thanks for this interesting idea. It would be interesting to think about
how external gateway could leverage the l2pop framework.

Currently l2pop sends its fdb messages once the status of the port is
modified. AFAIK, this status is only modified by agents which send
update_devce_up/down().
This issue has also to be addressed if we want agent less equipments to be
announced through l2pop.

Another way to do it is to introduce some bgp speakers with e-vpn
capabilities at the control plane of ML2 (as a MD for instance). Bagpipe
[1] is an opensource bgp speaker which is able to do that.
BGP is standardized so equipments might already have it embedded.

last summit, we talked about this kind of idea [2]. We were going further
by introducing the bgp speaker on each compute node, in use case B of [2].

[1]https://github.com/Orange-OpenSource/bagpipe-bgp
[2]http://www.slideshare.net/ThomasMorin1/neutron-and-bgp-vpns-with-bagpipe

On Thu, Mar 26, 2015 at 7:21 AM, henry hly <henry4hly at gmail.com> wrote:

> Hi ML2er,
>
> Today we use agent_ip in L2pop to store endpoints for ports on a
> tunnel type network, such as vxlan or gre. However this has some
> drawbacks:
>
> 1) It can only work with backends with agents;
> 2) Only one fixed ip is supported per-each agent;
> 3) Difficult to interact with other backend and world outside of Openstack.
>
> L2pop is already widely accepted and deployed in host based overlay,
> however because it use agent_ip to populate tunnel endpoint, it's very
> hard to co-exist and inter-operating with other vxlan backend,
> especially agentless MD.
>
> A small change is suggested that the tunnel endpoint should not be the
> attribute of *agent*, but be the attribute of *port*, so if we store
> it in something like *binding:tun_ip*, it is much easier for different
> backend to co-exists. Existing ovs agent and bridge need a small
> patch, to put the local agent_ip into the port context binding fields
> when doing port_up rpc.
>
> Several extra benefits may also be obtained by this way:
>
> 1) we can easily and naturally create *external vxlan/gre port* which
> is not attached by an Nova booted VM, with the binding:tun_ip set when
> creating;
> 2) we can develop some *proxy agent* which manage a bunch of remote
> external backend, without restriction of its agent_ip.
>
> Best Regards,
> Henry
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150330/3d31525e/attachment.html>