Open Stack

Coordinating communication between various backends for encapsulation
termination is something that would be really nice to address in Liberty.
I've added it to the etherpad to bring it up at the summit.[1]


1. http://lists.openstack.org/pipermail/openstack-dev/2015-March/059961.html

On Tue, Mar 31, 2015 at 2:57 PM, Sławek Kapłoński <slawek at kaplonski.pl>
wrote:

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



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150402/df64b61a/attachment.html>