Subject: Re: iSCSI: Canonical Targets

From: "Jim Hafner" <[email-masked]>
Date: Wed, 16 May 2001 12:56:45 -0700

Mark and Steph,

I guess I'm having trouble understanding the issues here.   We seem to be
moving toward three types of iSCSI targets:
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.
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
3) all other "named" targets, that may or may not require two-sided
authentication, but are used for real SCSI stuff.

Frankly, I think I see no real need for the second one (a SCSI-functional
thing with no true name).   The third one can perform the function of the
second one if the initiator doesn't bother to authenticate the target's
name (provided it has a straightforward way to get the name).  The first
one was what we were moving to as the functional use of the "iSCSI" target.
The only value I see is that the initiator doesn't have to find the name
first.  But the target will need to "correct" that name in response anyway
(at which point it has a name which it can use for all other sessions) --
it could/should be a one time deal, probably, to go through the discovery
(SendTargets) step.  I don't think we really want the host to think that it
has any number of real targets all named "iSCSI"!

Jim Hafner

Mark Bakke <[email-masked]>@ece.cmu.edu on 05-16-2001 12:14:35 PM

Sent by:  [email-masked]

To:   Stephen Bailey <[email-masked]>
cc:   [email-masked]
Subject:  Re: iSCSI: Canonical Targets

That kind of makes sense.  If we limit SendTargets to the discovery
session, and disallow SCSI commands to the discovery session, then
we really don't have a target at all from SCSI's point of view; but
we do have a "special" target from iSCSI's point of view since we
are doing the full login to it.

So if we used

  TargetName=

we would get the discovery target; if we used

  TargetName=iSCSI    # Note: this is case-insensitive

we would get whatever default target the iSCSI device wanted
our initiator to see.  Even if we do end up supporting both, I
guess I'd rather see a target name, rather than leaving it
blank.  How about

   TargetName=discovery

BTW, nobody else has spoken up for having this default target
that would avoid having to use SendTargets if there were not
multiple targets available to an initiator.

Who plans to make use of this?  I don't mind putting it in
(we had sort of implied the functionality before), but if
it is not in anyone's plans, I'd rather go for a simpler spec.

Stephen Bailey wrote:
>
> > Any other ideas?
>
> My suggestion was to not supply any target name for a discovery login
> (which is how a discovery login would be distinguished) and call
> `iSCSI' the `default' (operational) target.
>
> Steph

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Mark Bakke <[email-masked]>
Date: Wed, 16 May 2001 16:01:36 -0500

Actually, that's a good point about the multiple target names.  If
a host is allowed to use a target without learning its name, it has
two problems:

1. If it has multiple targets with the name "iscsi", it will not
   know whether they are multiple targets, or multiple addresses
   for the same target.

2. If the target's IP address changes, it will not be able to tell
   whether a newly-discovered target is the same target at a new
   address, or a new target.

Given these, I think there is too much danger in allowing a host not
to learn the actual name of a target.  Also, Jim is correct about
discovery being a one-time thing; after the first time a host has
connected, it will probably squirrel the iSCSI name away in a config
file or registry somewhere anyway, so it knows where to look for its
disks, and which /dev entries to map them to the next time it boots.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 17 May 2001 00:09:07 -0700

Mark,

That 'squirreling' depends on local storage which may not be available.  It
seems there is going to be something that knows what the initial target
should be outside the host otherwise there is no security.  If security is
dependable, then automatic assignment should also be dependable.  The
listing function should allow human intervention to alter the default
assignments.  Once beyond the initial OS launch, confirming the target then
makes sense.

Doug

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 17 May 2001 12:17:47 -0400

Jim, Mark, et al.,

> 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.

> initiators, i.e., a one-sided authentication, but ONLY for the purposes of

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.

> authenticated initiators, i.e., a one-sided authentication, but used for

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