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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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: >> [email protected]?subject:unsubscribe >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >> >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> -- >> Pozdrawiam >> Sławek Kapłoński >> [email protected] >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Kevin Benton > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
