|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: ISID issueJim, > As I said in my last note, I'm willing to abandon use of the ISID for the > purposes of naming SCSI Initiator Ports and replace that with some text key > (so that ISIDs are removed from the dual role of identifying sessions AND > SCSI initiator ports). But I haven't seen any specific proposal to that > effect and that addresses all the issues involved (as outlined also in my > last note). Ok, I think this is the key piece of your last note: > My point general point is > that I believe we need to have an unambiguous identifier of the SCSI > initiator port. This is for reasons of > (a) persistent reserverations (as defined today) as well as for future > extensions > (b) there is an obligation today (I think) for the transport layer to > present to the OS layers above a "picture" of the SCSI Initiator Ports > (isn't that what you keep saying goes in /dev stuff?). Wedge drivers rely > on this stuff too. > (c) some access control stuff (as defined by T10) but this is not a hard > requirement I would do the following: (a) Set aside all notion of "future extensions" thereby removing a need for an externally visible iSCSI Initiator Port Name for this purpose. (b) Use the iSCSI Initiator Node Name + iSCSI Target Node Name + TSID for this purpose. (c) Do nothing in the absence of a "hard requirement", and try to use the Initiator Node Name for this purpose rather than a Port Name. I would plan to deal with "future extensions" via a possible "future text key" to be specified after the "future extensions" are so that we have a concrete set of requirements and objectives to work to. In the Interim, we can advise T10 that iSCSI strongly prefers reservations to be associated with Initiators, rather than Initiator Ports. > In fact, if we do find an alternative to the ISID for naming SCSI Initiator > Ports, then the ISID would be irrelevant to the SCSI model (as the TSID is > now) and we won't need the ISID rule anymore (we'd need another rule for > port names, however). This includes one more reason: (d) iSCSI entity to which the SAM2 concept of SCSI Initiator Port maps to. As we discussed, and I think agreed, earlier, it is sufficient to assert the existence of such an entity in an iSCSI implementation (some sort of session data structure) for the purpose of mapping, but not provide an externally visible name that is independently useful outside the bounds of the specific iSCSI implementation. I think this leads to removing ISIDs and the ISID RULE without substituting a port name rule. What goes wrong if this is done? > We can then ask if there is any value in the iSCSI > protocol for either the ISID or the TSID (as I did many many > months ago prior to this dicussion). I'm not seeing any. We might be better off using that field to hold the Target Portal Group number; TSIDs would then only need to be unique to an Initiator within a Target Portal Group, and hence could be independently managed on a per-Portal Group basis, as opposed to the current TSID RULE that spans the entire Target (instead of configuring TSID ranges, one configures the Portal Group Number, which probably needs to be configured anyway). This also makes any attempt to span Target Portal Groups or recover a session across Target Portal Groups immediately obvious to the Target (the first is forbidden, the second might work, but probably requires special handling at the Target, and may need some more protocol support). One consequence of this field change would be to add Target Portal Group to (b) above, and that may actually be a good thing as it forces exposure of this fundamental level of structure. John had previously had a bad reaction to my additional suggestion to change the TSID field size to 24 bits and the Portal Group field size to 8 bits if the ISID to Target Portal Group change is made, but that's a second order issue at best (and one that I don't care that strongly about). Are we getting anywhere? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------
Home Last updated: Thu Oct 04 15:17:24 2001 7041 messages in chronological order |