On Thu, Apr 2, 2015 at 3:51 PM, Kevin Benton <[email protected]> wrote: > 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] >>
Thanks a lot, Kevin. I think it's really important, for more customers are asking about various backends coordinating. >> >> 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. Sure, I agree. >>> With change to tun_ip Henry propese l2_pop agent will be able to >>> establish tunnel with external device. Maybe not necessary here, the key is that interaction between l2pop and external device MD is needed. Below are just some very basic ideas: 1) MD as the plugin side agent? * each MD register hook in l2pop, then l2pop call the hook list as well as notifying to agent; * MD simulate a update_device_up/down, however with binding:tun_ip because it has no agent_ip; * How MD get port status remain unsolved. 2) Things may be much easier in case of hierarchical port binding (merged in Kilo) * A ovs/linuxbridge agent still exist to produce update_device_up/down message; * external device MD get port status update, then add tun_ip to port context, then trigger l2pop MD? >>> >>> 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 Hi Mathieu, Thanks for your idea, the interaction between l2pop and other MD is really the key point, and remove agent_ip is just the first step. BGP speakers is interesting, however I think the goal is not very same, because I want to keep compatibility of existing deployed l2pop solutions, and want to extend and enhance it while not replacing it totally. >>> > [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 > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
