Subject: RE: iSCSI: Wrapping up SendTargets

From: [email-masked]
Date: Wed, 13 Jun 2001 14:02:06 -0400

Modified SLP should be the mandatory to implement.

SendTargets is allowed under a grandfather agreement since it is out there and should be carried in an Annex with a clear notation that it is obsolete and is there because of pre-standard implementations.

There is no need to mention iSNS - that is pretty nearly a vendor specific approach to solving their perception of a problem, open source available or not.

At 06/12/2001, Jim Hafner wrote:

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: "Douglas Otis" <[email-masked]>
Date: Mon, 18 Jun 2001 11:46:14 -0700

LJ,

Rather than mandating a non-existent standard (one modified to implement
signaling), there is already a method of signaling using ICMP for other
types of networking protocols.  If this signaling is of a critical nature,
then adopting two ICMP codes for SAN Notice and Reply together with a means
of logging running servers could provide an alternative. This would only
entail registry of these codes.  Finding a means to log running servers
could be done with protocols like LDAP, SLP or equivalents.  With the
assumption that there will be agents running (servers perhaps) that notice
events that needs propagated, a list of servers would enable that function.
It would then be incumbent upon the transport to further that signal to the
clients to minimize this change to only those devices providing a SAN
related service.  The signal would be an indication to recheck
configurations.

Doug

> SendTargets is allowed under a grandfather agreement since it is
> out there and should be carried in an Annex with a clear notation
> that it is obsolete and is there because of pre-standard implementations.
>
> There is no need to mention iSNS - that is pretty nearly a vendor
> specific approach to solving their perception of a problem, open
> source available or not.
>
>
>
>