Open Stack

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

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.

Best regards, any suggestion is welcome

--
Zang MingJie