[imss] FC-SP MIB - consensus RE-check

Black_David@emc.com Wed, 27 February 2008 19:58 UTC

Return-Path: <imss-bounces@ietf.org>
X-Original-To: ietfarch-imss-archive@core3.amsl.com
Delivered-To: ietfarch-imss-archive@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8C6793A6A29; Wed, 27 Feb 2008 11:58:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.153
X-Spam-Status: No, score=-3.153 tagged_above=-999 required=5 tests=[AWL=-2.716, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id mNNp3tXHHduo; Wed, 27 Feb 2008 11:58:32 -0800 (PST)
Received: from core3.amsl.com (localhost []) by core3.amsl.com (Postfix) with ESMTP id 97E6D3A6B19; Wed, 27 Feb 2008 11:58:32 -0800 (PST)
X-Original-To: imss@core3.amsl.com
Delivered-To: imss@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 768C83A689A for <imss@core3.amsl.com>; Wed, 27 Feb 2008 11:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id FmkGgIqlfiOJ for <imss@core3.amsl.com>; Wed, 27 Feb 2008 11:58:25 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com []) by core3.amsl.com (Postfix) with ESMTP id 0940A3A6874 for <imss@ietf.org>; Wed, 27 Feb 2008 11:57:50 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m1RJvhor008591 for <imss@ietf.org>; Wed, 27 Feb 2008 14:57:43 -0500 (EST)
Received: from mailhub.lss.emc.com (uraeus.lss.emc.com []) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor) for <imss@ietf.org>; Wed, 27 Feb 2008 14:57:43 -0500
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m1RJvB1w012447 for <imss@ietf.org>; Wed, 27 Feb 2008 14:57:41 -0500 (EST)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 14:57:35 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 27 Feb 2008 14:57:34 -0500
Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91923806@CORPUSMX20A.corp.emc.com>
In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085E7E@CORPUSMX20A.corp.emc.com>
Thread-Topic: FC-SP MIB - consensus RE-check
Thread-Index: AchRSPWe1ji+CuHbTyiyhQe5WwUwYAoKyZSw
X-Priority: 1
Priority: Urgent
Importance: high
References: <8CC6CEAB44F131478D3A7B429ECACD91085E7E@CORPUSMX20A.corp.emc.com>
To: <imss@ietf.org>
X-OriginalArrivalTime: 27 Feb 2008 19:57:35.0194 (UTC) FILETIME=[FF0AFBA0:01C8797A]
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2007.8.30.51425
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Tablus-Inspected: yes
X-Tablus-Classifications: M and A Terms
X-Tablus-Action: allow
Subject: [imss] FC-SP MIB - consensus RE-check
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Internet and Management Support for Storage Working Group <imss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: imss-bounces@ietf.org
Errors-To: imss-bounces@ietf.org

Based on some further technical analysis, the -01 FC-SP MIB
draft took a different approach to two of the technical issues
that arose during WG Last Call than was described in my previous
email and hence these issues need to be rechecked with the WG.

> 1) In the SA-MIB:
> > the intent of omitting the FabricIndex from
> > the INDEX clause of t11FcSpSaTSelPropTable (and t11FcSpSaTransTable)
> > was so that the same list of Traffic Selectors (or transforms) could
> > proposed for multiple SA's even when the SA's are on different
> > which seemed like it would be useful in some situations.  However,
> > need to have a StorageType which is common for the lists and for the
> > proposals, introduces an (always present) complication which I think
> > outweighs the potential (and at most occasional) benefit. That is, I
> > longer believe the omission is worthwhile.  If the WG agrees, I
> > to change the rows in t11FcSpSaTSelPropTable and t11FcSpSaTransTable
> > be per-Fabric, i.e., to add t11FcSpSaIfFabricIndex into the INDEX
> > clause of the t11FcSpSaTSelPropTable and of the t11FcSpSaTransTable.
> > (Indeed, the DESCRIPTION of t11FcSpSaIfStorageType is already worded
> > assume this change will be made.)

Instead of adding the fabric as an index to these two tables, this
issue has been addressed in the -01 version of the draft by adding a
StorageType to each table, maintaining the existing table structure.
> 2) In the POLICY-MIB:
> > The second is that t11FcSpPoAdminFabricName is read-only, as indeed
> > must be because it's part of the Active Policy which cannot be
> > once it's active.  So, how is the Fabric name specified when Policy
> > in use ??  I believe the answer is that t11FcSpPoNaSummaryFabricName
> > needs to be added as a read-create object in the
> > If the WG agrees, then I will add this new object.

This one's subtle.  It turns out that the addition is not needed
because the t11FcSpPoAdminFabricName is obtained from
t11FcSpPoNaSwListFabricName when the policy is activated, and
the latter object is already read-create.  This approach corresponds
to FC-SP where the Fabric Name is in the Switch Membership List
Object and that object has to be created while the policy is
inactive for obvious reasons.

While the Switch Membership List Object may seem to be a non-
obvious place to put the Fabric Name, it's what FC-SP actually does,
so the MIB should do likewise.  The DESCRIPTION clause for
t11FcSpPoAdminFabricName already reflects this approach:

  t11FcSpPoAdminFabricName OBJECT-TYPE
      SYNTAX       FcNameIdOrZero (SIZE (8))
      MAX-ACCESS   read-only
      STATUS       current
             "The administratively-specified name for this Fabric, as
             specified in the active Switch Membership List Object.
             This value is meaningful only ...

but some additional text in Section 3.4.5 would be useful to
point out that the fabric name is in the Switch Membership List
Object, as opposed to the Policy Summary Object.

We need a -02 version of the FC-SP MIB draft to correct a tooling
problem that fouled up the table of contents, so this text should
be added to that version.  The -01 version of the draft is at:



Internet-Draft submission is now cut off until the IETF
meeting week that starts on March 10th.

If anyone has objections to the above approaches, please post
them to the imss list by Wednesday, March 12th.  Absence of
objection will be taken as an indication of WG agreement with
these approaches.

Assuming that nothing major surfaces, Keith should submit a
-02 version of the draft containing the final results shortly
thereafter, and then I will send that draft forward to our ADs
with a request that it be published as an RFC.

--David (imss WG chair)
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
imss mailing list