RE: iSCSI: login issue - partial consensus call

["Eddy Quicksall" <eddy_quicksall@ivivity.com>]

David,

Now, I'm really confused...

I just read through the spec and I don't see where it mentions the
"Initiator" as you have presented it below. Can you please give me a
reference?

Section 1.1 appears to define "initiator" as:

  Clients of a SCSI interface are called "initiators".

  Initiators are one endpoint of a SCSI transport.

Section 1.2.1 says:

   The group of TCP connections that link an initiator
   with a target, form a session (loosely equivalent to a SCSI I-T
   nexus).

That does not seem to be consistent with your definition.

In parallel SCSI, you can have two different initiators talking to the same
target with both initiators on the same host ... your use of Initiator does
not seem to be consistent that that because you would allow only one
Initiator (the host).

Also, if the InitiatorName is the name of the host, how does an independent
HBA find out the name?

I would like to propose that "Initiator" refers to that end point which is
maintaining unique ISID's. I believe this definition would be consistent
with all that is in the spec.


Eddy

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Thursday, September 06, 2001 11:42 AM
To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
Subject: RE: iSCSI: login issue - partial consensus call


Nope, the iSCSI Initiator Name is supposed to refer to the
host into which the HBAs are plugged (or, more precisely,
the OS instance using the HBAs for systems that support multiple
OS instances).  If we were to change the naming approach to
associate Initiator identities with network interfaces, this
particular issue gets easier, but we'd have to take another
hard look at why multiple sessions are allowed between the
same Initiator and Target (ditto multiple connections per
session).

--David

> -----Original Message-----
> From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
> Sent: Thursday, September 06, 2001 10:57 AM
> To: Nick.Martin@compaq.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: login issue - partial consensus call
>
>
> But wouldn't the two different vendors you mention below have
> different
> iSCSI Initiator Names? Remember, the Initiator is not the
> host, it is the
> HBA in this case.
>
> If two different HBA's are going to play together then a
> common driver would
> be used and the driver would provide the iSCSI Initiator
> Name. Then, the
> ISID would be properly maintained by the driver.
>
> Think of the Initiator Name as the owner of the ISID's for that name.
>
> Eddy
>
> -----Original Message-----
> From: Martin, Nick [mailto:Nick.Martin@compaq.com]
> Sent: Wednesday, September 05, 2001 5:50 PM
> To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu
> Subject: RE: iSCSI: login issue - partial consensus call
>
>
> Marj,
>
> You mention vendors not knowing how to play right.
> The problem is that iSCSI does not and will not specify how two HBAs
> from different vendors installed in the same Initiator should or could
> get a range of ISIDs for their exclusive use.  This will be operating
> system specific and vendor defined.  It is uncertain that the
> same tool
> or repository would be used by all HBA vendors in any environment.
> Given this, accidental overlap in ISID space is not unlikely.
>
> Given that there is no one way to play right, we must make sure that
> everyone can at least play nice.
>
> My expectation is that sessions are infrequently established and long
> lived.  ISIDs may be re-used at will by their current owners.  When no
> "already owned" ISIDs are available, or an attempt to re-use
> an "already
> owned" ISID failed, and HBA would need to a) "probe" for a
> new available
> ISID or b) fail the request to establish the session.
> Session recovery
> should not be attempted unless a session is known to have failed.
>
> If tools are available, and the administrator has used them correctly,
> then HBAs will not collide in ISID space.  If the tools are not
> available or were not used correctly, I would hope the second HBA can
> still attempt to come up without impacting the sessions established by
> the first.
>
> Again, I state my support for a login with existing ISID harmlessly
> fails (the Target state does not change) unless a session recovery
> indicator is set.  Also if a session recovery indicator is
> set, and the
> ISID is not in use (by this Initiator at this Target), the login also
> fails.
>
> Thanks,
> Nick
> -----Original Message-----
> From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> [mailto:marjorie_krueger@hp.com]
> Sent: Friday, August 31, 2001 12:09 PM
> To: Martin, Nick; ips@ece.cmu.edu
> Subject: RE: iSCSI: login issue - partial consensus call
>
>
> > In particular this enables independent agents within the same
> initiator to
> > attempt a login without knowing all ISIDs in use by other agents.
> Each
> > agent would know the ISID of sessions it had successfully
> established,
> but
> > not the ISIDs for sessions established by others.  It can use the
> ISIDs it
> > knows to recover sessions it owns.  If an agent gets a  failure
> attempting
> to
> > establish a new session, it would pick a different ISID and
> > retry (or just quit), rather than disrupting a session of another
> agent.
>
> The intent of the presentation on SCSI/iSCSI modeling, and the text in
> the
> draft, is to illustrate how this example is not a recommended
> implementation
> choice due to the probability of violating the SCSI/iSCSI
> rules pointed
> out.
> If the "independant agents" had partitioned the ISID space,
> there would
> be
> no collision on login and no time wasted.  Your illustrated
> implementation
> could spend significant time "trying" ISID's in use by the "other
> agents".
>
> However, I'm starting to have more sympathy with Julian's concerns due
> to
> the apparent risks of different vendors' initiator implementations not
> following the rules.
>
> I just imagined having vendor A's HBA installed and happily servicing
> applications, installing vendor B's "plug-n-play" implementation, and
> having
> all A's sessions aborted cause B doesn't know how to play right :-(
>
> Marj
>