Re: iSCSI: Canonical Targets

[Mark Bakke <mbakke@cisco.com>]

Steph-

Good discussion.  My comments are below.

Stephen Bailey wrote:
> My proposal of allowing:
>   1) target discovery login
>   2) operational login to a default (Julian's right---the term
>      canonical is inappropriate) target
>   3) operational login to a specified target

I'm OK with adding the default target if we feel we need it; again,
I just don't want to over-simplify the initiators to the point where
they don't support more than one.

BTW, I'm not all that attached to "canonical"; if anyone has a better
name for either the discovery target or the default operational
target, please send it to the list.

> seems to cover all bases.  If your bridge does not want to support a
> default target (I bet it will.... how else will you be able to slap it
> under the skins with a Symmetrix and call it an iSCSI storage array?),
> you can reject the login, with a `no default' reason code (TBS).

At that point, the initiator can either give up, or log into the
discovery/canonical target, do SendTargets, and then log in.  As long
as we make the latter a MUST, I'm OK with the default target.  If the
latter is a SHOULD, then I'm not.

> I don't mind adding Jim Hafner's multi-layer discovery proposal if you
> guys really think it will help.  Personally, I'm skeptical.  Whatever
> the case, it seems like it can be done in such a way as to still
> permit a single-layer login when given nothing but socket
> coordinates.
> 
> Let me beat on this one final time.  I think EVERYBODY on this list is
> aware that the biggest selling point of iSCSI across the entire range
> of applications is that it leverages existing IP management skills.
> As such, using socket coordinates to specify targets is what IP
> managers understand.  That doesn't mean we can't introduce additional
> concepts, but the users should be able to get going without them.

Absolutely.  However, there are two points of view from which one can
count a concept as "additional":

1. The FC SAN point of view:  People who have already deployed Fibre
   Channel, and wish to extend their storage network to a greater
   number of hosts.  To these people, iSCSI/IP is just another network
   interface.  These people have the storage management skills, and
   many have the IP networking skills as well.  Most of the storage
   vendors themselves probably belong to this category.

2. The intranetworking point of view:  People who don't know storage,
   but are accustomed to managing web servers, file servers, and
   the like.  To these people, an iSCSI device is just another server,
   and should be managed as such.  These people have the IP networking
   skills, and are not likely to be familiar with managing storage.
   Most potential iSCSI customers probably belong to this category.

Taking the FC SAN point of view might be expedient for many vendors,
but in the end, group #2 is probably much bigger than group #1, and
my guess is that the storage folks know more about networking than
the networking folks know about storage anyway.

So I think that to leverage existing IP management skills, taking
a server point of view will be easier to handle than a storage device
point of view.  The distinctions are perhaps subtle, but putting things
like multiple targets into the storage array probably counts as an
additional concept to the FC SAN folks, but not to the networking
folks.

> 
> Steph

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054