Will it work with existing service discovery systems? What happens if a container I'm linked to goes down and comes up on another host? Do I get transparently reconnected?
There's so much involved with the abstraction they're making that I'm getting a suspicion that it's probably an unwieldy beast of an implementation that probably leaks abstractions everywhere. I'd love to be proven otherwise, but their lack of details should make any developer nervous to bet their product on docker.
vxlan (overlay) and bridge, depending:
"Docker ships with 2 drivers:
bridge -- This driver provides the same sort of networking via veth bridge devices that prior versions of docker use, it is the default.
overlay -- Not to be confused with the "overlay" storage driver (thanks overlayfs), this driver provides native multi-host networking for docker clusters. When using swarm, this is the default driver."
Basically integrating OVS APIs into Docker so it could use more mature networking code as well as VXLAN forwarding. VXLAN is basically IP encapsulation (a 16-bit ID) that the networking industry has standardized on. It more or less allows for L2 over L3 links. I like to think of it as the next Spanning Tree.
So the unwieldy part is the weight OVS brings as well as the VXLAN encapsulation in software - both of which have momentum towards being more lightweight.