[Ipoverib] 56th IETF IPoIB meeting minutes
Hsiao-keng Chu <Jerry.Chu@eng.sun.com> Mon, 14 April 2003 07:17 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26369 for <ipoverib-archive@lists.ietf.org>; Mon, 14 Apr 2003 03:17:39 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7OJ828885; Mon, 14 Apr 2003 03:24:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7MY828767 for <ipoverib@optimus.ietf.org>; Mon, 14 Apr 2003 03:22:34 -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 DAA26250 for <ipoverib@ietf.org>; Mon, 14 Apr 2003 03:14:33 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194yDB-0000J5-00 for ipoverib@ietf.org; Mon, 14 Apr 2003 03:17:05 -0400
Received: from patan.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 194yDA-0000J0-00 for ipoverib@ietf.org; Mon, 14 Apr 2003 03:17:04 -0400
Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA13850; Mon, 14 Apr 2003 01:17:05 -0600 (MDT)
Received: from sr1-ctpe06-01 (sr1-ctpe06-01.Taiwan.Sun.COM [129.158.184.33]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h3E7Gsmq974423; Mon, 14 Apr 2003 00:17:04 -0700 (PDT)
Message-Id: <200304140717.h3E7Gsmq974423@jurassic.eng.sun.com>
Date: Mon, 14 Apr 2003 15:17:03 +0800
From: Hsiao-keng Chu <Jerry.Chu@eng.sun.com>
Reply-To: Hsiao-keng Chu <Jerry.Chu@eng.sun.com>
To: ipoverib@ietf.org
Cc: bill@strahm.net
MIME-Version: 1.0
Content-Type: TEXT/plain; charset="us-ascii"
Content-MD5: Jw1OKBSxq7dm8lZb1Sju1A==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc
Subject: [Ipoverib] 56th IETF IPoIB meeting minutes
Sender: ipoverib-admin@ietf.org
Errors-To: ipoverib-admin@ietf.org
X-BeenThere: ipoverib@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=unsubscribe>
List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
List-Post: <mailto:ipoverib@ietf.org>
List-Help: <mailto:ipoverib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=subscribe>
IP over InfiniBand: 56th IETF San Francisco (3/18/03) - Meeting Minutes Sean Harnedy Vivek Kashyap ================================================================== There were approximately twenty people in attendance at the IPOIB Working Group meeting. Agenda Intro from Working Group Chairs IPoIB MIBs status IPoIB connected mode Wrap up Introduction - Jerry Chu (Sun Microsystems) & Bill Strahm (Sun Microsystems) The co-chairs, Jerry Chu and Bill Strahm, presented the agenda and circulated the blue attendance sheets. Sean Harnedy and Vivek Kashyap volunteered to take the minutes. The co-chairs first introduced the document status. The Protocol drafts, encapsulation, link and multicast, and DHCP, are all up for IESG review and last call comments. The AD (Tom Narten from IBM) is looking into when they will be moved onto the RFC track. IPoIB MIBs Status - Sean Harnedy (InfiniSwitch Corporation) ----------------------------------------------------------- Sean updated the WG on the progress of the MIBs. The primary action item that has happened since the last meeting was that the MIBs were updated to the IBTA 1.1 spec. (The BMA MIB update is still in progress). There has also been a number of guidelines on writing RFCs, Internet-Drafts, and MIB documents that need to be reviewed to be sure the MIBs and the Internet-Drafts are in compliance. After this, more IETF people will check the MIBs and then they can be advanced to Working Group last call before becoming RFCs. There was a discussion of adding new MIBs, but nothing definite was agreed upon at the meeting. Sean asked if anyone had MIB implementation experience to send comments to the mailing list. There was a discussion, largely between Bill & Thomas, on the process of moving the drafts to become RFCs. It was discussed that the 6 drafts may be prioritised and then put on MIB doctor's list. The textual conventions draft is required by all other drafts and hence should be at the head of the list. Before submitting to MIB doctor's list all known problems should be fixed. IPoIB connected mode - Vivek Kashyap (IBM) ------------------------------------------ Vivek presented his draft on IPOIB in Connected Mode (CM). The two types of connected mode proposed were reliable and unreliable. He noted that since unreliable datagram had to be supported by all InfiniBand network entities, the UD discovery (via multicast) already being used could be reused for Connected Mode. The two major benefits of using CM are large MTU and redundancy (using the InfiniBand Automatic Path Recovery feature). It is also more reliable. The actual CM address resolution is a bit more complex and involves 3 phases: UD multicast, the use of Communication Manager (CM REQ, CM REPLY, CM RTU), and then the IP connection. There was also a discussion on the size of the messages. Is even 64K packets too small? At 10X IB is capable of supporting very large MTUs. This is a prime candidate for the use of Connected Mode. The large MTU may make IB more appealing than competing Ethernet technologies. There was a discussion of the use of "cookies" in the address resolution phase. The next version of the draft will specify the QPN of the UD QP used for address resolution. The MTU negotiation was also discussed. There will be a desired MTU and a minimum MTU field. The connection setup will use IB MADs. There will be a Service ID field and a private data field that holds the desired and minimum MTU fields. There was a discussion of PVCs for setting up existing connections. Vivek summarized the draft including benefits of CM and the reuse of UD features (Ethertype field and ARP). The main difference is the IB connection phase with the Communication Manager steps. He asked for questions. One question was what if the CM cannot support desired MTU of 64K? Answer: Connection may be setup with smaller MT. There was a question about the use of Inverse ARP (for creating PVCs). Should this be added to the spec? Vivek said he will release another revision of the draft but suggested that one could avoid Inverse ARP. It was discussed that after fixing some minor comments received on the encapsulation and multicast drafts the drafts be put on working group last call. Vivek will submit the next version of the architecture draft updated as per the latest set of drafts and IB spec 1.1. Jerry and Bill closed the meeting. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib
- [Ipoverib] 56th IETF IPoIB meeting minutes Hsiao-keng Chu