Re: iSCSI: More on naming and discovery

[julian_satran@il.ibm.com]

David,

With the current draft:

a)-TCP connection can be set with any type of addressing the initiator sees
fit to use -
     and that works for boot to
b)-IP address use for third party is provided for (DNS is recommended but
not mandatory)
c)-strings if used have a canonic form that is conforming to common
practice

I think that going beyond this with our current level of understanding
would be a mistake
and doing less than that will create interoperability problems

I also think that the bulk of the naming discussion - is highly relevant
but we should postpone
it for our discovery/management stage. At that time IP addressing,
autoconfiguration, Service Location
will all come into play.

NAT & Tunneling will work with what we have and I addressed already connect
in a previous note.

Sorry if I repeat myself but my previous notes on this very subject did not
catch your eye.

Julo


Black_David@emc.com on 05/10/2000 16:39:38

Please respond to Black_David@emc.com

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  iSCSI: More on naming and discovery




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.

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.

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.

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

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