Comment 19 for bug 1458890

@ed, We (godaddy) currently have no need to schedule networks based upon some presumed latency characteristics. We just need to schedule a network based on where that network actually lives in the network. Be that at a host, rack, set of racks, or the entire cloud. It maybe a requirement to try to limit the number of vxlan extensions in the network at some point - though. Since current switches are limited to the number of VNI's they can support. IE: prefer hosts that already have this network segment trunked to it, vs's trunking a new segment through the network.

@Cedric, For us this is correct. In our configuration we also eliminated l3-agents from our implementation. We handle floating ip's by injecting a route into the network with the next-hop for the fixed-ip of them. Then we bind the IP the floating ip to a non-arping interface locally. Though technically we could implement this via a L3-agent that talks BGP to the switches to handle these advertisements, right now we are using our own internal automation system to inject routes into the network.