Subject: Re: UNH Plugfest

From: "Julian Satran" <[email-masked]>
Date: Fri, 15 Feb 2002 10:22:54 +0200

Bob,

Thanks for the great work at the plugfest.

As for the question at hand - I think you did see already two opinions, 
that I tend to agree with, that those poor souls that still rely on the 
the CDB LUN should fix their drivers.

We tried hard to avoid having to look inside the CDB all over iSCSI (we 
don't even have to look inside to determine the length and that was 
considered too at a point) and I don't see any good reason to break this 
rule.

Thanks,
Julo

"Robert D. Russell" <[email-masked]>
15-02-02 00:11

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        Re: UNH Plugfest

Julian:

The last several days at the UNH plugfest have uncovered no major
issues relating to the standard.

One thing that was observed was that a number of implementations are
dealing with SCSI-2 systems, because most of the world (i.e., Windows)
is still based on SCSI-2.  The iSCSI standard clearly references the
SCSI-3 specifications.  However, perhaps we should consider how iSCSI
could be used with SCSI-2.

In particular, there is the issue of LUNs.  Some implementers are
expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order
bits of byte 1 in the CDB, and are not setting/using the LUN field
in the iSCSI PDU.  This is clearly wrong, although if both target and
initiator do it, then they interoperate with each other but not with
standard-conformant implementations.

Of course, there may be (and probably are) additional issues (besides
the LUN issue) that may arise.  However, it still might be useful to
warn implementers that this is an issue, and perhaps to suggest a
"conversion rule" that would allow SCSI-2 to interoperate with iSCSI.

One possibility for such a rule follows:

If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN,
it should extract the LUN from the 3 high-order bits of CDB byte 1
and send that in the iSCSI LUN field (unless, of course, it has some
other means of obtaining the LUN value independent of the CDB, in which
case it should send that value in the iSCSI LUN field).

If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if
the iSCSI LUN field is 0 it should extract the LUN value from the
3 high-order bits of CDB byte 1 (which in the SCSI-3 case should always
be 0 anyway) and use that as the LUN value;
if the iSCSI LUN field is not 0 then it should use that as the LUN value.

At first glance this rule seems to allow an initiator and/or a target
to interoperate with both SCSI-2 and SCSI-3 systems.

Comments?

Bob Russell, UNH
Rod Harrison, Wind river

---

From: "Robert D. Russell" <[email-masked]>
Date: Fri, 15 Feb 2002 08:39:27 -0500 (EST)

> considered too at a point) and I don't see any good reason to break this

I certainly agree that the spec does not need to be changed in any way
to accommodate this.  The thought was only that somewhere, perhaps in
an appendix or maybe a separate document, the issue of dealing with
legacy SCSI systems could be deal with so that everyone would do it
the same way and thus be interoperable.  But the spec as written is
fine, and hopefully the operating systems still using the old SCSI
specs will be upgraded in the near future (but there will always be
users running older systems!)

Bob Russell

---

From: "Rod Harrison" <[email-masked]>
Date: Fri, 15 Feb 2002 17:43:13 -0000

Ditto to what Bob said. This question arose because we saw
implementations here at the plugfest ignoring the LUN field in
the iSCSI PDUs in favour of the SCSI CDB LUN field. Clearly this
is wrong but the spec doesn't say so, it is only implied because
all SCSI references are to SAM-2.

	- Rod

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of
Robert D. Russell
Sent: Friday, February 15, 2002 1:39 PM
To: Julian Satran
Cc: [email-masked]
Subject: Re: UNH Plugfest

> considered too at a point) and I don't see any good reason to
break this

I certainly agree that the spec does not need to be changed in
any way
to accommodate this.  The thought was only that somewhere,
perhaps in
an appendix or maybe a separate document, the issue of dealing
with
legacy SCSI systems could be deal with so that everyone would do
it
the same way and thus be interoperable.  But the spec as written
is
fine, and hopefully the operating systems still using the old
SCSI
specs will be upgraded in the near future (but there will always
be
users running older systems!)

Bob Russell