|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 > --------------------------------------------------- > > > >
Home Last updated: Tue Sep 04 01:06:41 2001 6315 messages in chronological order |