iSCSI: ICMP for Notification?

[Black_David@emc.com]

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