Open Stack

On Thu, Apr 2, 2015 at 3:51 PM, Kevin Benton <blak111 at 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 <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]
>>

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

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