RE: iSCSI Naming and Discovery

[Black_David@emc.com]

All of this is with my WG co-chair hat off:

At a high level, my concern about DNS and LDAP is based
on Leslie Lamport's infamous (in jest) definition of 
a distributed system -- one on which he can't get
work done because a computer he's never heard of is
down :-).  While the sort of infrastructure services
that run on "a computer he's never heard of" have been
getting more and more reliable, the moral I take away
from this is to be cautious about introducing
dependencies on services.  Every introduced dependency
provides new ways for things to fail, and this needs
to be balanced against the new ways in which things
work because of the dependency.  IMHO, NATs and IPv4/v6
transparency don't tip the balance far enough to favor
DNS or LDAP (but I always reserve the right to change
my opinion :-) ).

For current block storage, a host's access to its storage
either does not depend on any external service (parallel
SCSI, FC-AL) or a depends on the Fibre Channel fabric
nameserver (FC-SW).  The fabric nameserver is usually
embedded in the Fibre Channel switches, so that if the
nameserver's not working, the switch probably isn't working
either (e.g., in practice, if the nameserver isn't responding
to the HBAs, the switch gets replaced).

In contrast, both DNS and LDAP are external services, probably
located on general purpose servers, on which block storage
access currently does not depend.  LDAP in particular can be
rather complex, as some of its leading implementations sit
on top of full-fledged relational databases.  FWIW, the
original design of the FC fabric nameserver was LDAP-based,
but this was discovered to be infeasible -- an LDAP server
doesn't embed into a switch very well, or at least didn't
at the time.  The characterization of LDAP as "very simple"
is significantly off the mark, IMHO.

The discussions of DNS and LDAP on this list have had the
flavor of these being ubiquitous completely reliable and
available services on which dependencies are no big deal.
When everything is working right, that may be the case, but
everything doesn't always work right; disasters happen
taking down entire facilities and requiring them to be
brought up from scratch.  An example of what could go
wrong is that two DNS servers could be configured in a
way that each depends on the other for its storage.  If
each server is rebooted individually to test the
configuration, things work, but if both go down, neither
will come back up.  This is one more problem for overworked
system and network administrators - having to determine
which servers must use IP names for storage vs. DNS names,
with nasty consequences of getting it wrong.  This isn't a
fatal problem, but every time management becomes more
complicated, it's one more barrier to adoption.  This is
why I don't put much weight on the argument that IP URLs
can be used where DNS or LDAP won't work - there are too
many opportunities to screw this up if DNS is allowed in
general.

Boot is a specific concern, because if DNS or LDAP is
involved in locating the boot volume, then the HBA card
BIOS has to be able to access DNS or LDAP.  There's nothing
inherently difficult or infeasible about this, it's just
more code in yet another place ... making it harder to
deploy/adopt this.

Beyond this, I need to toss in a few important scattered comments.

Most systems don't boot via BOOTP today; demanding that everything
boot via BOOTP in order to avoid problems created by an entirely too
clever naming structure sounds like a bad tradeoff.  This will lead
to iSCSI repeating the Fibre Channel experience of boot not working
for a long period of time after deployment of the technology.
Customer reactions to that Fibre Channel experience have been
negative to the point of just barely printable in some instances.

The LDAP vs. nameserver discussion misses the point.  The Fibre
Channel experience makes it clear that iSCSI is going to need
some sort of central repository of configuration information to
get the sort of discovery functionality that is expected.  That
repository is at least a nameserver, and possibly more - the
approach of defining LDAP schemas is the result of deciding
to use LDAP as the communication protocol for accessing
iSCSI nameservers.

The [3] discussion of NATs at the end of my previous message was
rather verbose.  The bottom line is that if IP addresses are stored
in and distributed by a central iSCSI config repository, then NATs
cause a problem, and a brute force solution that is likely to work
in many cases is not to put NATs between the repository and its users.
Alternate solutions based on application level gateways and storing
addresses with respect to users of the repository rather than the
repository server are workable, but more complex.

On [4], I see the following advantages of IP addresses over DNS URLs.
- IP addresses are much better for booting, and in some cases have
	to be used (see above).  DNS hostnames are then an additional
	mechanism that adds implementation work and complicates
	management (see above).
- Scanning a range of possible locations of Targets has some attractive
	properties, because it removes the obligation of a new target
	to proactively make itself known to some iSCSI configuration
	repository (such mechanisms do work, Fibre Channel is an example,
	but the FC solution doesn't directly apply to iSCSI).  It seems
	to me that wildcarding an IP address via a mask or range works
	better than wildcarding some portion of a URL (e.g., if the
	wildcard is xyz*.abc.com, there's a fair amount of work involved
	in finding xyzf, xyz01, and xyz17a in the abc.com domain,
	by comparison to finding things that match 192.48.27.128-191 or
	equivalently 192.48.27.128/27).

One more note on NATs:

> FTP must use the passive mode to get past the NAT. 

That's not correct.  There are NATs deployed that detect FTP
traffic and rewrite the IP addresses in the FTP payloads
to make everything work right.  The official name for
this feature/kludge is an Application Level Gateway (ALG),
and the FTP features that require it are generally regarded
as an example not to be emulated.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------