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.
My Mom the Radio Star Max MaxfieldPost a comment I've said it before and I'll say it again -- it's a funny old world when you come to think about it. Last Friday lunchtime, for example, I received an email from Tim Levell, the editor for ...
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...