RE: iSCSI: Stand alone SAN network configuration change notice.

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

David,

If you feel ICMP is off the table, then consider this suggestion as a
general signaling mechanism using UDP.  Although the affected programs may
be at the application level, the change notification would be changes in
assignments or function within the physical networks through a SAN bridge,
router or switch.  The suggestion that I made included notice and reply to
overcome your delivery concern.  If you look at RFC2521 (1999 experimental)
you will see ICMP used to signal security failures.  As the server and the
SAN network is likely inside the firewall, there should be few such issues
related to ICMP for this type of signaling concerning IPSec and may be
viewed as a feature.  I would not view this signal used at the client.  The
server should relay such concerns through the native transport.  It is at
the switch, router, bridge where this signal is likely to occur to perhaps
inform higher level protocols of this network related change as is often the
case.  It is at that level of impact that I think deserves this
consideration that may happen only once every five years.  I have no trouble
looking elsewhere such as UDP but I must say I do not agree with your
conclusions.  Considering such a signaling mechanism may impact the various
transports if such signaling is standardized, reflector bandwidth should not
be a major concern to resolve if changing existing network services are the
best solution or if a more general and simpler scheme may be of greater
utility.

Doug

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