From owner-ipfc@standards.gadzoox.com Fri Jan 5 08:58:27 2001 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12654 for ; Fri, 5 Jan 2001 08:58:26 -0500 (EST) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id EAA31107 for ipfc-list; Fri, 5 Jan 2001 04:26:43 -0800 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from mercury.lss.emc.com (mercury.eng.emc.com [168.159.40.77]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id EAA31104 for ; Fri, 5 Jan 2001 04:26:38 -0800 Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jan 2001 08:33:00 -0500 Message-ID: <2CE33F05597DD411AAE800D0B769587C010C153F@sryoung.lss.emc.com> From: "blumenau, steven" To: Kevin Gibbons Cc: "'ipfc@standards.gadzoox.com'" Subject: RE: IPFC: Fibre Channel Management Framework Integration MIB requ est Date: Fri, 5 Jan 2001 08:34:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Kevin, I have made the change and it will be in the next version. Steve > -----Original Message----- > From: Kevin Gibbons [mailto:kgibbons@nishansystems.com] > Sent: Sunday, December 17, 2000 8:47 PM > To: blumenau, steven > Cc: 'ipfc@standards.gadzoox.com' > Subject: IPFC: Fibre Channel Management Framework Integration MIB > request > > > Steve, > I would like to request a change to the Simple Name Server table > indexing in the Fibre Channel Management Framework > Integration MIB for the > next revision. This is based on the discussions during the > IETF IP over FC > WG meeting held on 12/12/00. > > The change is to have the table index based on: > > INDEX { fcConnUnitId, fcConnUnitSnsPortName} > > instead of: > > INDEX { fcConnUnitId, fcConnUnitSnsPortIndex, > fcConnUnitSnsPortIdentifier } > > Since the fcConnUnitSnsPortName is guaranteed to be > unique by Fibre > Channel standards for each entry in the name server, even > across multiple > SANs, it lends itself well to being an index. > > In attempting to implement the table, with the > fcConnUnitSnsPortIndex and fcConnUnitSnsPortIdentifier, it can be a > challenge. When a port record is added, you do not know if > it previously > had an index from a previous period it was present in the > SAN, unless the > removed entries are maintained so the SnsPortName can be > compared to the new > entry. This is not a problem if you do not want to keep the > SnsPortIndex > constant for a single device over time, but if you do not the > value of it is > greatly diminished. > > If the index of the table is on fcConnUnitSnsPortName, > the problem > is eliminated. All methods recommended for accessing the > table in the MIB > are maintained, with access based on the fcConnUnitSnsPortName greatly > eased. > > Regards, Kevin > > ------ Snipped from draft-ietf-ipfc-fcmgmt-int-mib-05.txt > --------------- > > -- the Fibre Channel Simple Name Server table > -- > -- The Fibre Channel Simple Name Server table contains an entry > -- for each device presently known to this connUnit. There will > -- not be any version on this since FC-GS3 does not define a > -- version today. > -- > -- This table is accessed either directly if the management > -- software has an index value or via GetNexts. The value of > -- the indexes are not required to be contiguous. Each entry > -- created in this table will be assigned an index. This > -- relationship is kept persistent until the entry is removed > -- from the table or the system is reset. The total number of > -- entries are defined by the size of the table > > fcConnUnitSnsMaxEntry OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The maximum number of entries in the table." > ::= { fcMgmtConfig 9 } > Blumenau [Page 42] > > INTERNET-DRAFT FC Mgmt Integration MIB Nov 24, 2000 > > fcConnUnitSnsTable OBJECT-TYPE > SYNTAX SEQUENCE OF FcConnUnitSnsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table contains an entry for each object > registered with this port in the switch." > ::= { fcMgmtSNS 1 } > > fcConnUnitSnsEntry OBJECT-TYPE > SYNTAX fcConnUnitSnsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The Simple Name Server table for the port > represented by fcConnUnitSnsPortIndex ." > INDEX { fcConnUnitId, fcConnUnitSnsPortIndex, > fcConnUnitSnsPortIdentifier } > ::= { fcConnUnitSnsTable 1 } > > fcConnUnitSnsEntry ::= > SEQUENCE { > fcConnUnitSnsId OCTET STRING, > fcConnUnitSnsPortIndex Counter32, > fcConnUnitSnsPortIdentifier FcAddressId, > fcConnUnitSnsPortName FcNameId, > fcConnUnitSnsNodeName FcNameId, > fcConnUnitSnsClassOfSvc OCTET STRING, > fcConnUnitSnsNodeIPAddress OCTET STRING, > fcConnUnitSnsProcAssoc OCTET STRING, > fcConnUnitSnsFC4Type OCTET STRING, > fcConnUnitSnsPortType OCTET STRING, > fcConnUnitSnsPortIPAddress OCTET STRING, > fcConnUnitSnsFabricPortName FcNameId, > fcConnUnitSnsHardAddress FcAddressId, > fcConnUnitSnsSymbolicPortName DisplayString, > fcConnUnitSnsSymbolicNodeName DisplayString > } > > fcConnUnitSnsId OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (16)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The connUnitId of the connectivity unit > that contains this Name Server table." > ::= { fcConnUnitSnsEntry 1 } > > fcConnUnitSnsPortIndex OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The physical port number of this SNS table entry. > Each physical port has an SNS table with 1-n entries > > ----------------------------------------- > Kevin Gibbons > Nishan Systems, Inc. > (408) 519-3756 > kgibbons@NishanSystems.com > ----------------------------------------- > From owner-ipfc@standards.gadzoox.com Fri Jan 5 12:45:15 2001 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17762 for ; Fri, 5 Jan 2001 12:45:14 -0500 (EST) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA31272 for ipfc-list; Fri, 5 Jan 2001 08:15:56 -0800 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id IAA31269 for ; Fri, 5 Jan 2001 08:15:49 -0800 Received: from kgibbons (adsl-63-196-7-187.dsl.snfc21.pacbell.net [63.196.7.187]) by server1.NishanSystems.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id YGDLYD0X; Fri, 5 Jan 2001 09:20:19 -0800 From: "Kevin Gibbons" To: "blumenau, steven" Cc: Subject: RE: IPFC: Fibre Channel Management Framework Integration MIB request Date: Fri, 5 Jan 2001 09:10:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <2CE33F05597DD411AAE800D0B769587C010C153F@sryoung.lss.emc.com> Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Steve, thanks much. The Fibre Channel Management Framework Integration MIB has come a long way. I look forward to seeing the next version. Regards, Kevin -----Original Message----- From: blumenau, steven [mailto:blumenau_steven@emc.com] Sent: Friday, January 05, 2001 5:34 AM To: Kevin Gibbons Cc: 'ipfc@standards.gadzoox.com' Subject: RE: IPFC: Fibre Channel Management Framework Integration MIB request Kevin, I have made the change and it will be in the next version. Steve > -----Original Message----- > From: Kevin Gibbons [mailto:kgibbons@nishansystems.com] > Sent: Sunday, December 17, 2000 8:47 PM > To: blumenau, steven > Cc: 'ipfc@standards.gadzoox.com' > Subject: IPFC: Fibre Channel Management Framework Integration MIB > request > > > Steve, > I would like to request a change to the Simple Name Server table > indexing in the Fibre Channel Management Framework > Integration MIB for the > next revision. This is based on the discussions during the > IETF IP over FC > WG meeting held on 12/12/00. > > The change is to have the table index based on: > > INDEX { fcConnUnitId, fcConnUnitSnsPortName} > > instead of: > > INDEX { fcConnUnitId, fcConnUnitSnsPortIndex, > fcConnUnitSnsPortIdentifier } > > Since the fcConnUnitSnsPortName is guaranteed to be > unique by Fibre > Channel standards for each entry in the name server, even > across multiple > SANs, it lends itself well to being an index. > > In attempting to implement the table, with the > fcConnUnitSnsPortIndex and fcConnUnitSnsPortIdentifier, it can be a > challenge. When a port record is added, you do not know if > it previously > had an index from a previous period it was present in the > SAN, unless the > removed entries are maintained so the SnsPortName can be > compared to the new > entry. This is not a problem if you do not want to keep the > SnsPortIndex > constant for a single device over time, but if you do not the > value of it is > greatly diminished. > > If the index of the table is on fcConnUnitSnsPortName, > the problem > is eliminated. All methods recommended for accessing the > table in the MIB > are maintained, with access based on the fcConnUnitSnsPortName greatly > eased. > > Regards, Kevin > > ------ Snipped from draft-ietf-ipfc-fcmgmt-int-mib-05.txt > --------------- > > -- the Fibre Channel Simple Name Server table > -- > -- The Fibre Channel Simple Name Server table contains an entry > -- for each device presently known to this connUnit. There will > -- not be any version on this since FC-GS3 does not define a > -- version today. > -- > -- This table is accessed either directly if the management > -- software has an index value or via GetNexts. The value of > -- the indexes are not required to be contiguous. Each entry > -- created in this table will be assigned an index. This > -- relationship is kept persistent until the entry is removed > -- from the table or the system is reset. The total number of > -- entries are defined by the size of the table > > fcConnUnitSnsMaxEntry OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The maximum number of entries in the table." > ::= { fcMgmtConfig 9 } > Blumenau [Page 42] > > INTERNET-DRAFT FC Mgmt Integration MIB Nov 24, 2000 > > fcConnUnitSnsTable OBJECT-TYPE > SYNTAX SEQUENCE OF FcConnUnitSnsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table contains an entry for each object > registered with this port in the switch." > ::= { fcMgmtSNS 1 } > > fcConnUnitSnsEntry OBJECT-TYPE > SYNTAX fcConnUnitSnsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The Simple Name Server table for the port > represented by fcConnUnitSnsPortIndex ." > INDEX { fcConnUnitId, fcConnUnitSnsPortIndex, > fcConnUnitSnsPortIdentifier } > ::= { fcConnUnitSnsTable 1 } > > fcConnUnitSnsEntry ::= > SEQUENCE { > fcConnUnitSnsId OCTET STRING, > fcConnUnitSnsPortIndex Counter32, > fcConnUnitSnsPortIdentifier FcAddressId, > fcConnUnitSnsPortName FcNameId, > fcConnUnitSnsNodeName FcNameId, > fcConnUnitSnsClassOfSvc OCTET STRING, > fcConnUnitSnsNodeIPAddress OCTET STRING, > fcConnUnitSnsProcAssoc OCTET STRING, > fcConnUnitSnsFC4Type OCTET STRING, > fcConnUnitSnsPortType OCTET STRING, > fcConnUnitSnsPortIPAddress OCTET STRING, > fcConnUnitSnsFabricPortName FcNameId, > fcConnUnitSnsHardAddress FcAddressId, > fcConnUnitSnsSymbolicPortName DisplayString, > fcConnUnitSnsSymbolicNodeName DisplayString > } > > fcConnUnitSnsId OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (16)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The connUnitId of the connectivity unit > that contains this Name Server table." > ::= { fcConnUnitSnsEntry 1 } > > fcConnUnitSnsPortIndex OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The physical port number of this SNS table entry. > Each physical port has an SNS table with 1-n entries > > ----------------------------------------- > Kevin Gibbons > Nishan Systems, Inc. > (408) 519-3756 > kgibbons@NishanSystems.com > ----------------------------------------- > From owner-ipfc@standards.gadzoox.com Thu Jan 11 09:17:54 2001 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01548 for ; Thu, 11 Jan 2001 09:17:54 -0500 (EST) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id EAA02127 for ipfc-list; Thu, 11 Jan 2001 04:39:04 -0800 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from bbmail1-out.unisys.com (bbmail1-out.unisys.com [192.63.108.40]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id EAA02124 for ; Thu, 11 Jan 2001 04:39:00 -0800 Received: from us-bb-gtwy-2.bb.unisys.com (us-bb-gtwy-2.bb.unisys.com [192.63.78.152]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id NAA28904 for ; Thu, 11 Jan 2001 13:43:02 GMT Received: by us-bb-gtwy-2.bb.unisys.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 08:48:29 -0500 Message-ID: From: "Weber, William L" To: "IPFC Mailing List (E-mail)" Subject: Question about WW_NN and RFC 2625 Date: Thu, 11 Jan 2001 08:48:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk I have a question concerning RFC 2625, IP and ARP over Fibre Channel, and Network_Address_Authority (NAA) of World Wide Names (WWN). I thought this would be the proper forum to present the question. The question is: Can the Node WWN (WW_NN) use NAA=5 for IEEE registered format and still be compliant/compatible with RFC 2625? I understand that the RFC 2625 requires the Port WWN (WW_PN) to use NAA = 1 for IEEE 48-bit addresses. RFC 2625 does not explicitly state the NAA for the WW_NN, however the examples in Appendix E (i.e. E.4.2) show the WW_NN with NAA=1. Thanks, // Bill Weber Phone: +1-610-648-7022 // Unisys Corporation Fax: +1-610-648-4010 // 2476 Swedesford Rd. mailto:William.Weber@unisys.com // Malvern, PA 19355-9700 From owner-ipfc@standards.gadzoox.com Thu Jan 11 11:36:39 2001 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07116 for ; Thu, 11 Jan 2001 11:36:38 -0500 (EST) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id HAA02271 for ipfc-list; Thu, 11 Jan 2001 07:01:46 -0800 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id HAA02268 for ; Thu, 11 Jan 2001 07:01:40 -0800 Received: from emulex.com (jinfantepc.emulex.com [138.239.96.81]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id IAA23789; Thu, 11 Jan 2001 08:10:58 -0800 (PST) Message-ID: <3A5DDB8E.637091D3@emulex.com> Date: Thu, 11 Jan 2001 08:13:02 -0800 From: "Infante, Jon" Organization: Emulex Corporation X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Weber, William L" CC: "IPFC Mailing List (E-mail)" Subject: Re: Question about WW_NN and RFC 2625 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Bill, My understanding is that only the World Wide Port Name requires NAA = 1. It is not a requirement for the World Wide Node Name to have NAA = 1; Jon Infante Emulex "Weber, William L" wrote: > I have a question concerning RFC 2625, IP and ARP over Fibre Channel, and > Network_Address_Authority (NAA) of World Wide Names (WWN). I thought this > would be the proper forum to present the question. > The question is: > Can the Node WWN (WW_NN) use NAA=5 for IEEE registered format and still > be > compliant/compatible with RFC 2625? > > I understand that the RFC 2625 requires the Port WWN (WW_PN) to use NAA = 1 > for IEEE 48-bit addresses. RFC 2625 does not explicitly state the NAA for > the WW_NN, however the examples in Appendix E (i.e. E.4.2) show the WW_NN > with NAA=1. > > Thanks, > // Bill Weber Phone: +1-610-648-7022 > // Unisys Corporation Fax: +1-610-648-4010 > // 2476 Swedesford Rd. mailto:William.Weber@unisys.com > // Malvern, PA 19355-9700 From owner-ipfc@standards.gadzoox.com Thu Jan 11 19:48:29 2001 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16879 for ; Thu, 11 Jan 2001 19:48:28 -0500 (EST) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id PAA02500 for ipfc-list; Thu, 11 Jan 2001 15:16:24 -0800 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id PAA02497 for ; Thu, 11 Jan 2001 15:16:16 -0800 Received: from emulex.com (jinfantepc.emulex.com [138.239.96.81]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id QAA03788; Thu, 11 Jan 2001 16:25:47 -0800 (PST) Message-ID: <3A5E4F86.21BE36B2@emulex.com> Date: Thu, 11 Jan 2001 16:27:50 -0800 From: "Infante, Jon" Organization: Emulex Corporation X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Murali Rajagopal CC: "Weber, William L" , "IPFC Mailing List (E-mail)" Subject: Re: Question about WW_NN and RFC 2625 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Murali, I disagree. The Fibre Channel Network header ONLY contains the WWPN. That is the main reason the NAA for the WWPN must be 1 (mapping MAC addresses to WWPNs). Correct me if I'm wrong. however, I don't see any technical reason for the WWNN NAA to be 1 nor did I infer that was the intent of the many discussions the group had on this topic??? Jon Murali Rajagopal wrote: > The intent was NAA=1 for both. > If it did not get reflected, then it was an oversight. > > -Murali > > -----Original Message----- > From: owner-ipfc@standards.gadzoox.com > [mailto:owner-ipfc@standards.gadzoox.com]On Behalf Of Infante, Jon > Sent: Thursday, January 11, 2001 8:13 AM > To: Weber, William L > Cc: IPFC Mailing List (E-mail) > Subject: Re: Question about WW_NN and RFC 2625 > > Bill, > > My understanding is that only the World Wide Port Name requires NAA = 1. > It is not a requirement for the World Wide Node Name to have NAA = 1; > > Jon Infante > Emulex > > "Weber, William L" wrote: > > > I have a question concerning RFC 2625, IP and ARP over Fibre Channel, and > > Network_Address_Authority (NAA) of World Wide Names (WWN). I thought this > > would be the proper forum to present the question. > > The question is: > > Can the Node WWN (WW_NN) use NAA=5 for IEEE registered format and still > > be > > compliant/compatible with RFC 2625? > > > > I understand that the RFC 2625 requires the Port WWN (WW_PN) to use NAA = > 1 > > for IEEE 48-bit addresses. RFC 2625 does not explicitly state the NAA for > > the WW_NN, however the examples in Appendix E (i.e. E.4.2) show the WW_NN > > with NAA=1. > > > > Thanks, > > // Bill Weber Phone: +1-610-648-7022 > > // Unisys Corporation Fax: +1-610-648-4010 > > // 2476 Swedesford Rd. mailto:William.Weber@unisys.com > > // Malvern, PA 19355-9700