SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [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