I do not think DNS will solve the workload mobility challenge. Unfortunately since DNS is not a pub/sub model and is cached at the edge and the edge cache may choose to, and often does, ignore the set TTL the change in IP address of a host/server will almost always result in noticeable downtime and even at best will result in all sockets breaking. Neither of which is acceptable if I want to run a business. (I changed the IP address of my blog and it took over 24 hours for all the DNS caches to age out…)

On the other hand, I completely agree with you that when you dismantle the ‘galactic reformation’ type of problems associated with network management or even QoS management and look at a discrete problem set you can really make a useful product. By focusing on the need to mark voice traffic and then place that voice traffic into a strict-priority queue you can make voice easy to roll out on a WAN or Campus. Similarly, if I was to take a narrow focus on marking traffic, setting up a lossless queue, a real-time queue, and an elastic queue, and a bad traffic policer I could probably make a very simple and scalable QoS management for the data center.

The changes I am talking about needing for the network are a) the interfaces to the network for the management to be effective and useful, b) to enable IP address portability (unless you want the IP equivalent of a cell phone that can’t roam between towers), and c) a mechanism to ensure consistent policy is applied to a given workload even if I move it from one provider to another (ot at least be opaque and give my provider the opportunity to read in last known segmentation/QoS state that a particular app/os/vm/workload is expecting)

dg