|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI gateways, proxies, etc.Julo, The Map/Unmap commands will not be needed (by the time the iSCSI standard gets approved). I predict that the function you want will be part of SCSI (i.e., approved by T10) by the Jan. 2001 meeting. Ed Gardner is proposing something along these lines to solve both the iSCSI and SVP (SCSI over VI Protocol) issues of names larger than 8 bytes. Jim Hafner julian_satran@il.ibm.com@ece.cmu.edu on 10-12-2000 12:26:47 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: 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:42 2001 6315 messages in chronological order |