Subject: RE: iSCSI: login issue - partial consensus call

From: "Martin, Nick" <[email-masked]>
Date: Wed, 5 Sep 2001 16:49:44 -0500

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:[email-masked]]
Sent: Friday, August 31, 2001 12:09 PM
To: Martin, Nick; [email-masked]
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

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 6 Sep 2001 10:56:50 -0400

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:[email-masked]]
Sent: Wednesday, September 05, 2001 5:50 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); [email-masked]
Subject: RE: iSCSI: login issue - partial consensus call

Marj,

Thanks,
Nick
-----Original Message-----

initiator to
Each
established,
but
ISIDs it
attempting
to
agent.

Marj

---

From: Santosh Rao <[email-masked]>
Date: Thu, 06 Sep 2001 11:56:47 -0700

> Given this, accidental overlap in ISID space is not unlikely.

In the above scenario, if the HBAs do not have an interface to receive a
range of ISIDs from the OS iscsi driver, then, they must also lack an
interface to be handed down an iscsi initiator node name from the
OS driver. Without using a common iscsi initiator node name, the ISID issue
does not arise for multiple HBAs. [since each would be using its own iscsi
name].

OTOH, if the HBAs have an interface to be handed down an iscsi initiator
node name from the OS driver, there's no reason for them to not provide an
interface to be handed down an ISID or a range of ISIDs for their use.

I am in favor of option (A) since it is the simplest and a well designed
HBA should be providing interfaces for the OS driver to assign the HBA an
iscsi initiator node name as well as a range of ISIDs, thus, rendering
Nick's scenario unlikely.

> still attempt to come up without impacting the sessions established by

If the tools were not available, how does the 2nd HBA get assigned the same
iscsi initiator node name as the first ? The ISID issue is only applicable
if both HBAs are sharing the same iscsi initiator node name.

I would like to understand the rationale behind an HBA interface allowing
an initiator node name to be assigned, but not an ISID or a range of ISIDs
(?).

Regards,
Santosh