SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: New iSCSI MIB draft


    • To: bill@sanera.net (Bill Strahm)
    • Subject: Re: iSCSI: New iSCSI MIB draft
    • From: Keith McCloghrie <kzm@cisco.com>
    • Date: Wed, 7 Nov 2001 10:00:45 -0800 (PST)
    • Cc: kzm@cisco.com, ips@ece.cmu.edu
    • Content-Transfer-Encoding: 7bit
    • Content-Type: text/plain; charset=us-ascii
    • In-Reply-To: <HDECJFNIFJBIAINDCFOMKEEJCDAA.bill@sanera.net> from "Bill Strahm" at Nov 07, 2001 09:39:35 AM
    • Sender: owner-ips@ece.cmu.edu

    Hi Bill,
    
    (I'll post your message and my response to the list as you said I could.)
    
    Yes, a socket interface typically provides the ability to listen
    for incoming connection requests on one or all addresses.  That is,
    a common implementation of the IP-layer allows for what iSCSI is
    proposing.  However, few if any applications do it.
    So, just because a lower-layer implementation allows for it to be
    done, should the application's arhcitecture require it be done ?
    
    Binding to an interface does seem better, but I think it causes iSCSI
    to enter the murky world of multi-homing, see the descriptions of the
    Strong ES model and the Weak ES model in RFC 1122 (pages 62-63).
    (Or perhaps, iSCSI is already in that world?)
    
    Keith.
    
    > Keith,
    > 
    > I want to pick a nit with your description of how a TCP/UDP Server works...
    > I'll do this privately, if you think it is worth expanding on feel free to
    > post to the IPS mailing list
    > 
    > Comments inline
    > 
    > 
    > -----Original Message-----
    > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > Keith McCloghrie
    > Sent: Wednesday, November 07, 2001 8:27 AM
    > To: Mark Bakke
    > Cc: Michele Hallak - Stamler; IPS
    > Subject: Re: iSCSI: New iSCSI MIB draft
    > 
    > None of the IP-based applications that I can think of (e.g., FTP, HTTP,
    > SNMP, SMTP, BGP, etc.) have a static binding of a local TCP port number
    > to a subset of the local host's IP-addresses.  Rather, they have a
    > static TCP/UDP port on which the server listens, and the client has a
    > port dynamically assigned on a per-connection/session basis.  The
    > server listens on the static port on all local IP addresses; the client
    > dynamically picks a local IP address on a per-connection/session
    > basis.  So, does iSCSI work this way also ??  If so, then the MIB
    > is wrong; if not, I think iSCSI has a problem with DHCP.
    > 
    > <Bill Strahm>
    > Actually the server may bind to ANY local address, in fact in many
    > situations you want the service to bind to one interface but not the other
    > (let say providing DHCP internally, but not externally, or providing
    > internal DNS, vs. external DNS).  This binding is done based on IP address
    > (the parameter provided to the bind call), you are correct most times a
    > default address is provided as 0.0.0.0 which means bind to all interfaces.
    > 
    > What you want to do (and I think will solve the DHCP problem) is to bind to
    > an InterfaceIndex, allowing the application to determine which IP address to
    > use based on entries in the IP table (what interface is that address bound
    > too)
    > <End Bill Strahm>
    > 
    > Also note that you have used InetAddressType (from RFC 2851), and one
    > of the enumerated values of InetAddressType is 'dns'.  As and when 'dns'
    > is the value of iscsiTgtPortalAddrType or iscsiIntrPortalAddrType, then
    > you would typically not have a static binding of a local TCP port
    > number to one of the local host's IP-addresses.
    > <Bill Strahm>
    > I think you can still statically bind to a single interface in this case
    > <End Bill Strahm>
    > 
    > Bill Strahm
    > +========+=========+=========+=========+=========+=========+=========+
    > Bill Strahm     Software Development is a race between Programmers
    > Member of the   trying to build bigger and better idiot proof software
    > Technical Staff and the Universe trying to produce bigger and better
    > bill@sanera.net idiots.
    > (503) 601-0263  So far the Universe is winning --- Rich Cook
    > 
    > 
    > 
    
    


Home

Last updated: Wed Nov 07 14:17:41 2001
7618 messages in chronological order