From ipoverib-admin@ietf.org Tue Jan 7 08:33: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 IAA12589 for ; Tue, 7 Jan 2003 08:33: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 h07DgEJ20236; Tue, 7 Jan 2003 08:42: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 h07DegJ20144 for ; Tue, 7 Jan 2003 08:40:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12142; Tue, 7 Jan 2003 08:29:27 -0500 (EST) Message-Id: <200301071329.IAA12142@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, 07 Jan 2003 08:29:27 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-dhcp-over-infiniband-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 : DHCP over InfiniBand Author(s) : V. Kashyap Filename : draft-ietf-ipoib-dhcp-over-infiniband-04.txt Pages : 6 Date : 2003-1-6 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-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-dhcp-over-infiniband-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-dhcp-over-infiniband-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-1-6145354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-dhcp-over-infiniband-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-dhcp-over-infiniband-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145354.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 Jan 7 08:33: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 IAA12601 for ; Tue, 7 Jan 2003 08:33:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07DiEt20301 for ipoverib-archive@odin.ietf.org; Tue, 7 Jan 2003 08:44: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 h07DiEJ20298 for ; Tue, 7 Jan 2003 08:44: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 IAA12581 for ; Tue, 7 Jan 2003 08:32: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 h07DgEJ20236; Tue, 7 Jan 2003 08:42: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 h07DegJ20144 for ; Tue, 7 Jan 2003 08:40:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12142; Tue, 7 Jan 2003 08:29:27 -0500 (EST) Message-Id: <200301071329.IAA12142@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, 07 Jan 2003 08:29:27 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-dhcp-over-infiniband-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 : DHCP over InfiniBand Author(s) : V. Kashyap Filename : draft-ietf-ipoib-dhcp-over-infiniband-04.txt Pages : 6 Date : 2003-1-6 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-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-dhcp-over-infiniband-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-dhcp-over-infiniband-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-1-6145354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-dhcp-over-infiniband-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-dhcp-over-infiniband-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145354.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 Jan 9 09:28:23 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 JAA11210 for ; Thu, 9 Jan 2003 09:28: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 h09EckJ26906; Thu, 9 Jan 2003 09:38:47 -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 h09EZrJ26066 for ; Thu, 9 Jan 2003 09:35:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10834; Thu, 9 Jan 2003 09:23:39 -0500 (EST) Message-Id: <200301091423.JAA10834@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: Thu, 09 Jan 2003 09:23:38 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibmib-tc-mib-02.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 : Definition of Textual Conventions and OBJECT-IDENTITIES for IP Over InfiniBand (IPOVERIB) Management Author(s) : S. Harnedy Filename : draft-ietf-ipoib-ibmib-tc-mib-02.txt Pages : 11 Date : 2003-1-8 This memo describes Textual Conventions and OBJECT-IDENTITIES for use in definitions of management information for IP Over InfiniBand (IPOVERIB) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.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-ibmib-tc-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-9092340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ibmib-tc-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092340.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Thu Jan 9 09:28:23 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 JAA11219 for ; Thu, 9 Jan 2003 09:28:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Ee7I27014 for ipoverib-archive@odin.ietf.org; Thu, 9 Jan 2003 09:40: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 h09Ee7J27011 for ; Thu, 9 Jan 2003 09:40:07 -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 JAA11188 for ; Thu, 9 Jan 2003 09:27:52 -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 h09EckJ26906; Thu, 9 Jan 2003 09:38:47 -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 h09EZrJ26066 for ; Thu, 9 Jan 2003 09:35:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10834; Thu, 9 Jan 2003 09:23:39 -0500 (EST) Message-Id: <200301091423.JAA10834@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: Thu, 09 Jan 2003 09:23:38 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibmib-tc-mib-02.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 : Definition of Textual Conventions and OBJECT-IDENTITIES for IP Over InfiniBand (IPOVERIB) Management Author(s) : S. Harnedy Filename : draft-ietf-ipoib-ibmib-tc-mib-02.txt Pages : 11 Date : 2003-1-8 This memo describes Textual Conventions and OBJECT-IDENTITIES for use in definitions of management information for IP Over InfiniBand (IPOVERIB) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.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-ibmib-tc-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-9092340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ibmib-tc-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092340.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 Jan 9 09:29:51 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 JAA11276 for ; Thu, 9 Jan 2003 09:29:51 -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 h09EehJ27069; Thu, 9 Jan 2003 09:40:43 -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 h09EZxJ26082 for ; Thu, 9 Jan 2003 09:35:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10852; Thu, 9 Jan 2003 09:23:45 -0500 (EST) Message-Id: <200301091423.JAA10852@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: Thu, 09 Jan 2003 09:23:45 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibif-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 Interface Type Author(s) : B. Anderson, S. Harnedy Filename : draft-ietf-ipoib-ibif-mib-04.txt Pages : 29 Date : 2003-1-8 InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture to deliver scalable performance in data centers. This memo defines a portion of Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IBA defined InfiniBand interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibif-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-ibif-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-ibif-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-1-9092350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ibif-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ibif-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092350.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Thu Jan 9 09:29:51 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 JAA11284 for ; Thu, 9 Jan 2003 09:29:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09EfZd27135 for ipoverib-archive@odin.ietf.org; Thu, 9 Jan 2003 09:41:35 -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 h09EfZJ27132 for ; Thu, 9 Jan 2003 09:41:35 -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 JAA11259 for ; Thu, 9 Jan 2003 09:29:20 -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 h09EehJ27069; Thu, 9 Jan 2003 09:40:43 -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 h09EZxJ26082 for ; Thu, 9 Jan 2003 09:35:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10852; Thu, 9 Jan 2003 09:23:45 -0500 (EST) Message-Id: <200301091423.JAA10852@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: Thu, 09 Jan 2003 09:23:45 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibif-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 Interface Type Author(s) : B. Anderson, S. Harnedy Filename : draft-ietf-ipoib-ibif-mib-04.txt Pages : 29 Date : 2003-1-8 InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture to deliver scalable performance in data centers. This memo defines a portion of Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IBA defined InfiniBand interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibif-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-ibif-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-ibif-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-1-9092350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ibif-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ibif-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092350.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon Jan 13 17:33:59 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 RAA26535 for ; Mon, 13 Jan 2003 17:33:59 -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 h0DMkSJ28987; Mon, 13 Jan 2003 17:46:28 -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 h0DMjXJ28931 for ; Mon, 13 Jan 2003 17:45:33 -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 RAA26473 for ; Mon, 13 Jan 2003 17:31:11 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25985 for ; Mon, 13 Jan 2003 14:34:31 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0DMYU4w002369 for ; Mon, 13 Jan 2003 14:34:30 -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 <0H8O00LCUC1IB3@ha1sun-mail1.eng.sun.com> for ipoverib@ietf.org; Mon, 13 Jan 2003 14:34:30 -0800 (PST) Date: Mon, 13 Jan 2003 14:34:30 -0800 From: Kanoj Sarcar To: ipoverib@ietf.org, Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E233EF6.EFB39FED@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/ifconfig question 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, Here's an IPoIB implementation issue that I would like to get feedback on from implementors. What should the ifconfig/arp/packet-sniffer output look like for the mac address part of an IPoIB interface? In the examples below, assume QPN=0x14, GID prefix is FE80::0 and GID suffix is 0002c900011c9781, so that the mac address in hex is 14FE800000000000000002c900011c9781. Some options might be 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 (or 0:14:FE80:0:0:0:2:c900:011c:9781) 3: 0:14:FE80::2:c900:011c:9781 I understand this is probably not something that should be put into any of the I/Ds, but it would be nice if various vendors' outputs matched. My choice is option 1, since it is the closest to how most systems represent ethernet addresses (except the length of course). Most systems' "arp" command is also easily converted to handle this format and obviates the need for complicated parsing. Note that the I/D http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt on page 8 section 8.0 represents IBA multicast GIDs in v6 format, I am not sure whether to suggest that the link layer address should also be represented similarly by network tools. For reference, here's the ifconfig output line that prints mac addresses on Solaris and Linux: Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E ether 8:0:20:d9:4:97 Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon Jan 13 17:34:00 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 RAA26542 for ; Mon, 13 Jan 2003 17:33:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DMlnQ29042 for ipoverib-archive@odin.ietf.org; Mon, 13 Jan 2003 17:47:49 -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 h0DMlnJ29039 for ; Mon, 13 Jan 2003 17:47:49 -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 RAA26530 for ; Mon, 13 Jan 2003 17:33:28 -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 h0DMkSJ28987; Mon, 13 Jan 2003 17:46:28 -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 h0DMjXJ28931 for ; Mon, 13 Jan 2003 17:45:33 -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 RAA26473 for ; Mon, 13 Jan 2003 17:31:11 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25985 for ; Mon, 13 Jan 2003 14:34:31 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0DMYU4w002369 for ; Mon, 13 Jan 2003 14:34:30 -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 <0H8O00LCUC1IB3@ha1sun-mail1.eng.sun.com> for ipoverib@ietf.org; Mon, 13 Jan 2003 14:34:30 -0800 (PST) Date: Mon, 13 Jan 2003 14:34:30 -0800 From: Kanoj Sarcar To: ipoverib@ietf.org, Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E233EF6.EFB39FED@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/ifconfig question 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, Here's an IPoIB implementation issue that I would like to get feedback on from implementors. What should the ifconfig/arp/packet-sniffer output look like for the mac address part of an IPoIB interface? In the examples below, assume QPN=0x14, GID prefix is FE80::0 and GID suffix is 0002c900011c9781, so that the mac address in hex is 14FE800000000000000002c900011c9781. Some options might be 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 (or 0:14:FE80:0:0:0:2:c900:011c:9781) 3: 0:14:FE80::2:c900:011c:9781 I understand this is probably not something that should be put into any of the I/Ds, but it would be nice if various vendors' outputs matched. My choice is option 1, since it is the closest to how most systems represent ethernet addresses (except the length of course). Most systems' "arp" command is also easily converted to handle this format and obviates the need for complicated parsing. Note that the I/D http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt on page 8 section 8.0 represents IBA multicast GIDs in v6 format, I am not sure whether to suggest that the link layer address should also be represented similarly by network tools. For reference, here's the ifconfig output line that prints mac addresses on Solaris and Linux: Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E ether 8:0:20:d9:4:97 Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon Jan 13 17: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 RAA27112 for ; Mon, 13 Jan 2003 17: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 h0DN38J29867; Mon, 13 Jan 2003 18:03: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 h0DN2LJ29824 for ; Mon, 13 Jan 2003 18:02:21 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27061 for ; Mon, 13 Jan 2003 17:48:00 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20330 for ; Mon, 13 Jan 2003 15:51:19 -0700 (MST) 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 h0DMpJgE011385 for ; Mon, 13 Jan 2003 14:51:19 -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 <0H8O00LXNCTJB3@ha1sun-mail1.eng.sun.com> for ipoverib@ietf.org; Mon, 13 Jan 2003 14:51:19 -0800 (PST) Date: Mon, 13 Jan 2003 14:51:19 -0800 From: Kanoj Sarcar To: ipoverib@ietf.org, Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E2342E7.27A73988@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] ifPhysAddress question 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 a question on the I/D http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibif-mib-04.txt section 2.2.5 on ifPhysAddress. Why is the ifPhysAddress being chosen to be the 16 bit LID, when it might very well be the mac address as proposed section 6.1.1 in the I/D http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband-01.txt I would think redefining the ifPhysAddress to be the mac address for HCAs (with switches special cased as required) will be more useful, in the sense that sysadmins would be able to match output from "arp" commands with output from snmp information. Otherwise, it seems to me that a special command will need to be used to establish the correspondence between SNMP information and arp command output. Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon Jan 13 17: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 RAA27125 for ; Mon, 13 Jan 2003 17:50:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DN40c29928 for ipoverib-archive@odin.ietf.org; Mon, 13 Jan 2003 18:04:00 -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 h0DN40J29923 for ; Mon, 13 Jan 2003 18:04:00 -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 RAA27086 for ; Mon, 13 Jan 2003 17: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 h0DN38J29867; Mon, 13 Jan 2003 18:03: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 h0DN2LJ29824 for ; Mon, 13 Jan 2003 18:02:21 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27061 for ; Mon, 13 Jan 2003 17:48:00 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20330 for ; Mon, 13 Jan 2003 15:51:19 -0700 (MST) 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 h0DMpJgE011385 for ; Mon, 13 Jan 2003 14:51:19 -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 <0H8O00LXNCTJB3@ha1sun-mail1.eng.sun.com> for ipoverib@ietf.org; Mon, 13 Jan 2003 14:51:19 -0800 (PST) Date: Mon, 13 Jan 2003 14:51:19 -0800 From: Kanoj Sarcar To: ipoverib@ietf.org, Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E2342E7.27A73988@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] ifPhysAddress question 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 a question on the I/D http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibif-mib-04.txt section 2.2.5 on ifPhysAddress. Why is the ifPhysAddress being chosen to be the 16 bit LID, when it might very well be the mac address as proposed section 6.1.1 in the I/D http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband-01.txt I would think redefining the ifPhysAddress to be the mac address for HCAs (with switches special cased as required) will be more useful, in the sense that sysadmins would be able to match output from "arp" commands with output from snmp information. Otherwise, it seems to me that a special command will need to be used to establish the correspondence between SNMP information and arp command output. Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue Jan 14 13:40: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 NAA06203 for ; Tue, 14 Jan 2003 13:40: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 h0EIrHJ21183; Tue, 14 Jan 2003 13:53: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 h0EIqwJ21144 for ; Tue, 14 Jan 2003 13:52:58 -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 NAA06184 for ; Tue, 14 Jan 2003 13:38:11 -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 h0EIa1t24430 for ; Tue, 14 Jan 2003 18:36:03 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 h0EIaah15537 for ; Tue, 14 Jan 2003 18:36:36 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011410393218131 ; Tue, 14 Jan 2003 10:39:32 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 10:41:28 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@sun.com'" , ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Tue, 14 Jan 2003 10:41:23 -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, While not a draft issue, I agree that it would be nice to use this forum to set a de facto standard for IPoIB hardware address display format. Given the long length, I'm inclined to go with the most condensed representation which would be #3. However, this does not provide a fixed length display which is useful for scripting applications so I'm thinking a modified #2 with all fixed length numbers and a single field QPN of 0014 instead of 0:14). Roy -----Original Message----- From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] Sent: Monday, January 13, 2003 2:35 PM To: ipoverib@ietf.org; Kanoj Sarcar Subject: [Ipoverib] IPoIB/ifconfig question Hi, Here's an IPoIB implementation issue that I would like to get feedback on from implementors. What should the ifconfig/arp/packet-sniffer output look like for the mac address part of an IPoIB interface? In the examples below, assume QPN=0x14, GID prefix is FE80::0 and GID suffix is 0002c900011c9781, so that the mac address in hex is 14FE800000000000000002c900011c9781. Some options might be 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 (or 0:14:FE80:0:0:0:2:c900:011c:9781) 3: 0:14:FE80::2:c900:011c:9781 I understand this is probably not something that should be put into any of the I/Ds, but it would be nice if various vendors' outputs matched. My choice is option 1, since it is the closest to how most systems represent ethernet addresses (except the length of course). Most systems' "arp" command is also easily converted to handle this format and obviates the need for complicated parsing. Note that the I/D http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt on page 8 section 8.0 represents IBA multicast GIDs in v6 format, I am not sure whether to suggest that the link layer address should also be represented similarly by network tools. For reference, here's the ifconfig output line that prints mac addresses on Solaris and Linux: Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E ether 8:0:20:d9:4:97 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 Tue Jan 14 13:40: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 NAA06213 for ; Tue, 14 Jan 2003 13:40:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EIsHg21239 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 13:54: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 h0EIsHJ21236 for ; Tue, 14 Jan 2003 13:54:17 -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 NAA06194 for ; Tue, 14 Jan 2003 13:39:31 -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 h0EIrHJ21183; Tue, 14 Jan 2003 13:53: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 h0EIqwJ21144 for ; Tue, 14 Jan 2003 13:52:58 -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 NAA06184 for ; Tue, 14 Jan 2003 13:38:11 -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 h0EIa1t24430 for ; Tue, 14 Jan 2003 18:36:03 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 h0EIaah15537 for ; Tue, 14 Jan 2003 18:36:36 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011410393218131 ; Tue, 14 Jan 2003 10:39:32 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 10:41:28 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@sun.com'" , ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Tue, 14 Jan 2003 10:41:23 -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, While not a draft issue, I agree that it would be nice to use this forum to set a de facto standard for IPoIB hardware address display format. Given the long length, I'm inclined to go with the most condensed representation which would be #3. However, this does not provide a fixed length display which is useful for scripting applications so I'm thinking a modified #2 with all fixed length numbers and a single field QPN of 0014 instead of 0:14). Roy -----Original Message----- From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] Sent: Monday, January 13, 2003 2:35 PM To: ipoverib@ietf.org; Kanoj Sarcar Subject: [Ipoverib] IPoIB/ifconfig question Hi, Here's an IPoIB implementation issue that I would like to get feedback on from implementors. What should the ifconfig/arp/packet-sniffer output look like for the mac address part of an IPoIB interface? In the examples below, assume QPN=0x14, GID prefix is FE80::0 and GID suffix is 0002c900011c9781, so that the mac address in hex is 14FE800000000000000002c900011c9781. Some options might be 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 (or 0:14:FE80:0:0:0:2:c900:011c:9781) 3: 0:14:FE80::2:c900:011c:9781 I understand this is probably not something that should be put into any of the I/Ds, but it would be nice if various vendors' outputs matched. My choice is option 1, since it is the closest to how most systems represent ethernet addresses (except the length of course). Most systems' "arp" command is also easily converted to handle this format and obviates the need for complicated parsing. Note that the I/D http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt on page 8 section 8.0 represents IBA multicast GIDs in v6 format, I am not sure whether to suggest that the link layer address should also be represented similarly by network tools. For reference, here's the ifconfig output line that prints mac addresses on Solaris and Linux: Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E ether 8:0:20:d9:4:97 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 Tue Jan 14 13:59: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 NAA07063 for ; Tue, 14 Jan 2003 13:59:10 -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 h0EJC8J22726; Tue, 14 Jan 2003 14:12: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 h0EJBeJ22662 for ; Tue, 14 Jan 2003 14:11:40 -0500 Received: from nwkea-mail-2.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06962 for ; Tue, 14 Jan 2003 13:56:54 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22695; Tue, 14 Jan 2003 11:00:14 -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 h0EJ0DgE014900; Tue, 14 Jan 2003 11:00:13 -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 <0H8P00F0DWSCCM@ha1sun-mail1.eng.sun.com>; Tue, 14 Jan 2003 11:00:13 -0800 (PST) Date: Tue, 14 Jan 2003 11:00:12 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question To: "Larsen, Roy K" Cc: ipoverib@ietf.org, Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E245E3C.8581889@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, > > While not a draft issue, I agree that it would be nice to use this forum to > set a de facto standard for IPoIB hardware address display format. Given > the long length, I'm inclined to go with the most condensed representation > which would be #3. However, this does not provide a fixed length display > which is useful for scripting applications so I'm thinking a modified #2 > with all fixed length numbers and a single field QPN of 0014 instead of > 0:14). > > Roy > Roy, It was pointed out to me that http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt has IbGuid ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION It would seem to me that unless there is good reason for deviation, tcpdump/snoop/ifconfig/arp et al could just use this format (maps to option 1). Another reason I prefer 1 is because scripts written with the ethernet format in mind would mostly work (if the length issues were fixed in the script). Option 2 packs 16 bits in between each :, whereas these ethernet based scripts pack 8 bits. What do you think? The reason I went with 0:14 for the QPN (in #3) is because the QPN is actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 could be a possible value (theoretically). To represent that, I would need to say 12:3456:... I wanted this to look the same (in terms of number of :s) as in the case of QPN=0x00000014. Or are you suggesting something like 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 in this case? Thanks. Kanoj > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Monday, January 13, 2003 2:35 PM > To: ipoverib@ietf.org; Kanoj Sarcar > Subject: [Ipoverib] IPoIB/ifconfig question > > Hi, > > Here's an IPoIB implementation issue that I would > like to get feedback on from implementors. > > What should the ifconfig/arp/packet-sniffer output look like for > the mac address part of an IPoIB interface? In the examples below, > assume QPN=0x14, GID prefix is FE80::0 and GID suffix is > 0002c900011c9781, so that the mac address in hex is > 14FE800000000000000002c900011c9781. > > Some options might be > > 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 0:14:FE80:0:0:0:2:c900:011c:9781) > 3: 0:14:FE80::2:c900:011c:9781 > > I understand this is probably not something that should be > put into any of the I/Ds, but it would be nice if various > vendors' outputs matched. My choice is option 1, since it > is the closest to how most systems represent ethernet > addresses (except the length of course). Most systems' > "arp" command is also easily converted to handle this > format and obviates the need for complicated parsing. > > Note that the I/D > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt > > on page 8 section 8.0 represents IBA multicast GIDs in v6 > format, I am not sure whether to suggest that the link layer > address should also be represented similarly by network tools. > > For reference, here's the ifconfig output line that prints > mac addresses on Solaris and Linux: > Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E > ether 8:0:20:d9:4:97 > > 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 Tue Jan 14 13:59: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 NAA07073 for ; Tue, 14 Jan 2003 13:59:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJDQE22829 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 14:13:26 -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 h0EJDQJ22826 for ; Tue, 14 Jan 2003 14:13:26 -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 NAA07034 for ; Tue, 14 Jan 2003 13:58:39 -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 h0EJC8J22726; Tue, 14 Jan 2003 14:12: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 h0EJBeJ22662 for ; Tue, 14 Jan 2003 14:11:40 -0500 Received: from nwkea-mail-2.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06962 for ; Tue, 14 Jan 2003 13:56:54 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22695; Tue, 14 Jan 2003 11:00:14 -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 h0EJ0DgE014900; Tue, 14 Jan 2003 11:00:13 -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 <0H8P00F0DWSCCM@ha1sun-mail1.eng.sun.com>; Tue, 14 Jan 2003 11:00:13 -0800 (PST) Date: Tue, 14 Jan 2003 11:00:12 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question To: "Larsen, Roy K" Cc: ipoverib@ietf.org, Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E245E3C.8581889@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, > > While not a draft issue, I agree that it would be nice to use this forum to > set a de facto standard for IPoIB hardware address display format. Given > the long length, I'm inclined to go with the most condensed representation > which would be #3. However, this does not provide a fixed length display > which is useful for scripting applications so I'm thinking a modified #2 > with all fixed length numbers and a single field QPN of 0014 instead of > 0:14). > > Roy > Roy, It was pointed out to me that http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt has IbGuid ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION It would seem to me that unless there is good reason for deviation, tcpdump/snoop/ifconfig/arp et al could just use this format (maps to option 1). Another reason I prefer 1 is because scripts written with the ethernet format in mind would mostly work (if the length issues were fixed in the script). Option 2 packs 16 bits in between each :, whereas these ethernet based scripts pack 8 bits. What do you think? The reason I went with 0:14 for the QPN (in #3) is because the QPN is actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 could be a possible value (theoretically). To represent that, I would need to say 12:3456:... I wanted this to look the same (in terms of number of :s) as in the case of QPN=0x00000014. Or are you suggesting something like 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 in this case? Thanks. Kanoj > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Monday, January 13, 2003 2:35 PM > To: ipoverib@ietf.org; Kanoj Sarcar > Subject: [Ipoverib] IPoIB/ifconfig question > > Hi, > > Here's an IPoIB implementation issue that I would > like to get feedback on from implementors. > > What should the ifconfig/arp/packet-sniffer output look like for > the mac address part of an IPoIB interface? In the examples below, > assume QPN=0x14, GID prefix is FE80::0 and GID suffix is > 0002c900011c9781, so that the mac address in hex is > 14FE800000000000000002c900011c9781. > > Some options might be > > 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 0:14:FE80:0:0:0:2:c900:011c:9781) > 3: 0:14:FE80::2:c900:011c:9781 > > I understand this is probably not something that should be > put into any of the I/Ds, but it would be nice if various > vendors' outputs matched. My choice is option 1, since it > is the closest to how most systems represent ethernet > addresses (except the length of course). Most systems' > "arp" command is also easily converted to handle this > format and obviates the need for complicated parsing. > > Note that the I/D > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt > > on page 8 section 8.0 represents IBA multicast GIDs in v6 > format, I am not sure whether to suggest that the link layer > address should also be represented similarly by network tools. > > For reference, here's the ifconfig output line that prints > mac addresses on Solaris and Linux: > Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E > ether 8:0:20:d9:4:97 > > 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 Tue Jan 14 14:25:04 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 OAA08317 for ; Tue, 14 Jan 2003 14:25:04 -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 h0EJcEJ24931; Tue, 14 Jan 2003 14:38: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 h0EJbLJ24584 for ; Tue, 14 Jan 2003 14:37:21 -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 OAA08226 for ; Tue, 14 Jan 2003 14:22:33 -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 h0EJNIr09611 for ; Tue, 14 Jan 2003 19:23:19 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 h0EJL0s29598 for ; Tue, 14 Jan 2003 19:21:00 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011411273418707 ; Tue, 14 Jan 2003 11:27:34 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 11:25:53 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@Sun.COM'" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Tue, 14 Jan 2003 11:25:53 -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: , Ah yes, 24 bits.... I had a brain fart and was thinking the QPN was 16. Then if fixed length is desirable, what you show for #4 is better than the 60 digit #1 (regardless of what the mib draft proposes). It just isn't practical to display 60 characters (although 47 characters is pretty much in the same camp) and is not very parsable by a human. Remember, this sequence would be displayed for things like ifconfig(8) and arp(8) which are fairly frequent administrative operations. I still like #3 but since I don't do much network administration, I don't know what the impact of a variable length hardware address would have. The network admin tools I work with already use a hardware type based library for displaying interface specific information so there is no need to follow Ethernet convention from my point of view. Roy -----Original Message----- From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] Sent: Tuesday, January 14, 2003 11:00 AM To: Larsen, Roy K Cc: ipoverib@ietf.org; Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question "Larsen, Roy K" wrote: > > Kanoj, > > While not a draft issue, I agree that it would be nice to use this forum to > set a de facto standard for IPoIB hardware address display format. Given > the long length, I'm inclined to go with the most condensed representation > which would be #3. However, this does not provide a fixed length display > which is useful for scripting applications so I'm thinking a modified #2 > with all fixed length numbers and a single field QPN of 0014 instead of > 0:14). > > Roy > Roy, It was pointed out to me that http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt has IbGuid ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION It would seem to me that unless there is good reason for deviation, tcpdump/snoop/ifconfig/arp et al could just use this format (maps to option 1). Another reason I prefer 1 is because scripts written with the ethernet format in mind would mostly work (if the length issues were fixed in the script). Option 2 packs 16 bits in between each :, whereas these ethernet based scripts pack 8 bits. What do you think? The reason I went with 0:14 for the QPN (in #3) is because the QPN is actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 could be a possible value (theoretically). To represent that, I would need to say 12:3456:... I wanted this to look the same (in terms of number of :s) as in the case of QPN=0x00000014. Or are you suggesting something like 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 in this case? Thanks. Kanoj > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Monday, January 13, 2003 2:35 PM > To: ipoverib@ietf.org; Kanoj Sarcar > Subject: [Ipoverib] IPoIB/ifconfig question > > Hi, > > Here's an IPoIB implementation issue that I would > like to get feedback on from implementors. > > What should the ifconfig/arp/packet-sniffer output look like for > the mac address part of an IPoIB interface? In the examples below, > assume QPN=0x14, GID prefix is FE80::0 and GID suffix is > 0002c900011c9781, so that the mac address in hex is > 14FE800000000000000002c900011c9781. > > Some options might be > > 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 0:14:FE80:0:0:0:2:c900:011c:9781) > 3: 0:14:FE80::2:c900:011c:9781 > > I understand this is probably not something that should be > put into any of the I/Ds, but it would be nice if various > vendors' outputs matched. My choice is option 1, since it > is the closest to how most systems represent ethernet > addresses (except the length of course). Most systems' > "arp" command is also easily converted to handle this > format and obviates the need for complicated parsing. > > Note that the I/D > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt > > on page 8 section 8.0 represents IBA multicast GIDs in v6 > format, I am not sure whether to suggest that the link layer > address should also be represented similarly by network tools. > > For reference, here's the ifconfig output line that prints > mac addresses on Solaris and Linux: > Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E > ether 8:0:20:d9:4:97 > > 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 Tue Jan 14 14:25:05 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 OAA08337 for ; Tue, 14 Jan 2003 14:25:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJdLB25002 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 14:39: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 h0EJdLJ24999 for ; Tue, 14 Jan 2003 14:39:21 -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 OAA08290 for ; Tue, 14 Jan 2003 14:24:33 -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 h0EJcEJ24931; Tue, 14 Jan 2003 14:38: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 h0EJbLJ24584 for ; Tue, 14 Jan 2003 14:37:21 -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 OAA08226 for ; Tue, 14 Jan 2003 14:22:33 -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 h0EJNIr09611 for ; Tue, 14 Jan 2003 19:23:19 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 h0EJL0s29598 for ; Tue, 14 Jan 2003 19:21:00 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011411273418707 ; Tue, 14 Jan 2003 11:27:34 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 11:25:53 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@Sun.COM'" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Tue, 14 Jan 2003 11:25:53 -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: , Ah yes, 24 bits.... I had a brain fart and was thinking the QPN was 16. Then if fixed length is desirable, what you show for #4 is better than the 60 digit #1 (regardless of what the mib draft proposes). It just isn't practical to display 60 characters (although 47 characters is pretty much in the same camp) and is not very parsable by a human. Remember, this sequence would be displayed for things like ifconfig(8) and arp(8) which are fairly frequent administrative operations. I still like #3 but since I don't do much network administration, I don't know what the impact of a variable length hardware address would have. The network admin tools I work with already use a hardware type based library for displaying interface specific information so there is no need to follow Ethernet convention from my point of view. Roy -----Original Message----- From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] Sent: Tuesday, January 14, 2003 11:00 AM To: Larsen, Roy K Cc: ipoverib@ietf.org; Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question "Larsen, Roy K" wrote: > > Kanoj, > > While not a draft issue, I agree that it would be nice to use this forum to > set a de facto standard for IPoIB hardware address display format. Given > the long length, I'm inclined to go with the most condensed representation > which would be #3. However, this does not provide a fixed length display > which is useful for scripting applications so I'm thinking a modified #2 > with all fixed length numbers and a single field QPN of 0014 instead of > 0:14). > > Roy > Roy, It was pointed out to me that http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt has IbGuid ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION It would seem to me that unless there is good reason for deviation, tcpdump/snoop/ifconfig/arp et al could just use this format (maps to option 1). Another reason I prefer 1 is because scripts written with the ethernet format in mind would mostly work (if the length issues were fixed in the script). Option 2 packs 16 bits in between each :, whereas these ethernet based scripts pack 8 bits. What do you think? The reason I went with 0:14 for the QPN (in #3) is because the QPN is actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 could be a possible value (theoretically). To represent that, I would need to say 12:3456:... I wanted this to look the same (in terms of number of :s) as in the case of QPN=0x00000014. Or are you suggesting something like 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 in this case? Thanks. Kanoj > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > Sent: Monday, January 13, 2003 2:35 PM > To: ipoverib@ietf.org; Kanoj Sarcar > Subject: [Ipoverib] IPoIB/ifconfig question > > Hi, > > Here's an IPoIB implementation issue that I would > like to get feedback on from implementors. > > What should the ifconfig/arp/packet-sniffer output look like for > the mac address part of an IPoIB interface? In the examples below, > assume QPN=0x14, GID prefix is FE80::0 and GID suffix is > 0002c900011c9781, so that the mac address in hex is > 14FE800000000000000002c900011c9781. > > Some options might be > > 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 0:14:FE80:0:0:0:2:c900:011c:9781) > 3: 0:14:FE80::2:c900:011c:9781 > > I understand this is probably not something that should be > put into any of the I/Ds, but it would be nice if various > vendors' outputs matched. My choice is option 1, since it > is the closest to how most systems represent ethernet > addresses (except the length of course). Most systems' > "arp" command is also easily converted to handle this > format and obviates the need for complicated parsing. > > Note that the I/D > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt > > on page 8 section 8.0 represents IBA multicast GIDs in v6 > format, I am not sure whether to suggest that the link layer > address should also be represented similarly by network tools. > > For reference, here's the ifconfig output line that prints > mac addresses on Solaris and Linux: > Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E > ether 8:0:20:d9:4:97 > > 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 Tue Jan 14 15:25:56 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 PAA10398 for ; Tue, 14 Jan 2003 15:25:56 -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 h0EKdFJ30095; Tue, 14 Jan 2003 15:39:15 -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 h0EKcnJ30071 for ; Tue, 14 Jan 2003 15:38:49 -0500 Received: from umhlanga.STRATNET.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10361 for ; Tue, 14 Jan 2003 15:24:00 -0500 (EST) Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 12:27:21 -0800 Received: from gold ([10.10.253.60] unverified) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 12:27:00 -0800 Received: from roland by gold with local (Exim 3.35 #1 (Debian)) id 18YXeY-0007UJ-00 for ; Tue, 14 Jan 2003 12:27:18 -0800 To: ipoverib@ietf.org Subject: Re: [Ipoverib] IPoIB/ifconfig question References: X-Message-Flag: Warning: May contain useful information X-Priority: 1 X-MSMail-Priority: High From: Roland Dreier Date: 14 Jan 2003 12:27:18 -0800 In-Reply-To: Message-ID: <52d6mzmq8p.fsf@topspin.com> Lines: 6 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 14 Jan 2003 20:27:01.0000 (UTC) FILETIME=[4B131880:01C2BC0B] 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: , One thing to think about in regards to how to display a HW address is the fact that a GID technically _is_ an IPv6 address, so it might make sense to display it as one. Best, Roland _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue Jan 14 15:25:57 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 PAA10405 for ; Tue, 14 Jan 2003 15:25:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKeED30194 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 15:40: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 h0EKeEJ30191 for ; Tue, 14 Jan 2003 15:40: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 PAA10376 for ; Tue, 14 Jan 2003 15:25:26 -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 h0EKdFJ30095; Tue, 14 Jan 2003 15:39:15 -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 h0EKcnJ30071 for ; Tue, 14 Jan 2003 15:38:49 -0500 Received: from umhlanga.STRATNET.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10361 for ; Tue, 14 Jan 2003 15:24:00 -0500 (EST) Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 12:27:21 -0800 Received: from gold ([10.10.253.60] unverified) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 12:27:00 -0800 Received: from roland by gold with local (Exim 3.35 #1 (Debian)) id 18YXeY-0007UJ-00 for ; Tue, 14 Jan 2003 12:27:18 -0800 To: ipoverib@ietf.org Subject: Re: [Ipoverib] IPoIB/ifconfig question References: X-Message-Flag: Warning: May contain useful information X-Priority: 1 X-MSMail-Priority: High From: Roland Dreier Date: 14 Jan 2003 12:27:18 -0800 In-Reply-To: Message-ID: <52d6mzmq8p.fsf@topspin.com> Lines: 6 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 14 Jan 2003 20:27:01.0000 (UTC) FILETIME=[4B131880:01C2BC0B] 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: , One thing to think about in regards to how to display a HW address is the fact that a GID technically _is_ an IPv6 address, so it might make sense to display it as one. Best, Roland _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue Jan 14 15:43:46 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 PAA10940 for ; Tue, 14 Jan 2003 15:43:46 -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 h0EKv5J31603; Tue, 14 Jan 2003 15:57:05 -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 h0EKuuJ31522 for ; Tue, 14 Jan 2003 15:56:56 -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 PAA10869 for ; Tue, 14 Jan 2003 15:42:06 -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 MAA06948; Tue, 14 Jan 2003 12:45:25 -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 h0EKjOgE023454; Tue, 14 Jan 2003 12:45:24 -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 <0H8Q00FJ31NOCM@ha1sun-mail1.eng.sun.com>; Tue, 14 Jan 2003 12:45:24 -0800 (PST) Date: Tue, 14 Jan 2003 12:45:24 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question To: "Larsen, Roy K" Cc: ipoverib@ietf.org, Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E2476E4.C764268D@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: > > Ah yes, 24 bits.... I had a brain fart and was thinking the QPN was 16. > Then if fixed length is desirable, what you show for #4 is better than the > 60 digit #1 (regardless of what the mib draft proposes). It just isn't > practical to display 60 characters (although 47 characters is pretty much in > the same camp) and is not very parsable by a human. Remember, this sequence > would be displayed for things like ifconfig(8) and arp(8) which are fairly > frequent administrative operations. I still like #3 but since I don't do > much network administration, I don't know what the impact of a variable > length hardware address would have. I think we are down to #1 and #4, right? (Another point against #3 is that it *might* be confusing to have a v6 protocol layer addressing scheme applied to a link layer address; specially since the link layer address is not 128bits long). Here they are (with QPN=0x123456): 1. 00:12:34:56:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 (or 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 (or 123456:FE80:0:0:0:2:c900:11c:9781) Given the irregularity (length wise) in the first few digits in 4, I would think #2 would be better. Here it is: 2. 12:3456:FE80:0000:0000:0000:0002:c900:011c:9781 (or 12:3456:FE80:0:0:0:2:c900:11c:9781) I do have a preference for #1 still, primarily because a. it is the most easily adapatable to the "arp" command (ie, when you are doing a "set" operation, it is very easy to teach "arp", which on most systems currently only expect ethernet addresses, how to parse a #1 style ib command, in contrast to #2 or #4). Any other format picked can of course be handled, I have seen the least amount of work with #1 while prototyping (I am dealing with Solaris, but I expect that to be true on most other systems like BSD too; Linux has a -H option, so this is not an issue). b. I do believe there is value in matching the MIB format, specially since admins might want to correlate the outputs from various commands (ifconfig, arp, snoop and SNMP). c. Any current scripts that parse ethernet addresses (HWaddr output in Linux etc) if applicable on IPoIB would need to be converted; I am not aware of any, but if there are some, logic in a. again applies. The advantage of 2 and 4 are their somewhat shorter lengths. > > The network admin tools I work with already use a hardware type based > library for displaying interface specific information so there is no need to > follow Ethernet convention from my point of view. > What about (sysadmin) scripts that parse output from ifconfig (ie look at HWaddr field), which currently assume ethernet format? I assume you are talking about Linux (and thus you have the -H arp option to help)? Notice, you could still build in automatic parsing in Linux "arp", which on seeing format #1 will recognize it as an IPoIB address (ie, the default type for 20b addresses can be IPoIB, similar to the default type for 6b addresses is ethernet; this would allow admins not to have to specify -H for each IPoIB operation, thus making IPoIB just a little more similar to ethernet); I imagine it will be just a little harder to do #2 or #4. Thanks. Kanoj > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] > Sent: Tuesday, January 14, 2003 11:00 AM > To: Larsen, Roy K > Cc: ipoverib@ietf.org; Kanoj Sarcar > Subject: Re: [Ipoverib] IPoIB/ifconfig question > > "Larsen, Roy K" wrote: > > > > Kanoj, > > > > While not a draft issue, I agree that it would be nice to use this forum > to > > set a de facto standard for IPoIB hardware address display format. Given > > the long length, I'm inclined to go with the most condensed representation > > which would be #3. However, this does not provide a fixed length display > > which is useful for scripting applications so I'm thinking a modified #2 > > with all fixed length numbers and a single field QPN of 0014 instead of > > 0:14). > > > > Roy > > > > Roy, > > It was pointed out to me that > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt > > has > > IbGuid ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1x:" > STATUS current > DESCRIPTION > > It would seem to me that unless there is good reason for deviation, > tcpdump/snoop/ifconfig/arp et al could just use this format (maps to > option 1). > > Another reason I prefer 1 is because scripts written with the ethernet > format in mind would mostly work (if the length issues were fixed in > the script). Option 2 packs 16 bits in between each :, whereas these > ethernet based scripts pack 8 bits. > > What do you think? > > The reason I went with 0:14 for the QPN (in #3) is because the QPN is > actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 > could be a possible value (theoretically). To represent that, I would > need to say 12:3456:... I wanted this to look the same (in terms of > number of :s) as in the case of QPN=0x00000014. Or are you suggesting > something like > > 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > > in this case? > > Thanks. > > Kanoj > > > -----Original Message----- > > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > > Sent: Monday, January 13, 2003 2:35 PM > > To: ipoverib@ietf.org; Kanoj Sarcar > > Subject: [Ipoverib] IPoIB/ifconfig question > > > > Hi, > > > > Here's an IPoIB implementation issue that I would > > like to get feedback on from implementors. > > > > What should the ifconfig/arp/packet-sniffer output look like for > > the mac address part of an IPoIB interface? In the examples below, > > assume QPN=0x14, GID prefix is FE80::0 and GID suffix is > > 0002c900011c9781, so that the mac address in hex is > > 14FE800000000000000002c900011c9781. > > > > Some options might be > > > > 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > > (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > > 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 > > (or 0:14:FE80:0:0:0:2:c900:011c:9781) > > 3: 0:14:FE80::2:c900:011c:9781 > > > > I understand this is probably not something that should be > > put into any of the I/Ds, but it would be nice if various > > vendors' outputs matched. My choice is option 1, since it > > is the closest to how most systems represent ethernet > > addresses (except the length of course). Most systems' > > "arp" command is also easily converted to handle this > > format and obviates the need for complicated parsing. > > > > Note that the I/D > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt > > > > on page 8 section 8.0 represents IBA multicast GIDs in v6 > > format, I am not sure whether to suggest that the link layer > > address should also be represented similarly by network tools. > > > > For reference, here's the ifconfig output line that prints > > mac addresses on Solaris and Linux: > > Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E > > ether 8:0:20:d9:4:97 > > > > 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 Tue Jan 14 15:43:47 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 PAA10951 for ; Tue, 14 Jan 2003 15:43:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKw5o31949 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 15:58:05 -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 h0EKw5J31946 for ; Tue, 14 Jan 2003 15:58:05 -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 PAA10923 for ; Tue, 14 Jan 2003 15:43:15 -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 h0EKv5J31603; Tue, 14 Jan 2003 15:57:05 -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 h0EKuuJ31522 for ; Tue, 14 Jan 2003 15:56:56 -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 PAA10869 for ; Tue, 14 Jan 2003 15:42:06 -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 MAA06948; Tue, 14 Jan 2003 12:45:25 -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 h0EKjOgE023454; Tue, 14 Jan 2003 12:45:24 -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 <0H8Q00FJ31NOCM@ha1sun-mail1.eng.sun.com>; Tue, 14 Jan 2003 12:45:24 -0800 (PST) Date: Tue, 14 Jan 2003 12:45:24 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question To: "Larsen, Roy K" Cc: ipoverib@ietf.org, Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E2476E4.C764268D@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: > > Ah yes, 24 bits.... I had a brain fart and was thinking the QPN was 16. > Then if fixed length is desirable, what you show for #4 is better than the > 60 digit #1 (regardless of what the mib draft proposes). It just isn't > practical to display 60 characters (although 47 characters is pretty much in > the same camp) and is not very parsable by a human. Remember, this sequence > would be displayed for things like ifconfig(8) and arp(8) which are fairly > frequent administrative operations. I still like #3 but since I don't do > much network administration, I don't know what the impact of a variable > length hardware address would have. I think we are down to #1 and #4, right? (Another point against #3 is that it *might* be confusing to have a v6 protocol layer addressing scheme applied to a link layer address; specially since the link layer address is not 128bits long). Here they are (with QPN=0x123456): 1. 00:12:34:56:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 (or 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 (or 123456:FE80:0:0:0:2:c900:11c:9781) Given the irregularity (length wise) in the first few digits in 4, I would think #2 would be better. Here it is: 2. 12:3456:FE80:0000:0000:0000:0002:c900:011c:9781 (or 12:3456:FE80:0:0:0:2:c900:11c:9781) I do have a preference for #1 still, primarily because a. it is the most easily adapatable to the "arp" command (ie, when you are doing a "set" operation, it is very easy to teach "arp", which on most systems currently only expect ethernet addresses, how to parse a #1 style ib command, in contrast to #2 or #4). Any other format picked can of course be handled, I have seen the least amount of work with #1 while prototyping (I am dealing with Solaris, but I expect that to be true on most other systems like BSD too; Linux has a -H option, so this is not an issue). b. I do believe there is value in matching the MIB format, specially since admins might want to correlate the outputs from various commands (ifconfig, arp, snoop and SNMP). c. Any current scripts that parse ethernet addresses (HWaddr output in Linux etc) if applicable on IPoIB would need to be converted; I am not aware of any, but if there are some, logic in a. again applies. The advantage of 2 and 4 are their somewhat shorter lengths. > > The network admin tools I work with already use a hardware type based > library for displaying interface specific information so there is no need to > follow Ethernet convention from my point of view. > What about (sysadmin) scripts that parse output from ifconfig (ie look at HWaddr field), which currently assume ethernet format? I assume you are talking about Linux (and thus you have the -H arp option to help)? Notice, you could still build in automatic parsing in Linux "arp", which on seeing format #1 will recognize it as an IPoIB address (ie, the default type for 20b addresses can be IPoIB, similar to the default type for 6b addresses is ethernet; this would allow admins not to have to specify -H for each IPoIB operation, thus making IPoIB just a little more similar to ethernet); I imagine it will be just a little harder to do #2 or #4. Thanks. Kanoj > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] > Sent: Tuesday, January 14, 2003 11:00 AM > To: Larsen, Roy K > Cc: ipoverib@ietf.org; Kanoj Sarcar > Subject: Re: [Ipoverib] IPoIB/ifconfig question > > "Larsen, Roy K" wrote: > > > > Kanoj, > > > > While not a draft issue, I agree that it would be nice to use this forum > to > > set a de facto standard for IPoIB hardware address display format. Given > > the long length, I'm inclined to go with the most condensed representation > > which would be #3. However, this does not provide a fixed length display > > which is useful for scripting applications so I'm thinking a modified #2 > > with all fixed length numbers and a single field QPN of 0014 instead of > > 0:14). > > > > Roy > > > > Roy, > > It was pointed out to me that > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt > > has > > IbGuid ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1x:" > STATUS current > DESCRIPTION > > It would seem to me that unless there is good reason for deviation, > tcpdump/snoop/ifconfig/arp et al could just use this format (maps to > option 1). > > Another reason I prefer 1 is because scripts written with the ethernet > format in mind would mostly work (if the length issues were fixed in > the script). Option 2 packs 16 bits in between each :, whereas these > ethernet based scripts pack 8 bits. > > What do you think? > > The reason I went with 0:14 for the QPN (in #3) is because the QPN is > actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 > could be a possible value (theoretically). To represent that, I would > need to say 12:3456:... I wanted this to look the same (in terms of > number of :s) as in the case of QPN=0x00000014. Or are you suggesting > something like > > 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > > in this case? > > Thanks. > > Kanoj > > > -----Original Message----- > > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > > Sent: Monday, January 13, 2003 2:35 PM > > To: ipoverib@ietf.org; Kanoj Sarcar > > Subject: [Ipoverib] IPoIB/ifconfig question > > > > Hi, > > > > Here's an IPoIB implementation issue that I would > > like to get feedback on from implementors. > > > > What should the ifconfig/arp/packet-sniffer output look like for > > the mac address part of an IPoIB interface? In the examples below, > > assume QPN=0x14, GID prefix is FE80::0 and GID suffix is > > 0002c900011c9781, so that the mac address in hex is > > 14FE800000000000000002c900011c9781. > > > > Some options might be > > > > 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > > (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > > 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 > > (or 0:14:FE80:0:0:0:2:c900:011c:9781) > > 3: 0:14:FE80::2:c900:011c:9781 > > > > I understand this is probably not something that should be > > put into any of the I/Ds, but it would be nice if various > > vendors' outputs matched. My choice is option 1, since it > > is the closest to how most systems represent ethernet > > addresses (except the length of course). Most systems' > > "arp" command is also easily converted to handle this > > format and obviates the need for complicated parsing. > > > > Note that the I/D > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt > > > > on page 8 section 8.0 represents IBA multicast GIDs in v6 > > format, I am not sure whether to suggest that the link layer > > address should also be represented similarly by network tools. > > > > For reference, here's the ifconfig output line that prints > > mac addresses on Solaris and Linux: > > Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E > > ether 8:0:20:d9:4:97 > > > > 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 Tue Jan 14 16:49:59 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 QAA12974 for ; Tue, 14 Jan 2003 16:49:59 -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 h0EM3CJ05315; Tue, 14 Jan 2003 17:03: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 h0EM2JJ05273 for ; Tue, 14 Jan 2003 17:02:19 -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 QAA12890 for ; Tue, 14 Jan 2003 16:47:29 -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 h0ELm7s01420 for ; Tue, 14 Jan 2003 21:48:12 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 h0ELjiJ18202 for ; Tue, 14 Jan 2003 21:45:44 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011413521729154 ; Tue, 14 Jan 2003 13:52:17 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 13:50:36 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@Sun.COM'" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Tue, 14 Jan 2003 13:50:35 -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: , The more I think about it, the more I'm in favor of the condensed/IPv6 format. I really would like to consider the aesthetic of the format. Although my mailer is probably going to wrap these lines (a hint at what it would look like on an 80 character xterm), consider the following displays from a Linux system. The first is the standard output (80 character line length) followed by option #1(120 chars), #3(88 chars) and #4(107 chars). Note that the arp header is constant meaning that it would take the new field widths for all network devices including Ethernet. Also keep in mind that the primary reason to display this info is for a human to read. Of these, I believe the admin would want to use option #3 for input and output. It's easy enough to change/add a MIB definition for a IPoIB hardware address (as opposed to the GUID display hint that folks have alluded to). Other comments in-line /rkl Roy Standard #3 #4 #1 V V V V 1 2 3 4 5 6 7 8 9 100 110 120 1234567890123456789012345678901234567890123456789012345678901234567890123456 78901234567890123456789012345678901234567890 -------------------------------------------------------- Standard format eth0 Link encap:IPoIB HWaddr 00:A0:C9:FC:15:4A inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:5398865 errors:0 dropped:0 overruns:0 frame:0 TX packets:2396617 errors:0 dropped:0 overruns:0 carrier:0 collisions:148296 txqueuelen:100 RX bytes:810245774 (772.7 Mb) TX bytes:1587921980 (1514.3 Mb) Interrupt:21 Base address:0xa000 Address HWtype HWaddress Flags Mask Iface 10.7.159.251 ether 00:D0:D3:39:18:A8 C eth0 -------------------------------------------------------- option #1 ib01 Link encap:Infina HWaddr 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 collisions:148295 txqueuelen:100 RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) Interrupt:21 Base address:0xa000 Address HWtype HWaddress Flags Mask Iface 10.7.159.251 infina 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 C ib01 ------------------------------------------------------- option #3 ib01 Link encap:IPoIB HWaddr 0:14:FE80::2:c900:011c:9781 inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 collisions:148295 txqueuelen:100 RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) Interrupt:21 Base address:0xa000 Address HWtype HWaddress Flags Mask Iface 10.7.159.251 infina 0:14:FE80::2:c900:011c:9781 C ib01 ------------------------------------------------------- option #4 ib01 Link encap:Infina HWaddr 123456:FE80:0000:0000:0000:0002:c900:011c:9781 inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 collisions:148295 txqueuelen:100 RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) Interrupt:21 Base address:0xa000 Address HWtype HWaddress Flags Mask Iface 10.7.159.251 infina 123456:FE80:0000:0000:0000:0002:c900:011c:9781 C ib01 -----Original Message----- From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] Sent: Tuesday, January 14, 2003 12:45 PM To: Larsen, Roy K Cc: ipoverib@ietf.org; Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question "Larsen, Roy K" wrote: > > Ah yes, 24 bits.... I had a brain fart and was thinking the QPN was 16. > Then if fixed length is desirable, what you show for #4 is better than the > 60 digit #1 (regardless of what the mib draft proposes). It just isn't > practical to display 60 characters (although 47 characters is pretty much in > the same camp) and is not very parsable by a human. Remember, this sequence > would be displayed for things like ifconfig(8) and arp(8) which are fairly > frequent administrative operations. I still like #3 but since I don't do > much network administration, I don't know what the impact of a variable > length hardware address would have. I think we are down to #1 and #4, right? (Another point against #3 is that it *might* be confusing to have a v6 protocol layer addressing scheme applied to a link layer address; specially since the link layer address is not 128bits long). /rkl As Roland points out, GIDs are IPv6 addresses so it doesn't bother me that they follow an IPv6 format. The admin tools make it very clear where the hw address is displayed rkl/ Here they are (with QPN=0x123456): 1. 00:12:34:56:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 (or 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 (or 123456:FE80:0:0:0:2:c900:11c:9781) Given the irregularity (length wise) in the first few digits in 4, I would think #2 would be better. Here it is: 2. 12:3456:FE80:0000:0000:0000:0002:c900:011c:9781 (or 12:3456:FE80:0:0:0:2:c900:11c:9781) I do have a preference for #1 still, primarily because a. it is the most easily adapatable to the "arp" command (ie, when you are doing a "set" operation, it is very easy to teach "arp", which on most systems currently only expect ethernet addresses, how to parse a #1 style ib command, in contrast to #2 or #4). Any other format picked can of course be handled, I have seen the least amount of work with #1 while prototyping (I am dealing with Solaris, but I expect that to be true on most other systems like BSD too; Linux has a -H option, so this is not an issue). /rkl When you say adaptable to the arp(8) command, are you taking into account the display headaches I try to illustrate above? Given that the IPoIB hardware address is virtual and the pathrecord is always required, do you think "set" is viable? Even so, do you think the admin would want to enter 60 characters as opposed to something around 27? rkl/ b. I do believe there is value in matching the MIB format, specially since admins might want to correlate the outputs from various commands (ifconfig, arp, snoop and SNMP). /rkl I don't disagree. But if the MIB format is not practical, we can change the draft. Anyway, it doesn't have a display hint for IPoIB hardware address so we can invent one. rkl/ c. Any current scripts that parse ethernet addresses (HWaddr output in Linux etc) if applicable on IPoIB would need to be converted; I am not aware of any, but if there are some, logic in a. again applies. /rkl I'm not aware of any need to parse a hardware address except perhaps to compare them. Format in that case is not as important. rkl/ The advantage of 2 and 4 are their somewhat shorter lengths. /rkl #3 is even shorter :^) rkl/ > > The network admin tools I work with already use a hardware type based > library for displaying interface specific information so there is no need to > follow Ethernet convention from my point of view. > What about (sysadmin) scripts that parse output from ifconfig (ie look at HWaddr field), which currently assume ethernet format? /rkl But I assume they already assume a fixed length representing 6 octets so they are going to have to change anyway. At most, they are going to comparisons so I don't think this a compelling argument for #1 rkl/ I assume you are talking about Linux (and thus you have the -H arp option to help)? Notice, you could still build in automatic parsing in Linux "arp", which on seeing format #1 will recognize it as an IPoIB address (ie, the default type for 20b addresses can be IPoIB, similar to the default type for 6b addresses is ethernet; this would allow admins not to have to specify -H for each IPoIB operation, thus making IPoIB just a little more similar to ethernet); I imagine it will be just a little harder to do #2 or #4. /rkl I believe the -H option only acts as a filter, not a display formatter. rkl/ Thanks. Kanoj > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] > Sent: Tuesday, January 14, 2003 11:00 AM > To: Larsen, Roy K > Cc: ipoverib@ietf.org; Kanoj Sarcar > Subject: Re: [Ipoverib] IPoIB/ifconfig question > > "Larsen, Roy K" wrote: > > > > Kanoj, > > > > While not a draft issue, I agree that it would be nice to use this forum > to > > set a de facto standard for IPoIB hardware address display format. Given > > the long length, I'm inclined to go with the most condensed representation > > which would be #3. However, this does not provide a fixed length display > > which is useful for scripting applications so I'm thinking a modified #2 > > with all fixed length numbers and a single field QPN of 0014 instead of > > 0:14). > > > > Roy > > > > Roy, > > It was pointed out to me that > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt > > has > > IbGuid ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1x:" > STATUS current > DESCRIPTION > > It would seem to me that unless there is good reason for deviation, > tcpdump/snoop/ifconfig/arp et al could just use this format (maps to > option 1). > > Another reason I prefer 1 is because scripts written with the ethernet > format in mind would mostly work (if the length issues were fixed in > the script). Option 2 packs 16 bits in between each :, whereas these > ethernet based scripts pack 8 bits. > > What do you think? > > The reason I went with 0:14 for the QPN (in #3) is because the QPN is > actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 > could be a possible value (theoretically). To represent that, I would > need to say 12:3456:... I wanted this to look the same (in terms of > number of :s) as in the case of QPN=0x00000014. Or are you suggesting > something like > > 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > > in this case? > > Thanks. > > Kanoj > > > -----Original Message----- > > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > > Sent: Monday, January 13, 2003 2:35 PM > > To: ipoverib@ietf.org; Kanoj Sarcar > > Subject: [Ipoverib] IPoIB/ifconfig question > > > > Hi, > > > > Here's an IPoIB implementation issue that I would > > like to get feedback on from implementors. > > > > What should the ifconfig/arp/packet-sniffer output look like for > > the mac address part of an IPoIB interface? In the examples below, > > assume QPN=0x14, GID prefix is FE80::0 and GID suffix is > > 0002c900011c9781, so that the mac address in hex is > > 14FE800000000000000002c900011c9781. > > > > Some options might be > > > > 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > > (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > > 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 > > (or 0:14:FE80:0:0:0:2:c900:011c:9781) > > 3: 0:14:FE80::2:c900:011c:9781 > > > > I understand this is probably not something that should be > > put into any of the I/Ds, but it would be nice if various > > vendors' outputs matched. My choice is option 1, since it > > is the closest to how most systems represent ethernet > > addresses (except the length of course). Most systems' > > "arp" command is also easily converted to handle this > > format and obviates the need for complicated parsing. > > > > Note that the I/D > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt > > > > on page 8 section 8.0 represents IBA multicast GIDs in v6 > > format, I am not sure whether to suggest that the link layer > > address should also be represented similarly by network tools. > > > > For reference, here's the ifconfig output line that prints > > mac addresses on Solaris and Linux: > > Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E > > ether 8:0:20:d9:4:97 > > > > 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 Tue Jan 14 16:50:00 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 QAA12987 for ; Tue, 14 Jan 2003 16:50:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EM4I605443 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 17:04: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 h0EM4HJ05440 for ; Tue, 14 Jan 2003 17:04:17 -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 QAA12963 for ; Tue, 14 Jan 2003 16:49: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 h0EM3CJ05315; Tue, 14 Jan 2003 17:03: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 h0EM2JJ05273 for ; Tue, 14 Jan 2003 17:02:19 -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 QAA12890 for ; Tue, 14 Jan 2003 16:47:29 -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 h0ELm7s01420 for ; Tue, 14 Jan 2003 21:48:12 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 h0ELjiJ18202 for ; Tue, 14 Jan 2003 21:45:44 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011413521729154 ; Tue, 14 Jan 2003 13:52:17 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 13:50:36 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@Sun.COM'" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Tue, 14 Jan 2003 13:50:35 -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: , The more I think about it, the more I'm in favor of the condensed/IPv6 format. I really would like to consider the aesthetic of the format. Although my mailer is probably going to wrap these lines (a hint at what it would look like on an 80 character xterm), consider the following displays from a Linux system. The first is the standard output (80 character line length) followed by option #1(120 chars), #3(88 chars) and #4(107 chars). Note that the arp header is constant meaning that it would take the new field widths for all network devices including Ethernet. Also keep in mind that the primary reason to display this info is for a human to read. Of these, I believe the admin would want to use option #3 for input and output. It's easy enough to change/add a MIB definition for a IPoIB hardware address (as opposed to the GUID display hint that folks have alluded to). Other comments in-line /rkl Roy Standard #3 #4 #1 V V V V 1 2 3 4 5 6 7 8 9 100 110 120 1234567890123456789012345678901234567890123456789012345678901234567890123456 78901234567890123456789012345678901234567890 -------------------------------------------------------- Standard format eth0 Link encap:IPoIB HWaddr 00:A0:C9:FC:15:4A inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:5398865 errors:0 dropped:0 overruns:0 frame:0 TX packets:2396617 errors:0 dropped:0 overruns:0 carrier:0 collisions:148296 txqueuelen:100 RX bytes:810245774 (772.7 Mb) TX bytes:1587921980 (1514.3 Mb) Interrupt:21 Base address:0xa000 Address HWtype HWaddress Flags Mask Iface 10.7.159.251 ether 00:D0:D3:39:18:A8 C eth0 -------------------------------------------------------- option #1 ib01 Link encap:Infina HWaddr 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 collisions:148295 txqueuelen:100 RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) Interrupt:21 Base address:0xa000 Address HWtype HWaddress Flags Mask Iface 10.7.159.251 infina 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 C ib01 ------------------------------------------------------- option #3 ib01 Link encap:IPoIB HWaddr 0:14:FE80::2:c900:011c:9781 inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 collisions:148295 txqueuelen:100 RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) Interrupt:21 Base address:0xa000 Address HWtype HWaddress Flags Mask Iface 10.7.159.251 infina 0:14:FE80::2:c900:011c:9781 C ib01 ------------------------------------------------------- option #4 ib01 Link encap:Infina HWaddr 123456:FE80:0000:0000:0000:0002:c900:011c:9781 inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 collisions:148295 txqueuelen:100 RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) Interrupt:21 Base address:0xa000 Address HWtype HWaddress Flags Mask Iface 10.7.159.251 infina 123456:FE80:0000:0000:0000:0002:c900:011c:9781 C ib01 -----Original Message----- From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] Sent: Tuesday, January 14, 2003 12:45 PM To: Larsen, Roy K Cc: ipoverib@ietf.org; Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question "Larsen, Roy K" wrote: > > Ah yes, 24 bits.... I had a brain fart and was thinking the QPN was 16. > Then if fixed length is desirable, what you show for #4 is better than the > 60 digit #1 (regardless of what the mib draft proposes). It just isn't > practical to display 60 characters (although 47 characters is pretty much in > the same camp) and is not very parsable by a human. Remember, this sequence > would be displayed for things like ifconfig(8) and arp(8) which are fairly > frequent administrative operations. I still like #3 but since I don't do > much network administration, I don't know what the impact of a variable > length hardware address would have. I think we are down to #1 and #4, right? (Another point against #3 is that it *might* be confusing to have a v6 protocol layer addressing scheme applied to a link layer address; specially since the link layer address is not 128bits long). /rkl As Roland points out, GIDs are IPv6 addresses so it doesn't bother me that they follow an IPv6 format. The admin tools make it very clear where the hw address is displayed rkl/ Here they are (with QPN=0x123456): 1. 00:12:34:56:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 (or 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 (or 123456:FE80:0:0:0:2:c900:11c:9781) Given the irregularity (length wise) in the first few digits in 4, I would think #2 would be better. Here it is: 2. 12:3456:FE80:0000:0000:0000:0002:c900:011c:9781 (or 12:3456:FE80:0:0:0:2:c900:11c:9781) I do have a preference for #1 still, primarily because a. it is the most easily adapatable to the "arp" command (ie, when you are doing a "set" operation, it is very easy to teach "arp", which on most systems currently only expect ethernet addresses, how to parse a #1 style ib command, in contrast to #2 or #4). Any other format picked can of course be handled, I have seen the least amount of work with #1 while prototyping (I am dealing with Solaris, but I expect that to be true on most other systems like BSD too; Linux has a -H option, so this is not an issue). /rkl When you say adaptable to the arp(8) command, are you taking into account the display headaches I try to illustrate above? Given that the IPoIB hardware address is virtual and the pathrecord is always required, do you think "set" is viable? Even so, do you think the admin would want to enter 60 characters as opposed to something around 27? rkl/ b. I do believe there is value in matching the MIB format, specially since admins might want to correlate the outputs from various commands (ifconfig, arp, snoop and SNMP). /rkl I don't disagree. But if the MIB format is not practical, we can change the draft. Anyway, it doesn't have a display hint for IPoIB hardware address so we can invent one. rkl/ c. Any current scripts that parse ethernet addresses (HWaddr output in Linux etc) if applicable on IPoIB would need to be converted; I am not aware of any, but if there are some, logic in a. again applies. /rkl I'm not aware of any need to parse a hardware address except perhaps to compare them. Format in that case is not as important. rkl/ The advantage of 2 and 4 are their somewhat shorter lengths. /rkl #3 is even shorter :^) rkl/ > > The network admin tools I work with already use a hardware type based > library for displaying interface specific information so there is no need to > follow Ethernet convention from my point of view. > What about (sysadmin) scripts that parse output from ifconfig (ie look at HWaddr field), which currently assume ethernet format? /rkl But I assume they already assume a fixed length representing 6 octets so they are going to have to change anyway. At most, they are going to comparisons so I don't think this a compelling argument for #1 rkl/ I assume you are talking about Linux (and thus you have the -H arp option to help)? Notice, you could still build in automatic parsing in Linux "arp", which on seeing format #1 will recognize it as an IPoIB address (ie, the default type for 20b addresses can be IPoIB, similar to the default type for 6b addresses is ethernet; this would allow admins not to have to specify -H for each IPoIB operation, thus making IPoIB just a little more similar to ethernet); I imagine it will be just a little harder to do #2 or #4. /rkl I believe the -H option only acts as a filter, not a display formatter. rkl/ Thanks. Kanoj > Roy > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] > Sent: Tuesday, January 14, 2003 11:00 AM > To: Larsen, Roy K > Cc: ipoverib@ietf.org; Kanoj Sarcar > Subject: Re: [Ipoverib] IPoIB/ifconfig question > > "Larsen, Roy K" wrote: > > > > Kanoj, > > > > While not a draft issue, I agree that it would be nice to use this forum > to > > set a de facto standard for IPoIB hardware address display format. Given > > the long length, I'm inclined to go with the most condensed representation > > which would be #3. However, this does not provide a fixed length display > > which is useful for scripting applications so I'm thinking a modified #2 > > with all fixed length numbers and a single field QPN of 0014 instead of > > 0:14). > > > > Roy > > > > Roy, > > It was pointed out to me that > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt > > has > > IbGuid ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1x:" > STATUS current > DESCRIPTION > > It would seem to me that unless there is good reason for deviation, > tcpdump/snoop/ifconfig/arp et al could just use this format (maps to > option 1). > > Another reason I prefer 1 is because scripts written with the ethernet > format in mind would mostly work (if the length issues were fixed in > the script). Option 2 packs 16 bits in between each :, whereas these > ethernet based scripts pack 8 bits. > > What do you think? > > The reason I went with 0:14 for the QPN (in #3) is because the QPN is > actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 > could be a possible value (theoretically). To represent that, I would > need to say 12:3456:... I wanted this to look the same (in terms of > number of :s) as in the case of QPN=0x00000014. Or are you suggesting > something like > > 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > > in this case? > > Thanks. > > Kanoj > > > -----Original Message----- > > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > > Sent: Monday, January 13, 2003 2:35 PM > > To: ipoverib@ietf.org; Kanoj Sarcar > > Subject: [Ipoverib] IPoIB/ifconfig question > > > > Hi, > > > > Here's an IPoIB implementation issue that I would > > like to get feedback on from implementors. > > > > What should the ifconfig/arp/packet-sniffer output look like for > > the mac address part of an IPoIB interface? In the examples below, > > assume QPN=0x14, GID prefix is FE80::0 and GID suffix is > > 0002c900011c9781, so that the mac address in hex is > > 14FE800000000000000002c900011c9781. > > > > Some options might be > > > > 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > > (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > > 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 > > (or 0:14:FE80:0:0:0:2:c900:011c:9781) > > 3: 0:14:FE80::2:c900:011c:9781 > > > > I understand this is probably not something that should be > > put into any of the I/Ds, but it would be nice if various > > vendors' outputs matched. My choice is option 1, since it > > is the closest to how most systems represent ethernet > > addresses (except the length of course). Most systems' > > "arp" command is also easily converted to handle this > > format and obviates the need for complicated parsing. > > > > Note that the I/D > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt > > > > on page 8 section 8.0 represents IBA multicast GIDs in v6 > > format, I am not sure whether to suggest that the link layer > > address should also be represented similarly by network tools. > > > > For reference, here's the ifconfig output line that prints > > mac addresses on Solaris and Linux: > > Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E > > ether 8:0:20:d9:4:97 > > > > 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 Tue Jan 14 17:37:57 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 RAA14339 for ; Tue, 14 Jan 2003 17:37:57 -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 h0EMpEJ08683; Tue, 14 Jan 2003 17:51: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 h0EMhbJ08438 for ; Tue, 14 Jan 2003 17:43:37 -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 RAA14037 for ; Tue, 14 Jan 2003 17:28:46 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14359; Tue, 14 Jan 2003 15:32:06 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0EMW55f002038; Tue, 14 Jan 2003 17:32:05 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0EMW5xO082948; Tue, 14 Jan 2003 17:32:05 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0EMW5KR082945; Tue, 14 Jan 2003 17:32:05 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15908.36837.543501.452444@gargle.gargle.HOWL> Date: Tue, 14 Jan 2003 17:32:05 -0500 From: James Carlson To: "Larsen, Roy K" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question In-Reply-To: Larsen, Roy K's message of 14 January 2003 13:50:35 References: X-Mailer: VM 7.01 under Emacs 21.2.1 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 writes: > The more I think about it, the more I'm in favor of the condensed/IPv6 > format. I really would like to consider the aesthetic of the format. I think that's going to be exciting when you're using IPv6 over IB. % netstat -pnf inet6 Net to Media Table: IPv6 If Physical Address Type State Destination/Mask ----- ---------------------------------------------- ------- ------------ --------------------------- ib01 123456:fe80:0000:0000:0000:0002:c900:011c:9781 dynamic REACHABLE 2002:8194:aeaa:1:203:baff:fe00:de2f ... yuck. Which one is which? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue Jan 14 17:37: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 RAA14352 for ; Tue, 14 Jan 2003 17:37:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EMqHI08807 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 17:52: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 h0EMqHJ08804 for ; Tue, 14 Jan 2003 17:52:17 -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 RAA14310 for ; Tue, 14 Jan 2003 17:37:26 -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 h0EMpEJ08683; Tue, 14 Jan 2003 17:51: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 h0EMhbJ08438 for ; Tue, 14 Jan 2003 17:43:37 -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 RAA14037 for ; Tue, 14 Jan 2003 17:28:46 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14359; Tue, 14 Jan 2003 15:32:06 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0EMW55f002038; Tue, 14 Jan 2003 17:32:05 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0EMW5xO082948; Tue, 14 Jan 2003 17:32:05 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0EMW5KR082945; Tue, 14 Jan 2003 17:32:05 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15908.36837.543501.452444@gargle.gargle.HOWL> Date: Tue, 14 Jan 2003 17:32:05 -0500 From: James Carlson To: "Larsen, Roy K" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question In-Reply-To: Larsen, Roy K's message of 14 January 2003 13:50:35 References: X-Mailer: VM 7.01 under Emacs 21.2.1 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 writes: > The more I think about it, the more I'm in favor of the condensed/IPv6 > format. I really would like to consider the aesthetic of the format. I think that's going to be exciting when you're using IPv6 over IB. % netstat -pnf inet6 Net to Media Table: IPv6 If Physical Address Type State Destination/Mask ----- ---------------------------------------------- ------- ------------ --------------------------- ib01 123456:fe80:0000:0000:0000:0002:c900:011c:9781 dynamic REACHABLE 2002:8194:aeaa:1:203:baff:fe00:de2f ... yuck. Which one is which? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue Jan 14 18:20:56 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 SAA15729 for ; Tue, 14 Jan 2003 18:20:56 -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 h0ENY9J11572; Tue, 14 Jan 2003 18:34:09 -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 h0ENXpJ11555 for ; Tue, 14 Jan 2003 18:33:51 -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 SAA15665 for ; Tue, 14 Jan 2003 18:18:58 -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 PAA23236; Tue, 14 Jan 2003 15:21:48 -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 h0ENLlgE013714; Tue, 14 Jan 2003 15:21:47 -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 <0H8Q00FH58WBCM@ha1sun-mail1.eng.sun.com>; Tue, 14 Jan 2003 15:21:47 -0800 (PST) Date: Tue, 14 Jan 2003 15:21:47 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question To: "Larsen, Roy K" Cc: ipoverib@ietf.org, Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E249B8B.3693B12C@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: > > The more I think about it, the more I'm in favor of the condensed/IPv6 > format. I really would like to consider the aesthetic of the format. > Although my mailer is probably going to wrap these lines (a hint at what it > would look like on an 80 character xterm), consider the following displays > from a Linux system. The first is the standard output (80 character line > length) followed by option #1(120 chars), #3(88 chars) and #4(107 chars). > Note that the arp header is constant meaning that it would take the new > field widths for all network devices including Ethernet. Also keep in mind > that the primary reason to display this info is for a human to read. Of > these, I believe the admin would want to use option #3 for input and output. > It's easy enough to change/add a MIB definition for a IPoIB hardware address > (as opposed to the GUID display hint that folks have alluded to). > Roy, You might also want to try a non-default GID prefix, specially one that does not have too many runs of 0s. I am not sure if the Linux implementation will allow that, but it is probably possible on other systems. In that case, the benefits of #3 might be limited (whereas 1, 2 and 4 are independent of actual values). Another suggestion is to eliminate leading 0's for all options (that can only shorten the output) when you compare. Comments below. > Other comments in-line /rkl > Roy > I am including output from a Solaris system here, similar to what Roy did for Linux: hme0: flags=1000843 mtu 1500 index 2 inet 10.7.198.20 netmask ffffff00 broadcast 10.7.198.255 ether 8:0:20:d9:4:97 ibd0: flags=1000843 mtu 504 index 3 inet 192.129.100.100 netmask ffffff00 broadcast 192.129.100.255 ib 0:0:0:14:0:0:0:0:0:0:0:4:0:2:C9:0:1:1C:97:81 root@pap# arp pap pap (10.7.198.20) at 8:0:20:d9:4:97 permanent published root@pap# arp pap-ibd pap-ibd (192.129.100.100) at 0:0:0:14:0:0:0:0:0:0:0:4:0:2:C9:0:1:1C:97:81 permanent established > > Standard #3 #4 #1 > > V V V V > 1 2 3 4 5 6 7 > 8 9 100 110 120 > 1234567890123456789012345678901234567890123456789012345678901234567890123456 > 78901234567890123456789012345678901234567890 > -------------------------------------------------------- > Standard format > > eth0 Link encap:IPoIB HWaddr 00:A0:C9:FC:15:4A > inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 > RX packets:5398865 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2396617 errors:0 dropped:0 overruns:0 carrier:0 > collisions:148296 txqueuelen:100 > RX bytes:810245774 (772.7 Mb) TX bytes:1587921980 (1514.3 Mb) > Interrupt:21 Base address:0xa000 > > Address HWtype HWaddress Flags Mask > Iface > 10.7.159.251 ether 00:D0:D3:39:18:A8 C > eth0 > > -------------------------------------------------------- > option #1 > > ib01 Link encap:Infina HWaddr > 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 > RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 > collisions:148295 txqueuelen:100 > RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) > Interrupt:21 Base address:0xa000 > > Address HWtype HWaddress > Flags Mask Iface > 10.7.159.251 infina > 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 C > ib01 > > ------------------------------------------------------- > option #3 > > ib01 Link encap:IPoIB HWaddr 0:14:FE80::2:c900:011c:9781 > inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 > RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 > collisions:148295 txqueuelen:100 > RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) > Interrupt:21 Base address:0xa000 > > Address HWtype HWaddress Flags Mask > Iface > 10.7.159.251 infina 0:14:FE80::2:c900:011c:9781 C > ib01 > > ------------------------------------------------------- > option #4 > > ib01 Link encap:Infina HWaddr > 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 > RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 > collisions:148295 txqueuelen:100 > RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) > Interrupt:21 Base address:0xa000 > > Address HWtype HWaddress > Flags Mask Iface > 10.7.159.251 infina > 123456:FE80:0000:0000:0000:0002:c900:011c:9781 C ib01 > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] > Sent: Tuesday, January 14, 2003 12:45 PM > To: Larsen, Roy K > Cc: ipoverib@ietf.org; Kanoj Sarcar > Subject: Re: [Ipoverib] IPoIB/ifconfig question > > "Larsen, Roy K" wrote: > > > > Ah yes, 24 bits.... I had a brain fart and was thinking the QPN was 16. > > Then if fixed length is desirable, what you show for #4 is better than the > > 60 digit #1 (regardless of what the mib draft proposes). It just isn't > > practical to display 60 characters (although 47 characters is pretty much > in > > the same camp) and is not very parsable by a human. Remember, this > sequence > > would be displayed for things like ifconfig(8) and arp(8) which are fairly > > frequent administrative operations. I still like #3 but since I don't do > > much network administration, I don't know what the impact of a variable > > length hardware address would have. > > I think we are down to #1 and #4, right? (Another point against #3 is that > it *might* be confusing to have a v6 protocol layer addressing scheme > applied > to a link layer address; specially since the link layer address is not > 128bits > long). > > /rkl > As Roland points out, GIDs are IPv6 addresses so it doesn't bother me that > they follow an IPv6 format. The admin tools make it very clear where the hw > address is displayed > rkl/ But we are talking about GID+QPN here, and since thats 20b instead of v6 16 bytes, I don't know whether this is a good idea. The other part is, the GID is similar to v6 in the context of IBA network layer, but that same GID is being used as (part of) a link layer address for IPoIB. > > Here they are (with QPN=0x123456): > > 1. 00:12:34:56:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > (or 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 123456:FE80:0:0:0:2:c900:11c:9781) > > Given the irregularity (length wise) in the first few digits in 4, > I would think #2 would be better. Here it is: > > 2. 12:3456:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 12:3456:FE80:0:0:0:2:c900:11c:9781) > > I do have a preference for #1 still, primarily because > > a. it is the most easily adapatable to the "arp" command (ie, when you > are doing a "set" operation, it is very easy to teach "arp", which on > most systems currently only expect ethernet addresses, how to parse a > #1 style ib command, in contrast to #2 or #4). Any other format picked > can of course be handled, I have seen the least amount of work with #1 > while prototyping (I am dealing with Solaris, but I expect that to be > true on most other systems like BSD too; Linux has a -H option, so this > is not an issue). > > /rkl > When you say adaptable to the arp(8) command, are you taking into account > the display headaches I try to illustrate above? Given that the IPoIB > hardware address is virtual and the pathrecord is always required, do you > think "set" is viable? Even so, do you think the admin would want to enter > 60 characters as opposed to something around 27? > rkl/ We have to allow that "set"s might be meaningful in certain implementations. Does the Linux implementation allow it? If so, what is the syntax of the command, and how was "arp" modified for accepting IPoIB link address input? (For Solaris, which is similar to BSD, I can do "arp -s hostname 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81" I had to teach arp to accept not only a:b:c:d:e:f ethernet format, but also the 20b format). Yes, I am aware there are display issues, but I think they might be different issues on different platforms (eg Solaris prints the link address on a seperate line, so its lesser of an issue). > > b. I do believe there is value in matching the MIB format, specially since > admins might want to correlate the outputs from various commands (ifconfig, > arp, snoop and SNMP). > > /rkl > I don't disagree. But if the MIB format is not practical, we can change the > draft. Anyway, it doesn't have a display hint for IPoIB hardware address so > we can invent one. > rkl/ > > c. Any current scripts that parse ethernet addresses (HWaddr output in > Linux etc) if applicable on IPoIB would need to be converted; I am not > aware of any, but if there are some, logic in a. again applies. > > /rkl > I'm not aware of any need to parse a hardware address except perhaps to > compare them. Format in that case is not as important. > rkl/ > > The advantage of 2 and 4 are their somewhat shorter lengths. > /rkl > #3 is even shorter :^) > rkl/ > > > > > The network admin tools I work with already use a hardware type based > > library for displaying interface specific information so there is no need > to > > follow Ethernet convention from my point of view. > > > > What about (sysadmin) scripts that parse output from ifconfig (ie look at > HWaddr field), which currently assume ethernet format? > > /rkl > But I assume they already assume a fixed length representing 6 octets so > they are going to have to change anyway. At most, they are going to > comparisons so I don't think this a compelling argument for #1 > rkl/ > > I assume you are talking about Linux (and thus you have the -H arp option > to help)? Notice, you could still build in automatic parsing in Linux "arp", > > which on seeing format #1 will recognize it as an IPoIB address (ie, > the default type for 20b addresses can be IPoIB, similar to the default > type for 6b addresses is ethernet; this would allow admins not to have > to specify -H for each IPoIB operation, thus making IPoIB just a little > more similar to ethernet); I imagine it will be just a little harder to > do #2 or #4. > > /rkl > I believe the -H option only acts as a filter, not a display formatter. > rkl/ Okay. I am still curious about how Linux/IPoIB does a arp set operation. Thanks. Kanoj > > Thanks. > > Kanoj > > > Roy > > > > -----Original Message----- > > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] > > Sent: Tuesday, January 14, 2003 11:00 AM > > To: Larsen, Roy K > > Cc: ipoverib@ietf.org; Kanoj Sarcar > > Subject: Re: [Ipoverib] IPoIB/ifconfig question > > > > "Larsen, Roy K" wrote: > > > > > > Kanoj, > > > > > > While not a draft issue, I agree that it would be nice to use this forum > > to > > > set a de facto standard for IPoIB hardware address display format. > Given > > > the long length, I'm inclined to go with the most condensed > representation > > > which would be #3. However, this does not provide a fixed length > display > > > which is useful for scripting applications so I'm thinking a modified #2 > > > with all fixed length numbers and a single field QPN of 0014 instead of > > > 0:14). > > > > > > Roy > > > > > > > Roy, > > > > It was pointed out to me that > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt > > > > has > > > > IbGuid ::= TEXTUAL-CONVENTION > > DISPLAY-HINT "1x:" > > STATUS current > > DESCRIPTION > > > > It would seem to me that unless there is good reason for deviation, > > tcpdump/snoop/ifconfig/arp et al could just use this format (maps to > > option 1). > > > > Another reason I prefer 1 is because scripts written with the ethernet > > format in mind would mostly work (if the length issues were fixed in > > the script). Option 2 packs 16 bits in between each :, whereas these > > ethernet based scripts pack 8 bits. > > > > What do you think? > > > > The reason I went with 0:14 for the QPN (in #3) is because the QPN is > > actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 > > could be a possible value (theoretically). To represent that, I would > > need to say 12:3456:... I wanted this to look the same (in terms of > > number of :s) as in the case of QPN=0x00000014. Or are you suggesting > > something like > > > > 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > > > > in this case? > > > > Thanks. > > > > Kanoj > > > > > -----Original Message----- > > > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > > > Sent: Monday, January 13, 2003 2:35 PM > > > To: ipoverib@ietf.org; Kanoj Sarcar > > > Subject: [Ipoverib] IPoIB/ifconfig question > > > > > > Hi, > > > > > > Here's an IPoIB implementation issue that I would > > > like to get feedback on from implementors. > > > > > > What should the ifconfig/arp/packet-sniffer output look like for > > > the mac address part of an IPoIB interface? In the examples below, > > > assume QPN=0x14, GID prefix is FE80::0 and GID suffix is > > > 0002c900011c9781, so that the mac address in hex is > > > 14FE800000000000000002c900011c9781. > > > > > > Some options might be > > > > > > 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > > > (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > > > 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 > > > (or 0:14:FE80:0:0:0:2:c900:011c:9781) > > > 3: 0:14:FE80::2:c900:011c:9781 > > > > > > I understand this is probably not something that should be > > > put into any of the I/Ds, but it would be nice if various > > > vendors' outputs matched. My choice is option 1, since it > > > is the closest to how most systems represent ethernet > > > addresses (except the length of course). Most systems' > > > "arp" command is also easily converted to handle this > > > format and obviates the need for complicated parsing. > > > > > > Note that the I/D > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt > > > > > > on page 8 section 8.0 represents IBA multicast GIDs in v6 > > > format, I am not sure whether to suggest that the link layer > > > address should also be represented similarly by network tools. > > > > > > For reference, here's the ifconfig output line that prints > > > mac addresses on Solaris and Linux: > > > Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E > > > ether 8:0:20:d9:4:97 > > > > > > 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 Tue Jan 14 18:20:57 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 SAA15739 for ; Tue, 14 Jan 2003 18:20:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ENZH411681 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 18:35: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 h0ENZHJ11678 for ; Tue, 14 Jan 2003 18:35:17 -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 SAA15706 for ; Tue, 14 Jan 2003 18:20: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 h0ENY9J11572; Tue, 14 Jan 2003 18:34:09 -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 h0ENXpJ11555 for ; Tue, 14 Jan 2003 18:33:51 -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 SAA15665 for ; Tue, 14 Jan 2003 18:18:58 -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 PAA23236; Tue, 14 Jan 2003 15:21:48 -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 h0ENLlgE013714; Tue, 14 Jan 2003 15:21:47 -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 <0H8Q00FH58WBCM@ha1sun-mail1.eng.sun.com>; Tue, 14 Jan 2003 15:21:47 -0800 (PST) Date: Tue, 14 Jan 2003 15:21:47 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question To: "Larsen, Roy K" Cc: ipoverib@ietf.org, Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E249B8B.3693B12C@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: > > The more I think about it, the more I'm in favor of the condensed/IPv6 > format. I really would like to consider the aesthetic of the format. > Although my mailer is probably going to wrap these lines (a hint at what it > would look like on an 80 character xterm), consider the following displays > from a Linux system. The first is the standard output (80 character line > length) followed by option #1(120 chars), #3(88 chars) and #4(107 chars). > Note that the arp header is constant meaning that it would take the new > field widths for all network devices including Ethernet. Also keep in mind > that the primary reason to display this info is for a human to read. Of > these, I believe the admin would want to use option #3 for input and output. > It's easy enough to change/add a MIB definition for a IPoIB hardware address > (as opposed to the GUID display hint that folks have alluded to). > Roy, You might also want to try a non-default GID prefix, specially one that does not have too many runs of 0s. I am not sure if the Linux implementation will allow that, but it is probably possible on other systems. In that case, the benefits of #3 might be limited (whereas 1, 2 and 4 are independent of actual values). Another suggestion is to eliminate leading 0's for all options (that can only shorten the output) when you compare. Comments below. > Other comments in-line /rkl > Roy > I am including output from a Solaris system here, similar to what Roy did for Linux: hme0: flags=1000843 mtu 1500 index 2 inet 10.7.198.20 netmask ffffff00 broadcast 10.7.198.255 ether 8:0:20:d9:4:97 ibd0: flags=1000843 mtu 504 index 3 inet 192.129.100.100 netmask ffffff00 broadcast 192.129.100.255 ib 0:0:0:14:0:0:0:0:0:0:0:4:0:2:C9:0:1:1C:97:81 root@pap# arp pap pap (10.7.198.20) at 8:0:20:d9:4:97 permanent published root@pap# arp pap-ibd pap-ibd (192.129.100.100) at 0:0:0:14:0:0:0:0:0:0:0:4:0:2:C9:0:1:1C:97:81 permanent established > > Standard #3 #4 #1 > > V V V V > 1 2 3 4 5 6 7 > 8 9 100 110 120 > 1234567890123456789012345678901234567890123456789012345678901234567890123456 > 78901234567890123456789012345678901234567890 > -------------------------------------------------------- > Standard format > > eth0 Link encap:IPoIB HWaddr 00:A0:C9:FC:15:4A > inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 > RX packets:5398865 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2396617 errors:0 dropped:0 overruns:0 carrier:0 > collisions:148296 txqueuelen:100 > RX bytes:810245774 (772.7 Mb) TX bytes:1587921980 (1514.3 Mb) > Interrupt:21 Base address:0xa000 > > Address HWtype HWaddress Flags Mask > Iface > 10.7.159.251 ether 00:D0:D3:39:18:A8 C > eth0 > > -------------------------------------------------------- > option #1 > > ib01 Link encap:Infina HWaddr > 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 > RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 > collisions:148295 txqueuelen:100 > RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) > Interrupt:21 Base address:0xa000 > > Address HWtype HWaddress > Flags Mask Iface > 10.7.159.251 infina > 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 C > ib01 > > ------------------------------------------------------- > option #3 > > ib01 Link encap:IPoIB HWaddr 0:14:FE80::2:c900:011c:9781 > inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 > RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 > collisions:148295 txqueuelen:100 > RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) > Interrupt:21 Base address:0xa000 > > Address HWtype HWaddress Flags Mask > Iface > 10.7.159.251 infina 0:14:FE80::2:c900:011c:9781 C > ib01 > > ------------------------------------------------------- > option #4 > > ib01 Link encap:Infina HWaddr > 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > inet addr:10.7.159.98 Bcast:10.7.159.255 Mask:255.255.255.0 > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 > RX packets:5390566 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2388650 errors:0 dropped:0 overruns:0 carrier:0 > collisions:148295 txqueuelen:100 > RX bytes:809726070 (772.2 Mb) TX bytes:1584781754 (1511.3 Mb) > Interrupt:21 Base address:0xa000 > > Address HWtype HWaddress > Flags Mask Iface > 10.7.159.251 infina > 123456:FE80:0000:0000:0000:0002:c900:011c:9781 C ib01 > > -----Original Message----- > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] > Sent: Tuesday, January 14, 2003 12:45 PM > To: Larsen, Roy K > Cc: ipoverib@ietf.org; Kanoj Sarcar > Subject: Re: [Ipoverib] IPoIB/ifconfig question > > "Larsen, Roy K" wrote: > > > > Ah yes, 24 bits.... I had a brain fart and was thinking the QPN was 16. > > Then if fixed length is desirable, what you show for #4 is better than the > > 60 digit #1 (regardless of what the mib draft proposes). It just isn't > > practical to display 60 characters (although 47 characters is pretty much > in > > the same camp) and is not very parsable by a human. Remember, this > sequence > > would be displayed for things like ifconfig(8) and arp(8) which are fairly > > frequent administrative operations. I still like #3 but since I don't do > > much network administration, I don't know what the impact of a variable > > length hardware address would have. > > I think we are down to #1 and #4, right? (Another point against #3 is that > it *might* be confusing to have a v6 protocol layer addressing scheme > applied > to a link layer address; specially since the link layer address is not > 128bits > long). > > /rkl > As Roland points out, GIDs are IPv6 addresses so it doesn't bother me that > they follow an IPv6 format. The admin tools make it very clear where the hw > address is displayed > rkl/ But we are talking about GID+QPN here, and since thats 20b instead of v6 16 bytes, I don't know whether this is a good idea. The other part is, the GID is similar to v6 in the context of IBA network layer, but that same GID is being used as (part of) a link layer address for IPoIB. > > Here they are (with QPN=0x123456): > > 1. 00:12:34:56:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > (or 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 123456:FE80:0:0:0:2:c900:11c:9781) > > Given the irregularity (length wise) in the first few digits in 4, > I would think #2 would be better. Here it is: > > 2. 12:3456:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 12:3456:FE80:0:0:0:2:c900:11c:9781) > > I do have a preference for #1 still, primarily because > > a. it is the most easily adapatable to the "arp" command (ie, when you > are doing a "set" operation, it is very easy to teach "arp", which on > most systems currently only expect ethernet addresses, how to parse a > #1 style ib command, in contrast to #2 or #4). Any other format picked > can of course be handled, I have seen the least amount of work with #1 > while prototyping (I am dealing with Solaris, but I expect that to be > true on most other systems like BSD too; Linux has a -H option, so this > is not an issue). > > /rkl > When you say adaptable to the arp(8) command, are you taking into account > the display headaches I try to illustrate above? Given that the IPoIB > hardware address is virtual and the pathrecord is always required, do you > think "set" is viable? Even so, do you think the admin would want to enter > 60 characters as opposed to something around 27? > rkl/ We have to allow that "set"s might be meaningful in certain implementations. Does the Linux implementation allow it? If so, what is the syntax of the command, and how was "arp" modified for accepting IPoIB link address input? (For Solaris, which is similar to BSD, I can do "arp -s hostname 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81" I had to teach arp to accept not only a:b:c:d:e:f ethernet format, but also the 20b format). Yes, I am aware there are display issues, but I think they might be different issues on different platforms (eg Solaris prints the link address on a seperate line, so its lesser of an issue). > > b. I do believe there is value in matching the MIB format, specially since > admins might want to correlate the outputs from various commands (ifconfig, > arp, snoop and SNMP). > > /rkl > I don't disagree. But if the MIB format is not practical, we can change the > draft. Anyway, it doesn't have a display hint for IPoIB hardware address so > we can invent one. > rkl/ > > c. Any current scripts that parse ethernet addresses (HWaddr output in > Linux etc) if applicable on IPoIB would need to be converted; I am not > aware of any, but if there are some, logic in a. again applies. > > /rkl > I'm not aware of any need to parse a hardware address except perhaps to > compare them. Format in that case is not as important. > rkl/ > > The advantage of 2 and 4 are their somewhat shorter lengths. > /rkl > #3 is even shorter :^) > rkl/ > > > > > The network admin tools I work with already use a hardware type based > > library for displaying interface specific information so there is no need > to > > follow Ethernet convention from my point of view. > > > > What about (sysadmin) scripts that parse output from ifconfig (ie look at > HWaddr field), which currently assume ethernet format? > > /rkl > But I assume they already assume a fixed length representing 6 octets so > they are going to have to change anyway. At most, they are going to > comparisons so I don't think this a compelling argument for #1 > rkl/ > > I assume you are talking about Linux (and thus you have the -H arp option > to help)? Notice, you could still build in automatic parsing in Linux "arp", > > which on seeing format #1 will recognize it as an IPoIB address (ie, > the default type for 20b addresses can be IPoIB, similar to the default > type for 6b addresses is ethernet; this would allow admins not to have > to specify -H for each IPoIB operation, thus making IPoIB just a little > more similar to ethernet); I imagine it will be just a little harder to > do #2 or #4. > > /rkl > I believe the -H option only acts as a filter, not a display formatter. > rkl/ Okay. I am still curious about how Linux/IPoIB does a arp set operation. Thanks. Kanoj > > Thanks. > > Kanoj > > > Roy > > > > -----Original Message----- > > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] > > Sent: Tuesday, January 14, 2003 11:00 AM > > To: Larsen, Roy K > > Cc: ipoverib@ietf.org; Kanoj Sarcar > > Subject: Re: [Ipoverib] IPoIB/ifconfig question > > > > "Larsen, Roy K" wrote: > > > > > > Kanoj, > > > > > > While not a draft issue, I agree that it would be nice to use this forum > > to > > > set a de facto standard for IPoIB hardware address display format. > Given > > > the long length, I'm inclined to go with the most condensed > representation > > > which would be #3. However, this does not provide a fixed length > display > > > which is useful for scripting applications so I'm thinking a modified #2 > > > with all fixed length numbers and a single field QPN of 0014 instead of > > > 0:14). > > > > > > Roy > > > > > > > Roy, > > > > It was pointed out to me that > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt > > > > has > > > > IbGuid ::= TEXTUAL-CONVENTION > > DISPLAY-HINT "1x:" > > STATUS current > > DESCRIPTION > > > > It would seem to me that unless there is good reason for deviation, > > tcpdump/snoop/ifconfig/arp et al could just use this format (maps to > > option 1). > > > > Another reason I prefer 1 is because scripts written with the ethernet > > format in mind would mostly work (if the length issues were fixed in > > the script). Option 2 packs 16 bits in between each :, whereas these > > ethernet based scripts pack 8 bits. > > > > What do you think? > > > > The reason I went with 0:14 for the QPN (in #3) is because the QPN is > > actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 > > could be a possible value (theoretically). To represent that, I would > > need to say 12:3456:... I wanted this to look the same (in terms of > > number of :s) as in the case of QPN=0x00000014. Or are you suggesting > > something like > > > > 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > > > > in this case? > > > > Thanks. > > > > Kanoj > > > > > -----Original Message----- > > > From: Kanoj Sarcar [mailto:Kanoj.Sarcar@sun.com] > > > Sent: Monday, January 13, 2003 2:35 PM > > > To: ipoverib@ietf.org; Kanoj Sarcar > > > Subject: [Ipoverib] IPoIB/ifconfig question > > > > > > Hi, > > > > > > Here's an IPoIB implementation issue that I would > > > like to get feedback on from implementors. > > > > > > What should the ifconfig/arp/packet-sniffer output look like for > > > the mac address part of an IPoIB interface? In the examples below, > > > assume QPN=0x14, GID prefix is FE80::0 and GID suffix is > > > 0002c900011c9781, so that the mac address in hex is > > > 14FE800000000000000002c900011c9781. > > > > > > Some options might be > > > > > > 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > > > (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > > > 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781 > > > (or 0:14:FE80:0:0:0:2:c900:011c:9781) > > > 3: 0:14:FE80::2:c900:011c:9781 > > > > > > I understand this is probably not something that should be > > > put into any of the I/Ds, but it would be nice if various > > > vendors' outputs matched. My choice is option 1, since it > > > is the closest to how most systems represent ethernet > > > addresses (except the length of course). Most systems' > > > "arp" command is also easily converted to handle this > > > format and obviates the need for complicated parsing. > > > > > > Note that the I/D > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt > > > > > > on page 8 section 8.0 represents IBA multicast GIDs in v6 > > > format, I am not sure whether to suggest that the link layer > > > address should also be represented similarly by network tools. > > > > > > For reference, here's the ifconfig output line that prints > > > mac addresses on Solaris and Linux: > > > Link encap:Ethernet HWaddr 00:06:5B:4E:E4:6E > > > ether 8:0:20:d9:4:97 > > > > > > 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 Jan 14 18:55:38 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 SAA16494 for ; Tue, 14 Jan 2003 18:55: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 h0F099J14196; Tue, 14 Jan 2003 19:09:09 -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 h0F08NJ14153 for ; Tue, 14 Jan 2003 19:08:23 -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 SAA16455 for ; Tue, 14 Jan 2003 18:53:31 -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 h0ENpMh10127 for ; Tue, 14 Jan 2003 23:51:22 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 h0ENpq309252 for ; Tue, 14 Jan 2003 23:51:52 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011415582621762 ; Tue, 14 Jan 2003 15:58:26 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 15:56:45 -0800 Message-ID: From: "Larsen, Roy K" To: "'James Carlson'" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Tue, 14 Jan 2003 15:56:44 -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: , James, That's and easy one. The hw address is listed in the column labeled "Physical Address" and the IP under "Destination/Mask". :^) Roy -----Original Message----- From: James Carlson [mailto:james.d.carlson@east.sun.com] Sent: Tuesday, January 14, 2003 2:32 PM To: Larsen, Roy K Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Larsen, Roy K writes: > The more I think about it, the more I'm in favor of the condensed/IPv6 > format. I really would like to consider the aesthetic of the format. I think that's going to be exciting when you're using IPv6 over IB. % netstat -pnf inet6 Net to Media Table: IPv6 If Physical Address Type State Destination/Mask ----- ---------------------------------------------- ------- ------------ --------------------------- ib01 123456:fe80:0000:0000:0000:0002:c900:011c:9781 dynamic REACHABLE 2002:8194:aeaa:1:203:baff:fe00:de2f ... yuck. Which one is which? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue Jan 14 18:55:39 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 SAA16505 for ; Tue, 14 Jan 2003 18:55:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F0A0M14224 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 19:10:00 -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 h0F0A0J14221 for ; Tue, 14 Jan 2003 19:10:00 -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 SAA16485 for ; Tue, 14 Jan 2003 18:55: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 h0F099J14196; Tue, 14 Jan 2003 19:09:09 -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 h0F08NJ14153 for ; Tue, 14 Jan 2003 19:08:23 -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 SAA16455 for ; Tue, 14 Jan 2003 18:53:31 -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 h0ENpMh10127 for ; Tue, 14 Jan 2003 23:51:22 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 h0ENpq309252 for ; Tue, 14 Jan 2003 23:51:52 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011415582621762 ; Tue, 14 Jan 2003 15:58:26 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 15:56:45 -0800 Message-ID: From: "Larsen, Roy K" To: "'James Carlson'" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Tue, 14 Jan 2003 15:56:44 -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: , James, That's and easy one. The hw address is listed in the column labeled "Physical Address" and the IP under "Destination/Mask". :^) Roy -----Original Message----- From: James Carlson [mailto:james.d.carlson@east.sun.com] Sent: Tuesday, January 14, 2003 2:32 PM To: Larsen, Roy K Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Larsen, Roy K writes: > The more I think about it, the more I'm in favor of the condensed/IPv6 > format. I really would like to consider the aesthetic of the format. I think that's going to be exciting when you're using IPv6 over IB. % netstat -pnf inet6 Net to Media Table: IPv6 If Physical Address Type State Destination/Mask ----- ---------------------------------------------- ------- ------------ --------------------------- ib01 123456:fe80:0000:0000:0000:0002:c900:011c:9781 dynamic REACHABLE 2002:8194:aeaa:1:203:baff:fe00:de2f ... yuck. Which one is which? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue Jan 14 19:32:47 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 TAA17314 for ; Tue, 14 Jan 2003 19:32:47 -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 h0F0kCJ16246; Tue, 14 Jan 2003 19:46: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 h0F0jeJ16230 for ; Tue, 14 Jan 2003 19:45:40 -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 TAA17253 for ; Tue, 14 Jan 2003 19:30:46 -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 h0F0VPF13445 for ; Wed, 15 Jan 2003 00:31:25 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 h0F0T7E11984 for ; Wed, 15 Jan 2003 00:29:07 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011416354114226 ; Tue, 14 Jan 2003 16:35:41 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 16:34:00 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@Sun.COM'" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Tue, 14 Jan 2003 16:33:59 -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: , /rkl coments in-line rkl/ -----Original Message----- From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] Sent: Tuesday, January 14, 2003 3:22 PM To: Larsen, Roy K Cc: ipoverib@ietf.org; Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question "Larsen, Roy K" wrote: > > The more I think about it, the more I'm in favor of the condensed/IPv6 > format. I really would like to consider the aesthetic of the format. > Although my mailer is probably going to wrap these lines (a hint at what it > would look like on an 80 character xterm), consider the following displays > from a Linux system. The first is the standard output (80 character line > length) followed by option #1(120 chars), #3(88 chars) and #4(107 chars). > Note that the arp header is constant meaning that it would take the new > field widths for all network devices including Ethernet. Also keep in mind > that the primary reason to display this info is for a human to read. Of > these, I believe the admin would want to use option #3 for input and output. > It's easy enough to change/add a MIB definition for a IPoIB hardware address > (as opposed to the GUID display hint that folks have alluded to). > Roy, You might also want to try a non-default GID prefix, specially one that does not have too many runs of 0s. I am not sure if the Linux implementation will allow that, but it is probably possible on other systems. In that case, the benefits of #3 might be limited (whereas 1, 2 and 4 are independent of actual values). /rkl I take your point but my assumptions is that there would always be display economy using the condensed format rkl/ Another suggestion is to eliminate leading 0's for all options (that can only shorten the output) when you compare. Comments below. > Other comments in-line /rkl > Roy > I am including output from a Solaris system here, similar to what Roy did for Linux: hme0: flags=1000843 mtu 1500 index 2 inet 10.7.198.20 netmask ffffff00 broadcast 10.7.198.255 ether 8:0:20:d9:4:97 ibd0: flags=1000843 mtu 504 index 3 inet 192.129.100.100 netmask ffffff00 broadcast 192.129.100.255 ib 0:0:0:14:0:0:0:0:0:0:0:4:0:2:C9:0:1:1C:97:81 root@pap# arp pap pap (10.7.198.20) at 8:0:20:d9:4:97 permanent published root@pap# arp pap-ibd pap-ibd (192.129.100.100) at 0:0:0:14:0:0:0:0:0:0:0:4:0:2:C9:0:1:1C:97:81 permanent established /rkl Clearly the Solaris output is more suited for long hardware address display. This is not the case for Linux.... rkl/ > I think we are down to #1 and #4, right? (Another point against #3 is that > it *might* be confusing to have a v6 protocol layer addressing scheme > applied > to a link layer address; specially since the link layer address is not > 128bits > long). > > /rkl > As Roland points out, GIDs are IPv6 addresses so it doesn't bother me that > they follow an IPv6 format. The admin tools make it very clear where the hw > address is displayed > rkl/ But we are talking about GID+QPN here, and since thats 20b instead of v6 16 bytes, I don't know whether this is a good idea. The other part is, the GID is similar to v6 in the context of IBA network layer, but that same GID is being used as (part of) a link layer address for IPoIB. /rkl I'm not sure I appreciate why this would matter. Although the componets of the hw address are generally not a concern to the admin, the GID is a component. I'm just looking for a way to make them more user/display friendly in the same way the IPv6 folks made their address more friendly. rkl/ > > Here they are (with QPN=0x123456): > > 1. 00:12:34:56:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > (or 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 123456:FE80:0:0:0:2:c900:11c:9781) > > Given the irregularity (length wise) in the first few digits in 4, > I would think #2 would be better. Here it is: > > 2. 12:3456:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 12:3456:FE80:0:0:0:2:c900:11c:9781) > > I do have a preference for #1 still, primarily because > > a. it is the most easily adapatable to the "arp" command (ie, when you > are doing a "set" operation, it is very easy to teach "arp", which on > most systems currently only expect ethernet addresses, how to parse a > #1 style ib command, in contrast to #2 or #4). Any other format picked > can of course be handled, I have seen the least amount of work with #1 > while prototyping (I am dealing with Solaris, but I expect that to be > true on most other systems like BSD too; Linux has a -H option, so this > is not an issue). > > /rkl > When you say adaptable to the arp(8) command, are you taking into account > the display headaches I try to illustrate above? Given that the IPoIB > hardware address is virtual and the pathrecord is always required, do you > think "set" is viable? Even so, do you think the admin would want to enter > 60 characters as opposed to something around 27? > rkl/ We have to allow that "set"s might be meaningful in certain implementations. Does the Linux implementation allow it? If so, what is the syntax of the command, and how was "arp" modified for accepting IPoIB link address input? (For Solaris, which is similar to BSD, I can do "arp -s hostname 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81" I had to teach arp to accept not only a:b:c:d:e:f ethernet format, but also the 20b format). /rkl Although I have taken a look at the Linux kernel and network admin tools that are affected, the SourceForge project has not jet tackled these. Currently they truncate the IPoIB hardware address. I believe the Linux maintainers have just accepted the changes needed to deal with the kernel/user interface (the sock_addr size issue). Yes, Linux arp(8), as a facility, allows entries to be set. rkl/ Yes, I am aware there are display issues, but I think they might be different issues on different platforms (eg Solaris prints the link address on a seperate line, so its lesser of an issue). /rkl This is my primary concern since changes here will affect the display format for all network devices including Ethernet on Linux. It appears the Solaris format makes long hw addresses painless. This is not true for Linux and must be taken into consideration. The customer experience is more important to me that a standardized format. If changing the core Linux display format for ifconfig(8) and arp(8) is acceptable, that may be a way to satisfy both interests. rkl/ > What about (sysadmin) scripts that parse output from ifconfig (ie look at > HWaddr field), which currently assume ethernet format? > > /rkl > But I assume they already assume a fixed length representing 6 octets so > they are going to have to change anyway. At most, they are going to > comparisons so I don't think this a compelling argument for #1 > rkl/ > > I assume you are talking about Linux (and thus you have the -H arp option > to help)? Notice, you could still build in automatic parsing in Linux "arp", > > which on seeing format #1 will recognize it as an IPoIB address (ie, > the default type for 20b addresses can be IPoIB, similar to the default > type for 6b addresses is ethernet; this would allow admins not to have > to specify -H for each IPoIB operation, thus making IPoIB just a little > more similar to ethernet); I imagine it will be just a little harder to > do #2 or #4. > > /rkl > I believe the -H option only acts as a filter, not a display formatter. > rkl/ Okay. I am still curious about how Linux/IPoIB does a arp set operation. /rkl When implemented, it would be set in the same way as any non-default (ether) network device: arp -H infini -s The format of the address is network device dependent so any format would be acceptable. Roy rkl/ Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue Jan 14 19:32:47 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 TAA17327 for ; Tue, 14 Jan 2003 19:32:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F0l9L16293 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 19:47:09 -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 h0F0l9J16290 for ; Tue, 14 Jan 2003 19:47:09 -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 TAA17307 for ; Tue, 14 Jan 2003 19:32:15 -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 h0F0kCJ16246; Tue, 14 Jan 2003 19:46: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 h0F0jeJ16230 for ; Tue, 14 Jan 2003 19:45:40 -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 TAA17253 for ; Tue, 14 Jan 2003 19:30:46 -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 h0F0VPF13445 for ; Wed, 15 Jan 2003 00:31:25 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) 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 h0F0T7E11984 for ; Wed, 15 Jan 2003 00:29:07 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011416354114226 ; Tue, 14 Jan 2003 16:35:41 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 16:34:00 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@Sun.COM'" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Tue, 14 Jan 2003 16:33:59 -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: , /rkl coments in-line rkl/ -----Original Message----- From: Kanoj Sarcar [mailto:Kanoj.Sarcar@Sun.COM] Sent: Tuesday, January 14, 2003 3:22 PM To: Larsen, Roy K Cc: ipoverib@ietf.org; Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question "Larsen, Roy K" wrote: > > The more I think about it, the more I'm in favor of the condensed/IPv6 > format. I really would like to consider the aesthetic of the format. > Although my mailer is probably going to wrap these lines (a hint at what it > would look like on an 80 character xterm), consider the following displays > from a Linux system. The first is the standard output (80 character line > length) followed by option #1(120 chars), #3(88 chars) and #4(107 chars). > Note that the arp header is constant meaning that it would take the new > field widths for all network devices including Ethernet. Also keep in mind > that the primary reason to display this info is for a human to read. Of > these, I believe the admin would want to use option #3 for input and output. > It's easy enough to change/add a MIB definition for a IPoIB hardware address > (as opposed to the GUID display hint that folks have alluded to). > Roy, You might also want to try a non-default GID prefix, specially one that does not have too many runs of 0s. I am not sure if the Linux implementation will allow that, but it is probably possible on other systems. In that case, the benefits of #3 might be limited (whereas 1, 2 and 4 are independent of actual values). /rkl I take your point but my assumptions is that there would always be display economy using the condensed format rkl/ Another suggestion is to eliminate leading 0's for all options (that can only shorten the output) when you compare. Comments below. > Other comments in-line /rkl > Roy > I am including output from a Solaris system here, similar to what Roy did for Linux: hme0: flags=1000843 mtu 1500 index 2 inet 10.7.198.20 netmask ffffff00 broadcast 10.7.198.255 ether 8:0:20:d9:4:97 ibd0: flags=1000843 mtu 504 index 3 inet 192.129.100.100 netmask ffffff00 broadcast 192.129.100.255 ib 0:0:0:14:0:0:0:0:0:0:0:4:0:2:C9:0:1:1C:97:81 root@pap# arp pap pap (10.7.198.20) at 8:0:20:d9:4:97 permanent published root@pap# arp pap-ibd pap-ibd (192.129.100.100) at 0:0:0:14:0:0:0:0:0:0:0:4:0:2:C9:0:1:1C:97:81 permanent established /rkl Clearly the Solaris output is more suited for long hardware address display. This is not the case for Linux.... rkl/ > I think we are down to #1 and #4, right? (Another point against #3 is that > it *might* be confusing to have a v6 protocol layer addressing scheme > applied > to a link layer address; specially since the link layer address is not > 128bits > long). > > /rkl > As Roland points out, GIDs are IPv6 addresses so it doesn't bother me that > they follow an IPv6 format. The admin tools make it very clear where the hw > address is displayed > rkl/ But we are talking about GID+QPN here, and since thats 20b instead of v6 16 bytes, I don't know whether this is a good idea. The other part is, the GID is similar to v6 in the context of IBA network layer, but that same GID is being used as (part of) a link layer address for IPoIB. /rkl I'm not sure I appreciate why this would matter. Although the componets of the hw address are generally not a concern to the admin, the GID is a component. I'm just looking for a way to make them more user/display friendly in the same way the IPv6 folks made their address more friendly. rkl/ > > Here they are (with QPN=0x123456): > > 1. 00:12:34:56:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81 > (or 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81) > 4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 123456:FE80:0:0:0:2:c900:11c:9781) > > Given the irregularity (length wise) in the first few digits in 4, > I would think #2 would be better. Here it is: > > 2. 12:3456:FE80:0000:0000:0000:0002:c900:011c:9781 > (or 12:3456:FE80:0:0:0:2:c900:11c:9781) > > I do have a preference for #1 still, primarily because > > a. it is the most easily adapatable to the "arp" command (ie, when you > are doing a "set" operation, it is very easy to teach "arp", which on > most systems currently only expect ethernet addresses, how to parse a > #1 style ib command, in contrast to #2 or #4). Any other format picked > can of course be handled, I have seen the least amount of work with #1 > while prototyping (I am dealing with Solaris, but I expect that to be > true on most other systems like BSD too; Linux has a -H option, so this > is not an issue). > > /rkl > When you say adaptable to the arp(8) command, are you taking into account > the display headaches I try to illustrate above? Given that the IPoIB > hardware address is virtual and the pathrecord is always required, do you > think "set" is viable? Even so, do you think the admin would want to enter > 60 characters as opposed to something around 27? > rkl/ We have to allow that "set"s might be meaningful in certain implementations. Does the Linux implementation allow it? If so, what is the syntax of the command, and how was "arp" modified for accepting IPoIB link address input? (For Solaris, which is similar to BSD, I can do "arp -s hostname 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81" I had to teach arp to accept not only a:b:c:d:e:f ethernet format, but also the 20b format). /rkl Although I have taken a look at the Linux kernel and network admin tools that are affected, the SourceForge project has not jet tackled these. Currently they truncate the IPoIB hardware address. I believe the Linux maintainers have just accepted the changes needed to deal with the kernel/user interface (the sock_addr size issue). Yes, Linux arp(8), as a facility, allows entries to be set. rkl/ Yes, I am aware there are display issues, but I think they might be different issues on different platforms (eg Solaris prints the link address on a seperate line, so its lesser of an issue). /rkl This is my primary concern since changes here will affect the display format for all network devices including Ethernet on Linux. It appears the Solaris format makes long hw addresses painless. This is not true for Linux and must be taken into consideration. The customer experience is more important to me that a standardized format. If changing the core Linux display format for ifconfig(8) and arp(8) is acceptable, that may be a way to satisfy both interests. rkl/ > What about (sysadmin) scripts that parse output from ifconfig (ie look at > HWaddr field), which currently assume ethernet format? > > /rkl > But I assume they already assume a fixed length representing 6 octets so > they are going to have to change anyway. At most, they are going to > comparisons so I don't think this a compelling argument for #1 > rkl/ > > I assume you are talking about Linux (and thus you have the -H arp option > to help)? Notice, you could still build in automatic parsing in Linux "arp", > > which on seeing format #1 will recognize it as an IPoIB address (ie, > the default type for 20b addresses can be IPoIB, similar to the default > type for 6b addresses is ethernet; this would allow admins not to have > to specify -H for each IPoIB operation, thus making IPoIB just a little > more similar to ethernet); I imagine it will be just a little harder to > do #2 or #4. > > /rkl > I believe the -H option only acts as a filter, not a display formatter. > rkl/ Okay. I am still curious about how Linux/IPoIB does a arp set operation. /rkl When implemented, it would be set in the same way as any non-default (ether) network device: arp -H infini -s The format of the address is network device dependent so any format would be acceptable. Roy rkl/ Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue Jan 14 21:07:44 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 VAA18992 for ; Tue, 14 Jan 2003 21:07:44 -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 h0F2LAJ21776; Tue, 14 Jan 2003 21:21:11 -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 h0F2K4J21743 for ; Tue, 14 Jan 2003 21:20:04 -0500 Received: from nwkea-mail-2.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18935 for ; Tue, 14 Jan 2003 21:05:08 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01107; Tue, 14 Jan 2003 18:08:29 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0F28S4w014941; Tue, 14 Jan 2003 18:08:28 -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 <0H8Q00FHBGM4CM@ha1sun-mail1.eng.sun.com>; Tue, 14 Jan 2003 18:08:28 -0800 (PST) Date: Tue, 14 Jan 2003 18:08:28 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question To: "Larsen, Roy K" Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E24C29C.A5F5D758@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 > Roy, > > You might also want to try a non-default GID prefix, specially one that does > not have too many runs of 0s. I am not sure if the Linux implementation will > allow that, but it is probably possible on other systems. In that case, the > benefits of #3 might be limited (whereas 1, 2 and 4 are independent of > actual > values). > > /rkl > I take your point but my assumptions is that there would always be display > economy using the condensed format > rkl/ True. But see below what the (at least perceived) reasons are against this format. I think the main problem is in formatting the ifconfig/arp output; adoption of a v6-like format does not guarantee you solve that problem for non default GIDs (on Linux, that is). > /rkl > Clearly the Solaris output is more suited for long hardware address display. > This is not the case for Linux.... > rkl/ > True, it can accommodate longer addresses by virtue of being on a seperate line (and I am not claiming anyone did this by design). Notice that both Linux and Solaris places the inet6 address on a seperate line. I don't think I would suggest trying to change Linux's ifconfig to print the HWaddr on a seperate line. > > > > I think we are down to #1 and #4, right? (Another point against #3 is that > > it *might* be confusing to have a v6 protocol layer addressing scheme > > applied > > to a link layer address; specially since the link layer address is not > > 128bits > > long). > > > > /rkl > > As Roland points out, GIDs are IPv6 addresses so it doesn't bother me that > > they follow an IPv6 format. The admin tools make it very clear where the > hw > > address is displayed > > rkl/ > > But we are talking about GID+QPN here, and since thats 20b instead of v6 > 16 bytes, I don't know whether this is a good idea. The other part is, the > GID is similar to v6 in the context of IBA network layer, but that same > GID is being used as (part of) a link layer address for IPoIB. > > /rkl > I'm not sure I appreciate why this would matter. Although the componets of > the hw address are generally not a concern to the admin, the GID is a > component. I'm just looking for a way to make them more user/display > friendly in the same way the IPv6 folks made their address more friendly. > rkl/ > Agreed; I am just pointing out ([in]valid?) reasons why this might be confusing. > > We have to allow that "set"s might be meaningful in certain implementations. > Does the Linux implementation allow it? If so, what is the syntax of the > command, and how was "arp" modified for accepting IPoIB link address input? > (For Solaris, which is similar to BSD, I can do > "arp -s hostname 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81" > I had to teach arp to accept not only a:b:c:d:e:f ethernet format, but also > the 20b format). > > /rkl > Although I have taken a look at the Linux kernel and network admin tools > that are affected, the SourceForge project has not jet tackled these. > Currently they truncate the IPoIB hardware address. I believe the Linux > maintainers have just accepted the changes needed to deal with the > kernel/user interface (the sock_addr size issue). Yes, Linux arp(8), as a > facility, allows entries to be set. > rkl/ > Off topic, but I am very curious to find out exactly what sock_addr changes were accepted. Can you provide pointers (names of ioctls, or structures, in 2.4.X or 2.5.X)? Also, I am not sure of the ifconfig output that you provided: was that based on hacking up ifconfig/arp to demonstrate what might happen with longer addresses? > Yes, I am aware there are display issues, but I think they might be > different > issues on different platforms (eg Solaris prints the link address on a > seperate > line, so its lesser of an issue). > > /rkl > This is my primary concern since changes here will affect the display format > for all network devices including Ethernet on Linux. It appears the Solaris > format makes long hw addresses painless. This is not true for Linux and > must be taken into consideration. The customer experience is more important > to me that a standardized format. If changing the core Linux display format > for ifconfig(8) and arp(8) is acceptable, that may be a way to satisfy both > interests. > rkl/ > I am not sure what you are saying: in all your Linux/ifconfig examples, you did not change the core display format, and as you point out, option #3 seemed to experience least line wrap issues (at least with the address that was tried). If you change the ifconfig/arp output format (for Ethernet and all else, probably by putting the HWaddr on a seperate line), you might be able to solve the problem (and in which case, you can adopt option #1 too). Option #3 is good in default GID cases, but is not guaranteed to work always. > > > > What about (sysadmin) scripts that parse output from ifconfig (ie look at > > HWaddr field), which currently assume ethernet format? > > > > /rkl > > But I assume they already assume a fixed length representing 6 octets so > > they are going to have to change anyway. At most, they are going to > > comparisons so I don't think this a compelling argument for #1 > > rkl/ > > > > I assume you are talking about Linux (and thus you have the -H arp option > > to help)? Notice, you could still build in automatic parsing in Linux > "arp", > > > > which on seeing format #1 will recognize it as an IPoIB address (ie, > > the default type for 20b addresses can be IPoIB, similar to the default > > type for 6b addresses is ethernet; this would allow admins not to have > > to specify -H for each IPoIB operation, thus making IPoIB just a little > > more similar to ethernet); I imagine it will be just a little harder to > > do #2 or #4. > > > > /rkl > > I believe the -H option only acts as a filter, not a display formatter. > > rkl/ > > Okay. I am still curious about how Linux/IPoIB does a arp set operation. > > /rkl > When implemented, it would be set in the same way as any non-default (ether) > network device: > arp -H infini -s > > The format of the address is network device dependent so any format would be > acceptable. > > Roy > rkl/ > Also, note the suggestion I made, that -H might not be needed if arp can be taught that the default media for option #1 (or any other formatting option that you/we finally pick) is for IPoIB. If any other current/future media happens to use the same formatting option, they will be constrained to using -H. Thanks. Kanoj > Thanks. > > Kanoj > > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue Jan 14 21:07:45 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 VAA19005 for ; Tue, 14 Jan 2003 21:07:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F2M9k21837 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 21:22:09 -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 h0F2M9J21834 for ; Tue, 14 Jan 2003 21:22:09 -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 VAA18973 for ; Tue, 14 Jan 2003 21:07: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 h0F2LAJ21776; Tue, 14 Jan 2003 21:21:11 -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 h0F2K4J21743 for ; Tue, 14 Jan 2003 21:20:04 -0500 Received: from nwkea-mail-2.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18935 for ; Tue, 14 Jan 2003 21:05:08 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01107; Tue, 14 Jan 2003 18:08:29 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0F28S4w014941; Tue, 14 Jan 2003 18:08:28 -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 <0H8Q00FHBGM4CM@ha1sun-mail1.eng.sun.com>; Tue, 14 Jan 2003 18:08:28 -0800 (PST) Date: Tue, 14 Jan 2003 18:08:28 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question To: "Larsen, Roy K" Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E24C29C.A5F5D758@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 > Roy, > > You might also want to try a non-default GID prefix, specially one that does > not have too many runs of 0s. I am not sure if the Linux implementation will > allow that, but it is probably possible on other systems. In that case, the > benefits of #3 might be limited (whereas 1, 2 and 4 are independent of > actual > values). > > /rkl > I take your point but my assumptions is that there would always be display > economy using the condensed format > rkl/ True. But see below what the (at least perceived) reasons are against this format. I think the main problem is in formatting the ifconfig/arp output; adoption of a v6-like format does not guarantee you solve that problem for non default GIDs (on Linux, that is). > /rkl > Clearly the Solaris output is more suited for long hardware address display. > This is not the case for Linux.... > rkl/ > True, it can accommodate longer addresses by virtue of being on a seperate line (and I am not claiming anyone did this by design). Notice that both Linux and Solaris places the inet6 address on a seperate line. I don't think I would suggest trying to change Linux's ifconfig to print the HWaddr on a seperate line. > > > > I think we are down to #1 and #4, right? (Another point against #3 is that > > it *might* be confusing to have a v6 protocol layer addressing scheme > > applied > > to a link layer address; specially since the link layer address is not > > 128bits > > long). > > > > /rkl > > As Roland points out, GIDs are IPv6 addresses so it doesn't bother me that > > they follow an IPv6 format. The admin tools make it very clear where the > hw > > address is displayed > > rkl/ > > But we are talking about GID+QPN here, and since thats 20b instead of v6 > 16 bytes, I don't know whether this is a good idea. The other part is, the > GID is similar to v6 in the context of IBA network layer, but that same > GID is being used as (part of) a link layer address for IPoIB. > > /rkl > I'm not sure I appreciate why this would matter. Although the componets of > the hw address are generally not a concern to the admin, the GID is a > component. I'm just looking for a way to make them more user/display > friendly in the same way the IPv6 folks made their address more friendly. > rkl/ > Agreed; I am just pointing out ([in]valid?) reasons why this might be confusing. > > We have to allow that "set"s might be meaningful in certain implementations. > Does the Linux implementation allow it? If so, what is the syntax of the > command, and how was "arp" modified for accepting IPoIB link address input? > (For Solaris, which is similar to BSD, I can do > "arp -s hostname 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81" > I had to teach arp to accept not only a:b:c:d:e:f ethernet format, but also > the 20b format). > > /rkl > Although I have taken a look at the Linux kernel and network admin tools > that are affected, the SourceForge project has not jet tackled these. > Currently they truncate the IPoIB hardware address. I believe the Linux > maintainers have just accepted the changes needed to deal with the > kernel/user interface (the sock_addr size issue). Yes, Linux arp(8), as a > facility, allows entries to be set. > rkl/ > Off topic, but I am very curious to find out exactly what sock_addr changes were accepted. Can you provide pointers (names of ioctls, or structures, in 2.4.X or 2.5.X)? Also, I am not sure of the ifconfig output that you provided: was that based on hacking up ifconfig/arp to demonstrate what might happen with longer addresses? > Yes, I am aware there are display issues, but I think they might be > different > issues on different platforms (eg Solaris prints the link address on a > seperate > line, so its lesser of an issue). > > /rkl > This is my primary concern since changes here will affect the display format > for all network devices including Ethernet on Linux. It appears the Solaris > format makes long hw addresses painless. This is not true for Linux and > must be taken into consideration. The customer experience is more important > to me that a standardized format. If changing the core Linux display format > for ifconfig(8) and arp(8) is acceptable, that may be a way to satisfy both > interests. > rkl/ > I am not sure what you are saying: in all your Linux/ifconfig examples, you did not change the core display format, and as you point out, option #3 seemed to experience least line wrap issues (at least with the address that was tried). If you change the ifconfig/arp output format (for Ethernet and all else, probably by putting the HWaddr on a seperate line), you might be able to solve the problem (and in which case, you can adopt option #1 too). Option #3 is good in default GID cases, but is not guaranteed to work always. > > > > What about (sysadmin) scripts that parse output from ifconfig (ie look at > > HWaddr field), which currently assume ethernet format? > > > > /rkl > > But I assume they already assume a fixed length representing 6 octets so > > they are going to have to change anyway. At most, they are going to > > comparisons so I don't think this a compelling argument for #1 > > rkl/ > > > > I assume you are talking about Linux (and thus you have the -H arp option > > to help)? Notice, you could still build in automatic parsing in Linux > "arp", > > > > which on seeing format #1 will recognize it as an IPoIB address (ie, > > the default type for 20b addresses can be IPoIB, similar to the default > > type for 6b addresses is ethernet; this would allow admins not to have > > to specify -H for each IPoIB operation, thus making IPoIB just a little > > more similar to ethernet); I imagine it will be just a little harder to > > do #2 or #4. > > > > /rkl > > I believe the -H option only acts as a filter, not a display formatter. > > rkl/ > > Okay. I am still curious about how Linux/IPoIB does a arp set operation. > > /rkl > When implemented, it would be set in the same way as any non-default (ether) > network device: > arp -H infini -s > > The format of the address is network device dependent so any format would be > acceptable. > > Roy > rkl/ > Also, note the suggestion I made, that -H might not be needed if arp can be taught that the default media for option #1 (or any other formatting option that you/we finally pick) is for IPoIB. If any other current/future media happens to use the same formatting option, they will be constrained to using -H. Thanks. Kanoj > Thanks. > > Kanoj > > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue Jan 14 21:23: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 VAA19325 for ; Tue, 14 Jan 2003 21:23: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 h0F2b5J22626; Tue, 14 Jan 2003 21:37:05 -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 h0F2aQJ22516 for ; Tue, 14 Jan 2003 21:36:26 -0500 Received: from umhlanga.STRATNET.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19232 for ; Tue, 14 Jan 2003 21:21:30 -0500 (EST) Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 18:24:51 -0800 Received: from gold ([10.10.253.60] unverified) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 18:24:31 -0800 Received: from roland by gold with local (Exim 3.35 #1 (Debian)) id 18YdEX-000081-00; Tue, 14 Jan 2003 18:24:49 -0800 To: Kanoj.Sarcar@sun.com Cc: ipoverib@ietf.org Subject: Re: [Ipoverib] IPoIB/ifconfig question References: <3E24C29C.A5F5D758@Sun.COM> X-Message-Flag: Warning: May contain useful information X-Priority: 1 X-MSMail-Priority: High From: Roland Dreier Date: 14 Jan 2003 18:24:49 -0800 In-Reply-To: <3E24C29C.A5F5D758@Sun.COM> Message-ID: <521y3fkv4e.fsf@topspin.com> Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 15 Jan 2003 02:24:31.0515 (UTC) FILETIME=[3C93EEB0:01C2BC3D] 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> Off topic, but I am very curious to find out exactly what Kanoj> sock_addr changes were accepted. Can you provide pointers Kanoj> (names of ioctls, or structures, in 2.4.X or 2.5.X)? I was the author of the patch that went into the 2.5.55 Linux kernel. It increased Linux's MAX_ADDR_LEN from 8 to 32, and extended the rtnetlink facility to allow setting the hardware and broadcast address of an interface. rtnetlink already handled arbitrary lengths properly, and provided mechanisms for querying hardware addresses and managing ARP entries. struct sock_addr did not change, so SIOCGIFHWADDR et al will not work correctly for IPoIB interfaces. Users will probably have to use the ip command (from the iproute2 package) instead of ifconfig. If you would like a copy of the actual patch, I would be happy to forward it to you. Best, Roland _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue Jan 14 21:23:38 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 VAA19335 for ; Tue, 14 Jan 2003 21:23:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F2c2f23270 for ipoverib-archive@odin.ietf.org; Tue, 14 Jan 2003 21:38:02 -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 h0F2c2J23267 for ; Tue, 14 Jan 2003 21:38:02 -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 VAA19268 for ; Tue, 14 Jan 2003 21:23:07 -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 h0F2b5J22626; Tue, 14 Jan 2003 21:37:05 -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 h0F2aQJ22516 for ; Tue, 14 Jan 2003 21:36:26 -0500 Received: from umhlanga.STRATNET.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19232 for ; Tue, 14 Jan 2003 21:21:30 -0500 (EST) Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 18:24:51 -0800 Received: from gold ([10.10.253.60] unverified) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 18:24:31 -0800 Received: from roland by gold with local (Exim 3.35 #1 (Debian)) id 18YdEX-000081-00; Tue, 14 Jan 2003 18:24:49 -0800 To: Kanoj.Sarcar@sun.com Cc: ipoverib@ietf.org Subject: Re: [Ipoverib] IPoIB/ifconfig question References: <3E24C29C.A5F5D758@Sun.COM> X-Message-Flag: Warning: May contain useful information X-Priority: 1 X-MSMail-Priority: High From: Roland Dreier Date: 14 Jan 2003 18:24:49 -0800 In-Reply-To: <3E24C29C.A5F5D758@Sun.COM> Message-ID: <521y3fkv4e.fsf@topspin.com> Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 15 Jan 2003 02:24:31.0515 (UTC) FILETIME=[3C93EEB0:01C2BC3D] 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> Off topic, but I am very curious to find out exactly what Kanoj> sock_addr changes were accepted. Can you provide pointers Kanoj> (names of ioctls, or structures, in 2.4.X or 2.5.X)? I was the author of the patch that went into the 2.5.55 Linux kernel. It increased Linux's MAX_ADDR_LEN from 8 to 32, and extended the rtnetlink facility to allow setting the hardware and broadcast address of an interface. rtnetlink already handled arbitrary lengths properly, and provided mechanisms for querying hardware addresses and managing ARP entries. struct sock_addr did not change, so SIOCGIFHWADDR et al will not work correctly for IPoIB interfaces. Users will probably have to use the ip command (from the iproute2 package) instead of ifconfig. If you would like a copy of the actual patch, I would be happy to forward it to you. Best, Roland _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed Jan 15 12:23:38 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 MAA04144 for ; Wed, 15 Jan 2003 12:23: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 h0FHbKJ28204; Wed, 15 Jan 2003 12:37:20 -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 h0FHaWJ27772 for ; Wed, 15 Jan 2003 12:36:32 -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 MAA04087 for ; Wed, 15 Jan 2003 12:21:17 -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 h0FHJ6I13290 for ; Wed, 15 Jan 2003 17:19:06 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 h0FHJfd16315 for ; Wed, 15 Jan 2003 17:19:41 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011509223831032 ; Wed, 15 Jan 2003 09:22:38 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:24:34 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@Sun.COM'" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Wed, 15 Jan 2003 09:24:22 -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: , Off topic, but I am very curious to find out exactly what sock_addr changes were accepted. Can you provide pointers (names of ioctls, or structures, in 2.4.X or 2.5.X)? Also, I am not sure of the ifconfig output that you provided: was that based on hacking up ifconfig/arp to demonstrate what might happen with longer addresses? /rkl Roland's mail addressed the changes (of which I was a little off base). Yes, I edited the output of the ifconfig/arp commands. I have not done any work yet toward implementing support IPoIB support for admin commands. rkl/ > Yes, I am aware there are display issues, but I think they might be > different > issues on different platforms (eg Solaris prints the link address on a > seperate > line, so its lesser of an issue). > > /rkl > This is my primary concern since changes here will affect the display format > for all network devices including Ethernet on Linux. It appears the Solaris > format makes long hw addresses painless. This is not true for Linux and > must be taken into consideration. The customer experience is more important > to me that a standardized format. If changing the core Linux display format > for ifconfig(8) and arp(8) is acceptable, that may be a way to satisfy both > interests. > rkl/ > I am not sure what you are saying: in all your Linux/ifconfig examples, you did not change the core display format, and as you point out, option #3 seemed to experience least line wrap issues (at least with the address that was tried). If you change the ifconfig/arp output format (for Ethernet and all else, probably by putting the HWaddr on a seperate line), you might be able to solve the problem (and in which case, you can adopt option #1 too). Option #3 is good in default GID cases, but is not guaranteed to work always. /rkl I am trying to say that the goal is to come up with a common hw address display format that provides a pleasing customer experience. But, the customer experience is paramount. I don't have any problem with option #1 or #4. However, I think there will be a lot of resistance by the Linux community to rearranging the current admin format but I am willing to explore that option. If I fail at making that change, the #3 format would be the most accommodating to the current ifconfig/arp commands - and I accept that it may be different than on other platforms (and may be unpleasing under certain GID values). Roy rkl/ Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed Jan 15 12:23:39 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 MAA04152 for ; Wed, 15 Jan 2003 12:23:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FHcLA28562 for ipoverib-archive@odin.ietf.org; Wed, 15 Jan 2003 12:38: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 h0FHcLJ28559 for ; Wed, 15 Jan 2003 12:38:21 -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 MAA04124 for ; Wed, 15 Jan 2003 12:23:07 -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 h0FHbKJ28204; Wed, 15 Jan 2003 12:37:20 -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 h0FHaWJ27772 for ; Wed, 15 Jan 2003 12:36:32 -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 MAA04087 for ; Wed, 15 Jan 2003 12:21:17 -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 h0FHJ6I13290 for ; Wed, 15 Jan 2003 17:19:06 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 h0FHJfd16315 for ; Wed, 15 Jan 2003 17:19:41 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011509223831032 ; Wed, 15 Jan 2003 09:22:38 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:24:34 -0800 Message-ID: From: "Larsen, Roy K" To: "'Kanoj.Sarcar@Sun.COM'" Cc: ipoverib@ietf.org Subject: RE: [Ipoverib] IPoIB/ifconfig question Date: Wed, 15 Jan 2003 09:24:22 -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: , Off topic, but I am very curious to find out exactly what sock_addr changes were accepted. Can you provide pointers (names of ioctls, or structures, in 2.4.X or 2.5.X)? Also, I am not sure of the ifconfig output that you provided: was that based on hacking up ifconfig/arp to demonstrate what might happen with longer addresses? /rkl Roland's mail addressed the changes (of which I was a little off base). Yes, I edited the output of the ifconfig/arp commands. I have not done any work yet toward implementing support IPoIB support for admin commands. rkl/ > Yes, I am aware there are display issues, but I think they might be > different > issues on different platforms (eg Solaris prints the link address on a > seperate > line, so its lesser of an issue). > > /rkl > This is my primary concern since changes here will affect the display format > for all network devices including Ethernet on Linux. It appears the Solaris > format makes long hw addresses painless. This is not true for Linux and > must be taken into consideration. The customer experience is more important > to me that a standardized format. If changing the core Linux display format > for ifconfig(8) and arp(8) is acceptable, that may be a way to satisfy both > interests. > rkl/ > I am not sure what you are saying: in all your Linux/ifconfig examples, you did not change the core display format, and as you point out, option #3 seemed to experience least line wrap issues (at least with the address that was tried). If you change the ifconfig/arp output format (for Ethernet and all else, probably by putting the HWaddr on a seperate line), you might be able to solve the problem (and in which case, you can adopt option #1 too). Option #3 is good in default GID cases, but is not guaranteed to work always. /rkl I am trying to say that the goal is to come up with a common hw address display format that provides a pleasing customer experience. But, the customer experience is paramount. I don't have any problem with option #1 or #4. However, I think there will be a lot of resistance by the Linux community to rearranging the current admin format but I am willing to explore that option. If I fail at making that change, the #3 format would be the most accommodating to the current ifconfig/arp commands - and I accept that it may be different than on other platforms (and may be unpleasing under certain GID values). Roy rkl/ Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed Jan 15 12:31:12 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 MAA04336 for ; Wed, 15 Jan 2003 12:31: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 h0FHg1J28745; Wed, 15 Jan 2003 12:42: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 h0FHfLJ28712 for ; Wed, 15 Jan 2003 12:41:21 -0500 Received: from umhlanga.STRATNET.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04181 for ; Wed, 15 Jan 2003 12:26:07 -0500 (EST) Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 09:29:28 -0800 Received: from gold ([10.10.253.60] unverified) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 09:29:07 -0800 Received: from roland by gold with local (Exim 3.35 #1 (Debian)) id 18YrLx-0005Ml-00 for ; Wed, 15 Jan 2003 09:29:25 -0800 To: ipoverib@ietf.org Subject: Re: [Ipoverib] IPoIB/ifconfig question References: <3E24C29C.A5F5D758@Sun.COM> <521y3fkv4e.fsf@topspin.com> X-Message-Flag: Warning: May contain useful information X-Priority: 1 X-MSMail-Priority: High From: Roland Dreier Date: 15 Jan 2003 09:29:25 -0800 In-Reply-To: <521y3fkv4e.fsf@topspin.com> Message-ID: <52of6ijp8q.fsf@topspin.com> Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 15 Jan 2003 17:29:07.0859 (UTC) FILETIME=[9BCCC630:01C2BCBB] 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: , By the way, here's the output format used today by the Linux iproute2 package. Note that it already handles (though not gracefully) long hardware addresses. The "link/[32]" is how ip currently displays an IPoIB hardware address. I would expect that to be replaced by "link/ipoib", and it would be easy to use any format we decide on for the actual address. (ib0 is a dummy driver I use for testing with a 20 byte hardware address; the specific hardware addresses shown are just random junk) # ip address 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:30:48:23:3c:f3 brd ff:ff:ff:ff:ff:ff inet 10.3.0.84/16 brd 10.3.255.255 scope global eth0 3: ib0: mtu 2044 qdisc pfifo_fast qlen 128 link/[32] bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc brd ff:fe:fd:fc:fb:fa:f9:f8:f7:f6:f5:f4:f3:f2:f1:f0:ef:ee:ed:ec inet 12.0.0.1/8 brd 12.255.255.255 scope global ib0 _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed Jan 15 12:31:12 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 MAA04345 for ; Wed, 15 Jan 2003 12:31:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FHjse28890 for ipoverib-archive@odin.ietf.org; Wed, 15 Jan 2003 12:45:54 -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 h0FHjsJ28887 for ; Wed, 15 Jan 2003 12:45:54 -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 MAA04309 for ; Wed, 15 Jan 2003 12:30:41 -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 h0FHg1J28745; Wed, 15 Jan 2003 12:42: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 h0FHfLJ28712 for ; Wed, 15 Jan 2003 12:41:21 -0500 Received: from umhlanga.STRATNET.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04181 for ; Wed, 15 Jan 2003 12:26:07 -0500 (EST) Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 09:29:28 -0800 Received: from gold ([10.10.253.60] unverified) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 09:29:07 -0800 Received: from roland by gold with local (Exim 3.35 #1 (Debian)) id 18YrLx-0005Ml-00 for ; Wed, 15 Jan 2003 09:29:25 -0800 To: ipoverib@ietf.org Subject: Re: [Ipoverib] IPoIB/ifconfig question References: <3E24C29C.A5F5D758@Sun.COM> <521y3fkv4e.fsf@topspin.com> X-Message-Flag: Warning: May contain useful information X-Priority: 1 X-MSMail-Priority: High From: Roland Dreier Date: 15 Jan 2003 09:29:25 -0800 In-Reply-To: <521y3fkv4e.fsf@topspin.com> Message-ID: <52of6ijp8q.fsf@topspin.com> Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 15 Jan 2003 17:29:07.0859 (UTC) FILETIME=[9BCCC630:01C2BCBB] 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: , By the way, here's the output format used today by the Linux iproute2 package. Note that it already handles (though not gracefully) long hardware addresses. The "link/[32]" is how ip currently displays an IPoIB hardware address. I would expect that to be replaced by "link/ipoib", and it would be easy to use any format we decide on for the actual address. (ib0 is a dummy driver I use for testing with a 20 byte hardware address; the specific hardware addresses shown are just random junk) # ip address 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:30:48:23:3c:f3 brd ff:ff:ff:ff:ff:ff inet 10.3.0.84/16 brd 10.3.255.255 scope global eth0 3: ib0: mtu 2044 qdisc pfifo_fast qlen 128 link/[32] bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc:bc brd ff:fe:fd:fc:fb:fa:f9:f8:f7:f6:f5:f4:f3:f2:f1:f0:ef:ee:ed:ec inet 12.0.0.1/8 brd 12.255.255.255 scope global ib0 _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed Jan 15 12:37:16 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 MAA04516 for ; Wed, 15 Jan 2003 12:37:16 -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 h0FHp3J29275; Wed, 15 Jan 2003 12:51:03 -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 h0FHolJ29245 for ; Wed, 15 Jan 2003 12:50:47 -0500 Received: from nwkea-mail-2.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04487 for ; Wed, 15 Jan 2003 12:35:33 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29058; Wed, 15 Jan 2003 09:38:53 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0FHcq4w001056; Wed, 15 Jan 2003 09:38:53 -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 <0H8R00MTQNOSZ8@ha1sun-mail1.eng.sun.com>; Wed, 15 Jan 2003 09:38:52 -0800 (PST) Date: Wed, 15 Jan 2003 09:38:52 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question To: Roland Dreier Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E259CAC.E245B598@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: <3E24C29C.A5F5D758@Sun.COM> <521y3fkv4e.fsf@topspin.com> 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 Roland Dreier wrote: > > Kanoj> Off topic, but I am very curious to find out exactly what > Kanoj> sock_addr changes were accepted. Can you provide pointers > Kanoj> (names of ioctls, or structures, in 2.4.X or 2.5.X)? > > I was the author of the patch that went into the 2.5.55 Linux kernel. > It increased Linux's MAX_ADDR_LEN from 8 to 32, and extended the > rtnetlink facility to allow setting the hardware and broadcast address > of an interface. rtnetlink already handled arbitrary lengths > properly, and provided mechanisms for querying hardware addresses and > managing ARP entries. > > struct sock_addr did not change, so SIOCGIFHWADDR et al will not work > correctly for IPoIB interfaces. Users will probably have to use the > ip command (from the iproute2 package) instead of ifconfig. > > If you would like a copy of the actual patch, I would be happy to > forward it to you. > > Best, > Roland Roland, Sure, I would like a copy of the patch (feel free to send it to me in private mail, if you think its appropriate). I imagine from your description though that you have enabled the Linux kernel (internally) to support 32b mac addresses, using existing RTM_NEWADDR/RTM_DELADDR/RTM_GETADDR messages to manipulate the ARP cache (using which command? GNU "arp" uses the SIOC*ARP calls, right?), and using new rtnetlink messages to set the hw/bcast address via a new ipoib-specific command (or will that be driven via the ip command for IPoIB interfaces?). Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed Jan 15 12:37:16 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 MAA04521 for ; Wed, 15 Jan 2003 12:37:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FHpwO29305 for ipoverib-archive@odin.ietf.org; Wed, 15 Jan 2003 12:51:58 -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 h0FHpwJ29302 for ; Wed, 15 Jan 2003 12:51:58 -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 MAA04504 for ; Wed, 15 Jan 2003 12:36:45 -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 h0FHp3J29275; Wed, 15 Jan 2003 12:51:03 -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 h0FHolJ29245 for ; Wed, 15 Jan 2003 12:50:47 -0500 Received: from nwkea-mail-2.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04487 for ; Wed, 15 Jan 2003 12:35:33 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29058; Wed, 15 Jan 2003 09:38:53 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0FHcq4w001056; Wed, 15 Jan 2003 09:38:53 -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 <0H8R00MTQNOSZ8@ha1sun-mail1.eng.sun.com>; Wed, 15 Jan 2003 09:38:52 -0800 (PST) Date: Wed, 15 Jan 2003 09:38:52 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] IPoIB/ifconfig question To: Roland Dreier Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E259CAC.E245B598@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: <3E24C29C.A5F5D758@Sun.COM> <521y3fkv4e.fsf@topspin.com> 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 Roland Dreier wrote: > > Kanoj> Off topic, but I am very curious to find out exactly what > Kanoj> sock_addr changes were accepted. Can you provide pointers > Kanoj> (names of ioctls, or structures, in 2.4.X or 2.5.X)? > > I was the author of the patch that went into the 2.5.55 Linux kernel. > It increased Linux's MAX_ADDR_LEN from 8 to 32, and extended the > rtnetlink facility to allow setting the hardware and broadcast address > of an interface. rtnetlink already handled arbitrary lengths > properly, and provided mechanisms for querying hardware addresses and > managing ARP entries. > > struct sock_addr did not change, so SIOCGIFHWADDR et al will not work > correctly for IPoIB interfaces. Users will probably have to use the > ip command (from the iproute2 package) instead of ifconfig. > > If you would like a copy of the actual patch, I would be happy to > forward it to you. > > Best, > Roland Roland, Sure, I would like a copy of the patch (feel free to send it to me in private mail, if you think its appropriate). I imagine from your description though that you have enabled the Linux kernel (internally) to support 32b mac addresses, using existing RTM_NEWADDR/RTM_DELADDR/RTM_GETADDR messages to manipulate the ARP cache (using which command? GNU "arp" uses the SIOC*ARP calls, right?), and using new rtnetlink messages to set the hw/bcast address via a new ipoib-specific command (or will that be driven via the ip command for IPoIB interfaces?). Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed Jan 15 17:01: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 RAA11430 for ; Wed, 15 Jan 2003 17:01: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 h0FMFLJ13966; Wed, 15 Jan 2003 17:15: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 h0FMAkJ13729 for ; Wed, 15 Jan 2003 17:10:46 -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 QAA11228 for ; Wed, 15 Jan 2003 16:55:26 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08514 for ; Wed, 15 Jan 2003 14:58:48 -0700 (MST) 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 h0FLwlgE011605 for ; Wed, 15 Jan 2003 13:58:47 -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 <0H8R005K3ZPZW7@ha1sun-mail1.eng.sun.com> for ipoverib@ietf.org; Wed, 15 Jan 2003 13:58:47 -0800 (PST) Date: Wed, 15 Jan 2003 13:58:47 -0800 From: Kanoj Sarcar To: ipoverib@ietf.org Cc: Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E25D997.B4F5DAD3@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: <3E24C29C.A5F5D758@Sun.COM> <521y3fkv4e.fsf@topspin.com> <52of6ijp8q.fsf@topspin.com> Content-Transfer-Encoding: 7BIT Subject: [Ipoverib] IPoIB/aton question 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 Folks, While I have your attention, there is another issue I would like to get feedback on from implementors. On BSD, Linux, Solaris, AIX etc, there are a set of calls (maybe with minor variations): #include #include #include #include #include char *ether_ntoa(struct ether_addr *e); struct ether_addr *ether_aton(const char *asc); It seems to me that most systems that support IPoIB will need something like: #include char *link_ntoa(char *addr, int length, int type); unsigned char *link_aton(const char *asc, int &size); to handle network to ascii formatting and vice-versa. (Note: ether_line is not relevant since IPoIB link address is not persistent and can not be put into ethers databases; similar logic applies to ether_ntohost() and ether_hostton(); link_aton() also sounds quite optional to me). The "type" field in link_ntoa() is to force media specific formatting behavior; its value should identify the media type (or 0 for default behavior). Thus for Linux, ARPHRD_ETHER, ARPHRD_INFINIBAND etc would be possible values, whereas for Solaris and other DLPI based systems, it would be DL_ETHER etc. link_ntoa() should by default format the xx:yy:... (sized according to the length argument) string, but its formatting action can be altered depending on the type input (eg a compressed v6 format for IPoIB, if that is the way Linux should go). Are there any plans on these lines by IPoIB implementors on various systems? Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed Jan 15 17:01: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 RAA11438 for ; Wed, 15 Jan 2003 17:01:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMGJ614029 for ipoverib-archive@odin.ietf.org; Wed, 15 Jan 2003 17:16:19 -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 h0FMGJJ14026 for ; Wed, 15 Jan 2003 17:16:19 -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 RAA11401 for ; Wed, 15 Jan 2003 17:00:59 -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 h0FMFLJ13966; Wed, 15 Jan 2003 17:15: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 h0FMAkJ13729 for ; Wed, 15 Jan 2003 17:10:46 -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 QAA11228 for ; Wed, 15 Jan 2003 16:55:26 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08514 for ; Wed, 15 Jan 2003 14:58:48 -0700 (MST) 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 h0FLwlgE011605 for ; Wed, 15 Jan 2003 13:58:47 -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 <0H8R005K3ZPZW7@ha1sun-mail1.eng.sun.com> for ipoverib@ietf.org; Wed, 15 Jan 2003 13:58:47 -0800 (PST) Date: Wed, 15 Jan 2003 13:58:47 -0800 From: Kanoj Sarcar To: ipoverib@ietf.org Cc: Kanoj Sarcar Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E25D997.B4F5DAD3@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: <3E24C29C.A5F5D758@Sun.COM> <521y3fkv4e.fsf@topspin.com> <52of6ijp8q.fsf@topspin.com> Content-Transfer-Encoding: 7BIT Subject: [Ipoverib] IPoIB/aton question 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 Folks, While I have your attention, there is another issue I would like to get feedback on from implementors. On BSD, Linux, Solaris, AIX etc, there are a set of calls (maybe with minor variations): #include #include #include #include #include char *ether_ntoa(struct ether_addr *e); struct ether_addr *ether_aton(const char *asc); It seems to me that most systems that support IPoIB will need something like: #include char *link_ntoa(char *addr, int length, int type); unsigned char *link_aton(const char *asc, int &size); to handle network to ascii formatting and vice-versa. (Note: ether_line is not relevant since IPoIB link address is not persistent and can not be put into ethers databases; similar logic applies to ether_ntohost() and ether_hostton(); link_aton() also sounds quite optional to me). The "type" field in link_ntoa() is to force media specific formatting behavior; its value should identify the media type (or 0 for default behavior). Thus for Linux, ARPHRD_ETHER, ARPHRD_INFINIBAND etc would be possible values, whereas for Solaris and other DLPI based systems, it would be DL_ETHER etc. link_ntoa() should by default format the xx:yy:... (sized according to the length argument) string, but its formatting action can be altered depending on the type input (eg a compressed v6 format for IPoIB, if that is the way Linux should go). Are there any plans on these lines by IPoIB implementors on various systems? Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Thu Jan 16 08:10:05 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 IAA09171 for ; Thu, 16 Jan 2003 08:10:04 -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 h0GDNqJ20185; Thu, 16 Jan 2003 08:23:52 -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 h0GDMaJ20099 for ; Thu, 16 Jan 2003 08:22:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08914; Thu, 16 Jan 2003 08:06:59 -0500 (EST) Message-Id: <200301161306.IAA08914@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: Thu, 16 Jan 2003 08:06:58 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-subnet-mgmt-agent-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 : Definition of Managed Objects for the Infiniband Subnet Management Agent (SMA) Author(s) : B. Swortwood, S. Harnedy Filename : draft-ietf-ipoib-subnet-mgmt-agent-mib-04.txt Pages : 72 Date : 2003-1-15 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 Subnet Management Agents (SMA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-subnet-mgmt-agent-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-subnet-mgmt-agent-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-subnet-mgmt-agent-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-1-15125709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-subnet-mgmt-agent-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-subnet-mgmt-agent-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-15125709.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Thu Jan 16 08:10:05 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 IAA09181 for ; Thu, 16 Jan 2003 08:10:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GDPBM20309 for ipoverib-archive@odin.ietf.org; Thu, 16 Jan 2003 08:25:11 -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 h0GDPBJ20306 for ; Thu, 16 Jan 2003 08:25:11 -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 IAA09137 for ; Thu, 16 Jan 2003 08:09: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 h0GDNqJ20185; Thu, 16 Jan 2003 08:23:52 -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 h0GDMaJ20099 for ; Thu, 16 Jan 2003 08:22:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08914; Thu, 16 Jan 2003 08:06:59 -0500 (EST) Message-Id: <200301161306.IAA08914@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: Thu, 16 Jan 2003 08:06:58 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-subnet-mgmt-agent-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 : Definition of Managed Objects for the Infiniband Subnet Management Agent (SMA) Author(s) : B. Swortwood, S. Harnedy Filename : draft-ietf-ipoib-subnet-mgmt-agent-mib-04.txt Pages : 72 Date : 2003-1-15 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 Subnet Management Agents (SMA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-subnet-mgmt-agent-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-subnet-mgmt-agent-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-subnet-mgmt-agent-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-1-15125709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-subnet-mgmt-agent-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-subnet-mgmt-agent-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-15125709.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib