Subject: RE: iSCSI MIB Object Model

From: Venkat Rangan <[email-masked]>
Date: Wed, 14 Mar 2001 10:57:22 -0800

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.

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?

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?

Thanks,

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

-----Original Message-----
From: Mark Bakke [mailto:[email-masked]]
Sent: Monday, March 12, 2001 7:12 AM
To: IPS
Subject: iSCSI MIB Object Model

iSCSI MIB enthusiasts-

While building the iSCSI MIB table structure, we created a
UML (more or less) model for iSCSI, from which the MIB was
derived.  Julian has placed a pdf of the model on his web
site; it is available at:

http://www.haifa.il.ibm.com/satran/ips/Visio-iscsi-uml-model-02.pdf

The UML model does not show every table and attribute; it is
meant as a higher-level abstraction, and should be helpful in
reading the MIB, or in understanding how the iSCSI objects
relate to one another.  It has been updated to include a few
fields that are missing in the current draft.

Also available, for those who do not have the previous messages:

iSCSI MIB table structure

http://www.haifa.il.ibm.com/satran/ips/iscsi-mib-structure-02.pdf

iSCSI MIB (zipped version)

http://www.haifa.il.ibm.com/satran/ips/draft-bakke-iscsimib-02.zip

iSCSI MIB (uncompressed)

http://www.haifa.il.ibm.com/satran/ips/draft-bakke-iscsimib-02.txt

Enjoy,

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

---

From: Mark Bakke <[email-masked]>
Date: Wed, 14 Mar 2001 14:48:47 -0600

Venkat-

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

Thanks,

Mark

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

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

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

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

---

From: "Somesh Gupta" <[email-masked]>
Date: Wed, 14 Mar 2001 16:52:07 -0800

Mark,

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mark Bakke
> Sent: Wednesday, March 14, 2001 12:49 PM
> To: Venkat Rangan
> Cc: IPS; [email-masked]
> Subject: Re: iSCSI MIB Object Model
>
>
> Venkat-
>

I just did a rough (very rough) calculation for the amount of data
required per lu and per lun - It is of the order of 256 bytes per lu
and 512 bytes (actually more like 350) per lun. The number of
Luns/lus can be in the 10s of thousands.

Even though the iSCSI PDU header carries a LUN number, this value
is really transparent to the iSCSI layer. The iSCSI layer should
not even know how many LUNs there are in the system. The size of
the data set, and the cost of managing it are fairly significant.
The ability of systems to dynamically add & delete LUNs/LUs should
not be tied to the ability of the iSCSI layer to track the stats.

I think reasons 1 & 2 are not very good reasons. An analogy would
be asking TCP to perpetually keep statistics on every 4-tuple that
was ever used to create a connection.

I would recommend focusing on the error cases only for one - and
perhaps have a table per error type tracking the last "n" errors.
What does it matter if an R2T was received for a LUN or not? It
just becomes a bunch of probably unneeded information to weed
through to get to the real info.

> > http://www.rhapsodynetworks.com

Somesh

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Mark Bakke <[email-masked]>
Date: Thu, 15 Mar 2001 14:29:13 -0600

Somesh-

We are looking into making the LU and LUN tables optional,
which would help in this case.   I will bring up the appropriateness
of including them at IETF next week.

I like your idea of keeping track of the last few LUN errors.

I assume that you would like to see something like:

1. Each target includes a list of errors; the target would fill
   in something like the timestamp, LUN, and initiator WWUI that
   caused that error last.

2. Each session includes a list of errors, and does a similar
   thing.

Does this sound reasonable?  Do you have other ideas for doing
this that would simplify finding out what went wrong with LUs
and LUNs?

--
Mark

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

---

From: "Somesh Gupta" <[email-masked]>
Date: Thu, 15 Mar 2001 13:38:33 -0800

Mark,

What you propose is what I was thinking of. I would
expect this info to be the most useful part.

My preference would be to not have per LU and per LUN
info at all, even optional (at the transport level).
Just because it is visible is not a good reason.

This issue is really something to be addressed at a
higher level, and if they don't have it yet, maybe that
is just fine.

Regards,
Somesh

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 12:29 PM
> To: [email-masked]
> Cc: Venkat Rangan; IPS; [email-masked]

---

From: Mark Bakke <[email-masked]>
Date: Fri, 16 Mar 2001 09:00:03 -0600

Matt brought up the same thing, about not having LU and
LUN info.  If we can get a SCSI MIB done quickly enough,
that might give us the visibility we would need for these,
and perhaps we could take them out.  I am hoping to get
a strong WG consensus on this next week.

--
Mark

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