RE: iSCSI Naming and Discovery

[Joshua Tseng <jtseng@NishanSystems.com>]

Doug,

If the point you are making is that applications are growing
more dependent on external, centralized services, then I would
agree on that.  iSCSI would therefore be bucking the trend
if it were not to leverage external services such as DNS, DHCP,
and LDAP.

Josh

-----Original Message-----
From: Douglas Otis [mailto:dotis@sanlight.net]
Sent: Wednesday, October 04, 2000 2:05 PM
To: Joshua Tseng/Nishan Systems; Black_David@emc.com; ips@ece.cmu.edu
Subject: RE: iSCSI Naming and Discovery


Joshua,
<snip>

> If any dependence on any external service is what you're
> trying to avoid, I think that's unrealistic.  If iSCSI
> is to be deployed through the Public Internet, then at
> the very least you will have firewall services, not to
> mention possibly a PKI infrastructure to provide
> authentication & encryption services.  DNS, with all
> its warts, is pretty reliable, and if it fails, then
> EVERYONE knows it failed.  Storage won't necessarily
> be the only thing in trouble.

DHCP is virtually ubiquitous in most enterprise environments.  DHCP can
deliver the required information to bring up any scheme you wish without
reliance on any other server (except for TFTP).  I would strongly recommend
LDAP, even via NIS, be used to provide the desired parameters which can also
be used by the OS for setting up user accounts, email programs, browser, and
the like.  LDAP supports many interfaces such as Java as well.  It has been
around and becoming even more complete in its level of support for various
security schemes of exchanging information.  I would hope this group could
influence an LDAP guru into recommending a reasonable solution for both
class objects and suggested implementations.  Making a Best Practice
document would help standardize this solution.

> <snip..snip>
> I see a few issues with this idea which I can't begin
> to understand.  Will DHCP support iSCSI, and if so will that
> cause IP addresses to change?  What if addresses are not
> assigned according to a neatly defined range?  How many retries
> to each IP address before the initiator decides no target
> exists at that address? Will this lead to a school of homeless
> IP packets spinning around the network until TTL expires?

There are only 255 lives for a packet, even if a circular path is found,
which I doubt as they route at the switch based on MAC addresses that do not
change.  Yes, if you have a short term lease setup in a DHCP server and for
some odd reason the DHCP server likes to change the IPs, then you will find
a problem at times.  It would be a poor configuration and more than just
connections to drives might be flapping if something required the IP beyond
establishing the connection.  Ethernet routes using MAC addresses.

DHCP allows you to load a boot sector via a trivial FTP if there is no local
drive and your BIOS settings enable the network.  It also allows vendor
specific parameters to be loaded as well as this boot code.  This boot code
only needs to impart enough knowledge to get to the next step whatever that
might be.  Perhaps it would be a networked base SCSI interface. :)

Doug

> Josh
>
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, October 04, 2000 9:29 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI Naming and Discovery
>
>
> 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
> ---------------------------------------------------
>