From mailman-bounces@ietf.org Wed Dec 1 09:30:46 2004 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 JAA02930 for ; Wed, 1 Dec 2004 09:30:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZVac-0001DI-Jc for imss-web-archive@ietf.org; Wed, 01 Dec 2004 09:36:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSiL-0005r8-2Y for imss-web-archive@ietf.org; Wed, 01 Dec 2004 06:32:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: imss-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:52:19 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for imss-web-archive@ietf.org: List Password // URL ---- -------- imss@ietf.org otpees https://www1.ietf.org/mailman/options/imss/imss-web-archive%40ietf.org From imss-bounces@ietf.org Thu Dec 2 06:29:09 2004 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 GAA02320 for ; Thu, 2 Dec 2004 06:29:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZpEc-0007de-O9 for imss-web-archive@ietf.org; Thu, 02 Dec 2004 06:34:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZol3-0006Mm-15; Thu, 02 Dec 2004 06:04:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZocj-0006Ft-31; Thu, 02 Dec 2004 05:55:45 -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 FAA28232; Thu, 2 Dec 2004 05:55:42 -0500 (EST) From: elizabeth.rodriguez@dothill.com Received: from artecon.dothill.com ([155.254.128.254] helo=dothill.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZoiD-0006SH-Kh; Thu, 02 Dec 2004 06:01:27 -0500 Received: from exchange.artecon.com (exchange [206.6.182.75]) by dothill.com (8.12.9+Sun/8.12.5) with ESMTP id iB2AnPXc013919; Thu, 2 Dec 2004 02:49:25 -0800 (PST) Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Dec 2004 02:52:03 -0800 Message-ID: To: ips@ietf.org Date: Thu, 2 Dec 2004 00:50:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: imss@ietf.org, T11_5@t11.org, t11_3@t11.org Subject: [imss] Changes to FC Mgmt MIB -- Please Review! X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Hi all, The FC Mgmt MIB has completed IETF last call, but as mentioned in the IETF meeting in D.C., an IETF last call comment was inadvertently missed. This change is the addition of a column to the fcmSwitchTable. Since this is a special circumstance, we will be addressing this issue at this time. In addition, there are a few other change that have been approved to go into the draft, some editorial, and some which have been discussed on this list before. Please review the proposed changes that Keith lists below and discuss on the ips list and/or get any feedback to Keith, David and I as soon as possible. Should no discussion occur by Dec 9th, we will assume consensus and go forth with these changes. Thanks, Elizabeth > Forwarded message: > > IP Storage (ips) WG - Washington DC minutes - DRAFT > > ... > > November 8, 2004 at the IETF meetings in Washington, DC. > > ... > > FC Management MIB (draft-ietf-ips-fcmgmt-mib-05.txt) > > - New field to be added to deal with a MIB instance that > > covers multiple switches. This was submitted as an > > IETF Last Call comment, but got lost. -06 version of > > MIB will be produced containing all agreed-to changes > > from -05 plus this change. Message will be sent to > > list to do a quick review of this final change. > > > Please can you check to ensure that the following is the correct set > of changes that I need to make: > > 1.Add a new columnar object in the fcmSwitchTable: > > a) add its definition : > > fcmSwitchWWN OBJECT-TYPE > SYNTAX FcNameIdOrZero > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The World Wide Name of this switch." > ::= { fcmSwitchEntry 4 } > > b) add the object in fcmSwitchEntry's SEQUENCE, and > > c) add the object to the fcmSwitchBasicGroup which now becomes: > > fcmSwitchBasicGroup OBJECT-GROUP > OBJECTS { fcmSwitchDomainId, fcmSwitchPrincipal, fcmSwitchWWN } > STATUS current > DESCRIPTION > "Basic information about Fibre Channel switches." > ::= { fcmgmtGroups 2 } > > 2. Add to fcmInstanceFabricId's DESCRIPTION, this paragraph: > > In the event that the Fibre Channel entity/entities managed by > this management instance is/are connected to multiple fabrics, > then this object records the first (known) one. > > 3. Change in the DESCRIPTION of fcmLinkEnd2AgentAddress > > "The GS-3 specification provides example values of URLs which > indicate an SNMP, HTTP or XML agent." > -> > "The GS-4 specification provides some information about > management agents." > > 4. Remove spurious double-quote character at end of section 4.8. > > 5. The FC-MI document has been published; the reference should be > changed to: > > [FC-MI] > "Fibre Channel - Methodologies for Interconnects Technical Report > (FC-MI)" INCITS TR-30-2002. > > 6. The FC-GS-3 document has been published, the multiple references to it > should be changed to delete "Rev 7.01, 28 Nov 2000" > > 7. In the last sentence of section 5.2, change: > > "the implementation is not required ..." > -> > "the agent implementation is not required ..." > > Thanks, > Keith. > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Sun Dec 5 12:27:07 2004 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 MAA23539 for ; Sun, 5 Dec 2004 12:27:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb0GL-0003YH-H6 for imss-web-archive@ietf.org; Sun, 05 Dec 2004 12:33:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb01D-00008n-7N; Sun, 05 Dec 2004 12:17:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CazyE-000788-QK for imss@megatron.ietf.org; Sun, 05 Dec 2004 12:14:52 -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 MAA22594 for ; Sun, 5 Dec 2004 12:14:48 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb04P-0003ID-K3 for imss@ietf.org; Sun, 05 Dec 2004 12:21:14 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 05 Dec 2004 10:22:24 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB5HEDD9027712; Sun, 5 Dec 2004 09:14:13 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA09001; Sun, 5 Dec 2004 09:14:15 -0800 (PST) From: Keith McCloghrie Message-Id: <200412051714.JAA09001@cisco.com> To: imss@ietf.org, t11_5@mail.t11.org (T11.5) Date: Sun, 5 Dec 2004 09:14:15 -0800 (PST) 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: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Keith McCloghrie Subject: [imss] Changes to draft-ietf-imss-fc-fam-mib-00.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit 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 From imss-bounces@ietf.org Fri Dec 10 03:03:49 2004 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 DAA20622 for ; Fri, 10 Dec 2004 03:03:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccfrt-0006ma-Rc for imss-web-archive@ietf.org; Fri, 10 Dec 2004 03:11:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcfkI-00075m-89; Fri, 10 Dec 2004 03:03:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcfjK-0006uZ-3k for imss@megatron.ietf.org; Fri, 10 Dec 2004 03:02:22 -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 DAA20510 for ; Fri, 10 Dec 2004 03:02:20 -0500 (EST) From: elizabeth.rodriguez@dothill.com Received: from artecon.dothill.com ([155.254.128.254] helo=dothill.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcfqS-0006kO-V8 for imss@ietf.org; Fri, 10 Dec 2004 03:09:45 -0500 Received: from exchange.artecon.com (exchange [206.6.182.75]) by dothill.com (8.12.9+Sun/8.12.5) with ESMTP id iBA7u0Xc018702 for ; Thu, 9 Dec 2004 23:56:00 -0800 (PST) Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Dec 2004 23:58:14 -0800 Message-ID: To: imss@ietf.org Date: Fri, 10 Dec 2004 00:05:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Subject: [imss] IMSS Meeting Minutes, IETF 61 X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Here are the minutes from the IMSS working group from D.C. Let me know of any corrections or clarifications. Thanks, Elizabeth --- The IMSS Working Group met on Tuesday, November 9, 2004 at 14:15 (2:15 pm) at the IETF-61 in Washington D.C. The following agenda was presented: Agenda: 2:15: Administrativa (Elizabeth Rodriguez) 2:25: Liaison Report from T11.5 (Roger Cummings) 2:35: New working group drafts: (Keith McCloghrie) Fibre Channel Name Server MIB: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-nsm-mib-00.txt Fibre Channel Fabric Address Manager MIB: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-fam-mib-00.txt (formerly Domain Mgr MIB) 2:50: New proposed work item: (Claudio DeSanti) IPv4 over Fibre Channel: http://www.ietf.org/internet-drafts/draft-desanti-imss-ipv4-over-fibre-chann el-00.txt This draft is a proposed draft that the authors believe should either update or replace RFC 2625. It includes details of differences between RFC 2625 and the I-D. 3:05: Discussion of proposed new work items. (Roger Cummings) INCITS T11.5 would like to propose new work for the IMSS working group to consider. FSPF (Fibre Shortest Path First) MIB Routing Information MIB (routing protocol independent) No drafts currently available. 3:--: Open Mike (time permitting) 3:15: Meeting Concludes Adminstrativa included a greeting, noting that the "note well' statement applies. Elizabeth indicated that the IMSS WG has a very close relationship with the INCITS T11 organization, and T11.5 in particular. T11.5 is a task group within the INCITS T11 Technical committee. In general, the work performed in this working group is a joint effort between T11 and IMSS, with each group providing particular expertise for the drafts -- T11 addresses FC specific criteria and IETF provides the MIB and IP expertise. -- Roger Cummings then presented the T11.5 Status for IMSS. Roger is the T11.5 liaison to the IMSS working group. Two drafts have been submitted from T11.5 and accepted as working group items: draft-ietf-imss-fc-fam-mib-00.txt and draft-ietf-imss-fc-nsm-mib-00.txt The presentation 04-740v0.pdf has details on how to access the T11.5 information on those drafts, including various URLs. Roger then presented preliminary information on two drafts that T11.5 is working on. These drafts are the Routing Information MIB (SM-RTM) and Fibre Shortest Path First (FSPF) (SM-FSM) No formal drafts exist yet. T11.5 is targeting July, 2005 for submitting these drafts to IMSS for consideration as official working group items. Roger then mentioned two other items that T11.5 may undertake, which also will likely be presented to IMSS for consideration as working group items. The first is a MIB to address Virtual Fabrics and the second addresses Fabric Routing. Roger discussed the IANA registry created for Fibre Channel Port Types. Roger has been designated the expert reviewer for this registry. Elizabeth suggested it would be beneficial to post the T11.5 SD-3 (proposal documents) that are expected to eventually be submitted to IMSS on the IMSS reflector or as individual submissions to IMSS, so that IMSS has a heads up on what T11.5 is planning on working on and what their contents will cover. -- Next Keith McCloghrie presented more information on the first two MIBs that have been submitted to the IMSS working group as official working group items -- draft-ietf-imss-fc-fam-mib-00.txt and draft-ietf-imss-fc-nsm-mib-00.txt mentioned before. He began with a brief history of FC MIBs that have been worked on in the past. The first FC MIB was the FC entity MIB, RFC 2837. Next was the Fibre Alliance MIB that was submitted to the IETF, eventually withdrawn. T11 did publish this draft eventually as MIB-FA, but only as informational, not a standard. IP Storage then defined the FC MGMT MIB, which merged the above two MIBs. This draft has completed IETF Last Call and been approved by the IESG. Elizabeth pointed out that one of the issues that came out of this work is that some people felt that T11 did not have enough say in this document, even though individuals did participate in the development. This is one of the reasons for the joint work that T11 and IMSS are doing now, so that both organizations have an opportunity to "bless" the document. When an outline for 9 new MIBs were presented to the IPS WG for consideration as working group items, it was decided that instead we would develop a process by which the drafts would be worked on first in the T11.5 working group to insure conformance with T11 FC standards. The MIBs would then be transferred to IMSS. This working group will insure that they conform to SMIv2 and consistency with other MIBS. The drafts would not become T11 standards, only IETF standards. Keith presented more information on the draft-ietf-imss-fc-fam-mib-00.txt and draft-ietf-imss-fc-nsm-mib.00.txt. See the presentation for more details. FAM contains two MIB modules: T11-TC-MIB and T11-FC-FABRIC-ADDR-MGR-MIB. T11-TC-MIB module contains only FabricIndex. For current FC specks, this value always 1, but added for future proofing -- corresponding to new work in FC-SW-4. Tables indexed by FC Mgmt Instance (FC Mgmt MIB), switch index and fabric index. Contains 5 tables and three notifications. NSM contains 1 MIB module: T11-FC-NAME-SERVER-MIB, 5 tables and 1 notification. Indexed by Management Instance (FC mgmt MIB) and subset index. Confirmation requested that the IMSS working group does want to work on these drafts. Consensus. Next step is to have discussion on IMSS mailing list to see if there any changes or updates required for the FAM and NSM MIBs. One point was bought up that there were some items in a previous T11 version of the draft that were removed due to no corresponding standard in T11 containing the information. This has changed, and as such, the possibility of making changes to the MIB corresponding to these new additions to the T11 standards should be considered, since these changes would likely otherwise result in this MIB requiring a revision later. Once changes have been considered and, if necessary, made, conducting a WG last call, potentially in January or February, for these drafts will be considered. One thing that T11 needs to figure out is if a process needs to be developed for T11 to take some kind of vote confirming changed made in the IETF, probably in the same timeframe that IETF is conducting WG last call. -- Next Claudio DeSanti presented IPv4 and ARP over Fibre Channel. Prior to Claudio making the presentation, Elizabeth gave a little bit of background. Specifically, the first WG item undertaken by IMSS was IPv6 over FC, which became RFC 3831. RFC 3831 targeted IPv6 only, since RFC 2625 addressed IPv4 over FC. The intent had been to take RFC 2625 to proposed standard, but it was determined by several people interested in advancing RFC 2625 that this was not feasible. So, in T11 task group T11.3, new work was undertaken to develop a draft to fix the issues from RFC 2625. An IPv4 over FC draft has been submitted for consideration by this working group as draft-desanti-imss-ipv4-over-fibre-channel-00.txt. This draft is targeted to replace (obsolete) RFC 2625.One question needs to be addressed is what is the appropriate process for performing this work, since we have an RFC that addresses IPv4 over FC and another that addresses IPv6 over FC, and typically all new work is supposed to cover both IPv4 and IPv6. Should the new draft also replace RFC 3831? Some issues with RFC 2625: N_Port_Name format restriction to using only NAA=1, and requiring use of FARP. NAA is an address format used by FC, and NAA=1 is a 48 bit MAC like address format. FARP is a Fibre Channel ARP format defined in 2625, but that has major problems. Many vendors did not implement ARP. Some disk vendors do/did not tolerate receiving FARPs and could cause errors, including errors for an unrelated device on the network. Consensus in T11 that RFC 2625 should be replaced with this new work. Also makes sense to create a unified document replacing both RFC 2625 and 3831. The new document would be 100% backward compatible with 3831, since the new draft is based on 3831. Question asked regarding FARP -- will the new draft prohibit FARP - Response no; would not prohibit, but would not require. Confusion over the term exchange. In this context of this discussion, exchange refers to Fibre Channel Exchange, not exchange of IP packets. The combined document would have no technical changes to the IPv6 over FC component of the draft. New draft would have changes to the IPv4 component -- namely all commonly used Name Identifier formats (NAA) are supported; ARP simplified, FARP not required. Missing functionality such as IPv4 Multicast support added. Bert does not see a problem in replacing both RFC 2625 and RFC 3831, but need to consult with Margaret Wasserman, since this is not his area of expertise. David Black expressed the opinion that he feels this is the right idea. Elizabeth needs to follow up with Margaret to confirm she is OK with this. Send to Margaret Claudio's slides. Needs to be discussed with the IESG. Consensus call: Does anyone object to this becoming a new working group item, pending approval by the IESG. -- No objection. Is there any interest in working in this group to work on this draft. Consensus yes. First official IMSS draft will be combined draft. Discussion of SM-FSM and SM-RTM, briefly touched on at the beginning of the meeting. Elizabeth emphasized that the work on these drafts needs to be crossposted to both T11.5 and IMSS mailing lists. The drafts themselves should be submitted to both organizations. No further discussion. Meeting concluded. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Wed Dec 15 15:06:49 2004 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 PAA03943 for ; Wed, 15 Dec 2004 15:06:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CefYS-0008Q3-GD for imss-web-archive@ietf.org; Wed, 15 Dec 2004 15:15:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CefJ3-0006mZ-Ky; Wed, 15 Dec 2004 14:59:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cef8z-0004wS-Or for imss@megatron.ietf.org; Wed, 15 Dec 2004 14:49:07 -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 OAA02485 for ; Wed, 15 Dec 2004 14:49:03 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CefGu-0007v4-2h for imss@ietf.org; Wed, 15 Dec 2004 14:57:39 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Dec 2004 11:52:11 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBFJm3Vw021565; Wed, 15 Dec 2004 11:48:06 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA14951; Wed, 15 Dec 2004 11:48:02 -0800 (PST) From: Keith McCloghrie Message-Id: <200412151948.LAA14951@cisco.com> To: imss@ietf.org, t11_5@mail.t11.org Date: Wed, 15 Dec 2004 11:48:02 -0800 (PST) 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: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: Keith McCloghrie Subject: [imss] Re: Changes to draft-ietf-imss-fc-fam-mib-00.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: 7bit 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 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 From imss-bounces@ietf.org Wed Dec 15 17:20:20 2004 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 ; 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 ; 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 Message-Id: <200412152207.OAA11079@cisco.com> Subject: Re: [imss] Re: Changes to draft-ietf-imss-fc-fam-mib-00.txt To: kzm@cisco.com (Keith McCloghrie) Date: Wed, 15 Dec 2004 14:07:48 -0800 (PST) In-Reply-To: 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 X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-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 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 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