RE: iSCSI: Support Alias in the protocol

["Douglas Otis" <dotis@sanlight.net>]

John,

As Bob eloquently explained, these labels are just as likely to confuse as
to assist those individuals that may be assigned different targets when
connecting to their storage.  It is likely these labels will be problematic
rather than helpful and a source of frustration for IT individuals to
explain to now confused users.  The goal should be to ensure that some
management functionality is obtainable even from such satellite environments
to avoid these types of problems rather than placing hopes on an alias label
that does not indicate the nature of the connection as being helpful.

Doug

> Martin,
> I think your view is "Right-ON".  Over the years I have had the
> "marvelous"
> opportunity to work in the management of an IS/IT organization.  It is the
> presents of little things like this Alias that make or break so much of
> what we attempted.  I was not only responsible for the management of a
> Large Data Center (at IBM Santa Teresa Lab) but also its
> satellites  It was
> in the satellite systems, where the full featured Management Software was
> most likely not to exist.
>
> I expect that this view is the rule in smaller installations, that is, you
> will not generally find the large Network and Storage Management Software
> in those environments.  They will have a number of simple low end, or no,
> general Management Software.
>
> Though I would like to have Tivoli or HP Open View (for example)
> everywhere, I know this will not happen.  We need to do
> everything possible
> to support the small installation as long as it does not cause a
> big impact
> on the iSCSI protocol.
>
> I think that the Alias capability, though not a hard requirement
> for iSCSI,
> is a very worthwhile feature, that will help humans.
>
> .
> .
> .
> 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: hufferd@us.ibm.com
>
>
> "Martin, Nick" <Nick.Martin@compaq.com>@ece.cmu.edu on 08/21/2001 11:34:54
> AM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "'Robert Snively'" <rsnively@Brocade.COM>, "'ips@ece.cmu.edu'"
>       <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI: Support Alias in the protocol
>
>
>
> 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:rsnively@Brocade.COM]
> Sent: Monday, August 20, 2001 4:25 PM
> To: 'Mark S. Edwards'; ips@ece.cmu.edu
> 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
>
> > >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.
>
>
>
>