Re: iSCSI: New iSCSI MIB draft

[Keith McCloghrie <kzm@cisco.com>]

Mark,

> > Michele >> For the portals, I have to tell that I have some problems:
> > 1. it seems correct to allow an administrator to define iSCSI portals
> > from the iSCSI MIB.
> 
> That should be possible; the iSCSI MIB would likely be the
> right place to do this for many implementations.  This could
> work one of two ways, depending on the implementation:
> 
> - The management station could add the IP address via the iSCSI
>   MIB, and have it automatically be added on the host or device.

As I intimated in my previous message, this is out of scope for this MIB
because assigning new IP addresses to a host is not an iSCSI-specific
function.

> - The managment station could add an existing IP address (one already
>   configured on the host or device); adding it here would make it
>   usable by the iSCSI implementation.
> 
> Incidentally, should we add something like iscsiTgtPortalSource
> to these structures?  This would be an enumerated type indicating
> whether an address was statically configured, or discovered through
> DHCP.
 
Actually, your mention of DHCP raises an interesting problem.

The MIB currently allows an iSCSI instance to have two (say, target)
portals, one at (I1,P1) and the other at (I2,P2), where I1 and I2 are
IP-addresses and P1 and P2 are TCP/transport port numbers.
Now, if P1 and P2 are different, and the host/device uses DHCP to
obtain the two IP addresses.  How do you know which port number goes
with which address ??  My reaction is that you don't/can't.
To solve this problem the MIB must not statically bind local IP
addresses to portals.

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.

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.

Keith.