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



    
    
    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:20 2001
6315 messages in chronological order