Re: [Ipoverib] Comments on the latest IPoIB-CM draft
Vivek Kashyap <kashyapv@us.ibm.com> Wed, 19 October 2005 06:35 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES7XV-0002aB-S5; Wed, 19 Oct 2005 02:35:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES7XS-0002Vj-RC for ipoverib@megatron.ietf.org; Wed, 19 Oct 2005 02:35:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24470 for <ipoverib@ietf.org>; Wed, 19 Oct 2005 02:34:51 -0400 (EDT)
Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES7j5-0000Qr-Qq for ipoverib@ietf.org; Wed, 19 Oct 2005 02:47:05 -0400
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9J6YlfN027531 for <ipoverib@ietf.org>; Wed, 19 Oct 2005 02:34:47 -0400
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9J6Ylb5527910 for <ipoverib@ietf.org>; Wed, 19 Oct 2005 00:34:47 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j9J6YlJV023891 for <ipoverib@ietf.org>; Wed, 19 Oct 2005 00:34:47 -0600
Received: from sig-9-65-39-77.mts.ibm.com (sig-9-65-39-77.mts.ibm.com [9.65.39.77]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j9J6Yk2v023872; Wed, 19 Oct 2005 00:34:46 -0600
Date: Tue, 18 Oct 2005 23:24:12 -0700
From: Vivek Kashyap <kashyapv@us.ibm.com>
X-X-Sender: kashyapv@localhost.localdomain
To: "H.K. Jerry Chu" <Jerry.Chu@eng.sun.com>
Subject: Re: [Ipoverib] Comments on the latest IPoIB-CM draft
In-Reply-To: <200510181812.j9IICF5f611564@jurassic.eng.sun.com>
Message-ID: <Pine.LNX.4.62.0510182255130.6070@localhost.localdomain>
References: <200510181812.j9IICF5f611564@jurassic.eng.sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: ipoverib@ietf.org
X-BeenThere: ipoverib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=unsubscribe>
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>
Sender: ipoverib-bounces@ietf.org
Errors-To: ipoverib-bounces@ietf.org
On Tue, 18 Oct 2005, H.K. Jerry Chu wrote: > Vivek, Jerry, Thanks for the detailed comments. I'll incorporate and resend the draft. Some responses below. > > The following is a list of my comments on > draft-ietf-ipoib-connected-mode-01.txt, many are editorial. > > 1) Line 27 > "Internet- Drafts" => > "Internet-Drafts". yep > > 2) Line 48 > "This document specifies a method" => > "This document specifies an optional method" > > Suggest to spell out the "optional" part up front. ok > > 3) Line 92 > Remove the non-ASCII character. Puzzling. Am using text editor on Linux (vi) and nroff. Will remove it. > > 4) Various places in the draft has paragraphs describing IPoIB-CM > as if it were an independent transport mechansim for IPoIB that > is separate from IPoIB-UD. If the draft simply states upfront that > IPoIB-CM is an extension (or add-on) to IPoIB-UD, many paragraphs > become redudant and can be removed. E.g. paragraphs beginning at > line 161, section 2.1, most of sec 2.2. Line 313 to 319, 516-518, > ...etc. The idea is to delineate the differences between the option -CM and the required -UD mode. However, I'll relook at the wording. > > 5) <nit> The first five lines of 2.2 may give an impression that > one QP may be used to connect to all remote nodes. ok..will make that clearer. > > 6) Continue from 4) and 5) above, sections 2.2 and 2.3 may be > combined as follows. > > Every IPoIB-CM interface MUST have two sets of QPs associated with it: > > 1) An unreliable datagram mode QP > 2) one or more connected mode QPs > > [IPoIB_UD] describes how a node can obtain 1) and, through the address > resolution procedure, a remote node's link-layer address. Once the > latter is known, an IB connection must be setup between the nodes > before any IP communication may occur over an IB connected transport. > > [continue from line 226.] agreed..though one reason for going into more detail is to make sure the whole process is understood w/o any ambiguity. > > 7) Line 291, why not simply say the QPN is the same as the one from > [IPoIB-UD] to avoid any confusion? ok.. > > 8) Line 350, change > "The IB connection is setup using the Service-ID as defined above." > to > "The IB connection is setup using the Service-ID as defined in 3.5 > below." ok > > 9) Line 317 contains garbled characters (looks like apostrophe), so > does line 331, 373, 375, 377, 386. must be character set problem...need to verify and fix. > > 10) Line 377, 378 > QP => QPN ok > > 11) Line 383 change > "To ensure that two IB connections are not setup between the peers" > => > "To ensure that two IB connections are not setup between the peers > due to REQ crossing" ok > > 12) [nit] Section 3.3 should spell out how to numerically compare 20 > byte link-layer address. ok > > 13) Section 3.4, add a stronger statement > "IB connections created though IPoIB-CM are considered part of > an IPoIB-CM interface. As such, they SHOULD be torn down when an > IPoIB-CM interface is torn down. > yes, good suggestion. > 14) Section 3.5 the paragraph > "The Reserved fields MUST be transmitted as zeroes. It is > dependent on the CM to ignore or check for zeroes in the > Reserved fields. This is because some implementations of CMs > require all ServiceIDs to be explicitly specified and cannot > listen to a range of values." > sounds awkward. If we allow implementations to either check for > zeros or ignore on the listening side, we might as well not to say > nothing. ok.. > > 15) Section 4.0 > Do we expect ARP/RARP to be sent through IB connections ever? > If not it should say so in section 7.0 and remove ARP/RARP from > the table to avoid any confusion. ok..will remove. > > 16) Section 7.0 > Need to clarify ARP/RARP over IB connections. E.g., ARP reply > is unicast. Can it be sent back through an IB connection? (Suggest > no.) will do. yes, agree on the 'no'. Vivek > > > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib
- [Ipoverib] Comments on the latest IPoIB-CM draft H.K. Jerry Chu
- Re: [Ipoverib] Comments on the latest IPoIB-CM dr… Vivek Kashyap