[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