RE: iSCSI gateways, proxies, etc.

[julian_satran@il.ibm.com]

Charles,

Both Ralph Weber and Jim Hafner let us know that T10 has already a proposal
that
is going to be approved soon. I think it would be nice if we could get a
chance to comment
on it before it gets voted.

Julo

Charles Monia <cmonia@NishanSystems.com> on 12/10/2000 19:44:59

Please respond to Charles Monia <cmonia@NishanSystems.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI gateways, proxies, etc.




Hi:

Do you plan to submit a proposal for T10's consideration

Charles

> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Thursday, October 12, 2000 12:27 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI gateways, proxies, etc.
>
>
>
>
> David,
>
> That is a fair summary and I agree with it.
> I think that one point of clarification is needed with regard to 2.
> To use the T10 addresses for third party we invented the
> (admittedly ugly)
> map and unmap
> messages. It should be clear that as we can't afford to
> synchronize with
> T10
> those will have to stay and get obsoleted in some later
> version when T10
> moves
> to a more flexible scheme.
>
> Julo
>
> Black_David@emc.com on 11/10/2000 21:17:51
>
> Please respond to Black_David@emc.com
>
> 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
> ---------------------------------------------------
>
>
>
>