Re: iSCSI: Canonical Targets

[julian_satran@il.ibm.com]

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