Subject: Re: iSCSI: Canonical Targets

From: [email-masked]
Date: Sat, 12 May 2001 19:05:00 +0300

Why would any discovery service be wiser/stupider than the mechanism we are
having in N&D?
If the issue of ports is widespread then others have it too and discovery
may include all the nice things we
have in iSCSI.  I don't see any reason iSNS or an LDAP repository can't
contain them.

My only claim is that this adds weight to iSCSI.

As for interoperability - I claim that adding features makes
interoperability an issue. Removing them does not.
The whole "canonical" (why canonical - there is nothing canonical about it)
target idea is good but in another realm - I don't think it belongs to
iSCSI - it belongs to discovery be it specific or general.

I can leave with the mechanism as it is - but I really feel that we are on
the wrong track.

Regards,
Julo

James Smart <[email-masked]> on 12-05-2001 15:42:09

Please respond to [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL, Mark Bakke <[email-masked]>
cc:   [email-masked]
Subject:  Re: iSCSI: Canonical Targets

I'm in agreement with Mark, that canonical target support is mandatory. The
key is interoperability. The initiator must be mandated to probe the
canonical target and not assume a single target device. If all initiators
do
not support this type of probing, then interoperability goes out the
window.
Mark's effort, mandates the support on the target device - which indirectly
puts the mandate on the initiator to check, and makes sure there are not
confusing answers from devices that otherwise would not respond to the
canonical target.

Is this replacing discovery - perhaps in some ways. The real issue is
allowing i/o traffic to be rerouted to non-IANA TCP port numbers, which is
a
critical need of the proxy/routers/etc, which have little left in the
socket
4-tuple to classify on if rerouting is not allowed.. I would expect the
"discovery" (SLP, uPnP,etc) mechanisms would contain the "targets" that the
proxy/router/etc, but the expectation is that they would all point at the
well-known IANA TCP port number. The canonical processing simply allows the
target device to shift session-specific traffic to target-assigned port
numbers that can aid it's classification schemes.

-- James

[email-masked] wrote:

> Mark,
>
> I am not sure that we want to have your "canonical" target as a mandatory
> construct.
> It is good for proxies, routers, portals etc.? Don't the have better
> mechanisms for discovery.
> But why should you force it on some small box that has the name wired and
> printed on it's label.
> To reach the canonical you have to go through all the "login etc.".
>
> I think that all goes back to asking - why should we use iSCSI for
> discovery?
>
> SLP, UPnP, Salutation, Jini all attempt discovery using a a general form
> (good for iSCSI, Lpr printers etc.)
> Can't we take the same path?
>
> Julo
>
> Mark Bakke <[email-masked]> on 12-05-2001 00:04:24
>
> Please respond to Mark Bakke <[email-masked]>
>
> To:   IPS <[email-masked]>
> cc:
> Subject:  iSCSI: Canonical Targets
>
> It was pointed out during the interim meeting that the
> canonical target is defined somewhat ambiguously, and may
> be a bit too flexible for interoperability purposes.  This
> message is a stake in the ground for defining this a little
> more tightly.
>
> So here are the new canonical target rules.  Please let me
> know if there are major problems with any of them.  I tried
> to define them a-la-carte, to make it easier to pick out any
> that might cause trouble.
>
> 1. Each iSCSI implementation MUST include a canonical target.
>
> 2. A canonical target MUST be accessible at the default, IANA-
>    assigned TCP port on each IP address on which the iSCSI
>    implementation is listening for iSCSI connections.
>
> 3. A canonical target MUST NOT be used for SCSI commands.
>
>    A canonical target is an iSCSI construct only, and does not
>    have a corresponding SCSI device.  This means it may not
>    be used to access Logical Units.
>
>    A session created to a canonical target is a discovery session
>    only, and once in full feature phase, is used only for text
>    commands and asynchronous messages.  (Do any other commands make
>    sense)?
>
> 4. A device containing a single target MUST provide both the
>    canonical target and the real target.  (This is implied by the
>    above requirements).
>
>    An initiator connecting to such a device using only its IP address
>    would first connect to the canonical target, and use SendTargets
>    to obtain the iSCSI name of the real target.  It would then create
>    a separate session to the real target.  Essentially, this means
>    there's nothing special about a single-target device.
>
> 5. An iSCSI device MUST provide a unique iSCSI name for each of its
>    targets.  Using the canonical target as a nameless iSCSI target
>    is not supported.
>
> 6. We can further specify the order in which the SendTargets response
>    fields are returned, to simplify things further, e.g. each target
>    in the SendTargets response MUST return these fields in this order:
>
>    - A TargetName= field
>    - A TargetAlias= field (value left blank if there's no alias)
>    - One or more TargetAddress= fields
>    - Any vendor-specific fields (ignored by standard initiators)
>
> The above rules will make the behavior of various target implementations
> identical, regardless of the number of interfaces or targets they
> support.  This will reduce the number of end-cases that initiator
> implementations will have to handle.
>
> If we agree on these, we can edit them into the iSCSI and NDT documents.
>
> Additional questions to send input on:
>
> 1. Should a non-canonical target respond to a SendTargets command?
>
> 2. If so, should it respond only with addresses for its own target,
>    or should it respond with other targets, as a canonical target
>    might do?
>
> 3. If not, the initiator must connect to a canonical target to find
>    the other addresses of a target to which it is already connected;
>    is the information it has sufficient to do so?  (I think the answer
>    is yes, given canonical requirement #2 above).
>
> --
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054

---

From: "Jim Hafner" <[email-masked]>
Date: Mon, 14 May 2001 08:14:31 -0700

Julo,

You object to the term "canonical"?  My dictionary says canonical is
"conforming to a general rule", but perhaps that isn't the best term.
Would "well-known" would be better?

Jim Hafner

Julian Satran/Haifa/IBM@[email-masked] on 05-12-2001 09:05:00 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Regards,
Julo

-- James

---

From: "Jim Hafner" <[email-masked]>
Date: Mon, 14 May 2001 08:11:36 -0700

Steph,

One argument for SendTargets on non-canonical targets would be the
following (and might help address your iterator concerns).

A canonical target *could* respond to SendTargets with list of actual
targets but only provide a partial list of addressess and ports (an
abbreviated list).  Then each actual target could respond to SendTargets
with just itself in its list and its complete list of all addresses and
ports it responds to.   This gives a heirarchical local discovery
mechanism.

N&DT hasn't fully scoped these issues, which is why this discussion was
started.

I don't think there is a requirement in what Mark wrote that the response
to SendTargets to any target (canonical or actual) has to report complete
knowledge of everything known to that box.

I have a question for you (and the list) about a long Text response (as
might be needed for SendTargets).  Can the Text response come in multiple
PDUs?  In particular, can one "key=value" pair span multiple PDUs?  If so
(for either question), what exactly is the spec'ed method?  And if so, does
this help address your resources concerns?  (The target can send the
response is chunks.)

Jim Hafner

Stephen Bailey <[email-masked]>@ece.cmu.edu on 05-13-2001 07:54:28
PM

To:   [email-masked]
cc:

Mark,

This is mostly fine with me.  However, I KNOW implementors are going
to gripe about having to know the target name before performing an
operational login.  In general, the spec seems a bit capricious about
when implementors just have to suck it up and do the hard thing,
versus when we try to make it easy for them.  Realistically, it's not
a big deal to learn the name (just an extra login), but most end
points are going to have a single target, and from a configuration
standpoint endpoint (and, hence the target) is going to be specified
by transport coordinates (address, port).  This extra login for
discovery is simply an irritant.

>    - Any vendor-specific fields (ignored by standard initiators)

I can only guess that you are implying that target descriptions
following this rule may be tiled arbitrarily into Text PDUs returned
from the target?  If so, we should specify that.

> 1. Should a non-canonical target respond to a SendTargets command?

I'd say no.  Given the nature of the interaction, why bother?  Now, I
know the iSCSI philosophy seems to be `if it's not complete gibberish,
why NOT bother?' but that results in complicated implementation.
Specifically, each end (target and initiator) should be able to audit
the other for correctness when possible.  Hard rules like `thou shalt
not issue a SendTargets in an operational session' make the auditing a
zillion times easier.

To this end, I would go a step further and allow only a single
outstanding SendTargets exchange in a target discovery session.

Steph

---

From: Stephen Bailey <[email-masked]>
Date: Tue, 15 May 2001 09:18:21 -0400

Rob,

> Surely you are aware that most medium-to-large-scale
> storage arrays present multiple targets today, usually
> in the form of multiple FC interfaces, each acting
> as a target (i.e. FC WWPN)?

Yes.  However, this behavior is not really doing what you claim.  WWPN
is a way to uniquely identify an INTERFACE.  From the standpoint of
SAM's notion of target, you are correct that an FCP interface presents
a unique `target'.

In reality (one step above SAM), these boxes present a single target
visible through multiple interfaces.  There is no independent target
addressing coordinate in FCP as there is in iSCSI or SST.  What really
represents the target in FCP, from an addressible entity standpoint,
is the FC Node Name.  The targets presented on different ports by the
same box have different N_Port_Names, but they all have the same
Node_Name.  That means if you change the contents of a disk LUN
through one port, you will see the changes (eventually) of a
corresponding LUN on another port.

Furthermore, there seems a strong move afoot to modify SAM to embrace
this notion of multiple views of a target.  Seeing a single target
through multiple interfaces behavior has been the norm for enterprise
storage since ||SCSI.

A wedge driver (your host or HBA-level software) uses Node_Name, or
more likely something from the VPD of inquiry (serial number, device
Id, which probably is the FC Node_Name) to keep /dev entries straight,
not N_Port_Name.  The VPD information is available across transports,
so you can still find the target on a box with heterogeneous links.

Steph

---

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Tue, 15 May 2001 18:25:09 +0100

What about "Discovery Target"? - its simple, short and straight to the
point!

Matthew Burbridge
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: [email-masked]

> -----Original Message-----
> From: Mark Bakke [mailto:[email-masked]]
> Sent: 15 May 2001 17:46
> To: Stephen Bailey; [email-masked]
> How about using the term "well-known target" instead of
> canonical target?  It would fit in well with the networking
> world.  Any other ideas?
> 
> --
> Mark
> 
> > 
> > BTW, I'm not all that attached to "canonical"; if anyone 
> has a better
> > name for either the discovery target or the default operational
> > target, please send it to the list.
> > 
> 
> -- 
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054
>

---

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 15 May 2001 14:07:35 -0700

This seems like a reasonable proposal to me, with the following comments.

>    there's nothing special about a single-target device. 

There needs to be an explicit SHOULD for the initiator.  While I see
value in having the initiator always follow a specific set of steps
to establish a full feature session, it seems a bit harsh to require
the a two step process when the initiator may very well know who it
should connect to.

>    - Any vendor-specific fields (ignored by standard initiators)

The above fields should be considered a 'record' and should not be 
split across multiple PDUs if we decide upon an iterator.  Personally,
I think the idea of only allowing SendTargets on this session eliminates
the need for an iterator and is a good direction to take.  A complete
'record' should always be return for each target in the list.  This
'record' must include the name, address and alias, but the alias
value can be left blank as described above.

The concept of this 'record' should also be used in Login-response
PDUs in the case of Target Moves or Redirects.  Again, the complete
record should be returned.  Note that this allows the ability to
redirect the login to a completely different target.  Not something
that is currently possible, but would be valuable.  In the current
Login-response only a TargetAddress field needs to be returned, but 
instead it should specify an entire target record.

>    or should it respond with other targets, as a canonical target

It should be allowed to respond with the complete target 'records' for
other targets that this initiator has access to if it so desires.  There
is no reason to restrict this.

Paul

+--------------------------+----------------------------+
+ Paul Congdon             + Email: [email-masked] +
+ Hewlett Packard Company  + Mail Stop:  5662           +
+ HP ProCurve Networking   + Phone:  (916) 785-5753     +
+ 8000 Foothills Blvd      + Fax:    (916) 785-5949     +
+ Roseville, CA   95747    + Mobile: (916) 765-4056     +
+--------------------------+----------------------------+

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 16 May 2001 18:57:21 -0700

> 
> How about this instead:
> 
> 2. A discovery target MUST be accessible on the default tcp port
>    on each IP address on which an iSCSI implementation is listening
>    for iSCSI connections.  This default tcp port will often be the
>    IANA-assigned TCP port for iSCSI.  If the implementation is
>    listening on multiple TCP ports, the discovery target MAY be
>    accessible on each TCP port.

I feel this "MUST" is a "MAY".  The comments in this thread seem to focus on
enabling I-T discovery in an "easy", insecure way.  It seems to me there are
many possibilities for "discovery models" ranging from

initiators probe targets "discovery" ports
to
initiators access "domain-specific directories" (this has also been referred
to as "storage name servers", but I think that model is a narrow subset of a
network resource management soln)

In the environments where initiators get their storage resource information
from a "directory server", it would be desirable to disable this "discovery
target" to guard against unintended/unauthorized access to targets.
Initiators may be authenticating to "directory servers" who then pass
specific information about targets to attach to, as well as an
authentication token.  The initiator could then log into the specific
targets with the authentication token and the target is freed from the task
of assigning/managing initiator lists.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked]

---

From: "Jim Hafner" <[email-masked]>
Date: Thu, 17 May 2001 10:27:29 -0700

Steph,

I'll need more time to absorb more of what you're saying, but I want to
make one wording clarification which you alluded to in your first
paragraph.  It's the misunderstood and overused term "target".  There are
three interpretations of that term running around in this space:
1) "SCSI target port": this is the more common interpretation of "target",
at least in the SCSI world  (the multiport model for SAM-2 was titled
"Defining targets/initiators as ports" so you see where the legacy comes
from).
2) "SCSI target device": this one is only now more formally being added to
the SAM-2 model; essentially it is a container of SCSI target ports and
SCSI logical units (and a few other things)
3) "iSCSI target": this is the thing that gets the iSCSI name (at least as
we've been looking at it) and is a purely iSCSI construct.
[A similar distinction is required on the term "initiator".]

I personally always attempt to be completely clear when I use the terms.
So, if you read my note carefully, I use the term "iSCSI target"
exclusively to mean thing 3.

Can we all agree to use these terms carefully, to avoid the confusion
misinterpretation of intent can cause?  Or should we come up with different
terms?

Here's short outline of how we've modeled things (and how I interpret the
use of these terms):

-- Each iSCSI target gets an iSCSI name.
-- Each iSCSI target MAY contain at most one SCSI target device.
-- An iSCSI target that does not contain a SCSI target device is there only
for iSCSI purposes (such as SendTargets).
-- Each iSCSI target must require it's name be supplied during login.
This was so that iSCSI initiators (those things that initiate iSCSI login
but may or may not have a SCSI initiator device within them) will always do
the same login process, that is, include the iSCSI name.  [In other words,
the name is mandatory for every login.]

-- For an iSCSI target that only performs the SendTargets (has no SCSI
target device), we allowed that to have the generic name "iSCSI".
-- For an iSCSI target that has a SCSI target device, we wanted such things
to have unique names for two reasons:
   (a) so that there would be something the initiator can authenticate and
configure against
   (b) so that the SCSI target device could have a name as well (it would
inherit the name from it's parent entity, the iSCSI target).

We could easily remove the name from the SCSI-deviceless iSCSI target, but
then the iSCSI initiator has to make the distinction of when to include the
tag and when not to.  It's a nit.  We could make the name="none".  It's a
placeholder, more than anything else.  On the other hand, there may be a
need latter for other iSCSI targets that don't contain SCSI targets.  These
might be administrative entities in the box.  So other "well-known names"
could be defined as well.

As I said above, I need some time to digest the rest of your note, but in
the meantime, I am not confortable with an iSCSI target that contains a
SCSI target device not having a unique name (if for no other reason to meet
(b) above).  If it has a unique name and because it is available to the
iSCSI initiator, there is no reason that initiator can't use it.

Jim Hafner

Stephen Bailey <[email-masked]>@ece.cmu.edu on 05-17-2001 09:17:47
AM

To:
cc:

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

---

From: [email-masked]
Date: Sat, 19 May 2001 10:26:29 +0300

Jim,

The canonical attribute is associated with strictly conforming to a rule
(as in canonical form for expressions or canon in music, or canonical
religious text).  I would use the term generic-name or class-name for it.
But again the objection on the name was only minor.  I strongly believe
this is a service-delivery discovery item and we are repeating an old
mistake - creating a specialized solution for a general problem.  Any
discovery service would be better than placing this in the iSCSI realm.

Julo

"Jim Hafner" <[email-masked]> on 14-05-2001 18:14:31

Please respond to "Jim Hafner" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: iSCSI: Canonical Targets

Julo,

Jim Hafner

To:   [email-masked]
cc:

Regards,
Julo

-- James

---

From: [email-masked]
Date: Sat, 19 May 2001 10:08:16 +0300

Mark,

I don't see any iSCSI interoperability issue if you don't have the
canonical target.
This is a service discovery mechanism that we are mistakenly taking on a
specialized track.
I assume that many other services "hide" behind portals (print is one good
example).
We are not going to leverage this commonality if we are attempting a
specialized interface.
Perhaps the boxes should be mandated to have something to enable discovery.
My only claim is that this is not an "iSCSI item" it is a service discovery
issue and it should be
handled in that realm and enable interoperability with other service
discovery mechanisms.

Julo

Mark Bakke <[email-masked]> on 14-05-2001 16:13:59

To:   [email-masked]
cc:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
Subject:  Re: iSCSI: Canonical Targets

James-

Your argument for interoperability is correct.  Please see my comments
below on the other discovery mechanisms.

do
window.
> confusing answers from devices that otherwise would not respond to the

Correct.  The danger in not supporting the canonical target on all devices
is that initiators may then choose not to look at it.  Even in an
environment
without proxies and gateways, any medium-sized disk array should be able
to support more than one logical target.

> allowing i/o traffic to be rerouted to non-IANA TCP port numbers, which
is a
socket
> 4-tuple to classify on if rerouting is not allowed.. I would expect the

Actually, by defining several logical targets, a single IP address + IANA
TCP port can be shared by all.  This is a direction I suspect many
implementors
will take.

> well-known IANA TCP port number. The canonical processing simply allows
the

The SLP template includes the TCP port number on which the target is
listening.  If a target is discovered using SLP, the initiator could
skip using SendTargets on its address.

Although we are not considering using it, SSDP (used by UPnP) returns
a URL, which could include a TCP port number.

--
Mark

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

---

From: "Jim Hafner" <[email-masked]>
Date: Mon, 21 May 2001 08:04:38 -0700

Julo,

I was only teasing about the name.  I don't care either, it's a nit.

As for "discovery service". Here's a twist on the issue.

In the case of most services, at a single ipaddress:tcpport, you'll find a
single service entity (web server, ftp server, etc) and only AFTER you get
through the first layer does finer granularity of discovery occur (e.g.,
through the query string of the url). But even in these cases, there's
actually little of discovery going on.  You pretty much have to know what
you're going for first, or you drill manually (think of ftp server accessed
through browser -- you get directory listing which you browse).  What I
think we're doing here is providing a "directory list" function for the
single service entity that lives at the defined tcpport.   This "listing"
service can then be used to drill deeper.   I don't see much that's
different in what we're spec'ing and what needs to be spec'd for this
purpose.

We can rely on some mechanisms such as SLP and SNS for somethings.  SLP
helps to find the place to start for listing service.  SNS has "all the
answers".   We're attempting to fill in the middle ground.

Jim Hafner

Julian Satran/Haifa/IBM@[email-masked] on 05-19-2001 12:26:29 AM

To:   [email-masked]
cc:

Jim,

Julo

Julo,

Jim Hafner

To:   [email-masked]
cc:

Regards,
Julo

-- James

---

From: [email-masked]
Date: Fri, 25 May 2001 09:20:07 +0300

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 <[email-masked]> on 23-05-2001 05:08:16

Please respond to Stephen Bailey <[email-masked]>

To:   [email-masked]
cc:

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

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 25 May 2001 09:59:27 -0700

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: [email-masked]

Julian Satran/Haifa/IBM@[email-masked] on 05/24/2001 11:20:07 PM

To:   [email-masked]
cc:

Julo

To:   [email-masked]
cc:

Julian,

Why not?

Steph