Subject: RE: iSCSI: INQUIRY page 0x83 identifier

From: Michael Krause <[email-masked]>
Date: Fri, 26 Jan 2001 19:07:41 -0800

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

---

From: Patrick Stirling <[email-masked]>
Date: Fri, 26 Jan 2001 20:31:46 -0800 (PST)

> components / controllers.  Having a 128-bit value seems like overkill and 

Well, I'd prefer to stick with the current scheme of allowing the device
to specify its identifier within certain limits (table 181 in spc2r18).

I'm working on a virtual storage server, which serves up virtual disks on
the fibre-channel SAN (with iSCSI coming soon I expect). We set just this
identifier in VPD page 0x83, using a type 3 identifier (FC-PH) - actually
a Registered Extended IEEE Name, 128bits. It's convenient to use this
length as it allows me to set the upper 64bits to our server's WWN (which
is also used as the World-Wide Node Name shared by all target HBAs on the
server), and the lower 64bits to a simple number identifying the virtual
disk on this server.

This makes it easy to set an identifier which is guaranteed unique
world-wide, although it does have the drawback of making it hard to
keep the id if you move the virtual disk's data to another server.

With the formatting of the various identifiers, 64 bits doesn't go very
far at all.

patrick
Patrick Stirling
VERITAS Software Corporation
[email-masked]

---

From: Michael Krause <[email-masked]>
Date: Mon, 29 Jan 2001 10:16:15 -0800

>server), and the lower 64bits to a simple number identifying the virtual

Sounds like an IPv6 address.  InfiniBand uses the same technique where an 
EUI64 is combined with an IPv6 subnet prefix.  This provides the 
flexibility you desire with a manufacturer unique GUID.  It also makes 
attachment to the Internet much simpler as well as leverages existing / new 
IPv6-based tools / services.  BTW, wireless seems to be moving towards IPv6 
as well so why not just use the same paradigm for everything: server I/O 
interconnect, wireless, storage, etc.

Mike