RE: iSCSI: ICMP for Notification?

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

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