Subject: RE: iSCSI: New iSCSI MIB draft

From: "Michele Hallak - Stamler" <[email-masked]>
Date: Wed, 7 Nov 2001 11:40:46 +0200

My answers in-line also:

-----Original Message-----
From: Mark Bakke [mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 4:19 PM
To: Michele Hallak - Stamler
Cc: IPS
Subject: Re: iSCSI: New iSCSI MIB draft

Michele-

Answers inline.  Basically, we have discussed making parts of the
MIB writable, and need to start working on it some more.  Please keep
posting anything that you think might be useful as a writable attribute
or a creatable/deletable row.

--
Mark

Michele Hallak - Stamler wrote:
> 
> Hi,
> 1.I see that the target access list is still read-only. How do you
think
> that it should be configured?

I had originally assumed that these would be configured by other
means than SNMP, but it is certainly something that makes sense to
configure.  I will post another message to start a thread on this.

Michele>> I think also that we should add an additional field describing
the kind of access (read-only / read-write)
I think also that it will be a good idea to have and enable/disable
field as you and Keith suggested.

> 2. Who should configure the aliases of the iscsi targets and
initiators?

These could easily be writable as well.

> 3. Same question for the portals.

Have to think about this one.  Any ideas?
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.
2. in another way, a portal has some relation to a specific interface
(IP Address/MAC Address) and for that relation we need the IP-MIB (if
I'm not wrong)
3. so it should be specified clearly: can we define "new ip addresses"
via this MIB or only use the existing IP defined in 
ipNetToMediaTable?
4. anyway, IMHO, it should be the only standard way to define a new
iSCSI TCP Port.

Additional comments:
Are there no needs to configure: 
1. Max Number of Sessions (per instance? per target? per portal?)
2. Max Number of connections per session?

Thanks,
	Michele

---

From: Mark Bakke <[email-masked]>
Date: Wed, 07 Nov 2001 09:08:30 -0600

> or a creatable/deletable row.

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.

- 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.

> (IP Address/MAC Address) and for that relation we need the IP-MIB (if

Technically, we don't need to do this; the relationship between
an IP address and a physical interface is typically an indirect
one that makes use of the host or device's routing tables.  However,
anything supporting iSCSI ought to have all of the TCP and IP MIBs
anyway.

> via this MIB or only use the existing IP defined in

Good question for debate; it can be done either way.

> 4. anyway, IMHO, it should be the only standard way to define a new

I would guess that most target implementations will assume an iSCSI
TCP port as the default, and the user or management station will
only have to specify one if they want something different.

> 2. Max Number of connections per session?

I don't think so.  These are generally limited by the implementation,
rather than by the user.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 7 Nov 2001 06:58:38 -0800 (PST)

> via this MIB or only use the existing IP defined in ipNetToMediaTable?

This MIB should use IP address(es) that a device already has; it should
not attempt to provide the ability to configure additional IP addresses.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 7 Nov 2001 08:26:45 -0800 (PST)

Mark,

>   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.

> whether an address was statically configured, or discovered through
 
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.