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
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 blak...@gmail.com wrote:
Coordinating communication between various backends for encapsulation
termination is something that would be really nice to
On Thu, Apr 2, 2015 at 3:51 PM, Kevin Benton blak...@gmail.com 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 blak...@gmail.com wrote:
Coordinating communication between various backends
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,
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
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