Subject: iSCSI: INQUIRY page 0x83 identifier

From: Raghavendra Rao <[email-masked]>
Date: Tue, 23 Jan 2001 11:02:05 -0500 (GMT)

This may seem like a T10 issue at a high level, but I'm concerned that
SPC-2 (SCSI primary command set) defines in the INQUIRY page 0x83 identifier
type field, a FC identifier type (value = 3).

What identifer type should an iSCSI target use to report a LU identifier
when queried for page 0x83 ? Luckily there seem to be a generic IEEE
extended identifier type (value = 2).

Is the naming and discovery document going to provide a clear defintion
about LU names ? I understand that there should be NO interconnect specific
identifier at the SCSI layer - But SPC-2 is already polluted with a FC
identifier type.

-JP

---

From: "Elliott, Robert" <[email-masked]>
Date: Thu, 25 Jan 2001 16:02:51 -0600

I agree that SPC should not reference FC-PH, FC-PH3, and FC-FS for 
VPD "Device Identifier" type 3h, especially given that iSCSI and 
InfiniBand SRP devices will want to use that format.

We could describe the format in SPC-3 itself, making sure to match 
the existing FC formats.  We could leave out some of the choices, 
perhaps only documenting the 64-bit IEEE Registered and 128-bit 
IEEE Registered Extended formats.  

For reference, the FC-FS formats are:
* IEEE (48 bits, 802.1A universal LAN MAC address)
* IEEE Extended (48 bits + 12 more bits)
* Locally assigned (60 bits)
* IP (32-bit IPv4 + 32 bits of padding)
* IEEE registered (24-bit company ID + 
  36-bit vendor-specified identifier)
* IEEE registered extended (24-bit company ID +
  36-bit vendor-specified identifier +
  64 bit vendor-specified identifier extension)
* CCITT individual address (60 bits)
* CCITT group address (60 bits)

(the 4 bit NAA field identifying the naming authority increases
these to 64 bits each, except for registered extended which is
128 bits)

> -----Original Message-----
> From: Charles Binford [mailto:[email-masked]]
> Sent: Thursday, January 25, 2001 8:46 AM
> To: [email-masked]
> Subject: RE: iSCSI: INQUIRY page 0x83 identifier
> 
> Jim,  You didn't confuse me more - you made a very good point.  The
> identifier is for the LU and is *independent* of the 
> transport.  In fact, it
> is vital that the same identifier be given over any path, any 
> transport.
> Consider a storage device that has multiple host interfaces, 
> some may be FC,
> some may be iSCSI, some may be parallel SCSI.  If a host does 
> an INQUIRY
> page x83 to the same LU through any of the above mentioned 
> interfaces, it
> better get the same identifier back.
> 
> Using an "FC type identifier" does not imply the interface is 
> FC.  It just
> specifies the format of the data.  For the binary 
> identifiers, even the
> format of the identifier is a 'don't care' to the host as it 
> should treat
> them as opaque fields that can be matched, but not parsed.  
> By following the
> format rules, however, the LU can ensure the identifier it gives is
> world-wide unique.
> 
> 
> Charles Binford
> Blue Spruce Networks
> office/cell: (316) 210-6404
> e-fax: (509) 756-4425
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jim Hafner
> Sent: Wednesday, January 24, 2001 9:33 PM
> To: [email-masked]
> Subject: Re: iSCSI: INQUIRY page 0x83 identifier
>
> JP,
> 
> The identifier in this page of Inquiry is NOT at the 'target 
> device' or
> 'iSCSI device' layer.  It is an identifier for the logical 
> unit to which
> the inquiry command was sent.  The FC format was meant 
> primarily for FC
> disk drives that have only one logical unit (though it can be 
> used in some
> ways by FC controllers, etc.).
> [deleted]
> 
> Did I confuse things even more?
> 
> Jim Hafner
>

---

From: Raghavendra Rao <[email-masked]>
Date: Thu, 25 Jan 2001 10:40:30 -0500 (GMT)

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

This is a good starting point - I accept it. But wouldn't it help iSCSI
if NDT recommends a LU identifier format ? I'm not asking for a new invention
of LU identifier format here - I'm asking for adoption of one of the formats
that SPC-2 currently defines.

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

Does this mean that "type" field in the page 83 LU identifier shouldn't be
taken too seriously ?

Thanks.

-JP

---

From: Robert Snively <[email-masked]>
Date: Fri, 26 Jan 2001 13:30:43 -0800

> 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

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.

---

From: "Elliott, Robert" <[email-masked]>
Date: Mon, 29 Jan 2001 10:38:37 -0600

> From: Michael Krause [mailto:[email-masked]]
> Sent: Friday, January 26, 2001 9:08 PM
> To: Robert Snively
> Cc: [email-masked]
...
> 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.

A RAID controller needs to construct unique identifiers for
its virtual volumes.  The hardware typically has a single
EUI-64.  It's difficult for software to construct unique
64-bit identifiers that don't interfere with the EUI-64
namespace.  The hardware EUI-64 would have to represent a
range rather than just one ID.  It's much simpler to use the 
EUI-64 as a base and append bits to the end.  That's how the 
128-bit Registered Extended format is used.

I wouldn't mind only documenting the 64-bit IEEE Registered
and 128-bit IEEE Registered Extended formats in type 3h.
However, this is an SPC-3 issue, not an iSCSI issue.

The difference between the type 2h EUI-64 and the type 3h
IEEE Registered type is the latter includes a 4-bit Naming
Address Authority (NAA) field, restricting the 
vendor-specific portion to 36 bits.

Type 2 (EIU-64):
	24-bit company ID + 40 bit vendor-specific

Type 3 (FC-FS): 
	4 bit NAA + 60 bit NAA-specific

  Type 3 NAA=IEEE Registered:
	24-bit company ID + 36-bit vendor-specific
  Type 3 NAA=IEEE Registered Extended: 
	24-bit company ID + 36-bit vendor-specific + 64-bit vendor-specific

---
PC: [email-masked]
UNIX: [email-masked]

---

From: Robert Snively <[email-masked]>
Date: Mon, 29 Jan 2001 12:50:43 -0800

Michael,

In answer to your question:

>  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

>  Sent: Friday, January 26, 2001 7:08 PM
>  To: Robert Snively
>  Cc: [email-masked]
>  At 01:30 PM 1/26/2001 -0800, Robert Snively wrote:
>  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: Robert Snively <[email-masked]>
Date: Mon, 29 Jan 2001 12:50:43 -0800

Michael,

Bob

---

From: "John Hufferd" <[email-masked]>
Date: Mon, 29 Jan 2001 20:48:47 -0800

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: [email-masked]

Jim Hafner/Almaden/IBM@[email-masked] on 01/29/2001 09:08:44 AM

Sent by:  [email-masked]

To:   [email-masked], Robert Snively <[email-masked]>
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 <[email-masked]> on 01-26-2001 01:30:43 PM

To:   Jim Hafner/Almaden/IBM@IBMUS, [email-masked]
cc:
Subject:  RE: iSCSI: INQUIRY page 0x83 identifier

Jim,

---

From: Robert Snively <[email-masked]>
Date: Tue, 30 Jan 2001 06:56:03 -0800

>  to some defined iSCSI mechanism seems inappropriate.

Jim,  There is actually nothing "FC" about the number defined
except the fact that the format is defined in an FC document.
Everything else about it is generic and is in fact used in all
SCSI transport families.

>  rooted in EUI-64 for the device. 
>  

Jim and Rob,  There is no standard 128 bit format rooted in EUI-64.
You will have to invent one, define it in a standard document, 
route it up through the IEEE tutorial definition process, and change
SPC to get it identified as a standard.  Why not use the already
defined transport independent format defined in FC-FS, SPC, and the
IEEE tutorials.

Bob