SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI MIB Object Model



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


Home

Last updated: Tue Sep 04 01:05:18 2001
6315 messages in chronological order