Subject: RE: iSCSI: Support Alias in the protocol

From: Kevin Gibbons <[email-masked]>
Date: Tue, 7 Aug 2001 15:04:08 -0700

I support the Alias field.  I can see value in being able to assign a user
readable name to a storage device that is not required to be unique or
adhere to a specific format.

Regards, Kevin

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 9:52 AM
To: [email-masked]
Subject: iSCSI: Support Alias in the protocol 

Today at the 51st meeting of the IETF, I presented an issue that came out
of the Naming and Discovery Team.

That was that some members of the team did not understand why we needed to
have an Alias field, which is in the base protocol today, since it was
technically not needed.   The position I presented to the group was that
the Naming and Discovery Team did not have consensus, since many of us felt
that having a Human oriented "Tagging" function was useful, and a small
item which would be useful for Administrators especially when EUI names are
used.

One person, at the meeting today, stated that it might not be of extreme
importance on large Networks with sophisticated Management tools, but it
was very useful in small to medium environments, where the Management tools
were slim.  And at least one person stated that since it was not required,
it should not be in the protocol.

As the conversations when on, it was pointed out by the area director,
Scott  Bradner, that SLP used a similar Text field in its protocol, so
there was clearly a president.

In any event, we could not reach consensus at the meeting, so I was asked
to bring the issue to the List.  (So here it is!)

Please state your positions so that David can call a consensus.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 9 Aug 2001 12:41:50 -0400

> of the Naming and Discovery Team.

Didn't come out of NDT, I raised it on the IPS list.

> technically not needed.   

There is no question of "not understanding" anything, the statement of fact
is that this is not used by the protocol, not necessary to the protocol
function, and therefore should be deleted.  I can think of all sorts of
things that "it would be nice for the protocol to do", can I add them all?
It would be nice, for instance, to have a color text command, that would
cause the display on the device to turn a different color - shall we add
that?  Where do you draw the line? ;-)

>The position I presented to the  group was that
> the Naming and Discovery Team did not have consensus, since 
> many of us felt that having a Human oriented "Tagging" function was useful

Many?  Most didn't care!!  A few thought it would "be nice" but agreed it
was not used by the protocol.
 
..snip..
> were slim.  

But it requires a management tool for the alias information to be displayed
to the user.  Does it make a mgmt tool "sophisticated" to add a text label
of it's own to iSCSI target names?  I think not ;-)
  
> there was clearly a president.

This statement is incorrect. Scott made a reference to the fact that *SNMP*
carries this sort of information (mgmt information!).  There is no known
*precident* for this sort of field in a protocol.  Even if you find a
precident, it doesn't mean it's a smart thing to do.

We have been discussing simplifying the protocol.  Deleting this command
doesn't represent a huge simplification, but retaining it on the basis that
"it is nice" is not logical.  The point is where do you draw the line
regarding protocol commands?  Shall we add more "nice to have" things, even
though they aren't used by the protocol but provide some sort of mgmt
function?  Didn't we already go thru this discussion regarding the
SendTargets command?  Let's at least try to be consistant.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked]

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 9 Aug 2001 13:30:24 -0700

Marjorie,
I did not intend to give a Skewed report.  Since you think I did, I
apologize.

I get so much e-mail I can not remember if you sent it to the list or to
the NDT team, if you say the list, fine, I am not sure it matters, since we
decided in the NDT for me to take it to the meeting in London.

Perhaps it was SNMP instead of SLP, OK, the precedent (see even I can
sometime get some spelling right) is there.  I know you do not think it
counts as much, and that is true, but it does count for something.

Your point that I think you are making -- that a Management tool to input
the Alias is needed so why not leave it up to the Management tool to handle
and remember the Alias etc. -- is perhaps over stated.  All of the
implementations that I am aware of, will have a way to input the Initiator
and Target iSCSI Node Names, etc.  This is really basic stuff, and not a
Tivoli or HP Open View type of management action, especially in small to
mid environments.  Having this basic tool also add the Alias stuff is not a
hard thing to assume.

It also makes since to have the Alias reflected in the MIB, and reported
via SNMP when something happens.

.
.
.
John L. Hufferd

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>@ece.cmu.edu
on 08/09/2001 09:41:50 AM

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS, [email-masked]
cc:
Subject:  RE: iSCSI: Support Alias in the protocol

..snip..

Marjorie Krueger

---

From: Robert Snively <[email-masked]>
Date: Fri, 10 Aug 2001 00:06:54 -0700

John,

I feel that the alias does not belong in the iSCSI architecture.
Aliasing is already routinely provided at two other levels in
the protocol stack and need not be redundantly inserted in iSCSI.

a)  In the SCSI command set

There is already available a logical unit level aliasing process
using the SET/REPORT DEVICE IDENTIFIER service actions defined
in the SCSI command set standard SPC-2.  

b)  In the operating system stack

Most implementations use aliases created at the system level, not
the protocol level, that are far more useful and can be tuned
to the particular environment.  A particularly naive example of
this is the mapping of identified devices to the A:, B:, or 
C: disk drives in the similarly naive MS-DOS operating system.
More sophisticated systems and management structures use similar
aliasing at the system level.

Bob

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 9:52 AM
To: [email-masked]
Subject: iSCSI: Support Alias in the protocol

.
.
.
John L. Hufferd

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 10 Aug 2001 05:10:27 -0700

Robert,
You make good points, however, I would say that they show that an alias in
the protocol is useful.  The items you list are not an "eui" iSCSI
Initiator or Target Node name.  The fact that and "eui" name can be a bunch
of Hex numbers, is the exact reason that a human way to talk about it, and
get MIB and SNMP reports is useful and important.  There is no other item
in the system or the SCSI level that has a method of identifying an iSCSI
Initiator or Target via a Human oriented name.

.
.
.
John L. Hufferd

Robert Snively <[email-masked]> on 08/10/2001 12:06:54 AM

John,

Bob

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 9:52 AM
To: [email-masked]
Subject: iSCSI: Support Alias in the protocol

.
.
.
John L. Hufferd

---

From: "John Hufferd" <[email-masked]>
Date: Sat, 11 Aug 2001 16:32:59 -0700

Robert (the following resend has the sentence structured somewhat
improved),

You make good points, however, I would say that they show that an alias in
the protocol is useful.  The items you list are not an "eui" iSCSI
Initiator or Target Node name.  The fact that and "eui" name can be a bunch
of Hex numbers, is the exact reason that a human might want another way to
talk about it, and
that includes Alias in MIB and SNMP reports. There is no other item
in the system or the SCSI level that has a method of identifying an iSCSI
Initiator or Target via a Human oriented name.

.
.
.
John L. Hufferd

John,

Bob

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 9:52 AM
To: [email-masked]
Subject: iSCSI: Support Alias in the protocol

.
.
.
John L. Hufferd

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 14 Aug 2001 15:20:31 +0300

Whoever brought to the list the notion that TargetAlias or InitiatorAlias
name LUs must have  been reading a document that is not accessible to the
rest of us.

As specified today they are referring to what they say they are referring -
Targets and Initiators.

In any case please don't misread me - I am not part of this debate.

Julo

"Mark S. Edwards" <[email-masked]>@ece.cmu.edu on 14-08-2001 08:46:35

Please respond to "Mark S. Edwards" <[email-masked]>

To:   [email-masked]
cc:

At 09:09 PM 8/13/2001 -0400, [email-masked] wrote:

>Let me also acknowledge as valid Marj's opinion that anything of
>this sort belongs in a management tool rather than the protocol.

But it only works if everyone uses the same management tool, or the tools
agree upon the location and storage format of the information --  Somebody
dig me up from my grave when Tivoli and OpenView merge.

As a way of easily identifying virtual LUN's or LU's within a Target Space
of potential hundreds or thousands the alias is very valuable.

Mark.

---

From: "Mark S. Edwards" <[email-masked]>
Date: Thu, 16 Aug 2001 07:50:08 +0100

>Importance: Normal
>To: "Mark S. Edwards" <[email-masked]>
>X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
>From: "John Hufferd" <[email-masked]>
>Date: Wed, 15 Aug 2001 12:15:13 -0700
>X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 
>18, 2001) at
>  08/15/2001 01:15:56 PM
>
>
>Mark,
>I understand what you are saying.  You will be setting up LUN "Sets"  which
>you want the initiators to think of as iSCSI Targets that just happen to
>have the exact same LUNs that you are virtualizing to that Initiator.  You
>are also saying that this approach finds Alias very useful.  OK, I can buy
>what you said, just as long as people do not think that Alias and LUNs
>somehow map together, with out such a virtualizing layer.
>
>I think this needs to be posted to the main list.  So if you would, since
>you sent this to just me, please post you statement and my reply to the IPS
>iSCSI Reflector.
>
>.
>.
>.
>John L. Hufferd
>"Mark S. Edwards" <[email-masked]> on 08/14/2001 10:44:33 PM
>
>To:   John Hufferd/San Jose/IBM@IBMUS
>cc:
>Perhaps a loose use of terminology, but we are implementing a virtual SCSI
>layer on the target.  In this case, people tend to view a single exported
>LU as a target in its own right and the primary way of understanding it's
>identity is with the alias.  Multiple LUN's behind a virtual target are a
>slightly different matter.
>
>I know the spec does not address issues such as virtualisation, and at this
>stage it is a complication it can well do without.  Perhaps I tossed the
>note off thinking in local terminology and should be more careful to filter
>to terminology to where the group thinks it's at.  However, we have found
>that the group does tend to discuss matters either from the perspective of
>the initiator or by assuming that the protocol is relatively symmetric.
>
>Since we are only producing a target, we seem to have encountered
>a lot of the complicated target issues ahead of many others
>realising how different the initiator and target environments really are.
>
>Cheers,
>
>Mark.
>
>
>At 02:47 AM 8/14/2001 -0700, John Hufferd wrote:
>
> >Mark,
> >Perhaps I misunderstood your note, however, even though you wisely support
> >Alias :-), they do not supply any help with LU/LUNs.  They only permit the
> >customer to have names for his iSCSI Targets (think Raid Controllers, not
> >LUs), however, that is still very useful.
> >
> >.
> >.
> >.
> >John L. Hufferd
> >"Mark S. Edwards" <[email-masked]>@ece.cmu.edu on 08/13/2001 10:46:35
> >PM
> >

---

From: "Martin, Nick" <[email-masked]>
Date: Tue, 21 Aug 2001 13:34:54 -0500

Bob,

I agree that the iSCSI Name is analogous to the VIN number on a car.
The VIN number and the iSCSI Name are supposed to be constant for the life
of the device.
In my mind the iSCSI Alias is like the license plate tag.  If someone is
looking for your car, in the mall parking lot you don't tell them the
manufacturer assigned VIN number, you tell them the tag.  (You may also
mention the make, model, and color.)  The VIN number is used for
confirmation when required.  These are administrator assigned regionally and
duplicate numbers are not much of a problem.

Initiator Target relationships are defined by the InitiatorName and
TargetName.  The protocol does not need aliases, but I believe the
administrators do.  We need to allow administrators to assign their own tags
to devices, and I believe these should be carried within the protocol so
that no external databases are required.  When reporting a problem to an
administrator, the device alias should be reported along with the device
name.  The chances for error and confusion will be greatly reduced.  The
alias or "tag" value will be easier for humans to deal with on a daily basis
than a name field or VIN number would be.

I support Alias within the iSCSI protocol.

Thanks,
Nick
-----Original Message-----
From: Robert Snively [mailto:[email-masked]]
Sent: Monday, August 20, 2001 4:25 PM
To: 'Mark S. Edwards'; [email-masked]
Subject: RE: iSCSI: Support Alias in the protocol

Folks,

I remain concerned about this called consensus.  Clearly there
will be thousands of Targets and Initiators running around
a network.  Creating a set of human useable aliases
that will distinguish all these seems to me somewhat farfetched.
We don't even do very well on kings.  George, George II, etc.

To create aliases in the context of a single management environment
makes some sense, but again, that should be outside the 
scope of iSCSI.

That we call our car Skeezix (human useable, for management
purposes within the tightly constrained context of our own
family) is non-architected information.  Whenever anyone cares 
which car it is (including during servicing and upgrades) they 
use the VIN, a registered and architected non-human-readable value.

If Marjorie and I are the only voices in the woods, we have
clearly had the consensus called against us, but this is high
on my list of things that really aren't much help to anyone
and shouldn't be in the document.

Bob

> But it only works if everyone uses the same management tool, 
> or the tools agree upon the location and storage format of the 
> information 
> --  Somebody dig me up from my grave when Tivoli and 
> OpenView merge.
> 
> As a way of easily identifying virtual LUN's or LU's within a 
> Target Space of potential hundreds or thousands the alias 
> is very valuable.

---

From: Robert Snively <[email-masked]>
Date: Wed, 22 Aug 2001 09:00:16 -0700

Yes, though I lost that vote.

Aliases for this type of device identification are
only relevant in the well-defined management environment
that formulates the aliases.  Posting them in the device is
an invitation to confuse their meaning among two management
environments having access to the same set of devices.

If one administrator likes the characters in popular songs
for his names and another likes planets, wait till you find
two Venuses in the system.

The thing that computers do best is keep track of unique
numbers and associate them with convenient human oriented
symbols.  Let the architecture define the unique numbers
and the management environment relate them to human
oriented symbols.

Bob

> From: Stephen Bailey [mailto:[email-masked]]
> Sent: Tuesday, August 21, 2001 7:38 PM
> To: [email-masked]
> Subject: Re: iSCSI: Support Alias in the protocol
> 
> 
> Bob,
> 
> > family) is non-architected information.
> 
> What's your position on the SCSI LU alias?  Do you think that was a
> bad idea too?
>