Re: [imss] Re: Changes to draft-ietf-imss-fc-fam-mib-00.txt

Keith McCloghrie <kzm@cisco.com> Wed, 15 December 2004 22:20 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23620 for <imss-web-archive@ietf.org>; Wed, 15 Dec 2004 17:20:20 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cehdi-0005Yn-O2 for imss-web-archive@ietf.org; Wed, 15 Dec 2004 17:28:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CehKY-0003xE-7u; Wed, 15 Dec 2004 17:09:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CehJn-0003jK-2q for imss@megatron.ietf.org; Wed, 15 Dec 2004 17:08:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22492 for <imss@ietf.org>; Wed, 15 Dec 2004 17:08:20 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CehS5-0005Dc-SX for imss@ietf.org; Wed, 15 Dec 2004 17:16:58 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 15 Dec 2004 14:13:46 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBFM7kMI001580; Wed, 15 Dec 2004 14:07:46 -0800 (PST)
Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA11079; Wed, 15 Dec 2004 14:07:48 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200412152207.OAA11079@cisco.com>
Subject: Re: [imss] Re: Changes to draft-ietf-imss-fc-fam-mib-00.txt
To: kzm@cisco.com
Date: Wed, 15 Dec 2004 14:07:48 -0800
In-Reply-To: <no.id> from "Keith McCloghrie" at Dec 15, 2004 11:48:02 AM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48
Content-Transfer-Encoding: 7bit
Cc: imss@ietf.org, t11_5@mail.t11.org, Keith McCloghrie <kzm@cisco.com>
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group <imss.ietf.org>
List-Unsubscribe: <https://www1.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://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=subscribe>
Sender: imss-bounces@ietf.org
Errors-To: imss-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Content-Transfer-Encoding: 7bit

Bob Snively has reminded me of a related change which was discussed
at the T11.5 Ad Hoc meeting last week.  Specifically, we agreed in
T11.5 that:

1. I will add a strong warning in draft-ietf-imss-fc-fam-mib-01.txt
   concerning the need for a Fabric name to be the same on all switches
   in a Fabric; this is just as true for a configured Fabric Name, as
   it is when the Fabric Name is the WWN of the Principal switch. 

2. Bob will organize the submission of a contribution to the relevant
   part of T11 proposing that configured Fabric names be required to be
   from a subset of the namespace which has no overlap with the subset
   of the namespace occupied by all possible WWNs of Principal switches.

Keith.
---------------------
From: Keith McCloghrie <kzm@cisco.com>
To: imss@ietf.org, t11_5@mail.t11.org
Date: Wed, 15 Dec 2004 11:48:02 -0800 (PST)
Subject: [imss] Re: Changes to draft-ietf-imss-fc-fam-mib-00.txt

Hi,

Since I sent the message below, the only comment that I've received was
from Claudio, who pointed out to me that FC-SP contains more information
on the subject; in particular, FC-SP defines what it calls an "Insistent
Domain_ID" (see FC-SP, rev 1.6, page 122-123).  Based on this, Claudio
and I believe we need to change the syntax and DESCRIPTIONs of
t11FamConfigDomainId & t11FamConfigDomainIdType, as follows:

  t11FamConfigDomainId OBJECT-TYPE
      SYNTAX      FcDomainIdOrZero
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
	   "The configured Domain_ID of the particular switch on this
	   Fabric, or zero if no Domain_ID has been configured.  The
	   meaning of this object depends on the corresponding
           t11FamConfigDomainIdType object.

	   If t11FamConfigDomainIdType is 'preferred', then the
	   configured Domain_ID is called the 'preferred Domain_ID'.
	   Valid values are between 0 and 239. In a situation where
	   this Domain_ID can not be assigned, any other Domain_ID
	   will be acceptable.  A value of zero means any Domain_ID.

	   If t11FamConfigDomainIdType is 'insistent', then the
	   configured Domain_ID is called the 'insistent Domain_ID' and
	   valid values are between 1 and 239. In a situation where
	   this Domain_ID can not be assigned, no other Domain_ID is
           acceptable.

	   In both of the above cases, the switch sends an RDI (Request
	   Domain_ID) to request this Domain_ID to the Principal
	   Switch. If no Domain_ID is able to be granted in the case
	   of 'preferred', or if an 'insistent' Domain_ID is configured
	   but not able to be granted, then it is an error condition.
	   When this error occurs, the switch will continue as if it
	   receives a SW_RJT with a reason/explanation of 'Unable to
	   perform command request'/'Domain_ID not available'.  That
	   is, its E_Ports on that Fabric will be isolated and the
	   administrator informed via a 't11FamDomainIdNotAssigned'
	   notification.

	   If t11FamConfigDomainIdType is 'static', then the configured
	   Domain_ID is called the 'static Domain_ID' and valid values
	   are between 1 and 239.  In this situation, there is no
	   Principal Switch in the Fabric and the Domain_ID is simply
	   assigned by configuration, together with the Fabric_Name.
           A switch configured with a static Domain_ID, on receiving
           an EFP, BF, RCF, DIA or RDI SW_ILS shall reply with an
           SW_RJT having Reason Code Explanation 'E_Port is Isolated'
           and shall isolate the receiving E_Port."
      DEFVAL  { 0 }
      ::= { t11FamEntry 2 }

  t11FamConfigDomainIdType OBJECT-TYPE
      SYNTAX      INTEGER {
                       preferred(1),
                       insistent(2),
                       static(3)
                  }
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
           "Type of configured Domain_ID contained in
           t11FamConfigDomainId."
      DEFVAL  { preferred }
      ::= { t11FamEntry 3 }

If I don't hear any further comments, I plan to create a
draft-ietf-imss-fc-fam-mib-01.txt incorporating these changes.

Thanks,
Keith.
----------------
From: Keith McCloghrie <kzm>
Message-Id: <200412051714.JAA09001@cisco.com>
Subject: Changes to draft-ietf-imss-fc-fam-mib-00.txt
To: imss@ietf.org, t11_5@mail.t11.org (T11.5)
Date: Sun, 5 Dec 2004 09:14:15 -0800 (PST)
Cc: kzm@cisco.com (Keith McCloghrie)

Hi,

One of the items raised in the IMSS WG at the last IETF meeting in
Washington was that of updating draft-ietf-imss-fc-fam-mib-00.txt in
accordance with the latest agreements in T11.  An earlier revision of
the I-D (draft-desanti-fc-domain-manager-00.txt, dated January 2004)
contained two extra objects and an extra enumerated value for the
T11FamState TC.  At that earlier date, T11.5 decided that it was
"premature" to define these, and they were deleted from subsequent
revisions.

The following text was recently added to FC-SW-4 (in section 7.1):

   Domain_IDs may be assigned statically or dynamically. When
   Domain_IDs are assigned statically, the administrator shall
   configure a Domain_ID and a Fabric_Name on each Switch of the
   Fabric, and the operations described in 7.3 and 7.4 shall not be
   performed by a Switch. When Domain_IDs are assigned dynamically, the
   operations described in 7.3 and 7.4 shall be performed by a Switch.

Based on this addition to FC-SW-4, it is proposed that having the
extra objects/enumeration is no longer "premature", and thus, that they
should now be added.  Here are the specific objects and enumeration:

- additional enumeration to T11FamState:

                       disabled(11),

- two additional objects in the t11FamTable:

  t11FamEnable OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
             "Enables the Fabric Address Manager on this switch
             on this Fabric.

             If enabled on a Fabric, the switch will participate
             in principal switch selection.  If disabled, the
             switch will participate in neither the principal
             switch selection nor domain allocation.  Thus, the
             corresponding value of t11FamConfigDomainIdType
             needs to be 'static'."
      DEFVAL  { true }
      ::= { t11FamEntry 26 }

  t11FamFabricName  OBJECT-TYPE
      SYNTAX      FcNameIdOrZero
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
             "The WWN that is configured on this switch to be
             used as the name of this Fabric when the value of
             t11FamEnable is 'false'.

             If the value of t11FamEnable is 'true', this value
             is not used."
      ::= { t11FamEntry 27 }

Are we agreed on this ?

Keith.

_______________________________________________
imss mailing list
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss

_______________________________________________
imss mailing list
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss