Re: iSCSI gateways, proxies, etc.

["Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com>]

David,

As with others, I agree this is a nice summary.

Here's my opinions:
1) I think we should stop at option (1).  I think David Robinson has made
the best case in this regard.

2) IF WE NEED OPTION (2) (which I take to be some in-band, i.e., iSCSI,
mechanism), then I believe the question splits in two.
   Q1: what is the data that goes in the message?  [DNS names, URLs, binary
data about the target, ...?]
   Q2: what format should the message be in? [part of the login message or
a separate CONNECT message.]
   IMO (I'm rapidly loosing my humility here!), the answer to Q2 is a
CONNECT message.  I don't have strong feelings about the answer to Q1, but
I weakly lean toward DNS names.  They may be sufficient as the point is
only to get a TCP connection established end-to-end between TCP layers, so
that that iSCSI layers can do their own thing.

Of course, to answer the NEED for (2), we must come to agreement as to what
that need is, because there seem to be many different perceptions in this
regard, and each different "need" seems to lead to a different answer to
the two questions.

The only "NEED" (I can see) might be for plumbing, again something
analogous to HTTPS CONNECT protocol.  I don't see a need for anything else.
But, as I've said, I think iSCSI can stay out of this completely as well.

Jim Hafner


Black_David@emc.com@ece.cmu.edu on 10-11-2000 11:17:51 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI gateways, proxies, etc.



Folks,

We've been going around on the topic of these for
a while without much visible progress.  I'd like
to suggest a means to extricate ourselves from this
situation.

Jim Hafner correctly observed that there is a
fundamental difference between:
- A gateway that always exposes TCP/IP addresses for the
     iSCSI targets behind it, and
- A gateway that must be dynamically configured to
     obtain connectivity to the iSCSI targets behind it.
We don't need to do anything to support the first class
of gateway.  For the second class, there's another
crucial distinction in the second category, namely
between in-band and out-of-band configuration mechanisms.

From a protocol specification viewpoint, out-of-band
configuration mechanisms are both more flexible and
easier to deal with.  Flexibility comes from the
variety of possible mechanisms, for example:

[A] A NAT monitors DNS traffic to/from a DNS server in
private address space behind the NAT.  When a DNS reply
containing a translation is intercepted, the NAT sets up
an external IP address that maps to the internal IP address
in the DNS reply, and substitutes that external IP address
for the internal IP address before forwarding the reply
(in addition to the usual translation operations performed
on the header).  Credit/apologies to whomever (Joshua Tseng?)
originally described this example.

[B] An encrypting firewall does not provide connectivity
to hosts behind the firewall for general traffic outside
the firewall.  If an encrypted IPsec tunnel is set up in
accordance with the firewall's policies, then connectivity
to some of the hosts behind the firewall is provided for
traffic using the tunnel in accordance with the firewall's
policies.

Note that both the NAT and the firewall have to be configured
by some means, and that both of these mechanisms work without
any changes to the iSCSI protocol, as both the DNS lookup and
IPsec tunnel setup happen before the first iSCSI packet is sent.
The fact that we don't have to specify anything makes these
easier to deal with, and gives iSCSI compatibility with all sorts
of things we haven't thought of (yet).

Both the current URL mechanism and the discussion of the
CONNECT message are in-band configuration mechanisms.  In the
context of proxy configuration (Julian's concern about views
is a different, but related issue), this has been turning
into a tarpit on the list.  From what I can see, the issues
here are similar to the issues in naming for 3rd party
commands, something that is not in particularly good shape,
despite T10's best efforts. I find it hard to believe that
people want to repeat T10's experience with this from scratch
for iSCSI, but ... I see three possible paths forward
from which the WG needs to choose:

(1) Rely on out-of-band gateway/proxy configuration.
(2) Reference T10's 3rd party naming formats for target naming.
     This WG would still define an iSCSI 3rd party naming format
     and recommend it to T10, and could define ways of using
     T10 naming formats with Internet protocols (e.g., LDAP).
(3) Invent new ways of naming targets.

I'm inclined to dismiss (3) as being out-of-scope, because
if this really is analogous to 3rd party naming, then it needs
to be left to T10 and iSCSI should follow what T10 adopts, BUT
I'm willing to listen to counter-arguments.

(1) and (2) are complementary rather than exclusive, but the
protocol gets simpler if we don't have to do (2).  The 3rd party
naming recommendations to T10 are needed regardless.

Ok - comments are solicited, as I do intend to try to call
consensus on this set of issues to make progress.

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