From mailnull@www1.ietf.org Sat Feb 1 00:09:24 2003 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 AAA28945 for ; Sat, 1 Feb 2003 00:09:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h115DEl09552 for ipoverib-archive@odin.ietf.org; Sat, 1 Feb 2003 00:13:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h115DEJ09549 for ; Sat, 1 Feb 2003 00:13:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28941 for ; Sat, 1 Feb 2003 00:08:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1158RJ09480; Sat, 1 Feb 2003 00:08:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1157VJ09451 for ; Sat, 1 Feb 2003 00:07:31 -0500 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28895 for ; Sat, 1 Feb 2003 00:03:10 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04784; Fri, 31 Jan 2003 21:06:42 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1156gVK022678; Fri, 31 Jan 2003 21:06:42 -0800 (PST) Received: from Sun.COM (sr1-usun-02.Eng.Sun.COM [129.144.135.8]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0H9M0000Q675XW@ha1sun-mail1.eng.sun.com>; Fri, 31 Jan 2003 21:06:42 -0800 (PST) Date: Fri, 31 Jan 2003 21:06:41 -0800 From: Kanoj Sarcar To: ipoverib@ietf.org Cc: vivk@us.ibm.com Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E3B55E1.9A7F5BE5@Sun.COM> MIME-version: 1.0 X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Subject: [Ipoverib] IPoIB/DHCP 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, I have an issue with section 2.1 of draft-ietf-ipoib-dhcp-over-infiniband-04.txt. I think it should be reworded to allow the following two formats for the client-id: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ Note that if the 20 byte client identifier does not represent the MAC address of the interface, the type should be 0. The type can be 32 only if the mac address is being used as the identifier. In fact, I doubt the neccesity of specifying the second format, since it represents an unstable address (QPN), which is likely to change whenever a port is rebooted. For the rationale, please see section 9.14 of RFC 2132: "A hardware type of 0 (zero) should be used when the value field contains an identifier other than a hardware address (e.g. a fully qualified domain name)." Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Sat Feb 1 00:10:02 2003 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 AAA28964 for ; Sat, 1 Feb 2003 00:10:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1158RJ09480; Sat, 1 Feb 2003 00:08:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1157VJ09451 for ; Sat, 1 Feb 2003 00:07:31 -0500 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28895 for ; Sat, 1 Feb 2003 00:03:10 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04784; Fri, 31 Jan 2003 21:06:42 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1156gVK022678; Fri, 31 Jan 2003 21:06:42 -0800 (PST) Received: from Sun.COM (sr1-usun-02.Eng.Sun.COM [129.144.135.8]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0H9M0000Q675XW@ha1sun-mail1.eng.sun.com>; Fri, 31 Jan 2003 21:06:42 -0800 (PST) Date: Fri, 31 Jan 2003 21:06:41 -0800 From: Kanoj Sarcar To: ipoverib@ietf.org Cc: vivk@us.ibm.com Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E3B55E1.9A7F5BE5@Sun.COM> MIME-version: 1.0 X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Subject: [Ipoverib] IPoIB/DHCP 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi, I have an issue with section 2.1 of draft-ietf-ipoib-dhcp-over-infiniband-04.txt. I think it should be reworded to allow the following two formats for the client-id: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ Note that if the 20 byte client identifier does not represent the MAC address of the interface, the type should be 0. The type can be 32 only if the mac address is being used as the identifier. In fact, I doubt the neccesity of specifying the second format, since it represents an unstable address (QPN), which is likely to change whenever a port is rebooted. For the rationale, please see section 9.14 of RFC 2132: "A hardware type of 0 (zero) should be used when the value field contains an identifier other than a hardware address (e.g. a fully qualified domain name)." Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon Feb 3 13:54:21 2003 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 NAA17233 for ; Mon, 3 Feb 2003 13:54:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IuHJ15141; Mon, 3 Feb 2003 13:56:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13ItBJ15022 for ; Mon, 3 Feb 2003 13:55:11 -0500 Received: from rwcrmhc51.attbi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17105 for ; Mon, 3 Feb 2003 13:49:34 -0500 (EST) Received: from mobilebill (12-211-30-155.client.attbi.com[12.211.30.155]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003020318530905100hut98e>; Mon, 3 Feb 2003 18:53:09 +0000 From: "bill" To: Date: Mon, 3 Feb 2003 10:52:43 -0800 Message-ID: <000701c2cbb5$72e47890$6501a8c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Ipoverib] FW: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003) 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A friendly reminder of the Internet cutoff dates for the March meeting in San Francisco. If you are planning on creating or updating a draft for the meeting, make sure your draft is in long before the cutoff date, otherwise it will not post until after the meeting. Thank you Bill Strahm -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] On Behalf Of Internet-Drafts Administrator Sent: Monday, February 03, 2003 4:08 AM To: IETF-Announce: Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003) NOTE: There are two (2) Internet-Draft Cutoff dates February 24th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, February 24th, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, February 24th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of February 24th will NOT be accepted. March 3rd: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, March 3rd, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_56.html _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon Feb 3 13:54:22 2003 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 NAA17243 for ; Mon, 3 Feb 2003 13:54:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13IxRn15403 for ipoverib-archive@odin.ietf.org; Mon, 3 Feb 2003 13:59:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IxRJ15400 for ; Mon, 3 Feb 2003 13:59:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17201 for ; Mon, 3 Feb 2003 13:53:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IuHJ15141; Mon, 3 Feb 2003 13:56:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13ItBJ15022 for ; Mon, 3 Feb 2003 13:55:11 -0500 Received: from rwcrmhc51.attbi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17105 for ; Mon, 3 Feb 2003 13:49:34 -0500 (EST) Received: from mobilebill (12-211-30-155.client.attbi.com[12.211.30.155]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003020318530905100hut98e>; Mon, 3 Feb 2003 18:53:09 +0000 From: "bill" To: Date: Mon, 3 Feb 2003 10:52:43 -0800 Message-ID: <000701c2cbb5$72e47890$6501a8c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Ipoverib] FW: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003) 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A friendly reminder of the Internet cutoff dates for the March meeting in San Francisco. If you are planning on creating or updating a draft for the meeting, make sure your draft is in long before the cutoff date, otherwise it will not post until after the meeting. Thank you Bill Strahm -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] On Behalf Of Internet-Drafts Administrator Sent: Monday, February 03, 2003 4:08 AM To: IETF-Announce: Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003) NOTE: There are two (2) Internet-Draft Cutoff dates February 24th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, February 24th, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, February 24th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of February 24th will NOT be accepted. March 3rd: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, March 3rd, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_56.html _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon Feb 3 15:11:08 2003 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 PAA19820 for ; Mon, 3 Feb 2003 15:11:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KD8J21959; Mon, 3 Feb 2003 15:13:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KCBJ21930 for ; Mon, 3 Feb 2003 15:12:11 -0500 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19553 for ; Mon, 3 Feb 2003 15:06:32 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h13K3ch22689 for ; Mon, 3 Feb 2003 20:04:18 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h13K48n21702 for ; Mon, 3 Feb 2003 20:04:08 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003020312071206848 ; Mon, 03 Feb 2003 12:07:12 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 12:09:16 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@sun.com'" , ipoverib@ietf.org Cc: vivk@us.ibm.com Subject: RE: [Ipoverib] IPoIB/DHCP Date: Mon, 3 Feb 2003 12:09:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, I tend to agree. The client-id issues was thrashed on the list and it basically devolved to what was stated in the last paragraph of 2.1 "This document does not preclude the use of other 'client identifier' type, such as fully qualified domain name(FQDN) or the EUI-64 value associated with the interface." However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the bill. However, for the reasons you state, we do not plan on using in our implementation. Roy -----Original Message----- From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] Sent: Friday, January 31, 2003 9:07 PM To: ipoverib@ietf.org Cc: vivk@us.ibm.com Subject: [Ipoverib] IPoIB/DHCP Hi, I have an issue with section 2.1 of draft-ietf-ipoib-dhcp-over-infiniband-04.txt. I think it should be reworded to allow the following two formats for the client-id: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ Note that if the 20 byte client identifier does not represent the MAC address of the interface, the type should be 0. The type can be 32 only if the mac address is being used as the identifier. In fact, I doubt the neccesity of specifying the second format, since it represents an unstable address (QPN), which is likely to change whenever a port is rebooted. For the rationale, please see section 9.14 of RFC 2132: "A hardware type of 0 (zero) should be used when the value field contains an identifier other than a hardware address (e.g. a fully qualified domain name)." Thanks. Kanoj _______________________________________________ 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 From mailnull@www1.ietf.org Mon Feb 3 15:11:09 2003 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 PAA19832 for ; Mon, 3 Feb 2003 15:11:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13KGGE22179 for ipoverib-archive@odin.ietf.org; Mon, 3 Feb 2003 15:16:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KGGJ22175 for ; Mon, 3 Feb 2003 15:16:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19796 for ; Mon, 3 Feb 2003 15:10:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KD8J21959; Mon, 3 Feb 2003 15:13:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KCBJ21930 for ; Mon, 3 Feb 2003 15:12:11 -0500 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19553 for ; Mon, 3 Feb 2003 15:06:32 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h13K3ch22689 for ; Mon, 3 Feb 2003 20:04:18 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h13K48n21702 for ; Mon, 3 Feb 2003 20:04:08 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003020312071206848 ; Mon, 03 Feb 2003 12:07:12 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 12:09:16 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@sun.com'" , ipoverib@ietf.org Cc: vivk@us.ibm.com Subject: RE: [Ipoverib] IPoIB/DHCP Date: Mon, 3 Feb 2003 12:09:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, I tend to agree. The client-id issues was thrashed on the list and it basically devolved to what was stated in the last paragraph of 2.1 "This document does not preclude the use of other 'client identifier' type, such as fully qualified domain name(FQDN) or the EUI-64 value associated with the interface." However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the bill. However, for the reasons you state, we do not plan on using in our implementation. Roy -----Original Message----- From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] Sent: Friday, January 31, 2003 9:07 PM To: ipoverib@ietf.org Cc: vivk@us.ibm.com Subject: [Ipoverib] IPoIB/DHCP Hi, I have an issue with section 2.1 of draft-ietf-ipoib-dhcp-over-infiniband-04.txt. I think it should be reworded to allow the following two formats for the client-id: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ Note that if the 20 byte client identifier does not represent the MAC address of the interface, the type should be 0. The type can be 32 only if the mac address is being used as the identifier. In fact, I doubt the neccesity of specifying the second format, since it represents an unstable address (QPN), which is likely to change whenever a port is rebooted. For the rationale, please see section 9.14 of RFC 2132: "A hardware type of 0 (zero) should be used when the value field contains an identifier other than a hardware address (e.g. a fully qualified domain name)." Thanks. Kanoj _______________________________________________ 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 From ipoverib-admin@ietf.org Mon Feb 3 15:25:43 2003 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 PAA20441 for ; Mon, 3 Feb 2003 15:25:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KSCJ22796; Mon, 3 Feb 2003 15:28:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KRhJ22776 for ; Mon, 3 Feb 2003 15:27:43 -0500 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20373 for ; Mon, 3 Feb 2003 15:22:04 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11727; Mon, 3 Feb 2003 12:25:39 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13KPdVK026128; Mon, 3 Feb 2003 12:25:39 -0800 (PST) Received: from Sun.COM (sr1-usun-02.Eng.Sun.COM [129.144.135.8]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0H9R005MG22QJF@ha1sun-mail1.eng.sun.com>; Mon, 03 Feb 2003 12:25:38 -0800 (PST) Date: Mon, 03 Feb 2003 12:25:38 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/DHCP To: "Larsen, Roy K" Cc: ipoverib@ietf.org, vivk@us.ibm.com Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E3ED042.244D4E63@Sun.COM> MIME-version: 1.0 X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Content-Transfer-Encoding: 7BIT 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT "Larsen, Roy K" wrote: > > Kanoj, > > I tend to agree. The client-id issues was thrashed on the list and it > basically devolved to what was stated in the last paragraph of 2.1 > > "This document does not preclude the use of other 'client identifier' type, > such as fully qualified domain name(FQDN) or the EUI-64 value associated > with the interface." > Roy, > However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the The client identifier format suggested in the document does not use the QPN, rather a "Unique-value(4 octets)"; thus the 20 bytes does not represent the MAC address, thus the type should not be 32, but should be 0. I do agree that if an implementation does use the QPN as the 4 octets, it should set the type to 32. I think something like this would be more appropriate: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ "If an implementation uses the QPN of the interface as the 4 octet Unique-value, alongwith the 16 octet GID to create a 20 octet client-identifier, then it should set the Type value to 32 [ARPPARAM]" Thanks. Kanoj > bill. However, for the reasons you state, we do not plan on using in our > implementation. > > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Friday, January 31, 2003 9:07 PM > To: ipoverib@ietf.org > Cc: vivk@us.ibm.com > Subject: [Ipoverib] IPoIB/DHCP > > Hi, > > I have an issue with section 2.1 of > draft-ietf-ipoib-dhcp-over-infiniband-04.txt. > I think it should be reworded to allow the following two formats for the > client-id: > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Note that if the 20 byte client identifier does not represent the MAC > address > of the interface, the type should be 0. The type can be 32 only if the mac > address is being used as the identifier. > > In fact, I doubt the neccesity of specifying the second format, since it > represents > an unstable address (QPN), which is likely to change whenever a port is > rebooted. > > For the rationale, please see section 9.14 of RFC 2132: > "A hardware type of 0 (zero) should be used when the value field > contains an identifier other than a hardware address (e.g. a fully > qualified domain name)." > > Thanks. > > Kanoj > _______________________________________________ > 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 From mailnull@www1.ietf.org Mon Feb 3 15:25:43 2003 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 PAA20454 for ; Mon, 3 Feb 2003 15:25:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13KUpU22876 for ipoverib-archive@odin.ietf.org; Mon, 3 Feb 2003 15:30:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KUpJ22873 for ; Mon, 3 Feb 2003 15:30:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20410 for ; Mon, 3 Feb 2003 15:25:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KSCJ22796; Mon, 3 Feb 2003 15:28:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KRhJ22776 for ; Mon, 3 Feb 2003 15:27:43 -0500 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20373 for ; Mon, 3 Feb 2003 15:22:04 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11727; Mon, 3 Feb 2003 12:25:39 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13KPdVK026128; Mon, 3 Feb 2003 12:25:39 -0800 (PST) Received: from Sun.COM (sr1-usun-02.Eng.Sun.COM [129.144.135.8]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0H9R005MG22QJF@ha1sun-mail1.eng.sun.com>; Mon, 03 Feb 2003 12:25:38 -0800 (PST) Date: Mon, 03 Feb 2003 12:25:38 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/DHCP To: "Larsen, Roy K" Cc: ipoverib@ietf.org, vivk@us.ibm.com Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E3ED042.244D4E63@Sun.COM> MIME-version: 1.0 X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Content-Transfer-Encoding: 7BIT 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT "Larsen, Roy K" wrote: > > Kanoj, > > I tend to agree. The client-id issues was thrashed on the list and it > basically devolved to what was stated in the last paragraph of 2.1 > > "This document does not preclude the use of other 'client identifier' type, > such as fully qualified domain name(FQDN) or the EUI-64 value associated > with the interface." > Roy, > However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the The client identifier format suggested in the document does not use the QPN, rather a "Unique-value(4 octets)"; thus the 20 bytes does not represent the MAC address, thus the type should not be 32, but should be 0. I do agree that if an implementation does use the QPN as the 4 octets, it should set the type to 32. I think something like this would be more appropriate: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ "If an implementation uses the QPN of the interface as the 4 octet Unique-value, alongwith the 16 octet GID to create a 20 octet client-identifier, then it should set the Type value to 32 [ARPPARAM]" Thanks. Kanoj > bill. However, for the reasons you state, we do not plan on using in our > implementation. > > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Friday, January 31, 2003 9:07 PM > To: ipoverib@ietf.org > Cc: vivk@us.ibm.com > Subject: [Ipoverib] IPoIB/DHCP > > Hi, > > I have an issue with section 2.1 of > draft-ietf-ipoib-dhcp-over-infiniband-04.txt. > I think it should be reworded to allow the following two formats for the > client-id: > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Note that if the 20 byte client identifier does not represent the MAC > address > of the interface, the type should be 0. The type can be 32 only if the mac > address is being used as the identifier. > > In fact, I doubt the neccesity of specifying the second format, since it > represents > an unstable address (QPN), which is likely to change whenever a port is > rebooted. > > For the rationale, please see section 9.14 of RFC 2132: > "A hardware type of 0 (zero) should be used when the value field > contains an identifier other than a hardware address (e.g. a fully > qualified domain name)." > > Thanks. > > Kanoj > _______________________________________________ > 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 From ipoverib-admin@ietf.org Mon Feb 3 18:27:54 2003 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 SAA25182 for ; Mon, 3 Feb 2003 18:27:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13NULJ02126; Mon, 3 Feb 2003 18:30:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13NTfJ02099 for ; Mon, 3 Feb 2003 18:29:41 -0500 Received: from SMTP.HOTELS.MAGINET.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25138 for ; Mon, 3 Feb 2003 18:24:00 -0500 (EST) Received: from vaio505he ([61.193.171.17]) by SMTP.HOTELS.MAGINET.NET with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Feb 2003 16:33:36 -0700 Reply-To: From: "Yaron Haviv" To: , "'Larsen, Roy K'" Cc: , Subject: RE: [Ipoverib] IPoIB/DHCP Date: Tue, 4 Feb 2003 01:27:32 +0200 Message-ID: <002601c2cbdb$d46ee930$66df780a@voltaire.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3E3ED042.244D4E63@Sun.COM> X-OriginalArrivalTime: 03 Feb 2003 23:33:36.0406 (UTC) FILETIME=[AC517B60:01C2CBDC] Content-Transfer-Encoding: 7bit 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One observation on the DHCP issues, If we eventually don't use the real IPoIB MAC address (GID+QP) why not to just settle for Uniqe Value (4) + GUID (8) = 12 < 16 This way we will have a unique address, which also enable determining the node (Base GID = Subnet Prefix + GUID) And avoid all the hassle of dealing with long 20 byte addresses This way we don't need to change DHCP at all Also we see many other implementation issues that prevent using the 20 Byte address without messing with the OS code In some OS's it is even not practical Not to mention that some network monitoring and diagnostic tools fail to work in such an environment (20 bytes) Yaron -----Original Message----- From: ipoverib-admin@ietf.org [mailto:ipoverib-admin@ietf.org]On Behalf Of Kanoj Sarcar Sent: Monday, February 03, 2003 10:26 PM To: Larsen, Roy K Cc: ipoverib@ietf.org; vivk@us.ibm.com Subject: Re: [Ipoverib] IPoIB/DHCP "Larsen, Roy K" wrote: > > Kanoj, > > I tend to agree. The client-id issues was thrashed on the list and it > basically devolved to what was stated in the last paragraph of 2.1 > > "This document does not preclude the use of other 'client identifier' type, > such as fully qualified domain name(FQDN) or the EUI-64 value associated > with the interface." > Roy, > However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the The client identifier format suggested in the document does not use the QPN, rather a "Unique-value(4 octets)"; thus the 20 bytes does not represent the MAC address, thus the type should not be 32, but should be 0. I do agree that if an implementation does use the QPN as the 4 octets, it should set the type to 32. I think something like this would be more appropriate: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ "If an implementation uses the QPN of the interface as the 4 octet Unique-value, alongwith the 16 octet GID to create a 20 octet client-identifier, then it should set the Type value to 32 [ARPPARAM]" Thanks. Kanoj > bill. However, for the reasons you state, we do not plan on using in our > implementation. > > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Friday, January 31, 2003 9:07 PM > To: ipoverib@ietf.org > Cc: vivk@us.ibm.com > Subject: [Ipoverib] IPoIB/DHCP > > Hi, > > I have an issue with section 2.1 of > draft-ietf-ipoib-dhcp-over-infiniband-04.txt. > I think it should be reworded to allow the following two formats for the > client-id: > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Note that if the 20 byte client identifier does not represent the MAC > address > of the interface, the type should be 0. The type can be 32 only if the mac > address is being used as the identifier. > > In fact, I doubt the neccesity of specifying the second format, since it > represents > an unstable address (QPN), which is likely to change whenever a port is > rebooted. > > For the rationale, please see section 9.14 of RFC 2132: > "A hardware type of 0 (zero) should be used when the value field > contains an identifier other than a hardware address (e.g. a fully > qualified domain name)." > > Thanks. > > Kanoj > _______________________________________________ > 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 mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon Feb 3 18:27:54 2003 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 SAA25190 for ; Mon, 3 Feb 2003 18:27:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13NX4T02200 for ipoverib-archive@odin.ietf.org; Mon, 3 Feb 2003 18:33:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13NX4J02197 for ; Mon, 3 Feb 2003 18:33:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25162 for ; Mon, 3 Feb 2003 18:27:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13NULJ02126; Mon, 3 Feb 2003 18:30:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13NTfJ02099 for ; Mon, 3 Feb 2003 18:29:41 -0500 Received: from SMTP.HOTELS.MAGINET.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25138 for ; Mon, 3 Feb 2003 18:24:00 -0500 (EST) Received: from vaio505he ([61.193.171.17]) by SMTP.HOTELS.MAGINET.NET with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Feb 2003 16:33:36 -0700 Reply-To: From: "Yaron Haviv" To: , "'Larsen, Roy K'" Cc: , Subject: RE: [Ipoverib] IPoIB/DHCP Date: Tue, 4 Feb 2003 01:27:32 +0200 Message-ID: <002601c2cbdb$d46ee930$66df780a@voltaire.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3E3ED042.244D4E63@Sun.COM> X-OriginalArrivalTime: 03 Feb 2003 23:33:36.0406 (UTC) FILETIME=[AC517B60:01C2CBDC] Content-Transfer-Encoding: 7bit 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One observation on the DHCP issues, If we eventually don't use the real IPoIB MAC address (GID+QP) why not to just settle for Uniqe Value (4) + GUID (8) = 12 < 16 This way we will have a unique address, which also enable determining the node (Base GID = Subnet Prefix + GUID) And avoid all the hassle of dealing with long 20 byte addresses This way we don't need to change DHCP at all Also we see many other implementation issues that prevent using the 20 Byte address without messing with the OS code In some OS's it is even not practical Not to mention that some network monitoring and diagnostic tools fail to work in such an environment (20 bytes) Yaron -----Original Message----- From: ipoverib-admin@ietf.org [mailto:ipoverib-admin@ietf.org]On Behalf Of Kanoj Sarcar Sent: Monday, February 03, 2003 10:26 PM To: Larsen, Roy K Cc: ipoverib@ietf.org; vivk@us.ibm.com Subject: Re: [Ipoverib] IPoIB/DHCP "Larsen, Roy K" wrote: > > Kanoj, > > I tend to agree. The client-id issues was thrashed on the list and it > basically devolved to what was stated in the last paragraph of 2.1 > > "This document does not preclude the use of other 'client identifier' type, > such as fully qualified domain name(FQDN) or the EUI-64 value associated > with the interface." > Roy, > However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the The client identifier format suggested in the document does not use the QPN, rather a "Unique-value(4 octets)"; thus the 20 bytes does not represent the MAC address, thus the type should not be 32, but should be 0. I do agree that if an implementation does use the QPN as the 4 octets, it should set the type to 32. I think something like this would be more appropriate: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ "If an implementation uses the QPN of the interface as the 4 octet Unique-value, alongwith the 16 octet GID to create a 20 octet client-identifier, then it should set the Type value to 32 [ARPPARAM]" Thanks. Kanoj > bill. However, for the reasons you state, we do not plan on using in our > implementation. > > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Friday, January 31, 2003 9:07 PM > To: ipoverib@ietf.org > Cc: vivk@us.ibm.com > Subject: [Ipoverib] IPoIB/DHCP > > Hi, > > I have an issue with section 2.1 of > draft-ietf-ipoib-dhcp-over-infiniband-04.txt. > I think it should be reworded to allow the following two formats for the > client-id: > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Note that if the 20 byte client identifier does not represent the MAC > address > of the interface, the type should be 0. The type can be 32 only if the mac > address is being used as the identifier. > > In fact, I doubt the neccesity of specifying the second format, since it > represents > an unstable address (QPN), which is likely to change whenever a port is > rebooted. > > For the rationale, please see section 9.14 of RFC 2132: > "A hardware type of 0 (zero) should be used when the value field > contains an identifier other than a hardware address (e.g. a fully > qualified domain name)." > > Thanks. > > Kanoj > _______________________________________________ > 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 mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon Feb 3 19:05:34 2003 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 TAA25797 for ; Mon, 3 Feb 2003 19:05:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14087J04440; Mon, 3 Feb 2003 19:08:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1407vJ04426 for ; Mon, 3 Feb 2003 19:07:57 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25733 for ; Mon, 3 Feb 2003 19:02:13 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h1402vC09885 for ; Tue, 4 Feb 2003 00:02:57 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h1400fh03250 for ; Tue, 4 Feb 2003 00:00:41 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003020316034419370 ; Mon, 03 Feb 2003 16:03:44 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 16:05:48 -0800 Message-ID: From: "Larsen, Roy K" To: "'yaronh@voltaire.com'" , Kanoj.Sarcar@sun.com Cc: ipoverib@ietf.org, vivk@us.ibm.com Subject: RE: [Ipoverib] IPoIB/DHCP Date: Mon, 3 Feb 2003 16:05:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Yaron, Are you suggesting putting the value you describe in the chaddr field? That won't work. The DHCP server must be instructed to reply with a broadcast and since we can't use the chaddr field, we must use the client ID field. Once we use the client ID field, any unique and persistent value/character string (like the one you outline below) should work just fine since it is opaque to the DHCP server. Roy -----Original Message----- From: Yaron Haviv [mailto:yaronh@voltaire.com] Sent: Monday, February 03, 2003 3:28 PM To: Kanoj.Sarcar@sun.com; 'Larsen, Roy K' Cc: ipoverib@ietf.org; vivk@us.ibm.com Subject: RE: [Ipoverib] IPoIB/DHCP One observation on the DHCP issues, If we eventually don't use the real IPoIB MAC address (GID+QP) why not to just settle for Uniqe Value (4) + GUID (8) = 12 < 16 This way we will have a unique address, which also enable determining the node (Base GID = Subnet Prefix + GUID) And avoid all the hassle of dealing with long 20 byte addresses This way we don't need to change DHCP at all Also we see many other implementation issues that prevent using the 20 Byte address without messing with the OS code In some OS's it is even not practical Not to mention that some network monitoring and diagnostic tools fail to work in such an environment (20 bytes) Yaron -----Original Message----- From: ipoverib-admin@ietf.org [mailto:ipoverib-admin@ietf.org]On Behalf Of Kanoj Sarcar Sent: Monday, February 03, 2003 10:26 PM To: Larsen, Roy K Cc: ipoverib@ietf.org; vivk@us.ibm.com Subject: Re: [Ipoverib] IPoIB/DHCP "Larsen, Roy K" wrote: > > Kanoj, > > I tend to agree. The client-id issues was thrashed on the list and it > basically devolved to what was stated in the last paragraph of 2.1 > > "This document does not preclude the use of other 'client identifier' type, > such as fully qualified domain name(FQDN) or the EUI-64 value associated > with the interface." > Roy, > However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the The client identifier format suggested in the document does not use the QPN, rather a "Unique-value(4 octets)"; thus the 20 bytes does not represent the MAC address, thus the type should not be 32, but should be 0. I do agree that if an implementation does use the QPN as the 4 octets, it should set the type to 32. I think something like this would be more appropriate: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ "If an implementation uses the QPN of the interface as the 4 octet Unique-value, alongwith the 16 octet GID to create a 20 octet client-identifier, then it should set the Type value to 32 [ARPPARAM]" Thanks. Kanoj > bill. However, for the reasons you state, we do not plan on using in our > implementation. > > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Friday, January 31, 2003 9:07 PM > To: ipoverib@ietf.org > Cc: vivk@us.ibm.com > Subject: [Ipoverib] IPoIB/DHCP > > Hi, > > I have an issue with section 2.1 of > draft-ietf-ipoib-dhcp-over-infiniband-04.txt. > I think it should be reworded to allow the following two formats for the > client-id: > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Note that if the 20 byte client identifier does not represent the MAC > address > of the interface, the type should be 0. The type can be 32 only if the mac > address is being used as the identifier. > > In fact, I doubt the neccesity of specifying the second format, since it > represents > an unstable address (QPN), which is likely to change whenever a port is > rebooted. > > For the rationale, please see section 9.14 of RFC 2132: > "A hardware type of 0 (zero) should be used when the value field > contains an identifier other than a hardware address (e.g. a fully > qualified domain name)." > > Thanks. > > Kanoj > _______________________________________________ > 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 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 From mailnull@www1.ietf.org Mon Feb 3 19:05:35 2003 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 TAA25810 for ; Mon, 3 Feb 2003 19:05:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h140AkO04551 for ipoverib-archive@odin.ietf.org; Mon, 3 Feb 2003 19:10:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h140AkJ04548 for ; Mon, 3 Feb 2003 19:10:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25793 for ; Mon, 3 Feb 2003 19:05:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14087J04440; Mon, 3 Feb 2003 19:08:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1407vJ04426 for ; Mon, 3 Feb 2003 19:07:57 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25733 for ; Mon, 3 Feb 2003 19:02:13 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h1402vC09885 for ; Tue, 4 Feb 2003 00:02:57 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h1400fh03250 for ; Tue, 4 Feb 2003 00:00:41 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003020316034419370 ; Mon, 03 Feb 2003 16:03:44 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 16:05:48 -0800 Message-ID: From: "Larsen, Roy K" To: "'yaronh@voltaire.com'" , Kanoj.Sarcar@sun.com Cc: ipoverib@ietf.org, vivk@us.ibm.com Subject: RE: [Ipoverib] IPoIB/DHCP Date: Mon, 3 Feb 2003 16:05:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Yaron, Are you suggesting putting the value you describe in the chaddr field? That won't work. The DHCP server must be instructed to reply with a broadcast and since we can't use the chaddr field, we must use the client ID field. Once we use the client ID field, any unique and persistent value/character string (like the one you outline below) should work just fine since it is opaque to the DHCP server. Roy -----Original Message----- From: Yaron Haviv [mailto:yaronh@voltaire.com] Sent: Monday, February 03, 2003 3:28 PM To: Kanoj.Sarcar@sun.com; 'Larsen, Roy K' Cc: ipoverib@ietf.org; vivk@us.ibm.com Subject: RE: [Ipoverib] IPoIB/DHCP One observation on the DHCP issues, If we eventually don't use the real IPoIB MAC address (GID+QP) why not to just settle for Uniqe Value (4) + GUID (8) = 12 < 16 This way we will have a unique address, which also enable determining the node (Base GID = Subnet Prefix + GUID) And avoid all the hassle of dealing with long 20 byte addresses This way we don't need to change DHCP at all Also we see many other implementation issues that prevent using the 20 Byte address without messing with the OS code In some OS's it is even not practical Not to mention that some network monitoring and diagnostic tools fail to work in such an environment (20 bytes) Yaron -----Original Message----- From: ipoverib-admin@ietf.org [mailto:ipoverib-admin@ietf.org]On Behalf Of Kanoj Sarcar Sent: Monday, February 03, 2003 10:26 PM To: Larsen, Roy K Cc: ipoverib@ietf.org; vivk@us.ibm.com Subject: Re: [Ipoverib] IPoIB/DHCP "Larsen, Roy K" wrote: > > Kanoj, > > I tend to agree. The client-id issues was thrashed on the list and it > basically devolved to what was stated in the last paragraph of 2.1 > > "This document does not preclude the use of other 'client identifier' type, > such as fully qualified domain name(FQDN) or the EUI-64 value associated > with the interface." > Roy, > However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the The client identifier format suggested in the document does not use the QPN, rather a "Unique-value(4 octets)"; thus the 20 bytes does not represent the MAC address, thus the type should not be 32, but should be 0. I do agree that if an implementation does use the QPN as the 4 octets, it should set the type to 32. I think something like this would be more appropriate: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ "If an implementation uses the QPN of the interface as the 4 octet Unique-value, alongwith the 16 octet GID to create a 20 octet client-identifier, then it should set the Type value to 32 [ARPPARAM]" Thanks. Kanoj > bill. However, for the reasons you state, we do not plan on using in our > implementation. > > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Friday, January 31, 2003 9:07 PM > To: ipoverib@ietf.org > Cc: vivk@us.ibm.com > Subject: [Ipoverib] IPoIB/DHCP > > Hi, > > I have an issue with section 2.1 of > draft-ietf-ipoib-dhcp-over-infiniband-04.txt. > I think it should be reworded to allow the following two formats for the > client-id: > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Note that if the 20 byte client identifier does not represent the MAC > address > of the interface, the type should be 0. The type can be 32 only if the mac > address is being used as the identifier. > > In fact, I doubt the neccesity of specifying the second format, since it > represents > an unstable address (QPN), which is likely to change whenever a port is > rebooted. > > For the rationale, please see section 9.14 of RFC 2132: > "A hardware type of 0 (zero) should be used when the value field > contains an identifier other than a hardware address (e.g. a fully > qualified domain name)." > > Thanks. > > Kanoj > _______________________________________________ > 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 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 From ipoverib-admin@ietf.org Mon Feb 3 20:13:48 2003 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 UAA26538 for ; Mon, 3 Feb 2003 20:13:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h141GMJ07307; Mon, 3 Feb 2003 20:16:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h141FHJ07267 for ; Mon, 3 Feb 2003 20:15:17 -0500 Received: from e34.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26448; Mon, 3 Feb 2003 20:09:32 -0500 (EST) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h141D8PL013858; Mon, 3 Feb 2003 20:13:08 -0500 Received: from d03nm036.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h141D74v060854; Mon, 3 Feb 2003 18:13:07 -0700 Subject: Re: [Ipoverib] IPoIB/DHCP To: Kanoj.Sarcar@sun.com Cc: ipoverib@ietf.org, ipoverib-admin@ietf.org, "Larsen, Roy K" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Mon, 3 Feb 2003 17:09:09 -0800 X-MIMETrack: Serialize by Router on D03NM036/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/03/2003 18:13:06 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, You are right - the GID by itself is not the MAC address. This brings up the two options you have mentioned: - when QPN is included in the client-identifier; the hardware type is 32. - when a value other than QPN is used in forming the client-identifier; the hardware type is 0. I am ok with making the change as suggested by you. Is it agreeable to all? Vivek -- Vivek Kashyap Linux Technology Center, IBM vivk@us.ibm.com kashyapv@us.ibm.com Ph: 503 578 3422 T/L: 775 3422 Kanoj Sarcar .com> cc: ipoverib@ietf.org, Vivek Kashyap/Beaverton/IBM@IBMUS Sent by: Subject: Re: [Ipoverib] IPoIB/DHCP ipoverib-admin@ie tf.org 02/03/2003 12:25 PM Please respond to Kanoj.Sarcar "Larsen, Roy K" wrote: > > Kanoj, > > I tend to agree. The client-id issues was thrashed on the list and it > basically devolved to what was stated in the last paragraph of 2.1 > > "This document does not preclude the use of other 'client identifier' type, > such as fully qualified domain name(FQDN) or the EUI-64 value associated > with the interface." > Roy, > However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the The client identifier format suggested in the document does not use the QPN, rather a "Unique-value(4 octets)"; thus the 20 bytes does not represent the MAC address, thus the type should not be 32, but should be 0. I do agree that if an implementation does use the QPN as the 4 octets, it should set the type to 32. I think something like this would be more appropriate: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ "If an implementation uses the QPN of the interface as the 4 octet Unique-value, alongwith the 16 octet GID to create a 20 octet client-identifier, then it should set the Type value to 32 [ARPPARAM]" Thanks. Kanoj > bill. However, for the reasons you state, we do not plan on using in our > implementation. > > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Friday, January 31, 2003 9:07 PM > To: ipoverib@ietf.org > Cc: vivk@us.ibm.com > Subject: [Ipoverib] IPoIB/DHCP > > Hi, > > I have an issue with section 2.1 of > draft-ietf-ipoib-dhcp-over-infiniband-04.txt. > I think it should be reworded to allow the following two formats for the > client-id: > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Note that if the 20 byte client identifier does not represent the MAC > address > of the interface, the type should be 0. The type can be 32 only if the mac > address is being used as the identifier. > > In fact, I doubt the neccesity of specifying the second format, since it > represents > an unstable address (QPN), which is likely to change whenever a port is > rebooted. > > For the rationale, please see section 9.14 of RFC 2132: > "A hardware type of 0 (zero) should be used when the value field > contains an identifier other than a hardware address (e.g. a fully > qualified domain name)." > > Thanks. > > Kanoj > _______________________________________________ > 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 mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon Feb 3 20:13:48 2003 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 UAA26550 for ; Mon, 3 Feb 2003 20:13:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h141J1E07395 for ipoverib-archive@odin.ietf.org; Mon, 3 Feb 2003 20:19:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h141J1J07392 for ; Mon, 3 Feb 2003 20:19:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26506 for ; Mon, 3 Feb 2003 20:13:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h141GMJ07307; Mon, 3 Feb 2003 20:16:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h141FHJ07267 for ; Mon, 3 Feb 2003 20:15:17 -0500 Received: from e34.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26448; Mon, 3 Feb 2003 20:09:32 -0500 (EST) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h141D8PL013858; Mon, 3 Feb 2003 20:13:08 -0500 Received: from d03nm036.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h141D74v060854; Mon, 3 Feb 2003 18:13:07 -0700 Subject: Re: [Ipoverib] IPoIB/DHCP To: Kanoj.Sarcar@sun.com Cc: ipoverib@ietf.org, ipoverib-admin@ietf.org, "Larsen, Roy K" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Mon, 3 Feb 2003 17:09:09 -0800 X-MIMETrack: Serialize by Router on D03NM036/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/03/2003 18:13:06 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, You are right - the GID by itself is not the MAC address. This brings up the two options you have mentioned: - when QPN is included in the client-identifier; the hardware type is 32. - when a value other than QPN is used in forming the client-identifier; the hardware type is 0. I am ok with making the change as suggested by you. Is it agreeable to all? Vivek -- Vivek Kashyap Linux Technology Center, IBM vivk@us.ibm.com kashyapv@us.ibm.com Ph: 503 578 3422 T/L: 775 3422 Kanoj Sarcar .com> cc: ipoverib@ietf.org, Vivek Kashyap/Beaverton/IBM@IBMUS Sent by: Subject: Re: [Ipoverib] IPoIB/DHCP ipoverib-admin@ie tf.org 02/03/2003 12:25 PM Please respond to Kanoj.Sarcar "Larsen, Roy K" wrote: > > Kanoj, > > I tend to agree. The client-id issues was thrashed on the list and it > basically devolved to what was stated in the last paragraph of 2.1 > > "This document does not preclude the use of other 'client identifier' type, > such as fully qualified domain name(FQDN) or the EUI-64 value associated > with the interface." > Roy, > However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the The client identifier format suggested in the document does not use the QPN, rather a "Unique-value(4 octets)"; thus the 20 bytes does not represent the MAC address, thus the type should not be 32, but should be 0. I do agree that if an implementation does use the QPN as the 4 octets, it should set the type to 32. I think something like this would be more appropriate: Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ "If an implementation uses the QPN of the interface as the 4 octet Unique-value, alongwith the 16 octet GID to create a 20 octet client-identifier, then it should set the Type value to 32 [ARPPARAM]" Thanks. Kanoj > bill. However, for the reasons you state, we do not plan on using in our > implementation. > > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Friday, January 31, 2003 9:07 PM > To: ipoverib@ietf.org > Cc: vivk@us.ibm.com > Subject: [Ipoverib] IPoIB/DHCP > > Hi, > > I have an issue with section 2.1 of > draft-ietf-ipoib-dhcp-over-infiniband-04.txt. > I think it should be reworded to allow the following two formats for the > client-id: > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 0 | Unique-value(4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > | 61 | 21 | 32 | QPN (4 octets) | GID (16 octets) | > +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ > > Note that if the 20 byte client identifier does not represent the MAC > address > of the interface, the type should be 0. The type can be 32 only if the mac > address is being used as the identifier. > > In fact, I doubt the neccesity of specifying the second format, since it > represents > an unstable address (QPN), which is likely to change whenever a port is > rebooted. > > For the rationale, please see section 9.14 of RFC 2132: > "A hardware type of 0 (zero) should be used when the value field > contains an identifier other than a hardware address (e.g. a fully > qualified domain name)." > > Thanks. > > Kanoj > _______________________________________________ > 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 mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue Feb 11 16:12:19 2003 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 QAA18641 for ; Tue, 11 Feb 2003 16:12:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BLKOp12796; Tue, 11 Feb 2003 16:20:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BLJmp12738 for ; Tue, 11 Feb 2003 16:19:48 -0500 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18593 for ; Tue, 11 Feb 2003 16:10:14 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19394 for ; Tue, 11 Feb 2003 13:13:57 -0800 (PST) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h1BLDuVA573995 for ; Tue, 11 Feb 2003 13:13:56 -0800 (PST) Message-Id: <200302112113.h1BLDuVA573995@jurassic.eng.sun.com> Date: Tue, 11 Feb 2003 13:13:52 -0800 (PST) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" To: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +3XSX9EtXm5PSDZkRRXc6Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Subject: [Ipoverib] upcoming IETF meeting in San Francisco 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , The next IETF meeting is fast approaching, but we have not scheduled a slot for IPoIB yet. Our current deliverables are 1) Encapsulation draft 2) link and multicast draft 3) DHCP draft 4) MIB drafts The first three drafts went to the IESG and are currently being revised based on feedback and IBA 1.1 spec. Vivek and I will published the revised drafts in a few days. The MIB drafts have been updated, and are getting close to last call. Bill and I are interested in knowing your opinion on if we have business to conduct in San Fransisco. If you have a presentation that you would like to make, or an agenda item to discuss - bring it to the list so we know that we need to schedule a meeting. The deadline for this will be Friday 21 Feb. If we do not have any requests for agenda items by then we will not schedule a meeting, if there are agenda requests we will schedule a meeting. Included here are the Important Meeting Dates: January 7, Tuesday - Working Group and BOF scheduling begins January 13, Monday - Registration begins February 24, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET February 25, Tuesday - Working Group and BOF scheduling closes at 17:00 ET March 3, Monday - Internet Draft final submission cut-off at 09:00 ET March 7, Friday - Registration and Pre-payment cut-off at 12:00 noon ET March 12, Wednesday - Registration cancellation cut-off at 17:00 ET March 13, Thursday - Working Group agendas due date at 12:00 ET March 16-21 - 56th IETF Meeting in San Francisco, CA April 14, Monday - Proceedings submission cutoff date by 17:00 ET * All times are in US Eastern Time Thank you, Bill and Jerry, co-chairs IPoIB WG _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue Feb 11 16:12:19 2003 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 QAA18648 for ; Tue, 11 Feb 2003 16:12:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BLLMV12851 for ipoverib-archive@odin.ietf.org; Tue, 11 Feb 2003 16:21:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BLLMp12848 for ; Tue, 11 Feb 2003 16:21:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18627 for ; Tue, 11 Feb 2003 16:11:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BLKOp12796; Tue, 11 Feb 2003 16:20:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BLJmp12738 for ; Tue, 11 Feb 2003 16:19:48 -0500 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18593 for ; Tue, 11 Feb 2003 16:10:14 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19394 for ; Tue, 11 Feb 2003 13:13:57 -0800 (PST) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h1BLDuVA573995 for ; Tue, 11 Feb 2003 13:13:56 -0800 (PST) Message-Id: <200302112113.h1BLDuVA573995@jurassic.eng.sun.com> Date: Tue, 11 Feb 2003 13:13:52 -0800 (PST) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" To: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +3XSX9EtXm5PSDZkRRXc6Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Subject: [Ipoverib] upcoming IETF meeting in San Francisco 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , The next IETF meeting is fast approaching, but we have not scheduled a slot for IPoIB yet. Our current deliverables are 1) Encapsulation draft 2) link and multicast draft 3) DHCP draft 4) MIB drafts The first three drafts went to the IESG and are currently being revised based on feedback and IBA 1.1 spec. Vivek and I will published the revised drafts in a few days. The MIB drafts have been updated, and are getting close to last call. Bill and I are interested in knowing your opinion on if we have business to conduct in San Fransisco. If you have a presentation that you would like to make, or an agenda item to discuss - bring it to the list so we know that we need to schedule a meeting. The deadline for this will be Friday 21 Feb. If we do not have any requests for agenda items by then we will not schedule a meeting, if there are agenda requests we will schedule a meeting. Included here are the Important Meeting Dates: January 7, Tuesday - Working Group and BOF scheduling begins January 13, Monday - Registration begins February 24, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET February 25, Tuesday - Working Group and BOF scheduling closes at 17:00 ET March 3, Monday - Internet Draft final submission cut-off at 09:00 ET March 7, Friday - Registration and Pre-payment cut-off at 12:00 noon ET March 12, Wednesday - Registration cancellation cut-off at 17:00 ET March 13, Thursday - Working Group agendas due date at 12:00 ET March 16-21 - 56th IETF Meeting in San Francisco, CA April 14, Monday - Proceedings submission cutoff date by 17:00 ET * All times are in US Eastern Time Thank you, Bill and Jerry, co-chairs IPoIB WG _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Fri Feb 14 06:47:58 2003 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 GAA17298 for ; Fri, 14 Feb 2003 06:47:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBoPp18748; Fri, 14 Feb 2003 06:50:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBmPp18596 for ; Fri, 14 Feb 2003 06:48:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16916; Fri, 14 Feb 2003 06:44:18 -0500 (EST) Message-Id: <200302141144.GAA16916@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipoverib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Feb 2003 06:44:18 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-channel-adapter-mib-04.txt 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over InfiniBand Working Group of the IETF. Title : Definitions of Managed Objects for Infiniband Channel Adapters (CA) Author(s) : S. Harnedy Filename : draft-ietf-ipoib-channel-adapter-mib-04.txt Pages : 21 Date : 2003-2-13 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Channel Adapters (CA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-channel-adapter-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipoib-channel-adapter-mib-04.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-ipoib-channel-adapter-mib-04.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: <2003-2-13152818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-channel-adapter-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-channel-adapter-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13152818.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Fri Feb 14 06:47:58 2003 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 GAA17310 for ; Fri, 14 Feb 2003 06:47:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EBpYf18851 for ipoverib-archive@odin.ietf.org; Fri, 14 Feb 2003 06:51:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBpYp18848 for ; Fri, 14 Feb 2003 06:51:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17233 for ; Fri, 14 Feb 2003 06:47:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBoPp18748; Fri, 14 Feb 2003 06:50:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBmPp18596 for ; Fri, 14 Feb 2003 06:48:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16916; Fri, 14 Feb 2003 06:44:18 -0500 (EST) Message-Id: <200302141144.GAA16916@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipoverib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Feb 2003 06:44:18 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-channel-adapter-mib-04.txt 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over InfiniBand Working Group of the IETF. Title : Definitions of Managed Objects for Infiniband Channel Adapters (CA) Author(s) : S. Harnedy Filename : draft-ietf-ipoib-channel-adapter-mib-04.txt Pages : 21 Date : 2003-2-13 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Channel Adapters (CA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-channel-adapter-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipoib-channel-adapter-mib-04.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-ipoib-channel-adapter-mib-04.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: <2003-2-13152818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-channel-adapter-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-channel-adapter-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13152818.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Fri Feb 14 06:50:09 2003 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 GAA17455 for ; Fri, 14 Feb 2003 06:50:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBqrp18978; Fri, 14 Feb 2003 06:52:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBn0p18628 for ; Fri, 14 Feb 2003 06:49:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17049; Fri, 14 Feb 2003 06:44:53 -0500 (EST) Message-Id: <200302141144.GAA17049@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipoverib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Feb 2003 06:44:53 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-perf-mgmt-agent-mib-01.txt 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over InfiniBand Working Group of the IETF. Title : Definitions of Managed Objects for the Infiniband Performance Management Agent (PMA) Author(s) : S. Harnedy Filename : draft-ietf-ipoib-perf-mgmt-agent-mib-01.txt Pages : 56 Date : 2003-2-13 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Performance Management Agents (PMA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-perf-mgmt-agent-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipoib-perf-mgmt-agent-mib-01.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-ipoib-perf-mgmt-agent-mib-01.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: <2003-2-13155144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-perf-mgmt-agent-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-perf-mgmt-agent-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13155144.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Fri Feb 14 06:50:10 2003 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 GAA17463 for ; Fri, 14 Feb 2003 06:50:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EBrkD19064 for ipoverib-archive@odin.ietf.org; Fri, 14 Feb 2003 06:53:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBrjp19061 for ; Fri, 14 Feb 2003 06:53:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17428 for ; Fri, 14 Feb 2003 06:49:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBqrp18978; Fri, 14 Feb 2003 06:52:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBn0p18628 for ; Fri, 14 Feb 2003 06:49:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17049; Fri, 14 Feb 2003 06:44:53 -0500 (EST) Message-Id: <200302141144.GAA17049@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipoverib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Feb 2003 06:44:53 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-perf-mgmt-agent-mib-01.txt 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over InfiniBand Working Group of the IETF. Title : Definitions of Managed Objects for the Infiniband Performance Management Agent (PMA) Author(s) : S. Harnedy Filename : draft-ietf-ipoib-perf-mgmt-agent-mib-01.txt Pages : 56 Date : 2003-2-13 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Performance Management Agents (PMA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-perf-mgmt-agent-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipoib-perf-mgmt-agent-mib-01.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-ipoib-perf-mgmt-agent-mib-01.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: <2003-2-13155144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-perf-mgmt-agent-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-perf-mgmt-agent-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13155144.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Thu Feb 20 17:14:54 2003 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 RAA01594 for ; Thu, 20 Feb 2003 17:14:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMKRp21096; Thu, 20 Feb 2003 17:20:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMK0p21036 for ; Thu, 20 Feb 2003 17:20:00 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01569 for ; Thu, 20 Feb 2003 17:12:43 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09596 for ; Thu, 20 Feb 2003 15:16:33 -0700 (MST) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h1KMGXim891669 for ; Thu, 20 Feb 2003 14:16:33 -0800 (PST) Message-Id: <200302202216.h1KMGXim891669@jurassic.eng.sun.com> Date: Thu, 20 Feb 2003 14:16:31 -0800 (PST) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" To: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0RxtO3dSwmdUc5kIWeJwoA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Subject: [Ipoverib] IPoIB slot in San Francisco 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , We've got a morning slot on Tuesday in the upcoming San Francisco IETF: TUESDAY, March 18, 2003 0800-1800 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions INT dnsext DNS Extensions WG INT ipoib IP over InfiniBand WG OPS bmwg Benchmarking Methodology WG RTG rpsec Routing Protocol Security Requirements WG SUB mpls Multiprotocol Label Switching WG TSV avt Audio/Video Transport WG Please make your travel plan accordingly, but beware that the schedule may change until the scheduling closes in a week or so. For those who plan to make presentations, please let me know your topics and how much time you need. Thanks, Jerry _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Thu Feb 20 17:14:55 2003 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 RAA01604 for ; Thu, 20 Feb 2003 17:14:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KMLfq21129 for ipoverib-archive@odin.ietf.org; Thu, 20 Feb 2003 17:21:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMLep21126 for ; Thu, 20 Feb 2003 17:21:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01585 for ; Thu, 20 Feb 2003 17:14:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMKRp21096; Thu, 20 Feb 2003 17:20:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMK0p21036 for ; Thu, 20 Feb 2003 17:20:00 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01569 for ; Thu, 20 Feb 2003 17:12:43 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09596 for ; Thu, 20 Feb 2003 15:16:33 -0700 (MST) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h1KMGXim891669 for ; Thu, 20 Feb 2003 14:16:33 -0800 (PST) Message-Id: <200302202216.h1KMGXim891669@jurassic.eng.sun.com> Date: Thu, 20 Feb 2003 14:16:31 -0800 (PST) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" To: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0RxtO3dSwmdUc5kIWeJwoA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Subject: [Ipoverib] IPoIB slot in San Francisco 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , We've got a morning slot on Tuesday in the upcoming San Francisco IETF: TUESDAY, March 18, 2003 0800-1800 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions INT dnsext DNS Extensions WG INT ipoib IP over InfiniBand WG OPS bmwg Benchmarking Methodology WG RTG rpsec Routing Protocol Security Requirements WG SUB mpls Multiprotocol Label Switching WG TSV avt Audio/Video Transport WG Please make your travel plan accordingly, but beware that the schedule may change until the scheduling closes in a week or so. For those who plan to make presentations, please let me know your topics and how much time you need. Thanks, Jerry _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue Feb 25 06:50:37 2003 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 GAA25286 for ; Tue, 25 Feb 2003 06:50:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBwYp21447; Tue, 25 Feb 2003 06:58:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBtIp21256 for ; Tue, 25 Feb 2003 06:55:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24834; Tue, 25 Feb 2003 06:45:49 -0500 (EST) Message-Id: <200302251145.GAA24834@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipoverib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Feb 2003 06:45:49 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-dhcp-over-infiniband-05.txt 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over InfiniBand Working Group of the IETF. Title : DHCP over InfiniBand Author(s) : V. Kashyap Filename : draft-ietf-ipoib-dhcp-over-infiniband-05.txt Pages : 7 Date : 2003-2-24 An InfiniBand network uses a link-layer addressing scheme that is 20-octets long. This is larger than the 16-octets reserved for the hardware address in DHCP/BOOTP message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IP over InfiniBand(IPoIB) network. This document describes the use of DHCP message fields when implementing DHCP over IPoIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-dhcp-over-infiniband-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipoib-dhcp-over-infiniband-05.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-ipoib-dhcp-over-infiniband-05.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: <2003-2-24142446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-dhcp-over-infiniband-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-dhcp-over-infiniband-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-24142446.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue Feb 25 06:50:37 2003 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 GAA25295 for ; Tue, 25 Feb 2003 06:50:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PBxaY21579 for ipoverib-archive@odin.ietf.org; Tue, 25 Feb 2003 06:59:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBxap21576 for ; Tue, 25 Feb 2003 06:59:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25247 for ; Tue, 25 Feb 2003 06:50:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBwYp21447; Tue, 25 Feb 2003 06:58:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBtIp21256 for ; Tue, 25 Feb 2003 06:55:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24834; Tue, 25 Feb 2003 06:45:49 -0500 (EST) Message-Id: <200302251145.GAA24834@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipoverib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Feb 2003 06:45:49 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-dhcp-over-infiniband-05.txt 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over InfiniBand Working Group of the IETF. Title : DHCP over InfiniBand Author(s) : V. Kashyap Filename : draft-ietf-ipoib-dhcp-over-infiniband-05.txt Pages : 7 Date : 2003-2-24 An InfiniBand network uses a link-layer addressing scheme that is 20-octets long. This is larger than the 16-octets reserved for the hardware address in DHCP/BOOTP message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IP over InfiniBand(IPoIB) network. This document describes the use of DHCP message fields when implementing DHCP over IPoIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-dhcp-over-infiniband-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipoib-dhcp-over-infiniband-05.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-ipoib-dhcp-over-infiniband-05.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: <2003-2-24142446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-dhcp-over-infiniband-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-dhcp-over-infiniband-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-24142446.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Fri Feb 28 16:40:29 2003 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 QAA14100 for ; Fri, 28 Feb 2003 16:40:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLmHp30390; Fri, 28 Feb 2003 16:48:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLlVp30362 for ; Fri, 28 Feb 2003 16:47:31 -0500 Received: from rwcrmhc51.attbi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14073 for ; Fri, 28 Feb 2003 16:38:19 -0500 (EST) Received: from mobilebill (12-211-30-155.client.attbi.com[12.211.30.155]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003022821401705100iqgnke>; Fri, 28 Feb 2003 21:40:17 +0000 From: "bill" To: Date: Fri, 28 Feb 2003 13:39:57 -0800 Message-ID: <000801c2df71$f3341350$6501a8c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Ipoverib] FW: I-D ACTION:draft-ietf-ops-mib-review-guidelines-01.txt 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit For MIB authors and reviewers in the working group: The OPS area has taken the task of reviewing all MIB documents that are processed in working groups... This document describes the process and what they might be looking for, please take a look and make sure your documents won't run into problems from this review (at the IESG last call level) Bill -----Original Message----- From: owner-wgchairs@ietf.org [mailto:owner-wgchairs@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, February 25, 2003 6:33 AM To: wgchairs@ietf.org Subject: FW: I-D ACTION:draft-ietf-ops-mib-review-guidelines-01.txt FYI. This is the second revision that has incorprated all comments and feedback we got. From now on we will be using these guidelines when we do MIB doctor review. It would be good if your editors/authors check their MIB documents against this as well, and that you as WG chairs try to make sure that the WG has taken these guidelines into consideration when they approve (bu WG Last Call) such a document. If any questions come up... feel free to post them to the mibs@ops.ietf.org mailings (general MIB related discussions list) or send them to myself. Thanks, Bert -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: dinsdag 25 februari 2003 12:46 Subject: I-D ACTION:draft-ietf-ops-mib-review-guidelines-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations & Management Open Area Working Group of the IETF. Title : Guidelines for MIB Authors and Reviewers Author(s) : C. Heard Filename : draft-ietf-ops-mib-review-guidelines-01.txt Pages : 47 Date : 2003-2-24 This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may used as a basis for reviews of other MIB documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines -01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ops-mib-review-guidelines-01.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-ops-mib-review-guidelines-01.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. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Fri Feb 28 16:40:30 2003 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 QAA14109 for ; Fri, 28 Feb 2003 16:40:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SLnAg30428 for ipoverib-archive@odin.ietf.org; Fri, 28 Feb 2003 16:49:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLnAp30425 for ; Fri, 28 Feb 2003 16:49:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14096 for ; Fri, 28 Feb 2003 16:39:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLmHp30390; Fri, 28 Feb 2003 16:48:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLlVp30362 for ; Fri, 28 Feb 2003 16:47:31 -0500 Received: from rwcrmhc51.attbi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14073 for ; Fri, 28 Feb 2003 16:38:19 -0500 (EST) Received: from mobilebill (12-211-30-155.client.attbi.com[12.211.30.155]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003022821401705100iqgnke>; Fri, 28 Feb 2003 21:40:17 +0000 From: "bill" To: Date: Fri, 28 Feb 2003 13:39:57 -0800 Message-ID: <000801c2df71$f3341350$6501a8c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Ipoverib] FW: I-D ACTION:draft-ietf-ops-mib-review-guidelines-01.txt 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: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit For MIB authors and reviewers in the working group: The OPS area has taken the task of reviewing all MIB documents that are processed in working groups... This document describes the process and what they might be looking for, please take a look and make sure your documents won't run into problems from this review (at the IESG last call level) Bill -----Original Message----- From: owner-wgchairs@ietf.org [mailto:owner-wgchairs@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, February 25, 2003 6:33 AM To: wgchairs@ietf.org Subject: FW: I-D ACTION:draft-ietf-ops-mib-review-guidelines-01.txt FYI. This is the second revision that has incorprated all comments and feedback we got. From now on we will be using these guidelines when we do MIB doctor review. It would be good if your editors/authors check their MIB documents against this as well, and that you as WG chairs try to make sure that the WG has taken these guidelines into consideration when they approve (bu WG Last Call) such a document. If any questions come up... feel free to post them to the mibs@ops.ietf.org mailings (general MIB related discussions list) or send them to myself. Thanks, Bert -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: dinsdag 25 februari 2003 12:46 Subject: I-D ACTION:draft-ietf-ops-mib-review-guidelines-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations & Management Open Area Working Group of the IETF. Title : Guidelines for MIB Authors and Reviewers Author(s) : C. Heard Filename : draft-ietf-ops-mib-review-guidelines-01.txt Pages : 47 Date : 2003-2-24 This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may used as a basis for reviews of other MIB documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines -01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ops-mib-review-guidelines-01.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-ops-mib-review-guidelines-01.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. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib