RE: iSCSI: Wrapping up SendTargets

["Douglas Otis" <dotis@sanlight.net>]

Charles,

You seem to leave out existing stable management servers that already exist
and do not need modification such as LDAP, etc.  If you need to have
signaling perhaps just servers would need to support something as complex as
a Directory User Agent.  Any SAN agent detecting or creating a critical
change would send an ICMP Code (41?) "SAN_Notice" to those SAN servers
logged as 'running' where these running servers (targets) acknowledge ICMP
Code (42?) "SAN_Rely".  All IP stacks support ICMP.  This signaling could be
invoked when a server detects an error and investigates running status from
the management server or at predetermined intervals.  This would be a
smaller change than writing a new server or modifying SLP to do signaling.
It would seem to apply to a broad range of SAN related systems.

Doug

> Hi Jim:
>
> Thanks for bringing this back on point.
>
> > The choices are, it seems, that *every* box would need to
> > support at least
> > one of:
> > a) SendTargets
> > b) modified SLP
> > c) iSNS
> >
>
> As I recall, the issue was whether or not to require support for
> SendTargets. I thought the consensus on that issue was 'yes', irrespective
> of the other two issues.  So, in my opinion, the matter of SendTargets was
> indeed 'wrapped up' as far as this thread is concerned.
>
> That said, of course, the others remain open.
>
> Charles
> > -----Original Message-----
> > From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> > Sent: Tuesday, June 12, 2001 4:56 PM
> > To: ips@ece.cmu.edu
> > 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
> >
>