Re: Comments: New iSCSI MIB draft

[Mark Bakke <mbakke@cisco.com>]

Peter-

Sorry for the delay.  Some answers below.

--
Mark

Peter Mellquist wrote:
> 
> Mark,
> 
> Everything looks well. I appreciate the UML diagrams.
> 
> I have a general question in regard to the iscsiSessionAttributeTable.
> - What is the life of a row in this table? Do they persist after the session
> is gone?

Session rows are not kept after a session is gone.

> - Do rows come and go with each iSCSI session? I assume that this is so
> since iscsiConnectionNumber must have a value from (1..65535).

Yes.  We had discussed the lifespan of some of these objects (especially
session), and while they could provide some value if we kept them after
termination, we didn't see a compelling enough reason to have implementations
do the extra work of maintaining them after they are gone.

> I am considering session statistics (iscsiSessionStats ) in which a SNMP
> manager would like to access stats after the session has been terminated.
> With the current design, is it possible for this to work? Or... does this

That was not the intent, although there's nothing that says an
implementation can't keep them around for a while.  If we decided
that we needed this functionality, it would be better to require
it.  However, that gets us into the dilemma of how long to keep
dead sessions before destroying them.

> information exists only as long as a session is active. It would be nice to
> have historical iSCSI stats in the same manner as the RMON MIB does through
> the history group. Otherwise one would have to have an active SNMP manager
> running all the time gathering session info. Consider a session in which a
> number of errors occur to the point the session is terminated. How does an
> SNMP manager determine what the actual errors were?

The instance object contains counters for errors that cause session
termination; it would not show you which sessions were terminated by
which errors, but you would be able to see what types of errors are
causing sessions to terminate.

> 
> Thank you,
> 
> -peter
> 
> Peter Mellquist
> Seven-Systems Technolgies
> peterm@seven-systems.com
> 
> ----- Original Message -----
> From: "Mark Bakke" <mbakke@cisco.com>
> To: "IPS" <ips@ece.cmu.edu>
> Sent: Wednesday, October 31, 2001 11:00 AM
> Subject: Re: iSCSI: New iSCSI MIB draft
> 
> > For those who are more pictorially inclined when looking at
> > MIBs, I have an updated MIB tree drawing available at:
> >
> > ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-mib-structure-03.pdf
> >
> > --
> > Mark
> >
> > Mark Bakke wrote:
> > >
> > > We have submitted a new iSCSI MIB draft to the repository.
> > > Until it becomes available, it may be retrieved as either
> > > a gzipped or text version from:
> > >
> > > ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt.gz
> > >
> > > ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt
> > >
> > > A matching UML drawing is available at:
> > >
> > > ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-uml-model-03.pdf
> > >
> > > The table hierarchy has been significantly flattened.  This does
> > > not change the object model, but does reduce the number of redundant
> > > levels of OIDs when address individual objects.  I will send a
> > > new table structure drawing soon.
> > >
> > > We will send a list of open issues to the IPS list shortly.
> > >
> > > Thanks,
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >

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