|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Canonical TargetsMark, > I also don't think that there will be a lot of single-target devices out > there, at least not right away. Perhaps not right away, but definitely eventually. Using the LUN model is the way to ensure that a target (true target, not bridge) implementation can be relatively transport independent. That's proven to be a major survival characteristic for targets. > Most devices will likely be accessed through iSCSI-FC or iSCSI-SCSI > gateways in the near future, before iSCSI interfaces are added to > the devices themselves. Our gateway, for example, provides more > than one target; my guess is that others will do the same. Agreed. The only SST target in the world is a gateway, and it provides multiple target support as well. Our solution to this problem was to constrain the target addressing range so that the initiator can do the traditional big crawl. SST was aimed at a different design point, so I'm not saying we should adopt the same solution with iSCSI, I'm just agreeing that allowing multiple targets behind an endpoint in the protocol design is a good idea. > In this case, an initiator has to deal with multiple targets > anyway. Absolutely. However, in the limit, the bridges usually wither away. Sometimes they wither away a lot faster than you might expect. There were some early attempts at FC/||SCSI bridging that worked from the same set of assumptions. You probably don't need to know how successful those were. That would never happen to today's modern bridge vendor, since they've learned how to apply all their accumulated cleverness to building native targets in short order :^) The bridged scenario shouldn't be at the expense of the unbridged one. My proposal of allowing: 1) target discovery login 2) operational login to a default (Julian's right---the term canonical is inappropriate) target 3) operational login to a specified target seems to cover all bases. If your bridge does not want to support a default target (I bet it will.... how else will you be able to slap it under the skins with a Symmetrix and call it an iSCSI storage array?), you can reject the login, with a `no default' reason code (TBS). I don't mind adding Jim Hafner's multi-layer discovery proposal if you guys really think it will help. Personally, I'm skeptical. Whatever the case, it seems like it can be done in such a way as to still permit a single-layer login when given nothing but socket coordinates. Let me beat on this one final time. I think EVERYBODY on this list is aware that the biggest selling point of iSCSI across the entire range of applications is that it leverages existing IP management skills. As such, using socket coordinates to specify targets is what IP managers understand. That doesn't mean we can't introduce additional concepts, but the users should be able to get going without them. Steph
Home Last updated: Tue Sep 04 01:04:42 2001 6315 messages in chronological order |