Open Stack

Hello,

I think that easiest way could be to have own mech_driver (AFAIK such
drivers are for such usage) to talk with external devices to "tell" them
what tunnels should it establish.
With change to tun_ip Henry propese l2_pop agent will be able to
establish tunnel with external device.

On Mon, Mar 30, 2015 at 10:19:38PM +0200, Mathieu Rohon wrote:
> 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
> >

> __________________________________________________________________________
> 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


-- 
Pozdrawiam
Sławek Kapłoński
slawek at kaplonski.pl