RE: iSCSI: INQUIRY page 0x83 identifier

["John Hufferd" <hufferd@us.ibm.com>]

Folks,
I think we have strayed from iSCSIness.  The things you are talking about
here is best handled with T10, I think.  As the attached note from Jim
Hafner, below states  "I'd like to keep iSCSI from specifying any
requirements on logical units (that's not the right space)".

It was an interesting seg-way getting into this, however, it does not apply
to the SCSI Transport called iSCSI.

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


Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 01/29/2001 09:08:44 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu, Robert Snively <rsnively@Brocade.COM>
cc:
Subject:  RE: iSCSI: INQUIRY page 0x83 identifier




Bob,

I strongly agree with the requirement that these identifiers be WWUnique.
But I also agree with Charles that whatever identifier that is presented
should be the same regardless of the interconnect, so binding them to FC or
to some defined iSCSI mechanism seems inappropriate.

So, I think I'm agreeing the Rob Elliot.  Namely, specify a 128 format
rooted in EUI-64 for the device. Back away from anything FC-specific in the
format of the EUI-64. A vendor of a storage controller will probably have
an EUI-64 for the device, though that might not be FC-based.  Use this as
the basis for some vendor-specific algorithm to generate the LU identifier.
Leave it to the vendor to define an algorithm that will provide the
uniqueness.

Also, I'd like to keep iSCSI from specifying any requirements on logical
units (that's not the right space).  SPC-2/3 can spec a general format and
the requirement for uniqueness.  Then leave it to the vendors to implement
correctly.

Does that sound reasonable?
Jim Hafner


Robert Snively <rsnively@brocade.com> on 01-26-2001 01:30:43 PM

To:   Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: INQUIRY page 0x83 identifier



> As for an iSCSI type or format for logical unit identifiers:
> 1) SCSI already allows for an ascii formatted identifier (typically this
> includes vendor, model, serial number). Since NDT has defined WWUIs for
> DEVICES and these have a defined UTF-8 format, there is nothing to
> *prevent* a vendor from using these strings as the starting point for LU
> page 83 identifiers of the logical units within that device.
> 2) But..., iSCSI and NDT should not attempt to make a rule under which
> these are used.  FC's intervention in this was more as a strong
suggestion,
> and is certainly not a requirement.

Jim,

I generally agree with the text of your comments, but there are
a couple of details I would like to address.

Any name not based on a registered entity and in a registered format
is not guaranteed to be world-wide unique, and is therefore
inappropriate.  That is why numbers like OUIs and SCSI Vendor IDs
in specified parts of the identifier are a requirement.  EUI-64
and FC identifiers have that property.  FC identifiers have the added
benefit of having a regular extension capability for dynamic creation
of logical units.  As you point out, iSCSI need not use FC
identifiers, but a bunch of people like them for their constant
defined length and guaranteed world-wide unique identifiers.

However, I feel that iSCSI should be a lot more hard nosed than
SAM-2 and require that VPD page "83" contain a mandatory world-wide
unique logical unit identifier in an appropriate invariant format.
For compatibility with other SCSI drivers, it should be limited
to 128 bits of length.  This would not be an identifier set by
the user (there are other SCSI identifiers that can be set by the
user), but one that is invariant from the time of manufacture (for
physical devices) or creation (for logical devices) of the logical unit.