RE: iSCSI: multiple sessions b/n a pair of WWUIs.

["John Hufferd" <hufferd@us.ibm.com>]

David,
let me argue another side.  I was about to send my version of what Jim
said, but I think Jim, as usual was "dead on".  It is important to be
completely correct here.  This direction seemed to be having an influence
on MIBs and other things.  Though it is possible to do what you suggest, I
would say that doing so causes unintentional thought problems.  That is,
it is important that the Initiator Side (or the Target Side)  have a way
that the Management/Configuration Software can tell the iSCSI Port what the
iSCSI Node Name is, and what ISID value (or Range) should be used.  This is
true if the iSCSI Port is a SW entity or a HW iSCSI Host Bus Adapter (HBA).

It is much simpler for an iSCSI Port to use one ISID for every session it
creates to any target, then to have an algorithm for deriving one.  (Yes, I
know someone has to do that, but I think it should be done at the
Configuration Software level instead of at the iSCSI Port level.)

Also, since a second session by the same iSCSI Initiator Port, to the same
iSCSI Target Port is not, in my opinion "legal", it is not clear to me that
any given iSCSI Port needs any more then one ISID.  If we say anything
else, I think we risk the danger of mixing the concept of Wedge Driver in
with the concept of iSCSI Port, and that will do us all a disservice.

Some folks are going to want to define Wedge Drivers, and there should be
no interfering thought that some how the same iSCSI Initiator Port can have
Multiple Sessions to the same iSCSI Target Port (this is the domain of
Multiple Connections per Session).  Wedge Drivers, if needed, should be
seen as something that span iSCSI Initiator Ports and address specific
iSCSI Target Ports.  (Implementations may blur the levels here, but the
concepts should be clear.)

Therefore, I suggest that we Not put any such notes, like you suggest, in
the draft, but in fact encourage a single ISID/TSID per iSCSI
Initiator/Target Port.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: hufferd@us.ibm.com


Black_David@emc.com@ece.cmu.edu on 05/07/2001 07:52:08 PM

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


To:   Jim Hafner/Almaden/IBM@IBMUS, marjorie_krueger@hp.com
cc:   ips@ece.cmu.edu
Subject:  RE: iSCSI: multiple sessions b/n a pair of WWUIs.



While Jim's correct ... in Marj's defense, what
she wrote is a fairly obvious way to implement
it, and that might be worth noting in the draft.

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

> -----Original Message-----
> From:   Jim Hafner [SMTP:hafner@almaden.ibm.com]
> Sent:   Monday, May 07, 2001 10:44 PM
> To:     KRUEGER,MARJORIE (HP-Roseville,ex1)
> Cc:     ips@ece.cmu.edu
> Subject:     RE: iSCSI: multiple sessions b/n a pair of WWUIs.
>
>
> Marj,
>
> I think you've stretched my words too far.  The requirement is for a
> single
> logical unit to recover enough identity information provided through the
> I_T_L nexus to reestablish the reservation.  That means that the
name+ISID
> must be unique *from the viewpoint of a single iSCSI target device*.  So
> it's more like the
> "initiator must have unique ISID for all sessions with <delete>all
> targets</delete> any given target device".
>
> The best way to think about this is the following:
> 1) only a single target's (actually logical unit's) view of the initiator
> counts in this regard
> 2) there are no rules in SCSI concerning multi-target device interactions
> In other words, for these rules, look only from inside a target going
out.
>
> Jim Hafner
>
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 05/04/2001 05:39:35 PM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "'Matt Wakeley'" <matt_wakeley@agilent.com>, ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: multiple sessions b/n a pair of WWUIs.
>
>
>
> > One clarification: these are unique between any I-T *pair*.
> > (you make it sound like an initiator must have a unique ISID
> > for all sessions
> > with all targets)
> >
> > -Matt
>
> The ISID must be unique within the iSCSI layer on an iSCSI device - that
> amounts to "initiator must have unique ISID for all sessions with all
> targets".
>
> To quote Jim "The requirement in name+disc that a given initiator name
> cannot reuse an ISID for two different sessions comes as a consequence a
> number of things (which are described in the draft).  The gist is that
> this
> is needed to provide the correct context for restoration of reservations
> state (and other nexus state) to a particular nexus after logout/login.
In
> other words, if the session goes down for some reason, the target needs
> clear context to restore nexus state to a rebuilt session. The only tool
> it
> has is uniqueness of Name+ISID combination within its name space."
>
> -Marj
>
>