iSCSI: ISID progress

[Black_David@emc.com]

This message is shorter than my last one, so that's
at least a superficial indication of progress ;-).

Jim and Julian had four comments/objections to the
notion of using a text key to indicate iSCSI Initiator
Port Name.  Summarizing and responding:

Jim (a): Optional use of port name is ok as far as SAM-2 is
	concerned, but is odd.

Indeed it is odd, but given the choice between an odd
mapping of SAM-2 to iSCSI and allowing odd behavior of
iSCSI implementations, I'll take the former.

Jim (b): Would require at least as much coordination above
	the session level of iSCSI as ISIDs.

That would be incorrect.  128 bits is sufficient to eliminate
coordination.  The reference for this is an expired Internet-
Draft, draft-leach-uuids-guids-01.txt, that can still be found
on the web at:

http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt
http://globecom.net/ietf/draft/draft-leach-uuids-guids-01.html

I'm not seriously proposing that port name generation be done
in this fashion, but rather providing a widely used counter-
example to Jim's statement.  Note that a network interface
MAC is likely to be available to many iSCSI implementations.

Jim (c): How to describe model when the text key is optional?
	"Is it that all initiator session endpoints that don't
	 provide this text key have *implicit* unique names and
	 only when the text key is presented does the name get
	 explicit (and then possibly not be unique)? In that case,
	 the key would have to be supplied in login next to the
	 InitiatorName.

Yes and yes when it's used, in that order.  Jim's comment (a)
about this being odd applies.

Julian: ... and have as much chances to blow a session as ISID

That would also be incorrect.  As previously stated, ISID conflict
is fatal to one of the sessions involved (one cannot change the
ISID and continue), and can occur in any system that opens parallel
sessions.  This text key conflict need not be fatal (one can
change the text key and continue negotiation) and can only occur
in systems that want to use the new port-spanning persistent
reservation functionality, as other systems won't use the text
key.  Also see the draft noted in response to Jim (b) above;
Julian's "have as much chance" language is incorrect.

As previously noted, I can also deal with requiring conservative
reuse of ISIDs as a means to address this situation.

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
---------------------------------------------------