Re: iSCSI: Canonical Targets

["John Hufferd" <hufferd@us.ibm.com>]

Julian,
I do not agree with you on the issue of Send Targets, it is not a discovery
function as much as it is a reporting function (perhaps we should have
called it Report Targets).  It performs a function that is similar to
Report LUNs.  If you are saying that Send Targets should not be there, then
that is an argument against Report LUNs also.  I do not think that is a
meaningful discussion.  We have had to use the LUN 0 to get the LUN
information which was a bit more clumsy than the way we are going about
Send Targets, which will have an explicit way of telling the authorized
requester, what the target knows, which is directly applicable to the
conduct of the Initiator (It needs to know that it can reach this Target,
and what portals it can use and which portals can be used for Multiple
Connections per Session, etc).  This is so important and so primitive of a
function, I do not get the issue about having to have support for some
other variety of Discovery functions, just to get an approprate Report on
the Targets supported, and the Portal on which they can be reached.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: hufferd@us.ibm.com


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 05/24/2001 11:20:07 PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: Canonical Targets





I am not concerned about the amount of work the "discovery target" will
generate for a builder.
If the function is needed it is needed and will be done.

The context however is not right. The discovery will surely imply more than
the name - and will include various device characteristics not all of them
apparent today.

A generic discovery will have provisions to include them.  iSCSI - most
probably not.

If all we want is a lightweight discovery mechanism - we should choose a
lightweight discovery protocol not add a "lightweight feature" to iSCSI.

Julo

Stephen Bailey <steph@cs.uchicago.edu> on 23-05-2001 05:08:16

Please respond to Stephen Bailey <steph@cs.uchicago.edu>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: Canonical Targets




Julian,

> Why shouldn't we take the road of deferring the name discovery to
> the specialized (iSCSI) part of a more general discovery protocol?

The reason is, for a minimal, useful iSCSI configuration, we must not
require any additional pieces of infrastructure beyond (Mark's term)
table stakes for IP (e.g. DNS), an iSCSI initiator and an iSCSI
target.  Assuming we want to allow multitarget iSCSI endpoints in
minimal configurations (I'm sure we do), there MUST be a way for the
initiator to learn what targets are behind that endpoint from within
the initiator's machine environment.  The solution to this problem
can't be `walk over to the target and read a bunch of numbers and type
them in to the initiator'.

> You don't expect the management applications to start using iSCSI for
> discovery do you?

Why not?

When you say `management application' you seem to imply an application
which would manage an arbitrary, possibly extremely large
configuration (e.g. OpenView).  Actual management applications range
from simple to complex, and many configurations (particularly in the
pilot phase that hopefully iSCSI will be entering) start very simple.

I don't think anybody would argue that FCP PL-DA provided very
complicated networks, yet every initiator implementation usually
provided a program or something which simply spat out the WWNs (and
probably the AL_PAs) for each target.  Such a simple `management
application' is going to be a lot like (perhaps IS) an existing SCSI
control utility that can give you a list of buses, targets, LUNs, some
inquiry data, and whatnot.

Clearly, iSNS has nothing to say about this scenario.

Are you proposing that SLP be used to supplant the existing simple
directory mechanism in the iSCSI draft (and that it be mandatory to
implement)?  That might work.  I'm not sure it makes sense, but if you
think so, let's discuss it.

In this case, multicast support (a typical objection to SLP) wouldn't
be necessary, because you'd already know where the target is by
configuration.  SLP+iSCSI mechanisms would be offering the same
service as the existing SendTargets but in a more ultimately scalable
way.  However, this proposal doesn't appear to solve any security
problems.  What security provisions does SLP have?  Presumably the
target would still authenticate the initiator in the SLP connection to
ensure the initiator had rights to get the target list.  That part is
the same as the current proposal, so you're not saving the target any
work.

Steph