iSCSI - structured values

[Keith McCloghrie <kzm@cisco.com>]

Hi,

The following ideas came up in a discussion I had about iSCSI.

The first issue is about the algorithm to use for allocating the
structured ISID values, which contain three fields:

 - The Type field identifies the format:
           00h     - IEEE OUI
           01h     - IANA Enterprise Number (EN)
           02h     - "Random"
           03h-FFh - Reserved
 - The Naming Authority field identifies the vendor or organization
 - The Qualifier field is a 16 bit value that provides a range of
   possible values for the ISID within the Type and Naming Authority
   namespace.

The "notes" in draft-ietf-ips-iscsi-name-disc-03.txt specify:

     (a) As noted, the structure of the ISID namespace provides each
     vendor with its own piece of the ISID namespace.  In effect, this
     provides for a vendor-partitioning of that namespace within each
     initiator.

So, this puts the onus on a "vendor" to come up with the vendor's own
scheme for allocating ISID values.  For the situation where a vendor
wants to assign different values to different interfaces/HBAs, the
simplest scheme would be to use a unique value which is shipped with
each product, such as a MAC address.  This would be simple because it
would obviate any need to coordinate between different interfaces
(even those from the same vendor).  In fact, the first three bytes of
a 6-byte MAC address are an IEEE OUI, which is exactly what type=0
specifies, except that the MAC address has 3 more bytes, and the
Qualifier field is only 2 bytes.  So, in order to allow vendors to
adopt such a simple scheme, I'd like to propose that the Qualifier
field be enlarged to at least 3 bytes.  It probably doesn't make much
sense to make the overall ISID to be 7 bytes long.  So, how about
making the Qualifier be 4 bytes so that the ISID is 8 bytes long ?  
As far as I'm aware the performance impact of this is virtually
negligible, and so I can't really see any disadvantage in doing so.

The second issue concerns Portal Group Tags.  It seems that despite 
the difference in terminology, that an ISID and a Portal Group Tag
are corresponding concepts.  For example, a SCSI Port Name is defined
as "the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag".  However,
a Portal Group Tag is defined as a 16-bit integer.  Now, I understand
that an ISID was originally defined as a 16-bit integer, before its
format was expanded (as discussed above).  So, with the correspondence
of ISID and Portal Group Tag, surely it makes sense for a Portal Group
Tag to have the same format as an ISID.  This will allow vendors of
iSCSI targets with multiple interfaces/HBAs to use a simple scheme as
and when they need to assign different Portal Group Tag values to the
different interfaces/HBAs.  So, whether or not the ISID format is
changed based on the first issue above, I propose that the same
structured format be used for both ISIDs and Portal Group Tags.

Keith.