From exim@www1.ietf.org Fri Apr 9 08:13:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24496 for ; Fri, 9 Apr 2004 08:13:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBusL-0005NU-7J for imss-archive@odin.ietf.org; Fri, 09 Apr 2004 08:12:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39CCnLt020672 for imss-archive@odin.ietf.org; Fri, 9 Apr 2004 08:12:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBusL-0005NL-3e for imss-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 08:12:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24461 for ; Fri, 9 Apr 2004 08:12:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBusJ-0006LB-00 for imss-web-archive@ietf.org; Fri, 09 Apr 2004 08:12:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBuqe-0006Dj-00 for imss-web-archive@ietf.org; Fri, 09 Apr 2004 08:11:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBupe-00065R-00 for imss-web-archive@ietf.org; Fri, 09 Apr 2004 08:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBupc-0005Hj-2l; Fri, 09 Apr 2004 08:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBuos-0005FH-4k for imss@optimus.ietf.org; Fri, 09 Apr 2004 08:09:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24344 for ; Fri, 9 Apr 2004 08:09:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBuoo-00060E-00 for imss@ietf.org; Fri, 09 Apr 2004 08:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBunp-0005s1-00 for imss@ietf.org; Fri, 09 Apr 2004 08:08:10 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BBumU-0005e3-00 for imss@ietf.org; Fri, 09 Apr 2004 08:06:46 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i39C5nr28796 for ; Fri, 9 Apr 2004 07:05:53 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1690HZPX>; Fri, 9 Apr 2004 14:05:47 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503FD6B26@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Imss (E-mail)" Date: Fri, 9 Apr 2004 14:05:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [imss] FW: Last Call: 'Transmission of IPv6 Packets over Fibre Channel' to Proposed Standard Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Here are some last minute comments/questions that we got from one of the IPv6 WG chairs. Can you send an answer please. Thanks, Bert -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net] Sent: donderdag 8 april 2004 18:53 To: Wijnen, Bert (Bert); cds@andiamo.com Cc: Thomas Narten; Margaret Wasserman (E-mail); Bob Hinden Subject: Re: Last Call: 'Transmission of IPv6 Packets over Fibre Channel' to Proposed Standard Hi All, I just have a few comments/questions on this draft. On the whole, it looks good to me. 1. Section 2.3 - Can all of the defined Optional Headers appear in a single frame? Does that affect the ability to support the minimum MTU of 1280? 2. Section 3, 5th bullet - Why is the receive data size minimized at 1024 octets? I would think that this should be 1280 for IPv6, and that doesn't include any Optional Headers. 3. Section 6 - I would think that this section needs to at least say that the rules defined in RFC 2462 should be followed. And any variations from that document need to be explicitly stated here. 4. Section 9 - Again a mention of 1024 octets rather than 1280. 5. Section A - Can a node determine in which mode each port is working in? If so, should the NDP behavior be different between p2p, loop, and fabric mode? Thanks, Brian _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Mon Apr 12 18:13:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19116 for ; Mon, 12 Apr 2004 18:13:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD9fz-0007BA-73 for imss-archive@odin.ietf.org; Mon, 12 Apr 2004 18:13:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CMDBle027596 for imss-archive@odin.ietf.org; Mon, 12 Apr 2004 18:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD9fq-00079A-Jf for imss-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 18:13:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19052 for ; Mon, 12 Apr 2004 18:12:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD9fn-0006uf-00 for imss-web-archive@ietf.org; Mon, 12 Apr 2004 18:12:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD9Bg-0004wB-00 for imss-web-archive@ietf.org; Mon, 12 Apr 2004 17:41:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD8kk-00033H-00 for imss-web-archive@ietf.org; Mon, 12 Apr 2004 17:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD8kj-0004aM-Ob; Mon, 12 Apr 2004 17:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD8kD-0004X2-Ti for imss@optimus.ietf.org; Mon, 12 Apr 2004 17:13:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15048 for ; Mon, 12 Apr 2004 17:13:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD8kB-00030K-00 for imss@ietf.org; Mon, 12 Apr 2004 17:13:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD8LH-0001E5-00 for imss@ietf.org; Mon, 12 Apr 2004 16:47:45 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BD7xo-0007FT-00 for imss@ietf.org; Mon, 12 Apr 2004 16:23:28 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 12:32:55 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3CKMq2O010972; Mon, 12 Apr 2004 13:22:52 -0700 (PDT) Received: from cds-w2k04.cisco.com (dhcp-171-71-49-107.cisco.com [171.71.49.107]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id ARF19071; Mon, 12 Apr 2004 13:21:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20040412122002.022ec0e0@mira-sjcd-1.cisco.com> X-Sender: cds@mira-sjcd-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Apr 2004 13:22:50 -0700 To: Brian Haberman From: Claudio DeSanti Cc: "Wijnen, Bert (Bert)" , Thomas Narten , "Margaret Wasserman (E-mail)" , Bob Hinden , imss@ietf.org In-Reply-To: <40758383.5010805@innovationslab.net> References: <200404071213.i37CDoT06951@cichlid.raleigh.ibm.com> <200404071213.i37CDoT06951@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [imss] Re: Last Call: 'Transmission of IPv6 Packets over Fibre Channel' to Proposed Standard Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Brian, thanks for your review. My replies are in-line. Please tell me if they solve your issues. Thanks, Claudio. At 12:53 PM 4/8/2004 -0400, Brian Haberman wrote: >Hi All, > >I just have a few comments/questions on this draft. On the whole, >it looks good to me. > >1. Section 2.3 - Can all of the defined Optional Headers appear in > a single frame? Does that affect the ability to support the minimum > MTU of 1280? Yes, No. An important characteristic that differentiates Fibre Channel from other technologies is that it maps an IPv6 packet to a sequence of frames, not to a single frame, as explained in section 2.4. An IPv6 packet is called Information Unit in fibre channel terminology. Size requirements on IPv6 are then information unit requirements on Fibre Channel. An information unit is mapped by Fibre Channel to a sequence of frames, not to a single frame, and this explain, among the other things, how the default MTU for IPv6 over FC is 65280 octets, while the maximum frame payload size is 2112 octets. The information unit to sequence mapping is performed by Fibre Channel and is transparent to IPv6. The usage of optional header is specific to each protocol mapped over Fibre Channel. Most optional headers are per information unit (which means they are present only on the first frame of a sequence), while others are per frame (which means they are present in each frame of a sequence). For IPv6, section 4 of this document specifies that the Network_Header MUST be used with the LLC/SNAP header, that the ESP_Header MAY be used, and that other types of optional headers MUST NOT be used. The ESP_Header is a per frame optional header, and as such it is transparent to the size of the original information unit. Then the requirement to support the minimum IPv6 MTU of 1280 octets translates in the requirement to support an information unit at least 1304 octets long (bullet 4 in section 3), which is 1280 (IPv6) + 16 (Network_Header) + 8 (LLC/SNAP header). See also figure 2. >2. Section 3, 5th bullet - Why is the receive data size minimized at > 1024 octets? I would think that this should be 1280 for IPv6, and > that doesn't include any Optional Headers. This is a frame size requirement, not an information unit requirement. As explained in section 2.2, fourth paragraph, before effective communication is possible between two Nx_Ports, a port login has to be performed, to exchange operational parameters. A critical parameters for the sequencing mechanism is the maximum frame size that may be received by an Nx_Port. When this parameter is known, an information unit will be segmented in a sequence of frames, each of them not bigger than the maximum receive data field size. So this requirement does not limit the size of an information unit. This requirement is needed for multicast/broadcast data transmission. For unicast communication an explicit login may be performed, i.e., an exchange of frames carrying the Nx_Ports' operational parameters. For broadcast transmission it is no possible to perform an explicit login, and then the login has to be implicit, so with parameters known "a priori", i.e., set by this specification. 1024 is a receive data field size that accommodates any current implementation, and this is the reason why it has been chosen. The requirement is carefully worded as a SHOULD, because if in a particular environment the network administrator knows that all the involved Nx_Ports are capable to support a bigger receive data field size, it may configure them accordingly. The only real requirement, as explained in section 9, second paragraph, is that the chosen parameter MUST be equal across all the IPv6 communicating Nx_Ports. >3. Section 6 - I would think that this section needs to at least say > that the rules defined in RFC 2462 should be followed. And any > variations from that document need to be explicitly stated here. Section 6 is all about following the RFC 2462 rules, and that RFC is referenced in the third paragraph of section 6.1. If we want to make this more explicit, that paragraph may be reworded as follows: "Stateless address autoconfiguration MUST be performed as specified in [ACONF]. An IPv6 Address Prefix used for stateless address autoconfiguration of an Nx_Port MUST have a length of 64 bits." >4. Section 9 - Again a mention of 1024 octets rather than 1280. See my reply to point 2. >5. Section A - Can a node determine in which mode each port is working > in? If so, should the NDP behavior be different between p2p, loop, > and fabric mode? An Nx_Port always determines in which mode it is working, p2p, loop or fabric, but all of that is transparent to the upper layer. The Neighbor Discovery behavior is the same across the three topologies. >Thanks, >Brian _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Wed Apr 14 11:11:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00196 for ; Wed, 14 Apr 2004 11:11:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDluG-0006cA-OR for imss-archive@odin.ietf.org; Wed, 14 Apr 2004 11:02:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EF2Spn025426 for imss-archive@odin.ietf.org; Wed, 14 Apr 2004 11:02:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlm4-0004tN-Rv for imss-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 10:54:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28995 for ; Wed, 14 Apr 2004 10:53:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlm2-00009b-00 for imss-web-archive@ietf.org; Wed, 14 Apr 2004 10:53:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDll7-00004b-00 for imss-web-archive@ietf.org; Wed, 14 Apr 2004 10:53:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDlkG-0007la-00 for imss-web-archive@ietf.org; Wed, 14 Apr 2004 10:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDleL-0003f0-EY; Wed, 14 Apr 2004 10:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDla8-0002pQ-PG for imss@optimus.ietf.org; Wed, 14 Apr 2004 10:41:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28504 for ; Wed, 14 Apr 2004 10:41:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDla6-0006SH-00 for imss@ietf.org; Wed, 14 Apr 2004 10:41:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlZ7-0006Kf-00 for imss@ietf.org; Wed, 14 Apr 2004 10:40:38 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BDlYC-00067B-00 for imss@ietf.org; Wed, 14 Apr 2004 10:39:40 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3EEd3V25780 for ; Wed, 14 Apr 2004 09:39:04 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1690KTSG>; Wed, 14 Apr 2004 16:39:02 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155041241D5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" Cc: "Imss (E-mail)" , cds@andiamo.com Date: Wed, 14 Apr 2004 16:39:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [imss] FW: COMMENT: draft-ietf-imss-ipv6-over-fibre-channel-01 Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I received this comment from IESG review from Russ Housley: COMMENT Section 4.1 does a good job of pointing out that layer 2 and layer 3 security protocols can be used. This information should be repeated in the security considerations. > > The FC ESP_Header [FC-FS] MAY be used to secure the FC frames > composing the FC Sequence. [AH] or [ESP] may be used to provide > security at the IPv6 layer. Other types of FC Optional Header MUST > NOT be used in an IPv6 FC Sequence. > It would be nice to expand on this discussion in the security considerations section, especially in the area of layer 2 security since [FC-FS] is not as easy to obtain as an RFC. Can Claudio pls suggest a pragraph to be added to the security section? If it is not too big, I may be able to do it as an RFC-Editor note. Bert _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Wed Apr 14 14:32:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13378 for ; Wed, 14 Apr 2004 14:32:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoyr-0002O3-BU for imss-archive@odin.ietf.org; Wed, 14 Apr 2004 14:19:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EIJPMS009170 for imss-archive@odin.ietf.org; Wed, 14 Apr 2004 14:19:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDosj-0000GK-7r for imss-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 14:13:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12228 for ; Wed, 14 Apr 2004 14:13:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDosg-0005MK-00 for imss-web-archive@ietf.org; Wed, 14 Apr 2004 14:13:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDorq-0005KS-00 for imss-web-archive@ietf.org; Wed, 14 Apr 2004 14:12:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDoqz-0005IM-00 for imss-web-archive@ietf.org; Wed, 14 Apr 2004 14:11:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDok1-00066H-7x; Wed, 14 Apr 2004 14:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoX0-0002DF-5i for imss@optimus.ietf.org; Wed, 14 Apr 2004 13:50:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10710 for ; Wed, 14 Apr 2004 13:50:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDoWx-0003k4-00 for imss@ietf.org; Wed, 14 Apr 2004 13:50:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoW1-0003dM-00 for imss@ietf.org; Wed, 14 Apr 2004 13:49:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDoUt-0003Se-00 for imss@ietf.org; Wed, 14 Apr 2004 13:48:28 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Apr 2004 09:58:19 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3EHll2W016607; Wed, 14 Apr 2004 10:47:55 -0700 (PDT) Received: from cds-w2k04.cisco.com (dhcp-171-71-186-110.cisco.com [171.71.186.110]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id ARH11987; Wed, 14 Apr 2004 10:45:02 -0700 (PDT) Message-Id: <4.3.2.7.2.20040414103100.02c92e80@mira-sjcd-1.cisco.com> X-Sender: cds@mira-sjcd-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Apr 2004 10:46:47 -0700 To: "Wijnen, Bert (Bert)" From: Claudio DeSanti Cc: "Imss (E-mail)" In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155041241D5@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [imss] Re: FW: COMMENT: draft-ietf-imss-ipv6-over-fibre-channel-01 Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Bert, I would rewrite the security considerations section as follows: IPv6 does not introduce any additional security concerns beyond those that already exist within the Fibre Channel protocols. Zoning techniques based on FC Name Server masking (soft zoning) do not work with IPv6, because IPv6 over Fibre Channel does not use the FC Name Server. The FC ESP_Header [FC-FS] may be used to secure the FC frames composing FC Sequences carrying IPv6 packets. All the techniques defined to secure IPv6 traffic at the IPv6 layer may be used in a Fibre Channel environment. I don't think it would be appropriate to expand more this section on the ESP_Header. FC-FS is the base specification of Fibre Channel, is well known to everybody involved with Fibre Channel, and may be easily obtained from the T11 web site. Thanks, Claudio. At 04:39 PM 4/14/2004 +0200, Wijnen, Bert (Bert) wrote: >I received this comment from IESG review from Russ Housley: > > COMMENT > > Section 4.1 does a good job of pointing out that layer 2 and layer 3 > security protocols can be used. This information should be repeated > in the security considerations. > > > > The FC ESP_Header [FC-FS] MAY be used to secure the FC frames > > composing the FC Sequence. [AH] or [ESP] may be used to provide > > security at the IPv6 layer. Other types of FC Optional Header MUST > > NOT be used in an IPv6 FC Sequence. > > > It would be nice to expand on this discussion in the security > considerations > section, especially in the area of layer 2 security since [FC-FS] is > not as > easy to obtain as an RFC. > >Can Claudio pls suggest a pragraph to be added to the security section? > >If it is not too big, I may be able to do it as an RFC-Editor note. > >Bert _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Fri Apr 16 16:59:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09306 for ; Fri, 16 Apr 2004 16:59:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaEn-0001Vr-Jw for imss-archive@odin.ietf.org; Fri, 16 Apr 2004 16:47:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GKl1rM005795 for imss-archive@odin.ietf.org; Fri, 16 Apr 2004 16:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZxp-0001T8-VL for imss-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 16:29:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05782 for ; Fri, 16 Apr 2004 16:29:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEZxo-0005J4-5T for imss-web-archive@ietf.org; Fri, 16 Apr 2004 16:29:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZws-0005FD-00 for imss-web-archive@ietf.org; Fri, 16 Apr 2004 16:28:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEZw1-0005AB-00 for imss-web-archive@ietf.org; Fri, 16 Apr 2004 16:27:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZEu-0006os-4w; Fri, 16 Apr 2004 15:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZ94-00058e-Mk for imss@optimus.ietf.org; Fri, 16 Apr 2004 15:37:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01056; Fri, 16 Apr 2004 15:37:00 -0400 (EDT) Message-Id: <200404161937.PAA01056@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: imss@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 16 Apr 2004 15:37:00 -0400 Subject: [imss] I-D ACTION:draft-ietf-imss-ipv6-over-fibre-channel-02.txt Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF. Title : Transmission of IPv6 Packets over Fibre Channel Author(s) : C. Desanti Filename : draft-ietf-imss-ipv6-over-fibre-channel-02.txt Pages : 24 Date : 2004-4-16 This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imss-ipv6-over-fibre-channel-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-16154600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-ipv6-over-fibre-channel-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-16154600.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Fri Apr 16 21:13:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25095 for ; Fri, 16 Apr 2004 21:13:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEeKl-0005IU-Bv for imss-archive@odin.ietf.org; Fri, 16 Apr 2004 21:09:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H19RoU020357 for imss-archive@odin.ietf.org; Fri, 16 Apr 2004 21:09:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEeIt-0004Ui-AC for imss-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 21:07:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24793 for ; Fri, 16 Apr 2004 21:07:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEeIq-0000yf-Pl for imss-web-archive@ietf.org; Fri, 16 Apr 2004 21:07:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEeHv-0000vc-00 for imss-web-archive@ietf.org; Fri, 16 Apr 2004 21:06:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEeHS-0000tG-00 for imss-web-archive@ietf.org; Fri, 16 Apr 2004 21:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEeDa-0002sP-6z; Fri, 16 Apr 2004 21:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEe6G-0000pC-Dg for imss@optimus.ietf.org; Fri, 16 Apr 2004 20:54:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23941 for ; Fri, 16 Apr 2004 20:54:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEe6D-00001S-OG for imss@ietf.org; Fri, 16 Apr 2004 20:54:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEe5J-0007kU-00 for imss@ietf.org; Fri, 16 Apr 2004 20:53:30 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BEe4W-0007bB-00 for imss@ietf.org; Fri, 16 Apr 2004 20:52:40 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2004 17:01:49 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3H0q97t025565; Fri, 16 Apr 2004 17:52:09 -0700 (PDT) Received: from cds-w2k04.cisco.com (dhcp-171-71-186-104.cisco.com [171.71.186.104]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id ARJ61732; Fri, 16 Apr 2004 17:50:23 -0700 (PDT) Message-Id: <4.3.2.7.2.20040416170048.02a6ee28@mira-sjcd-1.cisco.com> X-Sender: cds@mira-sjcd-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Apr 2004 17:52:06 -0700 To: imss@ietf.org From: Claudio DeSanti Cc: bwijnen@lucent.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [imss] New revision of the IPv6 over Fibre Channel draft Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi all, I released revision -02 of the IPv6 over Fibre Channel specification to resolve the comments received from the IESG review. Here is a summary of the comments with the relative resolutions. Thanks for the review, Claudio. ------------ Russ Housley: Comment: [2004-04-12] Section 4.1 does a good job of pointing out that layer 2 and layer 3 security protocols can be used. This information should be repeated in the security considerations. > > The FC ESP_Header [FC-FS] MAY be used to secure the FC frames > composing the FC Sequence. [AH] or [ESP] may be used to provide > security at the IPv6 layer. Other types of FC Optional Header MUST > NOT be used in an IPv6 FC Sequence. > It would be nice to expand on this discussion in the security considerations section, especially in the area of layer 2 security since [FC-FS] is not as easy to obtain as an RFC. Resolution: Improved the security considerations section, by changing: Server. All the techniques defined to secure IPv6 traffic may be used in a Fibre Channel Environment. in: Server. The FC ESP_Header [FC-FS] may be used to secure the FC frames composing FC Sequences carrying IPv6 packets. All the techniques defined to secure IPv6 traffic at the IPv6 layer may be used in a Fibre Channel environment. Allison Mankin: Comment: [2004-04-14] I couldn't decide whether to make this a blocking comment, hence the record of a cleared Discuss. Does this ND actually work? Section 9 says the solicited-node address is mapped to broadcast, so there's a scaling question. Appendix B has a discussion related to validating the Neighbor Solicitation information which is unreadable, because of unexplained acronyms from the FC specs, but which suggests there are complications. Resolution: in Fibre Channel we need to use broadcast, because there is no standardized way to perform distribution of multicasts. Instead there are mechanisms to limit the distribution of broadcasts to only the involved nodes, and so this is not a scaling issue. Appendix B has nothing to do with validating the Neighbor Solicitation information, instead it describes informatively a normal procedure each Fibre Channel port should perform when certain events occur, independently from IPv6. The sentence in section 9 which may lead to think that the Neighbor Solicitation information has to be verified has been improved, by changing: are required to resolve an IPv6 unicast address. The fact that the N_Port_ID is volatile implies that the mapping between N_Port_Name and N_Port_ID MUST be valid before use. Appendix B discusses the validation process. in: are required to resolve an IPv6 unicast address. The fact that the N_Port_ID is volatile implies that an Nx_Port MUST validate the mapping between its N_Port_Name and N_Port_ID when certain Fibre Channel events occur (see Appendix B). Michael Patton: Comment: [2004-04-14] In section 3, it might be nice if they explained why only those specific N_Port_Name formats. This restriction is mentioned elsewhere as well. Given how much explanation of the underlying technology they have in Section 2, this oversight seems odd. After all, they laid the groundwork for all the other things on the list. I did see some explanation in 6.1, with details in the rest of section 6, so the simple fix is just a forward reference from Section 3 to Section 6. Although mentioning the restriction and why it's acceptable a little earlier than section 3 might be nice. Resolution: added a reference, by changing: - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats is outside the scope of this specification; in: - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF (see section 6.1). IPv6 support for other Name_Identifier formats is outside the scope of this specification; Comment: The last paragraph of Section 5 talks about "mixed media" but everywhere else the document seems to imply that FC is one media. So, I don't see what the heck this paragraph is about. Either it's spurious and should be removed, or better explanation of what they're talking about is needed. Resolution: added some media examples, by changing: For correct operation when mixed media are bridged together, the smallest MTU of all the media must be advertised by routers in an MTU option. If there are no routers present, this MTU must be manually configured in each node which is connected to a medium with a default MTU larger than the smallest MTU. in: For correct operation when mixed media (e.g., Ethernet and Fibre Channel) are bridged together, the smallest MTU of all the media must be advertised by routers in an MTU option. If there are no routers present, this MTU must be manually configured in each node which is connected to a medium with a default MTU larger than the smallest MTU. Comment: Simple typos: - First paragraph of intro has a comma that makes the grouping wrong. The comma at least should be removed, but even better would be to reword the single sentence paragraph as several sentences. - 4.1 "resulting to the" => "resulting in the" Resolution: corrected the typos. Brian Haberman: Comment: [2004-04-08] Section 6 - I would think that this section needs to at least say that the rules defined in RFC 2462 should be followed. And any variations from that document need to be explicitly stated here. Resolution: Section 6 is all about following the RFC 2462 rules, and that RFC is referenced in the third paragraph of section 6.1. Improved that paragraph, by changing: An IPv6 Address Prefix used for stateless address autoconfiguration [ACONF] of an Nx_Port MUST have a length of 64 bits. in: Stateless address autoconfiguration MUST be performed as specified in [ACONF]. An IPv6 Address Prefix used for stateless address autoconfiguration of an Nx_Port MUST have a length of 64 bits. From me: [2004-04-01] By checking the references, I found that the most updated document to refer for the LLC-SNAP header definition is: IEEE Std 802-2001, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture". instead than: IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, 1985. The current reference: [IEEE-LLC] IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, 1985. has been replaced by: [IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture". Finally, I updated my contact information with the Cisco address. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Fri Apr 16 22:52:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29665 for ; Fri, 16 Apr 2004 22:52:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEfvl-0000bq-Vh for imss-archive@odin.ietf.org; Fri, 16 Apr 2004 22:51:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H2pjr6002336 for imss-archive@odin.ietf.org; Fri, 16 Apr 2004 22:51:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEfse-0007wQ-TS for imss-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 22:48:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29397 for ; Fri, 16 Apr 2004 22:48:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEfsb-00003v-Ay for imss-web-archive@ietf.org; Fri, 16 Apr 2004 22:48:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEfrf-000007-00 for imss-web-archive@ietf.org; Fri, 16 Apr 2004 22:47:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEfqi-0007kD-00 for imss-web-archive@ietf.org; Fri, 16 Apr 2004 22:46:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEfkU-0005tp-WE; Fri, 16 Apr 2004 22:40:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEfi0-0004s0-U2 for imss@optimus.ietf.org; Fri, 16 Apr 2004 22:37:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29039 for ; Fri, 16 Apr 2004 22:37:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEfhx-0007Dp-Hl for imss@ietf.org; Fri, 16 Apr 2004 22:37:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEfh0-0007As-00 for imss@ietf.org; Fri, 16 Apr 2004 22:36:31 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BEfg7-00074G-00 for imss@ietf.org; Fri, 16 Apr 2004 22:35:35 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Apr 2004 18:45:56 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3H2Z47t021434; Fri, 16 Apr 2004 19:35:05 -0700 (PDT) Received: from cds-w2k04.cisco.com (dhcp-171-71-186-104.cisco.com [171.71.186.104]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id ARJ66126; Fri, 16 Apr 2004 19:33:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20040416191742.02c5d3b0@mira-sjcd-1.cisco.com> X-Sender: cds@mira-sjcd-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Apr 2004 19:35:03 -0700 To: imss@ietf.org From: Claudio DeSanti Cc: bwijnen@lucent.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [imss] Other comments Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 There are few other comments, which I forgot to mention in the previous mail, because they did not go into the document. Thanks, Claudio. ---------- From Michael Patton: >As previously mentioned, I'd like to see a general description of what >FC is. As far as I can tell, this document describes a mesh which >supports port-to-port unicast and broadcast (with a comment about >optional multicast). I'm a bit worried that the architecture >described is N-squared requiring every node to maintain a separate >connection to every other node and manage state for that connection >(called Exchanges in the FC lingo). This is a general problem of mesh >topologies, so I'm not sure there's much that can be done, but I'd >like to see a mention of this aspect. Hopefully, FC fabrics will be >able to handle that quantity of Exchanges. Furthermore, it explicitly >disclaims as "outside the scope of this document" the techniques for >dealing with that. Response: Section 2 is aimed to describe what Fibre Channel is. There may be scalability issues in this architecture, but the goal of this draft is simply to define how to carry IPv6 over this technology. >The acronym ESP applies both at the FC layer and the IPv6 layer. What >it means at the FC layer is not explained (nor is its meaning at the >IPv6 layer, but I know that one). From context it seems reasonable to >assume that they are, in fact, similar, but that should be mentioned. >Now, given my assumption that they are similar, I see them both >mentioned in section 4.1, mentioning that either may be used for >security. Yet, there is no discussion, either in that section or in >the Security Considerations section, of what the tradeoffs are for >choosing one or the other. [I actually know, but think it should be >explicitly stated in the document somewhere.] Response: The security considerations section has been improved in response to Russ Housley's comment. Being this a specification for how to carry IPv6 over this technology, the important point to say are that every security method defined for IPv6 may be used also in this environment. What Fibre Channel may offer in terms of security is still partially under development. From Brian Haberman: > Section 2.3 - Can all of the defined Optional Headers appear in > a single frame? Does that affect the ability to support the minimum > MTU of 1280? Response: Yes, No. An important characteristic that differentiates Fibre Channel from other technologies is that it maps an IPv6 packet to a sequence of frames, not to a single frame, as explained in section 2.4. An IPv6 packet is called Information Unit in fibre channel terminology. Size requirements on IPv6 are then information unit requirements on Fibre Channel. An information unit is mapped by Fibre Channel to a sequence of frames, not to a single frame, and this explain, among the other things, how the default MTU for IPv6 over FC is 65280 octets, while the maximum frame payload size is 2112 octets. The information unit to sequence mapping is performed by Fibre Channel and is transparent to IPv6. The usage of optional header is specific to each protocol mapped over Fibre Channel. Most optional headers are per information unit (which means they are present only on the first frame of a sequence), while others are per frame (which means they are present in each frame of a sequence). For IPv6, section 4 of this document specifies that the Network_Header MUST be used with the LLC/SNAP header, that the ESP_Header MAY be used, and that other types of optional headers MUST NOT be used. The ESP_Header is a per frame optional header, and as such it is transparent to the size of the original information unit. Then the requirement to support the minimum IPv6 MTU of 1280 octets translates in the requirement to support an information unit at least 1304 octets long (bullet 4 in section 3), which is 1280 (IPv6) + 16 (Network_Header) + 8 (LLC/SNAP header). See also figure 2. > Section 3, 5th bullet - Why is the receive data size minimized at > 1024 octets? I would think that this should be 1280 for IPv6, and > that doesn't include any Optional Headers. Response: This is a frame size requirement, not an information unit requirement. As explained in section 2.2, fourth paragraph, before effective communication is possible between two Nx_Ports, a port login has to be performed, to exchange operational parameters. A critical parameters for the sequencing mechanism is the maximum frame size that may be received by an Nx_Port. When this parameter is known, an information unit will be segmented in a sequence of frames, each of them not bigger than the maximum receive data field size. So this requirement does not limit the size of an information unit. This requirement is needed for multicast/broadcast data transmission. For unicast communication an explicit login may be performed, i.e., an exchange of frames carrying the Nx_Ports' operational parameters. For broadcast transmission it is no possible to perform an explicit login, and then the login has to be implicit, so with parameters known "a priori", i.e., set by this specification. 1024 is a receive data field size that accommodates any current implementation, and this is the reason why it has been chosen. The requirement is carefully worded as a SHOULD, because if in a particular environment the network administrator knows that all the involved Nx_Ports are capable to support a bigger receive data field size, it may configure them accordingly. The only real requirement, as explained in section 9, second paragraph, is that the chosen parameter MUST be equal across all the IPv6 communicating Nx_Ports. > Section A - Can a node determine in which mode each port is working > in? If so, should the NDP behavior be different between p2p, loop, > and fabric mode? Response: An Nx_Port always determines in which mode it is working, p2p, loop or fabric, but all of that is transparent to the upper layer. The Neighbor Discovery behavior is the same across the three topologies. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Mon Apr 19 17:47:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12676 for ; Mon, 19 Apr 2004 17:47:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgXe-0007r4-V6 for imss-archive@odin.ietf.org; Mon, 19 Apr 2004 17:43:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JLh2k5030190 for imss-archive@odin.ietf.org; Mon, 19 Apr 2004 17:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgTT-0007A8-FB for imss-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 17:38:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12273 for ; Mon, 19 Apr 2004 17:38:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFgTR-0000JZ-0B for imss-web-archive@ietf.org; Mon, 19 Apr 2004 17:38:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFgST-00003U-00 for imss-web-archive@ietf.org; Mon, 19 Apr 2004 17:37:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFgRv-0007aG-00 for imss-web-archive@ietf.org; Mon, 19 Apr 2004 17:37:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgK4-00056d-Ow; Mon, 19 Apr 2004 17:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgFa-000408-UH for imss@optimus.ietf.org; Mon, 19 Apr 2004 17:24:23 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11536 for ; Mon, 19 Apr 2004 17:24:19 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BFg6k-00028n-J3; Mon, 19 Apr 2004 17:15:14 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , imss mailing list , imss chair Message-Id: Date: Mon, 19 Apr 2004 17:15:14 -0400 Subject: [imss] Protocol Action: 'Transmission of IPv6 Packets over Fibre Channel' to Proposed Standard Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved the following document: - 'Transmission of IPv6 Packets over Fibre Channel ' as a Proposed Standard This document is the product of the Internet and Management Support for Storage Working Group. The IESG contact persons are Bert Wijnen and David Kessens. Technical Summary This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. Working Group Summary The initial WG Last Call resulted in a number (19) of Editorial comments and 2 Technical comments. The technical comments were as follows: - Use of a default large MTU size (65280 octets) for IPv6 over Fibre Channel, which far exceeds the message sizes typically used in the Internet. As a result, an explanation has been added with additional guidance. See section 5. - An inconsistency in the format of the Source/Target Link-layer Address option (used with Neighbor Discovery Protocol). This has been corrected in the 01 revision. - Further changes were made because of IESG review which resulted in revision 02. The working group has consensus to publish revision 02 of this document as a standards track RFC. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman and Bert Wijnen. Additional/explicit review was also requested from the IPv6 Working Group. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Wed Apr 28 15:31:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11284 for ; Wed, 28 Apr 2004 15:31:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIucJ-0007Xa-GD for imss-archive@odin.ietf.org; Wed, 28 Apr 2004 15:21:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SJLB2k028983 for imss-archive@odin.ietf.org; Wed, 28 Apr 2004 15:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuVp-00055L-NC for imss-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 15:14:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09410 for ; Wed, 28 Apr 2004 15:14:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuVm-0000tE-VT for imss-web-archive@ietf.org; Wed, 28 Apr 2004 15:14:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuUs-0000qx-00 for imss-web-archive@ietf.org; Wed, 28 Apr 2004 15:13:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIuUG-0000oy-00 for imss-web-archive@ietf.org; Wed, 28 Apr 2004 15:12:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuNd-0001Bl-5O; Wed, 28 Apr 2004 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuFK-00027J-Uz for imss@optimus.ietf.org; Wed, 28 Apr 2004 14:57:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07556 for ; Wed, 28 Apr 2004 14:57:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuFG-0007Pq-N3 for imss@ietf.org; Wed, 28 Apr 2004 14:57:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuEM-0007KH-00 for imss@ietf.org; Wed, 28 Apr 2004 14:56:27 -0400 Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1BIuDQ-0007BQ-00; Wed, 28 Apr 2004 14:55:29 -0400 Received: from hq-ex-11.corp.brocade.com (hq-ex-11 [192.168.38.58]) by blasphemy.brocade.com (Postfix) with ESMTP id D4A2F14152; Wed, 28 Apr 2004 11:54:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Apr 2004 11:54:59 -0700 Message-ID: <191DA4FAE235D24C9BCC8D50F6B17AB90933B6@hq-ex-11.brocade.com> Thread-Topic: DRAFT: Proposal to remove "dynamic" port type for FcPortType: DRAFT Thread-Index: AcQskqCVLCR/mzvDQn6Q2Jjb6vN9NgAvb4zA From: "Robert Snively" To: Cc: "T11_5 (E-mail)" , "T11_3 (E-mail)" , , "Robert Snively" Content-Transfer-Encoding: quoted-printable Subject: [imss] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I apologize for the cross posting, but the breadth of expert knowledge and breadth of responsibility for this particular=20 subject extends across all four reflectors. The history is: Snively: Proposed including: gPort glPort fnlPort Proposed removing: dynamic Because: All known "dynamic" ports are either G_Ports or GL_Ports (which dynamically change to F_ or E_Ports) or F/NL_Ports (which provides fabric services when no FL_Port is available). All other ports (if known) are "other",=20 whether dynamic or not. McCloghrie: Agreed to add: gPort glPort fnlPort =09 Proposed retaining: dynamic Because: There might be some future ports defined that had mechanisms that would select the final port type using previously undefined mechanisms. In a sense, this was a future proofing. Crandall: Proposed removing: dynamic Because: Unless some clear definition of the port were created or referenced in a standard, it was equivalent to "unknown". My final proposal would be: Remove: dynamic Because: There is no referent for a "dynamic" port. =20 Further explanation: All Fibre Channel Ports have an associated type. That type is determined absolutely either by the port being set to or=20 designed to be compliant with a particular type or by=20 being designed as a specified type of multi-function port that uses a certain standard algorithm to determine which port type will be agreed upon. Ports with knowable types (as opposed to "unknown" types)=20 that do not behave according to those rules are "other" and might as well be labeled as such. Future revisions of a MIB may add additional types to the list as new port types are defined or may use other mechanisms (manufacturer and model) to define the actual use of an "other" port until such changes can be made in the MIB. Note that PortType does not tell everything there is to know about a port. As an example, FcPortType nPort may be implemented as an FCP SCSI initiator port, an FCP SCSI target port, or an IPv6 over SCSI port, none of which is presently defined in the MIB. Similarly E_Ports may have different capabilities such as trunking that are not presently defined in the MIB. Many of these capabilities are also dynamic, requiring negotiations and login operations to actually enable them. However, these capabilities do NOT define a different port type. =20 I believe there are probably a number of solutions to the "future proofing" suggestion that do not require us to make up a definition for a port type. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Thu Apr 29 19:21:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10287 for ; Thu, 29 Apr 2004 19:21:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKeX-00061K-Ie for imss-archive@odin.ietf.org; Thu, 29 Apr 2004 19:09:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TN9DOV023142 for imss-archive@odin.ietf.org; Thu, 29 Apr 2004 19:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKa9-0004sG-Hp for imss-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 19:04:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09403 for ; Thu, 29 Apr 2004 19:04:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKa1-0006K5-4X for imss-web-archive@ietf.org; Thu, 29 Apr 2004 19:04:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKZ2-0006HF-00 for imss-web-archive@ietf.org; Thu, 29 Apr 2004 19:03:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKYq-0006ED-00 for imss-web-archive@ietf.org; Thu, 29 Apr 2004 19:03:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKPq-0003EU-I2; Thu, 29 Apr 2004 18:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKEm-0001Dy-Gn for imss@optimus.ietf.org; Thu, 29 Apr 2004 18:42:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08474 for ; Thu, 29 Apr 2004 18:42:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKEe-00052V-6q for imss@ietf.org; Thu, 29 Apr 2004 18:42:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKDi-0004zL-00 for imss@ietf.org; Thu, 29 Apr 2004 18:41:31 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BJKD0-0004tE-00; Thu, 29 Apr 2004 18:40:46 -0400 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TMeFW9017778; Thu, 29 Apr 2004 15:40:16 -0700 (PDT) Received: (from kzm@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA12461; Thu, 29 Apr 2004 15:40:05 -0700 (PDT) From: Keith McCloghrie Message-Id: <200404292240.PAA12461@cypher.cisco.com> To: rsnively@Brocade.COM (Robert Snively) Date: Thu, 29 Apr 2004 15:40:05 -0700 (PDT) Cc: ips@ietf.org, t11_5@mail.t11.org ("T11_5 (E-mail)"), t11_3@mail.t11.org ("T11_3 (E-mail)"), imss@ietf.org, rsnively@Brocade.COM (Robert Snively) In-Reply-To: <191DA4FAE235D24C9BCC8D50F6B17AB90933B6@hq-ex-11.brocade.com> from "Robert Snively" at Apr 28, 2004 11:54:59 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [imss] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bob, Thanks for raising this. I believe that as editor, I do need the WG's approval to make any additions or deletions to: draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. So, if the WG approves the addition of these three recently-defined new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the FcPortType TC, then I can go ahead and add them. As regards 'dynamic': - it is obviously needed in the MIB's current state (to represent G_Ports, GL_Ports and F/NL_Ports), and if the WG decided to defer the addition of the three new types, then it would continue to be needed. - to characterize the retention of 'dynamic' as unnecessary "future proofing" is to ignore history. Specifically, 'dynamic' was defined in the original version of the draft-ietf-ips-fcmgmt-mib, more than two years ago, and hindsight shows us that was a smart move, because (as I said above) it is needed in the MIB's current state, it would continue to be needed if we deferred adding the three new types, and there are good chances it will be needed yet again in the future, even after we add the three new types. - the first of those good chances is currently being debated in T11 in regard to (virtual-fabric) "trunking". It seems to me that while T11 has not yet reached the stage of debating of whether "trunking" is a characteristic of a port type, it likely is because a result of the layer-2 negotiation (that you mention) will be the port becoming either a trunking port or one of the already-defined values of FcPortType, i.e., it's a type just like the existing ones are. The other (non-)types you mention are completely different because they will not be the subject of a layer-2 negotiation, and thus I agree that those others are not port types at layer-2 (and this is a layer-2 MIB). - and finally, to remove 'dynamic' because: There is no referent for a "dynamic" port. doesn't make any sense to me because there is no referent for an "unknown port" and no referent for an "other port". Since we're not going to throw out 'unknown' or 'other' for this reason, then neither should we throw out 'dyanmic'. Thanks, Keith. > I apologize for the cross posting, but the breadth of expert > knowledge and breadth of responsibility for this particular > subject extends across all four reflectors. > > The history is: > > Snively: > > Proposed including: > gPort > glPort > fnlPort > > Proposed removing: > dynamic > > Because: > All known "dynamic" ports are either G_Ports or > GL_Ports (which dynamically change to F_ or E_Ports) > or F/NL_Ports (which provides fabric services when > no FL_Port is available). > All other ports (if known) are "other", > whether dynamic or not. > > McCloghrie: > > Agreed to add: > gPort > glPort > fnlPort > > Proposed retaining: > dynamic > > Because: > There might be some future ports defined that had > mechanisms that would select the final port type > using previously undefined mechanisms. > In a sense, this was a future proofing. > > Crandall: > > Proposed removing: > dynamic > > Because: > Unless some clear definition of the port were > created or referenced in a standard, it was > equivalent to "unknown". > > My final proposal would be: > > Remove: > dynamic > > Because: > There is no referent for a "dynamic" port. > > Further explanation: > > All Fibre Channel Ports have an associated type. That type > is determined absolutely either by the port being set to or > designed to be compliant with a particular type or by > being designed as a specified type of multi-function port > that uses a certain standard algorithm to determine which > port type will be agreed upon. > > Ports with knowable types (as opposed to "unknown" types) > that do not behave according to those rules are "other" > and might as well be labeled as such. Future revisions > of a MIB may add additional types to the list as new port types > are defined or may use other mechanisms (manufacturer and model) > to define the actual use of an "other" port until such changes > can be made in the MIB. > > Note that PortType does not tell everything there is to know > about a port. As an example, FcPortType nPort may be implemented > as an FCP SCSI initiator port, an FCP SCSI target port, or > an IPv6 over SCSI port, none of which is presently defined in the > MIB. Similarly E_Ports may have different capabilities such > as trunking that are not presently defined in the MIB. Many of > these capabilities are also dynamic, requiring negotiations and > login operations to actually enable them. However, these capabilities > do NOT define a different port type. > > I believe there are probably a number of solutions to the > "future proofing" suggestion that do not require us to > make up a definition for a port type. > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Fri Apr 30 11:55:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10861 for ; Fri, 30 Apr 2004 11:55:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaEb-0005kh-4c for imss-archive@odin.ietf.org; Fri, 30 Apr 2004 11:47:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UFlTnk022108 for imss-archive@odin.ietf.org; Fri, 30 Apr 2004 11:47:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJa86-00055c-Ve for imss-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 11:40:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09798 for ; Fri, 30 Apr 2004 11:40:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJa85-0002i0-VB for imss-web-archive@ietf.org; Fri, 30 Apr 2004 11:40:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJa74-0002YT-00 for imss-web-archive@ietf.org; Fri, 30 Apr 2004 11:39:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJa60-0002PQ-00 for imss-web-archive@ietf.org; Fri, 30 Apr 2004 11:38:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZzf-0002nh-HR; Fri, 30 Apr 2004 11:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZs8-0001HD-8E for imss@optimus.ietf.org; Fri, 30 Apr 2004 11:24:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08185 for ; Fri, 30 Apr 2004 11:24:13 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZs7-00014T-4A for imss@ietf.org; Fri, 30 Apr 2004 11:24:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZrJ-00011r-00 for imss@ietf.org; Fri, 30 Apr 2004 11:23:26 -0400 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1BJZqZ-0000uc-00; Fri, 30 Apr 2004 11:22:39 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 11:22:09 -0400 Message-ID: To: kzm@cisco.com, rsnively@Brocade.COM Cc: ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org Date: Fri, 30 Apr 2004 11:22:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [imss] RE: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 > Thanks for raising this. I believe that as editor, I do need the > WG's approval to make any additions or deletions to: > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. > > So, if the WG approves the addition of these three recently-defined > new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the > FcPortType TC, then I can go ahead and add them. With WG co-chair hat on, unless someone objects to these additions on the list, the editor should assume the that rough consensus of the ips WG is to make these additions. This is a relatively minor change (adds elements to an existing enumeration), and better aligns the MIB with Fibre Channel standards. As to the possible removal of the "dynamic" port type, the issue appears to boil down to whether a "dynamic" type is justified in addition to "other" and "unknown". Let me encourage further comments to focus on this specific issue, and I offer the following advice: - I think Keith is correct that not having a standard to reference is insufficient to remove "dynamic", as this would also entail also removing "other" and "unknown", which does not appear to be a desired outcome. - It would be useful to see an explanation of how "dynamic" improves "future proofing" over and above "other" and "unknown". I think there's rough consensus that some form of "future proofing" is needed, and the disagreement centers on whether "other" and "unknown" are sufficient. The current MIB text is: unknown(1), other(2), -- none of the below dynamic(3), -- determined dynamically where the "below" list contains N, NL, F, FL, E and B ports (and will contain G, GL and FNL ports, assuming no objections to their addition). Note that if we were to remove "dynamic", its value in the enumeration would be reserved in order to avoid renumbering other port types or accidental reuse in the future. Thanks, --David (ips WG co-chair) ---------------------------------------------------- David L. Black, Senior Technologist 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 ---------------------------------------------------- > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of Keith McCloghrie > Sent: Thursday, April 29, 2004 6:40 PM > To: rsnively@Brocade.COM > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; > imss@ietf.org; rsnively@Brocade.COM > Subject: Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType > > > Bob, > > Thanks for raising this. I believe that as editor, I do need the > WG's approval to make any additions or deletions to: > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. > > So, if the WG approves the addition of these three recently-defined > new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the > FcPortType TC, then I can go ahead and add them. > > As regards 'dynamic': > > - it is obviously needed in the MIB's current state (to represent > G_Ports, GL_Ports and F/NL_Ports), and if the WG decided to defer the > addition of the three new types, then it would continue to be needed. > > - to characterize the retention of 'dynamic' as unnecessary "future > proofing" is to ignore history. Specifically, 'dynamic' was > defined in > the original version of the draft-ietf-ips-fcmgmt-mib, more than two > years ago, and hindsight shows us that was a smart move, because (as > I said above) it is needed in the MIB's current state, it would > continue to be needed if we deferred adding the three new types, and > there are good chances it will be needed yet again in the future, even > after we add the three new types. > > - the first of those good chances is currently being debated in T11 in > regard to (virtual-fabric) "trunking". It seems to me that while T11 > has not yet reached the stage of debating of whether "trunking" is a > characteristic of a port type, it likely is because a result of the > layer-2 negotiation (that you mention) will be the port > becoming either > a trunking port or one of the already-defined values of > FcPortType, i.e., > it's a type just like the existing ones are. The other > (non-)types you > mention are completely different because they will not be the subject > of a layer-2 negotiation, and thus I agree that those others are not > port types at layer-2 (and this is a layer-2 MIB). > > - and finally, to remove 'dynamic' because: > > There is no referent for a "dynamic" port. > > doesn't make any sense to me because there is no referent for an > "unknown port" and no referent for an "other port". Since we're not > going to throw out 'unknown' or 'other' for this reason, then neither > should we throw out 'dyanmic'. > > Thanks, > Keith. > > > > I apologize for the cross posting, but the breadth of expert > > knowledge and breadth of responsibility for this particular > > subject extends across all four reflectors. > > > > The history is: > > > > Snively: > > > > Proposed including: > > gPort > > glPort > > fnlPort > > > > Proposed removing: > > dynamic > > > > Because: > > All known "dynamic" ports are either G_Ports or > > GL_Ports (which dynamically change to F_ or E_Ports) > > or F/NL_Ports (which provides fabric services when > > no FL_Port is available). > > All other ports (if known) are "other", > > whether dynamic or not. > > > > McCloghrie: > > > > Agreed to add: > > gPort > > glPort > > fnlPort > > > > Proposed retaining: > > dynamic > > > > Because: > > There might be some future ports defined that had > > mechanisms that would select the final port type > > using previously undefined mechanisms. > > In a sense, this was a future proofing. > > > > Crandall: > > > > Proposed removing: > > dynamic > > > > Because: > > Unless some clear definition of the port were > > created or referenced in a standard, it was > > equivalent to "unknown". > > > > My final proposal would be: > > > > Remove: > > dynamic > > > > Because: > > There is no referent for a "dynamic" port. > > > > Further explanation: > > > > All Fibre Channel Ports have an associated type. That type > > is determined absolutely either by the port being set to or > > designed to be compliant with a particular type or by > > being designed as a specified type of multi-function port > > that uses a certain standard algorithm to determine which > > port type will be agreed upon. > > > > Ports with knowable types (as opposed to "unknown" types) > > that do not behave according to those rules are "other" > > and might as well be labeled as such. Future revisions > > of a MIB may add additional types to the list as new port types > > are defined or may use other mechanisms (manufacturer and model) > > to define the actual use of an "other" port until such changes > > can be made in the MIB. > > > > Note that PortType does not tell everything there is to know > > about a port. As an example, FcPortType nPort may be > implemented > > as an FCP SCSI initiator port, an FCP SCSI target port, or > > an IPv6 over SCSI port, none of which is presently > defined in the > > MIB. Similarly E_Ports may have different capabilities such > > as trunking that are not presently defined in the MIB. Many of > > these capabilities are also dynamic, requiring negotiations and > > login operations to actually enable them. However, > these capabilities > > do NOT define a different port type. > > > > I believe there are probably a number of solutions to the > > "future proofing" suggestion that do not require us to > > make up a definition for a port type. > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Fri Apr 30 13:24:39 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16196 for ; Fri, 30 Apr 2004 13:24:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbhG-0008OV-JJ for imss-archive@odin.ietf.org; Fri, 30 Apr 2004 13:21:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UHLAsw032267 for imss-archive@odin.ietf.org; Fri, 30 Apr 2004 13:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbdS-0007Kh-QI for imss-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 13:17:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15823 for ; Fri, 30 Apr 2004 13:17:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbdQ-0001va-RF for imss-web-archive@ietf.org; Fri, 30 Apr 2004 13:17:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbcX-0001sK-00 for imss-web-archive@ietf.org; Fri, 30 Apr 2004 13:16:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJbbx-0001p0-00 for imss-web-archive@ietf.org; Fri, 30 Apr 2004 13:15:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbXR-0006eR-B4; Fri, 30 Apr 2004 13:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbMw-0004KB-0Y for imss@optimus.ietf.org; Fri, 30 Apr 2004 13:00:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14540 for ; Fri, 30 Apr 2004 13:00:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbMt-0000aQ-Us for imss@ietf.org; Fri, 30 Apr 2004 13:00:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbLy-0000UL-00 for imss@ietf.org; Fri, 30 Apr 2004 12:59:11 -0400 Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1BJbL1-0000Ni-00; Fri, 30 Apr 2004 12:58:11 -0400 Received: from hq-ex-11.corp.brocade.com (hq-ex-11 [192.168.38.58]) by blasphemy.brocade.com (Postfix) with ESMTP id 2CB5F14149; Fri, 30 Apr 2004 09:57:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Apr 2004 09:57:36 -0700 Message-ID: <191DA4FAE235D24C9BCC8D50F6B17AB90933BB@hq-ex-11.brocade.com> Thread-Topic: [Ips] Proposal to remove "dynamic" port type for FcPortType Thread-Index: AcQuOx+GC/+RQNvqQdyVzSqSoeq/mwAlphFw From: "Robert Snively" To: "Keith McCloghrie" Cc: , , , Content-Transfer-Encoding: quoted-printable Subject: [imss] RE: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Using David Black's consensus call, I will focus on=20 the "dynamic" question. I am in agreement with Mike O'Donnell's=20 analysis of "unknown" and "other". I support his conclusions on "dynamic" (i.e. that it should be removed as a port type). Keith McLoughrie indicates that dynamic is useful for future proofing. I believe that the most effective mechanism for future proofing would be to remove "dynamic" as a type, then provide a certain number of pre-specified type values for future assignment by INCITS TC T11 standards. That way, the MIB can remain unchanged and the values be picked up by future T11 standards if they are ever required. The number of such values should be small, since any large number of future variants would probably require modification to the MIB anyway. That allows both for future definition of ports with a=20 negotiation algorithm and ports with a pre-established=20 fixed type, something that "dynamic" does not. Robert Snively Brocade Communications Systems, Inc. 1745 Technology Drive San Jose, CA 95110 +1 408 333 8135 rsnively@brocade.com=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Fri Apr 30 15:16:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24075 for ; Fri, 30 Apr 2004 15:16:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdPO-00068U-LZ for imss-archive@odin.ietf.org; Fri, 30 Apr 2004 15:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UJAoSJ023583 for imss-archive@odin.ietf.org; Fri, 30 Apr 2004 15:10:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJd7Z-0006bP-55 for imss-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 14:52:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22077 for ; Fri, 30 Apr 2004 14:52:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJd7W-0001yl-AF for imss-web-archive@ietf.org; Fri, 30 Apr 2004 14:52:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJd6d-0001u2-00 for imss-web-archive@ietf.org; Fri, 30 Apr 2004 14:51:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJd68-0001pF-00 for imss-web-archive@ietf.org; Fri, 30 Apr 2004 14:50:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJd0Q-0005JG-2Q; Fri, 30 Apr 2004 14:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcxh-0004io-1P for imss@optimus.ietf.org; Fri, 30 Apr 2004 14:42:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21492 for ; Fri, 30 Apr 2004 14:42:07 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcxd-00010B-RC for imss@ietf.org; Fri, 30 Apr 2004 14:42:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcwf-0000vW-00 for imss@ietf.org; Fri, 30 Apr 2004 14:41:11 -0400 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcvg-0000nC-00; Fri, 30 Apr 2004 14:40:08 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 14:39:25 -0400 Message-ID: To: mike.o'donnell@mcdata.com, Black_David@emc.com, kzm@cisco.com, rsnively@Brocade.COM Cc: ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org Date: Fri, 30 Apr 2004 14:39:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [imss] RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME,OFFERS_ETC autolearn=no version=2.60 Mike, I'm trying not to take sides in this discussion. From your message, I understand your view to be that "unknown" and "other" are sufficient to cover all the cases in which the port type is not one of the specific values in the enumeration (N, NL, F, etc.), and hence that "dynamic" should not be part of that enumeration. Consider that view noted. Someone who is in favor of "dynamic" will need to address your question about how it improves future-proofing. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist 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 ---------------------------------------------------- > -----Original Message----- > From: Mike O'Donnell [mailto:mike.o'donnell@mcdata.com] > Sent: Friday, April 30, 2004 12:06 PM > To: Black_David@emc.com; kzm@cisco.com; rsnively@Brocade.COM > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; > imss@ietf.org > Subject: RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" > port type for FcPortType > > > > David, > > I beg to differ... > > >"I think Keith is correct that not having a standard to reference is > > insufficient to remove "dynamic", as this would also entail > > also removing "other" and "unknown", which does not appear to > > be a desired outcome. > > "Other" and "Unknown" are (as is stated) used to indicate > that (for the case of 'other') the agent can determine the > port type and it is NOT any of those types identified in the > MIB. "Unknown" indicates the agent is unable to ascertain > its type (be it any of those identified or other). It is an > accepted mechanism in MIB's to provide an agent a mechanism > to report it as such. > > Based on the above, I don't accept the logic that because > 'other' and 'unknown' are not specified in any standard and > that dynamic is ALSO not specified in any standard then > "other" an "unknown" should also be removed from the MIB. > > As for the use of dynamic, it is my opinion that if the > specified states of a port can be determined (and documented > in the MIB), then dynamic has no value. And, from an > implementor's perspective, if dynamic is added to the MIB, > when does one report "dynamic" versus G-port, GL_port, > FNL_port (or other specified port types)? > > If it is to 'future-proof' the MIB, what does > 'future_port_type' (aka 'dynamic') tell me that 'other' does > not? Help me understand. Maybe someone can point to where > this has been successfully implemented (not just documented) > in other MIBs so we can use this as a model for > future-proofing our FC MIB's. As an application vendor, > "dynamic" doesn't add any additional value as specified today. > > Mike O'Donnell > > ====================== > Michael E. O'Donnell > Director Software Architecture > McDATA Corporation > 4 McDATA Parkway > Broomfield, Colorado 80021 > 720.558.4142 (office) > 303.570.3631 (cel) > mike.o'donnell@mcdata.com > ====================== > > > > > > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, April 30, 2004 9:22 AM > To: kzm@cisco.com; rsnively@Brocade.COM > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; > imss@ietf.org > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType > > > INCITS T11.5 Mail Reflector > ******************************** > > > Thanks for raising this. I believe that as editor, I do need the > > WG's approval to make any additions or deletions to: > > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. > > > > So, if the WG approves the addition of these three recently-defined > > new types: 'gPort', 'glPort' and 'fnlPort' as new > enumerations of the > > FcPortType TC, then I can go ahead and add them. > > With WG co-chair hat on, unless someone objects to these additions > on the list, the editor should assume the that rough consensus of the > ips WG is to make these additions. This is a relatively minor change > (adds elements to an existing enumeration), and better aligns the MIB > with Fibre Channel standards. > > As to the possible removal of the "dynamic" port type, the > issue appears > to boil down to whether a "dynamic" type is justified in addition to > "other" and "unknown". Let me encourage further comments to focus on > this specific issue, and I offer the following advice: > > - I think Keith is correct that not having a standard to reference is > insufficient to remove "dynamic", as this would also entail > also removing "other" and "unknown", which does not appear to > be a desired outcome. > - It would be useful to see an explanation of how "dynamic" improves > "future proofing" over and above "other" and "unknown". I think > there's rough consensus that some form of "future proofing" is > needed, and the disagreement centers on whether "other" and > "unknown" are sufficient. > > The current MIB text is: > unknown(1), > other(2), -- none of the below > dynamic(3), -- determined dynamically > where the "below" list contains N, NL, F, FL, E and B ports (and will > contain G, GL and FNL ports, assuming no objections to their > addition). > > Note that if we were to remove "dynamic", its value in the > enumeration would be reserved in order to avoid renumbering > other port types or accidental reuse in the future. > > Thanks, > --David (ips WG co-chair) > ---------------------------------------------------- > David L. Black, Senior Technologist > 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 > ---------------------------------------------------- > > > -----Original Message----- > > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > > Behalf Of Keith McCloghrie > > Sent: Thursday, April 29, 2004 6:40 PM > > To: rsnively@Brocade.COM > > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; > > imss@ietf.org; rsnively@Brocade.COM > > Subject: Re: [Ips] Proposal to remove "dynamic" port type for > > FcPortType > > > > > > Bob, > > > > Thanks for raising this. I believe that as editor, I do need the > > WG's approval to make any additions or deletions to: > > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. > > > > So, if the WG approves the addition of these three recently-defined > > new types: 'gPort', 'glPort' and 'fnlPort' as new > enumerations of the > > FcPortType TC, then I can go ahead and add them. > > > > As regards 'dynamic': > > > > - it is obviously needed in the MIB's current state (to represent > > G_Ports, GL_Ports and F/NL_Ports), and if the WG decided to > defer the > > addition of the three new types, then it would continue to > be needed. > > > > - to characterize the retention of 'dynamic' as unnecessary "future > > proofing" is to ignore history. Specifically, 'dynamic' was > > defined in > > the original version of the draft-ietf-ips-fcmgmt-mib, more than two > > years ago, and hindsight shows us that was a smart move, because (as > > I said above) it is needed in the MIB's current state, it would > > continue to be needed if we deferred adding the three new types, and > > there are good chances it will be needed yet again in the > future, even > > after we add the three new types. > > > > - the first of those good chances is currently being > debated in T11 in > > regard to (virtual-fabric) "trunking". It seems to me that > while T11 > > has not yet reached the stage of debating of whether "trunking" is a > > characteristic of a port type, it likely is because a result of the > > layer-2 negotiation (that you mention) will be the port > > becoming either > > a trunking port or one of the already-defined values of > > FcPortType, i.e., > > it's a type just like the existing ones are. The other > > (non-)types you > > mention are completely different because they will not be > the subject > > of a layer-2 negotiation, and thus I agree that those others are not > > port types at layer-2 (and this is a layer-2 MIB). > > > > - and finally, to remove 'dynamic' because: > > > > There is no referent for a "dynamic" port. > > > > doesn't make any sense to me because there is no referent for an > > "unknown port" and no referent for an "other port". Since we're not > > going to throw out 'unknown' or 'other' for this reason, > then neither > > should we throw out 'dyanmic'. > > > > Thanks, > > Keith. > > > > > > > I apologize for the cross posting, but the breadth of expert > > > knowledge and breadth of responsibility for this particular > > > subject extends across all four reflectors. > > > > > > The history is: > > > > > > Snively: > > > > > > Proposed including: > > > gPort > > > glPort > > > fnlPort > > > > > > Proposed removing: > > > dynamic > > > > > > Because: > > > All known "dynamic" ports are either G_Ports or > > > GL_Ports (which dynamically change to F_ or E_Ports) > > > or F/NL_Ports (which provides fabric services when > > > no FL_Port is available). > > > All other ports (if known) are "other", > > > whether dynamic or not. > > > > > > McCloghrie: > > > > > > Agreed to add: > > > gPort > > > glPort > > > fnlPort > > > > > > Proposed retaining: > > > dynamic > > > > > > Because: > > > There might be some future ports defined that had > > > mechanisms that would select the final port type > > > using previously undefined mechanisms. > > > In a sense, this was a future proofing. > > > > > > Crandall: > > > > > > Proposed removing: > > > dynamic > > > > > > Because: > > > Unless some clear definition of the port were > > > created or referenced in a standard, it was > > > equivalent to "unknown". > > > > > > My final proposal would be: > > > > > > Remove: > > > dynamic > > > > > > Because: > > > There is no referent for a "dynamic" port. > > > > > > Further explanation: > > > > > > All Fibre Channel Ports have an associated type. That type > > > is determined absolutely either by the port being set to or > > > designed to be compliant with a particular type or by > > > being designed as a specified type of multi-function port > > > that uses a certain standard algorithm to determine which > > > port type will be agreed upon. > > > > > > Ports with knowable types (as opposed to "unknown" types) > > > that do not behave according to those rules are "other" > > > and might as well be labeled as such. Future revisions > > > of a MIB may add additional types to the list as new port types > > > are defined or may use other mechanisms (manufacturer and model) > > > to define the actual use of an "other" port until such changes > > > can be made in the MIB. > > > > > > Note that PortType does not tell everything there is to know > > > about a port. As an example, FcPortType nPort may be > > implemented > > > as an FCP SCSI initiator port, an FCP SCSI target port, or > > > an IPv6 over SCSI port, none of which is presently > > defined in the > > > MIB. Similarly E_Ports may have different capabilities such > > > as trunking that are not presently defined in the MIB. Many of > > > these capabilities are also dynamic, requiring negotiations and > > > login operations to actually enable them. However, > > these capabilities > > > do NOT define a different port type. > > > > > > I believe there are probably a number of solutions to the > > > "future proofing" suggestion that do not require us to > > > make up a definition for a port type. > > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > > > To Unsubscribe: > mailto:t11_5-request@mail.t11.org?subject=unsubscribe > > > SPECIAL NOTICE > > All information transmitted hereby is intended only for the > use of the > addressee(s) named above and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or distribution > of confidential and privileged information is prohibited. If > the reader of > this message is not the intended recipient(s) or the employee > or agent > responsible for delivering the message to the intended recipient, you > are hereby notified that you must not read this transmission and that > disclosure, copying, printing, distribution or use of any of the > information contained in or attached to this transmission is STRICTLY > PROHIBITED. > > Anyone who receives confidential and privileged information > in error should > notify us immediately by telephone and mail the original > message to us at the > above address and destroy all copies. To the extent any > portion of this > communication contains public information, no such restrictions > apply to that information. (gate01) > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Fri Apr 30 18:21:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09457 for ; Fri, 30 Apr 2004 18:21:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgCU-0003Gk-1C for imss-archive@odin.ietf.org; Fri, 30 Apr 2004 18:09:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UM9gRr012561 for imss-archive@odin.ietf.org; Fri, 30 Apr 2004 18:09:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJg4h-0006oh-6u for imss-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 18:01:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07455 for ; Fri, 30 Apr 2004 18:01:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJg4e-00008X-Fx for imss-web-archive@ietf.org; Fri, 30 Apr 2004 18:01:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJg3p-00000o-00 for imss-web-archive@ietf.org; Fri, 30 Apr 2004 18:00:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJg2m-0007gz-00 for imss-web-archive@ietf.org; Fri, 30 Apr 2004 17:59:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfsS-0003LC-CF; Fri, 30 Apr 2004 17:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaYY-00014d-Jh for imss@optimus.ietf.org; Fri, 30 Apr 2004 12:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11658 for ; Fri, 30 Apr 2004 12:08:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaYW-0004hw-JQ for imss@ietf.org; Fri, 30 Apr 2004 12:08:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaXZ-0004bx-00 for imss@ietf.org; Fri, 30 Apr 2004 12:07:07 -0400 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1BJaWi-0004XR-00; Fri, 30 Apr 2004 12:06:12 -0400 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 10:06:26 -0600 Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Fri, 30 Apr 2004 10:06:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Apr 2004 10:06:24 -0600 Message-ID: <95C56F83F771C041B4EC26C4DAEEC942D4B434@MC4EXCH03.mcdata.com> Thread-Topic: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Thread-Index: AcQuxxU67JYgezpLQYyNGB1YSjYWSgAASvkw From: "Mike O'Donnell" To: , , Cc: , , , X-OriginalArrivalTime: 30 Apr 2004 16:06:26.0161 (UTC) FILETIME=[16F5FE10:01C42ECD] Content-Transfer-Encoding: quoted-printable Subject: [imss] RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable David, I beg to differ... >"I think Keith is correct that not having a standard to reference is > insufficient to remove "dynamic", as this would also entail > also removing "other" and "unknown", which does not appear to > be a desired outcome. "Other" and "Unknown" are (as is stated) used to indicate that (for the= case of 'other') the agent can determine the port type and it is NOT any= of those types identified in the MIB. "Unknown" indicates the agent is= unable to ascertain its type (be it any of those identified or other). It= is an accepted mechanism in MIB's to provide an agent a mechanism to= report it as such.=20 Based on the above, I don't accept the logic that because 'other' and= 'unknown' are not specified in any standard and that dynamic is ALSO not= specified in any standard then "other" an "unknown" should also be removed= from the MIB.=20 As for the use of dynamic, it is my opinion that if the specified states of= a port can be determined (and documented in the MIB), then dynamic has no= value. And, from an implementor's perspective, if dynamic is added to the= MIB, when does one report "dynamic" versus G-port, GL_port, FNL_port (or= other specified port types)? If it is to 'future-proof' the MIB, what does 'future_port_type' (aka= 'dynamic') tell me that 'other' does not? Help me understand. Maybe= someone can point to where this has been successfully implemented (not= just documented) in other MIBs so we can use this as a model for= future-proofing our FC MIB's. As an application vendor, "dynamic" doesn't= add any additional value as specified today. Mike O'Donnell =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Michael E. O'Donnell=20 Director Software Architecture=20 McDATA Corporation=20 4 McDATA Parkway=20 Broomfield, Colorado 80021=20 720.558.4142 (office)=20 303.570.3631 (cel)=20 mike.o'donnell@mcdata.com=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, April 30, 2004 9:22 AM To: kzm@cisco.com; rsnively@Brocade.COM Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType INCITS T11.5 Mail Reflector ******************************** > Thanks for raising this. I believe that as editor, I do need the > WG's approval to make any additions or deletions to: > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. >=20 > So, if the WG approves the addition of these three recently-defined=20 > new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the > FcPortType TC, then I can go ahead and add them. With WG co-chair hat on, unless someone objects to these additions on the list, the editor should assume the that rough consensus of the ips WG is to make these additions. This is a relatively minor change (adds elements to an existing enumeration), and better aligns the MIB with Fibre Channel standards. As to the possible removal of the "dynamic" port type, the issue appears to boil down to whether a "dynamic" type is justified in addition to "other" and "unknown". Let me encourage further comments to focus on this specific issue, and I offer the following advice: - I think Keith is correct that not having a standard to reference is insufficient to remove "dynamic", as this would also entail also removing "other" and "unknown", which does not appear to be a desired outcome. - It would be useful to see an explanation of how "dynamic" improves "future proofing" over and above "other" and "unknown". I think there's rough consensus that some form of "future proofing" is needed, and the disagreement centers on whether "other" and "unknown" are sufficient. The current MIB text is: unknown(1), other(2), -- none of the below dynamic(3), -- determined dynamically where the "below" list contains N, NL, F, FL, E and B ports (and will contain G, GL and FNL ports, assuming no objections to their addition). Note that if we were to remove "dynamic", its value in the enumeration would be reserved in order to avoid renumbering other port types or accidental reuse in the future. Thanks, --David (ips WG co-chair) ---------------------------------------------------- David L. Black, Senior Technologist 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 ---------------------------------------------------- > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On=20 > Behalf Of Keith McCloghrie > Sent: Thursday, April 29, 2004 6:40 PM > To: rsnively@Brocade.COM > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org;=20 > imss@ietf.org; rsnively@Brocade.COM > Subject: Re: [Ips] Proposal to remove "dynamic" port type for=20 > FcPortType >=20 >=20 > Bob, >=20 > Thanks for raising this. I believe that as editor, I do need the > WG's approval to make any additions or deletions to: > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. >=20 > So, if the WG approves the addition of these three recently-defined=20 > new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the > FcPortType TC, then I can go ahead and add them. >=20 > As regards 'dynamic': >=20 > - it is obviously needed in the MIB's current state (to represent > G_Ports, GL_Ports and F/NL_Ports), and if the WG decided to defer the > addition of the three new types, then it would continue to be needed. >=20 > - to characterize the retention of 'dynamic' as unnecessary "future > proofing" is to ignore history. Specifically, 'dynamic' was=20 > defined in > the original version of the draft-ietf-ips-fcmgmt-mib, more than two > years ago, and hindsight shows us that was a smart move, because (as > I said above) it is needed in the MIB's current state, it would > continue to be needed if we deferred adding the three new types, and > there are good chances it will be needed yet again in the future, even > after we add the three new types. >=20 > - the first of those good chances is currently being debated in T11 in > regard to (virtual-fabric) "trunking". It seems to me that while T11 > has not yet reached the stage of debating of whether "trunking" is a > characteristic of a port type, it likely is because a result of the > layer-2 negotiation (that you mention) will be the port=20 > becoming either > a trunking port or one of the already-defined values of=20 > FcPortType, i.e., > it's a type just like the existing ones are. The other=20 > (non-)types you > mention are completely different because they will not be the subject > of a layer-2 negotiation, and thus I agree that those others are not > port types at layer-2 (and this is a layer-2 MIB). >=20 > - and finally, to remove 'dynamic' because: >=20 > There is no referent for a "dynamic" port. >=20 > doesn't make any sense to me because there is no referent for an > "unknown port" and no referent for an "other port". Since we're not > going to throw out 'unknown' or 'other' for this reason, then neither > should we throw out 'dyanmic'. >=20 > Thanks, > Keith. >=20 >=20 > > I apologize for the cross posting, but the breadth of expert > > knowledge and breadth of responsibility for this particular=20 > > subject extends across all four reflectors. > >=20 > > The history is: > >=20 > > Snively: > >=20 > > Proposed including: > > gPort > > glPort > > fnlPort > >=20 > > Proposed removing: > > dynamic > >=20 > > Because: > > All known "dynamic" ports are either G_Ports or > > GL_Ports (which dynamically change to F_ or E_Ports) > > or F/NL_Ports (which provides fabric services when > > no FL_Port is available). > > All other ports (if known) are "other",=20 > > whether dynamic or not. > >=20 > > McCloghrie: > >=20 > > Agreed to add: > > gPort > > glPort > > fnlPort > > =09 > > Proposed retaining: > > dynamic > >=20 > > Because: > > There might be some future ports defined that had > > mechanisms that would select the final port type > > using previously undefined mechanisms. > > In a sense, this was a future proofing. > >=20 > > Crandall: > >=20 > > Proposed removing: > > dynamic > >=20 > > Because: > > Unless some clear definition of the port were > > created or referenced in a standard, it was > > equivalent to "unknown". > >=20 > > My final proposal would be: > >=20 > > Remove: > > dynamic > >=20 > > Because: > > There is no referent for a "dynamic" port. =20 > >=20 > > Further explanation: > >=20 > > All Fibre Channel Ports have an associated type. That type > > is determined absolutely either by the port being set to or=20 > > designed to be compliant with a particular type or by=20 > > being designed as a specified type of multi-function port > > that uses a certain standard algorithm to determine which > > port type will be agreed upon. > >=20 > > Ports with knowable types (as opposed to "unknown" types)=20 > > that do not behave according to those rules are "other" > > and might as well be labeled as such. Future revisions > > of a MIB may add additional types to the list as new port types > > are defined or may use other mechanisms (manufacturer and model) > > to define the actual use of an "other" port until such changes > > can be made in the MIB. > > > > Note that PortType does not tell everything there is to know > > about a port. As an example, FcPortType nPort may be=20 > implemented > > as an FCP SCSI initiator port, an FCP SCSI target port, or > > an IPv6 over SCSI port, none of which is presently=20 > defined in the > > MIB. Similarly E_Ports may have different capabilities such > > as trunking that are not presently defined in the MIB. Many of > > these capabilities are also dynamic, requiring negotiations and > > login operations to actually enable them. However,=20 > these capabilities > > do NOT define a different port type. =20 > >=20 > > I believe there are probably a number of solutions to the > > "future proofing" suggestion that do not require us to > > make up a definition for a port type. > >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 To Unsubscribe: mailto:t11_5-request@mail.t11.org?subject=3Dunsubscribe SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent=20 responsible for delivering the message to the intended recipient, you are hereby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY=20 PROHIBITED. Anyone who receives confidential and privileged information in error should= =20 notify us immediately by telephone and mail the original message to us at= the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions=20 apply to that information. (gate01) _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss