RE: iSCSI: ICMP for Notification?

[Black_David@emc.com]

Doug,

There are a whole bunch of problems here:

- The IPS protocols are layer 5, ICMP is at
	layer 3.
- ICMP is an unreliable delivery protocol without
	retransmits.
- ICMP's interaction with IPSec can be peculiar,
	to put it mildly.
- No new standard codes have been added to ICMP for
	the past five years.

For all these reasons, I don't think use of ICMP for SAN
management notifications is a good idea, and hence the
WG should look elsewhere for a notification mechanism.
Further discussion of this topic is not an appropriate
use of list bandwidth.  Please do not reply to the list.

Thanks,
--David

> -----Original Message-----
> From:	Douglas Otis [SMTP:dotis@sanlight.net]
> Sent:	Tuesday, June 19, 2001 1:55 PM
> To:	Black_David@emc.com; ips@ece.cmu.edu
> Subject:	RE: iSCSI: ICMP for Notification?
> 
> David,
> 
> Although an ICMP code not understood is silently discarded, the only
> concern
> that I can see would be the rigor in ensuring this to be a rare signal as
> such a convention would not be a modification of ICMP.  If there is a
> concern that SAN agents can not ensure proper use, perhaps a UDP based
> signaling protocol be devised instead as a standby alternative.
> 
> A general signaling convention would allow notice for any SAN based
> protocol
> to query their management service.  Rather than overloading SLP which only
> partially satisfies a management requirement, making a general signaling
> convention would not require additional (perhaps unneeded) servers added
> to
> support IPS related transports.  A simple packet message with a small text
> string indicating the SAN domain that changed should be all that is
> required.  Use the ICMP template on a UDP port pending the dubious
> approval
> of this crazy idea.  This signal would be sent by the agent detecting the
> change to all servers advertising service affected by the domain.
> Although
> I still view the ICMP approach the cleanest solution as this protocol is
> already required by all IP stacks, adding a UDP filter at a specific port
> would be a small addition and comparable in overhead to any scheme devised
> for SLP.
> 
> If the IPS group worked together, the best solution should have merit.  If
> well presented, even the IESG should be receptive if it means fewer
> protocols are modified otherwise.  As I have provided cover if required,
> do
> you see an problem discussing a stand alone signaling scheme?
> 
> 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
> > > >
> > > >
> >