RE: iSCSI UNH Plugfest

["ERICKSON,SHAWN (HP-Roseville,ex1)" <shawn_erickson@hp.com>]

> -----Original Message-----
> From: Elliott, Robert [mailto:Robert.Elliott@compaq.com]
> Sent: Thursday, February 14, 2002 6:58 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI UNH Plugfest
> 
> 
> Although those bits are often reserved, some commands use them (e.g.
> SEND DIAGNOSTIC).  It's not safe to guess that they contain a 
> 3 bit LUN
> value.

Correct.

> The iSCSI initiator driver should clean up the CDB as needed 
> (your first
> suggestion) and keep the wire protocol clean.  If it's in an OS
> generating old CDBs, it knows that and is best suited to fix them.
> Don't burden the iSCSI targets with any of this.

I second that!
 
> The UNH test suite should check for compliance for this and 
> other basic
[snip]
> * logical units implement VPD pages 80h and 83h
>   * 80h unit serial number
>   * 83h NAA type IEEE Registered or IEEE Registered Extended

Yes, please do. The world will be a better place for storage administrators,
your customers will love you.

> * initiators don't send TARGET RESETs

Yes, please do. Disruptive in multi-initiator environments (which is mostly
the domain of FC & iSCSI).

> * initiators use logical unit VPD data to identify logical units, not
> the dynamic fabric/bus address of the target

YES, please do. Again your customers will love you!

-Shawn

> > -----Original Message-----
> > From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
> > Sent: Thursday, February 14, 2002 4:12 PM
> > To: Julian Satran
> > Cc: ips@ece.cmu.edu
> > 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.
> 
>