Subject: Re: iSCSI MIB Object Model

From: [email-masked]
Date: Thu, 15 Mar 2001 10:29:49 +0200

Mark,

iSCSI uses LUN almost transparently.  Also the LUN may change while a
session is active.
I am not sure that the fact that there is no SCSI MIB (yet) doe justify
including those items in the iSCSI MIB.

I also recall (a rumor?) that somebody is working on a SCSI MIB (it will be
needed anyhow there is more to SCSI than the LU).

Julo

Mark Bakke <[email-masked]> on 14/03/2001 22:48:47

Please respond to Mark Bakke <[email-masked]>

To:   Venkat Rangan <[email-masked]>
cc:   IPS <[email-masked]>, [email-masked]
Subject:  Re: iSCSI MIB Object Model

Venkat-

You have captured many of our open issues in this
message.  Please see my comments below.

Thanks,

Mark

Venkat Rangan wrote:
>
> Mark,
>
> The UML is very nice, and the new object model, covering both
> Initiator and Target instances is also nice.
>
> Overall, we do have some concern over the need for maintaining per-LU and
> per-LUN statistics. In some iSCSI implementations, the iSCSI entity is
> merely an intermediate layer, with no knowledge of LUs and LUNs. Placing
> this in the GeneralInfo category and making it mandatory would add undue
> burden on these implementations.

One of our open questions is "how much is too much?".  We added the LU
and LUN statistics for a few reasons:

1. The iSCSI layer does see the LUN; it is included in the SCSI Command
   message.

2. For implementations that include the actual target and LUs, such
   as storage controllers, there is no other way to get information
   on LUNs through SNMP, since there is no SCSI MIB.

3. We felt that in this case customers might require LU- or LUN-level
   accounting.

However, keeping statistics at this level does create some work; perhaps
there is a way to make it optional.

> In Section 5.9:
>    "The iscsiLUTable contains a list of iSCSI Logical Units that are
>    accessible via the iSCSI target."
>
> Would this list be the same as what the "Report LUNs" command would give?

It depends.  A LUN is just the address of a logical unit, and in the
general case, is only valid between a particular initiator and a particular
target.  If a second initiator issues a "Report LUNs" to the same target,
it may get back a different list if the target is performing some sort of
LUN mapping.  Some targets will show the same set of LUNs regardless of the
initiator; some won't.  There is no reliable way given the current MIB to
find out what "Report LUNs" would return; this is probably the domain of
a SCSI MIB.

> In Section 5.7:
>    "The iscsiLunTable contains an entry for each known LUN that is being
>    accessed using this session.  Note that is may not contain all of the
>    LUNs that could be accessed; the only ones available to iSCSI are the
>    ones that have been addressed specifically by iSCSI commands.
>    Therefore, LUNs that have been discovered via mechanisms such as the
>    SCSI "report LUNs" will not appear in this table until they are
>    specifically addressed by the initiator.
>
> How long do these entries live in the table? If iSCSI sessions logout and
> close, do these entries continue to remain?

The current intent is to have entries live only as long as the sessions;
these would be removed when the session is removed.  This is the simplest
solution and would put the smallest burden on the implementation.

However, we still have an open "requirements" question on whether anyone
wants these to hang around longer.

> Thanks,
>
> Venkat Rangan
> Rhapsody Networks Inc.
> http://www.rhapsodynetworks.com
>

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

---

From: Matt Wakeley <[email-masked]>
Date: Thu, 15 Mar 2001 13:25:19 -0800

I agree that LUNs and LUs are (should be) transparent to iSCSI, and thus such
LU/LUN specific information should not be included in the MIB.

Mark, since your company is now a member of T10, perhaps you can repackage the
information as a SCSI MIB draft?

-Matt Wakeley

---

From: Mark Bakke <[email-masked]>
Date: Fri, 16 Mar 2001 08:52:40 -0600

Matt-

LUs are not visible in iSCSI, but LUNs are visible within an iSCSI
session.  Once the session is gone, the LUN is gone, too.  Since the
information was avaiable, we wanted to see what value it might add.
Matt-

If we get a SCSI MIB going, perhaps we can avoid at least some of this.
Without a SCSI MIB, we still have customer requirements to see LUs
through a MIB, and if we had to break layers to do it, ...

Somesh's proposal would give users the information they need to
determine if access to a particular LUN is causing trouble, without
keeping track of individual LUNs.

Marjorie Krueger (HP) has been looking into doing a SCSI MIB draft,
starting with object models derived from iSCSI.  There are several
other members of the MIB team that are interested in working on this
as well.  One of our open issues for next week is whether to pursue
a SCSI MIB, and if so, how to do it within T10.  Dave Peterson will
bring it up with T10 as well.

At any rate, I hope to get some clear direction from the IPS WG in
general on this by next week.  Most of the comments from the WG
so far support minimizing or eliminating the LU and LUN information
from the iSCSI MIB.

--
Mark

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

---

From: Mark Bakke <[email-masked]>
Date: Fri, 16 Mar 2001 14:48:42 -0600

Julian-

You are right, it is "almost transparently".  We still have enough
visibility to keep track of who's-doing-what to a LUN, or at least
pointing at LUNs that have been the subject of an error.

Who changes LUNs during an active session?  This sounds pretty
strange to me.  I could see adding new LUNs, but changing the
addresses of existing ones sounds really odd.  Is there a reference
I can look at for something that does this?

I have the SCSI MIB topic in my presentation for Monday; hopefully
we will get some consensus on what to do.

Thanks,

Mark

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