RE: iSCSI: ISID issue

["Jim Hafner" <hafner@almaden.ibm.com>]

David,

You ask:
>The upshot is that ISIDs now serve no visible purpose, aside from
>complicating session setup - nonetheless, they're apparently going to
>stay in the specification ... did the N&D folks really intend this result?

The N&D folks never had any input to the creation or defintion or
specification of the ISID itself (that was in the main draft long before we
ever formed as a team).  Nor as a team were they involved directly with how
ISIDs are used in the current model.  I'll take almost sole responsibility
for that, with appreciation to some individuals of the N&D team for their
useful discussions and support.   So, don't blame the team, blame me and by
association a few others who were involved (and happen to be also on the
N&D team).
However, all I/we did was take the defined existence of the ISID in the
protocol and give it an additional role in the SCSI model.

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

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

Jim Hafner


Black_David@emc.com@ece.cmu.edu on 10/04/2001 05:24:38 PM

Sent by:  owner-ips@ece.cmu.edu


To:   John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: ISID issue



John,

Lacking additional visible support, I'm going to give up on this
issue, but I think a serious mistake is being made.  Two portions
of your message reinforce my opinion:

> However, there were some other things that we batted around that I will
> cover here.  First, the Name which you want to work with in the iSCSI
ACLs
> is the iSCSI Initiator Node Name.  That should be the same for ALL iSCSI
> Initiators in a Host Node.  If vendors attempt to use anything else, I
> think they are not following the spec.  And should be sent to Singapore
for
> Caning :-)

Not :-), rather an unrealistic exercise in wishful thinking.  I have yet
to see a coherent explanation of why this will not repeat the Fibre Channel
Node WWN experience (which started out with the same intention and the same
"not following the spec" notion for use of different Node WWNs on the same
Platform - nonetheless, that's what happened).  I expect problems to arise
not so much in iSCSI ACLs (a new mechanism), but in the adaptation of
existing
SCSI LU access control mechanisms to iSCSI.

> When Jim talked about the new SCSI idea that would have Persistent
Reserves
> being tied to the Initiator Node,  it seemed clear to me, and I think to
> the others on the team, that the iSCSI Initiator Node Name was ideal to
be
> used for that purpose.  Jim pointed out, again to us, that this name was
> NOT part of any other Nexus meaning, it is only to be used with
Persistent
> Reserves.   All other Nexus meanings are against the iSCSI Initiator's
FULL
> NAME which is the  iSCSI initiator Node Name and the ISID.

That is a change from what Jim has described on the list, which required
a persistent name for the iSCSI Initiator Port (not Node); what you have
described in the above paragraph does not.  Given that this sort of change
is possible in what T10 is considering, I think we should cease trying to
anticipate and provide for what T10 might (or might not) do, and instead
deal with the results of what T10 does after it happens.

The upshot is that ISIDs now serve no visible purpose, aside from
complicating session setup - nonetheless, they're apparently going to
stay in the specification ... did the N&D folks really intend this result?

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