RE: iSCSI: ICMP for Notification?

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

David,

I did not intend this to be related directly to iSCSI, but instead to a
class of protocols.  I indicated this signal could be 'SAN' related allowing
it to be used for any SAN class of transport.  It would not be modifying
ICMP but rather adding to the signal types.  My goal was to avoid doing
anything iSCSI specific and, in addition, I was attempting to further limit
use to just those devices providing services.  If you view this a critical
signal related to networking changes, then ICMP does seem like the proper
protocol for this level of notification.  It would provide only a notice of
change.  It would allow any number of SAN related protocols the ability to
then query services like SLP, LADP etc.  Rather than changing every possible
management related service, this one method could provide a means of keeping
management models and the many related protocols unaffected and unchanged.

Doug

Doug
>
> With my WG co-chair hat on, I want to discourage
> Doug's proposed use of ICMP as a bad idea - I
> can't imagine this ever making it to the IESG,
> let alone being approved by them.  Even the
> experimental SLP notification would be a far
> better approach.  Please do not spend any further
> list bandwidth on modifying ICMP specifically for
> iSCSI.
>
> Thanks,
> --David
>
> > -----Original Message-----
> > From:	Douglas Otis [SMTP:dotis@sanlight.net]
> > Sent:	Monday, June 18, 2001 2:46 PM
> > To:	ljlamers@mindspring.com; ips@ece.cmu.edu
> > Subject:	RE: iSCSI: Wrapping up SendTargets
> >
> > 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
> >
> > > 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
> > >
> > >
>