Subject: RE: iSNS scalability

From: Joshua Tseng <[email-masked]>
Date: Mon, 25 Mar 2002 10:48:46 -0800

Hi Ernest,

Thanks for your comments.  I understand your observations
and conclusions.  This has been a past topic of discussion
among the coauthors the iSNS implementers we've been working
with.

Note that the scope of this iSNS document is meant to
address the interaction between iSNS clients and the iSNS
server.  Interaction among multiple iSNS servers is
something to be addressed by future standards work, or by
individual implementations using proprietary or standards-
based mechanisms.  Perhaps I need to make that more clear
about that in the document abstract.  But I understand your
comments and would be open to addressing them in a separate
draft.

Comparison with DNS, while interesting and useful, needs to
take into consideration significant differences between DNS
and iSNS functionality.  Note the following:

1)  DNS does not support dynamic addition, deletion, or
updates of records by its clients.  Although zone transfers
and the distribution of DNS record information is standardized,
the process of changing and updating of the DNS records
themselves is done administratively, outside of the DNS
protocol mechanisms.  That really simplifies the job for DNS.
For iSNS, dynamic updates of records is an integral part of the
iSNS protocol.  The heirarchical model works well for DNS
because database updates only need to flow in one direction--
down the heirarchy.  With iSNS, updates and notifications will
need to flow in both directions, because there will be updates
done by iSNS clients at the lowest levels of the heirarchy.

2)  The concept of authority--Who is authoritative?  In DNS,
it's very simple.  Since we're only talking about names, the
authority is imbedded in the name itself.  However, for
discovery and management of storage devices, the authority is
not necessarily related to the name, and the name of the device
may have no relationship to its authority.  And I would be
reluctant to delegate authority for my storage devices to "root"
iSNS servers somewhere out there in the Internet.

3)  Security:  DNS has limited control over what information
is propagated down the heirarchy.  iSNS requires much stricter,
granular control.

Because of the above and especially because of 2), we felt that
existing standards-based tools such as LDAP and SNMP would be
sufficient for now.  Yes, as you point out it requires more
manual intervention, but the feeling is that this is a GOOD thing
since most administrators don't want discovery of their storage
arrays to take place on the Public Internet without their
knowledge, which is what happens with DNS all the time.

That being said, I would be open to working with anyone interested
in a new draft specifying interactions among iSNS servers.  If
anyone is interested, please send me an e-mail.

Josh
 
> 
> A major motive for the use of iSNS is to provide scalability 
> in a storage
> network. While many of the proposed features of iSNS do 
> provide this, it
> falls short in a few areas.
> 
> An organization with storage at several locations should have 
> the option for
> local management by each site, with an easy method to share 
> storage between
> sites. This is also required for sharing resources between 
> organizations,
> such as between business partners or between a Storage 
> Service Provider and
> customers. 
> 
> iSNS (draft 8) addresses this somewhat in Section 3.7, 
> "Transfer of iSNS
> Database Records between iSNS Servers". However, the 
> mechanism suggested for
> doing this may not be straight forward to automate and may 
> require manual
> intervention between sites to keep multiple iSNS servers 
> synchronized. In
> addition, since the mechanisms are suggested and not 
> standardized, there
> will probably not be a high degree of interoperabilty between 
> different
> implementations of iSNS.
> 
> The best example of a well-proven, scalable architecture to 
> address this is
> the Internet Domain Name Services (DNS). DNS scales from 
> single-site to
> multi-site to the global Internet. The key DNS concept 
> lacking in iSNS is
> that of local authority (i.e. ownership). With DNS, a site 
> has authority for
> its own domains. Requests for information about its domain 
> are supplied by
> its own servers (primary or secondary). When a server's 
> domain name records
> are modified, its database does not need to be replicated or 
> synchronized
> with external DNS servers. 
> 
> So, for example, in an organizaton global.com, there might be 
> subdomains
> partitioned and managed by different regions of the company, such as
> us.global.com and europe.global.com. A region can further 
> partition its
> domain if desired,  into say london.europe.global.com,
> rome.europe.global.com, etc. 
> 
> The concept of local authority, as used in DNS, could be 
> applied to iSNS
> objects such as Storage Nodes and Discovery Domains. That is, 
> only one iSNS
> server would maintain authoritative records for a particular object. A
> hierarchical iSNS with local authority would add significantly to the
> scalability of IP storage.
> 
> 
> 
>

---

From: Joshua Tseng <[email-masked]>
Date: Mon, 25 Mar 2002 15:34:55 -0800

Sukanta,

I hope my previous message addressed your question.
In a nutshell, information in iSNS is dynamic and
not persistent.  While DNS is more or less a static
database, iSNS information can be dynamically updated
by client devices.  The approach you suggested would
require the storage administrator to call the DNS
admin to add or change the RR whenever a storage
device is added, removed, or re-zoned.  My experience
in working with IT departments is that network and
storage admins don't talk very often, if at all, so
I don't think this is a very promising approach.

Josh

> -----Original Message-----
> From: Sukanta ganguly [mailto:[email-masked]]
> Sent: Monday, March 25, 2002 11:03 AM
> To: Ernest Dainow; 'Joshua Tseng'
> Cc: [email-masked]
> Subject: Re: iSNS scalability
> 
> 
> Hi All,
>   Since so much of DNS like features are required in
> the iSNS, wouldn't it be better the to add this as a
> new RR in the DNS server itself. The near-persistent
> data can stay in the DNS server, i.e in BIND database.
>   The iSNS client processing can be defined in the
> iSNS spec and the server can be dissolved.
>   What do you guys think ?
> 
> SG
> 
> --- Ernest Dainow <[email-masked]> wrote:
> > 
> > A major motive for the use of iSNS is to provide
> > scalability in a storage
> > network. While many of the proposed features of iSNS
> > do provide this, it
> > An organization with storage at several locations
> > should have the option for
> > local management by each site, with an easy method
> > to share storage between
> > sites. This is also required for sharing resources
> > between organizations,
> > such as between business partners or between a
> > Storage Service Provider and
> > customers. 
> > 
> > iSNS (draft 8) addresses this somewhat in Section
> > 3.7, "Transfer of iSNS
> > doing this may not be straight forward to automate
> > and may require manual
> > intervention between sites to keep multiple iSNS
> > servers synchronized. In
> > will probably not be a high degree of
> > interoperabilty between different
> > implementations of iSNS.
> > 
> > The best example of a well-proven, scalable
> > architecture to address this is
> > the Internet Domain Name Services (DNS). DNS scales
> > from single-site to
> > multi-site to the global Internet. The key DNS
> > concept lacking in iSNS is
> > that of local authority (i.e. ownership). With DNS,
> > a site has authority for
> > its own domains. Requests for information about its
> > domain are supplied by
> > its own servers (primary or secondary). When a
> > server's domain name records
> > are modified, its database does not need to be
> > replicated or synchronized
> > So, for example, in an organizaton global.com, there
> > might be subdomains
> > us.global.com and europe.global.com. A region can
> > further partition its
> > The concept of local authority, as used in DNS,
> > could be applied to iSNS
> > objects such as Storage Nodes and Discovery Domains.
> > That is, only one iSNS
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards®
> http://movies.yahoo.com/
>

---

From: Ernest Dainow <[email-masked]>
Date: Tue, 26 Mar 2002 11:24:39 -0500

Thanks for filling in the background on this. I guess it makes sense to
defer iSNS server to server communication to later.

Just a few points to clarify for future discussions. The examples I used for
partitioning DNS domains assumed a strictly internal (private) network in a
large organization and does not expose DNS servers or information about
internal machines to the Internet. External resources like public web
servers are handled by separate external DNS servers (usually outside the
firewall).

The concept of authority relates to division of responsibility, which is an
important issue in large organizations. That is, if a site has ownership of
storage resources, they should have ownership of that portion of the iSNS
database that relates to those resources. The current model for iSNS is
monolithic and may make this difficult. This is what DNS does so well
through the ability to delegate subdomains, which can then be managed by
separate servers. Authority is delegated down the DNS hierarchy, not up the
hierarchy to root servers.

I agree that DNS is quite different and may not be a good model for iSNS in
its detailed operation. The concept of "local authority" and how to apply it
to iSNS or between iSNS servers is the question. 

Ernie Dainow

-----Original Message-----
From: Joshua Tseng [mailto:[email-masked]]
Sent: Monday, March 25, 2002 1:49 PM
To: 'Ernest Dainow'
Cc: [email-masked]
Subject: RE: iSNS scalability

Hi Ernest,

Josh