Subject: RE: iSCSI: target discovery issue

From: Joshua Tseng <[email-masked]>
Date: Thu, 19 Apr 2001 10:35:16 -0700

Marjorie,
> 
> A more generic statement of "method D" is that there exist 
> applications for
> managing and administering networked resources (Novell eDirectory and
> Microsoft ActiveDirectory products are examples).  One of the 
> most important
> tasks a network administrator has is making sure that users 
> have access to
> files, resources and services they need on the network.  
> iSCSI adds block
> storage to the list of network resources, but resource assignment and
> management is a problem that has existed for quite some time 
> and solutions
> exist today.  Network resource management evolved from a 
> device-by-device
> management paradigm long before iSCSI was conceived.  I don't want to
> detract from the value of iSNS, but it's not correct to 
> suggest it's the
> only solution to resource management.

eDirectory and ActiveDirectory are implementations of LDAP with 
significant amounts of proprietary extensions.  So you must be talking
about the basic LDAP protocol itself, since as much as Microsoft
would desire, I can't imagine the storage industry imbedding
ActiveDirectory clients into each and every iSCSI storage device.
Nor could I imagine IETF standardizing on a Microsoft implementation.
Same thing with Novell.

If LDAP is what you are talking about, please see my previous notes
to Doug Otis regarding how LDAP is basically a generic directory service
that passively stores information deposited by clients, without any
regard to what that information is used for.  iSNS is also a protocol,
but since it is tailored to storage, it can interpret information
registered by clients, and take appropriate action.  That isn't to
say LDAP can't be used to accomplish some of the discovery and management
functions that iSNS has, but because iSNS has state-consciousness of
its client storage devices, it has more capabilities than a basic LDAP
server would have in managing storage devices.  David has already invited
anyone interested to write a draft on how LDAP can be used, and I would
be equally interested.  If you or someone else would oblige, then we
would have a "method E" of discovery iSCSI devices.

Finally, I would like to note that iSNS capabilities are modeled on
those provided by T11's FC-GS-3.  Presumably, these capabilities are
based upon real-life lessons learned by the Fibre Channel community in
managing and operating large enterprise-class storage networks.  I like
to think that we are incorporating the fruit of those lessons into iSNS.
We looked at LDAP--we really did--to see if it could provide comparable
FC-GS-3 services in the IP domain.  But there are shortcomings which
forced us to create the iSNS protocol.  These shortcomings are documented
in the iSNS document.

> 
> Typically users register/login to distributed resource management pts
> (domain servers) and these applications handle authentication,
> authorization, and assignment of resources.  John makes 
> important points in
> his email - you don't want all users informed of new storage 
> coming on line,
> those systems that are intended to have access should be 
> notified, or should
> explicitly "mount" the new storage.  It's not appropriate to 
> burden each
> storage device with this task, it is definitely a value add feature
> appropriate to a centralized resource management application. 

Yes, this is where iSNS with the discovery domain feature provides
significant value in a large storage network.

Regards,
Josh

> 
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: [email-masked] 
>

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 19 Apr 2001 19:07:20 -0700

Joshua,

Although being generic, it can also provide directory based privileges.  The
various requests structures can also provide tailored responses.  Not to
dwell on what has become a sensitive subject, there are alternatives to
signaling other than that proposed by iSNS.  It seems a signaling method
from IP based SCSI servers for informing clients of a need to check
configuration would be far more useful with respect to scaling this
architecture.

Clients would naturally already have persistent connections to these servers
greatly reducing the number of connections involved.  Signaling a change to
affected servers can be handled through any number of IPCs especially if
this number is within the realm of a few dozen servers and not thousands of
clients.  The SCSI server should be able to filter these signals adequately
based on common knowledge shared between server and client.  One other
principle area of concern comes from the need of creating this global name
space without a means of promulgating information across vendors.

The signaling already present for Fibre-Channel switches and controller may
need agents adopted for IP, but I would not be surprised if this already
exists and most of the tools for managing this equipment already share these
popular interfaces.  Signaling a change and distributing information should
be two separate functions.  Distributing information is easily handled by
generic servers.  A SAN should not be flapping at such a rate to mandate
specialized persistent connections to each and every client nor high levels
of overhead for servers to inform their clients if they find they were
affected the a resent update.  Each server must manage their own domain and
informing clients of a change seems like such a small matter.  This should
not justify adding a name server for this purpose.

Doug