RE: iSCSI: ISID issue

[Black_David@emc.com]

Yet more comments inline.  --David
 
> David,
> 
> Comments in line.
> 
> Jim Hafner
> 
> 
> Black_David@emc.com on 10/04/2001 06:56:46 PM
> 
> To:   Jim Hafner/Almaden/IBM@IBMUS, Black_David@emc.com
> cc:
> Subject:  RE: iSCSI: ISID issue
> 
> 
> 
> Jim,
> 
> > 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.
> 
> <JLH>
> If we do (b), then we're effectively having hte target "name/identify"
SCSI
> Initiator Port.  OK, now, suppose the initiator has two sessions active to
> given target portal group.  On one (say with TSID=5) he sends persistent
> reserve registration and on another (say with TSID=7) he sends persistent
> reserve registration + reservation.  Now the target resets and the
> initiator cleans up context and starts up one new session.  What does the
> target do?  Does it assign TSID=5 or 7 or 9?

If the Initiator wants the state from TSID 5 (or 7), the Initiator sets TSID
to 5 (or 7) on Login.  If the Initiator does not want that state, it sets
TSID
to 0 on Login, and the Target can assign 9 or 15 or 523.  If the Target has
removed or lost the state for TSID 5 or 7, the Initiator gets back an error
when attempting to login using those TSID values.  Targets SHOULD NOT
aggressively reuse TSID values to avoid possible confusion (e.g., if in
the interim, the Target has assigned 5 to a new session from the same
Initiator, confusion may result - correctly written Initiators can avoid
such confusion, but not aggressively reusing TSID values increases
robustness).

[.. text asking how the above could work elided ..]

> I don't know what you mean by (c).  What "purpose" are you talking about?

Access control.  I think it should be clear by now that given the choice,
iSCSI Node Names are the preferred entities to use to express Access
Control policy and decisions, not iSCSI Port Names.  Note that my (a), (b),
and (c) were intended to respond to your (a), (b) and (c).

> 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.
> 
> <JLH>
> But I also argued that existing OS's like to see some consistency (you've
> even said they put stuff in /dev) on their initiator ports.  If these are
> all driven by the target (in the sense of identification), then where can
> the iSCSI layer provide such consistency?
> </JLH>

It won't be the TSID, and it probably won't be the ISID because, as
currently
specified, it also lacks sufficient consistency for this purpose.  The info
will come out of local device configuration information on the Initiator,
which may or may not turn out to match up with Initiator Portal Groups.
This
kind of thing is already platform-specific and will remain so.  Folks like
Veritas will continue to rely on their own volume headers for configuration
of VxVM and the like rather that device names (FWIW, this is the only
technique
that has proven to have sufficient robustness in practice).
 
> > 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.
> 
> <JLH>
> You're proposal to include the target portal group number in the TSID is
an
> *implementation of configuring TSID ranges* for each target portal group,
> isn't it?  In fact, that would be how I would implement it my target (if I
> was building one, whether the spec said that it had this form or not --
and
> I'm implement my host driver pretty much the same way, via enumeration of
> drivers/devices  (which pretty much constitute initiator portal groups) as
> they are discovered/loaded by the OS).  Such an implementation guarantees
> compliance with the TSID RULE (and would do the same for the ISID RULE as
> well).  So, you haven't avoided it, you've simply spec'ed an
implementation
> that meets the requirements.
> 
> The proposal to include the target portal group tag in the message header
> (either within or separate from the TSID) is an independent issue from the
> ISID one.
> </JLH>

I agree, but observe that if we specify the one and only way in which
the Target Portal Group MUST be encoded in the TSID, then code can be
written in both iSCSI implementations and management tools that relies
on the encoding being done that way.  I think there's value to that.

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