RE: iSCSI: INQUIRY page 0x83 identifier

[Robert Snively <rsnively@Brocade.COM>]

Michael,

In answer to your question:

>  Why not just require EUI-64 which is a very large name space 
>  and is / will 
>  be used in many hardware solutions today / future?  This 
>  would also fit in 
>  well with other I/O standards that use EUI-64 for 
>  identifying all I/O 
>  components / controllers.  Having a 128-bit value seems like 
>  overkill and 
>  provides little benefit.

The EUI-64 is fine for devices coming from a factory.  It is less
satisfactory for logical units that are created in the field, as
RAID logical units typically are.  Those cases also require unique
names which are never recreated when a logical unit is destroyed
and a new one created.  There is also no architected limit to the
number of logical units that can be created either at one time or
over the life of a RAID box.

As a result, the 128-bit format 6 Fibre Channel format is very
popular for logical units because the 64-bit core can be taken 
from the identifier of the creating controller (which may change 
over the life of the RAID) and the 64-bit extension can be 
created in a controller specific manner (using combinations of
time stamps and other parameters) that still guarantees world-wide
uniqueness.

Bob




>  -----Original Message-----
>  From: Michael Krause [mailto:krause@cup.hp.com]
>  Sent: Friday, January 26, 2001 7:08 PM
>  To: Robert Snively
>  Cc: ips@ece.cmu.edu
>  Subject: RE: iSCSI: INQUIRY page 0x83 identifier
>  
>  
>  At 01:30 PM 1/26/2001 -0800, Robert Snively wrote:
>  > > 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.
>  
>  Why not just require EUI-64 which is a very large name space 
>  and is / will 
>  be used in many hardware solutions today / future?  This 
>  would also fit in 
>  well with other I/O standards that use EUI-64 for 
>  identifying all I/O 
>  components / controllers.  Having a 128-bit value seems like 
>  overkill and 
>  provides little benefit.
>  
>  Mike
>  
>  
>