Subject: RE: iSCSI: Wrapping up SendTargets

From: "John Hufferd" <[email-masked]>
Date: Tue, 12 Jun 2001 18:08:57 -0700

iSCSI Team,
I think that Jim has said it well.  I had a proposal about an Annex, for
the SendTargets, but whether we do that or not, I am getting the feeling
that most folks think, at least for this version of the protocol that we
keep SendTargets, and the subset that can be used as a Report Portal
Groups.  Even Mark, even though he thought he could Hack the SLP Source
code to do a similar thing, thought that it was best to keep SendTargets.

I would like to propose that we Close on Keeping the SendTargets command,
and the subset that is either Report Portal Groups or SendTargets <iSCSI
Target Name> (which returns only the information for that target only).

Now as to where we put the command.  I suggested an Annex, but can clearly
live with it in the Main document.  I seemed to get very little support for
the idea of the Annex, and since I think that the functions of Report
Portal Groups, must be part of the base,  I would like to suggest that we
either
1) Place the SendTargets in the Annex, and put a Report Portal Groups in
the main document, or
2) Keep the Send Targets in the Main Document and add the argument of
<iSCSI Target Name>

Please state your positions

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

Jim Hafner/Almaden/IBM@[email-masked] on 06/12/2001 04:56:10 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  RE: iSCSI: Wrapping up SendTargets

Folks,

I think this thread is wandering off the field.

The question is the issue of SendTargets.  Let's remind ourselves of the
original purpose of this proposed protocol: namely, it's designed for a
storage box that contains one or more iSCSI target devices to report about
ITSELF, about what's in it!  This includes both a list of the iSCSI targets
it has PLUS the session coordination (via tags) of the various
IPaddress/tcpport combos it supports.

In other words, it's job is to report about itself!  The use of (unicast)
SLP as an alternative to SendTargets was focused exactly on the same
question: I ask a single box to tell me about itself.   This function lies
between the two extremes of (a) static configuration of initiators and (b)
centralized management via iSNS style services.

Somehow, someway, we need to define a protocol for a box to "tell us about
itself" in the absense of the centralized management infrastructure.  That
seems critical to me.  Even if I want to do static configuration, the guy
doing the configuration needs a way to get at the guts of each new box
he/she rolls into the environment.

The choices are, it seems, that *every* box would need to support at least
one of:
a) SendTargets
b) modified SLP
c) iSNS

What's the consensus on the protocol we aim for to solve this middle ground
discovery problem?
Jim Hafner

---

From: Mark Bakke <[email-masked]>
Date: Wed, 20 Jun 2001 09:02:25 -0500

This thread turned out more interesting than I had expected,
but anyway, after reading through the messages sent while I
was gone, it looks like we at least have some consensus on
keeping SendTargets.

I would like to see John's option #2 as well.  Currently,
SendTargets is documented in the naming & discovery document;
where should we put it in the iSCSI spec?

We will also need to close on some of the previous threads
about aggregation tags, iteration, etc.

It looks like we should continue the thread on the future
(SLP, iSNS, etc.) discovery stuff, but I should have started
that one separately.

--
Mark

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