RE: iSCSI: Wrapping up SendTargets

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

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