RE: Internet Storage Name Server iSNS Proposal

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

Josh,

> Doug,
>
> As you are probably aware, LDAP can be used as the back-end
> database access protocol.  There are several reasons why
> we think iSNSP would be more favorable to LDAP as the
> front-end protocol for storage naming services:
>
> 1)  LDAPv3 has a lot of functionality which is not needed for
> storage name service.  This could make embedding an LDAP server
> on a device such as a switch problematic.  We felt that a simple,
> dedicated protocol such as iSNSP would be far easier to embed
> on a switch in a similar manner to how name server implementations
> are embedded on Fibre Channel switches today.

A switch should not be embedding access databases.  As drive mapping already
exists, the real hurdle is to provide users access to their drives.  There
is not much fluff in allowing controlled access with respect to LDAP
provided as an external service.  The only effort at the switch would be to
request from LDAP permissions for the user attempting to gain access.  The
user should already have the same permission list (map) and an OTP.  In the
simple case, security may grant access to the physical medium.  More
specific schemes may restrict the target and perhaps even LU.  Placing text
within the SCSI transport weakens security so real-time name lookups must
not be done.  You will still need an external database able to join together
names and places.  That is LDAP.  Once you know the place, you no longer
need the name.

> 2)  Similar problem with the name server clients.  If LDAP
> was used as the front-end protocol, that would require
> every iSCSI device to have an LDAPv3 client implementation,
> in order to obtain name service.  I don't believe this would
> be a favorable situation, if you think about the extra
> CPU-resources required for each target and initiator to
> run the LDAP client.  Asynchronous notification must be
> implemented, which will consume resources one way or another.

In the simple case, a simple flat file such as NIS, /etc, or inf file
setting can be used where minimal security is required and the configuration
is stable.  In this case, anonymous or fixed access would be granted at the
server and no external LDAP query would be required.  In the enterprise
environment, the SAN Server would only need to implement a directory user
agent rather than a more complex iSNS and thus require far less resources.
LDAP has several defined user agents in place.  Only within an enterprise
environment would LDAP be required and is likely already used.  Adding new
servers (iSNS) as a distributive databases still requires an authentication
server (yet to be invented) and thus does not reduce resources at all.

> 3)  Using iSNSP would allow you to hide the specifics of the
> LDAP schema from every name server client.  The LDAP schema
> for the back-end database would strictly become implementation-
> specific issue.  On the other hand, using LDAP for the front-
> end protocol would require a standardized schema that all
> clients must understand and conform to.

I already see problems with the iSNS schema as it exists.  LDAP is more
extensible.  Rather than waiting around a few years for some new server to
become stable, a reliable system could be put into place using LDAP with
existing tools and agents.  Rather than wasting time inventing new servers,
an LDAP schema would provide a superior solution. The SCSI transport would
work with an agent that makes the needed translations assuming a structured
approach.  Part of that process should include revisions.

> 4)  Using the LDAP persistent search capability for asynchronous
> notification requires a TCP connection be kept open for every
> client registered to receive the notification.  Again, this
> could be problematic for situation 1) above, as the server may
> be imbedded on a switch or other resource-constrained device,
> and would potentially have to keep 100's of TCP connections open.
> The alternative to persistent search is the client update
> protocol, which requires every iSCSI device to continually
> poll the server for changes.  Also not very scalable.

Will find these problems can be handled through a lease or a server signal.
LDAP has mechanism in place for updating.  Should there be a change that
affects the client, a notice of change from the server should be able to
direct the client to re-establish permissions.  The server more than the
client should have frequent queries to the LDAP server.  Even with a name
server, once address start wiggling around, you will need to reconfirm
permissions.  As addresses and permissions are synonymous, I fail to see the
need for a name server.  You can obtain the same url like interface using
LDAP with a browser plug-in.  Once you find LDAP, you're done with
discovery.

Doug

> Josh
>
> > Josh,
> >
> > LDAP is an alternative to iSNS.  The FC SNS can publish to
> > LDAP and satisfy
> > access requirements.  Information provided by iSNS is not
> > complete with
> > provisions of a single IP as example, so it would be interesting to
> > understand how an iSNS schema is expanded.
> >
> > Include a form-feed at the end of each page to help reviewers.
> >
> > For information on secure DNS, investigate
> > http://www.nominum.org.  There
> > has been extensive work in this area.
> >
> > Doug
> >
> > > Folks,
> > >
> > > Please note that our I-D proposal for a name server for iSCSI is now
> > > available:
> > >
> > > http://search.ietf.org/internet-drafts/draft-tseng-ips-isns-00.txt
> > >
> > > Please submit comments to me or this list.
> > >
> > > Thanks!
> > >
> > > Josh Tseng
> > >
> >
>