RE: iSCSI gateways, proxies, etc.

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

Charles,

Should there be a generalized encapsulation that must be altered by the
server, or should there be a specific encapsulation for the native SAN?  In
the case of a specific encapsulation, there would be a better likelihood of
scaling as the workload remains within the client.  Otherwise, inventing a
generalized encapsulation requiring modification of addressing and
structures seems pre-mature as there are many issues to be considered before
this encapsulation becomes native to the medium.  Forwarding and security is
but one aspect.

Doug

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