Re: iSCSI MIB Object Model

[Mark Bakke <mbakke@cisco.com>]

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

julian_satran@il.ibm.com wrote:
> 
> 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 <mbakke@cisco.com> on 14/03/2001 22:48:47
> 
> Please respond to Mark Bakke <mbakke@cisco.com>
> 
> To:   Venkat Rangan <venkat@rhapsodynetworks.com>
> cc:   IPS <ips@ece.cmu.edu>, jmuchow@cisco.com
> 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
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054