RE: iSCSI: More on naming and discovery

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

David,

> With my WG co-chair hat off:
>
> -- DNS
>
> I'm uncomfortable with passing hostnames inband
> in the basic iSCSI protocol with the exception of
> 3rd party commands.  As long as the iSCSI initiator
> and target can talk to each other via IP addresses,
> use of DNS or LDAP to get those addresses is reasonable
> provided that we have the ability to make sure booting
> works reliably, but I'm uncomfortable specifying the
> protocol in a way that requires resolution of DNS
> hostnames as part of connection setup.  The current
> CONNECT discussion seems to be consistent with this.

I would hope that even this connect scheme disappear and instead allow
gateways to handle much of the effort without trying to re-engineer network
routing.  This of course would depend more fully on the information obtained
from a LDAP server.

> IMHO, requiring BOOTP for a server
> that gets all its storage from iSCSI is not going to
> be accepted (lots of machines don't boot via BOOTP,
> and won't anytime in the near future), and requiring
> a DNS resolution to find the storage required to get
> the server up to the first point at which it can be
> worked on (e.g., single user mode in Unix) is an
> invitation to trouble.

BOOTP and DHCP should be viewed as virtually the same protocol.  DHCP is the
modern version and is present on your system.  You are right about DNS
possibly being a problem but at the same time, that is an option that IT
managers can make.  Perhaps their DNS services are in-house and reliable and
provide the secondary fail-over resources which improve on the reliability
of other resources. Even MS has space for indicating three DNS server
locations.  I would work on a scheme that did not rely on DNS, but not every
case is it bad.  Perhaps I over-stated my objections to dissuade invention
of a SCSI name server.  To scale a name server on a large scale requires a
massive amount of ram as these services can not be placed on a hard drive
for dynamic retrieval.

> 3rd party commands are a different matter.  The
> current naming structure of 3rd party commands that
> requires the Initiator to understand how the Target
> of the 3rd party command resolves names makes 3rd
> party commands difficult to use and fragile.
> Requiring DNS resolving functionality in the 3rd
> party command target in return for robust global
> names for the storage involved in the 3rd party
> command seems like a reasonable tradeoff.

There should be two clearly defined address spaces, IP and SCSI.  These
spaces should not be mixed in anyway.  Also, the SCSI address, if it must
transverse IP, should be done in a transparent fashion.  Such configuration
would be in the realm of the provider and not something that the client
should be allowed to deal with or influence.  This type of configuration
should happen at the time of authentication where the SCSI Portal is
signaled as routes are determined.  It would also be wise to lease the
authority.

> -- CONNECT and target naming
>
> One thing to keep in mind is that there are traffic
> analysis tools and both current and forthcoming
> implementations of QoS that understand TCP ports.
> If every iSCSI target has its own <IP address, TCP
> port>, these tools work and can differentiate the
> iSCSI targets without any further enhancements.
> If multiple iSCSI targets are behind a common
> <IP address, TCP port> pair, these tools will
> not be able to separate out traffic to the
> targets for different analysis or QoS treatment
> without iSCSI-specific enhancements, although
> they can do so based on different source addresses.

QOS is a system wide configuration and far beyond requirements for
connecting a SCSI transport.  Again, LDAP and a signal upon authentication
would be helpful.  Most of these details should be hidden from the
transport.  If they can be handled outside of the connection, they should
be.

Doug


> --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
> ---------------------------------------------------
>