In reply to Mark Detrick.

Hi Mark,

Thanks for taking the time to reply to the blog. I think you may have been confused by a couple of the points I was making, and I do appreciate the opportunity to clarify.

Re: Bandwidth constraints
The issue here is not bandwidth constraints at all. It's how you can add the ability to handle deterministic storage traffic that is normally architected in a North-South paradigm into an Ethernet topology that is East-West. The concern can be for storage administrators - I had one come up to me today at CiscoLive ask this question, for example - how we can prevent the fight for bandwidth when using multiple protocols. My point is that not only can you guarantee the bandwidth using standards-based ETS, but also capitalize on the additional bandwidth going through the network as well. If you've got it, you've got it.

Its all part of the planning process and should be to nobody’s surprise. I do not buy the, if Fabric A goes down, then Fabric B is under duress.

Again, you are correct. I did say that this is how you plan for and architect storage SAN A/B topologies. However, if the topologies are mis-calculated, and/or if storage capacity growth exceeds plans, it is possible to place a burden on an unprepared failover network.

[o]ne network is a major problem for critical enterprise workloads. Workloads in which the enterprise itself is based and an outage spells pure disaster.

Leaf/Spine architectures may not be commonplace, even in Ethernet deployments. This does not mean that there hasn't been a lot of interest in these types of topologies. ACI, DFA, FabricPath, etc., are just a few of the possible means to do this. This, however, is not a discussion about the merits of Leaf/Spine (which are used heavily in InfiniBand architectures, btw, and are well-understood), but rather how storage networks can be used in conjunction with them as a possible option.

Storage shops were not stupid back when the idea of A & B fabrics came about and we are just becoming enlightened now that there is this “new” way to converge them. The technology to converge FC fabrics into one has always existed and it could have certainly been done. There was no ulterior motive just to sell twice as much equipment. The reality is that the opposite is true, we were smart to keep them separate which has proven to work and be highly reliable.

I'm not sure where I implied that storage shops who had implemented physical separation were either unenlightened or duped. In fact, I believe I was very careful to indicate that this logical separation was simply an option, and it's not just possible (but highly likely) that data centers will continue to use Classical FC/FCoE environments in this fashion.

And, if shops move towards removing this absolute redundancy then they are becoming less enlightened as those that have gone before them.

Although I think it's pretty clear where you stand on the matter. :)