RE: iSCSI: Wrapping up SendTargets

[Charles Monia <cmonia@NishanSystems.com>]

My .02:

We either have a common tool for discovery and SAN management or we have
(perhaps) a common discovery tool plus an assortment of ad-hoc 'value-added'
solutions to fill the gaps.  In my opinion, such an outcome would make it
impossible to integrate heterogeneous storage products into the enterprise
environment.

With that concern in mind, the iSNS authors decided that a single SAN
management and discovery protocol was essential. As with iSCSI, we believed
the right place to start was with a model that was widely deployed and
supported by existing storage management products.

As to alternate approaches, I believe it will always be possible to point to
this or that tool or protocol that does or can be extended to do some piece
of iSNS functionality.  What's been missing, however, is a comprehensive,
well-articulated model into which all of these fit and a willingness to
deploy the implementations so we can all do a test drive. 

If anyone has an alternative model and implementation, I would encourage
them to put both forward for consideration.

Charles

> -----Original Message-----
> From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> [mailto:marjorie_krueger@hp.com]
> Sent: Monday, June 11, 2001 4:41 PM
> To: Ips Reflector (E-mail)
> Subject: RE: iSCSI: Wrapping up SendTargets
> 
> 
> Josh,
> 
> > Before you or anyone calls consensus, I would like to see
> > how SLP can solve the following issues:
> > 
> > 1)  Management of Discovery Domains.  You don't want
> > incompatible file systems discovering each other, or
> > very bad things will happen.  Say 'goodbye' to the Unix
> > file system who's host is discovered by SLP....
> 
> This function is the domain of an application value-add, and 
> does not need
> to be specified in the SLP protocol.  It is perfectly feasible for an
> application that provides storage discovery services using 
> SLP to filter the
> information given to a particular initiator based on that initiator's
> identity (just as a target would when responding to SendTargets).  The
> 'management of discovery domains' is a 'storage network 
> management' related
> value-add feature of an application, not something SLP must specify.
> 
> > 2)  Transfer of X.509 digital certificates.  SLP cannot
> > easily transfer binary entities.  This affects the iSCSI
> > target device's ability to enforce its access control list.
> 
> Again, this may be an application value-add, it's not a 
> requirement for
> storage discovery.  Security infrastructure is painful to 
> administer.  Seems
> to me as if a user would chose a generic security solution 
> using something
> like SCEP protocol, which would work for a variety of 
> applications, not just
> storage.  
> 
> > 3)  Monitoring of available devices.  SLP relies upon
> > service agents re-registering periodically, in order to keep
> > the freshness of its database entries.  But this leads to a
> > dilemma: if SA's re-register too often, the DA will be
> > overwhelmed.  And if they register not often enough, then
> > you will have stale device entries.  The fact is, SLP was
> > not designed to be a real-time discovery protocol. But in
> > storage networks, real-time information is crucial, as even
> > slightly out-of-date information can lead to unnecessary
> > logins and other events that will seriously degrade the
> > performance of the storage network.
> 
> I'm not sure I see the need for storage devices to 
> "re-register" themselves
> frequently since storage is not typically a highly dynamic 
> configuration
> environment.  You've made some statements about the real-time needs of
> storage, but without specific examples I don't see how "real-time
> monitoring" is a crucial requirement of a centralized storage resource
> management service.
> 
> As for your concerns about SA's re-registering too often and 
> overwhelming
> the DA, this "push" model is viewed as having less problems 
> than the "poll"
> model where a centralized application requests status updates 
> from multiple
> devices (but there are tradeoffs with both models).  This is a classic
> networked device monitoring problem, I don't think the group 
> that developed
> SLP would have ignored it in their protocol service design.
>  
> > 4)  State Change Notifications.  This is important to
> > support failover and redundancy capabilities, and to
> > ensure that initiators can persistently maintain their
> > sessions with targets in the event of network topology
> > changes.
> 
> This area of service really applies much more to a Fibre 
> Channel domain than
> an IP/iSCSI domain, due to differences in protocols.  
> Initiators shouldn't
> need notification of target devices "going away", since the 
> TCP connection
> provides that information.  As for devices being added, there 
> are a number
> of ways to model this, that's another thread of discussion.  On first
> thought, a model where an administrator triggers the update 
> of initiators
> when a target is added, rather than some automatic or polled 
> environment
> seems more desirable to me.  How many OS's can deal with 
> storage suddenly
> "appearing" after initial boot?  It seems that SLP could be used by an
> application to provide this service if it's deemed necessary, 
> it remains to
> be specified "how".
> 
> > Furthermore, it would be helpful if you clarify whether your
> > statements are representing the iSCSI NDT or only of your
> > personal views.  I do not believe your statements regarding
> > the SLP approach for iSCSI are consistent with what was
> > agreed to in the NDT.  I believe the consensus was that both
> > iSNS and SLP are to be considered for discovery.
> > 
> > >   Future - Pursue SLP as the "standard discovery", allowing for
> > >            other solutions such as iSNS as appropriate.
> > 
> > As an NDT member, I cannot support a decision on making any
> > protocol the "standard" without fully addressing the above
> > technical issues. The devil is in the details, and only after
> > exploring such issues will we be able to avoid future pitfalls
> > that may threaten the timely adoption of iSCSI.
> 
> I can't speak for Mark, but I think his intent may have been 
> to express that
> it remains to be fully specified "how" SLP can provide the 
> same information
> as "SendTargets" (we discussed this in the N&D team mtg).  
> Perhaps he didn't
> mean to imply that it would be the only way to discover storage.
> 
> I would speculate that the group/IPS community as a whole has 
> been focused
> on minimal protocol connectivity, and mostly not had 
> time/bandwidth to weigh
> in on the greater "storage directory server" requirements.  
> Nishan has done
> some good work on the iSNS application, the rest of us need 
> to catch up on
> considering which of it's features are "requirements of a 
> generic storage
> directory server" and which are value-add. 
> 
> Marjorie Krueger
> Hewlett-Packard
>