Open Stack

Hi,

This is what we intended to do here:

https://blueprints.launchpad.net/quantum/+spec/l2-population

The goal is to generalize ovs-tunnel-partial-mesh to any encapsulation,
and add ARP & FDB population.

There are ongoing discussion to implement that in ML2 plugin, there will be
a meeting today where this topic (among others) will be discussed:
http://lists.openstack.org/pipermail/openstack-dev/2013-June/010063.html

It'd be great if you could join!

Some additional inline comments:

2013/6/6 Zang MingJie <zealot0630 at gmail.com>:
> Hi all:
>
> While implementing a virtual network, I found the most important and
> difficulty problem of the control plane is to figure out where an
> endpoint locates. Depending on the network layer, either ip or mac
> address can be use to access an endpoint, assume a VM is accessing an
> endpoint by its mac address, the virtual network received a packet which
> destinate to the endpoint (say it's X) from a port assigned to network
> A, then the virtual network need to figure out where is X of network A.
> Different solution may use different approach. for ex:
>
>  * flat: arp broadcast and l2 mac address fdb
>  * gre: full-mesh broadcast
>  * kernel-vxlan: ip multicast
>  * ovs-vxlan: lisp
>
> To simplify the design and avoid duplicated work, we'd better introduce
> a general mechanism to solve the problem. In general, we need a mapping,
> which map an endpoint (identified by port-id) to its actual location:
>
>  port-id --> node-id:segmentation-id
>
> Where node is a quantum agent. Because the node may serving several
> networks, segmentation id is needed to locate the target, but depending
> your design, you may not need the segmentation id to build the forward
> db. Beside this map, we also need a map from endpoint identifier to port-id:
>
>  network-id:ip-address --> port-id
>
> or
>
>  network-id:mac-address --> port-id
>
> With these information, we can build up a forward database, by polluting
> the database to data plane, we get a fully functional fast forward
> virtual network. And the network will be more flexible, eg:
>
>  * load-balancer and hot-standby can be implemented by adjust the
> mapping entry.
>  * multi-host can be implemented by install different mapping in
> different agent
>  * inter-network connection can be implemented by change the
> segmentation-id (NAT may be used)
>  * cross region network

We were definitively also seeing these uses cases (multi-host routing, L2
service insertion, aso.) as a follow-on effort ;)

> Above is the concept, by checking current works, I found there is
> already some blueprints related:
>
>   https://blueprints.launchpad.net/quantum/+spec/ovs-tunnel-partial-mesh
>
> To implement the mapping, a map server like lisp map server can be used.
> Or a fully synced database across all agent is also a proper solution,
> it won't be too big, even with 1M endpoints the memory print will be ~ 50MB.

For the first implementation, we'll probably rely on plugin information
rather than building an additionnal "map server", because it turns out
that the plugin has nearly all the required infomation, using joins on
PortBinding, Port, IPAllocation, NetworkSegment DBs

> Best regards, any suggestion is welcome
>
> --
> Zang MingJie
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev