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
