|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI MIB Object ModelI 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 |