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

["Douglas Otis" <dotis@sanlight.net>]

John,

I am a bit confused by your comments.  From my understanding, the Initiator
model is now multi-port where each service port is identified by Initiator
Label+ISID.  Where I agree the essential aspect required by the Target is to
have a unique means of identifying the Initiator, the added requirement of
ensuring ISID is unique for all Targets does not detract from this essential
requirement stated by Jim.  With a multi-port model, an Initiator can indeed
have multiple sessions.  With the abstract service port, the need for the
wedge driver changes as the service port is no longer tied to physical
hardware.  This abstraction does the right thing unlike those that attached
to the physical hardware.

It is really hinged on how you wish the database held in the Initiator
sorted: ISID or Target Label.  It seems appropriate to attach structures on
those ISIDs that represent reconnections or reservations.  On the other
hand, you seem to be advocating a name list.  The usefulness of ISID is also
diminished if the client is not expected to maintain this value as unique
across all Targets.

Doug


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