Re: [storm] iSCSI MIB: Functional enhancements proposal

"Prakash Venkatesen, ERS-HCLTech" <> Thu, 04 October 2012 06:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A3F221F84FF for <>; Wed, 3 Oct 2012 23:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.141
X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kjoCmBE6KmzQ for <>; Wed, 3 Oct 2012 23:58:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9C83421F854E for <>; Wed, 3 Oct 2012 23:58:39 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,532,1344191400"; d="scan'208,217";a="4656050"
Received: from unknown (HELO CSEZ-CORP-HT02.CORP.HCL.IN) ([]) by with ESMTP/TLS/AES128-SHA; 04 Oct 2012 12:25:14 +0530
Received: from CHN-HCLT-CASHT1.HCLT.CORP.HCL.IN ( by CSEZ-CORP-HT02.CORP.HCL.IN ( with Microsoft SMTP Server (TLS) id; Thu, 4 Oct 2012 12:28:36 +0530
Received: from CHN-HCLT-EVS16.HCLT.CORP.HCL.IN ([fe80::f9a1:215b:4319:7e3]) by CHN-HCLT-CASHT1.HCLT.CORP.HCL.IN ([::1]) with mapi; Thu, 4 Oct 2012 12:28:36 +0530
From: "Prakash Venkatesen, ERS-HCLTech" <>
To: "" <>
Date: Thu, 4 Oct 2012 12:28:36 +0530
Thread-Topic: [storm] iSCSI MIB: Functional enhancements proposal
Thread-Index: AQHNof2s7+QAsHcgL0K3XgdtFxB7FQ==
Message-ID: <62DC16C614A9554F81C8E2E5C174A988384B1EAEE0@CHN-HCLT-EVS16.HCLT.CORP.HCL.IN>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "Prakash Venkatesen, ERS-HCLTech" <>
Subject: Re: [storm] iSCSI MIB: Functional enhancements proposal
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Oct 2012 06:58:41 -0000

This includes the following changes:
[1] Added NOP counters at iSCSI session scope for heartbeat tracking
[2] Added port number to the iscsiTgtLoginFailure and iscsiIntrLoginFailure notifications, and to the last failure info in iscsiInitiatorAttributesEntry
[3] Added description string to the iSCSI portal
[4] Added iscsiInstSsnTgtUnmappedErrors to support "Target Unmapped" session failure reporting in the iscsiInstSessionFailure notification. We could not identify a good reference for this object in the other iSCSI drafts. We have left out the reference clause for this object
[6] Added iscsiTgtLogoutCxnClosed and iscsiTgtLogoutCxnRemoved which maintain the count of Logout Command PDUs received by the target with reason codes 1 and 2 respectively. We hope this addresses the request [6] and conforms to the iSCSI Cons draft Section 11.14.1, Reason Code
We did not include the following requests:
[5] For each IscsiPortalAttributesEntry, there’s an iscsiTgtPortalAttributesEntry with the target port, and the initator portal’s port will be dynamic and will have to be found in the connection info.  Sections 6.4 through 6.6 explain this one. So, there is no need to add a port number to iscsiPortalAttributesEntry
[A] to [H]

From: Black, David []
Sent: Saturday, September 15, 2012 6:36 AM
Subject: [storm] iSCSI MIB: Functional enhancements proposal
The iSCSI MIB has been waiting for a WG decision about what to incorporate from the list of functional enhancements suggested by the MIB Doctor review.
With <WG chair hat off>, based on consulting with the MIB draft editors, I offer the following initial proposal for the WG's consideration ... in the hope of getting to a decision.
--- Make the following functional enhancements:
[1] Add NOP counters at iSCSI session scope for heartbeat tracking [2] Add a port number to the iscsiTgtLoginFailure and iscsiIntrLoginFailure notifications,
        and to the last failure info in iscsiInitiatorAttributesEntry.
[3] Add a description string to the iSCSI portal:
iscsiPortalDescr OBJECT-TYPE
    SYNTAX        SnmpAdminString
    MAX-ACCESS    read-only
    STATUS        current
        "A UTF-8 string, determined by the implementation to
        describe the iSCSI portal.  When only a single instance
        is present, this object may be set to the zero-length
        string; with multiple iSCSI portals, it may be used in
        an implementation-dependent manner to describe the
        respective portal, and could include information such as
        HBA model, description and version or software driver and
[4] Support "Target Unmapped" session failure reporting in the iscsiInstSessionFailure notification:
Editors: FailureType is an OID pointing to a stat in iscsiInstSsnErrorStatsTable, so we would need to add this:
    iscsiInstSsnTgtUnmappedErrors       Counter32
[5] Add a port number to iscsiPortalAttributesEntry
[6] Add a timeout counter to iscsiInitiatorLogoutStatsEntry to distinguish implicit
        logouts caused by timeouts from implicit logouts caused by other reasons.
--- Do not make any other functional enhancements, including the following
[A] Summary notifications for large numbers of targets or initiators.  (At most
        a single summary with a count would be appropriate for each notification type).
[B] RowPointer or other connection to transport state as part of
        iscsiInstanceSsnErrorStatsEntry (can be found indirectly in current structure).
[C] Support for reporting more than two digest algorithms (only one is standardized).
[D] Additional list of authentication methods for negotiation (already available based
        on reporting of authorized entities).
[E] Additional support for mutual authentication (check the MIBs at both ends instead).
[F] Support for digest provisioning at the iSCSI node level (use iSCSI portal instead).
[G] Additional session reporting, including digest, error recovery level, session type
        and additional counters for missing PDUs, data in PDUs, data out PDUs, async PDUs.
[H] Report initial remote IP address and port for connections in addition to actual
        IP address and port - this would be for situations in which a redirection has
[I] Report list of discovered targets (out of scope for this MIB).
Of the above list, I'd be particularly interested in comments on [A], [G] and [H] - if these were added to the MIB, would they be likely to be implemented and used?
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786        Mobile: +1 (978) 394-7754


The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.