Re: iSCSI: Canonical Targets

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

Mark,

> I also don't think that there will be a lot of single-target devices out
> there, at least not right away.

Perhaps not right away, but definitely eventually.  Using the LUN
model is the way to ensure that a target (true target, not bridge)
implementation can be relatively transport independent.  That's proven
to be a major survival characteristic for targets.

> Most devices will likely be accessed through iSCSI-FC or iSCSI-SCSI
> gateways in the near future, before iSCSI interfaces are added to
> the devices themselves.  Our gateway, for example, provides more
> than one target; my guess is that others will do the same.

Agreed.  The only SST target in the world is a gateway, and it
provides multiple target support as well.  Our solution to this
problem was to constrain the target addressing range so that the
initiator can do the traditional big crawl.  SST was aimed at a
different design point, so I'm not saying we should adopt the same
solution with iSCSI, I'm just agreeing that allowing multiple targets
behind an endpoint in the protocol design is a good idea.

> In this case, an initiator has to deal with multiple targets
> anyway.

Absolutely.  However, in the limit, the bridges usually wither away.
Sometimes they wither away a lot faster than you might expect.  There
were some early attempts at FC/||SCSI bridging that worked from the
same set of assumptions.  You probably don't need to know how
successful those were.  That would never happen to today's modern
bridge vendor, since they've learned how to apply all their
accumulated cleverness to building native targets in short order :^)

The bridged scenario shouldn't be at the expense of the unbridged one.

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

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

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.

Steph