It seems like they are trying to move enterprise networks from being general-purpose superhighways to being application-specific feeder roads. This may make sense in some specific applications, but it seems like there is a danger to making them too specific to particular applications which will change over time. SDNs are supposed to do that, but by allocating network resources at a software level which can adapt and change over time.
The argument for this is that enterprise applications don't change often. Unfortunately, baking the details into your network design is one way of ensuring that that description becomes even more self-fulfilling.
I'm not sure I understand what these "app-savvy switches" are really being asked to do, but I've always stayed away from any of these "fat tree" topologies, in my work.
Almost always, when I hear keynotes like this one, I know that I'm missing some key concept that the speaker has in mind. This would be no exception. Whether this key concept is generically applicable to networks, or whether it only applies to data centers, therefore escapes me.
My inclination has always been to design networks with many small switches, well distributed, in as dense a mesh as one can afford. This offers short paths between any two hosts and no prossibility of one or two switch failures creating a major catastrophy.
Interestingly both Edsall and a Googler who keynoted the day before (see link below) said protocols are still in an early definiton stage and OpenFlow is more of a starting point than a key piece of the SDN implementation.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.