« Hard zoning versus soft zoning in a FC/FCoE SAN | Main | Partner Mac Address: 00:00:00:00:00:00 »



Feed You can follow this conversation by subscribing to the comment feed for this post.

Dave Silvestri

Following up on sreejith's comments...

If you define masking in an autoprovisioning group (not exclusive to VMAX, other vendor's have initiator groups as well), would zoning be identical between fabrics?

For example:
- an IG of 2 initiators (1 per fabric)
- a PG of 2 ports (1 per fabric)
- a SG of x devs
- MV of the above

Would there be 4 zones in each fabric? Or would TDZ only create zones in it's fabric for the WWNs that it can locate? I believe it's the latter, but want to double check.

I may have missed something, I need to read the article again, lots of great info here.

Great article to be clear.

Erik Smith

Hi Dave, thanks! Peer zoning would allow either of the behaviors you are describing. As a result, I view this decision as an implementation detail. I can see arguments for and against both approaches. Do you have a strong preference towards one or the other or will either work?

Dave Silvestri

Personally I prefer to keep my zoning specific to the entities that exist in a fabric. I find it helps if someone does upgrades on a server and pulls the fibre cables, and then replaces them when complete, but gets them reversed.

Mostly that's for names/nicknames (which I also wonder if you could pull from the masking consistency is wonderful).

I suppose a benefit is that it wouldn't matter if the cables got reversed... however I prefer symmetry, and all my "a" labeled hbas on fabric A, and all my "b" labeled hbas on Fabric B...

To each his own though :)

Erwin van Londen

:-) Very nice to see it finally got accepted and written up by T11. Coincidence is that I had a similar proposal back in 2002 when doing consulting work for HP and had a long discussion with one of the HP engineer in Colorado Springs.

I asked once or twice how it went but when push came to shove other projects were given priorities and the idea lead to lala land. In this case your ears. :-)

Anyway, great job Eric and I hope to see this coming in array/switch implementations in the very near future. Will save many people a lot of headaches. :-)

Erik Smith

Hi Erwin, thanks! For our customers sake, I wish you had succeeded earlier! I think it would have made FC much easier for them to use...

Regards, Erik


Thank you Erik :) Appreciate your reply


Any progress on this really interesting topic?


Hi Michal, yes we're making progress on TDZ. I hope to have something significant to share in the next few days.



Hello Erick,

its a brilliant idea and significant savings from a operational perspective.

may i know how its making progress in terms of implementation by storage vendors (EMC, Cisco, Hitachi)?


Erik Smith

Hi Mallik, thanks! I was pleasantly surprised with all of the attention TDZ recieved at EMC World this year. Although interest from our Customers (and competition) is way up compared to a year ago, I cannot share anything specific about our product plans at this point. I can say the amount of time I've been spending on it recently has dramatically increased but its too early to say what will come of that effort.


Hello Eric,

As the concept of TDZ is still interesting to me, now, about 4 Years after, I wonder what was the popularity and the adoption rate by the customers?


Erik Smith

Hi Igal, although Brocade has supported TDZ since FOS 7.4 and I know at least one of our competitors support it as well, I don't have any information about actual adoption. Once our storage arrays support the feature, we'll have a better idea of actual adoption and I'll provide an update at that point.

The comments to this entry are closed.


  • This is not an official EMC blog.
    The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC nor does it constitute any official communication of EMC.