RE: iSCSI: Wrapping up SendTargets

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

Charles,

Without drawing any conclusions as to the general merits of iSNS, it is new,
based on a simple flat file, and likely not the best choice when
implementing a difficult to maintain boot ROM code.  There are alternative
solutions to the indicated problems that have driven a perceived need for a
new service in my view.  From that perspective, it would be much better to
use something already mature and stable.  I agree that a convergence on a
common solution would be good, but my hopes would be to use something
already in place based on mature and stable code.

Doug


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