Re: iSCSI: Canonical Targets

[Stephen Bailey <steph@cs.uchicago.edu>]

Jim, Mark, et al.,

> I guess I'm having trouble understanding the issues here.   We seem to be
> moving toward three types of iSCSI targets:

I disagree.  We still only have one type of target, but our choice of
terms is makes it look otherwise.

> 1) one for discovery only, suitable for login only by authenticated
> initiators, i.e., a one-sided authentication, but ONLY for the purposes of
> SendTargets.

A discovery login does not involve a target at all.  A target is a
SCSI entity, and, as Mark pointed out, there's no SCSI interaction in
a discovery login.

If, as Mark, you don't like the empty string to denote no target, we
could use:

  TargetName=none

for discovery login.  I don't really care how the notion is
represented, only that we agree upon the notion itself.

> 2) one "nameless" target ("iSCSI"), again suitable for login only by
> authenticated initiators, i.e., a one-sided authentication, but used for
> real SCSI stuff

This target is not nameless.  It has a full-fledged iSCSI name, which
is returned in the LoginResponse of the login interchange.  `iSCSI' is
A name (not THE name) for the DEFAULT (as administered at the target)
target.  The specific target named by iSCSI may vary based upon
initiator, or phase of the moon (a target-based administrative
choice).  Authentication is performed with the initiator against the
specific, target-chosen default target.  An initiator should only ask
for the default target when it wants the associated default behavior.

The advantage of the default target is you get an extremely
low-overhead way of administering the storage accessed by an initiator
which is configured purely at the target, without requiring additional
infrastructure.  As Doug pointed out, this behavior is useful for
initiators with limited resources, or just limited desire (or ability)
to select a particular target (e.g. booting servers in an
Infiniband-style zillion*3*1U rack farm).

I'm having a hard time swallowing the `it makes the specification more
complicated' argument.  After all, I tried that on multiconnection
sessions, where it really DOES make the specification more complicated
:^) Seriously, it's not complex to specify, we simply have to actually
do it.

Also, that somebody besides me and Doug (I'm sure there are many of
you out there for whom our mail doesn't even reach your inbox....)
hasn't specifically requested this feature isn't really a good
argument.  The set of iSCSI applications represented presently is
somewhat limited.  We all know iSCSI has huge potential, but if we
make it purely market-targeted based upon the present, (aim for the
immediate money), we're going miss future low-hanging fruit.

Put another way, we're not expecting anybody to throw away their
existing, local storage connection as soon as the ink dries on the
iSCSI RFC.  However, removing one entire port from systems is a
compelling argument for iSCSI in the long run.  To that end, the
default target is a simple, familiar mechanism which will make that
process easier.  Why?  Because although the rubber (dollars) really
meets the road in this case when you have many servers, and a big
network (and probably a complicated management infrastructure), a
natural consequence will be that people will want to take those same
components (off the shelf) and build small configurations, e.g. with a
SINGLE server, and a SINGLE target and little or no management
infrastructure.  Every large configuration begins as a small one.

Steph