Open Stack

Whoops, wrong link in last email.

https://etherpad.openstack.org/p/liberty-neutron-summit-topics

On Thu, Apr 2, 2015 at 12:50 AM, Kevin Benton <blak111 at gmail.com> wrote:

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



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