From ipoverib-admin@ietf.org Thu May 1 15:27: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 PAA02915 for ; Thu, 1 May 2003 15:27:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JWK818803; Thu, 1 May 2003 15:32:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JVl818425 for ; Thu, 1 May 2003 15:31:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02535; Thu, 1 May 2003 15:25:05 -0400 (EDT) Message-Id: <200305011925.PAA02535@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, 01 May 2003 15:25:05 -0400 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ip-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 : IP encapsulation and address resolution over InfiniBand networks Author(s) : V. Kashyap, J. Chu Filename : draft-ietf-ipoib-ip-over-infiniband-04.txt Pages : 15 Date : 2003-5-1 This document specifies the frame format for transmission of IP and ARP packets over InfiniBand networks. Unless explicitly specified, the term 'IP' refers to both IPv4 and IPv6. The term 'ARP' refers to all the ARP protocols/op-codes such as ARP/RARP. This document also describes the method of forming IPv6 link-local addresses, and the content of the source/target link layer address option used in Neighbour solicitation and advertisement, router advertisement, router redirect and router solicitation on IPv6 over InfiniBand. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-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-ip-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-ip-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-5-1153556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ip-over-infiniband-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ip-over-infiniband-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153556.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 May 1 15:27: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 PAA02926 for ; Thu, 1 May 2003 15:27:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41JXxV18915 for ipoverib-archive@odin.ietf.org; Thu, 1 May 2003 15:33:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JXw818911 for ; Thu, 1 May 2003 15:33:58 -0400 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 PAA02875 for ; Thu, 1 May 2003 15:27:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JWK818803; Thu, 1 May 2003 15:32:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JVl818425 for ; Thu, 1 May 2003 15:31:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02535; Thu, 1 May 2003 15:25:05 -0400 (EDT) Message-Id: <200305011925.PAA02535@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, 01 May 2003 15:25:05 -0400 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ip-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 : IP encapsulation and address resolution over InfiniBand networks Author(s) : V. Kashyap, J. Chu Filename : draft-ietf-ipoib-ip-over-infiniband-04.txt Pages : 15 Date : 2003-5-1 This document specifies the frame format for transmission of IP and ARP packets over InfiniBand networks. Unless explicitly specified, the term 'IP' refers to both IPv4 and IPv6. The term 'ARP' refers to all the ARP protocols/op-codes such as ARP/RARP. This document also describes the method of forming IPv6 link-local addresses, and the content of the source/target link layer address option used in Neighbour solicitation and advertisement, router advertisement, router redirect and router solicitation on IPv6 over InfiniBand. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-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-ip-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-ip-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-5-1153556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ip-over-infiniband-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ip-over-infiniband-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153556.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Fri May 2 10:53: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 KAA16930 for ; Fri, 2 May 2003 10:53:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42ExJ827892; Fri, 2 May 2003 10:59:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Ewm827842 for ; Fri, 2 May 2003 10:58:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16825 for ; Fri, 2 May 2003 10:51:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bbus-0004jL-00 for ipoverib@ietf.org; Fri, 02 May 2003 10:53:38 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 19Bbuc-0004ik-00 for ipoverib@ietf.org; Fri, 02 May 2003 10:53:22 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h42EqtuT266040 for ; Fri, 2 May 2003 10:52:55 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h42EqsgV088076 for ; Fri, 2 May 2003 08:52:54 -0600 To: ipoverib@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/02/2003 10:52:40 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/02/2003 10:52:40 AM, Serialize complete at 05/02/2003 10:52:40 AM, S/MIME Sign failed at 05/02/2003 10:52:40 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/02/2003 08:52:54, Serialize complete at 05/02/2003 08:52:54 Message-ID: Date: Fri, 2 May 2003 10:52:52 -0400 Content-Type: text/plain; charset="US-ASCII" Subject: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-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: , I've just started to look at IPoIB, so please forgive me if some of the comments below have been discussed previously. I did try to read through the mailing list archive, but may have missed some of the relevant posts. - The draft contains a reference to draft-ietf-ipoib-architecture-01.txt. This is an expired draft which hasn't been updated in almost 18 months. Should this reference be deleted, or is referenced draft updated and published as an RFC? - In Section 9.0, am I correct in assuming that all routers MUST join the all-routers multicast group if it exists? And, if one does not exist, shouldn't the router create the group when it first connects to the IB subnet as a "FullMember"? This section also makes it sound as though the IB administrator must create the all-router multicast group, which doesn't seem to be necessary. And it doesn't describe if/when/how a router is expected to join the all-router multicast group. - Section 9.0 indicates that "The packet SHOULD be forwarded to locally connected routers. [snip] The specific mechanism for a sender to forward packets to routers are left to implementations". At a minimum, I think the exact implementation needs to be specified. The text suggests using all-router multicast group or the broadcast group. If a router is required to create the all-router multicast group (see the previous comment), then wouldn't it be sufficient to check for the existence of the all-router multicast group and, if it exists, send to that? If it doesn't exist, then there can't be any multicast routers on the link, and since there aren't any local listeners there are no on-link listeners there isn't any need to send the packet. And shouldn't the IPoIB sender subscribe to the IB multicast group creation events using a wildcard MGID so that it can "SendOnlyNonMember" join the group if a listener appears on the local IB subnet, or "SendOnlyNonMember" join the all-routers group if a router appears on-link and creates the all-routers multicast group? And doesn't it need to subscribe to the IB multicast group deletion events so that it knows when to switch back to sending to the all-router multicast group and/or stop sending? But I'm wondering why a node needs to do this at all. Wouldn't it make more sense for the IPoIB node instead create the multicast group and join the group so that IPoIB multicast routers can join the group? Yes, the IPoIB sender will need create the group as a "FullMember", but this seems to provide a simpler mapping of IP multicast to IB multicast. - Section 9.0 also indicates that "A multicast sender must join the target multicast group as a "SendOnlyNonMember" before outgoing messages from it can be successfully routed." This text should be clarified to indicate this is only true if the node has not already joined the group as either a "FullMember" or "SendOnlyNonMember". The If-Then-Else logic below correctly shows this behavior, but this paragraph does not reflect that behavior. - Section 9.0 states that the MGID cache may need to be validated periodically. I think it would be useful to indicate why this might be necessary, how a node should go about doing so, and what action should be taken if the MGID is found to be invalid. I'm assuming that this would be done by checking with the SA on the outbound link for a "MCMemberRecord" that matches the MGID and, if not found, creating the multicast group and rejoining. - Section 9.0 indicates that "For the rest of attributes, it is recommended the same values from the all-node multicast/broadcast group be used." Should this instead say "For the rest of the attributes, the same values from the all-node multicast/broadcast group SHOULD be used." Regardless of the wording, this text seems to contradict the Section 7.0 which states a node must "use the rest of the link attributes associated with the group for all future communication on the link. If Section 7.0 is correct, should this be a MUST instead of a SHOULD? And, if not, under what circumstances would a node choose to not use the same values? Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Fri May 2 10:53: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 KAA16944 for ; Fri, 2 May 2003 10:53:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42F0I827994 for ipoverib-archive@odin.ietf.org; Fri, 2 May 2003 11:00:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42F0I827991 for ; Fri, 2 May 2003 11:00:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16918 for ; Fri, 2 May 2003 10:53:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BbwZ-0004kP-00 for ipoverib-web-archive@ietf.org; Fri, 02 May 2003 10:55:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BbwZ-0004kJ-00 for ipoverib-web-archive@ietf.org; Fri, 02 May 2003 10:55:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42ExJ827892; Fri, 2 May 2003 10:59:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Ewm827842 for ; Fri, 2 May 2003 10:58:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16825 for ; Fri, 2 May 2003 10:51:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bbus-0004jL-00 for ipoverib@ietf.org; Fri, 02 May 2003 10:53:38 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 19Bbuc-0004ik-00 for ipoverib@ietf.org; Fri, 02 May 2003 10:53:22 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h42EqtuT266040 for ; Fri, 2 May 2003 10:52:55 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h42EqsgV088076 for ; Fri, 2 May 2003 08:52:54 -0600 To: ipoverib@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/02/2003 10:52:40 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/02/2003 10:52:40 AM, Serialize complete at 05/02/2003 10:52:40 AM, S/MIME Sign failed at 05/02/2003 10:52:40 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/02/2003 08:52:54, Serialize complete at 05/02/2003 08:52:54 Message-ID: Date: Fri, 2 May 2003 10:52:52 -0400 Content-Type: text/plain; charset="US-ASCII" Subject: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-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: , I've just started to look at IPoIB, so please forgive me if some of the comments below have been discussed previously. I did try to read through the mailing list archive, but may have missed some of the relevant posts. - The draft contains a reference to draft-ietf-ipoib-architecture-01.txt. This is an expired draft which hasn't been updated in almost 18 months. Should this reference be deleted, or is referenced draft updated and published as an RFC? - In Section 9.0, am I correct in assuming that all routers MUST join the all-routers multicast group if it exists? And, if one does not exist, shouldn't the router create the group when it first connects to the IB subnet as a "FullMember"? This section also makes it sound as though the IB administrator must create the all-router multicast group, which doesn't seem to be necessary. And it doesn't describe if/when/how a router is expected to join the all-router multicast group. - Section 9.0 indicates that "The packet SHOULD be forwarded to locally connected routers. [snip] The specific mechanism for a sender to forward packets to routers are left to implementations". At a minimum, I think the exact implementation needs to be specified. The text suggests using all-router multicast group or the broadcast group. If a router is required to create the all-router multicast group (see the previous comment), then wouldn't it be sufficient to check for the existence of the all-router multicast group and, if it exists, send to that? If it doesn't exist, then there can't be any multicast routers on the link, and since there aren't any local listeners there are no on-link listeners there isn't any need to send the packet. And shouldn't the IPoIB sender subscribe to the IB multicast group creation events using a wildcard MGID so that it can "SendOnlyNonMember" join the group if a listener appears on the local IB subnet, or "SendOnlyNonMember" join the all-routers group if a router appears on-link and creates the all-routers multicast group? And doesn't it need to subscribe to the IB multicast group deletion events so that it knows when to switch back to sending to the all-router multicast group and/or stop sending? But I'm wondering why a node needs to do this at all. Wouldn't it make more sense for the IPoIB node instead create the multicast group and join the group so that IPoIB multicast routers can join the group? Yes, the IPoIB sender will need create the group as a "FullMember", but this seems to provide a simpler mapping of IP multicast to IB multicast. - Section 9.0 also indicates that "A multicast sender must join the target multicast group as a "SendOnlyNonMember" before outgoing messages from it can be successfully routed." This text should be clarified to indicate this is only true if the node has not already joined the group as either a "FullMember" or "SendOnlyNonMember". The If-Then-Else logic below correctly shows this behavior, but this paragraph does not reflect that behavior. - Section 9.0 states that the MGID cache may need to be validated periodically. I think it would be useful to indicate why this might be necessary, how a node should go about doing so, and what action should be taken if the MGID is found to be invalid. I'm assuming that this would be done by checking with the SA on the outbound link for a "MCMemberRecord" that matches the MGID and, if not found, creating the multicast group and rejoining. - Section 9.0 indicates that "For the rest of attributes, it is recommended the same values from the all-node multicast/broadcast group be used." Should this instead say "For the rest of the attributes, the same values from the all-node multicast/broadcast group SHOULD be used." Regardless of the wording, this text seems to contradict the Section 7.0 which states a node must "use the rest of the link attributes associated with the group for all future communication on the link. If Section 7.0 is correct, should this be a MUST instead of a SHOULD? And, if not, under what circumstances would a node choose to not use the same values? Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Fri May 2 10:54:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16998 for ; Fri, 2 May 2003 10:54:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42F02827960; Fri, 2 May 2003 11:00:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Ex3827875 for ; Fri, 2 May 2003 10:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16848 for ; Fri, 2 May 2003 10:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BbvM-0004jQ-00 for ipoverib@ietf.org; Fri, 02 May 2003 10:54:08 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19Bbv6-0004il-00 for ipoverib@ietf.org; Fri, 02 May 2003 10:53:52 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h42ErGYp223310 for ; Fri, 2 May 2003 10:53:16 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h42ErFgV139570 for ; Fri, 2 May 2003 08:53:16 -0600 To: ipoverib@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/02/2003 10:53:01 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/02/2003 10:53:01 AM, Serialize complete at 05/02/2003 10:53:01 AM, S/MIME Sign failed at 05/02/2003 10:53:01 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/02/2003 08:53:15, Serialize complete at 05/02/2003 08:53:15 Message-ID: Date: Fri, 2 May 2003 10:53:12 -0400 Content-Type: text/plain; charset="US-ASCII" Subject: [Ipoverib] Comments on draft-ietf-ip-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: , As with my comments on draft-ietf-ipoib-link-multicast-04.txt, I've just started to look at IPoIB, so please forgive me if some of the comments below have been discussed previously. - I've seen this discussed previously, but wouldn't it make sense to combine this draft with draft-ietf-ipoib-link-multicast-04.txt? You can't implement one without the other, and each draft only seems to have about 5-10 pages of unique text. - The draft contains a reference to draft-ietf-ipoib-architecture-02.txt. I've been unable to find a copy of this draft, either current or in an internet draft archive. draft-ietf-ipoib-architecture-01.txt is an expired draft which hasn't been updated in almost 18 months. Should this reference be deleted, or is referenced draft updated and published as an RFC? - Section 4.0 covers the setting of the IBoIB MTU. But I'm wondering why this is even discussed within this document at all. Isn't it already covered in "IP link and multicast over InfiniBand networks" draft, which seems to be the better place for this information? I actually prefer the text within this section over that in the "link and multicast" draft - maybe this section should be deleted and this text can replace that in the other draft. - Section 5.0 seems to require that the interface identifier be selected either from the GUID or, if the IPoIB subnet is contained within an IB subnet, from the LID. I don't believe is the intent, as there are quite a few other ways that an interface identifier may be generated - as per RFC 3041, via manual configuration, or some other algorithm as deemed necessary by the IPoIB node. I would prefer to see the text indicate that the GUID SHOULD be used if privacy is not a concern, but other mechanisms may be used as deemed appropriate. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Fri May 2 10:54: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 KAA17016 for ; Fri, 2 May 2003 10:54:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42F0ve28045 for ipoverib-archive@odin.ietf.org; Fri, 2 May 2003 11:00:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42F0u828042 for ; Fri, 2 May 2003 11:00:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16963 for ; Fri, 2 May 2003 10:53:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BbxC-0004kc-00 for ipoverib-web-archive@ietf.org; Fri, 02 May 2003 10:56:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BbxB-0004kW-00 for ipoverib-web-archive@ietf.org; Fri, 02 May 2003 10:56:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42F02827960; Fri, 2 May 2003 11:00:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Ex3827875 for ; Fri, 2 May 2003 10:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16848 for ; Fri, 2 May 2003 10:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BbvM-0004jQ-00 for ipoverib@ietf.org; Fri, 02 May 2003 10:54:08 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19Bbv6-0004il-00 for ipoverib@ietf.org; Fri, 02 May 2003 10:53:52 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h42ErGYp223310 for ; Fri, 2 May 2003 10:53:16 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h42ErFgV139570 for ; Fri, 2 May 2003 08:53:16 -0600 To: ipoverib@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/02/2003 10:53:01 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/02/2003 10:53:01 AM, Serialize complete at 05/02/2003 10:53:01 AM, S/MIME Sign failed at 05/02/2003 10:53:01 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/02/2003 08:53:15, Serialize complete at 05/02/2003 08:53:15 Message-ID: Date: Fri, 2 May 2003 10:53:12 -0400 Content-Type: text/plain; charset="US-ASCII" Subject: [Ipoverib] Comments on draft-ietf-ip-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: , As with my comments on draft-ietf-ipoib-link-multicast-04.txt, I've just started to look at IPoIB, so please forgive me if some of the comments below have been discussed previously. - I've seen this discussed previously, but wouldn't it make sense to combine this draft with draft-ietf-ipoib-link-multicast-04.txt? You can't implement one without the other, and each draft only seems to have about 5-10 pages of unique text. - The draft contains a reference to draft-ietf-ipoib-architecture-02.txt. I've been unable to find a copy of this draft, either current or in an internet draft archive. draft-ietf-ipoib-architecture-01.txt is an expired draft which hasn't been updated in almost 18 months. Should this reference be deleted, or is referenced draft updated and published as an RFC? - Section 4.0 covers the setting of the IBoIB MTU. But I'm wondering why this is even discussed within this document at all. Isn't it already covered in "IP link and multicast over InfiniBand networks" draft, which seems to be the better place for this information? I actually prefer the text within this section over that in the "link and multicast" draft - maybe this section should be deleted and this text can replace that in the other draft. - Section 5.0 seems to require that the interface identifier be selected either from the GUID or, if the IPoIB subnet is contained within an IB subnet, from the LID. I don't believe is the intent, as there are quite a few other ways that an interface identifier may be generated - as per RFC 3041, via manual configuration, or some other algorithm as deemed necessary by the IPoIB node. I would prefer to see the text indicate that the GUID SHOULD be used if privacy is not a concern, but other mechanisms may be used as deemed appropriate. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon May 5 04:20:27 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 EAA26802 for ; Mon, 5 May 2003 04:20:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h458R3813768; Mon, 5 May 2003 04:27:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h458OT813658 for ; Mon, 5 May 2003 04:24:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26748 for ; Mon, 5 May 2003 04:15:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CbAb-0004Tl-00 for ipoverib@ietf.org; Mon, 05 May 2003 04:17:57 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 19CbAK-0004Tb-00 for ipoverib@ietf.org; Mon, 05 May 2003 04:17:41 -0400 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h458HGXD091288 for ; Mon, 5 May 2003 04:17:16 -0400 Received: from w-vkashyap95.des.sequent.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h458HDNr059350; Mon, 5 May 2003 02:17:14 -0600 Date: Mon, 5 May 2003 00:27:16 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Roy Brabson cc: ipoverib@ietf.org Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt In-Reply-To: Message-ID: X-Warning: UNAuthenticated Sender MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , On Fri, 2 May 2003, Roy Brabson wrote: > I've just started to look at IPoIB, so please forgive me if some of the > comments below have been discussed previously. I did try to read through > the mailing list archive, but may have missed some of the relevant posts. > > - The draft contains a reference to draft-ietf-ipoib-architecture-01.txt. > This is an expired draft which hasn't been updated in almost 18 months. > Should this reference be deleted, or is referenced draft updated and > published as an RFC? My delay - I had hoped to publish the -02.txt along with the encapsulation draft -04.txt but couldn't. Will publish by 8th. > > - In Section 9.0, am I correct in assuming that all routers MUST join the > all-routers multicast group if it exists? And, if one does not exist, > shouldn't the router create the group when it first connects to the IB > subnet as a "FullMember"? This section also makes it sound as though > the IB administrator must create the all-router multicast group, which > doesn't seem to be necessary. And it doesn't describe if/when/how a > router is expected to join the all-router multicast group. Any IPoIB host/router is required to join the Broadcast-GID. That is how the subnet is setup. This GID is derived from the all 1's address in the case of IPv4; and the all-nodes address in the case of IPv6. The IP layer requires( v6- RFC1884; v4 - IGMPv2 RFC2236) that the multicast routers always be ready to accept packets received on the all-routers IP multicast address. Therefore the corresponding all-routers IB MGID must be "FullMember" joined by the router. The creation of the all-router IB group therefore is implicit in the IP router listening on the all-router IP multicast address. The administrator doesn't need to create it explicitly. > > - Section 9.0 indicates that "The packet SHOULD be forwarded to locally > connected routers. [snip] The specific mechanism for a sender to > forward packets to routers are left to implementations". At a > minimum, I think the exact implementation needs to be specified. The > text suggests using all-router multicast group or the broadcast group. > If a router is required to create the all-router multicast group (see > the previous comment), then wouldn't it be sufficient to check for the > existence of the all-router multicast group and, if it exists, send to > that? If it doesn't exist, then there can't be any multicast routers > on the link, and since there aren't any local listeners there are no > on-link listeners there isn't any need to send the packet. Yes, if the all-routers MGID doesn't exist and there are no receivers on the subnet there is no need to send the packet. > > And shouldn't the IPoIB sender subscribe to the IB multicast group > creation events using a wildcard MGID so that it can > "SendOnlyNonMember" join the group if a listener appears on the local > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > router appears on-link and creates the all-routers multicast group? > And doesn't it need to subscribe to the IB multicast group deletion > events so that it knows when to switch back to sending to the > all-router multicast group and/or stop sending? An IP application may send the multicast packet to any group. One could request that the interface be notified of every MGID creation/deletion but the application(s) might never send any data to those groups. Therefore, the wildcard report request is something that the implementation will have to weigh against usage. The choice is upto the implementor. It does seem like a reasonable thing to request creation/deletion report on the all-router multicast GID. > > But I'm wondering why a node needs to do this at all. Wouldn't it > make more sense for the IPoIB node instead create the multicast group > and join the group so that IPoIB multicast routers can join the group? > Yes, the IPoIB sender will need create the group as a "FullMember", > but this seems to provide a simpler mapping of IP multicast to IB > multicast. It will work but how is this a better thing to do ? I also do not think that such behaviour can/should be disallowed. Will go over the rest and answer later. Vivek > > - Section 9.0 also indicates that "A multicast sender must join the > target multicast group as a "SendOnlyNonMember" before outgoing > messages from it can be successfully routed." This text should be > clarified to indicate this is only true if the node has not already > joined the group as either a "FullMember" or "SendOnlyNonMember". The > If-Then-Else logic below correctly shows this behavior, but this > paragraph does not reflect that behavior. > > - Section 9.0 states that the MGID cache may need to be validated > periodically. I think it would be useful to indicate why this might > be necessary, how a node should go about doing so, and what action > should be taken if the MGID is found to be invalid. I'm assuming that > this would be done by checking with the SA on the outbound link for a > "MCMemberRecord" that matches the MGID and, if not found, creating the > multicast group and rejoining. > > - Section 9.0 indicates that "For the rest of attributes, it is > recommended the same values from the all-node multicast/broadcast > group be used." Should this instead say "For the rest of the > attributes, the same values from the all-node multicast/broadcast > group SHOULD be used." Regardless of the wording, this text seems to > contradict the Section 7.0 which states a node must "use the rest of > the link attributes associated with the group for all future > communication on the link. If Section 7.0 is correct, should this be > a MUST instead of a SHOULD? And, if not, under what circumstances > would a node choose to not use the same values? > > Roy > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon May 5 04:20:28 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 EAA26816 for ; Mon, 5 May 2003 04:20:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h458SMq13794 for ipoverib-archive@odin.ietf.org; Mon, 5 May 2003 04:28:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h458SM813791 for ; Mon, 5 May 2003 04:28:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26797 for ; Mon, 5 May 2003 04:19:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CbEa-0004UK-00 for ipoverib-web-archive@ietf.org; Mon, 05 May 2003 04:22:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CbEZ-0004UG-00 for ipoverib-web-archive@ietf.org; Mon, 05 May 2003 04:22:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h458R3813768; Mon, 5 May 2003 04:27:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h458OT813658 for ; Mon, 5 May 2003 04:24:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26748 for ; Mon, 5 May 2003 04:15:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CbAb-0004Tl-00 for ipoverib@ietf.org; Mon, 05 May 2003 04:17:57 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 19CbAK-0004Tb-00 for ipoverib@ietf.org; Mon, 05 May 2003 04:17:41 -0400 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h458HGXD091288 for ; Mon, 5 May 2003 04:17:16 -0400 Received: from w-vkashyap95.des.sequent.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h458HDNr059350; Mon, 5 May 2003 02:17:14 -0600 Date: Mon, 5 May 2003 00:27:16 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Roy Brabson cc: ipoverib@ietf.org Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt In-Reply-To: Message-ID: X-Warning: UNAuthenticated Sender MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , On Fri, 2 May 2003, Roy Brabson wrote: > I've just started to look at IPoIB, so please forgive me if some of the > comments below have been discussed previously. I did try to read through > the mailing list archive, but may have missed some of the relevant posts. > > - The draft contains a reference to draft-ietf-ipoib-architecture-01.txt. > This is an expired draft which hasn't been updated in almost 18 months. > Should this reference be deleted, or is referenced draft updated and > published as an RFC? My delay - I had hoped to publish the -02.txt along with the encapsulation draft -04.txt but couldn't. Will publish by 8th. > > - In Section 9.0, am I correct in assuming that all routers MUST join the > all-routers multicast group if it exists? And, if one does not exist, > shouldn't the router create the group when it first connects to the IB > subnet as a "FullMember"? This section also makes it sound as though > the IB administrator must create the all-router multicast group, which > doesn't seem to be necessary. And it doesn't describe if/when/how a > router is expected to join the all-router multicast group. Any IPoIB host/router is required to join the Broadcast-GID. That is how the subnet is setup. This GID is derived from the all 1's address in the case of IPv4; and the all-nodes address in the case of IPv6. The IP layer requires( v6- RFC1884; v4 - IGMPv2 RFC2236) that the multicast routers always be ready to accept packets received on the all-routers IP multicast address. Therefore the corresponding all-routers IB MGID must be "FullMember" joined by the router. The creation of the all-router IB group therefore is implicit in the IP router listening on the all-router IP multicast address. The administrator doesn't need to create it explicitly. > > - Section 9.0 indicates that "The packet SHOULD be forwarded to locally > connected routers. [snip] The specific mechanism for a sender to > forward packets to routers are left to implementations". At a > minimum, I think the exact implementation needs to be specified. The > text suggests using all-router multicast group or the broadcast group. > If a router is required to create the all-router multicast group (see > the previous comment), then wouldn't it be sufficient to check for the > existence of the all-router multicast group and, if it exists, send to > that? If it doesn't exist, then there can't be any multicast routers > on the link, and since there aren't any local listeners there are no > on-link listeners there isn't any need to send the packet. Yes, if the all-routers MGID doesn't exist and there are no receivers on the subnet there is no need to send the packet. > > And shouldn't the IPoIB sender subscribe to the IB multicast group > creation events using a wildcard MGID so that it can > "SendOnlyNonMember" join the group if a listener appears on the local > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > router appears on-link and creates the all-routers multicast group? > And doesn't it need to subscribe to the IB multicast group deletion > events so that it knows when to switch back to sending to the > all-router multicast group and/or stop sending? An IP application may send the multicast packet to any group. One could request that the interface be notified of every MGID creation/deletion but the application(s) might never send any data to those groups. Therefore, the wildcard report request is something that the implementation will have to weigh against usage. The choice is upto the implementor. It does seem like a reasonable thing to request creation/deletion report on the all-router multicast GID. > > But I'm wondering why a node needs to do this at all. Wouldn't it > make more sense for the IPoIB node instead create the multicast group > and join the group so that IPoIB multicast routers can join the group? > Yes, the IPoIB sender will need create the group as a "FullMember", > but this seems to provide a simpler mapping of IP multicast to IB > multicast. It will work but how is this a better thing to do ? I also do not think that such behaviour can/should be disallowed. Will go over the rest and answer later. Vivek > > - Section 9.0 also indicates that "A multicast sender must join the > target multicast group as a "SendOnlyNonMember" before outgoing > messages from it can be successfully routed." This text should be > clarified to indicate this is only true if the node has not already > joined the group as either a "FullMember" or "SendOnlyNonMember". The > If-Then-Else logic below correctly shows this behavior, but this > paragraph does not reflect that behavior. > > - Section 9.0 states that the MGID cache may need to be validated > periodically. I think it would be useful to indicate why this might > be necessary, how a node should go about doing so, and what action > should be taken if the MGID is found to be invalid. I'm assuming that > this would be done by checking with the SA on the outbound link for a > "MCMemberRecord" that matches the MGID and, if not found, creating the > multicast group and rejoining. > > - Section 9.0 indicates that "For the rest of attributes, it is > recommended the same values from the all-node multicast/broadcast > group be used." Should this instead say "For the rest of the > attributes, the same values from the all-node multicast/broadcast > group SHOULD be used." Regardless of the wording, this text seems to > contradict the Section 7.0 which states a node must "use the rest of > the link attributes associated with the group for all future > communication on the link. If Section 7.0 is correct, should this be > a MUST instead of a SHOULD? And, if not, under what circumstances > would a node choose to not use the same values? > > Roy > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon May 5 11:05:03 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 LAA04956 for ; Mon, 5 May 2003 11:05:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45FBt808851; Mon, 5 May 2003 11:11:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45FAN808789 for ; Mon, 5 May 2003 11:10:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04890 for ; Mon, 5 May 2003 11:01:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ChVV-0006MX-00 for ipoverib@ietf.org; Mon, 05 May 2003 11:03:57 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 19ChVF-0006MC-00 for ipoverib@ietf.org; Mon, 05 May 2003 11:03:41 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h45F2JXD192130 for ; Mon, 5 May 2003 11:02:19 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h45F2JV3027438; Mon, 5 May 2003 09:02:19 -0600 In-Reply-To: To: kashyapv@us.ibm.com Cc: ipoverib@ietf.org Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/05/2003 11:00:35 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/05/2003 11:00:35 AM, Serialize complete at 05/05/2003 11:00:35 AM, S/MIME Sign failed at 05/05/2003 11:00:35 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/05/2003 09:02:19, Serialize complete at 05/05/2003 09:02:19 Message-ID: Date: Mon, 5 May 2003 11:00:49 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > creation events using a wildcard MGID so that it can > > "SendOnlyNonMember" join the group if a listener appears on the local > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > router appears on-link and creates the all-routers multicast group? > > And doesn't it need to subscribe to the IB multicast group deletion > > events so that it knows when to switch back to sending to the > > all-router multicast group and/or stop sending? > > An IP application may send the multicast packet to any group. One could > request that the interface be notified of every MGID creation/deletion but the > application(s) might never send any data to those groups. Therefore, > the wildcard report request is something that the implementation will > have to weigh against usage. The choice is upto the implementor. This wasn't clear to me from reading the spec. Let me see if I have this straight: - A listener MUST perform a "FullMember" join for the MGID of the multicast group - A listener MUST be able to receive an IP multicast packet over either the broadcast GID or the MGID for the multicast group - A router MUST be able to receive an IP multicast packet over either the MGID, all-router MGID, or broadcast GID - If there is an on-link listener, a sender may send the packet using either the MGID or to the broadcast GID - If there is not an on-link listener, a sender may send the packet to either the broadcast GID or the all-router MGID Is that correct? And, if a sender wants to send packets using the MGID, it will need to listen for MGID creation/deletion reports so that it can switch between the MGID and the all-router MGID (or broadcast GID, I suppose) as on-link listeners join/leave the group. I do have to wonder whether having such a large number of optional mechanisms to handle the mapping of IP to IB multicasting is really a good idea. Would we be better off just selecting one approach and saying all IPoIB nodes should take that approach? > > It does seem like a reasonable thing to request creation/deletion > report on the all-router multicast GID. > > > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > make more sense for the IPoIB node instead create the multicast group > > and join the group so that IPoIB multicast routers can join the group? > > Yes, the IPoIB sender will need create the group as a "FullMember", > > but this seems to provide a simpler mapping of IP multicast to IB > > multicast. > > It will work but how is this a better thing to do ? I also > do not think that such behavior can/should be disallowed. I'm just trying to understand if there is some way to simplify the mapping of IP multicast groups to IB multicast groups. My main concern is with listening for IB group creation/deletion reports so a sender can tell if/when to use the multicast group's MGID and when to use the all-router MGID. If the sender performs a "FullMember" join, then it will always send using the MGID for the corresponding IB multicast group. But, based on what you said above, a sender can always use the broadcast GID when sending to a multicast group for which it is not also listening. This does simplify the logic, but at the cost of forcing every IPoIB node to filter the IP multicast packets for which they are not interested. Then again, it saves the SM from having to reprogram the switches/routers in the IB fabric when the sender performs a non-member join. To be honest, I have no idea how to go about making a rational choice on which approach will yield the better results. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon May 5 11:05: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 LAA04970 for ; Mon, 5 May 2003 11:05:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45FD7W08942 for ipoverib-archive@odin.ietf.org; Mon, 5 May 2003 11:13:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45FD7808939 for ; Mon, 5 May 2003 11:13:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04953 for ; Mon, 5 May 2003 11:04:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ChY8-0006OE-00 for ipoverib-web-archive@ietf.org; Mon, 05 May 2003 11:06:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ChY8-0006O7-00 for ipoverib-web-archive@ietf.org; Mon, 05 May 2003 11:06:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45FBt808851; Mon, 5 May 2003 11:11:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45FAN808789 for ; Mon, 5 May 2003 11:10:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04890 for ; Mon, 5 May 2003 11:01:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ChVV-0006MX-00 for ipoverib@ietf.org; Mon, 05 May 2003 11:03:57 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 19ChVF-0006MC-00 for ipoverib@ietf.org; Mon, 05 May 2003 11:03:41 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h45F2JXD192130 for ; Mon, 5 May 2003 11:02:19 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h45F2JV3027438; Mon, 5 May 2003 09:02:19 -0600 In-Reply-To: To: kashyapv@us.ibm.com Cc: ipoverib@ietf.org Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/05/2003 11:00:35 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/05/2003 11:00:35 AM, Serialize complete at 05/05/2003 11:00:35 AM, S/MIME Sign failed at 05/05/2003 11:00:35 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/05/2003 09:02:19, Serialize complete at 05/05/2003 09:02:19 Message-ID: Date: Mon, 5 May 2003 11:00:49 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > creation events using a wildcard MGID so that it can > > "SendOnlyNonMember" join the group if a listener appears on the local > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > router appears on-link and creates the all-routers multicast group? > > And doesn't it need to subscribe to the IB multicast group deletion > > events so that it knows when to switch back to sending to the > > all-router multicast group and/or stop sending? > > An IP application may send the multicast packet to any group. One could > request that the interface be notified of every MGID creation/deletion but the > application(s) might never send any data to those groups. Therefore, > the wildcard report request is something that the implementation will > have to weigh against usage. The choice is upto the implementor. This wasn't clear to me from reading the spec. Let me see if I have this straight: - A listener MUST perform a "FullMember" join for the MGID of the multicast group - A listener MUST be able to receive an IP multicast packet over either the broadcast GID or the MGID for the multicast group - A router MUST be able to receive an IP multicast packet over either the MGID, all-router MGID, or broadcast GID - If there is an on-link listener, a sender may send the packet using either the MGID or to the broadcast GID - If there is not an on-link listener, a sender may send the packet to either the broadcast GID or the all-router MGID Is that correct? And, if a sender wants to send packets using the MGID, it will need to listen for MGID creation/deletion reports so that it can switch between the MGID and the all-router MGID (or broadcast GID, I suppose) as on-link listeners join/leave the group. I do have to wonder whether having such a large number of optional mechanisms to handle the mapping of IP to IB multicasting is really a good idea. Would we be better off just selecting one approach and saying all IPoIB nodes should take that approach? > > It does seem like a reasonable thing to request creation/deletion > report on the all-router multicast GID. > > > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > make more sense for the IPoIB node instead create the multicast group > > and join the group so that IPoIB multicast routers can join the group? > > Yes, the IPoIB sender will need create the group as a "FullMember", > > but this seems to provide a simpler mapping of IP multicast to IB > > multicast. > > It will work but how is this a better thing to do ? I also > do not think that such behavior can/should be disallowed. I'm just trying to understand if there is some way to simplify the mapping of IP multicast groups to IB multicast groups. My main concern is with listening for IB group creation/deletion reports so a sender can tell if/when to use the multicast group's MGID and when to use the all-router MGID. If the sender performs a "FullMember" join, then it will always send using the MGID for the corresponding IB multicast group. But, based on what you said above, a sender can always use the broadcast GID when sending to a multicast group for which it is not also listening. This does simplify the logic, but at the cost of forcing every IPoIB node to filter the IP multicast packets for which they are not interested. Then again, it saves the SM from having to reprogram the switches/routers in the IB fabric when the sender performs a non-member join. To be honest, I have no idea how to go about making a rational choice on which approach will yield the better results. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon May 5 23:51:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25933 for ; Mon, 5 May 2003 23:51:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h463xC829910; Mon, 5 May 2003 23:59:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h463vl829856 for ; Mon, 5 May 2003 23:57:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25854 for ; Mon, 5 May 2003 23:48:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CtTe-0002vn-00 for ipoverib@ietf.org; Mon, 05 May 2003 23:50:50 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19CtTY-0002ve-00 for ipoverib@ietf.org; Mon, 05 May 2003 23:50:44 -0400 Received: from jurassic.eng.sun.com ([129.146.88.31]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id UAA00445; Mon, 5 May 2003 20:50:36 -0700 (PDT) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h463oaKQ279973; Mon, 5 May 2003 20:50:36 -0700 (PDT) Message-Id: <200305060350.h463oaKQ279973@jurassic.eng.sun.com> Date: Mon, 5 May 2003 20:50:35 -0700 (PDT) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: rbrabson@us.ibm.com Cc: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GpdF55GDgA3BT45m/VGc3g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc 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: , Roy, >To: ipoverib@ietf.org >MIME-Version: 1.0 >From: Roy Brabson > >I've just started to look at IPoIB, so please forgive me if some of the >comments below have been discussed previously. I did try to read through >the mailing list archive, but may have missed some of the relevant posts. > >- The draft contains a reference to draft-ietf-ipoib-architecture-01.txt. > This is an expired draft which hasn't been updated in almost 18 months. > Should this reference be deleted, or is referenced draft updated and > published as an RFC? > >- In Section 9.0, am I correct in assuming that all routers MUST join the > all-routers multicast group if it exists? Yes, but this is not a new requirement imposed by IPoIB, but rather an existing requirement from the IP layer. > And, if one does not exist, > shouldn't the router create the group when it first connects to the IB > subnet as a "FullMember"? This section also makes it sound as though > the IB administrator must create the all-router multicast group, which > doesn't seem to be necessary. You are right. In prior versions of the draft the all-router mulitcast group played a more prominent role. Now it looks like the all-router MC group can be treated just like many other multicast groups, and gets created by demand when a router joins. I'll change the "SHOULD" to "may" regarding the creation of the all- router multicast group in the paragraph before section 8.0. > And it doesn't describe if/when/how a > router is expected to join the all-router multicast group. Isn't this determined by the IP software independent of IPoIB? > >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > connected routers. [snip] The specific mechanism for a sender to > forward packets to routers are left to implementations". At a > minimum, I think the exact implementation needs to be specified. Why? (The draft strives to avoid dictating implementation details that do not affect interoperability.) > The > text suggests using all-router multicast group or the broadcast group. > If a router is required to create the all-router multicast group (see > the previous comment), then wouldn't it be sufficient to check for the > existence of the all-router multicast group and, if it exists, send to > that? If it doesn't exist, then there can't be any multicast routers > on the link, and since there aren't any local listeners there are no > on-link listeners there isn't any need to send the packet. Don't the code sinppet following 9.B match pretty much what you described above? > > And shouldn't the IPoIB sender subscribe to the IB multicast group > creation events using a wildcard MGID so that it can > "SendOnlyNonMember" join the group if a listener appears on the local > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > router appears on-link and creates the all-routers multicast group? > And doesn't it need to subscribe to the IB multicast group deletion > events so that it knows when to switch back to sending to the > all-router multicast group and/or stop sending? Aren't you saying the same thing (more or less) as what is described in the section following the code snippet? > > But I'm wondering why a node needs to do this at all. Wouldn't it > make more sense for the IPoIB node instead create the multicast group > and join the group so that IPoIB multicast routers can join the group? > Yes, the IPoIB sender will need create the group as a "FullMember", > but this seems to provide a simpler mapping of IP multicast to IB > multicast. While what you suggested may simplify the procedure, it essentially removes the difference between a multicast sender and a multicast receiver, which is wrong. In the IP multicast model a multicast sender doesn't need to be a member of a multicast group to send. The draft has tried to keep the same distinction. > >- Section 9.0 also indicates that "A multicast sender must join the > target multicast group as a "SendOnlyNonMember" before outgoing > messages from it can be successfully routed." This text should be > clarified to indicate this is only true if the node has not already > joined the group as either a "FullMember" or "SendOnlyNonMember". The > If-Then-Else logic below correctly shows this behavior, but this > paragraph does not reflect that behavior. Although your comment is correct, I'd argue this kind of details can be found in the IBA spec. It has nothing to do with IPoIB in particular, So the question becomes how much IBA info we need to repeat in an IPoIB RFC. Since the code sippet already covers this correctly, if you still believe this needs to be clarified i can certain add more text to it. > >- Section 9.0 states that the MGID cache may need to be validated > periodically. I think it would be useful to indicate why this might > be necessary, how a node should go about doing so, and what action > should be taken if the MGID is found to be invalid. I'm assuming that > this would be done by checking with the SA on the outbound link for a > "MCMemberRecord" that matches the MGID and, if not found, creating the > multicast group and rejoining. Good catch. The text comes from the old drafts before the MC group creation/deletion traps were invented. Now with the trap support the periodic cache flush is not needed anymore. > >- Section 9.0 indicates that "For the rest of attributes, it is > recommended the same values from the all-node multicast/broadcast > group be used." Should this instead say "For the rest of the > attributes, the same values from the all-node multicast/broadcast > group SHOULD be used." Regardless of the wording, this text seems to > contradict the Section 7.0 which states a node must "use the rest of > the link attributes associated with the group for all future > communication on the link. If Section 7.0 is correct, should this be > a MUST instead of a SHOULD? And, if not, under what circumstances > would a node choose to not use the same values? 7.0 describes the attributes used by a node when conducting unicast communication. 9.0 describes the attributes used to create a multicast group, i.e., for multicast communication. So the question is: Must path attributes used for unicast match with those for multicast? The flexibility allowed in the multicast case in the current draft is deliberate. I don't know in reality if this is useful, or even good to have. (Comments are welcome.) My design principle has been to not to make something a requirement unless it is needed for interoperability. Jerry > >Roy >_______________________________________________ >IPoverIB mailing list >IPoverIB@ietf.org >https://www1.ietf.org/mailman/listinfo/ipoverib _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon May 5 23:51: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 XAA25947 for ; Mon, 5 May 2003 23:51:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4640E530016 for ipoverib-archive@odin.ietf.org; Tue, 6 May 2003 00:00:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4640E830013 for ; Tue, 6 May 2003 00:00:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25930 for ; Mon, 5 May 2003 23:51:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CtWG-0002x4-00 for ipoverib-web-archive@ietf.org; Mon, 05 May 2003 23:53:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CtWF-0002x1-00 for ipoverib-web-archive@ietf.org; Mon, 05 May 2003 23:53:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h463xC829910; Mon, 5 May 2003 23:59:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h463vl829856 for ; Mon, 5 May 2003 23:57:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25854 for ; Mon, 5 May 2003 23:48:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CtTe-0002vn-00 for ipoverib@ietf.org; Mon, 05 May 2003 23:50:50 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19CtTY-0002ve-00 for ipoverib@ietf.org; Mon, 05 May 2003 23:50:44 -0400 Received: from jurassic.eng.sun.com ([129.146.88.31]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id UAA00445; Mon, 5 May 2003 20:50:36 -0700 (PDT) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h463oaKQ279973; Mon, 5 May 2003 20:50:36 -0700 (PDT) Message-Id: <200305060350.h463oaKQ279973@jurassic.eng.sun.com> Date: Mon, 5 May 2003 20:50:35 -0700 (PDT) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: rbrabson@us.ibm.com Cc: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GpdF55GDgA3BT45m/VGc3g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc 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: , Roy, >To: ipoverib@ietf.org >MIME-Version: 1.0 >From: Roy Brabson > >I've just started to look at IPoIB, so please forgive me if some of the >comments below have been discussed previously. I did try to read through >the mailing list archive, but may have missed some of the relevant posts. > >- The draft contains a reference to draft-ietf-ipoib-architecture-01.txt. > This is an expired draft which hasn't been updated in almost 18 months. > Should this reference be deleted, or is referenced draft updated and > published as an RFC? > >- In Section 9.0, am I correct in assuming that all routers MUST join the > all-routers multicast group if it exists? Yes, but this is not a new requirement imposed by IPoIB, but rather an existing requirement from the IP layer. > And, if one does not exist, > shouldn't the router create the group when it first connects to the IB > subnet as a "FullMember"? This section also makes it sound as though > the IB administrator must create the all-router multicast group, which > doesn't seem to be necessary. You are right. In prior versions of the draft the all-router mulitcast group played a more prominent role. Now it looks like the all-router MC group can be treated just like many other multicast groups, and gets created by demand when a router joins. I'll change the "SHOULD" to "may" regarding the creation of the all- router multicast group in the paragraph before section 8.0. > And it doesn't describe if/when/how a > router is expected to join the all-router multicast group. Isn't this determined by the IP software independent of IPoIB? > >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > connected routers. [snip] The specific mechanism for a sender to > forward packets to routers are left to implementations". At a > minimum, I think the exact implementation needs to be specified. Why? (The draft strives to avoid dictating implementation details that do not affect interoperability.) > The > text suggests using all-router multicast group or the broadcast group. > If a router is required to create the all-router multicast group (see > the previous comment), then wouldn't it be sufficient to check for the > existence of the all-router multicast group and, if it exists, send to > that? If it doesn't exist, then there can't be any multicast routers > on the link, and since there aren't any local listeners there are no > on-link listeners there isn't any need to send the packet. Don't the code sinppet following 9.B match pretty much what you described above? > > And shouldn't the IPoIB sender subscribe to the IB multicast group > creation events using a wildcard MGID so that it can > "SendOnlyNonMember" join the group if a listener appears on the local > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > router appears on-link and creates the all-routers multicast group? > And doesn't it need to subscribe to the IB multicast group deletion > events so that it knows when to switch back to sending to the > all-router multicast group and/or stop sending? Aren't you saying the same thing (more or less) as what is described in the section following the code snippet? > > But I'm wondering why a node needs to do this at all. Wouldn't it > make more sense for the IPoIB node instead create the multicast group > and join the group so that IPoIB multicast routers can join the group? > Yes, the IPoIB sender will need create the group as a "FullMember", > but this seems to provide a simpler mapping of IP multicast to IB > multicast. While what you suggested may simplify the procedure, it essentially removes the difference between a multicast sender and a multicast receiver, which is wrong. In the IP multicast model a multicast sender doesn't need to be a member of a multicast group to send. The draft has tried to keep the same distinction. > >- Section 9.0 also indicates that "A multicast sender must join the > target multicast group as a "SendOnlyNonMember" before outgoing > messages from it can be successfully routed." This text should be > clarified to indicate this is only true if the node has not already > joined the group as either a "FullMember" or "SendOnlyNonMember". The > If-Then-Else logic below correctly shows this behavior, but this > paragraph does not reflect that behavior. Although your comment is correct, I'd argue this kind of details can be found in the IBA spec. It has nothing to do with IPoIB in particular, So the question becomes how much IBA info we need to repeat in an IPoIB RFC. Since the code sippet already covers this correctly, if you still believe this needs to be clarified i can certain add more text to it. > >- Section 9.0 states that the MGID cache may need to be validated > periodically. I think it would be useful to indicate why this might > be necessary, how a node should go about doing so, and what action > should be taken if the MGID is found to be invalid. I'm assuming that > this would be done by checking with the SA on the outbound link for a > "MCMemberRecord" that matches the MGID and, if not found, creating the > multicast group and rejoining. Good catch. The text comes from the old drafts before the MC group creation/deletion traps were invented. Now with the trap support the periodic cache flush is not needed anymore. > >- Section 9.0 indicates that "For the rest of attributes, it is > recommended the same values from the all-node multicast/broadcast > group be used." Should this instead say "For the rest of the > attributes, the same values from the all-node multicast/broadcast > group SHOULD be used." Regardless of the wording, this text seems to > contradict the Section 7.0 which states a node must "use the rest of > the link attributes associated with the group for all future > communication on the link. If Section 7.0 is correct, should this be > a MUST instead of a SHOULD? And, if not, under what circumstances > would a node choose to not use the same values? 7.0 describes the attributes used by a node when conducting unicast communication. 9.0 describes the attributes used to create a multicast group, i.e., for multicast communication. So the question is: Must path attributes used for unicast match with those for multicast? The flexibility allowed in the multicast case in the current draft is deliberate. I don't know in reality if this is useful, or even good to have. (Comments are welcome.) My design principle has been to not to make something a requirement unless it is needed for interoperability. Jerry > >Roy >_______________________________________________ >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 May 6 03:44:53 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 DAA10888 for ; Tue, 6 May 2003 03:44:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467q8824430; Tue, 6 May 2003 03:52:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467ph824392 for ; Tue, 6 May 2003 03:51:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10823 for ; Tue, 6 May 2003 03:42:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cx7x-000434-00 for ipoverib@ietf.org; Tue, 06 May 2003 03:44:41 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19Cx7g-00042P-00 for ipoverib@ietf.org; Tue, 06 May 2003 03:44:24 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h467i9Qs154576 for ; Tue, 6 May 2003 03:44:09 -0400 Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h467i7V3051118 for ; Tue, 6 May 2003 01:44:08 -0600 Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: Roy Brabson Cc: ipoverib@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Tue, 6 May 2003 00:40:51 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.0.1 [IBM]|April 28, 2003) at 05/06/2003 01:44:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , My comments in below. Vivek -- Vivek Kashyap Linux Technology Center, IBM vivk@us.ibm.com kashyapv@us.ibm.com Ph: 503 578 3422 T/L: 775 3422 Roy Brabson/Raleigh/I To: kashyapv@us.ltcfwd.linux.ibm.com BM@IBMUS cc: ipoverib@ietf.org Sent by: Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt ipoverib-admin@ie tf.org 05/05/03 08:00 > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > creation events using a wildcard MGID so that it can > > "SendOnlyNonMember" join the group if a listener appears on the local > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > router appears on-link and creates the all-routers multicast group? > > And doesn't it need to subscribe to the IB multicast group deletion > > events so that it knows when to switch back to sending to the > > all-router multicast group and/or stop sending? > > An IP application may send the multicast packet to any group. One could > request that the interface be notified of every MGID creation/deletion but the > application(s) might never send any data to those groups. Therefore, > the wildcard report request is something that the implementation will > have to weigh against usage. The choice is upto the implementor. This wasn't clear to me from reading the spec. Let me see if I have this straight: - A listener MUST perform a "FullMember" join for the MGID of the multicast group It won't receive any packets otherwise as per IB specification. - A listener MUST be able to receive an IP multicast packet over either the broadcast GID or the MGID for the multicast group - A router MUST be able to receive an IP multicast packet over either the MGID, all-router MGID, or broadcast GID See the discussion on IP router below. - If there is an on-link listener, a sender may send the packet using either the MGID or to the broadcast GID I don't think the draft says that it is an either or between MGID and broadcast GID if the MGID exists. If the MGID exists the sender sends to the MGID. Oherwise it needs to send the packet to the router(s). Therefore the packet needs to be sent to the MGID corresponding to all-router address. - If there is not an on-link listener, a sender may send the packet to either the broadcast GID or the all-router MGID If there is no on-link listener then the sender should send the packet to the all-router MGID. I agree, as you had noted earlier, that if the all-router MGID doesn't exist then the packet can be dropped. Is that correct? And, if a sender wants to send packets using the MGID, it will need to listen for MGID creation/deletion reports so that it can switch between the MGID and the all-router MGID (or broadcast GID, I suppose) as on-link listeners join/leave the group. I do have to wonder whether having such a large number of optional mechanisms to handle the mapping of IP to IB multicasting is really a good idea. Would we be better off just selecting one approach and saying all IPoIB nodes should take that approach? Both IP and IB have similar concepts and use the same kind of words therefore let us append IP or IB in front of them. Instead of saying multicast group it is better to say IP multicast group or IB multicast group. If MGID is used then it is clear that IB is being talked about. IP listener: An IP listener would like to receive packets. For such a case the IP layer has to instruct the link layer to receive packets on the correspondingly mapped address. In the case of IB, the mapping is defined to the MGID. This is not enough. Therefore the link layer (IB) must IB_join the MGID as a FullMember. The MGID is created if it doesnt exist and the SM programs the fabric such that the packets are received by the listener. IP multicast router: An IP router must be able to receive the multicast packets and forward them if required - both into the subnet or out of the subnet. It gets to know of the groups by way of a routing protocol. Within the subnet IGMP/MLD are used. The router can therefore, on its link interface IB_join the MGIDs when it knows the IP multicast address(implementations don't seem to prefer this as per earlier discussions on this list) or it can listen promiscuously. In IB it cannot listen promiscuosly; therefore the router needs to request MGID creation/deletion reports from the SA/SM and the routers IB_join/leave groups on receiving the reports. The router gets to know of the IP groups to forward to from running a routing protocol. If there are no IP listeners (and hence no corresponding IB MGIDs)in the subnet and the router doesn't create the corresponding MGID itself(as noted in the previous paragraph) then there is no way that IP packets destined for the remote IP multicast address can reach the router unless the packet are sent to an MGID the router is already a member of such as the all-router address. Therefore, in the absence of the relevant MGID the sender needs to send the packet to the all-router MGID. This implies that the router needs to be able to receive IP multicast packets on the corresponding multicast MGID or the all-router MGID. Since a router really wants to receive packets as well as send packets it needs to IB_join as a FullMember or as a NonMember. A Non-Member IB join is preferable in that it doesn't effect the creation/tearing down of the MLID forwarding built into the switching fabric. But an implementation can choose to IB join as FullMember if it so prefers. This is not an option from IPoIb but just what IB provides. IP sender: Any IP host can send to any IP multicast address without itself being a member of the IP group. This is not always the case at the IB layer since the the switches need to be programmed to forward the MLID. Therefore a sender needs to map the IP multicast address to the corresponding MGID (as per mapping defined in this draft) and then IB join the MGID. It can then transmit the packet to the MGID. If there are IP listeners then there will be a corresponding IB MGID that the sender will IB_Join. The router, because it IB_joins all new IB MGID creations (see above) will also be a member and receive the packet. If there are no local subnet IP listeners, the corresponding MGID wouldn't exist. In such a case sending to MGID corresponding to all-routers IP multicast address ensures that the multicast addresses are receieved by the router. One could also argue that the sender should, instead of the SendOnlyNonMember join do a FullMember join. Then the MGID will be created if it doesn't exist and the router will join in on receiving the creation report. But, there is very likely a delay between the creation of the MGID, the report to the router and the router joining the MGID; during this delay the packet is likely dropped. Multicast is not reliable but in this situation the chances of loss are quite high and hence it is not a preferable way of transmitting multicast packets. Vivek > > It does seem like a reasonable thing to request creation/deletion > report on the all-router multicast GID. > > > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > make more sense for the IPoIB node instead create the multicast group > > and join the group so that IPoIB multicast routers can join the group? > > Yes, the IPoIB sender will need create the group as a "FullMember", > > but this seems to provide a simpler mapping of IP multicast to IB > > multicast. > > It will work but how is this a better thing to do ? I also > do not think that such behavior can/should be disallowed. I'm just trying to understand if there is some way to simplify the mapping of IP multicast groups to IB multicast groups. My main concern is with listening for IB group creation/deletion reports so a sender can tell if/when to use the multicast group's MGID and when to use the all-router MGID. If the sender performs a "FullMember" join, then it will always send using the MGID for the corresponding IB multicast group. But, based on what you said above, a sender can always use the broadcast GID when sending to a multicast group for which it is not also listening. This does simplify the logic, but at the cost of forcing every IPoIB node to filter the IP multicast packets for which they are not interested. Then again, it saves the SM from having to reprogram the switches/routers in the IB fabric when the sender performs a non-member join. To be honest, I have no idea how to go about making a rational choice on which approach will yield the better results. Roy _______________________________________________ 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 May 6 03:45: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 DAA10908 for ; Tue, 6 May 2003 03:45:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h467rY824521 for ipoverib-archive@odin.ietf.org; Tue, 6 May 2003 03:53:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467rV824515 for ; Tue, 6 May 2003 03:53:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10879 for ; Tue, 6 May 2003 03:44:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cx9h-00043y-00 for ipoverib-web-archive@ietf.org; Tue, 06 May 2003 03:46:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Cx9g-00043v-00 for ipoverib-web-archive@ietf.org; Tue, 06 May 2003 03:46:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467q8824430; Tue, 6 May 2003 03:52:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467ph824392 for ; Tue, 6 May 2003 03:51:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10823 for ; Tue, 6 May 2003 03:42:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cx7x-000434-00 for ipoverib@ietf.org; Tue, 06 May 2003 03:44:41 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19Cx7g-00042P-00 for ipoverib@ietf.org; Tue, 06 May 2003 03:44:24 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h467i9Qs154576 for ; Tue, 6 May 2003 03:44:09 -0400 Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h467i7V3051118 for ; Tue, 6 May 2003 01:44:08 -0600 Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: Roy Brabson Cc: ipoverib@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Tue, 6 May 2003 00:40:51 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.0.1 [IBM]|April 28, 2003) at 05/06/2003 01:44:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , My comments in below. Vivek -- Vivek Kashyap Linux Technology Center, IBM vivk@us.ibm.com kashyapv@us.ibm.com Ph: 503 578 3422 T/L: 775 3422 Roy Brabson/Raleigh/I To: kashyapv@us.ltcfwd.linux.ibm.com BM@IBMUS cc: ipoverib@ietf.org Sent by: Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt ipoverib-admin@ie tf.org 05/05/03 08:00 > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > creation events using a wildcard MGID so that it can > > "SendOnlyNonMember" join the group if a listener appears on the local > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > router appears on-link and creates the all-routers multicast group? > > And doesn't it need to subscribe to the IB multicast group deletion > > events so that it knows when to switch back to sending to the > > all-router multicast group and/or stop sending? > > An IP application may send the multicast packet to any group. One could > request that the interface be notified of every MGID creation/deletion but the > application(s) might never send any data to those groups. Therefore, > the wildcard report request is something that the implementation will > have to weigh against usage. The choice is upto the implementor. This wasn't clear to me from reading the spec. Let me see if I have this straight: - A listener MUST perform a "FullMember" join for the MGID of the multicast group It won't receive any packets otherwise as per IB specification. - A listener MUST be able to receive an IP multicast packet over either the broadcast GID or the MGID for the multicast group - A router MUST be able to receive an IP multicast packet over either the MGID, all-router MGID, or broadcast GID See the discussion on IP router below. - If there is an on-link listener, a sender may send the packet using either the MGID or to the broadcast GID I don't think the draft says that it is an either or between MGID and broadcast GID if the MGID exists. If the MGID exists the sender sends to the MGID. Oherwise it needs to send the packet to the router(s). Therefore the packet needs to be sent to the MGID corresponding to all-router address. - If there is not an on-link listener, a sender may send the packet to either the broadcast GID or the all-router MGID If there is no on-link listener then the sender should send the packet to the all-router MGID. I agree, as you had noted earlier, that if the all-router MGID doesn't exist then the packet can be dropped. Is that correct? And, if a sender wants to send packets using the MGID, it will need to listen for MGID creation/deletion reports so that it can switch between the MGID and the all-router MGID (or broadcast GID, I suppose) as on-link listeners join/leave the group. I do have to wonder whether having such a large number of optional mechanisms to handle the mapping of IP to IB multicasting is really a good idea. Would we be better off just selecting one approach and saying all IPoIB nodes should take that approach? Both IP and IB have similar concepts and use the same kind of words therefore let us append IP or IB in front of them. Instead of saying multicast group it is better to say IP multicast group or IB multicast group. If MGID is used then it is clear that IB is being talked about. IP listener: An IP listener would like to receive packets. For such a case the IP layer has to instruct the link layer to receive packets on the correspondingly mapped address. In the case of IB, the mapping is defined to the MGID. This is not enough. Therefore the link layer (IB) must IB_join the MGID as a FullMember. The MGID is created if it doesnt exist and the SM programs the fabric such that the packets are received by the listener. IP multicast router: An IP router must be able to receive the multicast packets and forward them if required - both into the subnet or out of the subnet. It gets to know of the groups by way of a routing protocol. Within the subnet IGMP/MLD are used. The router can therefore, on its link interface IB_join the MGIDs when it knows the IP multicast address(implementations don't seem to prefer this as per earlier discussions on this list) or it can listen promiscuously. In IB it cannot listen promiscuosly; therefore the router needs to request MGID creation/deletion reports from the SA/SM and the routers IB_join/leave groups on receiving the reports. The router gets to know of the IP groups to forward to from running a routing protocol. If there are no IP listeners (and hence no corresponding IB MGIDs)in the subnet and the router doesn't create the corresponding MGID itself(as noted in the previous paragraph) then there is no way that IP packets destined for the remote IP multicast address can reach the router unless the packet are sent to an MGID the router is already a member of such as the all-router address. Therefore, in the absence of the relevant MGID the sender needs to send the packet to the all-router MGID. This implies that the router needs to be able to receive IP multicast packets on the corresponding multicast MGID or the all-router MGID. Since a router really wants to receive packets as well as send packets it needs to IB_join as a FullMember or as a NonMember. A Non-Member IB join is preferable in that it doesn't effect the creation/tearing down of the MLID forwarding built into the switching fabric. But an implementation can choose to IB join as FullMember if it so prefers. This is not an option from IPoIb but just what IB provides. IP sender: Any IP host can send to any IP multicast address without itself being a member of the IP group. This is not always the case at the IB layer since the the switches need to be programmed to forward the MLID. Therefore a sender needs to map the IP multicast address to the corresponding MGID (as per mapping defined in this draft) and then IB join the MGID. It can then transmit the packet to the MGID. If there are IP listeners then there will be a corresponding IB MGID that the sender will IB_Join. The router, because it IB_joins all new IB MGID creations (see above) will also be a member and receive the packet. If there are no local subnet IP listeners, the corresponding MGID wouldn't exist. In such a case sending to MGID corresponding to all-routers IP multicast address ensures that the multicast addresses are receieved by the router. One could also argue that the sender should, instead of the SendOnlyNonMember join do a FullMember join. Then the MGID will be created if it doesn't exist and the router will join in on receiving the creation report. But, there is very likely a delay between the creation of the MGID, the report to the router and the router joining the MGID; during this delay the packet is likely dropped. Multicast is not reliable but in this situation the chances of loss are quite high and hence it is not a preferable way of transmitting multicast packets. Vivek > > It does seem like a reasonable thing to request creation/deletion > report on the all-router multicast GID. > > > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > make more sense for the IPoIB node instead create the multicast group > > and join the group so that IPoIB multicast routers can join the group? > > Yes, the IPoIB sender will need create the group as a "FullMember", > > but this seems to provide a simpler mapping of IP multicast to IB > > multicast. > > It will work but how is this a better thing to do ? I also > do not think that such behavior can/should be disallowed. I'm just trying to understand if there is some way to simplify the mapping of IP multicast groups to IB multicast groups. My main concern is with listening for IB group creation/deletion reports so a sender can tell if/when to use the multicast group's MGID and when to use the all-router MGID. If the sender performs a "FullMember" join, then it will always send using the MGID for the corresponding IB multicast group. But, based on what you said above, a sender can always use the broadcast GID when sending to a multicast group for which it is not also listening. This does simplify the logic, but at the cost of forcing every IPoIB node to filter the IP multicast packets for which they are not interested. Then again, it saves the SM from having to reprogram the switches/routers in the IB fabric when the sender performs a non-member join. To be honest, I have no idea how to go about making a rational choice on which approach will yield the better results. Roy _______________________________________________ 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 May 6 14: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 OAA02189 for ; Tue, 6 May 2003 14:29:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46IbI816254; Tue, 6 May 2003 14:37:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46G48802782 for ; Tue, 6 May 2003 12:04:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26999 for ; Tue, 6 May 2003 11:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D4oY-00008g-00 for ipoverib@ietf.org; Tue, 06 May 2003 11:57:10 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19D4oX-00008K-00 for ipoverib@ietf.org; Tue, 06 May 2003 11:57:09 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h46FvOQs258012; Tue, 6 May 2003 11:57:24 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h46FuufP105428; Tue, 6 May 2003 09:56:57 -0600 In-Reply-To: <200305060350.h463oaKQ279973@jurassic.eng.sun.com> To: "H.K. Jerry Chu" Cc: ipoverib@ietf.org Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/06/2003 11:56:36 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/06/2003 11:56:36 AM, Serialize complete at 05/06/2003 11:56:36 AM, S/MIME Sign failed at 05/06/2003 11:56:36 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/06/2003 09:56:56, Serialize complete at 05/06/2003 09:56:56 Message-ID: Date: Tue, 6 May 2003 11:56:52 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > > connected routers. [snip] The specific mechanism for a sender to > > forward packets to routers are left to implementations". At a > > minimum, I think the exact implementation needs to be specified. > > Why? (The draft strives to avoid dictating implementation details that > do not affect interoperability.) For interoperatibilty. The requirement is the host and router must agree on using a common mechanism for exchanging the IP multicast packet. Implementations are free to choose a mechanism as long as all other implementations with which they communicate also choose to implement the same mechanism. I don't think this is an area where we can or should punt - a minimal, common approach needs to be mandated such that all IPoIB nodes implement that mechanism so that any two IPoIB nodes will interoperate. > > The > > text suggests using all-router multicast group or the broadcast group. > > If a router is required to create the all-router multicast group (see > > the previous comment), then wouldn't it be sufficient to check for the > > existence of the all-router multicast group and, if it exists, send to > > that? If it doesn't exist, then there can't be any multicast routers > > on the link, and since there aren't any local listeners there are no > > on-link listeners there isn't any need to send the packet. > > Don't the code sinppet following 9.B match pretty much what you described > above? Yes, it does, and if the text matched the code snippet then I wouldn't have an issue. But the text which supports the code snippet doesn't. The text basically says you could send to the all-router multicast group OR the broadcast group. And either should work, as long as the receiving IPoIB node MUST accept the IP multicast packets regardless of the IB group over which they are received (I'm not sure I've seen this explicitly stated in the draft, but I may have missed it). But do we really need to have multiple mechanisms to accomplish the same result? Wouldn't we be better off just choosing one and going with that? And how are we going to find multiple interoperable implementations for each option when the draft puts no limits on the approaches which can be taken? > > > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > creation events using a wildcard MGID so that it can > > "SendOnlyNonMember" join the group if a listener appears on the local > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > router appears on-link and creates the all-routers multicast group? > > And doesn't it need to subscribe to the IB multicast group deletion > > events so that it knows when to switch back to sending to the > > all-router multicast group and/or stop sending? > > Aren't you saying the same thing (more or less) as what is described in > the section following the code snippet? You are right - I must have missed the text. But you need to change the "should" to a "MUST" in that paragraph. > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > make more sense for the IPoIB node instead create the multicast group > > and join the group so that IPoIB multicast routers can join the group? > > Yes, the IPoIB sender will need create the group as a "FullMember", > > but this seems to provide a simpler mapping of IP multicast to IB > > multicast. > > While what you suggested may simplify the procedure, it essentially > removes the difference between a multicast sender and a multicast receiver, > which is wrong. In the IP multicast model a multicast sender doesn't need > to be a member of a multicast group to send. The draft has tried to > keep the same distinction. However, you are mapping the IP multicast model to the IB multicast model, and the two are not the same. The reality is a sender must join an IB multicast group in order to send to it (albeit as a "SendOnlyNonMember"), and this step does not exist in the IP model. I imagine that the vast majority of the code/complexity of an IPoIB implementation is going to be dealing with IB multicasting. I was hoping there was some way to reduce both at an IPoIB host. Maybe it is just wishful thinking. By the way, after thinking about this a little more, I'm not sure that creating a group as I suggested makes sense in all cases. For instance, it is only useful for an IP multicast group which has a scope greater than link-local. For link-local scope, only nodes directly attached to the IPoIB link are able to receive the packet. Creating the group for the purpose of forwarding to an IPoIB multicast router is simply wasteful, as the IPoIB multicast router will not be able to forward the packet to another IP link. A similar optimization can also be taken with the current approach described in this draft - for an IP multicast group with link-local scope, if the IB MGID for that IP multicast group does not exist then an IPoIB node really doesn't need to send the multicast packet to the all-router MGID or broadcast GID. > >- Section 9.0 also indicates that "A multicast sender must join the > > target multicast group as a "SendOnlyNonMember" before outgoing > > messages from it can be successfully routed." This text should be > > clarified to indicate this is only true if the node has not already > > joined the group as either a "FullMember" or "SendOnlyNonMember". The > > If-Then-Else logic below correctly shows this behavior, but this > > paragraph does not reflect that behavior. > > Although your comment is correct, I'd argue this kind of details can > be found in the IBA spec. It has nothing to do with IPoIB in particular, > So the question becomes how much IBA info we need to repeat in an IPoIB RFC. > Since the code sippet already covers this correctly, if you still believe > this needs to be clarified i can certain add more text to it. My feeling is enough to describe HOW an IPoIB node will USE the IBA services, and this is one of those cases. I would prefer to see the text clarified if you do another revision of the draft, but given the code snippet describes the correct behavior I wouldn't hold this draft up just to clarify this paragraph. > >- Section 9.0 indicates that "For the rest of attributes, it is > > recommended the same values from the all-node multicast/broadcast > > group be used." Should this instead say "For the rest of the > > attributes, the same values from the all-node multicast/broadcast > > group SHOULD be used." Regardless of the wording, this text seems to > > contradict the Section 7.0 which states a node must "use the rest of > > the link attributes associated with the group for all future > > communication on the link. If Section 7.0 is correct, should this be > > a MUST instead of a SHOULD? And, if not, under what circumstances > > would a node choose to not use the same values? > > 7.0 describes the attributes used by a node when conducting unicast > communication. 9.0 describes the attributes used to create a multicast > group, i.e., for multicast communication. So the question is: > Must path attributes used for unicast match with those for multicast? > > The flexibility allowed in the multicast case in the current draft is > deliberate. I don't know in reality if this is useful, or even good to > have. (Comments are welcome.) My design principle has been to not to > make something a requirement unless it is needed for interoperability. Flexibility is often times good, but so is describing a minimal set of functions necessary for interoperability. If a node selects link attributes when creating an MGID which does not match the broadcast GID's attributes, then it is possible that not all nodes which are members of the IPoIB link will be able to support those attributes. If this happens, then the two nodes will not be able to communicate using the IP multicast group mapped to the MGID. All of a sudden, an IPoIB node can't send an ARP request or Neighbor Solicitation to another node. Perhaps it would be better to state that a node which creates a multicast group MUST use the same values for the attributes as the all-node multicast/broadcast group, but a node joining a multicast group must not verify the values match. If the node joining the group can't support the values for the multicast group, then it should log the error. That way, a future RFC could describe why/when/how a node would choose to use different values for the link attributes but still be able to interoperate with IPoIB nodes. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue May 6 14:29:53 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 OAA02203 for ; Tue, 6 May 2003 14:29:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46IcTC16791 for ipoverib-archive@odin.ietf.org; Tue, 6 May 2003 14:38:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46IcT816788 for ; Tue, 6 May 2003 14:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02185 for ; Tue, 6 May 2003 14:29:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D7Ds-0001EW-00 for ipoverib-web-archive@ietf.org; Tue, 06 May 2003 14:31:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D7Dr-0001ES-00 for ipoverib-web-archive@ietf.org; Tue, 06 May 2003 14:31:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46IbI816254; Tue, 6 May 2003 14:37:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46G48802782 for ; Tue, 6 May 2003 12:04:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26999 for ; Tue, 6 May 2003 11:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D4oY-00008g-00 for ipoverib@ietf.org; Tue, 06 May 2003 11:57:10 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19D4oX-00008K-00 for ipoverib@ietf.org; Tue, 06 May 2003 11:57:09 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h46FvOQs258012; Tue, 6 May 2003 11:57:24 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h46FuufP105428; Tue, 6 May 2003 09:56:57 -0600 In-Reply-To: <200305060350.h463oaKQ279973@jurassic.eng.sun.com> To: "H.K. Jerry Chu" Cc: ipoverib@ietf.org Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/06/2003 11:56:36 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/06/2003 11:56:36 AM, Serialize complete at 05/06/2003 11:56:36 AM, S/MIME Sign failed at 05/06/2003 11:56:36 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/06/2003 09:56:56, Serialize complete at 05/06/2003 09:56:56 Message-ID: Date: Tue, 6 May 2003 11:56:52 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > > connected routers. [snip] The specific mechanism for a sender to > > forward packets to routers are left to implementations". At a > > minimum, I think the exact implementation needs to be specified. > > Why? (The draft strives to avoid dictating implementation details that > do not affect interoperability.) For interoperatibilty. The requirement is the host and router must agree on using a common mechanism for exchanging the IP multicast packet. Implementations are free to choose a mechanism as long as all other implementations with which they communicate also choose to implement the same mechanism. I don't think this is an area where we can or should punt - a minimal, common approach needs to be mandated such that all IPoIB nodes implement that mechanism so that any two IPoIB nodes will interoperate. > > The > > text suggests using all-router multicast group or the broadcast group. > > If a router is required to create the all-router multicast group (see > > the previous comment), then wouldn't it be sufficient to check for the > > existence of the all-router multicast group and, if it exists, send to > > that? If it doesn't exist, then there can't be any multicast routers > > on the link, and since there aren't any local listeners there are no > > on-link listeners there isn't any need to send the packet. > > Don't the code sinppet following 9.B match pretty much what you described > above? Yes, it does, and if the text matched the code snippet then I wouldn't have an issue. But the text which supports the code snippet doesn't. The text basically says you could send to the all-router multicast group OR the broadcast group. And either should work, as long as the receiving IPoIB node MUST accept the IP multicast packets regardless of the IB group over which they are received (I'm not sure I've seen this explicitly stated in the draft, but I may have missed it). But do we really need to have multiple mechanisms to accomplish the same result? Wouldn't we be better off just choosing one and going with that? And how are we going to find multiple interoperable implementations for each option when the draft puts no limits on the approaches which can be taken? > > > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > creation events using a wildcard MGID so that it can > > "SendOnlyNonMember" join the group if a listener appears on the local > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > router appears on-link and creates the all-routers multicast group? > > And doesn't it need to subscribe to the IB multicast group deletion > > events so that it knows when to switch back to sending to the > > all-router multicast group and/or stop sending? > > Aren't you saying the same thing (more or less) as what is described in > the section following the code snippet? You are right - I must have missed the text. But you need to change the "should" to a "MUST" in that paragraph. > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > make more sense for the IPoIB node instead create the multicast group > > and join the group so that IPoIB multicast routers can join the group? > > Yes, the IPoIB sender will need create the group as a "FullMember", > > but this seems to provide a simpler mapping of IP multicast to IB > > multicast. > > While what you suggested may simplify the procedure, it essentially > removes the difference between a multicast sender and a multicast receiver, > which is wrong. In the IP multicast model a multicast sender doesn't need > to be a member of a multicast group to send. The draft has tried to > keep the same distinction. However, you are mapping the IP multicast model to the IB multicast model, and the two are not the same. The reality is a sender must join an IB multicast group in order to send to it (albeit as a "SendOnlyNonMember"), and this step does not exist in the IP model. I imagine that the vast majority of the code/complexity of an IPoIB implementation is going to be dealing with IB multicasting. I was hoping there was some way to reduce both at an IPoIB host. Maybe it is just wishful thinking. By the way, after thinking about this a little more, I'm not sure that creating a group as I suggested makes sense in all cases. For instance, it is only useful for an IP multicast group which has a scope greater than link-local. For link-local scope, only nodes directly attached to the IPoIB link are able to receive the packet. Creating the group for the purpose of forwarding to an IPoIB multicast router is simply wasteful, as the IPoIB multicast router will not be able to forward the packet to another IP link. A similar optimization can also be taken with the current approach described in this draft - for an IP multicast group with link-local scope, if the IB MGID for that IP multicast group does not exist then an IPoIB node really doesn't need to send the multicast packet to the all-router MGID or broadcast GID. > >- Section 9.0 also indicates that "A multicast sender must join the > > target multicast group as a "SendOnlyNonMember" before outgoing > > messages from it can be successfully routed." This text should be > > clarified to indicate this is only true if the node has not already > > joined the group as either a "FullMember" or "SendOnlyNonMember". The > > If-Then-Else logic below correctly shows this behavior, but this > > paragraph does not reflect that behavior. > > Although your comment is correct, I'd argue this kind of details can > be found in the IBA spec. It has nothing to do with IPoIB in particular, > So the question becomes how much IBA info we need to repeat in an IPoIB RFC. > Since the code sippet already covers this correctly, if you still believe > this needs to be clarified i can certain add more text to it. My feeling is enough to describe HOW an IPoIB node will USE the IBA services, and this is one of those cases. I would prefer to see the text clarified if you do another revision of the draft, but given the code snippet describes the correct behavior I wouldn't hold this draft up just to clarify this paragraph. > >- Section 9.0 indicates that "For the rest of attributes, it is > > recommended the same values from the all-node multicast/broadcast > > group be used." Should this instead say "For the rest of the > > attributes, the same values from the all-node multicast/broadcast > > group SHOULD be used." Regardless of the wording, this text seems to > > contradict the Section 7.0 which states a node must "use the rest of > > the link attributes associated with the group for all future > > communication on the link. If Section 7.0 is correct, should this be > > a MUST instead of a SHOULD? And, if not, under what circumstances > > would a node choose to not use the same values? > > 7.0 describes the attributes used by a node when conducting unicast > communication. 9.0 describes the attributes used to create a multicast > group, i.e., for multicast communication. So the question is: > Must path attributes used for unicast match with those for multicast? > > The flexibility allowed in the multicast case in the current draft is > deliberate. I don't know in reality if this is useful, or even good to > have. (Comments are welcome.) My design principle has been to not to > make something a requirement unless it is needed for interoperability. Flexibility is often times good, but so is describing a minimal set of functions necessary for interoperability. If a node selects link attributes when creating an MGID which does not match the broadcast GID's attributes, then it is possible that not all nodes which are members of the IPoIB link will be able to support those attributes. If this happens, then the two nodes will not be able to communicate using the IP multicast group mapped to the MGID. All of a sudden, an IPoIB node can't send an ARP request or Neighbor Solicitation to another node. Perhaps it would be better to state that a node which creates a multicast group MUST use the same values for the attributes as the all-node multicast/broadcast group, but a node joining a multicast group must not verify the values match. If the node joining the group can't support the values for the multicast group, then it should log the error. That way, a future RFC could describe why/when/how a node would choose to use different values for the link attributes but still be able to interoperate with IPoIB nodes. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue May 6 18:48: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 SAA13078 for ; Tue, 6 May 2003 18:48:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Mu8805147; Tue, 6 May 2003 18:56:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46MrS805056 for ; Tue, 6 May 2003 18:53:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12947 for ; Tue, 6 May 2003 18:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DBCX-0003DF-00 for ipoverib@ietf.org; Tue, 06 May 2003 18:46:21 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19DBCW-0003Co-00 for ipoverib@ietf.org; Tue, 06 May 2003 18:46:20 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h46Mkakc249160; Tue, 6 May 2003 18:46:36 -0400 Received: from w-vkashyap95.des.sequent.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h46MkZuk088832; Tue, 6 May 2003 16:46:35 -0600 Date: Tue, 6 May 2003 15:43:33 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Roy Brabson cc: "H.K. Jerry Chu" , Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt In-Reply-To: Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , On Tue, 6 May 2003, Roy Brabson wrote: > > >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > > > > connected routers. [snip] The specific mechanism for a sender to > > > forward packets to routers are left to implementations". At a > > > minimum, I think the exact implementation needs to be specified. > > > > Why? (The draft strives to avoid dictating implementation details that > > do not affect interoperability.) > > For interoperatibilty. The requirement is the host and router must agree > on using a common mechanism for exchanging the IP multicast packet. > Implementations are free to choose a mechanism as long as all other > implementations with which they communicate also choose to implement the > same mechanism. I don't think this is an area where we can or should punt > - a minimal, common approach needs to be mandated such that all IPoIB > nodes implement that mechanism so that any two IPoIB nodes will > interoperate. Roy, Yes, I agree that a common method must be described for interoperability. Though, in this case, even with the flexibility interoperability is maintained - the onus being on the router : The packet may be sent to the routers on broadcast-GID or the all-router GID. The router itself will listen on both - broadcast-GID since it is required by IPoIB and all-routers as a result of other specs (IPv6 & IGMP). Therefore the packet will be received by the router irrespective of the MGID used as long as the router accepts any multicast packets on these MGIDs. I have described the need for this in my previous reply. We could do one of three things when the relevant MGID does not exist: 1. The host must always forward on broadcast MGID and the router must always accept IP multicast packets on the broadcast GID. 2. The host must always forward on all-router MGID and the router must always accept IP multicast packets on the all-router MGID 3. The host must always forward on broadcast GID or all-router MGID. The router must accept IP multicast packets on both the broadcast MGID and all-router MGID. We have chosen case 3 . Is there a strong feeling that one of the other cases is preferable? It appears that the method chosen(case 3) needs to be explicitly stated in the draft. > > > > The > > > text suggests using all-router multicast group or the broadcast > group. > > > If a router is required to create the all-router multicast group (see > > > > the previous comment), then wouldn't it be sufficient to check for > the > > > existence of the all-router multicast group and, if it exists, send > to > > > that? If it doesn't exist, then there can't be any multicast routers > > > > on the link, and since there aren't any local listeners there are no > > > on-link listeners there isn't any need to send the packet. > > > > Don't the code sinppet following 9.B match pretty much what you > described > > above? > > Yes, it does, and if the text matched the code snippet then I wouldn't > have an issue. But the text which supports the code snippet doesn't. The > text basically says you could send to the all-router multicast group OR > the broadcast group. And either should work, as long as the receiving > IPoIB node MUST accept the IP multicast packets regardless of the IB group > over which they are received (I'm not sure I've seen this explicitly > stated in the draft, but I may have missed it). But do we really need to > have multiple mechanisms to accomplish the same result? Wouldn't we be > better off just choosing one and going with that? And how are we going to > find multiple interoperable implementations for each option when the draft > puts no limits on the approaches which can be taken? > > > > > > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > > creation events using a wildcard MGID so that it can > > > "SendOnlyNonMember" join the group if a listener appears on the local > > > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > > router appears on-link and creates the all-routers multicast group? > > > And doesn't it need to subscribe to the IB multicast group deletion > > > events so that it knows when to switch back to sending to the > > > all-router multicast group and/or stop sending? > > > > Aren't you saying the same thing (more or less) as what is described in > > the section following the code snippet? > > You are right - I must have missed the text. But you need to change the > "should" to a "MUST" in that paragraph. > > > > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > > make more sense for the IPoIB node instead create the multicast group > > > > and join the group so that IPoIB multicast routers can join the > group? > > > Yes, the IPoIB sender will need create the group as a "FullMember", > > > but this seems to provide a simpler mapping of IP multicast to IB > > > multicast. > > > > While what you suggested may simplify the procedure, it essentially > > removes the difference between a multicast sender and a multicast > receiver, > > which is wrong. In the IP multicast model a multicast sender doesn't > need > > to be a member of a multicast group to send. The draft has tried to > > keep the same distinction. > > However, you are mapping the IP multicast model to the IB multicast model, > and the two are not the same. The reality is a sender must join an IB > multicast group in order to send to it (albeit as a "SendOnlyNonMember"), > and this step does not exist in the IP model. I imagine that the vast > majority of the code/complexity of an IPoIB implementation is going to be > dealing with IB multicasting. I was hoping there was some way to reduce > both at an IPoIB host. Maybe it is just wishful thinking. > > By the way, after thinking about this a little more, I'm not sure that > creating a group as I suggested makes sense in all cases. For instance, > it is only useful for an IP multicast group which has a scope greater than > link-local. For link-local scope, only nodes directly attached to the > IPoIB link are able to receive the packet. Creating the group for the > purpose of forwarding to an IPoIB multicast router is simply wasteful, as > the IPoIB multicast router will not be able to forward the packet to > another IP link. > > A similar optimization can also be taken with the current approach > described in this draft - for an IP multicast group with link-local scope, > if the IB MGID for that IP multicast group does not exist then an IPoIB > node really doesn't need to send the multicast packet to the all-router > MGID or broadcast GID. > > > >- Section 9.0 also indicates that "A multicast sender must join the > > > target multicast group as a "SendOnlyNonMember" before outgoing > > > messages from it can be successfully routed." This text should be > > > clarified to indicate this is only true if the node has not already > > > joined the group as either a "FullMember" or "SendOnlyNonMember". The > > > > If-Then-Else logic below correctly shows this behavior, but this > > > paragraph does not reflect that behavior. > > > > Although your comment is correct, I'd argue this kind of details can > > be found in the IBA spec. It has nothing to do with IPoIB in particular, > > So the question becomes how much IBA info we need to repeat in an IPoIB > RFC. > > Since the code sippet already covers this correctly, if you still > believe > > this needs to be clarified i can certain add more text to it. > > My feeling is enough to describe HOW an IPoIB node will USE the IBA > services, and this is one of those cases. I would prefer to see the text > clarified if you do another revision of the draft, but given the code > snippet describes the correct behavior I wouldn't hold this draft up just > to clarify this paragraph. > > > >- Section 9.0 indicates that "For the rest of attributes, it is > > > recommended the same values from the all-node multicast/broadcast > > > group be used." Should this instead say "For the rest of the > > > attributes, the same values from the all-node multicast/broadcast > > > group SHOULD be used." Regardless of the wording, this text seems to > > > contradict the Section 7.0 which states a node must "use the rest of > > > the link attributes associated with the group for all future > > > communication on the link. If Section 7.0 is correct, should this be > > > > a MUST instead of a SHOULD? And, if not, under what circumstances > > > would a node choose to not use the same values? > > > > 7.0 describes the attributes used by a node when conducting unicast > > communication. 9.0 describes the attributes used to create a multicast > > group, i.e., for multicast communication. So the question is: > > Must path attributes used for unicast match with those for multicast? > > > > The flexibility allowed in the multicast case in the current draft is > > deliberate. I don't know in reality if this is useful, or even good to > > have. (Comments are welcome.) My design principle has been to not to > > make something a requirement unless it is needed for interoperability. > > Flexibility is often times good, but so is describing a minimal set of > functions necessary for interoperability. If a node selects link > attributes when creating an MGID which does not match the broadcast GID's > attributes, then it is possible that not all nodes which are members of > the IPoIB link will be able to support those attributes. If this happens, > then the two nodes will not be able to communicate using the IP multicast > group mapped to the MGID. All of a sudden, an IPoIB node can't send an > ARP request or Neighbor Solicitation to another node. > > Perhaps it would be better to state that a node which creates a multicast > group MUST use the same values for the attributes as the all-node > multicast/broadcast group, but a node joining a multicast group must not > verify the values match. If the node joining the group can't support the > values for the multicast group, then it should log the error. That way, a > future RFC could describe why/when/how a node would choose to use > different values for the link attributes but still be able to interoperate > with IPoIB nodes. That is a valid idea. The other alternative is to list the parameters that may differ from the ones used by the broadcast-GID. The parameters for an IB multicast group are: Q_Key, MLID, MTU, TClass, P_Key, Rate, SL, PacketLifeTime, FlowLabel, Hoplimit, scope. We certainly need the P_Key and MTU to be the same as the broadcast MGID. Similarly all multicast mappings in a subnet must have the same 'scope'. The other parameters can be different if it is ensured that they are all supported by all the members of the IP subnet. There is no well defined method of ensuring this - none is being defined by us. On the other had, by definition all members support the parameters supported by the broadcast-GID. Therefore I agree with you... Jerry, I think we should change the draft to state the following about the parameters: 1. unicast communication use the parameters used by broadcast-GID 2. multicast GIDs created should use the same parameters as the broadcast-GID. Vivek > > Roy > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue May 6 18:48:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13092 for ; Tue, 6 May 2003 18:48:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46Mv5A05226 for ipoverib-archive@odin.ietf.org; Tue, 6 May 2003 18:57:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Mv5805223 for ; Tue, 6 May 2003 18:57:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13060 for ; Tue, 6 May 2003 18:47:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DBG3-0003Eh-00 for ipoverib-web-archive@ietf.org; Tue, 06 May 2003 18:49:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DBG2-0003Ee-00 for ipoverib-web-archive@ietf.org; Tue, 06 May 2003 18:49:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Mu8805147; Tue, 6 May 2003 18:56:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46MrS805056 for ; Tue, 6 May 2003 18:53:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12947 for ; Tue, 6 May 2003 18:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DBCX-0003DF-00 for ipoverib@ietf.org; Tue, 06 May 2003 18:46:21 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19DBCW-0003Co-00 for ipoverib@ietf.org; Tue, 06 May 2003 18:46:20 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h46Mkakc249160; Tue, 6 May 2003 18:46:36 -0400 Received: from w-vkashyap95.des.sequent.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h46MkZuk088832; Tue, 6 May 2003 16:46:35 -0600 Date: Tue, 6 May 2003 15:43:33 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Roy Brabson cc: "H.K. Jerry Chu" , Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt In-Reply-To: Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , On Tue, 6 May 2003, Roy Brabson wrote: > > >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > > > > connected routers. [snip] The specific mechanism for a sender to > > > forward packets to routers are left to implementations". At a > > > minimum, I think the exact implementation needs to be specified. > > > > Why? (The draft strives to avoid dictating implementation details that > > do not affect interoperability.) > > For interoperatibilty. The requirement is the host and router must agree > on using a common mechanism for exchanging the IP multicast packet. > Implementations are free to choose a mechanism as long as all other > implementations with which they communicate also choose to implement the > same mechanism. I don't think this is an area where we can or should punt > - a minimal, common approach needs to be mandated such that all IPoIB > nodes implement that mechanism so that any two IPoIB nodes will > interoperate. Roy, Yes, I agree that a common method must be described for interoperability. Though, in this case, even with the flexibility interoperability is maintained - the onus being on the router : The packet may be sent to the routers on broadcast-GID or the all-router GID. The router itself will listen on both - broadcast-GID since it is required by IPoIB and all-routers as a result of other specs (IPv6 & IGMP). Therefore the packet will be received by the router irrespective of the MGID used as long as the router accepts any multicast packets on these MGIDs. I have described the need for this in my previous reply. We could do one of three things when the relevant MGID does not exist: 1. The host must always forward on broadcast MGID and the router must always accept IP multicast packets on the broadcast GID. 2. The host must always forward on all-router MGID and the router must always accept IP multicast packets on the all-router MGID 3. The host must always forward on broadcast GID or all-router MGID. The router must accept IP multicast packets on both the broadcast MGID and all-router MGID. We have chosen case 3 . Is there a strong feeling that one of the other cases is preferable? It appears that the method chosen(case 3) needs to be explicitly stated in the draft. > > > > The > > > text suggests using all-router multicast group or the broadcast > group. > > > If a router is required to create the all-router multicast group (see > > > > the previous comment), then wouldn't it be sufficient to check for > the > > > existence of the all-router multicast group and, if it exists, send > to > > > that? If it doesn't exist, then there can't be any multicast routers > > > > on the link, and since there aren't any local listeners there are no > > > on-link listeners there isn't any need to send the packet. > > > > Don't the code sinppet following 9.B match pretty much what you > described > > above? > > Yes, it does, and if the text matched the code snippet then I wouldn't > have an issue. But the text which supports the code snippet doesn't. The > text basically says you could send to the all-router multicast group OR > the broadcast group. And either should work, as long as the receiving > IPoIB node MUST accept the IP multicast packets regardless of the IB group > over which they are received (I'm not sure I've seen this explicitly > stated in the draft, but I may have missed it). But do we really need to > have multiple mechanisms to accomplish the same result? Wouldn't we be > better off just choosing one and going with that? And how are we going to > find multiple interoperable implementations for each option when the draft > puts no limits on the approaches which can be taken? > > > > > > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > > creation events using a wildcard MGID so that it can > > > "SendOnlyNonMember" join the group if a listener appears on the local > > > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > > router appears on-link and creates the all-routers multicast group? > > > And doesn't it need to subscribe to the IB multicast group deletion > > > events so that it knows when to switch back to sending to the > > > all-router multicast group and/or stop sending? > > > > Aren't you saying the same thing (more or less) as what is described in > > the section following the code snippet? > > You are right - I must have missed the text. But you need to change the > "should" to a "MUST" in that paragraph. > > > > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > > make more sense for the IPoIB node instead create the multicast group > > > > and join the group so that IPoIB multicast routers can join the > group? > > > Yes, the IPoIB sender will need create the group as a "FullMember", > > > but this seems to provide a simpler mapping of IP multicast to IB > > > multicast. > > > > While what you suggested may simplify the procedure, it essentially > > removes the difference between a multicast sender and a multicast > receiver, > > which is wrong. In the IP multicast model a multicast sender doesn't > need > > to be a member of a multicast group to send. The draft has tried to > > keep the same distinction. > > However, you are mapping the IP multicast model to the IB multicast model, > and the two are not the same. The reality is a sender must join an IB > multicast group in order to send to it (albeit as a "SendOnlyNonMember"), > and this step does not exist in the IP model. I imagine that the vast > majority of the code/complexity of an IPoIB implementation is going to be > dealing with IB multicasting. I was hoping there was some way to reduce > both at an IPoIB host. Maybe it is just wishful thinking. > > By the way, after thinking about this a little more, I'm not sure that > creating a group as I suggested makes sense in all cases. For instance, > it is only useful for an IP multicast group which has a scope greater than > link-local. For link-local scope, only nodes directly attached to the > IPoIB link are able to receive the packet. Creating the group for the > purpose of forwarding to an IPoIB multicast router is simply wasteful, as > the IPoIB multicast router will not be able to forward the packet to > another IP link. > > A similar optimization can also be taken with the current approach > described in this draft - for an IP multicast group with link-local scope, > if the IB MGID for that IP multicast group does not exist then an IPoIB > node really doesn't need to send the multicast packet to the all-router > MGID or broadcast GID. > > > >- Section 9.0 also indicates that "A multicast sender must join the > > > target multicast group as a "SendOnlyNonMember" before outgoing > > > messages from it can be successfully routed." This text should be > > > clarified to indicate this is only true if the node has not already > > > joined the group as either a "FullMember" or "SendOnlyNonMember". The > > > > If-Then-Else logic below correctly shows this behavior, but this > > > paragraph does not reflect that behavior. > > > > Although your comment is correct, I'd argue this kind of details can > > be found in the IBA spec. It has nothing to do with IPoIB in particular, > > So the question becomes how much IBA info we need to repeat in an IPoIB > RFC. > > Since the code sippet already covers this correctly, if you still > believe > > this needs to be clarified i can certain add more text to it. > > My feeling is enough to describe HOW an IPoIB node will USE the IBA > services, and this is one of those cases. I would prefer to see the text > clarified if you do another revision of the draft, but given the code > snippet describes the correct behavior I wouldn't hold this draft up just > to clarify this paragraph. > > > >- Section 9.0 indicates that "For the rest of attributes, it is > > > recommended the same values from the all-node multicast/broadcast > > > group be used." Should this instead say "For the rest of the > > > attributes, the same values from the all-node multicast/broadcast > > > group SHOULD be used." Regardless of the wording, this text seems to > > > contradict the Section 7.0 which states a node must "use the rest of > > > the link attributes associated with the group for all future > > > communication on the link. If Section 7.0 is correct, should this be > > > > a MUST instead of a SHOULD? And, if not, under what circumstances > > > would a node choose to not use the same values? > > > > 7.0 describes the attributes used by a node when conducting unicast > > communication. 9.0 describes the attributes used to create a multicast > > group, i.e., for multicast communication. So the question is: > > Must path attributes used for unicast match with those for multicast? > > > > The flexibility allowed in the multicast case in the current draft is > > deliberate. I don't know in reality if this is useful, or even good to > > have. (Comments are welcome.) My design principle has been to not to > > make something a requirement unless it is needed for interoperability. > > Flexibility is often times good, but so is describing a minimal set of > functions necessary for interoperability. If a node selects link > attributes when creating an MGID which does not match the broadcast GID's > attributes, then it is possible that not all nodes which are members of > the IPoIB link will be able to support those attributes. If this happens, > then the two nodes will not be able to communicate using the IP multicast > group mapped to the MGID. All of a sudden, an IPoIB node can't send an > ARP request or Neighbor Solicitation to another node. > > Perhaps it would be better to state that a node which creates a multicast > group MUST use the same values for the attributes as the all-node > multicast/broadcast group, but a node joining a multicast group must not > verify the values match. If the node joining the group can't support the > values for the multicast group, then it should log the error. That way, a > future RFC could describe why/when/how a node would choose to use > different values for the link attributes but still be able to interoperate > with IPoIB nodes. That is a valid idea. The other alternative is to list the parameters that may differ from the ones used by the broadcast-GID. The parameters for an IB multicast group are: Q_Key, MLID, MTU, TClass, P_Key, Rate, SL, PacketLifeTime, FlowLabel, Hoplimit, scope. We certainly need the P_Key and MTU to be the same as the broadcast MGID. Similarly all multicast mappings in a subnet must have the same 'scope'. The other parameters can be different if it is ensured that they are all supported by all the members of the IP subnet. There is no well defined method of ensuring this - none is being defined by us. On the other had, by definition all members support the parameters supported by the broadcast-GID. Therefore I agree with you... Jerry, I think we should change the draft to state the following about the parameters: 1. unicast communication use the parameters used by broadcast-GID 2. multicast GIDs created should use the same parameters as the broadcast-GID. Vivek > > Roy > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue May 6 19:22:31 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 TAA13834 for ; Tue, 6 May 2003 19:22:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46NU3807163; Tue, 6 May 2003 19:30:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46NTN807127 for ; Tue, 6 May 2003 19:29:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13760 for ; Tue, 6 May 2003 19:20:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DBlI-0003N4-00 for ipoverib@ietf.org; Tue, 06 May 2003 19:22:16 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19DBlH-0003N0-00 for ipoverib@ietf.org; Tue, 06 May 2003 19:22:15 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h46NMZkc252304; Tue, 6 May 2003 19:22:35 -0400 Received: from w-vkashyap95.des.sequent.com (d03av01.boulder.ibm.com [9.17.193.81]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h46NMYuk080922; Tue, 6 May 2003 17:22:35 -0600 Date: Tue, 6 May 2003 16:19:33 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Kanoj Sarcar cc: ipoverib@ietf.org Subject: Re: [Ipoverib] DHCP clarification In-Reply-To: <3E937048.564A18C7@Sun.COM> Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, How about the following: 2.2 Use of the BROADCAST flag A DHCP client on IPoIB MUST set the BROADCAST flag and set 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages when it is not in BOUND or RENEWING states. This ensures that the server (or the relay agent) broadcasts its reply to the client. In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be filled in with the client's IP address [RFC2131]. The BROADCAST flag MUST NOT be set in these cases since the DHCP server, after resolving the 'ciaddr' address using ARP, unicasts the DHCPACK message to the client. Vivek > Hi, > > While going over section 2 of ipoib/dhcp draft, I realized that it > can be cleaned up somewhat (in my opinion, ie; to others, it might > be quite clear already). Accordingly, I came up with the following > verbiage. If there are some improvements in here, it should be used > to reword the section. > > 2.2 Use of the BROADCAST flag > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > set 'ciaddr' to zero) in DHCPREQUEST messages and > DHCPDISCOVER messages sent when it is not in the BOUND > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > states). > > For other cases, the client SHOULD NOT set the BROADCAST > flag if it can receive the server's unicast responses. > As described in [RFC2131], 'ciaddr' MUST be filled in > with client's IP address during BOUND, RENEWING or > REBINDING states. In these cases, > the DHCP server attempts to unicast DHCP responses to > the address filled in by the client in 'ciaddr' by using > IPoIB ARP to resolve the link address. > > The reason I think this is clearer is because: > 1. It makes it clear that the BROADCAST flag has to be set in > DHCPDISCOVER. > 2. It makes it clear that the BROADCAST flag needs to be set > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > 3. It allows that servers might broadcast responses > (allowed per 2131, see last paragraph section 4.1). > 4. It allows that servers might respond with DHCPNAK. > 5. It allows that there might be other reasons for clients to > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > 6. It does not make it illegal for clients to set BROADCAST bit > for whatever other reason. Unless there is a good reason (other > than known issues) to make it illegal, I am not sure if this > was intended. I could not find any MUST NOT reference wrt BROADCAST > bit in 2131. > > Thanks. > > Kanoj > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue May 6 19:22:32 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 TAA13848 for ; Tue, 6 May 2003 19:22:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46NVE607244 for ipoverib-archive@odin.ietf.org; Tue, 6 May 2003 19:31:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46NVE807241 for ; Tue, 6 May 2003 19:31:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13823 for ; Tue, 6 May 2003 19:22:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DBn5-0003Og-00 for ipoverib-web-archive@ietf.org; Tue, 06 May 2003 19:24:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DBn4-0003Od-00 for ipoverib-web-archive@ietf.org; Tue, 06 May 2003 19:24:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46NU3807163; Tue, 6 May 2003 19:30:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46NTN807127 for ; Tue, 6 May 2003 19:29:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13760 for ; Tue, 6 May 2003 19:20:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DBlI-0003N4-00 for ipoverib@ietf.org; Tue, 06 May 2003 19:22:16 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19DBlH-0003N0-00 for ipoverib@ietf.org; Tue, 06 May 2003 19:22:15 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h46NMZkc252304; Tue, 6 May 2003 19:22:35 -0400 Received: from w-vkashyap95.des.sequent.com (d03av01.boulder.ibm.com [9.17.193.81]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h46NMYuk080922; Tue, 6 May 2003 17:22:35 -0600 Date: Tue, 6 May 2003 16:19:33 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Kanoj Sarcar cc: ipoverib@ietf.org Subject: Re: [Ipoverib] DHCP clarification In-Reply-To: <3E937048.564A18C7@Sun.COM> Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, How about the following: 2.2 Use of the BROADCAST flag A DHCP client on IPoIB MUST set the BROADCAST flag and set 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages when it is not in BOUND or RENEWING states. This ensures that the server (or the relay agent) broadcasts its reply to the client. In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be filled in with the client's IP address [RFC2131]. The BROADCAST flag MUST NOT be set in these cases since the DHCP server, after resolving the 'ciaddr' address using ARP, unicasts the DHCPACK message to the client. Vivek > Hi, > > While going over section 2 of ipoib/dhcp draft, I realized that it > can be cleaned up somewhat (in my opinion, ie; to others, it might > be quite clear already). Accordingly, I came up with the following > verbiage. If there are some improvements in here, it should be used > to reword the section. > > 2.2 Use of the BROADCAST flag > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > set 'ciaddr' to zero) in DHCPREQUEST messages and > DHCPDISCOVER messages sent when it is not in the BOUND > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > states). > > For other cases, the client SHOULD NOT set the BROADCAST > flag if it can receive the server's unicast responses. > As described in [RFC2131], 'ciaddr' MUST be filled in > with client's IP address during BOUND, RENEWING or > REBINDING states. In these cases, > the DHCP server attempts to unicast DHCP responses to > the address filled in by the client in 'ciaddr' by using > IPoIB ARP to resolve the link address. > > The reason I think this is clearer is because: > 1. It makes it clear that the BROADCAST flag has to be set in > DHCPDISCOVER. > 2. It makes it clear that the BROADCAST flag needs to be set > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > 3. It allows that servers might broadcast responses > (allowed per 2131, see last paragraph section 4.1). > 4. It allows that servers might respond with DHCPNAK. > 5. It allows that there might be other reasons for clients to > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > 6. It does not make it illegal for clients to set BROADCAST bit > for whatever other reason. Unless there is a good reason (other > than known issues) to make it illegal, I am not sure if this > was intended. I could not find any MUST NOT reference wrt BROADCAST > bit in 2131. > > Thanks. > > Kanoj > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue May 6 20:47:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15771 for ; Tue, 6 May 2003 20:47:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h470t8813608; Tue, 6 May 2003 20:55:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h470sx813583 for ; Tue, 6 May 2003 20:54:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15737 for ; Tue, 6 May 2003 20:45:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DD66-0003ub-00 for ipoverib@ietf.org; Tue, 06 May 2003 20:47:50 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19DD65-0003uY-00 for ipoverib@ietf.org; Tue, 06 May 2003 20:47:49 -0400 Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h470m9PH008518; Tue, 6 May 2003 17:48:10 -0700 (PDT) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h470m9Kw001693; Tue, 6 May 2003 17:48:09 -0700 (PDT) Received: from Sun.COM (sr1-usun-06.Eng.Sun.COM [129.144.135.9]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0HEH00MU7RK9O5@ha1sun-mail1.eng.sun.com>; Tue, 06 May 2003 17:48:09 -0700 (PDT) Date: Tue, 06 May 2003 17:48:09 -0700 From: Kanoj Sarcar Subject: Re: [Ipoverib] DHCP clarification To: Vivek Kashyap Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3EB857C9.3CEE9AA5@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 Vivek, The wording sounds fine; although I am uncomfortable with the "MUST NOT set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST NOT restriction required? RFC 2131 leaves the setting of this flag to the client (as far as I can tell; unless you can quote a specific section that implies otherwise). Are you worried about servers that might get confused with the BROADCAST bit in BOUND/RENEWING/REBINDING clients? Thanks. Kanoj Vivek Kashyap wrote: > > Kanoj, > > How about the following: > > 2.2 Use of the BROADCAST flag > > A DHCP client on IPoIB MUST set the BROADCAST flag and set > 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages > when it is not in BOUND or RENEWING states. This ensures that > the server (or the relay agent) broadcasts its reply to > the client. > > In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be > filled in with the client's IP address [RFC2131]. The > BROADCAST flag MUST NOT be set in these cases since the DHCP > server, after resolving the 'ciaddr' address using ARP, > unicasts the DHCPACK message to the client. > > Vivek > > > Hi, > > > > While going over section 2 of ipoib/dhcp draft, I realized that it > > can be cleaned up somewhat (in my opinion, ie; to others, it might > > be quite clear already). Accordingly, I came up with the following > > verbiage. If there are some improvements in here, it should be used > > to reword the section. > > > > 2.2 Use of the BROADCAST flag > > > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > > set 'ciaddr' to zero) in DHCPREQUEST messages and > > DHCPDISCOVER messages sent when it is not in the BOUND > > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > > states). > > > > For other cases, the client SHOULD NOT set the BROADCAST > > flag if it can receive the server's unicast responses. > > As described in [RFC2131], 'ciaddr' MUST be filled in > > with client's IP address during BOUND, RENEWING or > > REBINDING states. In these cases, > > the DHCP server attempts to unicast DHCP responses to > > the address filled in by the client in 'ciaddr' by using > > IPoIB ARP to resolve the link address. > > > > The reason I think this is clearer is because: > > 1. It makes it clear that the BROADCAST flag has to be set in > > DHCPDISCOVER. > > 2. It makes it clear that the BROADCAST flag needs to be set > > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > > 3. It allows that servers might broadcast responses > > (allowed per 2131, see last paragraph section 4.1). > > 4. It allows that servers might respond with DHCPNAK. > > 5. It allows that there might be other reasons for clients to > > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > > 6. It does not make it illegal for clients to set BROADCAST bit > > for whatever other reason. Unless there is a good reason (other > > than known issues) to make it illegal, I am not sure if this > > was intended. I could not find any MUST NOT reference wrt BROADCAST > > bit in 2131. > > > > Thanks. > > > > Kanoj > > _______________________________________________ > > IPoverIB mailing list > > IPoverIB@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > __ > > Vivek Kashyap > Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue May 6 20:47: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 UAA15785 for ; Tue, 6 May 2003 20:47:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h470uS613672 for ipoverib-archive@odin.ietf.org; Tue, 6 May 2003 20:56:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h470uS813669 for ; Tue, 6 May 2003 20:56:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15757 for ; Tue, 6 May 2003 20:47:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DD7X-0003vA-00 for ipoverib-web-archive@ietf.org; Tue, 06 May 2003 20:49:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DD7W-0003v7-00 for ipoverib-web-archive@ietf.org; Tue, 06 May 2003 20:49:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h470t8813608; Tue, 6 May 2003 20:55:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h470sx813583 for ; Tue, 6 May 2003 20:54:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15737 for ; Tue, 6 May 2003 20:45:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DD66-0003ub-00 for ipoverib@ietf.org; Tue, 06 May 2003 20:47:50 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19DD65-0003uY-00 for ipoverib@ietf.org; Tue, 06 May 2003 20:47:49 -0400 Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h470m9PH008518; Tue, 6 May 2003 17:48:10 -0700 (PDT) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h470m9Kw001693; Tue, 6 May 2003 17:48:09 -0700 (PDT) Received: from Sun.COM (sr1-usun-06.Eng.Sun.COM [129.144.135.9]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0HEH00MU7RK9O5@ha1sun-mail1.eng.sun.com>; Tue, 06 May 2003 17:48:09 -0700 (PDT) Date: Tue, 06 May 2003 17:48:09 -0700 From: Kanoj Sarcar Subject: Re: [Ipoverib] DHCP clarification To: Vivek Kashyap Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3EB857C9.3CEE9AA5@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 Vivek, The wording sounds fine; although I am uncomfortable with the "MUST NOT set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST NOT restriction required? RFC 2131 leaves the setting of this flag to the client (as far as I can tell; unless you can quote a specific section that implies otherwise). Are you worried about servers that might get confused with the BROADCAST bit in BOUND/RENEWING/REBINDING clients? Thanks. Kanoj Vivek Kashyap wrote: > > Kanoj, > > How about the following: > > 2.2 Use of the BROADCAST flag > > A DHCP client on IPoIB MUST set the BROADCAST flag and set > 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages > when it is not in BOUND or RENEWING states. This ensures that > the server (or the relay agent) broadcasts its reply to > the client. > > In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be > filled in with the client's IP address [RFC2131]. The > BROADCAST flag MUST NOT be set in these cases since the DHCP > server, after resolving the 'ciaddr' address using ARP, > unicasts the DHCPACK message to the client. > > Vivek > > > Hi, > > > > While going over section 2 of ipoib/dhcp draft, I realized that it > > can be cleaned up somewhat (in my opinion, ie; to others, it might > > be quite clear already). Accordingly, I came up with the following > > verbiage. If there are some improvements in here, it should be used > > to reword the section. > > > > 2.2 Use of the BROADCAST flag > > > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > > set 'ciaddr' to zero) in DHCPREQUEST messages and > > DHCPDISCOVER messages sent when it is not in the BOUND > > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > > states). > > > > For other cases, the client SHOULD NOT set the BROADCAST > > flag if it can receive the server's unicast responses. > > As described in [RFC2131], 'ciaddr' MUST be filled in > > with client's IP address during BOUND, RENEWING or > > REBINDING states. In these cases, > > the DHCP server attempts to unicast DHCP responses to > > the address filled in by the client in 'ciaddr' by using > > IPoIB ARP to resolve the link address. > > > > The reason I think this is clearer is because: > > 1. It makes it clear that the BROADCAST flag has to be set in > > DHCPDISCOVER. > > 2. It makes it clear that the BROADCAST flag needs to be set > > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > > 3. It allows that servers might broadcast responses > > (allowed per 2131, see last paragraph section 4.1). > > 4. It allows that servers might respond with DHCPNAK. > > 5. It allows that there might be other reasons for clients to > > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > > 6. It does not make it illegal for clients to set BROADCAST bit > > for whatever other reason. Unless there is a good reason (other > > than known issues) to make it illegal, I am not sure if this > > was intended. I could not find any MUST NOT reference wrt BROADCAST > > bit in 2131. > > > > Thanks. > > > > Kanoj > > _______________________________________________ > > IPoverIB mailing list > > IPoverIB@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > __ > > Vivek Kashyap > Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed May 7 00:55: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 AAA20584 for ; Wed, 7 May 2003 00:55:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4753F830807; Wed, 7 May 2003 01:03:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4752L830759 for ; Wed, 7 May 2003 01:02:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20570 for ; Wed, 7 May 2003 00:53:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DGxP-00057i-00 for ipoverib@ietf.org; Wed, 07 May 2003 00:55:07 -0400 Received: from kathmandu.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 19DGxO-00057d-00 for ipoverib@ietf.org; Wed, 07 May 2003 00:55:06 -0400 Received: from jurassic.eng.sun.com ([129.146.85.31]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA03636; Tue, 6 May 2003 22:55:58 -0600 (MDT) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h474tvKQ721750; Tue, 6 May 2003 21:55:57 -0700 (PDT) Message-Id: <200305070455.h474tvKQ721750@jurassic.eng.sun.com> Date: Tue, 6 May 2003 21:55:58 -0700 (PDT) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: rbrabson@us.ibm.com Cc: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XWjbzsIq1HbQ99chIKEzYg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc 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: , >> >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > >> > connected routers. [snip] The specific mechanism for a sender to >> > forward packets to routers are left to implementations". At a >> > minimum, I think the exact implementation needs to be specified. >> >> Why? (The draft strives to avoid dictating implementation details that >> do not affect interoperability.) > >For interoperatibilty. The requirement is the host and router must agree >on using a common mechanism for exchanging the IP multicast packet. >Implementations are free to choose a mechanism as long as all other >implementations with which they communicate also choose to implement the >same mechanism. I don't think this is an area where we can or should punt >- a minimal, common approach needs to be mandated such that all IPoIB >nodes implement that mechanism so that any two IPoIB nodes will >interoperate. I still don't see any problem you may have in mind. As long as a sender gets the pkt to the router, why it matter how it gets there? E.g., routers will listen to both the broadcast and the all-router multicast addresses. Does it matter which address a pkt is sent to? > >> > The >> > text suggests using all-router multicast group or the broadcast >group. >> > If a router is required to create the all-router multicast group (see > >> > the previous comment), then wouldn't it be sufficient to check for >the >> > existence of the all-router multicast group and, if it exists, send >to >> > that? If it doesn't exist, then there can't be any multicast routers > >> > on the link, and since there aren't any local listeners there are no >> > on-link listeners there isn't any need to send the packet. >> >> Don't the code sinppet following 9.B match pretty much what you >described >> above? > >Yes, it does, and if the text matched the code snippet then I wouldn't >have an issue. But the text which supports the code snippet doesn't. I can remove the text if it causes any confusion. I thought it is very obvious if no router exists then there is no need to forward (as illustrated by the code snippet). >The >text basically says you could send to the all-router multicast group OR >the broadcast group. And either should work, as long as the receiving >IPoIB node MUST accept the IP multicast packets regardless of the IB group >over which they are received (I'm not sure I've seen this explicitly >stated in the draft, but I may have missed it). I thought this is required by IP already. But please tell me if I'm wrong. >But do we really need to >have multiple mechanisms to accomplish the same result? Wouldn't we be >better off just choosing one and going with that? And how are we going to >find multiple interoperable implementations for each option when the draft >puts no limits on the approaches which can be taken? The multiple mechanisms were not there in the earlier draft, but were requested later by my co-author. I personally don't see any harm with it but I don't mind taking it out if Vivek agrees with you. > >> > >> > And shouldn't the IPoIB sender subscribe to the IB multicast group >> > creation events using a wildcard MGID so that it can >> > "SendOnlyNonMember" join the group if a listener appears on the local > >> > IB subnet, or "SendOnlyNonMember" join the all-routers group if a >> > router appears on-link and creates the all-routers multicast group? >> > And doesn't it need to subscribe to the IB multicast group deletion >> > events so that it knows when to switch back to sending to the >> > all-router multicast group and/or stop sending? >> >> Aren't you saying the same thing (more or less) as what is described in >> the section following the code snippet? > >You are right - I must have missed the text. But you need to change the >"should" to a "MUST" in that paragraph. Since the caching part is a "should", the subscription part ought to be a "should" too, right? > >> > >> > But I'm wondering why a node needs to do this at all. Wouldn't it >> > make more sense for the IPoIB node instead create the multicast group > >> > and join the group so that IPoIB multicast routers can join the >group? >> > Yes, the IPoIB sender will need create the group as a "FullMember", >> > but this seems to provide a simpler mapping of IP multicast to IB >> > multicast. >> >> While what you suggested may simplify the procedure, it essentially >> removes the difference between a multicast sender and a multicast >receiver, >> which is wrong. In the IP multicast model a multicast sender doesn't >need >> to be a member of a multicast group to send. The draft has tried to >> keep the same distinction. > >However, you are mapping the IP multicast model to the IB multicast model, >and the two are not the same. The reality is a sender must join an IB >multicast group in order to send to it (albeit as a "SendOnlyNonMember"), This is the big difference that was debated in IBTA. >and this step does not exist in the IP model. I imagine that the vast >majority of the code/complexity of an IPoIB implementation is going to be >dealing with IB multicasting. I was hoping there was some way to reduce >both at an IPoIB host. Maybe it is just wishful thinking. I actually have the same philosophy as well. I'm always against complexity unless it's fully justified. But IB multicast just works differently than IP multicast. We have gone through a number of alternatives and the current one seemed to a good balance between complexity and correctness. I don't remember all the tradeoffs but if we simply require a sender to be a full-member, how would one know when to leave a group, when to delete a group..., etc. Also wouldn't it enable anyone to write a silly sender program to try to send to a million different addresses and cause all the IB multicast resources to be used up? (The join call by IP_ADD_MEMBERSHIP at least places some resource limitation.) > >By the way, after thinking about this a little more, I'm not sure that >creating a group as I suggested makes sense in all cases. For instance, >it is only useful for an IP multicast group which has a scope greater than >link-local. For link-local scope, only nodes directly attached to the >IPoIB link are able to receive the packet. Creating the group for the >purpose of forwarding to an IPoIB multicast router is simply wasteful, as >the IPoIB multicast router will not be able to forward the packet to >another IP link. > >A similar optimization can also be taken with the current approach >described in this draft - for an IP multicast group with link-local scope, >if the IB MGID for that IP multicast group does not exist then an IPoIB >node really doesn't need to send the multicast packet to the all-router >MGID or broadcast GID. Correct. This level of details can arguably be left to implementation because it doesn't affect interoperability. But I think this optimization is simple and useful enough that I'll add a note to the draft. > >> >- Section 9.0 also indicates that "A multicast sender must join the >> > target multicast group as a "SendOnlyNonMember" before outgoing >> > messages from it can be successfully routed." This text should be >> > clarified to indicate this is only true if the node has not already >> > joined the group as either a "FullMember" or "SendOnlyNonMember". The > >> > If-Then-Else logic below correctly shows this behavior, but this >> > paragraph does not reflect that behavior. >> >> Although your comment is correct, I'd argue this kind of details can >> be found in the IBA spec. It has nothing to do with IPoIB in particular, >> So the question becomes how much IBA info we need to repeat in an IPoIB >RFC. >> Since the code sippet already covers this correctly, if you still >believe >> this needs to be clarified i can certain add more text to it. > >My feeling is enough to describe HOW an IPoIB node will USE the IBA >services, and this is one of those cases. I would prefer to see the text >clarified if you do another revision of the draft, but given the code >snippet describes the correct behavior I wouldn't hold this draft up just >to clarify this paragraph. Ok. > >> >- Section 9.0 indicates that "For the rest of attributes, it is >> > recommended the same values from the all-node multicast/broadcast >> > group be used." Should this instead say "For the rest of the >> > attributes, the same values from the all-node multicast/broadcast >> > group SHOULD be used." Regardless of the wording, this text seems to >> > contradict the Section 7.0 which states a node must "use the rest of >> > the link attributes associated with the group for all future >> > communication on the link. If Section 7.0 is correct, should this be > >> > a MUST instead of a SHOULD? And, if not, under what circumstances >> > would a node choose to not use the same values? >> >> 7.0 describes the attributes used by a node when conducting unicast >> communication. 9.0 describes the attributes used to create a multicast >> group, i.e., for multicast communication. So the question is: >> Must path attributes used for unicast match with those for multicast? >> >> The flexibility allowed in the multicast case in the current draft is >> deliberate. I don't know in reality if this is useful, or even good to >> have. (Comments are welcome.) My design principle has been to not to >> make something a requirement unless it is needed for interoperability. > >Flexibility is often times good, but so is describing a minimal set of >functions necessary for interoperability. If a node selects link >attributes when creating an MGID which does not match the broadcast GID's >attributes, then it is possible that not all nodes which are members of >the IPoIB link will be able to support those attributes. If this happens, >then the two nodes will not be able to communicate using the IP multicast >group mapped to the MGID. All of a sudden, an IPoIB node can't send an >ARP request or Neighbor Solicitation to another node. I think some of these "deliberate" flexibility (or ambuguity) came from the ambuguity of IB itself in some of the mutlicast attributes such as SL, TClass..., etc. It is not clear to me if they must or even can follow the ones for unicast (i.e. described by the broadcast group) in all cases. > >Perhaps it would be better to state that a node which creates a multicast >group MUST use the same values for the attributes as the all-node >multicast/broadcast group, but a node joining a multicast group must not >verify the values match. If the node joining the group can't support the >values for the multicast group, then it should log the error. That way, a >future RFC could describe why/when/how a node would choose to use >different values for the link attributes but still be able to interoperate >with IPoIB nodes. I'll leave the above for IB folks to comment. Jerry > >Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed May 7 00:55:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20598 for ; Wed, 7 May 2003 00:55:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4754DX30857 for ipoverib-archive@odin.ietf.org; Wed, 7 May 2003 01:04:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4754D830854 for ; Wed, 7 May 2003 01:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20578 for ; Wed, 7 May 2003 00:54:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DGzC-00057w-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 00:56:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DGzC-00057t-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 00:56:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4753F830807; Wed, 7 May 2003 01:03:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4752L830759 for ; Wed, 7 May 2003 01:02:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20570 for ; Wed, 7 May 2003 00:53:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DGxP-00057i-00 for ipoverib@ietf.org; Wed, 07 May 2003 00:55:07 -0400 Received: from kathmandu.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 19DGxO-00057d-00 for ipoverib@ietf.org; Wed, 07 May 2003 00:55:06 -0400 Received: from jurassic.eng.sun.com ([129.146.85.31]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA03636; Tue, 6 May 2003 22:55:58 -0600 (MDT) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h474tvKQ721750; Tue, 6 May 2003 21:55:57 -0700 (PDT) Message-Id: <200305070455.h474tvKQ721750@jurassic.eng.sun.com> Date: Tue, 6 May 2003 21:55:58 -0700 (PDT) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: rbrabson@us.ibm.com Cc: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XWjbzsIq1HbQ99chIKEzYg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc 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: , >> >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > >> > connected routers. [snip] The specific mechanism for a sender to >> > forward packets to routers are left to implementations". At a >> > minimum, I think the exact implementation needs to be specified. >> >> Why? (The draft strives to avoid dictating implementation details that >> do not affect interoperability.) > >For interoperatibilty. The requirement is the host and router must agree >on using a common mechanism for exchanging the IP multicast packet. >Implementations are free to choose a mechanism as long as all other >implementations with which they communicate also choose to implement the >same mechanism. I don't think this is an area where we can or should punt >- a minimal, common approach needs to be mandated such that all IPoIB >nodes implement that mechanism so that any two IPoIB nodes will >interoperate. I still don't see any problem you may have in mind. As long as a sender gets the pkt to the router, why it matter how it gets there? E.g., routers will listen to both the broadcast and the all-router multicast addresses. Does it matter which address a pkt is sent to? > >> > The >> > text suggests using all-router multicast group or the broadcast >group. >> > If a router is required to create the all-router multicast group (see > >> > the previous comment), then wouldn't it be sufficient to check for >the >> > existence of the all-router multicast group and, if it exists, send >to >> > that? If it doesn't exist, then there can't be any multicast routers > >> > on the link, and since there aren't any local listeners there are no >> > on-link listeners there isn't any need to send the packet. >> >> Don't the code sinppet following 9.B match pretty much what you >described >> above? > >Yes, it does, and if the text matched the code snippet then I wouldn't >have an issue. But the text which supports the code snippet doesn't. I can remove the text if it causes any confusion. I thought it is very obvious if no router exists then there is no need to forward (as illustrated by the code snippet). >The >text basically says you could send to the all-router multicast group OR >the broadcast group. And either should work, as long as the receiving >IPoIB node MUST accept the IP multicast packets regardless of the IB group >over which they are received (I'm not sure I've seen this explicitly >stated in the draft, but I may have missed it). I thought this is required by IP already. But please tell me if I'm wrong. >But do we really need to >have multiple mechanisms to accomplish the same result? Wouldn't we be >better off just choosing one and going with that? And how are we going to >find multiple interoperable implementations for each option when the draft >puts no limits on the approaches which can be taken? The multiple mechanisms were not there in the earlier draft, but were requested later by my co-author. I personally don't see any harm with it but I don't mind taking it out if Vivek agrees with you. > >> > >> > And shouldn't the IPoIB sender subscribe to the IB multicast group >> > creation events using a wildcard MGID so that it can >> > "SendOnlyNonMember" join the group if a listener appears on the local > >> > IB subnet, or "SendOnlyNonMember" join the all-routers group if a >> > router appears on-link and creates the all-routers multicast group? >> > And doesn't it need to subscribe to the IB multicast group deletion >> > events so that it knows when to switch back to sending to the >> > all-router multicast group and/or stop sending? >> >> Aren't you saying the same thing (more or less) as what is described in >> the section following the code snippet? > >You are right - I must have missed the text. But you need to change the >"should" to a "MUST" in that paragraph. Since the caching part is a "should", the subscription part ought to be a "should" too, right? > >> > >> > But I'm wondering why a node needs to do this at all. Wouldn't it >> > make more sense for the IPoIB node instead create the multicast group > >> > and join the group so that IPoIB multicast routers can join the >group? >> > Yes, the IPoIB sender will need create the group as a "FullMember", >> > but this seems to provide a simpler mapping of IP multicast to IB >> > multicast. >> >> While what you suggested may simplify the procedure, it essentially >> removes the difference between a multicast sender and a multicast >receiver, >> which is wrong. In the IP multicast model a multicast sender doesn't >need >> to be a member of a multicast group to send. The draft has tried to >> keep the same distinction. > >However, you are mapping the IP multicast model to the IB multicast model, >and the two are not the same. The reality is a sender must join an IB >multicast group in order to send to it (albeit as a "SendOnlyNonMember"), This is the big difference that was debated in IBTA. >and this step does not exist in the IP model. I imagine that the vast >majority of the code/complexity of an IPoIB implementation is going to be >dealing with IB multicasting. I was hoping there was some way to reduce >both at an IPoIB host. Maybe it is just wishful thinking. I actually have the same philosophy as well. I'm always against complexity unless it's fully justified. But IB multicast just works differently than IP multicast. We have gone through a number of alternatives and the current one seemed to a good balance between complexity and correctness. I don't remember all the tradeoffs but if we simply require a sender to be a full-member, how would one know when to leave a group, when to delete a group..., etc. Also wouldn't it enable anyone to write a silly sender program to try to send to a million different addresses and cause all the IB multicast resources to be used up? (The join call by IP_ADD_MEMBERSHIP at least places some resource limitation.) > >By the way, after thinking about this a little more, I'm not sure that >creating a group as I suggested makes sense in all cases. For instance, >it is only useful for an IP multicast group which has a scope greater than >link-local. For link-local scope, only nodes directly attached to the >IPoIB link are able to receive the packet. Creating the group for the >purpose of forwarding to an IPoIB multicast router is simply wasteful, as >the IPoIB multicast router will not be able to forward the packet to >another IP link. > >A similar optimization can also be taken with the current approach >described in this draft - for an IP multicast group with link-local scope, >if the IB MGID for that IP multicast group does not exist then an IPoIB >node really doesn't need to send the multicast packet to the all-router >MGID or broadcast GID. Correct. This level of details can arguably be left to implementation because it doesn't affect interoperability. But I think this optimization is simple and useful enough that I'll add a note to the draft. > >> >- Section 9.0 also indicates that "A multicast sender must join the >> > target multicast group as a "SendOnlyNonMember" before outgoing >> > messages from it can be successfully routed." This text should be >> > clarified to indicate this is only true if the node has not already >> > joined the group as either a "FullMember" or "SendOnlyNonMember". The > >> > If-Then-Else logic below correctly shows this behavior, but this >> > paragraph does not reflect that behavior. >> >> Although your comment is correct, I'd argue this kind of details can >> be found in the IBA spec. It has nothing to do with IPoIB in particular, >> So the question becomes how much IBA info we need to repeat in an IPoIB >RFC. >> Since the code sippet already covers this correctly, if you still >believe >> this needs to be clarified i can certain add more text to it. > >My feeling is enough to describe HOW an IPoIB node will USE the IBA >services, and this is one of those cases. I would prefer to see the text >clarified if you do another revision of the draft, but given the code >snippet describes the correct behavior I wouldn't hold this draft up just >to clarify this paragraph. Ok. > >> >- Section 9.0 indicates that "For the rest of attributes, it is >> > recommended the same values from the all-node multicast/broadcast >> > group be used." Should this instead say "For the rest of the >> > attributes, the same values from the all-node multicast/broadcast >> > group SHOULD be used." Regardless of the wording, this text seems to >> > contradict the Section 7.0 which states a node must "use the rest of >> > the link attributes associated with the group for all future >> > communication on the link. If Section 7.0 is correct, should this be > >> > a MUST instead of a SHOULD? And, if not, under what circumstances >> > would a node choose to not use the same values? >> >> 7.0 describes the attributes used by a node when conducting unicast >> communication. 9.0 describes the attributes used to create a multicast >> group, i.e., for multicast communication. So the question is: >> Must path attributes used for unicast match with those for multicast? >> >> The flexibility allowed in the multicast case in the current draft is >> deliberate. I don't know in reality if this is useful, or even good to >> have. (Comments are welcome.) My design principle has been to not to >> make something a requirement unless it is needed for interoperability. > >Flexibility is often times good, but so is describing a minimal set of >functions necessary for interoperability. If a node selects link >attributes when creating an MGID which does not match the broadcast GID's >attributes, then it is possible that not all nodes which are members of >the IPoIB link will be able to support those attributes. If this happens, >then the two nodes will not be able to communicate using the IP multicast >group mapped to the MGID. All of a sudden, an IPoIB node can't send an >ARP request or Neighbor Solicitation to another node. I think some of these "deliberate" flexibility (or ambuguity) came from the ambuguity of IB itself in some of the mutlicast attributes such as SL, TClass..., etc. It is not clear to me if they must or even can follow the ones for unicast (i.e. described by the broadcast group) in all cases. > >Perhaps it would be better to state that a node which creates a multicast >group MUST use the same values for the attributes as the all-node >multicast/broadcast group, but a node joining a multicast group must not >verify the values match. If the node joining the group can't support the >values for the multicast group, then it should log the error. That way, a >future RFC could describe why/when/how a node would choose to use >different values for the link attributes but still be able to interoperate >with IPoIB nodes. I'll leave the above for IB folks to comment. Jerry > >Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed May 7 09:13:28 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 JAA29340 for ; Wed, 7 May 2003 09:13:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47DKK814994; Wed, 7 May 2003 09:20:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47DJF814922 for ; Wed, 7 May 2003 09:19:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29181 for ; Wed, 7 May 2003 09:09:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DOi6-00012a-00 for ipoverib@ietf.org; Wed, 07 May 2003 09:11:50 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19DOi5-00012U-00 for ipoverib@ietf.org; Wed, 07 May 2003 09:11:49 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47DCAYp219750; Wed, 7 May 2003 09:12:10 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47DC9no140368; Wed, 7 May 2003 07:12:10 -0600 In-Reply-To: To: kashyapv@us.ibm.com Cc: ipoverib@ietf.org, "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 09:12:05 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 09:12:05 AM, Serialize complete at 05/07/2003 09:12:05 AM, S/MIME Sign failed at 05/07/2003 09:12:05 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/07/2003 07:12:09, Serialize complete at 05/07/2003 07:12:09 Message-ID: Date: Wed, 7 May 2003 09:12:08 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > > For interoperatibilty. The requirement is the host and router must agree > > on using a common mechanism for exchanging the IP multicast packet. > > Implementations are free to choose a mechanism as long as all other > > implementations with which they communicate also choose to implement the > > same mechanism. I don't think this is an area where we can or should punt > > - a minimal, common approach needs to be mandated such that all IPoIB > > nodes implement that mechanism so that any two IPoIB nodes will > > interoperate. > > Roy, > > Yes, I agree that a common method must be described for interoperability. > Though, in this case, even with the flexibility > interoperability is maintained - the onus being on the router : > > The packet may be sent to the routers on broadcast-GID or the > all-router GID. The router itself will listen on both - > broadcast-GID since it is required by IPoIB and all-routers as a > result of other specs (IPv6 & IGMP). Therefore the packet will be > received by the router irrespective of the MGID used as long as > the router accepts any multicast packets on these MGIDs. I have > described the need for this in my previous reply. > > > We could do one of three things when the relevant MGID does not > exist: > > 1. The host must always forward on broadcast MGID > and the router must always accept IP multicast packets on the > broadcast GID. > > 2. The host must always forward on all-router MGID and the router > must always accept IP multicast packets on the all-router > MGID > > 3. The host must always forward on broadcast GID or all-router > MGID. The router must accept IP multicast packets on both the > broadcast MGID and all-router MGID. > > > We have chosen case 3 . Is there a strong feeling that one of the > other cases is preferable? > > It appears that the method chosen(case 3) needs to be > explicitly stated in the draft. My preference is for case 2, as sending to the all-router MGID reduces the amount of multicast traffic an IPoIB host must filter as oppposed to sending to the broadcast GID. I can live with case 3, but if it is chosen would prefer the text to state that the all-router MGID SHOULD be used, but the broadcast GID MAY be used. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed May 7 09:13: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 JAA29354 for ; Wed, 7 May 2003 09:13:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47DMS315148 for ipoverib-archive@odin.ietf.org; Wed, 7 May 2003 09:22:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47DMS815145 for ; Wed, 7 May 2003 09:22:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29324 for ; Wed, 7 May 2003 09:12:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DOlD-00015a-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 09:15:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DOlD-00015X-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 09:15:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47DKK814994; Wed, 7 May 2003 09:20:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47DJF814922 for ; Wed, 7 May 2003 09:19:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29181 for ; Wed, 7 May 2003 09:09:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DOi6-00012a-00 for ipoverib@ietf.org; Wed, 07 May 2003 09:11:50 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19DOi5-00012U-00 for ipoverib@ietf.org; Wed, 07 May 2003 09:11:49 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47DCAYp219750; Wed, 7 May 2003 09:12:10 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47DC9no140368; Wed, 7 May 2003 07:12:10 -0600 In-Reply-To: To: kashyapv@us.ibm.com Cc: ipoverib@ietf.org, "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 09:12:05 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 09:12:05 AM, Serialize complete at 05/07/2003 09:12:05 AM, S/MIME Sign failed at 05/07/2003 09:12:05 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/07/2003 07:12:09, Serialize complete at 05/07/2003 07:12:09 Message-ID: Date: Wed, 7 May 2003 09:12:08 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > > For interoperatibilty. The requirement is the host and router must agree > > on using a common mechanism for exchanging the IP multicast packet. > > Implementations are free to choose a mechanism as long as all other > > implementations with which they communicate also choose to implement the > > same mechanism. I don't think this is an area where we can or should punt > > - a minimal, common approach needs to be mandated such that all IPoIB > > nodes implement that mechanism so that any two IPoIB nodes will > > interoperate. > > Roy, > > Yes, I agree that a common method must be described for interoperability. > Though, in this case, even with the flexibility > interoperability is maintained - the onus being on the router : > > The packet may be sent to the routers on broadcast-GID or the > all-router GID. The router itself will listen on both - > broadcast-GID since it is required by IPoIB and all-routers as a > result of other specs (IPv6 & IGMP). Therefore the packet will be > received by the router irrespective of the MGID used as long as > the router accepts any multicast packets on these MGIDs. I have > described the need for this in my previous reply. > > > We could do one of three things when the relevant MGID does not > exist: > > 1. The host must always forward on broadcast MGID > and the router must always accept IP multicast packets on the > broadcast GID. > > 2. The host must always forward on all-router MGID and the router > must always accept IP multicast packets on the all-router > MGID > > 3. The host must always forward on broadcast GID or all-router > MGID. The router must accept IP multicast packets on both the > broadcast MGID and all-router MGID. > > > We have chosen case 3 . Is there a strong feeling that one of the > other cases is preferable? > > It appears that the method chosen(case 3) needs to be > explicitly stated in the draft. My preference is for case 2, as sending to the all-router MGID reduces the amount of multicast traffic an IPoIB host must filter as oppposed to sending to the broadcast GID. I can live with case 3, but if it is chosen would prefer the text to state that the all-router MGID SHOULD be used, but the broadcast GID MAY be used. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed May 7 09:36: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 JAA00241 for ; Wed, 7 May 2003 09:36:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Di3817383; Wed, 7 May 2003 09:44:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47DhC817315 for ; Wed, 7 May 2003 09:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00167; Wed, 7 May 2003 09:33:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DP5H-0001Fn-00; Wed, 07 May 2003 09:35:47 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19DP5G-0001Eu-00; Wed, 07 May 2003 09:35:46 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47Da5kc290400; Wed, 7 May 2003 09:36:05 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47Da4x8063908; Wed, 7 May 2003 07:36:05 -0600 In-Reply-To: <200305070455.h474tvKQ721750@jurassic.eng.sun.com> To: "H.K. Jerry Chu" Cc: ipoverib@ietf.org, ipoverib-admin@ietf.org Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 09:36:00 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 09:36:00 AM, Serialize complete at 05/07/2003 09:36:00 AM, S/MIME Sign failed at 05/07/2003 09:36:00 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/07/2003 07:36:05, Serialize complete at 05/07/2003 07:36:05 Message-ID: Date: Wed, 7 May 2003 09:36:02 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > >> >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > > > >> > connected routers. [snip] The specific mechanism for a sender to > >> > forward packets to routers are left to implementations". At a > >> > minimum, I think the exact implementation needs to be specified. > >> > >> Why? (The draft strives to avoid dictating implementation details that > >> do not affect interoperability.) > > > >For interoperatibilty. The requirement is the host and router must agree > >on using a common mechanism for exchanging the IP multicast packet. > >Implementations are free to choose a mechanism as long as all other > >implementations with which they communicate also choose to implement the > >same mechanism. I don't think this is an area where we can or should punt > >- a minimal, common approach needs to be mandated such that all IPoIB > >nodes implement that mechanism so that any two IPoIB nodes will > >interoperate. > > I still don't see any problem you may have in mind. As long as a sender > gets the pkt to the router, why it matter how it gets there? E.g., > routers will listen to both the broadcast and the all-router multicast > addresses. Does it matter which address a pkt is sent to? I guess I thought that a receiver might choose to discard IB packets which is sent to the wrong (M)GID. If this isn't possible or allowed by IBA, then you are right - it doesn't matter how a packet arrives at the local QP, just as long as it arrives. So, I guess an alternative to using the all-router MGID or the broadcast GID would be to have an IPoIB host somehow determine all listeners and unicast packets to each listener. Not a real good alternative, but it would work. Even if there are many possible ways to make IPoIB work, we should be choosing the "best" or "most appropriate" one(s) and documenting those. This appears to be sending to the all-router MGID, or possibly the broadcast GID. Why not simply state these are the mechnisms defined by IPoIB, but state that future standards may define additional mechanisms for delivery of multicast packets to the IPoIB router. > > > >> > The > >> > text suggests using all-router multicast group or the broadcast > >group. > >> > If a router is required to create the all-router multicast group (see > > > >> > the previous comment), then wouldn't it be sufficient to check for > >the > >> > existence of the all-router multicast group and, if it exists, send > >to > >> > that? If it doesn't exist, then there can't be any multicast routers > > > >> > on the link, and since there aren't any local listeners there are no > >> > on-link listeners there isn't any need to send the packet. > >> > >> Don't the code sinppet following 9.B match pretty much what you > >described > >> above? > > > >Yes, it does, and if the text matched the code snippet then I wouldn't > >have an issue. But the text which supports the code snippet doesn't. > > I can remove the text if it causes any confusion. I thought it is very > obvious if no router exists then there is no need to forward (as > illustrated by the code snippet). > > >The > >text basically says you could send to the all-router multicast group OR > >the broadcast group. And either should work, as long as the receiving > >IPoIB node MUST accept the IP multicast packets regardless of the IB group > >over which they are received (I'm not sure I've seen this explicitly > >stated in the draft, but I may have missed it). > > I thought this is required by IP already. But please tell me if I'm > wrong. > > >But do we really need to > >have multiple mechanisms to accomplish the same result? Wouldn't we be > >better off just choosing one and going with that? And how are we going to > >find multiple interoperable implementations for each option when the draft > >puts no limits on the approaches which can be taken? > > The multiple mechanisms were not there in the earlier draft, but were > requested later by my co-author. I personally don't see any harm with > it but I don't mind taking it out if Vivek agrees with you. I responded to a separate post from Vivek on this topic. I'm OK if both mechanisms (send to the all-router MGID or broadcast GID) are left in, although I do think the best approach is to send to the all-router MGID. Doing so reduces the amount of traffic which needs to be filtered by IPoIB hosts when there are no on-link listeners. > >> > And shouldn't the IPoIB sender subscribe to the IB multicast group > >> > creation events using a wildcard MGID so that it can > >> > "SendOnlyNonMember" join the group if a listener appears on the local > > > >> > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > >> > router appears on-link and creates the all-routers multicast group? > >> > And doesn't it need to subscribe to the IB multicast group deletion > >> > events so that it knows when to switch back to sending to the > >> > all-router multicast group and/or stop sending? > >> > >> Aren't you saying the same thing (more or less) as what is described in > >> the section following the code snippet? > > > >You are right - I must have missed the text. But you need to change the > >"should" to a "MUST" in that paragraph. > > Since the caching part is a "should", the subscription part ought to be > a "should" too, right? Yes, you are right. Listening for creation/deletion reports doesn't make any sense if the IPoIB node does not cache the MGID for groups which it "NonMember" joins. > >> > But I'm wondering why a node needs to do this at all. Wouldn't it > >> > make more sense for the IPoIB node instead create the multicast group > > > >> > and join the group so that IPoIB multicast routers can join the > >group? > >> > Yes, the IPoIB sender will need create the group as a "FullMember", > >> > but this seems to provide a simpler mapping of IP multicast to IB > >> > multicast. > >> > >> While what you suggested may simplify the procedure, it essentially > >> removes the difference between a multicast sender and a multicast > >receiver, > >> which is wrong. In the IP multicast model a multicast sender doesn't > >need > >> to be a member of a multicast group to send. The draft has tried to > >> keep the same distinction. > > > >However, you are mapping the IP multicast model to the IB multicast model, > >and the two are not the same. The reality is a sender must join an IB > >multicast group in order to send to it (albeit as a "SendOnlyNonMember"), > > This is the big difference that was debated in IBTA. > > >and this step does not exist in the IP model. I imagine that the vast > >majority of the code/complexity of an IPoIB implementation is going to be > >dealing with IB multicasting. I was hoping there was some way to reduce > >both at an IPoIB host. Maybe it is just wishful thinking. > > I actually have the same philosophy as well. I'm always against complexity > unless it's fully justified. But IB multicast just works differently than > IP multicast. We have gone through a number of alternatives and the > current one seemed to a good balance between complexity and correctness. > I don't remember all the tradeoffs but if we simply require a sender > to be a full-member, how would one know when to leave a group, when to > delete a group..., etc. Also wouldn't it enable anyone to write a silly > sender program to try to send to a million different addresses and cause > all the IB multicast resources to be used up? (The join call by > IP_ADD_MEMBERSHIP at least places some resource limitation.) Yes, there are issues which might well make it more complex. As I said, maybe it was wishful thinking. From the sound of it, it was. > >By the way, after thinking about this a little more, I'm not sure that > >creating a group as I suggested makes sense in all cases. For instance, > >it is only useful for an IP multicast group which has a scope greater than > >link-local. For link-local scope, only nodes directly attached to the > >IPoIB link are able to receive the packet. Creating the group for the > >purpose of forwarding to an IPoIB multicast router is simply wasteful, as > >the IPoIB multicast router will not be able to forward the packet to > >another IP link. > > > >A similar optimization can also be taken with the current approach > >described in this draft - for an IP multicast group with link-local scope, > >if the IB MGID for that IP multicast group does not exist then an IPoIB > >node really doesn't need to send the multicast packet to the all-router > >MGID or broadcast GID. > > Correct. This level of details can arguably be left to implementation > because it doesn't affect interoperability. But I think this optimization > is simple and useful enough that I'll add a note to the draft. Sounds good. > > > >> >- Section 9.0 also indicates that "A multicast sender must join the > >> > target multicast group as a "SendOnlyNonMember" before outgoing > >> > messages from it can be successfully routed." This text should be > >> > clarified to indicate this is only true if the node has not already > >> > joined the group as either a "FullMember" or "SendOnlyNonMember". The > > > >> > If-Then-Else logic below correctly shows this behavior, but this > >> > paragraph does not reflect that behavior. > >> > >> Although your comment is correct, I'd argue this kind of details can > >> be found in the IBA spec. It has nothing to do with IPoIB in particular, > >> So the question becomes how much IBA info we need to repeat in an IPoIB > >RFC. > >> Since the code sippet already covers this correctly, if you still > >believe > >> this needs to be clarified i can certain add more text to it. > > > >My feeling is enough to describe HOW an IPoIB node will USE the IBA > >services, and this is one of those cases. I would prefer to see the text > >clarified if you do another revision of the draft, but given the code > >snippet describes the correct behavior I wouldn't hold this draft up just > >to clarify this paragraph. > > Ok. > > > > >> >- Section 9.0 indicates that "For the rest of attributes, it is > >> > recommended the same values from the all-node multicast/broadcast > >> > group be used." Should this instead say "For the rest of the > >> > attributes, the same values from the all-node multicast/broadcast > >> > group SHOULD be used." Regardless of the wording, this text seems to > >> > contradict the Section 7.0 which states a node must "use the rest of > >> > the link attributes associated with the group for all future > >> > communication on the link. If Section 7.0 is correct, should this be > > > >> > a MUST instead of a SHOULD? And, if not, under what circumstances > >> > would a node choose to not use the same values? > >> > >> 7.0 describes the attributes used by a node when conducting unicast > >> communication. 9.0 describes the attributes used to create a multicast > >> group, i.e., for multicast communication. So the question is: > >> Must path attributes used for unicast match with those for multicast? > >> > >> The flexibility allowed in the multicast case in the current draft is > >> deliberate. I don't know in reality if this is useful, or even good to > >> have. (Comments are welcome.) My design principle has been to not to > >> make something a requirement unless it is needed for interoperability. > > > >Flexibility is often times good, but so is describing a minimal set of > >functions necessary for interoperability. If a node selects link > >attributes when creating an MGID which does not match the broadcast GID's > >attributes, then it is possible that not all nodes which are members of > >the IPoIB link will be able to support those attributes. If this happens, > >then the two nodes will not be able to communicate using the IP multicast > >group mapped to the MGID. All of a sudden, an IPoIB node can't send an > >ARP request or Neighbor Solicitation to another node. > > I think some of these "deliberate" flexibility (or ambuguity) came from > the ambuguity of IB itself in some of the mutlicast attributes such as > SL, TClass..., etc. It is not clear to me if they must or even can > follow the ones for unicast (i.e. described by the broadcast group) > in all cases. Well, I hope they can, as that is what I was planning on doing for any MGIDs which I had to create. If they can't, I have no idea how to come up with the appropriate values for the attributes. > >Perhaps it would be better to state that a node which creates a multicast > >group MUST use the same values for the attributes as the all-node > >multicast/broadcast group, but a node joining a multicast group must not > >verify the values match. If the node joining the group can't support the > >values for the multicast group, then it should log the error. That way, a > >future RFC could describe why/when/how a node would choose to use > >different values for the link attributes but still be able to interoperate > >with IPoIB nodes. > > I'll leave the above for IB folks to comment. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed May 7 09:36: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 JAA00257 for ; Wed, 7 May 2003 09:36:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47DjwY17465 for ipoverib-archive@odin.ietf.org; Wed, 7 May 2003 09:45:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Djw817462 for ; Wed, 7 May 2003 09:45:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00238 for ; Wed, 7 May 2003 09:36:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DP7w-0001Gp-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 09:38:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DP7w-0001Gm-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 09:38:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Di3817383; Wed, 7 May 2003 09:44:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47DhC817315 for ; Wed, 7 May 2003 09:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00167; Wed, 7 May 2003 09:33:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DP5H-0001Fn-00; Wed, 07 May 2003 09:35:47 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19DP5G-0001Eu-00; Wed, 07 May 2003 09:35:46 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47Da5kc290400; Wed, 7 May 2003 09:36:05 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47Da4x8063908; Wed, 7 May 2003 07:36:05 -0600 In-Reply-To: <200305070455.h474tvKQ721750@jurassic.eng.sun.com> To: "H.K. Jerry Chu" Cc: ipoverib@ietf.org, ipoverib-admin@ietf.org Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 09:36:00 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 09:36:00 AM, Serialize complete at 05/07/2003 09:36:00 AM, S/MIME Sign failed at 05/07/2003 09:36:00 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/07/2003 07:36:05, Serialize complete at 05/07/2003 07:36:05 Message-ID: Date: Wed, 7 May 2003 09:36:02 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > >> >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > > > >> > connected routers. [snip] The specific mechanism for a sender to > >> > forward packets to routers are left to implementations". At a > >> > minimum, I think the exact implementation needs to be specified. > >> > >> Why? (The draft strives to avoid dictating implementation details that > >> do not affect interoperability.) > > > >For interoperatibilty. The requirement is the host and router must agree > >on using a common mechanism for exchanging the IP multicast packet. > >Implementations are free to choose a mechanism as long as all other > >implementations with which they communicate also choose to implement the > >same mechanism. I don't think this is an area where we can or should punt > >- a minimal, common approach needs to be mandated such that all IPoIB > >nodes implement that mechanism so that any two IPoIB nodes will > >interoperate. > > I still don't see any problem you may have in mind. As long as a sender > gets the pkt to the router, why it matter how it gets there? E.g., > routers will listen to both the broadcast and the all-router multicast > addresses. Does it matter which address a pkt is sent to? I guess I thought that a receiver might choose to discard IB packets which is sent to the wrong (M)GID. If this isn't possible or allowed by IBA, then you are right - it doesn't matter how a packet arrives at the local QP, just as long as it arrives. So, I guess an alternative to using the all-router MGID or the broadcast GID would be to have an IPoIB host somehow determine all listeners and unicast packets to each listener. Not a real good alternative, but it would work. Even if there are many possible ways to make IPoIB work, we should be choosing the "best" or "most appropriate" one(s) and documenting those. This appears to be sending to the all-router MGID, or possibly the broadcast GID. Why not simply state these are the mechnisms defined by IPoIB, but state that future standards may define additional mechanisms for delivery of multicast packets to the IPoIB router. > > > >> > The > >> > text suggests using all-router multicast group or the broadcast > >group. > >> > If a router is required to create the all-router multicast group (see > > > >> > the previous comment), then wouldn't it be sufficient to check for > >the > >> > existence of the all-router multicast group and, if it exists, send > >to > >> > that? If it doesn't exist, then there can't be any multicast routers > > > >> > on the link, and since there aren't any local listeners there are no > >> > on-link listeners there isn't any need to send the packet. > >> > >> Don't the code sinppet following 9.B match pretty much what you > >described > >> above? > > > >Yes, it does, and if the text matched the code snippet then I wouldn't > >have an issue. But the text which supports the code snippet doesn't. > > I can remove the text if it causes any confusion. I thought it is very > obvious if no router exists then there is no need to forward (as > illustrated by the code snippet). > > >The > >text basically says you could send to the all-router multicast group OR > >the broadcast group. And either should work, as long as the receiving > >IPoIB node MUST accept the IP multicast packets regardless of the IB group > >over which they are received (I'm not sure I've seen this explicitly > >stated in the draft, but I may have missed it). > > I thought this is required by IP already. But please tell me if I'm > wrong. > > >But do we really need to > >have multiple mechanisms to accomplish the same result? Wouldn't we be > >better off just choosing one and going with that? And how are we going to > >find multiple interoperable implementations for each option when the draft > >puts no limits on the approaches which can be taken? > > The multiple mechanisms were not there in the earlier draft, but were > requested later by my co-author. I personally don't see any harm with > it but I don't mind taking it out if Vivek agrees with you. I responded to a separate post from Vivek on this topic. I'm OK if both mechanisms (send to the all-router MGID or broadcast GID) are left in, although I do think the best approach is to send to the all-router MGID. Doing so reduces the amount of traffic which needs to be filtered by IPoIB hosts when there are no on-link listeners. > >> > And shouldn't the IPoIB sender subscribe to the IB multicast group > >> > creation events using a wildcard MGID so that it can > >> > "SendOnlyNonMember" join the group if a listener appears on the local > > > >> > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > >> > router appears on-link and creates the all-routers multicast group? > >> > And doesn't it need to subscribe to the IB multicast group deletion > >> > events so that it knows when to switch back to sending to the > >> > all-router multicast group and/or stop sending? > >> > >> Aren't you saying the same thing (more or less) as what is described in > >> the section following the code snippet? > > > >You are right - I must have missed the text. But you need to change the > >"should" to a "MUST" in that paragraph. > > Since the caching part is a "should", the subscription part ought to be > a "should" too, right? Yes, you are right. Listening for creation/deletion reports doesn't make any sense if the IPoIB node does not cache the MGID for groups which it "NonMember" joins. > >> > But I'm wondering why a node needs to do this at all. Wouldn't it > >> > make more sense for the IPoIB node instead create the multicast group > > > >> > and join the group so that IPoIB multicast routers can join the > >group? > >> > Yes, the IPoIB sender will need create the group as a "FullMember", > >> > but this seems to provide a simpler mapping of IP multicast to IB > >> > multicast. > >> > >> While what you suggested may simplify the procedure, it essentially > >> removes the difference between a multicast sender and a multicast > >receiver, > >> which is wrong. In the IP multicast model a multicast sender doesn't > >need > >> to be a member of a multicast group to send. The draft has tried to > >> keep the same distinction. > > > >However, you are mapping the IP multicast model to the IB multicast model, > >and the two are not the same. The reality is a sender must join an IB > >multicast group in order to send to it (albeit as a "SendOnlyNonMember"), > > This is the big difference that was debated in IBTA. > > >and this step does not exist in the IP model. I imagine that the vast > >majority of the code/complexity of an IPoIB implementation is going to be > >dealing with IB multicasting. I was hoping there was some way to reduce > >both at an IPoIB host. Maybe it is just wishful thinking. > > I actually have the same philosophy as well. I'm always against complexity > unless it's fully justified. But IB multicast just works differently than > IP multicast. We have gone through a number of alternatives and the > current one seemed to a good balance between complexity and correctness. > I don't remember all the tradeoffs but if we simply require a sender > to be a full-member, how would one know when to leave a group, when to > delete a group..., etc. Also wouldn't it enable anyone to write a silly > sender program to try to send to a million different addresses and cause > all the IB multicast resources to be used up? (The join call by > IP_ADD_MEMBERSHIP at least places some resource limitation.) Yes, there are issues which might well make it more complex. As I said, maybe it was wishful thinking. From the sound of it, it was. > >By the way, after thinking about this a little more, I'm not sure that > >creating a group as I suggested makes sense in all cases. For instance, > >it is only useful for an IP multicast group which has a scope greater than > >link-local. For link-local scope, only nodes directly attached to the > >IPoIB link are able to receive the packet. Creating the group for the > >purpose of forwarding to an IPoIB multicast router is simply wasteful, as > >the IPoIB multicast router will not be able to forward the packet to > >another IP link. > > > >A similar optimization can also be taken with the current approach > >described in this draft - for an IP multicast group with link-local scope, > >if the IB MGID for that IP multicast group does not exist then an IPoIB > >node really doesn't need to send the multicast packet to the all-router > >MGID or broadcast GID. > > Correct. This level of details can arguably be left to implementation > because it doesn't affect interoperability. But I think this optimization > is simple and useful enough that I'll add a note to the draft. Sounds good. > > > >> >- Section 9.0 also indicates that "A multicast sender must join the > >> > target multicast group as a "SendOnlyNonMember" before outgoing > >> > messages from it can be successfully routed." This text should be > >> > clarified to indicate this is only true if the node has not already > >> > joined the group as either a "FullMember" or "SendOnlyNonMember". The > > > >> > If-Then-Else logic below correctly shows this behavior, but this > >> > paragraph does not reflect that behavior. > >> > >> Although your comment is correct, I'd argue this kind of details can > >> be found in the IBA spec. It has nothing to do with IPoIB in particular, > >> So the question becomes how much IBA info we need to repeat in an IPoIB > >RFC. > >> Since the code sippet already covers this correctly, if you still > >believe > >> this needs to be clarified i can certain add more text to it. > > > >My feeling is enough to describe HOW an IPoIB node will USE the IBA > >services, and this is one of those cases. I would prefer to see the text > >clarified if you do another revision of the draft, but given the code > >snippet describes the correct behavior I wouldn't hold this draft up just > >to clarify this paragraph. > > Ok. > > > > >> >- Section 9.0 indicates that "For the rest of attributes, it is > >> > recommended the same values from the all-node multicast/broadcast > >> > group be used." Should this instead say "For the rest of the > >> > attributes, the same values from the all-node multicast/broadcast > >> > group SHOULD be used." Regardless of the wording, this text seems to > >> > contradict the Section 7.0 which states a node must "use the rest of > >> > the link attributes associated with the group for all future > >> > communication on the link. If Section 7.0 is correct, should this be > > > >> > a MUST instead of a SHOULD? And, if not, under what circumstances > >> > would a node choose to not use the same values? > >> > >> 7.0 describes the attributes used by a node when conducting unicast > >> communication. 9.0 describes the attributes used to create a multicast > >> group, i.e., for multicast communication. So the question is: > >> Must path attributes used for unicast match with those for multicast? > >> > >> The flexibility allowed in the multicast case in the current draft is > >> deliberate. I don't know in reality if this is useful, or even good to > >> have. (Comments are welcome.) My design principle has been to not to > >> make something a requirement unless it is needed for interoperability. > > > >Flexibility is often times good, but so is describing a minimal set of > >functions necessary for interoperability. If a node selects link > >attributes when creating an MGID which does not match the broadcast GID's > >attributes, then it is possible that not all nodes which are members of > >the IPoIB link will be able to support those attributes. If this happens, > >then the two nodes will not be able to communicate using the IP multicast > >group mapped to the MGID. All of a sudden, an IPoIB node can't send an > >ARP request or Neighbor Solicitation to another node. > > I think some of these "deliberate" flexibility (or ambuguity) came from > the ambuguity of IB itself in some of the mutlicast attributes such as > SL, TClass..., etc. It is not clear to me if they must or even can > follow the ones for unicast (i.e. described by the broadcast group) > in all cases. Well, I hope they can, as that is what I was planning on doing for any MGIDs which I had to create. If they can't, I have no idea how to come up with the appropriate values for the attributes. > >Perhaps it would be better to state that a node which creates a multicast > >group MUST use the same values for the attributes as the all-node > >multicast/broadcast group, but a node joining a multicast group must not > >verify the values match. If the node joining the group can't support the > >values for the multicast group, then it should log the error. That way, a > >future RFC could describe why/when/how a node would choose to use > >different values for the link attributes but still be able to interoperate > >with IPoIB nodes. > > I'll leave the above for IB folks to comment. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed May 7 11:36: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 LAA06035 for ; Wed, 7 May 2003 11:36:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Fi5827544; Wed, 7 May 2003 11:44:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Fhr827522 for ; Wed, 7 May 2003 11:43:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05953 for ; Wed, 7 May 2003 11:34:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQy1-0002Pe-00 for ipoverib@ietf.org; Wed, 07 May 2003 11:36:25 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19DQxz-0002PR-00 for ipoverib@ietf.org; Wed, 07 May 2003 11:36:23 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47FajQs209350 for ; Wed, 7 May 2003 11:36:45 -0400 Received: from d03nm122.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47FafGu115260 for ; Wed, 7 May 2003 09:36:45 -0600 Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: ipoverib@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Wed, 7 May 2003 08:36:28 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.0.1 [IBM]|April 28, 2003) at 05/07/2003 09:36:45 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > > 7.0 describes the attributes used by a node when conducting unicast > > communication. 9.0 describes the attributes used to create a multicast > > group, i.e., for multicast communication. So the question is: > > Must path attributes used for unicast match with those for multicast? > > > > The flexibility allowed in the multicast case in the current draft is > > deliberate. I don't know in reality if this is useful, or even good to > > have. (Comments are welcome.) My design principle has been to not to > > make something a requirement unless it is needed for interoperability. > Flexibility is often times good, but so is describing a minimal set of > functions necessary for interoperability. If a node selects link > attributes when creating an MGID which does not match the broadcast GID's > attributes, then it is possible that not all nodes which are members of > the IPoIB link will be able to support those attributes. If this happens, > then the two nodes will not be able to communicate using the IP multicast > group mapped to the MGID. All of a sudden, an IPoIB node can't send an > ARP request or Neighbor Solicitation to another node. > > Perhaps it would be better to state that a node which creates a multicast > group MUST use the same values for the attributes as the all-node > multicast/broadcast group, but a node joining a multicast group must not > verify the values match. If the node joining the group can't support the > values for the multicast group, then it should log the error. That way, a > future RFC could describe why/when/how a node would choose to use > different values for the link attributes but still be able to interoperate > with IPoIB nodes. That is a valid idea. The other alternative is to list the parameters that may differ from the ones used by the broadcast-GID. The parameters for an IB multicast group are: Q_Key, MLID, MTU, TClass, P_Key, Rate, SL, PacketLifeTime, FlowLabel, Hoplimit, scope. We certainly need the P_Key and MTU to be the same as the broadcast MGID. Similarly all multicast mappings in a subnet must have the same 'scope'. The other parameters can be different if it is ensured that they are all supported by all the members of the IP subnet. There is no well defined method of ensuring this - none is being defined by us. On the other had, by definition all members support the parameters supported by the broadcast-GID. Therefore I agree with you... Jerry, I think we should change the draft to state the following about the parameters: 1. unicast communication use the parameters used by broadcast-GID 2. multicast GIDs created should use the same parameters as the broadcast-GID. Vivek -- Vivek Kashyap Linux Technology Center, IBM vivk@us.ibm.com kashyapv@us.ibm.com Ph: 503 578 3422 T/L: 775 3422 ----- Forwarded by Vivek Kashyap/Beaverton/IBM on 05/07/03 08:28 ----- kashyapv@us.ltcfwd.li nux.ibm.com To: Roy Brabson/Raleigh/IBM@IBMUS Sent by: cc: "H.K. Jerry Chu" , ipoverib-admin@ietf.o Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt rg 05/06/03 15:43 On Tue, 6 May 2003, Roy Brabson wrote: > > >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > > > > connected routers. [snip] The specific mechanism for a sender to > > > forward packets to routers are left to implementations". At a > > > minimum, I think the exact implementation needs to be specified. > > > > Why? (The draft strives to avoid dictating implementation details that > > do not affect interoperability.) > > For interoperatibilty. The requirement is the host and router must agree > on using a common mechanism for exchanging the IP multicast packet. > Implementations are free to choose a mechanism as long as all other > implementations with which they communicate also choose to implement the > same mechanism. I don't think this is an area where we can or should punt > - a minimal, common approach needs to be mandated such that all IPoIB > nodes implement that mechanism so that any two IPoIB nodes will > interoperate. Roy, Yes, I agree that a common method must be described for interoperability. Though, in this case, even with the flexibility interoperability is maintained - the onus being on the router : The packet may be sent to the routers on broadcast-GID or the all-router GID. The router itself will listen on both - broadcast-GID since it is required by IPoIB and all-routers as a result of other specs (IPv6 & IGMP). Therefore the packet will be received by the router irrespective of the MGID used as long as the router accepts any multicast packets on these MGIDs. I have described the need for this in my previous reply. We could do one of three things when the relevant MGID does not exist: 1. The host must always forward on broadcast MGID and the router must always accept IP multicast packets on the broadcast GID. 2. The host must always forward on all-router MGID and the router must always accept IP multicast packets on the all-router MGID 3. The host must always forward on broadcast GID or all-router MGID. The router must accept IP multicast packets on both the broadcast MGID and all-router MGID. We have chosen case 3 . Is there a strong feeling that one of the other cases is preferable? It appears that the method chosen(case 3) needs to be explicitly stated in the draft. > > > > The > > > text suggests using all-router multicast group or the broadcast > group. > > > If a router is required to create the all-router multicast group (see > > > > the previous comment), then wouldn't it be sufficient to check for > the > > > existence of the all-router multicast group and, if it exists, send > to > > > that? If it doesn't exist, then there can't be any multicast routers > > > > on the link, and since there aren't any local listeners there are no > > > on-link listeners there isn't any need to send the packet. > > > > Don't the code sinppet following 9.B match pretty much what you > described > > above? > > Yes, it does, and if the text matched the code snippet then I wouldn't > have an issue. But the text which supports the code snippet doesn't. The > text basically says you could send to the all-router multicast group OR > the broadcast group. And either should work, as long as the receiving > IPoIB node MUST accept the IP multicast packets regardless of the IB group > over which they are received (I'm not sure I've seen this explicitly > stated in the draft, but I may have missed it). But do we really need to > have multiple mechanisms to accomplish the same result? Wouldn't we be > better off just choosing one and going with that? And how are we going to > find multiple interoperable implementations for each option when the draft > puts no limits on the approaches which can be taken? > > > > > > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > > creation events using a wildcard MGID so that it can > > > "SendOnlyNonMember" join the group if a listener appears on the local > > > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > > router appears on-link and creates the all-routers multicast group? > > > And doesn't it need to subscribe to the IB multicast group deletion > > > events so that it knows when to switch back to sending to the > > > all-router multicast group and/or stop sending? > > > > Aren't you saying the same thing (more or less) as what is described in > > the section following the code snippet? > > You are right - I must have missed the text. But you need to change the > "should" to a "MUST" in that paragraph. > > > > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > > make more sense for the IPoIB node instead create the multicast group > > > > and join the group so that IPoIB multicast routers can join the > group? > > > Yes, the IPoIB sender will need create the group as a "FullMember", > > > but this seems to provide a simpler mapping of IP multicast to IB > > > multicast. > > > > While what you suggested may simplify the procedure, it essentially > > removes the difference between a multicast sender and a multicast > receiver, > > which is wrong. In the IP multicast model a multicast sender doesn't > need > > to be a member of a multicast group to send. The draft has tried to > > keep the same distinction. > > However, you are mapping the IP multicast model to the IB multicast model, > and the two are not the same. The reality is a sender must join an IB > multicast group in order to send to it (albeit as a "SendOnlyNonMember"), > and this step does not exist in the IP model. I imagine that the vast > majority of the code/complexity of an IPoIB implementation is going to be > dealing with IB multicasting. I was hoping there was some way to reduce > both at an IPoIB host. Maybe it is just wishful thinking. > > By the way, after thinking about this a little more, I'm not sure that > creating a group as I suggested makes sense in all cases. For instance, > it is only useful for an IP multicast group which has a scope greater than > link-local. For link-local scope, only nodes directly attached to the > IPoIB link are able to receive the packet. Creating the group for the > purpose of forwarding to an IPoIB multicast router is simply wasteful, as > the IPoIB multicast router will not be able to forward the packet to > another IP link. > > A similar optimization can also be taken with the current approach > described in this draft - for an IP multicast group with link-local scope, > if the IB MGID for that IP multicast group does not exist then an IPoIB > node really doesn't need to send the multicast packet to the all-router > MGID or broadcast GID. > > > >- Section 9.0 also indicates that "A multicast sender must join the > > > target multicast group as a "SendOnlyNonMember" before outgoing > > > messages from it can be successfully routed." This text should be > > > clarified to indicate this is only true if the node has not already > > > joined the group as either a "FullMember" or "SendOnlyNonMember". The > > > > If-Then-Else logic below correctly shows this behavior, but this > > > paragraph does not reflect that behavior. > > > > Although your comment is correct, I'd argue this kind of details can > > be found in the IBA spec. It has nothing to do with IPoIB in particular, > > So the question becomes how much IBA info we need to repeat in an IPoIB > RFC. > > Since the code sippet already covers this correctly, if you still > believe > > this needs to be clarified i can certain add more text to it. > > My feeling is enough to describe HOW an IPoIB node will USE the IBA > services, and this is one of those cases. I would prefer to see the text > clarified if you do another revision of the draft, but given the code > snippet describes the correct behavior I wouldn't hold this draft up just > to clarify this paragraph. > > > >- Section 9.0 indicates that "For the rest of attributes, it is > > > recommended the same values from the all-node multicast/broadcast > > > group be used." Should this instead say "For the rest of the > > > attributes, the same values from the all-node multicast/broadcast > > > group SHOULD be used." Regardless of the wording, this text seems to > > > contradict the Section 7.0 which states a node must "use the rest of > > > the link attributes associated with the group for all future > > > communication on the link. If Section 7.0 is correct, should this be > > > > a MUST instead of a SHOULD? And, if not, under what circumstances > > > would a node choose to not use the same values? > > > > 7.0 describes the attributes used by a node when conducting unicast > > communication. 9.0 describes the attributes used to create a multicast > > group, i.e., for multicast communication. So the question is: > > Must path attributes used for unicast match with those for multicast? > > > > The flexibility allowed in the multicast case in the current draft is > > deliberate. I don't know in reality if this is useful, or even good to > > have. (Comments are welcome.) My design principle has been to not to > > make something a requirement unless it is needed for interoperability. > > Flexibility is often times good, but so is describing a minimal set of > functions necessary for interoperability. If a node selects link > attributes when creating an MGID which does not match the broadcast GID's > attributes, then it is possible that not all nodes which are members of > the IPoIB link will be able to support those attributes. If this happens, > then the two nodes will not be able to communicate using the IP multicast > group mapped to the MGID. All of a sudden, an IPoIB node can't send an > ARP request or Neighbor Solicitation to another node. > > Perhaps it would be better to state that a node which creates a multicast > group MUST use the same values for the attributes as the all-node > multicast/broadcast group, but a node joining a multicast group must not > verify the values match. If the node joining the group can't support the > values for the multicast group, then it should log the error. That way, a > future RFC could describe why/when/how a node would choose to use > different values for the link attributes but still be able to interoperate > with IPoIB nodes. That is a valid idea. The other alternative is to list the parameters that may differ from the ones used by the broadcast-GID. The parameters for an IB multicast group are: Q_Key, MLID, MTU, TClass, P_Key, Rate, SL, PacketLifeTime, FlowLabel, Hoplimit, scope. We certainly need the P_Key and MTU to be the same as the broadcast MGID. Similarly all multicast mappings in a subnet must have the same 'scope'. The other parameters can be different if it is ensured that they are all supported by all the members of the IP subnet. There is no well defined method of ensuring this - none is being defined by us. On the other had, by definition all members support the parameters supported by the broadcast-GID. Therefore I agree with you... Jerry, I think we should change the draft to state the following about the parameters: 1. unicast communication use the parameters used by broadcast-GID 2. multicast GIDs created should use the same parameters as the broadcast-GID. Vivek > > Roy > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ 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 Wed May 7 11:36:53 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 LAA06049 for ; Wed, 7 May 2003 11:36:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47Fjsw27677 for ipoverib-archive@odin.ietf.org; Wed, 7 May 2003 11:45:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Fjr827674 for ; Wed, 7 May 2003 11:45:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06011 for ; Wed, 7 May 2003 11:36:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQzx-0002Qp-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 11:38:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DQzx-0002Qm-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 11:38:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Fi5827544; Wed, 7 May 2003 11:44:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Fhr827522 for ; Wed, 7 May 2003 11:43:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05953 for ; Wed, 7 May 2003 11:34:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQy1-0002Pe-00 for ipoverib@ietf.org; Wed, 07 May 2003 11:36:25 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19DQxz-0002PR-00 for ipoverib@ietf.org; Wed, 07 May 2003 11:36:23 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47FajQs209350 for ; Wed, 7 May 2003 11:36:45 -0400 Received: from d03nm122.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47FafGu115260 for ; Wed, 7 May 2003 09:36:45 -0600 Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: ipoverib@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Wed, 7 May 2003 08:36:28 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.0.1 [IBM]|April 28, 2003) at 05/07/2003 09:36:45 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > > 7.0 describes the attributes used by a node when conducting unicast > > communication. 9.0 describes the attributes used to create a multicast > > group, i.e., for multicast communication. So the question is: > > Must path attributes used for unicast match with those for multicast? > > > > The flexibility allowed in the multicast case in the current draft is > > deliberate. I don't know in reality if this is useful, or even good to > > have. (Comments are welcome.) My design principle has been to not to > > make something a requirement unless it is needed for interoperability. > Flexibility is often times good, but so is describing a minimal set of > functions necessary for interoperability. If a node selects link > attributes when creating an MGID which does not match the broadcast GID's > attributes, then it is possible that not all nodes which are members of > the IPoIB link will be able to support those attributes. If this happens, > then the two nodes will not be able to communicate using the IP multicast > group mapped to the MGID. All of a sudden, an IPoIB node can't send an > ARP request or Neighbor Solicitation to another node. > > Perhaps it would be better to state that a node which creates a multicast > group MUST use the same values for the attributes as the all-node > multicast/broadcast group, but a node joining a multicast group must not > verify the values match. If the node joining the group can't support the > values for the multicast group, then it should log the error. That way, a > future RFC could describe why/when/how a node would choose to use > different values for the link attributes but still be able to interoperate > with IPoIB nodes. That is a valid idea. The other alternative is to list the parameters that may differ from the ones used by the broadcast-GID. The parameters for an IB multicast group are: Q_Key, MLID, MTU, TClass, P_Key, Rate, SL, PacketLifeTime, FlowLabel, Hoplimit, scope. We certainly need the P_Key and MTU to be the same as the broadcast MGID. Similarly all multicast mappings in a subnet must have the same 'scope'. The other parameters can be different if it is ensured that they are all supported by all the members of the IP subnet. There is no well defined method of ensuring this - none is being defined by us. On the other had, by definition all members support the parameters supported by the broadcast-GID. Therefore I agree with you... Jerry, I think we should change the draft to state the following about the parameters: 1. unicast communication use the parameters used by broadcast-GID 2. multicast GIDs created should use the same parameters as the broadcast-GID. Vivek -- Vivek Kashyap Linux Technology Center, IBM vivk@us.ibm.com kashyapv@us.ibm.com Ph: 503 578 3422 T/L: 775 3422 ----- Forwarded by Vivek Kashyap/Beaverton/IBM on 05/07/03 08:28 ----- kashyapv@us.ltcfwd.li nux.ibm.com To: Roy Brabson/Raleigh/IBM@IBMUS Sent by: cc: "H.K. Jerry Chu" , ipoverib-admin@ietf.o Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt rg 05/06/03 15:43 On Tue, 6 May 2003, Roy Brabson wrote: > > >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > > > > connected routers. [snip] The specific mechanism for a sender to > > > forward packets to routers are left to implementations". At a > > > minimum, I think the exact implementation needs to be specified. > > > > Why? (The draft strives to avoid dictating implementation details that > > do not affect interoperability.) > > For interoperatibilty. The requirement is the host and router must agree > on using a common mechanism for exchanging the IP multicast packet. > Implementations are free to choose a mechanism as long as all other > implementations with which they communicate also choose to implement the > same mechanism. I don't think this is an area where we can or should punt > - a minimal, common approach needs to be mandated such that all IPoIB > nodes implement that mechanism so that any two IPoIB nodes will > interoperate. Roy, Yes, I agree that a common method must be described for interoperability. Though, in this case, even with the flexibility interoperability is maintained - the onus being on the router : The packet may be sent to the routers on broadcast-GID or the all-router GID. The router itself will listen on both - broadcast-GID since it is required by IPoIB and all-routers as a result of other specs (IPv6 & IGMP). Therefore the packet will be received by the router irrespective of the MGID used as long as the router accepts any multicast packets on these MGIDs. I have described the need for this in my previous reply. We could do one of three things when the relevant MGID does not exist: 1. The host must always forward on broadcast MGID and the router must always accept IP multicast packets on the broadcast GID. 2. The host must always forward on all-router MGID and the router must always accept IP multicast packets on the all-router MGID 3. The host must always forward on broadcast GID or all-router MGID. The router must accept IP multicast packets on both the broadcast MGID and all-router MGID. We have chosen case 3 . Is there a strong feeling that one of the other cases is preferable? It appears that the method chosen(case 3) needs to be explicitly stated in the draft. > > > > The > > > text suggests using all-router multicast group or the broadcast > group. > > > If a router is required to create the all-router multicast group (see > > > > the previous comment), then wouldn't it be sufficient to check for > the > > > existence of the all-router multicast group and, if it exists, send > to > > > that? If it doesn't exist, then there can't be any multicast routers > > > > on the link, and since there aren't any local listeners there are no > > > on-link listeners there isn't any need to send the packet. > > > > Don't the code sinppet following 9.B match pretty much what you > described > > above? > > Yes, it does, and if the text matched the code snippet then I wouldn't > have an issue. But the text which supports the code snippet doesn't. The > text basically says you could send to the all-router multicast group OR > the broadcast group. And either should work, as long as the receiving > IPoIB node MUST accept the IP multicast packets regardless of the IB group > over which they are received (I'm not sure I've seen this explicitly > stated in the draft, but I may have missed it). But do we really need to > have multiple mechanisms to accomplish the same result? Wouldn't we be > better off just choosing one and going with that? And how are we going to > find multiple interoperable implementations for each option when the draft > puts no limits on the approaches which can be taken? > > > > > > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > > creation events using a wildcard MGID so that it can > > > "SendOnlyNonMember" join the group if a listener appears on the local > > > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > > router appears on-link and creates the all-routers multicast group? > > > And doesn't it need to subscribe to the IB multicast group deletion > > > events so that it knows when to switch back to sending to the > > > all-router multicast group and/or stop sending? > > > > Aren't you saying the same thing (more or less) as what is described in > > the section following the code snippet? > > You are right - I must have missed the text. But you need to change the > "should" to a "MUST" in that paragraph. > > > > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > > make more sense for the IPoIB node instead create the multicast group > > > > and join the group so that IPoIB multicast routers can join the > group? > > > Yes, the IPoIB sender will need create the group as a "FullMember", > > > but this seems to provide a simpler mapping of IP multicast to IB > > > multicast. > > > > While what you suggested may simplify the procedure, it essentially > > removes the difference between a multicast sender and a multicast > receiver, > > which is wrong. In the IP multicast model a multicast sender doesn't > need > > to be a member of a multicast group to send. The draft has tried to > > keep the same distinction. > > However, you are mapping the IP multicast model to the IB multicast model, > and the two are not the same. The reality is a sender must join an IB > multicast group in order to send to it (albeit as a "SendOnlyNonMember"), > and this step does not exist in the IP model. I imagine that the vast > majority of the code/complexity of an IPoIB implementation is going to be > dealing with IB multicasting. I was hoping there was some way to reduce > both at an IPoIB host. Maybe it is just wishful thinking. > > By the way, after thinking about this a little more, I'm not sure that > creating a group as I suggested makes sense in all cases. For instance, > it is only useful for an IP multicast group which has a scope greater than > link-local. For link-local scope, only nodes directly attached to the > IPoIB link are able to receive the packet. Creating the group for the > purpose of forwarding to an IPoIB multicast router is simply wasteful, as > the IPoIB multicast router will not be able to forward the packet to > another IP link. > > A similar optimization can also be taken with the current approach > described in this draft - for an IP multicast group with link-local scope, > if the IB MGID for that IP multicast group does not exist then an IPoIB > node really doesn't need to send the multicast packet to the all-router > MGID or broadcast GID. > > > >- Section 9.0 also indicates that "A multicast sender must join the > > > target multicast group as a "SendOnlyNonMember" before outgoing > > > messages from it can be successfully routed." This text should be > > > clarified to indicate this is only true if the node has not already > > > joined the group as either a "FullMember" or "SendOnlyNonMember". The > > > > If-Then-Else logic below correctly shows this behavior, but this > > > paragraph does not reflect that behavior. > > > > Although your comment is correct, I'd argue this kind of details can > > be found in the IBA spec. It has nothing to do with IPoIB in particular, > > So the question becomes how much IBA info we need to repeat in an IPoIB > RFC. > > Since the code sippet already covers this correctly, if you still > believe > > this needs to be clarified i can certain add more text to it. > > My feeling is enough to describe HOW an IPoIB node will USE the IBA > services, and this is one of those cases. I would prefer to see the text > clarified if you do another revision of the draft, but given the code > snippet describes the correct behavior I wouldn't hold this draft up just > to clarify this paragraph. > > > >- Section 9.0 indicates that "For the rest of attributes, it is > > > recommended the same values from the all-node multicast/broadcast > > > group be used." Should this instead say "For the rest of the > > > attributes, the same values from the all-node multicast/broadcast > > > group SHOULD be used." Regardless of the wording, this text seems to > > > contradict the Section 7.0 which states a node must "use the rest of > > > the link attributes associated with the group for all future > > > communication on the link. If Section 7.0 is correct, should this be > > > > a MUST instead of a SHOULD? And, if not, under what circumstances > > > would a node choose to not use the same values? > > > > 7.0 describes the attributes used by a node when conducting unicast > > communication. 9.0 describes the attributes used to create a multicast > > group, i.e., for multicast communication. So the question is: > > Must path attributes used for unicast match with those for multicast? > > > > The flexibility allowed in the multicast case in the current draft is > > deliberate. I don't know in reality if this is useful, or even good to > > have. (Comments are welcome.) My design principle has been to not to > > make something a requirement unless it is needed for interoperability. > > Flexibility is often times good, but so is describing a minimal set of > functions necessary for interoperability. If a node selects link > attributes when creating an MGID which does not match the broadcast GID's > attributes, then it is possible that not all nodes which are members of > the IPoIB link will be able to support those attributes. If this happens, > then the two nodes will not be able to communicate using the IP multicast > group mapped to the MGID. All of a sudden, an IPoIB node can't send an > ARP request or Neighbor Solicitation to another node. > > Perhaps it would be better to state that a node which creates a multicast > group MUST use the same values for the attributes as the all-node > multicast/broadcast group, but a node joining a multicast group must not > verify the values match. If the node joining the group can't support the > values for the multicast group, then it should log the error. That way, a > future RFC could describe why/when/how a node would choose to use > different values for the link attributes but still be able to interoperate > with IPoIB nodes. That is a valid idea. The other alternative is to list the parameters that may differ from the ones used by the broadcast-GID. The parameters for an IB multicast group are: Q_Key, MLID, MTU, TClass, P_Key, Rate, SL, PacketLifeTime, FlowLabel, Hoplimit, scope. We certainly need the P_Key and MTU to be the same as the broadcast MGID. Similarly all multicast mappings in a subnet must have the same 'scope'. The other parameters can be different if it is ensured that they are all supported by all the members of the IP subnet. There is no well defined method of ensuring this - none is being defined by us. On the other had, by definition all members support the parameters supported by the broadcast-GID. Therefore I agree with you... Jerry, I think we should change the draft to state the following about the parameters: 1. unicast communication use the parameters used by broadcast-GID 2. multicast GIDs created should use the same parameters as the broadcast-GID. Vivek > > Roy > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ 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 Wed May 7 12:01: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 MAA06659 for ; Wed, 7 May 2003 12:01:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47G95830362; Wed, 7 May 2003 12:09:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47G8m830322 for ; Wed, 7 May 2003 12:08:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06581; Wed, 7 May 2003 11:59:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DRM8-0002Zs-00; Wed, 07 May 2003 12:01:20 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 19DRM6-0002ZY-00; Wed, 07 May 2003 12:01:18 -0400 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47G1buT157448; Wed, 7 May 2003 12:01:37 -0400 Received: from d03nm122.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.193.81]) by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47G1KAp064146; Wed, 7 May 2003 10:01:23 -0600 Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: "H.K. Jerry Chu" Cc: ipoverib@ietf.org, ipoverib-admin@ietf.org, Roy Brabson X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Wed, 7 May 2003 09:01:04 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.0.1 [IBM]|April 28, 2003) at 05/07/2003 10:01:23 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , See below between -- Vivek Kashyap Linux Technology Center, IBM vivk@us.ibm.com kashyapv@us.ibm.com Ph: 503 578 3422 T/L: 775 3422 "H.K. Jerry Chu" cc: ipoverib@ietf.org Sent by: Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt ipoverib-admin@ie tf.org 05/06/03 21:55 Please respond to "H.K. Jerry Chu" >> >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > >> > connected routers. [snip] The specific mechanism for a sender to >> > forward packets to routers are left to implementations". At a >> > minimum, I think the exact implementation needs to be specified. >> >> Why? (The draft strives to avoid dictating implementation details that >> do not affect interoperability.) > >For interoperatibilty. The requirement is the host and router must agree >on using a common mechanism for exchanging the IP multicast packet. >Implementations are free to choose a mechanism as long as all other >implementations with which they communicate also choose to implement the >same mechanism. I don't think this is an area where we can or should punt >- a minimal, common approach needs to be mandated such that all IPoIB >nodes implement that mechanism so that any two IPoIB nodes will >interoperate. I still don't see any problem you may have in mind. As long as a sender gets the pkt to the router, why it matter how it gets there? E.g., routers will listen to both the broadcast and the all-router multicast addresses. Does it matter which address a pkt is sent to? As I noted in my previous mail... the onus is on the router. The router is required to listen to multicast packets on both: a) all-router MGID or b) broadcast-GID We could make that explicit in the draft. The second option, which apparently Roy favours is to specify that the nodes must, if the relevant MGID doesn't exist, send the packet to the MGID corresponding to the all-router MGID. This option is fine but it then adds another requirement: All IPoIB nodes MUST request creation request for all-router MGID whether the corresponding IP layer joins the all-router IP address or not. If the fall-back is the broadcast-GID then the end-nodes do not have to do anything special. The current option allows the sender to choose between taking the simple route of 'fall-back to broadcast GID' vs. 'must join all-router MGID'. I am ok with either case and if the 'must join all-router MGID' case is preferable then we can specify that instead. > >> > The >> > text suggests using all-router multicast group or the broadcast >group. >> > If a router is required to create the all-router multicast group (see > >> > the previous comment), then wouldn't it be sufficient to check for >the >> > existence of the all-router multicast group and, if it exists, send >to >> > that? If it doesn't exist, then there can't be any multicast routers > >> > on the link, and since there aren't any local listeners there are no >> > on-link listeners there isn't any need to send the packet. >> >> Don't the code sinppet following 9.B match pretty much what you >described >> above? > >Yes, it does, and if the text matched the code snippet then I wouldn't >have an issue. But the text which supports the code snippet doesn't. I can remove the text if it causes any confusion. I thought it is very obvious if no router exists then there is no need to forward (as illustrated by the code snippet). >The >text basically says you could send to the all-router multicast group OR >the broadcast group. And either should work, as long as the receiving >IPoIB node MUST accept the IP multicast packets regardless of the IB group >over which they are received (I'm not sure I've seen this explicitly >stated in the draft, but I may have missed it). I thought this is required by IP already. But please tell me if I'm wrong. >But do we really need to >have multiple mechanisms to accomplish the same result? Wouldn't we be >better off just choosing one and going with that? And how are we going to >find multiple interoperable implementations for each option when the draft >puts no limits on the approaches which can be taken? The multiple mechanisms were not there in the earlier draft, but were requested later by my co-author. I personally don't see any harm with it but I don't mind taking it out if Vivek agrees with you. Don't remember, could have on reasoning as described above. I think we can take it out and replace it with the condition that the packets are sent to the all-router MGID AND all IPoIB nodes (because any can be a sender) need to request creation report for all-router MGID and then IB_Join it. >> > >> > And shouldn't the IPoIB sender subscribe to the IB multicast group >> > creation events using a wildcard MGID so that it can >> > "SendOnlyNonMember" join the group if a listener appears on the local > >> > IB subnet, or "SendOnlyNonMember" join the all-routers group if a >> > router appears on-link and creates the all-routers multicast group? >> > And doesn't it need to subscribe to the IB multicast group deletion >> > events so that it knows when to switch back to sending to the >> > all-router multicast group and/or stop sending? >> >> Aren't you saying the same thing (more or less) as what is described in >> the section following the code snippet? > >You are right - I must have missed the text. But you need to change the >"should" to a "MUST" in that paragraph. Since the caching part is a "should", the subscription part ought to be a "should" too, right? > >> > >> > But I'm wondering why a node needs to do this at all. Wouldn't it >> > make more sense for the IPoIB node instead create the multicast group > >> > and join the group so that IPoIB multicast routers can join the >group? >> > Yes, the IPoIB sender will need create the group as a "FullMember", >> > but this seems to provide a simpler mapping of IP multicast to IB >> > multicast. >> >> While what you suggested may simplify the procedure, it essentially >> removes the difference between a multicast sender and a multicast >receiver, >> which is wrong. In the IP multicast model a multicast sender doesn't >need >> to be a member of a multicast group to send. The draft has tried to >> keep the same distinction. > >However, you are mapping the IP multicast model to the IB multicast model, >and the two are not the same. The reality is a sender must join an IB >multicast group in order to send to it (albeit as a "SendOnlyNonMember"), This is the big difference that was debated in IBTA. >and this step does not exist in the IP model. I imagine that the vast >majority of the code/complexity of an IPoIB implementation is going to be >dealing with IB multicasting. I was hoping there was some way to reduce >both at an IPoIB host. Maybe it is just wishful thinking. I actually have the same philosophy as well. I'm always against complexity unless it's fully justified. But IB multicast just works differently than IP multicast. We have gone through a number of alternatives and the current one seemed to a good balance between complexity and correctness. I don't remember all the tradeoffs but if we simply require a sender to be a full-member, how would one know when to leave a group, when to delete a group..., etc. Also wouldn't it enable anyone to write a silly sender program to try to send to a million different addresses and cause all the IB multicast resources to be used up? (The join call by IP_ADD_MEMBERSHIP at least places some resource limitation.) Yes, a major consideration has been the limited multicast resources avaialble in IB. Some other issues were such as the case I described a little while back: there is a very large chance of the router not receiving the packet when the sender the group due to the possible delay in the report reaching the router and the router IB_joining the group etc. > >By the way, after thinking about this a little more, I'm not sure that >creating a group as I suggested makes sense in all cases. For instance, >it is only useful for an IP multicast group which has a scope greater than >link-local. For link-local scope, only nodes directly attached to the >IPoIB link are able to receive the packet. Creating the group for the >purpose of forwarding to an IPoIB multicast router is simply wasteful, as >the IPoIB multicast router will not be able to forward the packet to >another IP link. > >A similar optimization can also be taken with the current approach >described in this draft - for an IP multicast group with link-local scope, >if the IB MGID for that IP multicast group does not exist then an IPoIB >node really doesn't need to send the multicast packet to the all-router >MGID or broadcast GID. Correct. This level of details can arguably be left to implementation because it doesn't affect interoperability. But I think this optimization is simple and useful enough that I'll add a note to the draft. Agreed. > >> >- Section 9.0 also indicates that "A multicast sender must join the >> > target multicast group as a "SendOnlyNonMember" before outgoing >> > messages from it can be successfully routed." This text should be >> > clarified to indicate this is only true if the node has not already >> > joined the group as either a "FullMember" or "SendOnlyNonMember". The > >> > If-Then-Else logic below correctly shows this behavior, but this >> > paragraph does not reflect that behavior. >> >> Although your comment is correct, I'd argue this kind of details can >> be found in the IBA spec. It has nothing to do with IPoIB in particular, >> So the question becomes how much IBA info we need to repeat in an IPoIB >RFC. >> Since the code sippet already covers this correctly, if you still >believe >> this needs to be clarified i can certain add more text to it. > >My feeling is enough to describe HOW an IPoIB node will USE the IBA >services, and this is one of those cases. I would prefer to see the text >clarified if you do another revision of the draft, but given the code >snippet describes the correct behavior I wouldn't hold this draft up just >to clarify this paragraph. Ok. > >> >- Section 9.0 indicates that "For the rest of attributes, it is >> > recommended the same values from the all-node multicast/broadcast >> > group be used." Should this instead say "For the rest of the >> > attributes, the same values from the all-node multicast/broadcast >> > group SHOULD be used." Regardless of the wording, this text seems to >> > contradict the Section 7.0 which states a node must "use the rest of >> > the link attributes associated with the group for all future >> > communication on the link. If Section 7.0 is correct, should this be > >> > a MUST instead of a SHOULD? And, if not, under what circumstances >> > would a node choose to not use the same values? >> >> 7.0 describes the attributes used by a node when conducting unicast >> communication. 9.0 describes the attributes used to create a multicast >> group, i.e., for multicast communication. So the question is: >> Must path attributes used for unicast match with those for multicast? >> >> The flexibility allowed in the multicast case in the current draft is >> deliberate. I don't know in reality if this is useful, or even good to >> have. (Comments are welcome.) My design principle has been to not to >> make something a requirement unless it is needed for interoperability. > >Flexibility is often times good, but so is describing a minimal set of >functions necessary for interoperability. If a node selects link >attributes when creating an MGID which does not match the broadcast GID's >attributes, then it is possible that not all nodes which are members of >the IPoIB link will be able to support those attributes. If this happens, >then the two nodes will not be able to communicate using the IP multicast >group mapped to the MGID. All of a sudden, an IPoIB node can't send an >ARP request or Neighbor Solicitation to another node. I think some of these "deliberate" flexibility (or ambuguity) came from the ambuguity of IB itself in some of the mutlicast attributes such as SL, TClass..., etc. It is not clear to me if they must or even can follow the ones for unicast (i.e. described by the broadcast group) in all cases. > >Perhaps it would be better to state that a node which creates a multicast >group MUST use the same values for the attributes as the all-node >multicast/broadcast group, but a node joining a multicast group must not >verify the values match. If the node joining the group can't support the >values for the multicast group, then it should log the error. That way, a >future RFC could describe why/when/how a node would choose to use >different values for the link attributes but still be able to interoperate >with IPoIB nodes. I'll leave the above for IB folks to comment. Jerry > >Roy _______________________________________________ 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 Wed May 7 12:01:01 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 MAA06680 for ; Wed, 7 May 2003 12:01:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47GA3R30436 for ipoverib-archive@odin.ietf.org; Wed, 7 May 2003 12:10:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47GA3830433 for ; Wed, 7 May 2003 12:10:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06650 for ; Wed, 7 May 2003 12:00:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DRNK-0002aS-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 12:02:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DRNJ-0002aP-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 12:02:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47G95830362; Wed, 7 May 2003 12:09:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47G8m830322 for ; Wed, 7 May 2003 12:08:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06581; Wed, 7 May 2003 11:59:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DRM8-0002Zs-00; Wed, 07 May 2003 12:01:20 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 19DRM6-0002ZY-00; Wed, 07 May 2003 12:01:18 -0400 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47G1buT157448; Wed, 7 May 2003 12:01:37 -0400 Received: from d03nm122.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.193.81]) by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47G1KAp064146; Wed, 7 May 2003 10:01:23 -0600 Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: "H.K. Jerry Chu" Cc: ipoverib@ietf.org, ipoverib-admin@ietf.org, Roy Brabson X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Wed, 7 May 2003 09:01:04 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.0.1 [IBM]|April 28, 2003) at 05/07/2003 10:01:23 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , See below between -- Vivek Kashyap Linux Technology Center, IBM vivk@us.ibm.com kashyapv@us.ibm.com Ph: 503 578 3422 T/L: 775 3422 "H.K. Jerry Chu" cc: ipoverib@ietf.org Sent by: Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt ipoverib-admin@ie tf.org 05/06/03 21:55 Please respond to "H.K. Jerry Chu" >> >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > >> > connected routers. [snip] The specific mechanism for a sender to >> > forward packets to routers are left to implementations". At a >> > minimum, I think the exact implementation needs to be specified. >> >> Why? (The draft strives to avoid dictating implementation details that >> do not affect interoperability.) > >For interoperatibilty. The requirement is the host and router must agree >on using a common mechanism for exchanging the IP multicast packet. >Implementations are free to choose a mechanism as long as all other >implementations with which they communicate also choose to implement the >same mechanism. I don't think this is an area where we can or should punt >- a minimal, common approach needs to be mandated such that all IPoIB >nodes implement that mechanism so that any two IPoIB nodes will >interoperate. I still don't see any problem you may have in mind. As long as a sender gets the pkt to the router, why it matter how it gets there? E.g., routers will listen to both the broadcast and the all-router multicast addresses. Does it matter which address a pkt is sent to? As I noted in my previous mail... the onus is on the router. The router is required to listen to multicast packets on both: a) all-router MGID or b) broadcast-GID We could make that explicit in the draft. The second option, which apparently Roy favours is to specify that the nodes must, if the relevant MGID doesn't exist, send the packet to the MGID corresponding to the all-router MGID. This option is fine but it then adds another requirement: All IPoIB nodes MUST request creation request for all-router MGID whether the corresponding IP layer joins the all-router IP address or not. If the fall-back is the broadcast-GID then the end-nodes do not have to do anything special. The current option allows the sender to choose between taking the simple route of 'fall-back to broadcast GID' vs. 'must join all-router MGID'. I am ok with either case and if the 'must join all-router MGID' case is preferable then we can specify that instead. > >> > The >> > text suggests using all-router multicast group or the broadcast >group. >> > If a router is required to create the all-router multicast group (see > >> > the previous comment), then wouldn't it be sufficient to check for >the >> > existence of the all-router multicast group and, if it exists, send >to >> > that? If it doesn't exist, then there can't be any multicast routers > >> > on the link, and since there aren't any local listeners there are no >> > on-link listeners there isn't any need to send the packet. >> >> Don't the code sinppet following 9.B match pretty much what you >described >> above? > >Yes, it does, and if the text matched the code snippet then I wouldn't >have an issue. But the text which supports the code snippet doesn't. I can remove the text if it causes any confusion. I thought it is very obvious if no router exists then there is no need to forward (as illustrated by the code snippet). >The >text basically says you could send to the all-router multicast group OR >the broadcast group. And either should work, as long as the receiving >IPoIB node MUST accept the IP multicast packets regardless of the IB group >over which they are received (I'm not sure I've seen this explicitly >stated in the draft, but I may have missed it). I thought this is required by IP already. But please tell me if I'm wrong. >But do we really need to >have multiple mechanisms to accomplish the same result? Wouldn't we be >better off just choosing one and going with that? And how are we going to >find multiple interoperable implementations for each option when the draft >puts no limits on the approaches which can be taken? The multiple mechanisms were not there in the earlier draft, but were requested later by my co-author. I personally don't see any harm with it but I don't mind taking it out if Vivek agrees with you. Don't remember, could have on reasoning as described above. I think we can take it out and replace it with the condition that the packets are sent to the all-router MGID AND all IPoIB nodes (because any can be a sender) need to request creation report for all-router MGID and then IB_Join it. >> > >> > And shouldn't the IPoIB sender subscribe to the IB multicast group >> > creation events using a wildcard MGID so that it can >> > "SendOnlyNonMember" join the group if a listener appears on the local > >> > IB subnet, or "SendOnlyNonMember" join the all-routers group if a >> > router appears on-link and creates the all-routers multicast group? >> > And doesn't it need to subscribe to the IB multicast group deletion >> > events so that it knows when to switch back to sending to the >> > all-router multicast group and/or stop sending? >> >> Aren't you saying the same thing (more or less) as what is described in >> the section following the code snippet? > >You are right - I must have missed the text. But you need to change the >"should" to a "MUST" in that paragraph. Since the caching part is a "should", the subscription part ought to be a "should" too, right? > >> > >> > But I'm wondering why a node needs to do this at all. Wouldn't it >> > make more sense for the IPoIB node instead create the multicast group > >> > and join the group so that IPoIB multicast routers can join the >group? >> > Yes, the IPoIB sender will need create the group as a "FullMember", >> > but this seems to provide a simpler mapping of IP multicast to IB >> > multicast. >> >> While what you suggested may simplify the procedure, it essentially >> removes the difference between a multicast sender and a multicast >receiver, >> which is wrong. In the IP multicast model a multicast sender doesn't >need >> to be a member of a multicast group to send. The draft has tried to >> keep the same distinction. > >However, you are mapping the IP multicast model to the IB multicast model, >and the two are not the same. The reality is a sender must join an IB >multicast group in order to send to it (albeit as a "SendOnlyNonMember"), This is the big difference that was debated in IBTA. >and this step does not exist in the IP model. I imagine that the vast >majority of the code/complexity of an IPoIB implementation is going to be >dealing with IB multicasting. I was hoping there was some way to reduce >both at an IPoIB host. Maybe it is just wishful thinking. I actually have the same philosophy as well. I'm always against complexity unless it's fully justified. But IB multicast just works differently than IP multicast. We have gone through a number of alternatives and the current one seemed to a good balance between complexity and correctness. I don't remember all the tradeoffs but if we simply require a sender to be a full-member, how would one know when to leave a group, when to delete a group..., etc. Also wouldn't it enable anyone to write a silly sender program to try to send to a million different addresses and cause all the IB multicast resources to be used up? (The join call by IP_ADD_MEMBERSHIP at least places some resource limitation.) Yes, a major consideration has been the limited multicast resources avaialble in IB. Some other issues were such as the case I described a little while back: there is a very large chance of the router not receiving the packet when the sender the group due to the possible delay in the report reaching the router and the router IB_joining the group etc. > >By the way, after thinking about this a little more, I'm not sure that >creating a group as I suggested makes sense in all cases. For instance, >it is only useful for an IP multicast group which has a scope greater than >link-local. For link-local scope, only nodes directly attached to the >IPoIB link are able to receive the packet. Creating the group for the >purpose of forwarding to an IPoIB multicast router is simply wasteful, as >the IPoIB multicast router will not be able to forward the packet to >another IP link. > >A similar optimization can also be taken with the current approach >described in this draft - for an IP multicast group with link-local scope, >if the IB MGID for that IP multicast group does not exist then an IPoIB >node really doesn't need to send the multicast packet to the all-router >MGID or broadcast GID. Correct. This level of details can arguably be left to implementation because it doesn't affect interoperability. But I think this optimization is simple and useful enough that I'll add a note to the draft. Agreed. > >> >- Section 9.0 also indicates that "A multicast sender must join the >> > target multicast group as a "SendOnlyNonMember" before outgoing >> > messages from it can be successfully routed." This text should be >> > clarified to indicate this is only true if the node has not already >> > joined the group as either a "FullMember" or "SendOnlyNonMember". The > >> > If-Then-Else logic below correctly shows this behavior, but this >> > paragraph does not reflect that behavior. >> >> Although your comment is correct, I'd argue this kind of details can >> be found in the IBA spec. It has nothing to do with IPoIB in particular, >> So the question becomes how much IBA info we need to repeat in an IPoIB >RFC. >> Since the code sippet already covers this correctly, if you still >believe >> this needs to be clarified i can certain add more text to it. > >My feeling is enough to describe HOW an IPoIB node will USE the IBA >services, and this is one of those cases. I would prefer to see the text >clarified if you do another revision of the draft, but given the code >snippet describes the correct behavior I wouldn't hold this draft up just >to clarify this paragraph. Ok. > >> >- Section 9.0 indicates that "For the rest of attributes, it is >> > recommended the same values from the all-node multicast/broadcast >> > group be used." Should this instead say "For the rest of the >> > attributes, the same values from the all-node multicast/broadcast >> > group SHOULD be used." Regardless of the wording, this text seems to >> > contradict the Section 7.0 which states a node must "use the rest of >> > the link attributes associated with the group for all future >> > communication on the link. If Section 7.0 is correct, should this be > >> > a MUST instead of a SHOULD? And, if not, under what circumstances >> > would a node choose to not use the same values? >> >> 7.0 describes the attributes used by a node when conducting unicast >> communication. 9.0 describes the attributes used to create a multicast >> group, i.e., for multicast communication. So the question is: >> Must path attributes used for unicast match with those for multicast? >> >> The flexibility allowed in the multicast case in the current draft is >> deliberate. I don't know in reality if this is useful, or even good to >> have. (Comments are welcome.) My design principle has been to not to >> make something a requirement unless it is needed for interoperability. > >Flexibility is often times good, but so is describing a minimal set of >functions necessary for interoperability. If a node selects link >attributes when creating an MGID which does not match the broadcast GID's >attributes, then it is possible that not all nodes which are members of >the IPoIB link will be able to support those attributes. If this happens, >then the two nodes will not be able to communicate using the IP multicast >group mapped to the MGID. All of a sudden, an IPoIB node can't send an >ARP request or Neighbor Solicitation to another node. I think some of these "deliberate" flexibility (or ambuguity) came from the ambuguity of IB itself in some of the mutlicast attributes such as SL, TClass..., etc. It is not clear to me if they must or even can follow the ones for unicast (i.e. described by the broadcast group) in all cases. > >Perhaps it would be better to state that a node which creates a multicast >group MUST use the same values for the attributes as the all-node >multicast/broadcast group, but a node joining a multicast group must not >verify the values match. If the node joining the group can't support the >values for the multicast group, then it should log the error. That way, a >future RFC could describe why/when/how a node would choose to use >different values for the link attributes but still be able to interoperate >with IPoIB nodes. I'll leave the above for IB folks to comment. Jerry > >Roy _______________________________________________ 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 Wed May 7 13:39:14 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 NAA09583 for ; Wed, 7 May 2003 13:39:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47HlR805849; Wed, 7 May 2003 13:47:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47HkI805773 for ; Wed, 7 May 2003 13:46:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09538 for ; Wed, 7 May 2003 13:36:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSsR-0003CN-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:38:47 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19DSsQ-0003Bn-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:38:46 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47Hd6Qs211712; Wed, 7 May 2003 13:39:06 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47Hd5X3095664; Wed, 7 May 2003 11:39:06 -0600 In-Reply-To: To: Vivek Kashyap Cc: ipoverib@ietf.org, "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 01:26:39 PM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 01:26:39 PM, Serialize complete at 05/07/2003 01:26:39 PM, S/MIME Sign failed at 05/07/2003 01:26:39 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/07/2003 11:39:05, Serialize complete at 05/07/2003 11:39:05 Message-ID: Date: Wed, 7 May 2003 13:26:40 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > As I noted in my previous mail... the onus is on the router. The > router is required to listen to multicast packets on both: a) all-router > MGID or b) broadcast-GID > > We could make that explicit in the draft. The second option, which > apparently Roy favours is to specify that the nodes must, if the relevant > MGID doesn't exist, send the packet to the MGID corresponding to the > all-router MGID. This option is fine but it then adds another requirement: > > All IPoIB nodes MUST request creation request for all-router MGID > whether the corresponding IP layer joins the all-router IP address or > not. I'm not sure I understand why an IPoIB host need to request creation of the all-router MGID (I do understand why an IPoIB router must, though). Wouldn't it be sufficient to try to "SendOnlyNonMember" join the all-router MGID and, if the all-router MGID doesn't exist, stop? If the all-router MGID doesn't exist, then it means there are no IP routers on the IPoIB link who can forward the request to any off-link listeners. And, since the multicast group MGID doesn't exist (otherwise, the IPoIB host would have sent to that MGID), we already know there aren't any on-link IPoIB listeners. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed May 7 13:39: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 NAA09600 for ; Wed, 7 May 2003 13:39:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47HmKY05916 for ipoverib-archive@odin.ietf.org; Wed, 7 May 2003 13:48:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47HmJ805913 for ; Wed, 7 May 2003 13:48:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09575 for ; Wed, 7 May 2003 13:38:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSuP-0003D0-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 13:40:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DSuO-0003Cx-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 13:40:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47HlR805849; Wed, 7 May 2003 13:47:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47HkI805773 for ; Wed, 7 May 2003 13:46:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09538 for ; Wed, 7 May 2003 13:36:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSsR-0003CN-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:38:47 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19DSsQ-0003Bn-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:38:46 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47Hd6Qs211712; Wed, 7 May 2003 13:39:06 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47Hd5X3095664; Wed, 7 May 2003 11:39:06 -0600 In-Reply-To: To: Vivek Kashyap Cc: ipoverib@ietf.org, "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 01:26:39 PM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 05/07/2003 01:26:39 PM, Serialize complete at 05/07/2003 01:26:39 PM, S/MIME Sign failed at 05/07/2003 01:26:39 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/07/2003 11:39:05, Serialize complete at 05/07/2003 11:39:05 Message-ID: Date: Wed, 7 May 2003 13:26:40 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > As I noted in my previous mail... the onus is on the router. The > router is required to listen to multicast packets on both: a) all-router > MGID or b) broadcast-GID > > We could make that explicit in the draft. The second option, which > apparently Roy favours is to specify that the nodes must, if the relevant > MGID doesn't exist, send the packet to the MGID corresponding to the > all-router MGID. This option is fine but it then adds another requirement: > > All IPoIB nodes MUST request creation request for all-router MGID > whether the corresponding IP layer joins the all-router IP address or > not. I'm not sure I understand why an IPoIB host need to request creation of the all-router MGID (I do understand why an IPoIB router must, though). Wouldn't it be sufficient to try to "SendOnlyNonMember" join the all-router MGID and, if the all-router MGID doesn't exist, stop? If the all-router MGID doesn't exist, then it means there are no IP routers on the IPoIB link who can forward the request to any off-link listeners. And, since the multicast group MGID doesn't exist (otherwise, the IPoIB host would have sent to that MGID), we already know there aren't any on-link IPoIB listeners. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed May 7 13:49:49 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 NAA09920 for ; Wed, 7 May 2003 13:49:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47HvU806441; Wed, 7 May 2003 13:57:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Hut806378 for ; Wed, 7 May 2003 13:56:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09822 for ; Wed, 7 May 2003 13:47:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DT2i-0003GZ-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:49:24 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19DT2h-0003GJ-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:49:23 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47HnbQs236892; Wed, 7 May 2003 13:49:37 -0400 Received: from d03nm122.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.193.81]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47Hnbng085968; Wed, 7 May 2003 11:49:37 -0600 Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: Roy Brabson Cc: ipoverib@ietf.org, "H.K. Jerry Chu" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Wed, 7 May 2003 10:34:54 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.0.1 [IBM]|April 28, 2003) at 05/07/2003 11:49:36 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > As I noted in my previous mail... the onus is on the router. The > router is required to listen to multicast packets on both: a) all-router > MGID or b) broadcast-GID > > We could make that explicit in the draft. The second option, which > apparently Roy favours is to specify that the nodes must, if the relevant > MGID doesn't exist, send the packet to the MGID corresponding to the > all-router MGID. This option is fine but it then adds another requirement: > > All IPoIB nodes MUST request creation request for all-router MGID > whether the corresponding IP layer joins the all-router IP address or > not. I'm not sure I understand why an IPoIB host need to request creation of the all-router MGID (I do understand why an IPoIB router must, though). Oops! a typo. Not creation -- IB_join. All nodes need to IB_join "SendOnlyNonMember" the all-router MGID whether the IP layer joins the all-router IP address or not. Wouldn't it be sufficient to try to "SendOnlyNonMember" join the all-router MGID and, if the all-router MGID doesn't exist, stop? If the all-router MGID doesn't exist, then it means there are no IP routers on the IPoIB link who can forward the request to any off-link listeners. And, since the multicast group MGID doesn't exist (otherwise, the IPoIB host would have sent to that MGID), we already know there aren't any on-link IPoIB listeners. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed May 7 13:49: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 NAA09940 for ; Wed, 7 May 2003 13:49:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47HwtR06506 for ipoverib-archive@odin.ietf.org; Wed, 7 May 2003 13:58:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Hwt806503 for ; Wed, 7 May 2003 13:58:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09889 for ; Wed, 7 May 2003 13:49:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DT4e-0003HQ-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 13:51:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DT4d-0003HN-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 13:51:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47HvU806441; Wed, 7 May 2003 13:57:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Hut806378 for ; Wed, 7 May 2003 13:56:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09822 for ; Wed, 7 May 2003 13:47:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DT2i-0003GZ-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:49:24 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19DT2h-0003GJ-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:49:23 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47HnbQs236892; Wed, 7 May 2003 13:49:37 -0400 Received: from d03nm122.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.193.81]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47Hnbng085968; Wed, 7 May 2003 11:49:37 -0600 Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: Roy Brabson Cc: ipoverib@ietf.org, "H.K. Jerry Chu" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Wed, 7 May 2003 10:34:54 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.0.1 [IBM]|April 28, 2003) at 05/07/2003 11:49:36 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , > As I noted in my previous mail... the onus is on the router. The > router is required to listen to multicast packets on both: a) all-router > MGID or b) broadcast-GID > > We could make that explicit in the draft. The second option, which > apparently Roy favours is to specify that the nodes must, if the relevant > MGID doesn't exist, send the packet to the MGID corresponding to the > all-router MGID. This option is fine but it then adds another requirement: > > All IPoIB nodes MUST request creation request for all-router MGID > whether the corresponding IP layer joins the all-router IP address or > not. I'm not sure I understand why an IPoIB host need to request creation of the all-router MGID (I do understand why an IPoIB router must, though). Oops! a typo. Not creation -- IB_join. All nodes need to IB_join "SendOnlyNonMember" the all-router MGID whether the IP layer joins the all-router IP address or not. Wouldn't it be sufficient to try to "SendOnlyNonMember" join the all-router MGID and, if the all-router MGID doesn't exist, stop? If the all-router MGID doesn't exist, then it means there are no IP routers on the IPoIB link who can forward the request to any off-link listeners. And, since the multicast group MGID doesn't exist (otherwise, the IPoIB host would have sent to that MGID), we already know there aren't any on-link IPoIB listeners. Roy _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed May 7 13:52:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10066 for ; Wed, 7 May 2003 13:52:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47I02806660; Wed, 7 May 2003 14:00:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47HxO806559 for ; Wed, 7 May 2003 13:59:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09921 for ; Wed, 7 May 2003 13:49:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DT57-0003Hv-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:51:53 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 19DT56-0003HM-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:51:52 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47Hq5Om157576; Wed, 7 May 2003 13:52:06 -0400 Received: from w-vkashyap95.des.sequent.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47Hpv3G096842; Wed, 7 May 2003 13:51:58 -0400 Date: Wed, 7 May 2003 10:48:55 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Kanoj Sarcar cc: ipoverib@ietf.org Subject: Re: [Ipoverib] DHCP clarification In-Reply-To: <3EB857C9.3CEE9AA5@Sun.COM> Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, The case where the B flag is not being set are when the ciaddr contains the IP address. RFC2855 states: Note: As described in [RFC2131], 'ciaddr' MUST be filled in with client's IP address during BOUND, RENEWING or REBINDING state, therefore, the BROADCAST flag MUST NOT be set. In these cases, the DHCP server unicasts DHCPACK message to the address in 'ciaddr'. The link address will be resolved by 1394 ARP. The existing draft has: Note: As described in [RFC2131], 'ciaddr' MUST be filled in with client's IP address during BOUND, RENEWING or REBINDING state, therefore, the BROADCAST flag MUST NOT be set. In these cases, the DHCP server unicasts DHCPACK message to the address in 'ciaddr'. The link address will be resolved by IPoIB ARP. Maybe we should leave it like that. Vivek On Tue, 6 May 2003, Kanoj Sarcar wrote: > Vivek, > > The wording sounds fine; although I am uncomfortable with the "MUST NOT > set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST > NOT restriction required? RFC 2131 leaves the setting of this flag to the > client (as far as I can tell; unless you can quote a specific section that > implies otherwise). Are you worried about servers that might get confused > with the BROADCAST bit in BOUND/RENEWING/REBINDING clients? > > Thanks. > > Kanoj > > > Vivek Kashyap wrote: > > > > Kanoj, > > > > How about the following: > > > > 2.2 Use of the BROADCAST flag > > > > A DHCP client on IPoIB MUST set the BROADCAST flag and set > > 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages > > when it is not in BOUND or RENEWING states. This ensures that > > the server (or the relay agent) broadcasts its reply to > > the client. > > > > In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be > > filled in with the client's IP address [RFC2131]. The > > BROADCAST flag MUST NOT be set in these cases since the DHCP > > server, after resolving the 'ciaddr' address using ARP, > > unicasts the DHCPACK message to the client. > > > > Vivek > > > > > Hi, > > > > > > While going over section 2 of ipoib/dhcp draft, I realized that it > > > can be cleaned up somewhat (in my opinion, ie; to others, it might > > > be quite clear already). Accordingly, I came up with the following > > > verbiage. If there are some improvements in here, it should be used > > > to reword the section. > > > > > > 2.2 Use of the BROADCAST flag > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > > > set 'ciaddr' to zero) in DHCPREQUEST messages and > > > DHCPDISCOVER messages sent when it is not in the BOUND > > > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > > > states). > > > > > > For other cases, the client SHOULD NOT set the BROADCAST > > > flag if it can receive the server's unicast responses. > > > As described in [RFC2131], 'ciaddr' MUST be filled in > > > with client's IP address during BOUND, RENEWING or > > > REBINDING states. In these cases, > > > the DHCP server attempts to unicast DHCP responses to > > > the address filled in by the client in 'ciaddr' by using > > > IPoIB ARP to resolve the link address. > > > > > > The reason I think this is clearer is because: > > > 1. It makes it clear that the BROADCAST flag has to be set in > > > DHCPDISCOVER. > > > 2. It makes it clear that the BROADCAST flag needs to be set > > > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > > > 3. It allows that servers might broadcast responses > > > (allowed per 2131, see last paragraph section 4.1). > > > 4. It allows that servers might respond with DHCPNAK. > > > 5. It allows that there might be other reasons for clients to > > > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > > > 6. It does not make it illegal for clients to set BROADCAST bit > > > for whatever other reason. Unless there is a good reason (other > > > than known issues) to make it illegal, I am not sure if this > > > was intended. I could not find any MUST NOT reference wrt BROADCAST > > > bit in 2131. > > > > > > Thanks. > > > > > > Kanoj > > > _______________________________________________ > > > IPoverIB mailing list > > > IPoverIB@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > __ > > > > Vivek Kashyap > > Linux Technology Center, IBM > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed May 7 13:52:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10081 for ; Wed, 7 May 2003 13:52:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47I1QJ06795 for ipoverib-archive@odin.ietf.org; Wed, 7 May 2003 14:01:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47I1Q806792 for ; Wed, 7 May 2003 14:01:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10044 for ; Wed, 7 May 2003 13:51:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DT75-0003J6-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 13:53:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DT75-0003J3-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 13:53:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47I02806660; Wed, 7 May 2003 14:00:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47HxO806559 for ; Wed, 7 May 2003 13:59:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09921 for ; Wed, 7 May 2003 13:49:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DT57-0003Hv-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:51:53 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 19DT56-0003HM-00 for ipoverib@ietf.org; Wed, 07 May 2003 13:51:52 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47Hq5Om157576; Wed, 7 May 2003 13:52:06 -0400 Received: from w-vkashyap95.des.sequent.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47Hpv3G096842; Wed, 7 May 2003 13:51:58 -0400 Date: Wed, 7 May 2003 10:48:55 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Kanoj Sarcar cc: ipoverib@ietf.org Subject: Re: [Ipoverib] DHCP clarification In-Reply-To: <3EB857C9.3CEE9AA5@Sun.COM> Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, The case where the B flag is not being set are when the ciaddr contains the IP address. RFC2855 states: Note: As described in [RFC2131], 'ciaddr' MUST be filled in with client's IP address during BOUND, RENEWING or REBINDING state, therefore, the BROADCAST flag MUST NOT be set. In these cases, the DHCP server unicasts DHCPACK message to the address in 'ciaddr'. The link address will be resolved by 1394 ARP. The existing draft has: Note: As described in [RFC2131], 'ciaddr' MUST be filled in with client's IP address during BOUND, RENEWING or REBINDING state, therefore, the BROADCAST flag MUST NOT be set. In these cases, the DHCP server unicasts DHCPACK message to the address in 'ciaddr'. The link address will be resolved by IPoIB ARP. Maybe we should leave it like that. Vivek On Tue, 6 May 2003, Kanoj Sarcar wrote: > Vivek, > > The wording sounds fine; although I am uncomfortable with the "MUST NOT > set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST > NOT restriction required? RFC 2131 leaves the setting of this flag to the > client (as far as I can tell; unless you can quote a specific section that > implies otherwise). Are you worried about servers that might get confused > with the BROADCAST bit in BOUND/RENEWING/REBINDING clients? > > Thanks. > > Kanoj > > > Vivek Kashyap wrote: > > > > Kanoj, > > > > How about the following: > > > > 2.2 Use of the BROADCAST flag > > > > A DHCP client on IPoIB MUST set the BROADCAST flag and set > > 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages > > when it is not in BOUND or RENEWING states. This ensures that > > the server (or the relay agent) broadcasts its reply to > > the client. > > > > In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be > > filled in with the client's IP address [RFC2131]. The > > BROADCAST flag MUST NOT be set in these cases since the DHCP > > server, after resolving the 'ciaddr' address using ARP, > > unicasts the DHCPACK message to the client. > > > > Vivek > > > > > Hi, > > > > > > While going over section 2 of ipoib/dhcp draft, I realized that it > > > can be cleaned up somewhat (in my opinion, ie; to others, it might > > > be quite clear already). Accordingly, I came up with the following > > > verbiage. If there are some improvements in here, it should be used > > > to reword the section. > > > > > > 2.2 Use of the BROADCAST flag > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > > > set 'ciaddr' to zero) in DHCPREQUEST messages and > > > DHCPDISCOVER messages sent when it is not in the BOUND > > > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > > > states). > > > > > > For other cases, the client SHOULD NOT set the BROADCAST > > > flag if it can receive the server's unicast responses. > > > As described in [RFC2131], 'ciaddr' MUST be filled in > > > with client's IP address during BOUND, RENEWING or > > > REBINDING states. In these cases, > > > the DHCP server attempts to unicast DHCP responses to > > > the address filled in by the client in 'ciaddr' by using > > > IPoIB ARP to resolve the link address. > > > > > > The reason I think this is clearer is because: > > > 1. It makes it clear that the BROADCAST flag has to be set in > > > DHCPDISCOVER. > > > 2. It makes it clear that the BROADCAST flag needs to be set > > > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > > > 3. It allows that servers might broadcast responses > > > (allowed per 2131, see last paragraph section 4.1). > > > 4. It allows that servers might respond with DHCPNAK. > > > 5. It allows that there might be other reasons for clients to > > > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > > > 6. It does not make it illegal for clients to set BROADCAST bit > > > for whatever other reason. Unless there is a good reason (other > > > than known issues) to make it illegal, I am not sure if this > > > was intended. I could not find any MUST NOT reference wrt BROADCAST > > > bit in 2131. > > > > > > Thanks. > > > > > > Kanoj > > > _______________________________________________ > > > IPoverIB mailing list > > > IPoverIB@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > __ > > > > Vivek Kashyap > > Linux Technology Center, IBM > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed May 7 15:18:53 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 PAA14163 for ; Wed, 7 May 2003 15:18:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47JQ6814625; Wed, 7 May 2003 15:26:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47JPc814598 for ; Wed, 7 May 2003 15:25:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14056 for ; Wed, 7 May 2003 15:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DUQW-0003xv-00 for ipoverib@ietf.org; Wed, 07 May 2003 15:18:04 -0400 Received: from patan.sun.com ([192.18.98.43] helo=brmea-mail-2.sun.com) by ietf-mx with esmtp (Exim 4.12) id 19DUQW-0003xs-00 for ipoverib@ietf.org; Wed, 07 May 2003 15:18:04 -0400 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h47JIu1C025373; Wed, 7 May 2003 13:18:56 -0600 (MDT) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47JIuuc025552; Wed, 7 May 2003 12:18:56 -0700 (PDT) Received: from Sun.COM (sr1-usun-06.Eng.Sun.COM [129.144.135.9]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0HEJ0041S6ZJ5L@ha1sun-mail1.eng.sun.com>; Wed, 07 May 2003 12:18:56 -0700 (PDT) Date: Wed, 07 May 2003 12:18:55 -0700 From: Kanoj Sarcar Subject: Re: [Ipoverib] DHCP clarification To: Vivek Kashyap Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3EB95C1F.80E93A78@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 Vivek, Yes, I had noticed 2855, and knew that most of the material in that applies to IPoIB too. But I was not sure why 2855 went ahead and put that restriction (specifically since 2131 doesn't), and I was questioning whether it is really required. In any case, I am okay if you want to keep the same restriction in ipoib/dhcp as in 2855. Thanks. Kanoj Vivek Kashyap wrote: > > Kanoj, > > The case where the B flag is not being set are when the ciaddr > contains the IP address. > > RFC2855 states: > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > client's IP address during BOUND, RENEWING or REBINDING state, > therefore, the BROADCAST flag MUST NOT be set. In these cases, > the DHCP server unicasts DHCPACK message to the address in > 'ciaddr'. The link address will be resolved by 1394 ARP. > > The existing draft has: > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > client's IP address during BOUND, RENEWING or REBINDING state, > therefore, the BROADCAST flag MUST NOT be set. In these cases, > the DHCP server unicasts DHCPACK message to the address in > 'ciaddr'. The link address will be resolved by IPoIB ARP. > > Maybe we should leave it like that. > > Vivek > > On Tue, 6 May 2003, Kanoj Sarcar wrote: > > > Vivek, > > > > The wording sounds fine; although I am uncomfortable with the "MUST NOT > > set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST > > NOT restriction required? RFC 2131 leaves the setting of this flag to the > > client (as far as I can tell; unless you can quote a specific section that > > implies otherwise). Are you worried about servers that might get confused > > with the BROADCAST bit in BOUND/RENEWING/REBINDING clients? > > > > Thanks. > > > > Kanoj > > > > > > Vivek Kashyap wrote: > > > > > > Kanoj, > > > > > > How about the following: > > > > > > 2.2 Use of the BROADCAST flag > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag and set > > > 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages > > > when it is not in BOUND or RENEWING states. This ensures that > > > the server (or the relay agent) broadcasts its reply to > > > the client. > > > > > > In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be > > > filled in with the client's IP address [RFC2131]. The > > > BROADCAST flag MUST NOT be set in these cases since the DHCP > > > server, after resolving the 'ciaddr' address using ARP, > > > unicasts the DHCPACK message to the client. > > > > > > Vivek > > > > > > > Hi, > > > > > > > > While going over section 2 of ipoib/dhcp draft, I realized that it > > > > can be cleaned up somewhat (in my opinion, ie; to others, it might > > > > be quite clear already). Accordingly, I came up with the following > > > > verbiage. If there are some improvements in here, it should be used > > > > to reword the section. > > > > > > > > 2.2 Use of the BROADCAST flag > > > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > > > > set 'ciaddr' to zero) in DHCPREQUEST messages and > > > > DHCPDISCOVER messages sent when it is not in the BOUND > > > > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > > > > states). > > > > > > > > For other cases, the client SHOULD NOT set the BROADCAST > > > > flag if it can receive the server's unicast responses. > > > > As described in [RFC2131], 'ciaddr' MUST be filled in > > > > with client's IP address during BOUND, RENEWING or > > > > REBINDING states. In these cases, > > > > the DHCP server attempts to unicast DHCP responses to > > > > the address filled in by the client in 'ciaddr' by using > > > > IPoIB ARP to resolve the link address. > > > > > > > > The reason I think this is clearer is because: > > > > 1. It makes it clear that the BROADCAST flag has to be set in > > > > DHCPDISCOVER. > > > > 2. It makes it clear that the BROADCAST flag needs to be set > > > > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > > > > 3. It allows that servers might broadcast responses > > > > (allowed per 2131, see last paragraph section 4.1). > > > > 4. It allows that servers might respond with DHCPNAK. > > > > 5. It allows that there might be other reasons for clients to > > > > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > > > > 6. It does not make it illegal for clients to set BROADCAST bit > > > > for whatever other reason. Unless there is a good reason (other > > > > than known issues) to make it illegal, I am not sure if this > > > > was intended. I could not find any MUST NOT reference wrt BROADCAST > > > > bit in 2131. > > > > > > > > Thanks. > > > > > > > > Kanoj > > > > _______________________________________________ > > > > IPoverIB mailing list > > > > IPoverIB@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > > > > > __ > > > > > > Vivek Kashyap > > > Linux Technology Center, IBM > > _______________________________________________ > > IPoverIB mailing list > > IPoverIB@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > __ > > Vivek Kashyap > Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed May 7 15:18:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14177 for ; Wed, 7 May 2003 15:18:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47JS2114822 for ipoverib-archive@odin.ietf.org; Wed, 7 May 2003 15:28:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47JS2814819 for ; Wed, 7 May 2003 15:28:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14149 for ; Wed, 7 May 2003 15:18:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DUSr-0003ze-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 15:20:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DUSq-0003zU-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 15:20:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47JQ6814625; Wed, 7 May 2003 15:26:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47JPc814598 for ; Wed, 7 May 2003 15:25:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14056 for ; Wed, 7 May 2003 15:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DUQW-0003xv-00 for ipoverib@ietf.org; Wed, 07 May 2003 15:18:04 -0400 Received: from patan.sun.com ([192.18.98.43] helo=brmea-mail-2.sun.com) by ietf-mx with esmtp (Exim 4.12) id 19DUQW-0003xs-00 for ipoverib@ietf.org; Wed, 07 May 2003 15:18:04 -0400 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h47JIu1C025373; Wed, 7 May 2003 13:18:56 -0600 (MDT) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47JIuuc025552; Wed, 7 May 2003 12:18:56 -0700 (PDT) Received: from Sun.COM (sr1-usun-06.Eng.Sun.COM [129.144.135.9]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0HEJ0041S6ZJ5L@ha1sun-mail1.eng.sun.com>; Wed, 07 May 2003 12:18:56 -0700 (PDT) Date: Wed, 07 May 2003 12:18:55 -0700 From: Kanoj Sarcar Subject: Re: [Ipoverib] DHCP clarification To: Vivek Kashyap Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3EB95C1F.80E93A78@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 Vivek, Yes, I had noticed 2855, and knew that most of the material in that applies to IPoIB too. But I was not sure why 2855 went ahead and put that restriction (specifically since 2131 doesn't), and I was questioning whether it is really required. In any case, I am okay if you want to keep the same restriction in ipoib/dhcp as in 2855. Thanks. Kanoj Vivek Kashyap wrote: > > Kanoj, > > The case where the B flag is not being set are when the ciaddr > contains the IP address. > > RFC2855 states: > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > client's IP address during BOUND, RENEWING or REBINDING state, > therefore, the BROADCAST flag MUST NOT be set. In these cases, > the DHCP server unicasts DHCPACK message to the address in > 'ciaddr'. The link address will be resolved by 1394 ARP. > > The existing draft has: > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > client's IP address during BOUND, RENEWING or REBINDING state, > therefore, the BROADCAST flag MUST NOT be set. In these cases, > the DHCP server unicasts DHCPACK message to the address in > 'ciaddr'. The link address will be resolved by IPoIB ARP. > > Maybe we should leave it like that. > > Vivek > > On Tue, 6 May 2003, Kanoj Sarcar wrote: > > > Vivek, > > > > The wording sounds fine; although I am uncomfortable with the "MUST NOT > > set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST > > NOT restriction required? RFC 2131 leaves the setting of this flag to the > > client (as far as I can tell; unless you can quote a specific section that > > implies otherwise). Are you worried about servers that might get confused > > with the BROADCAST bit in BOUND/RENEWING/REBINDING clients? > > > > Thanks. > > > > Kanoj > > > > > > Vivek Kashyap wrote: > > > > > > Kanoj, > > > > > > How about the following: > > > > > > 2.2 Use of the BROADCAST flag > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag and set > > > 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages > > > when it is not in BOUND or RENEWING states. This ensures that > > > the server (or the relay agent) broadcasts its reply to > > > the client. > > > > > > In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be > > > filled in with the client's IP address [RFC2131]. The > > > BROADCAST flag MUST NOT be set in these cases since the DHCP > > > server, after resolving the 'ciaddr' address using ARP, > > > unicasts the DHCPACK message to the client. > > > > > > Vivek > > > > > > > Hi, > > > > > > > > While going over section 2 of ipoib/dhcp draft, I realized that it > > > > can be cleaned up somewhat (in my opinion, ie; to others, it might > > > > be quite clear already). Accordingly, I came up with the following > > > > verbiage. If there are some improvements in here, it should be used > > > > to reword the section. > > > > > > > > 2.2 Use of the BROADCAST flag > > > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > > > > set 'ciaddr' to zero) in DHCPREQUEST messages and > > > > DHCPDISCOVER messages sent when it is not in the BOUND > > > > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > > > > states). > > > > > > > > For other cases, the client SHOULD NOT set the BROADCAST > > > > flag if it can receive the server's unicast responses. > > > > As described in [RFC2131], 'ciaddr' MUST be filled in > > > > with client's IP address during BOUND, RENEWING or > > > > REBINDING states. In these cases, > > > > the DHCP server attempts to unicast DHCP responses to > > > > the address filled in by the client in 'ciaddr' by using > > > > IPoIB ARP to resolve the link address. > > > > > > > > The reason I think this is clearer is because: > > > > 1. It makes it clear that the BROADCAST flag has to be set in > > > > DHCPDISCOVER. > > > > 2. It makes it clear that the BROADCAST flag needs to be set > > > > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > > > > 3. It allows that servers might broadcast responses > > > > (allowed per 2131, see last paragraph section 4.1). > > > > 4. It allows that servers might respond with DHCPNAK. > > > > 5. It allows that there might be other reasons for clients to > > > > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > > > > 6. It does not make it illegal for clients to set BROADCAST bit > > > > for whatever other reason. Unless there is a good reason (other > > > > than known issues) to make it illegal, I am not sure if this > > > > was intended. I could not find any MUST NOT reference wrt BROADCAST > > > > bit in 2131. > > > > > > > > Thanks. > > > > > > > > Kanoj > > > > _______________________________________________ > > > > IPoverIB mailing list > > > > IPoverIB@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > > > > > __ > > > > > > Vivek Kashyap > > > Linux Technology Center, IBM > > _______________________________________________ > > IPoverIB mailing list > > IPoverIB@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > __ > > Vivek Kashyap > Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed May 7 18:37: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 SAA21147 for ; Wed, 7 May 2003 18:37:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47MjH831582; Wed, 7 May 2003 18:45:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47MiX831546 for ; Wed, 7 May 2003 18:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21114 for ; Wed, 7 May 2003 18:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DXWz-0005MR-00 for ipoverib@ietf.org; Wed, 07 May 2003 18:36:57 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19DXWy-0005MO-00 for ipoverib@ietf.org; Wed, 07 May 2003 18:36:56 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47MbGQs198364; Wed, 7 May 2003 18:37:16 -0400 Received: from w-vkashyap95.des.sequent.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47MbFGt087260; Wed, 7 May 2003 16:37:15 -0600 Date: Wed, 7 May 2003 15:34:13 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Kanoj Sarcar cc: ipoverib@ietf.org Subject: Re: [Ipoverib] DHCP clarification In-Reply-To: <3EB95C1F.80E93A78@Sun.COM> Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , On Wed, 7 May 2003, Kanoj Sarcar wrote: > Vivek, > > Yes, I had noticed 2855, and knew that most of the material in > that applies to IPoIB too. But I was not sure why 2855 went ahead and put that > restriction (specifically since 2131 doesn't), and I was questioning whether > it is really required. I take the reasoning behind RFC2855 to be as follows: RFC2131 states: "A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. " Therefore: In the case of BOUND/RENEWING/REBINDING states the client stack has the IP address. Therefore, though the RFC doesn't say it explicitly (or at least I didn't find such a statement on a search), I still read the RFC as stating that the B flag is not to be set in these states. RFC2131 does explicitly say that a client MUST include the 'ciaddr' value in these states. Vivek > > In any case, I am okay if you want to keep the same restriction in ipoib/dhcp > as in 2855. > > Thanks. > > Kanoj > > Vivek Kashyap wrote: > > > > Kanoj, > > > > The case where the B flag is not being set are when the ciaddr > > contains the IP address. > > > > RFC2855 states: > > > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > > client's IP address during BOUND, RENEWING or REBINDING state, > > therefore, the BROADCAST flag MUST NOT be set. In these cases, > > the DHCP server unicasts DHCPACK message to the address in > > 'ciaddr'. The link address will be resolved by 1394 ARP. > > > > The existing draft has: > > > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > > client's IP address during BOUND, RENEWING or REBINDING state, > > therefore, the BROADCAST flag MUST NOT be set. In these cases, > > the DHCP server unicasts DHCPACK message to the address in > > 'ciaddr'. The link address will be resolved by IPoIB ARP. > > > > Maybe we should leave it like that. > > > > Vivek > > > > On Tue, 6 May 2003, Kanoj Sarcar wrote: > > > > > Vivek, > > > > > > The wording sounds fine; although I am uncomfortable with the "MUST NOT > > > set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST > > > NOT restriction required? RFC 2131 leaves the setting of this flag to the > > > client (as far as I can tell; unless you can quote a specific section that > > > implies otherwise). Are you worried about servers that might get confused > > > with the BROADCAST bit in BOUND/RENEWING/REBINDING clients? > > > > > > Thanks. > > > > > > Kanoj > > > > > > > > > Vivek Kashyap wrote: > > > > > > > > Kanoj, > > > > > > > > How about the following: > > > > > > > > 2.2 Use of the BROADCAST flag > > > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag and set > > > > 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages > > > > when it is not in BOUND or RENEWING states. This ensures that > > > > the server (or the relay agent) broadcasts its reply to > > > > the client. > > > > > > > > In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be > > > > filled in with the client's IP address [RFC2131]. The > > > > BROADCAST flag MUST NOT be set in these cases since the DHCP > > > > server, after resolving the 'ciaddr' address using ARP, > > > > unicasts the DHCPACK message to the client. > > > > > > > > Vivek > > > > > > > > > Hi, > > > > > > > > > > While going over section 2 of ipoib/dhcp draft, I realized that it > > > > > can be cleaned up somewhat (in my opinion, ie; to others, it might > > > > > be quite clear already). Accordingly, I came up with the following > > > > > verbiage. If there are some improvements in here, it should be used > > > > > to reword the section. > > > > > > > > > > 2.2 Use of the BROADCAST flag > > > > > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > > > > > set 'ciaddr' to zero) in DHCPREQUEST messages and > > > > > DHCPDISCOVER messages sent when it is not in the BOUND > > > > > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > > > > > states). > > > > > > > > > > For other cases, the client SHOULD NOT set the BROADCAST > > > > > flag if it can receive the server's unicast responses. > > > > > As described in [RFC2131], 'ciaddr' MUST be filled in > > > > > with client's IP address during BOUND, RENEWING or > > > > > REBINDING states. In these cases, > > > > > the DHCP server attempts to unicast DHCP responses to > > > > > the address filled in by the client in 'ciaddr' by using > > > > > IPoIB ARP to resolve the link address. > > > > > > > > > > The reason I think this is clearer is because: > > > > > 1. It makes it clear that the BROADCAST flag has to be set in > > > > > DHCPDISCOVER. > > > > > 2. It makes it clear that the BROADCAST flag needs to be set > > > > > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > > > > > 3. It allows that servers might broadcast responses > > > > > (allowed per 2131, see last paragraph section 4.1). > > > > > 4. It allows that servers might respond with DHCPNAK. > > > > > 5. It allows that there might be other reasons for clients to > > > > > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > > > > > 6. It does not make it illegal for clients to set BROADCAST bit > > > > > for whatever other reason. Unless there is a good reason (other > > > > > than known issues) to make it illegal, I am not sure if this > > > > > was intended. I could not find any MUST NOT reference wrt BROADCAST > > > > > bit in 2131. > > > > > > > > > > Thanks. > > > > > > > > > > Kanoj > > > > > _______________________________________________ > > > > > IPoverIB mailing list > > > > > IPoverIB@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > > > > > > > > > __ > > > > > > > > Vivek Kashyap > > > > Linux Technology Center, IBM > > > _______________________________________________ > > > IPoverIB mailing list > > > IPoverIB@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > __ > > > > Vivek Kashyap > > Linux Technology Center, IBM > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed May 7 18:37: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 SAA21161 for ; Wed, 7 May 2003 18:37:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47MkE931633 for ipoverib-archive@odin.ietf.org; Wed, 7 May 2003 18:46:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47MkE831630 for ; Wed, 7 May 2003 18:46:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21133 for ; Wed, 7 May 2003 18:36:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DXYc-0005N8-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 18:38:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DXYb-0005N5-00 for ipoverib-web-archive@ietf.org; Wed, 07 May 2003 18:38:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47MjH831582; Wed, 7 May 2003 18:45:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47MiX831546 for ; Wed, 7 May 2003 18:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21114 for ; Wed, 7 May 2003 18:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DXWz-0005MR-00 for ipoverib@ietf.org; Wed, 07 May 2003 18:36:57 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19DXWy-0005MO-00 for ipoverib@ietf.org; Wed, 07 May 2003 18:36:56 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47MbGQs198364; Wed, 7 May 2003 18:37:16 -0400 Received: from w-vkashyap95.des.sequent.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47MbFGt087260; Wed, 7 May 2003 16:37:15 -0600 Date: Wed, 7 May 2003 15:34:13 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Kanoj Sarcar cc: ipoverib@ietf.org Subject: Re: [Ipoverib] DHCP clarification In-Reply-To: <3EB95C1F.80E93A78@Sun.COM> Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , On Wed, 7 May 2003, Kanoj Sarcar wrote: > Vivek, > > Yes, I had noticed 2855, and knew that most of the material in > that applies to IPoIB too. But I was not sure why 2855 went ahead and put that > restriction (specifically since 2131 doesn't), and I was questioning whether > it is really required. I take the reasoning behind RFC2855 to be as follows: RFC2131 states: "A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. " Therefore: In the case of BOUND/RENEWING/REBINDING states the client stack has the IP address. Therefore, though the RFC doesn't say it explicitly (or at least I didn't find such a statement on a search), I still read the RFC as stating that the B flag is not to be set in these states. RFC2131 does explicitly say that a client MUST include the 'ciaddr' value in these states. Vivek > > In any case, I am okay if you want to keep the same restriction in ipoib/dhcp > as in 2855. > > Thanks. > > Kanoj > > Vivek Kashyap wrote: > > > > Kanoj, > > > > The case where the B flag is not being set are when the ciaddr > > contains the IP address. > > > > RFC2855 states: > > > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > > client's IP address during BOUND, RENEWING or REBINDING state, > > therefore, the BROADCAST flag MUST NOT be set. In these cases, > > the DHCP server unicasts DHCPACK message to the address in > > 'ciaddr'. The link address will be resolved by 1394 ARP. > > > > The existing draft has: > > > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > > client's IP address during BOUND, RENEWING or REBINDING state, > > therefore, the BROADCAST flag MUST NOT be set. In these cases, > > the DHCP server unicasts DHCPACK message to the address in > > 'ciaddr'. The link address will be resolved by IPoIB ARP. > > > > Maybe we should leave it like that. > > > > Vivek > > > > On Tue, 6 May 2003, Kanoj Sarcar wrote: > > > > > Vivek, > > > > > > The wording sounds fine; although I am uncomfortable with the "MUST NOT > > > set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST > > > NOT restriction required? RFC 2131 leaves the setting of this flag to the > > > client (as far as I can tell; unless you can quote a specific section that > > > implies otherwise). Are you worried about servers that might get confused > > > with the BROADCAST bit in BOUND/RENEWING/REBINDING clients? > > > > > > Thanks. > > > > > > Kanoj > > > > > > > > > Vivek Kashyap wrote: > > > > > > > > Kanoj, > > > > > > > > How about the following: > > > > > > > > 2.2 Use of the BROADCAST flag > > > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag and set > > > > 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages > > > > when it is not in BOUND or RENEWING states. This ensures that > > > > the server (or the relay agent) broadcasts its reply to > > > > the client. > > > > > > > > In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be > > > > filled in with the client's IP address [RFC2131]. The > > > > BROADCAST flag MUST NOT be set in these cases since the DHCP > > > > server, after resolving the 'ciaddr' address using ARP, > > > > unicasts the DHCPACK message to the client. > > > > > > > > Vivek > > > > > > > > > Hi, > > > > > > > > > > While going over section 2 of ipoib/dhcp draft, I realized that it > > > > > can be cleaned up somewhat (in my opinion, ie; to others, it might > > > > > be quite clear already). Accordingly, I came up with the following > > > > > verbiage. If there are some improvements in here, it should be used > > > > > to reword the section. > > > > > > > > > > 2.2 Use of the BROADCAST flag > > > > > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > > > > > set 'ciaddr' to zero) in DHCPREQUEST messages and > > > > > DHCPDISCOVER messages sent when it is not in the BOUND > > > > > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > > > > > states). > > > > > > > > > > For other cases, the client SHOULD NOT set the BROADCAST > > > > > flag if it can receive the server's unicast responses. > > > > > As described in [RFC2131], 'ciaddr' MUST be filled in > > > > > with client's IP address during BOUND, RENEWING or > > > > > REBINDING states. In these cases, > > > > > the DHCP server attempts to unicast DHCP responses to > > > > > the address filled in by the client in 'ciaddr' by using > > > > > IPoIB ARP to resolve the link address. > > > > > > > > > > The reason I think this is clearer is because: > > > > > 1. It makes it clear that the BROADCAST flag has to be set in > > > > > DHCPDISCOVER. > > > > > 2. It makes it clear that the BROADCAST flag needs to be set > > > > > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > > > > > 3. It allows that servers might broadcast responses > > > > > (allowed per 2131, see last paragraph section 4.1). > > > > > 4. It allows that servers might respond with DHCPNAK. > > > > > 5. It allows that there might be other reasons for clients to > > > > > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > > > > > 6. It does not make it illegal for clients to set BROADCAST bit > > > > > for whatever other reason. Unless there is a good reason (other > > > > > than known issues) to make it illegal, I am not sure if this > > > > > was intended. I could not find any MUST NOT reference wrt BROADCAST > > > > > bit in 2131. > > > > > > > > > > Thanks. > > > > > > > > > > Kanoj > > > > > _______________________________________________ > > > > > IPoverIB mailing list > > > > > IPoverIB@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > > > > > > > > > __ > > > > > > > > Vivek Kashyap > > > > Linux Technology Center, IBM > > > _______________________________________________ > > > IPoverIB mailing list > > > IPoverIB@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > __ > > > > Vivek Kashyap > > Linux Technology Center, IBM > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Fri May 9 16:39: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 QAA01297 for ; Fri, 9 May 2003 16:39:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Km2811498; Fri, 9 May 2003 16:48:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Klm811440 for ; Fri, 9 May 2003 16:47:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01174 for ; Fri, 9 May 2003 16:37:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEe9-0007GT-00 for ipoverib@ietf.org; Fri, 09 May 2003 16:39:13 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19EEe7-0007Fk-00 for ipoverib@ietf.org; Fri, 09 May 2003 16:39:12 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h49KdQYp194014; Fri, 9 May 2003 16:39:26 -0400 Received: from w-vkashyap95.des.sequent.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h49KdOVc215170; Fri, 9 May 2003 14:39:25 -0600 Date: Fri, 9 May 2003 13:36:22 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Kanoj Sarcar cc: ipoverib@ietf.org Subject: Re: [Ipoverib] DHCP clarification In-Reply-To: Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, I think we can leave the draft as is (draft-ietf-ipoib-dhcp-over-infiniband-05.txt). Vivek On Wed, 7 May 2003, Vivek Kashyap wrote: > On Wed, 7 May 2003, Kanoj Sarcar wrote: > > > Vivek, > > > > Yes, I had noticed 2855, and knew that most of the material in > > that applies to IPoIB too. But I was not sure why 2855 went ahead and put that > > restriction (specifically since 2131 doesn't), and I was questioning whether > > it is really required. > > I take the reasoning behind RFC2855 to be as follows: > > RFC2131 states: > > "A client that cannot receive unicast IP datagrams until its protocol > software has been configured with an IP address SHOULD set > the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or > DHCPREQUEST messages that client sends. The BROADCAST bit will > provide a hint to the DHCP server and BOOTP relay agent to broadcast > any messages to the client on the client's subnet. A client that can > receive unicast IP datagrams before its protocol software has been > configured SHOULD clear the BROADCAST bit to 0. " > > Therefore: > > In the case of BOUND/RENEWING/REBINDING states the client stack > has the IP address. Therefore, though the RFC doesn't say it > explicitly (or at least I didn't find such a statement on a > search), I still read the RFC as stating that the B flag is not > to be set in these states. RFC2131 does explicitly say that a > client MUST include the 'ciaddr' value in these states. > > > Vivek > > > > > In any case, I am okay if you want to keep the same restriction in ipoib/dhcp > > as in 2855. > > > > Thanks. > > > > Kanoj > > > > Vivek Kashyap wrote: > > > > > > Kanoj, > > > > > > The case where the B flag is not being set are when the ciaddr > > > contains the IP address. > > > > > > RFC2855 states: > > > > > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > > > client's IP address during BOUND, RENEWING or REBINDING state, > > > therefore, the BROADCAST flag MUST NOT be set. In these cases, > > > the DHCP server unicasts DHCPACK message to the address in > > > 'ciaddr'. The link address will be resolved by 1394 ARP. > > > > > > The existing draft has: > > > > > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > > > client's IP address during BOUND, RENEWING or REBINDING state, > > > therefore, the BROADCAST flag MUST NOT be set. In these cases, > > > the DHCP server unicasts DHCPACK message to the address in > > > 'ciaddr'. The link address will be resolved by IPoIB ARP. > > > > > > Maybe we should leave it like that. > > > > > > Vivek > > > > > > On Tue, 6 May 2003, Kanoj Sarcar wrote: > > > > > > > Vivek, > > > > > > > > The wording sounds fine; although I am uncomfortable with the "MUST NOT > > > > set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST > > > > NOT restriction required? RFC 2131 leaves the setting of this flag to the > > > > client (as far as I can tell; unless you can quote a specific section that > > > > implies otherwise). Are you worried about servers that might get confused > > > > with the BROADCAST bit in BOUND/RENEWING/REBINDING clients? > > > > > > > > Thanks. > > > > > > > > Kanoj > > > > > > > > > > > > Vivek Kashyap wrote: > > > > > > > > > > Kanoj, > > > > > > > > > > How about the following: > > > > > > > > > > 2.2 Use of the BROADCAST flag > > > > > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag and set > > > > > 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages > > > > > when it is not in BOUND or RENEWING states. This ensures that > > > > > the server (or the relay agent) broadcasts its reply to > > > > > the client. > > > > > > > > > > In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be > > > > > filled in with the client's IP address [RFC2131]. The > > > > > BROADCAST flag MUST NOT be set in these cases since the DHCP > > > > > server, after resolving the 'ciaddr' address using ARP, > > > > > unicasts the DHCPACK message to the client. > > > > > > > > > > Vivek > > > > > > > > > > > Hi, > > > > > > > > > > > > While going over section 2 of ipoib/dhcp draft, I realized that it > > > > > > can be cleaned up somewhat (in my opinion, ie; to others, it might > > > > > > be quite clear already). Accordingly, I came up with the following > > > > > > verbiage. If there are some improvements in here, it should be used > > > > > > to reword the section. > > > > > > > > > > > > 2.2 Use of the BROADCAST flag > > > > > > > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > > > > > > set 'ciaddr' to zero) in DHCPREQUEST messages and > > > > > > DHCPDISCOVER messages sent when it is not in the BOUND > > > > > > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > > > > > > states). > > > > > > > > > > > > For other cases, the client SHOULD NOT set the BROADCAST > > > > > > flag if it can receive the server's unicast responses. > > > > > > As described in [RFC2131], 'ciaddr' MUST be filled in > > > > > > with client's IP address during BOUND, RENEWING or > > > > > > REBINDING states. In these cases, > > > > > > the DHCP server attempts to unicast DHCP responses to > > > > > > the address filled in by the client in 'ciaddr' by using > > > > > > IPoIB ARP to resolve the link address. > > > > > > > > > > > > The reason I think this is clearer is because: > > > > > > 1. It makes it clear that the BROADCAST flag has to be set in > > > > > > DHCPDISCOVER. > > > > > > 2. It makes it clear that the BROADCAST flag needs to be set > > > > > > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > > > > > > 3. It allows that servers might broadcast responses > > > > > > (allowed per 2131, see last paragraph section 4.1). > > > > > > 4. It allows that servers might respond with DHCPNAK. > > > > > > 5. It allows that there might be other reasons for clients to > > > > > > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > > > > > > 6. It does not make it illegal for clients to set BROADCAST bit > > > > > > for whatever other reason. Unless there is a good reason (other > > > > > > than known issues) to make it illegal, I am not sure if this > > > > > > was intended. I could not find any MUST NOT reference wrt BROADCAST > > > > > > bit in 2131. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > Kanoj > > > > > > _______________________________________________ > > > > > > IPoverIB mailing list > > > > > > IPoverIB@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > > > > > > > > > > > > > __ > > > > > > > > > > Vivek Kashyap > > > > > Linux Technology Center, IBM > > > > _______________________________________________ > > > > IPoverIB mailing list > > > > IPoverIB@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > > > > > __ > > > > > > Vivek Kashyap > > > Linux Technology Center, IBM > > _______________________________________________ > > IPoverIB mailing list > > IPoverIB@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > __ > > Vivek Kashyap > Linux Technology Center, IBM > > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Fri May 9 16:39:52 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 QAA01316 for ; Fri, 9 May 2003 16:39:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49Knxx11662 for ipoverib-archive@odin.ietf.org; Fri, 9 May 2003 16:49:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Knw811659 for ; Fri, 9 May 2003 16:49:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01280 for ; Fri, 9 May 2003 16:39:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEgF-0007Hy-00 for ipoverib-web-archive@ietf.org; Fri, 09 May 2003 16:41:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EEgE-0007Hr-00 for ipoverib-web-archive@ietf.org; Fri, 09 May 2003 16:41:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Km2811498; Fri, 9 May 2003 16:48:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Klm811440 for ; Fri, 9 May 2003 16:47:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01174 for ; Fri, 9 May 2003 16:37:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEe9-0007GT-00 for ipoverib@ietf.org; Fri, 09 May 2003 16:39:13 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19EEe7-0007Fk-00 for ipoverib@ietf.org; Fri, 09 May 2003 16:39:12 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h49KdQYp194014; Fri, 9 May 2003 16:39:26 -0400 Received: from w-vkashyap95.des.sequent.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h49KdOVc215170; Fri, 9 May 2003 14:39:25 -0600 Date: Fri, 9 May 2003 13:36:22 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Kanoj Sarcar cc: ipoverib@ietf.org Subject: Re: [Ipoverib] DHCP clarification In-Reply-To: Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, I think we can leave the draft as is (draft-ietf-ipoib-dhcp-over-infiniband-05.txt). Vivek On Wed, 7 May 2003, Vivek Kashyap wrote: > On Wed, 7 May 2003, Kanoj Sarcar wrote: > > > Vivek, > > > > Yes, I had noticed 2855, and knew that most of the material in > > that applies to IPoIB too. But I was not sure why 2855 went ahead and put that > > restriction (specifically since 2131 doesn't), and I was questioning whether > > it is really required. > > I take the reasoning behind RFC2855 to be as follows: > > RFC2131 states: > > "A client that cannot receive unicast IP datagrams until its protocol > software has been configured with an IP address SHOULD set > the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or > DHCPREQUEST messages that client sends. The BROADCAST bit will > provide a hint to the DHCP server and BOOTP relay agent to broadcast > any messages to the client on the client's subnet. A client that can > receive unicast IP datagrams before its protocol software has been > configured SHOULD clear the BROADCAST bit to 0. " > > Therefore: > > In the case of BOUND/RENEWING/REBINDING states the client stack > has the IP address. Therefore, though the RFC doesn't say it > explicitly (or at least I didn't find such a statement on a > search), I still read the RFC as stating that the B flag is not > to be set in these states. RFC2131 does explicitly say that a > client MUST include the 'ciaddr' value in these states. > > > Vivek > > > > > In any case, I am okay if you want to keep the same restriction in ipoib/dhcp > > as in 2855. > > > > Thanks. > > > > Kanoj > > > > Vivek Kashyap wrote: > > > > > > Kanoj, > > > > > > The case where the B flag is not being set are when the ciaddr > > > contains the IP address. > > > > > > RFC2855 states: > > > > > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > > > client's IP address during BOUND, RENEWING or REBINDING state, > > > therefore, the BROADCAST flag MUST NOT be set. In these cases, > > > the DHCP server unicasts DHCPACK message to the address in > > > 'ciaddr'. The link address will be resolved by 1394 ARP. > > > > > > The existing draft has: > > > > > > Note: As described in [RFC2131], 'ciaddr' MUST be filled in with > > > client's IP address during BOUND, RENEWING or REBINDING state, > > > therefore, the BROADCAST flag MUST NOT be set. In these cases, > > > the DHCP server unicasts DHCPACK message to the address in > > > 'ciaddr'. The link address will be resolved by IPoIB ARP. > > > > > > Maybe we should leave it like that. > > > > > > Vivek > > > > > > On Tue, 6 May 2003, Kanoj Sarcar wrote: > > > > > > > Vivek, > > > > > > > > The wording sounds fine; although I am uncomfortable with the "MUST NOT > > > > set BROADCAST flag", preferring the "SHOULD NOT" option. Why is the MUST > > > > NOT restriction required? RFC 2131 leaves the setting of this flag to the > > > > client (as far as I can tell; unless you can quote a specific section that > > > > implies otherwise). Are you worried about servers that might get confused > > > > with the BROADCAST bit in BOUND/RENEWING/REBINDING clients? > > > > > > > > Thanks. > > > > > > > > Kanoj > > > > > > > > > > > > Vivek Kashyap wrote: > > > > > > > > > > Kanoj, > > > > > > > > > > How about the following: > > > > > > > > > > 2.2 Use of the BROADCAST flag > > > > > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag and set > > > > > 'ciaddr' to zero in DHCPDISCOVER and DHCPREQUEST messages > > > > > when it is not in BOUND or RENEWING states. This ensures that > > > > > the server (or the relay agent) broadcasts its reply to > > > > > the client. > > > > > > > > > > In the BOUND, RENEWING or REBINDING states 'ciaddr' MUST be > > > > > filled in with the client's IP address [RFC2131]. The > > > > > BROADCAST flag MUST NOT be set in these cases since the DHCP > > > > > server, after resolving the 'ciaddr' address using ARP, > > > > > unicasts the DHCPACK message to the client. > > > > > > > > > > Vivek > > > > > > > > > > > Hi, > > > > > > > > > > > > While going over section 2 of ipoib/dhcp draft, I realized that it > > > > > > can be cleaned up somewhat (in my opinion, ie; to others, it might > > > > > > be quite clear already). Accordingly, I came up with the following > > > > > > verbiage. If there are some improvements in here, it should be used > > > > > > to reword the section. > > > > > > > > > > > > 2.2 Use of the BROADCAST flag > > > > > > > > > > > > A DHCP client on IPoIB MUST set the BROADCAST flag (and > > > > > > set 'ciaddr' to zero) in DHCPREQUEST messages and > > > > > > DHCPDISCOVER messages sent when it is not in the BOUND > > > > > > or RENEWING states (ie it is in INIT-REBOOT or SELECTING > > > > > > states). > > > > > > > > > > > > For other cases, the client SHOULD NOT set the BROADCAST > > > > > > flag if it can receive the server's unicast responses. > > > > > > As described in [RFC2131], 'ciaddr' MUST be filled in > > > > > > with client's IP address during BOUND, RENEWING or > > > > > > REBINDING states. In these cases, > > > > > > the DHCP server attempts to unicast DHCP responses to > > > > > > the address filled in by the client in 'ciaddr' by using > > > > > > IPoIB ARP to resolve the link address. > > > > > > > > > > > > The reason I think this is clearer is because: > > > > > > 1. It makes it clear that the BROADCAST flag has to be set in > > > > > > DHCPDISCOVER. > > > > > > 2. It makes it clear that the BROADCAST flag needs to be set > > > > > > for DHCPREQUEST only in INIT-REBOOT/SELECTING states. > > > > > > 3. It allows that servers might broadcast responses > > > > > > (allowed per 2131, see last paragraph section 4.1). > > > > > > 4. It allows that servers might respond with DHCPNAK. > > > > > > 5. It allows that there might be other reasons for clients to > > > > > > set BROADCAST bit (specifically for INFORM, see 2131 table 5). > > > > > > 6. It does not make it illegal for clients to set BROADCAST bit > > > > > > for whatever other reason. Unless there is a good reason (other > > > > > > than known issues) to make it illegal, I am not sure if this > > > > > > was intended. I could not find any MUST NOT reference wrt BROADCAST > > > > > > bit in 2131. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > Kanoj > > > > > > _______________________________________________ > > > > > > IPoverIB mailing list > > > > > > IPoverIB@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > > > > > > > > > > > > > __ > > > > > > > > > > Vivek Kashyap > > > > > Linux Technology Center, IBM > > > > _______________________________________________ > > > > IPoverIB mailing list > > > > IPoverIB@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > > > > > __ > > > > > > Vivek Kashyap > > > Linux Technology Center, IBM > > _______________________________________________ > > IPoverIB mailing list > > IPoverIB@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > __ > > Vivek Kashyap > Linux Technology Center, IBM > > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Fri May 9 16:40: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 QAA01357 for ; Fri, 9 May 2003 16:40:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49KjF811239; Fri, 9 May 2003 16:45:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Kip811191 for ; Fri, 9 May 2003 16:44:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00982 for ; Fri, 9 May 2003 16:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEbI-0007El-00 for ipoverib@ietf.org; Fri, 09 May 2003 16:36:16 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19EEbH-0007EN-00 for ipoverib@ietf.org; Fri, 09 May 2003 16:36:15 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h49KafQs208506 for ; Fri, 9 May 2003 16:36:41 -0400 Received: from w-vkashyap95.des.sequent.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h49Kae7h027850; Fri, 9 May 2003 14:36:40 -0600 Date: Fri, 9 May 2003 13:33:37 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Roy Brabson cc: ipoverib@ietf.org Subject: Re: [Ipoverib] Comments on draft-ietf-ip-over-infiniband-04.txt In-Reply-To: Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Roy, On Fri, 2 May 2003, Roy Brabson wrote: > As with my comments on draft-ietf-ipoib-link-multicast-04.txt, I've > just started to look at IPoIB, so please forgive me if some of the > comments below have been discussed previously. > > - I've seen this discussed previously, but wouldn't it make sense to > combine this draft with draft-ietf-ipoib-link-multicast-04.txt? You > can't implement one without the other, and each draft only seems to > have about 5-10 pages of unique text. Yes, we discussed it but finally kept this form. > > - The draft contains a reference to draft-ietf-ipoib-architecture-02.txt. > I've been unable to find a copy of this draft, either current or in an > internet draft archive. draft-ietf-ipoib-architecture-01.txt is an > expired draft which hasn't been updated in almost 18 months. Should > this reference be deleted, or is referenced draft updated and published > as an RFC? Working on it. > > - Section 4.0 covers the setting of the IBoIB MTU. But I'm wondering > why this is even discussed within this document at all. Isn't it > already covered in "IP link and multicast over InfiniBand networks" > draft, which seems to be the better place for this information? > > I actually prefer the text within this section over that in the "link > and multicast" draft - maybe this section should be deleted and this > text can replace that in the other draft. The two drafts have different contexts -- this draft discusses the impact on the IP MTU due to the encapsulation defined in this draft and other parameters affecting the MTU. The link-multicast draft discusses the choice and setting of the link's MTU. > > - Section 5.0 seems to require that the interface identifier be selected > either from the GUID or, if the IPoIB subnet is contained within an IB > subnet, from the LID. I don't believe is the intent, as there are > quite a few other ways that an interface identifier may be generated - > as per RFC 3041, via manual configuration, or some other algorithm as > deemed necessary by the IPoIB node. I would prefer to see the text > indicate that the GUID SHOULD be used if privacy is not a concern, but > other mechanisms may be used as deemed appropriate. The description in the draft states the methods by which InfiniBand interface identifiers can be used to setup the interface id. It then recommends the use of the GUID (EUI-64) value. This does not preclude any of the other legal methods - as you also note. The other methods need not be specified since this is a SHOULD/RECOMMENDED clause - implying that there are situations where the other methods may be used (such as manual or as per RFC3041). It appears that RFCs/drafts for other media also discuss the identifiers associated with the interface and not the other methods (none of which are explicitly blocked). Vivek > > Roy > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Fri May 9 16:40:11 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 QAA01373 for ; Fri, 9 May 2003 16:40:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49KoIL11699 for ipoverib-archive@odin.ietf.org; Fri, 9 May 2003 16:50:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49KoH811696 for ; Fri, 9 May 2003 16:50:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01293 for ; Fri, 9 May 2003 16:39:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEgY-0007IC-00 for ipoverib-web-archive@ietf.org; Fri, 09 May 2003 16:41:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EEgY-0007I9-00 for ipoverib-web-archive@ietf.org; Fri, 09 May 2003 16:41:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49KjF811239; Fri, 9 May 2003 16:45:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Kip811191 for ; Fri, 9 May 2003 16:44:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00982 for ; Fri, 9 May 2003 16:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEbI-0007El-00 for ipoverib@ietf.org; Fri, 09 May 2003 16:36:16 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19EEbH-0007EN-00 for ipoverib@ietf.org; Fri, 09 May 2003 16:36:15 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h49KafQs208506 for ; Fri, 9 May 2003 16:36:41 -0400 Received: from w-vkashyap95.des.sequent.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h49Kae7h027850; Fri, 9 May 2003 14:36:40 -0600 Date: Fri, 9 May 2003 13:33:37 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: Roy Brabson cc: ipoverib@ietf.org Subject: Re: [Ipoverib] Comments on draft-ietf-ip-over-infiniband-04.txt In-Reply-To: Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Roy, On Fri, 2 May 2003, Roy Brabson wrote: > As with my comments on draft-ietf-ipoib-link-multicast-04.txt, I've > just started to look at IPoIB, so please forgive me if some of the > comments below have been discussed previously. > > - I've seen this discussed previously, but wouldn't it make sense to > combine this draft with draft-ietf-ipoib-link-multicast-04.txt? You > can't implement one without the other, and each draft only seems to > have about 5-10 pages of unique text. Yes, we discussed it but finally kept this form. > > - The draft contains a reference to draft-ietf-ipoib-architecture-02.txt. > I've been unable to find a copy of this draft, either current or in an > internet draft archive. draft-ietf-ipoib-architecture-01.txt is an > expired draft which hasn't been updated in almost 18 months. Should > this reference be deleted, or is referenced draft updated and published > as an RFC? Working on it. > > - Section 4.0 covers the setting of the IBoIB MTU. But I'm wondering > why this is even discussed within this document at all. Isn't it > already covered in "IP link and multicast over InfiniBand networks" > draft, which seems to be the better place for this information? > > I actually prefer the text within this section over that in the "link > and multicast" draft - maybe this section should be deleted and this > text can replace that in the other draft. The two drafts have different contexts -- this draft discusses the impact on the IP MTU due to the encapsulation defined in this draft and other parameters affecting the MTU. The link-multicast draft discusses the choice and setting of the link's MTU. > > - Section 5.0 seems to require that the interface identifier be selected > either from the GUID or, if the IPoIB subnet is contained within an IB > subnet, from the LID. I don't believe is the intent, as there are > quite a few other ways that an interface identifier may be generated - > as per RFC 3041, via manual configuration, or some other algorithm as > deemed necessary by the IPoIB node. I would prefer to see the text > indicate that the GUID SHOULD be used if privacy is not a concern, but > other mechanisms may be used as deemed appropriate. The description in the draft states the methods by which InfiniBand interface identifiers can be used to setup the interface id. It then recommends the use of the GUID (EUI-64) value. This does not preclude any of the other legal methods - as you also note. The other methods need not be specified since this is a SHOULD/RECOMMENDED clause - implying that there are situations where the other methods may be used (such as manual or as per RFC3041). It appears that RFCs/drafts for other media also discuss the identifiers associated with the interface and not the other methods (none of which are explicitly blocked). Vivek > > Roy > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Sun May 11 02:36: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 CAA28534 for ; Sun, 11 May 2003 02:36:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4B60OB14482; Sun, 11 May 2003 02:00:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4B5xPB14409 for ; Sun, 11 May 2003 01:59:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28495 for ; Sun, 11 May 2003 02:34:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EkRD-0007ZG-00 for ipoverib@ietf.org; Sun, 11 May 2003 02:35:59 -0400 Received: from kathmandu.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 19EkRC-0007ZD-00 for ipoverib@ietf.org; Sun, 11 May 2003 02:35:58 -0400 Received: from jurassic.eng.sun.com ([129.146.81.144]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA23380; Sun, 11 May 2003 00:36:58 -0600 (MDT) Received: from unknown (vpn-129-150-17-211.SFBay.Sun.COM [129.150.17.211]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h4B6apKQ693585; Sat, 10 May 2003 23:36:56 -0700 (PDT) Message-Id: <200305110636.h4B6apKQ693585@jurassic.eng.sun.com> Date: Sat, 10 May 2003 23:42:33 -0700 (PDT) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: rbrabson@us.ibm.com Cc: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KAk58iXh782/n+IP6O4dDQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 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: , >> >> >- Section 9.0 indicates that "The packet SHOULD be forwarded to >locally >> > >> >> > connected routers. [snip] The specific mechanism for a sender to >> >> > forward packets to routers are left to implementations". At a >> >> > minimum, I think the exact implementation needs to be specified. >> >> >> >> Why? (The draft strives to avoid dictating implementation details >that >> >> do not affect interoperability.) >> > >> >For interoperatibilty. The requirement is the host and router must >agree >> >on using a common mechanism for exchanging the IP multicast packet. >> >Implementations are free to choose a mechanism as long as all other >> >implementations with which they communicate also choose to implement >the >> >same mechanism. I don't think this is an area where we can or should >punt >> >- a minimal, common approach needs to be mandated such that all IPoIB >> >nodes implement that mechanism so that any two IPoIB nodes will >> >interoperate. >> >> I still don't see any problem you may have in mind. As long as a sender >> gets the pkt to the router, why it matter how it gets there? E.g., >> routers will listen to both the broadcast and the all-router multicast >> addresses. Does it matter which address a pkt is sent to? > >I guess I thought that a receiver might choose to discard IB packets which >is sent to the wrong (M)GID. If this isn't possible or allowed by IBA, I don't think it is possible to determine whether a destination link layer address is "right" or "wrong" wrt to a dst IP addr in general. >then you are right - it doesn't matter how a packet arrives at the local >QP, just as long as it arrives. So, I guess an alternative to using the >all-router MGID or the broadcast GID would be to have an IPoIB host >somehow determine all listeners and unicast packets to each listener. Not >a real good alternative, but it would work. Yup. > >Even if there are many possible ways to make IPoIB work, we should be >choosing the "best" or "most appropriate" one(s) and documenting those. >This appears to be sending to the all-router MGID, or possibly the >broadcast GID. Why not simply state these are the mechnisms defined by >IPoIB, but state that future standards may define additional mechanisms >for delivery of multicast packets to the IPoIB router. Again the draft has been carefully written to separate the required properties of IPoIB from implementation freedom. For a multicast receiver the draft clearly states it MUST join the approiate MGID. But for a multicast sender it doesn't really matter how the link layer manages to get an outbound multicast pkt to its receivers (including all the MC routers), as long as it does NOT make any undue assumption about receivers. One specific consideration is that although we don't encourage, we still want to allow implementations that must resort to broadcast when sending MC pkts to be declared compliant. An analogy is IP over Ethernet does not dictate implementations such as multicast receivers mustn't resort to promiscuous mode when its hash table overflows... Perhaps the best is not to dictate but to suggest the preferred implementation (i.e. the all-router MC group). > >> > >> >> > The >> >> > text suggests using all-router multicast group or the broadcast >> >group. >> >> > If a router is required to create the all-router multicast group >(see >> > >> >> > the previous comment), then wouldn't it be sufficient to check for > >> >the >> >> > existence of the all-router multicast group and, if it exists, >send >> >to >> >> > that? If it doesn't exist, then there can't be any multicast >routers >> > >> >> > on the link, and since there aren't any local listeners there are >no >> >> > on-link listeners there isn't any need to send the packet. >> >> >> >> Don't the code sinppet following 9.B match pretty much what you >> >described >> >> above? >> > >> >Yes, it does, and if the text matched the code snippet then I wouldn't >> >have an issue. But the text which supports the code snippet doesn't. >> >> I can remove the text if it causes any confusion. I thought it is very >> obvious if no router exists then there is no need to forward (as >> illustrated by the code snippet). >> >> >The >> >text basically says you could send to the all-router multicast group OR > >> >the broadcast group. And either should work, as long as the receiving >> >IPoIB node MUST accept the IP multicast packets regardless of the IB >group >> >over which they are received (I'm not sure I've seen this explicitly >> >stated in the draft, but I may have missed it). >> >> I thought this is required by IP already. But please tell me if I'm >> wrong. >> >> >But do we really need to >> >have multiple mechanisms to accomplish the same result? Wouldn't we be > >> >better off just choosing one and going with that? And how are we going >to >> >find multiple interoperable implementations for each option when the >draft >> >puts no limits on the approaches which can be taken? >> >> The multiple mechanisms were not there in the earlier draft, but were >> requested later by my co-author. I personally don't see any harm with >> it but I don't mind taking it out if Vivek agrees with you. > >I responded to a separate post from Vivek on this topic. I'm OK if both >mechanisms (send to the all-router MGID or broadcast GID) are left in, >although I do think the best approach is to send to the all-router MGID. >Doing so reduces the amount of traffic which needs to be filtered by IPoIB >hosts when there are no on-link listeners. Ok. > >> >> > And shouldn't the IPoIB sender subscribe to the IB multicast group > >> >> > creation events using a wildcard MGID so that it can >> >> > "SendOnlyNonMember" join the group if a listener appears on the >local >> > >> >> > IB subnet, or "SendOnlyNonMember" join the all-routers group if a >> >> > router appears on-link and creates the all-routers multicast >group? >> >> > And doesn't it need to subscribe to the IB multicast group >deletion >> >> > events so that it knows when to switch back to sending to the >> >> > all-router multicast group and/or stop sending? >> >> >> >> Aren't you saying the same thing (more or less) as what is described >in >> >> the section following the code snippet? >> > >> >You are right - I must have missed the text. But you need to change >the >> >"should" to a "MUST" in that paragraph. >> >> Since the caching part is a "should", the subscription part ought to be >> a "should" too, right? > >Yes, you are right. Listening for creation/deletion reports doesn't make >any sense if the IPoIB node does not cache the MGID for groups which it >"NonMember" joins. > >> >> > But I'm wondering why a node needs to do this at all. Wouldn't it > >> >> > make more sense for the IPoIB node instead create the multicast >group >> > >> >> > and join the group so that IPoIB multicast routers can join the >> >group? >> >> > Yes, the IPoIB sender will need create the group as a >"FullMember", >> >> > but this seems to provide a simpler mapping of IP multicast to IB >> >> > multicast. >> >> >> >> While what you suggested may simplify the procedure, it essentially >> >> removes the difference between a multicast sender and a multicast >> >receiver, >> >> which is wrong. In the IP multicast model a multicast sender doesn't >> >need >> >> to be a member of a multicast group to send. The draft has tried to >> >> keep the same distinction. >> > >> >However, you are mapping the IP multicast model to the IB multicast >model, >> >and the two are not the same. The reality is a sender must join an IB >> >multicast group in order to send to it (albeit as a >"SendOnlyNonMember"), >> >> This is the big difference that was debated in IBTA. >> >> >and this step does not exist in the IP model. I imagine that the vast >> >majority of the code/complexity of an IPoIB implementation is going to >be >> >dealing with IB multicasting. I was hoping there was some way to >reduce >> >both at an IPoIB host. Maybe it is just wishful thinking. >> >> I actually have the same philosophy as well. I'm always against >complexity >> unless it's fully justified. But IB multicast just works differently >than >> IP multicast. We have gone through a number of alternatives and the >> current one seemed to a good balance between complexity and correctness. >> I don't remember all the tradeoffs but if we simply require a sender >> to be a full-member, how would one know when to leave a group, when to >> delete a group..., etc. Also wouldn't it enable anyone to write a silly >> sender program to try to send to a million different addresses and cause >> all the IB multicast resources to be used up? (The join call by >> IP_ADD_MEMBERSHIP at least places some resource limitation.) > >Yes, there are issues which might well make it more complex. As I said, >maybe it was wishful thinking. From the sound of it, it was. > >> >By the way, after thinking about this a little more, I'm not sure that >> >creating a group as I suggested makes sense in all cases. For >instance, >> >it is only useful for an IP multicast group which has a scope greater >than >> >link-local. For link-local scope, only nodes directly attached to the >> >IPoIB link are able to receive the packet. Creating the group for the >> >purpose of forwarding to an IPoIB multicast router is simply wasteful, >as >> >the IPoIB multicast router will not be able to forward the packet to >> >another IP link. >> > >> >A similar optimization can also be taken with the current approach >> >described in this draft - for an IP multicast group with link-local >scope, >> >if the IB MGID for that IP multicast group does not exist then an IPoIB > >> >node really doesn't need to send the multicast packet to the all-router > >> >MGID or broadcast GID. >> >> Correct. This level of details can arguably be left to implementation >> because it doesn't affect interoperability. But I think this >optimization >> is simple and useful enough that I'll add a note to the draft. > >Sounds good. > >> > >> >> >- Section 9.0 also indicates that "A multicast sender must join the >> >> > target multicast group as a "SendOnlyNonMember" before outgoing >> >> > messages from it can be successfully routed." This text should be >> >> > clarified to indicate this is only true if the node has not >already >> >> > joined the group as either a "FullMember" or "SendOnlyNonMember". >The >> > >> >> > If-Then-Else logic below correctly shows this behavior, but this >> >> > paragraph does not reflect that behavior. >> >> >> >> Although your comment is correct, I'd argue this kind of details can >> >> be found in the IBA spec. It has nothing to do with IPoIB in >particular, >> >> So the question becomes how much IBA info we need to repeat in an >IPoIB >> >RFC. >> >> Since the code sippet already covers this correctly, if you still >> >believe >> >> this needs to be clarified i can certain add more text to it. >> > >> >My feeling is enough to describe HOW an IPoIB node will USE the IBA >> >services, and this is one of those cases. I would prefer to see the >text >> >clarified if you do another revision of the draft, but given the code >> >snippet describes the correct behavior I wouldn't hold this draft up >just >> >to clarify this paragraph. >> >> Ok. >> >> > >> >> >- Section 9.0 indicates that "For the rest of attributes, it is >> >> > recommended the same values from the all-node multicast/broadcast >> >> > group be used." Should this instead say "For the rest of the >> >> > attributes, the same values from the all-node multicast/broadcast >> >> > group SHOULD be used." Regardless of the wording, this text seems >to >> >> > contradict the Section 7.0 which states a node must "use the rest >of >> >> > the link attributes associated with the group for all future >> >> > communication on the link. If Section 7.0 is correct, should this >be >> > >> >> > a MUST instead of a SHOULD? And, if not, under what circumstances > >> >> > would a node choose to not use the same values? >> >> >> >> 7.0 describes the attributes used by a node when conducting unicast >> >> communication. 9.0 describes the attributes used to create a >multicast >> >> group, i.e., for multicast communication. So the question is: >> >> Must path attributes used for unicast match with those for multicast? >> >> >> >> The flexibility allowed in the multicast case in the current draft is >> >> deliberate. I don't know in reality if this is useful, or even good >to >> >> have. (Comments are welcome.) My design principle has been to not to >> >> make something a requirement unless it is needed for >interoperability. >> > >> >Flexibility is often times good, but so is describing a minimal set of >> >functions necessary for interoperability. If a node selects link >> >attributes when creating an MGID which does not match the broadcast >GID's >> >attributes, then it is possible that not all nodes which are members of > >> >the IPoIB link will be able to support those attributes. If this >happens, >> >then the two nodes will not be able to communicate using the IP >multicast >> >group mapped to the MGID. All of a sudden, an IPoIB node can't send an > >> >ARP request or Neighbor Solicitation to another node. >> >> I think some of these "deliberate" flexibility (or ambuguity) came from >> the ambuguity of IB itself in some of the mutlicast attributes such as >> SL, TClass..., etc. It is not clear to me if they must or even can >> follow the ones for unicast (i.e. described by the broadcast group) >> in all cases. > >Well, I hope they can, as that is what I was planning on doing for any >MGIDs which I had to create. If they can't, I have no idea how to come up >with the appropriate values for the attributes. The flexibility is not for you :-), but for those who for some reason know how to come up with an optimal set of values which turn out to be different than those of the broadcast group. Well I'll study IBA spec more to see what needs to be change here. > >> >Perhaps it would be better to state that a node which creates a >multicast >> >group MUST use the same values for the attributes as the all-node >> >multicast/broadcast group, but a node joining a multicast group must >not >> >verify the values match. If the node joining the group can't support >the >> >values for the multicast group, then it should log the error. That >way, a >> >future RFC could describe why/when/how a node would choose to use >> >different values for the link attributes but still be able to >interoperate >> >with IPoIB nodes. >> >> I'll leave the above for IB folks to comment. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Sun May 11 02:36: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 CAA28548 for ; Sun, 11 May 2003 02:36:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4B61XU14667 for ipoverib-archive@odin.ietf.org; Sun, 11 May 2003 02:01:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4B61WB14664 for ; Sun, 11 May 2003 02:01:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28531 for ; Sun, 11 May 2003 02:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EkTH-0007Zk-00 for ipoverib-web-archive@ietf.org; Sun, 11 May 2003 02:38:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EkTG-0007Zg-00 for ipoverib-web-archive@ietf.org; Sun, 11 May 2003 02:38:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4B60OB14482; Sun, 11 May 2003 02:00:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4B5xPB14409 for ; Sun, 11 May 2003 01:59:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28495 for ; Sun, 11 May 2003 02:34:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EkRD-0007ZG-00 for ipoverib@ietf.org; Sun, 11 May 2003 02:35:59 -0400 Received: from kathmandu.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 19EkRC-0007ZD-00 for ipoverib@ietf.org; Sun, 11 May 2003 02:35:58 -0400 Received: from jurassic.eng.sun.com ([129.146.81.144]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA23380; Sun, 11 May 2003 00:36:58 -0600 (MDT) Received: from unknown (vpn-129-150-17-211.SFBay.Sun.COM [129.150.17.211]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h4B6apKQ693585; Sat, 10 May 2003 23:36:56 -0700 (PDT) Message-Id: <200305110636.h4B6apKQ693585@jurassic.eng.sun.com> Date: Sat, 10 May 2003 23:42:33 -0700 (PDT) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: rbrabson@us.ibm.com Cc: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KAk58iXh782/n+IP6O4dDQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 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: , >> >> >- Section 9.0 indicates that "The packet SHOULD be forwarded to >locally >> > >> >> > connected routers. [snip] The specific mechanism for a sender to >> >> > forward packets to routers are left to implementations". At a >> >> > minimum, I think the exact implementation needs to be specified. >> >> >> >> Why? (The draft strives to avoid dictating implementation details >that >> >> do not affect interoperability.) >> > >> >For interoperatibilty. The requirement is the host and router must >agree >> >on using a common mechanism for exchanging the IP multicast packet. >> >Implementations are free to choose a mechanism as long as all other >> >implementations with which they communicate also choose to implement >the >> >same mechanism. I don't think this is an area where we can or should >punt >> >- a minimal, common approach needs to be mandated such that all IPoIB >> >nodes implement that mechanism so that any two IPoIB nodes will >> >interoperate. >> >> I still don't see any problem you may have in mind. As long as a sender >> gets the pkt to the router, why it matter how it gets there? E.g., >> routers will listen to both the broadcast and the all-router multicast >> addresses. Does it matter which address a pkt is sent to? > >I guess I thought that a receiver might choose to discard IB packets which >is sent to the wrong (M)GID. If this isn't possible or allowed by IBA, I don't think it is possible to determine whether a destination link layer address is "right" or "wrong" wrt to a dst IP addr in general. >then you are right - it doesn't matter how a packet arrives at the local >QP, just as long as it arrives. So, I guess an alternative to using the >all-router MGID or the broadcast GID would be to have an IPoIB host >somehow determine all listeners and unicast packets to each listener. Not >a real good alternative, but it would work. Yup. > >Even if there are many possible ways to make IPoIB work, we should be >choosing the "best" or "most appropriate" one(s) and documenting those. >This appears to be sending to the all-router MGID, or possibly the >broadcast GID. Why not simply state these are the mechnisms defined by >IPoIB, but state that future standards may define additional mechanisms >for delivery of multicast packets to the IPoIB router. Again the draft has been carefully written to separate the required properties of IPoIB from implementation freedom. For a multicast receiver the draft clearly states it MUST join the approiate MGID. But for a multicast sender it doesn't really matter how the link layer manages to get an outbound multicast pkt to its receivers (including all the MC routers), as long as it does NOT make any undue assumption about receivers. One specific consideration is that although we don't encourage, we still want to allow implementations that must resort to broadcast when sending MC pkts to be declared compliant. An analogy is IP over Ethernet does not dictate implementations such as multicast receivers mustn't resort to promiscuous mode when its hash table overflows... Perhaps the best is not to dictate but to suggest the preferred implementation (i.e. the all-router MC group). > >> > >> >> > The >> >> > text suggests using all-router multicast group or the broadcast >> >group. >> >> > If a router is required to create the all-router multicast group >(see >> > >> >> > the previous comment), then wouldn't it be sufficient to check for > >> >the >> >> > existence of the all-router multicast group and, if it exists, >send >> >to >> >> > that? If it doesn't exist, then there can't be any multicast >routers >> > >> >> > on the link, and since there aren't any local listeners there are >no >> >> > on-link listeners there isn't any need to send the packet. >> >> >> >> Don't the code sinppet following 9.B match pretty much what you >> >described >> >> above? >> > >> >Yes, it does, and if the text matched the code snippet then I wouldn't >> >have an issue. But the text which supports the code snippet doesn't. >> >> I can remove the text if it causes any confusion. I thought it is very >> obvious if no router exists then there is no need to forward (as >> illustrated by the code snippet). >> >> >The >> >text basically says you could send to the all-router multicast group OR > >> >the broadcast group. And either should work, as long as the receiving >> >IPoIB node MUST accept the IP multicast packets regardless of the IB >group >> >over which they are received (I'm not sure I've seen this explicitly >> >stated in the draft, but I may have missed it). >> >> I thought this is required by IP already. But please tell me if I'm >> wrong. >> >> >But do we really need to >> >have multiple mechanisms to accomplish the same result? Wouldn't we be > >> >better off just choosing one and going with that? And how are we going >to >> >find multiple interoperable implementations for each option when the >draft >> >puts no limits on the approaches which can be taken? >> >> The multiple mechanisms were not there in the earlier draft, but were >> requested later by my co-author. I personally don't see any harm with >> it but I don't mind taking it out if Vivek agrees with you. > >I responded to a separate post from Vivek on this topic. I'm OK if both >mechanisms (send to the all-router MGID or broadcast GID) are left in, >although I do think the best approach is to send to the all-router MGID. >Doing so reduces the amount of traffic which needs to be filtered by IPoIB >hosts when there are no on-link listeners. Ok. > >> >> > And shouldn't the IPoIB sender subscribe to the IB multicast group > >> >> > creation events using a wildcard MGID so that it can >> >> > "SendOnlyNonMember" join the group if a listener appears on the >local >> > >> >> > IB subnet, or "SendOnlyNonMember" join the all-routers group if a >> >> > router appears on-link and creates the all-routers multicast >group? >> >> > And doesn't it need to subscribe to the IB multicast group >deletion >> >> > events so that it knows when to switch back to sending to the >> >> > all-router multicast group and/or stop sending? >> >> >> >> Aren't you saying the same thing (more or less) as what is described >in >> >> the section following the code snippet? >> > >> >You are right - I must have missed the text. But you need to change >the >> >"should" to a "MUST" in that paragraph. >> >> Since the caching part is a "should", the subscription part ought to be >> a "should" too, right? > >Yes, you are right. Listening for creation/deletion reports doesn't make >any sense if the IPoIB node does not cache the MGID for groups which it >"NonMember" joins. > >> >> > But I'm wondering why a node needs to do this at all. Wouldn't it > >> >> > make more sense for the IPoIB node instead create the multicast >group >> > >> >> > and join the group so that IPoIB multicast routers can join the >> >group? >> >> > Yes, the IPoIB sender will need create the group as a >"FullMember", >> >> > but this seems to provide a simpler mapping of IP multicast to IB >> >> > multicast. >> >> >> >> While what you suggested may simplify the procedure, it essentially >> >> removes the difference between a multicast sender and a multicast >> >receiver, >> >> which is wrong. In the IP multicast model a multicast sender doesn't >> >need >> >> to be a member of a multicast group to send. The draft has tried to >> >> keep the same distinction. >> > >> >However, you are mapping the IP multicast model to the IB multicast >model, >> >and the two are not the same. The reality is a sender must join an IB >> >multicast group in order to send to it (albeit as a >"SendOnlyNonMember"), >> >> This is the big difference that was debated in IBTA. >> >> >and this step does not exist in the IP model. I imagine that the vast >> >majority of the code/complexity of an IPoIB implementation is going to >be >> >dealing with IB multicasting. I was hoping there was some way to >reduce >> >both at an IPoIB host. Maybe it is just wishful thinking. >> >> I actually have the same philosophy as well. I'm always against >complexity >> unless it's fully justified. But IB multicast just works differently >than >> IP multicast. We have gone through a number of alternatives and the >> current one seemed to a good balance between complexity and correctness. >> I don't remember all the tradeoffs but if we simply require a sender >> to be a full-member, how would one know when to leave a group, when to >> delete a group..., etc. Also wouldn't it enable anyone to write a silly >> sender program to try to send to a million different addresses and cause >> all the IB multicast resources to be used up? (The join call by >> IP_ADD_MEMBERSHIP at least places some resource limitation.) > >Yes, there are issues which might well make it more complex. As I said, >maybe it was wishful thinking. From the sound of it, it was. > >> >By the way, after thinking about this a little more, I'm not sure that >> >creating a group as I suggested makes sense in all cases. For >instance, >> >it is only useful for an IP multicast group which has a scope greater >than >> >link-local. For link-local scope, only nodes directly attached to the >> >IPoIB link are able to receive the packet. Creating the group for the >> >purpose of forwarding to an IPoIB multicast router is simply wasteful, >as >> >the IPoIB multicast router will not be able to forward the packet to >> >another IP link. >> > >> >A similar optimization can also be taken with the current approach >> >described in this draft - for an IP multicast group with link-local >scope, >> >if the IB MGID for that IP multicast group does not exist then an IPoIB > >> >node really doesn't need to send the multicast packet to the all-router > >> >MGID or broadcast GID. >> >> Correct. This level of details can arguably be left to implementation >> because it doesn't affect interoperability. But I think this >optimization >> is simple and useful enough that I'll add a note to the draft. > >Sounds good. > >> > >> >> >- Section 9.0 also indicates that "A multicast sender must join the >> >> > target multicast group as a "SendOnlyNonMember" before outgoing >> >> > messages from it can be successfully routed." This text should be >> >> > clarified to indicate this is only true if the node has not >already >> >> > joined the group as either a "FullMember" or "SendOnlyNonMember". >The >> > >> >> > If-Then-Else logic below correctly shows this behavior, but this >> >> > paragraph does not reflect that behavior. >> >> >> >> Although your comment is correct, I'd argue this kind of details can >> >> be found in the IBA spec. It has nothing to do with IPoIB in >particular, >> >> So the question becomes how much IBA info we need to repeat in an >IPoIB >> >RFC. >> >> Since the code sippet already covers this correctly, if you still >> >believe >> >> this needs to be clarified i can certain add more text to it. >> > >> >My feeling is enough to describe HOW an IPoIB node will USE the IBA >> >services, and this is one of those cases. I would prefer to see the >text >> >clarified if you do another revision of the draft, but given the code >> >snippet describes the correct behavior I wouldn't hold this draft up >just >> >to clarify this paragraph. >> >> Ok. >> >> > >> >> >- Section 9.0 indicates that "For the rest of attributes, it is >> >> > recommended the same values from the all-node multicast/broadcast >> >> > group be used." Should this instead say "For the rest of the >> >> > attributes, the same values from the all-node multicast/broadcast >> >> > group SHOULD be used." Regardless of the wording, this text seems >to >> >> > contradict the Section 7.0 which states a node must "use the rest >of >> >> > the link attributes associated with the group for all future >> >> > communication on the link. If Section 7.0 is correct, should this >be >> > >> >> > a MUST instead of a SHOULD? And, if not, under what circumstances > >> >> > would a node choose to not use the same values? >> >> >> >> 7.0 describes the attributes used by a node when conducting unicast >> >> communication. 9.0 describes the attributes used to create a >multicast >> >> group, i.e., for multicast communication. So the question is: >> >> Must path attributes used for unicast match with those for multicast? >> >> >> >> The flexibility allowed in the multicast case in the current draft is >> >> deliberate. I don't know in reality if this is useful, or even good >to >> >> have. (Comments are welcome.) My design principle has been to not to >> >> make something a requirement unless it is needed for >interoperability. >> > >> >Flexibility is often times good, but so is describing a minimal set of >> >functions necessary for interoperability. If a node selects link >> >attributes when creating an MGID which does not match the broadcast >GID's >> >attributes, then it is possible that not all nodes which are members of > >> >the IPoIB link will be able to support those attributes. If this >happens, >> >then the two nodes will not be able to communicate using the IP >multicast >> >group mapped to the MGID. All of a sudden, an IPoIB node can't send an > >> >ARP request or Neighbor Solicitation to another node. >> >> I think some of these "deliberate" flexibility (or ambuguity) came from >> the ambuguity of IB itself in some of the mutlicast attributes such as >> SL, TClass..., etc. It is not clear to me if they must or even can >> follow the ones for unicast (i.e. described by the broadcast group) >> in all cases. > >Well, I hope they can, as that is what I was planning on doing for any >MGIDs which I had to create. If they can't, I have no idea how to come up >with the appropriate values for the attributes. The flexibility is not for you :-), but for those who for some reason know how to come up with an optimal set of values which turn out to be different than those of the broadcast group. Well I'll study IBA spec more to see what needs to be change here. > >> >Perhaps it would be better to state that a node which creates a >multicast >> >group MUST use the same values for the attributes as the all-node >> >multicast/broadcast group, but a node joining a multicast group must >not >> >verify the values match. If the node joining the group can't support >the >> >values for the multicast group, then it should log the error. That >way, a >> >future RFC could describe why/when/how a node would choose to use >> >different values for the link attributes but still be able to >interoperate >> >with IPoIB nodes. >> >> I'll leave the above for IB folks to comment. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Sun May 11 03:43:14 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 DAA29235 for ; Sun, 11 May 2003 03:43:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4B779B29275; Sun, 11 May 2003 03:07:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4B76IB29079 for ; Sun, 11 May 2003 03:06:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29198 for ; Sun, 11 May 2003 03:40:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ElTv-0007k0-00 for ipoverib@ietf.org; Sun, 11 May 2003 03:42:51 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19ElTu-0007jv-00 for ipoverib@ietf.org; Sun, 11 May 2003 03:42:50 -0400 Received: from jurassic.eng.sun.com ([129.146.89.50]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4B7hKPH012673; Sun, 11 May 2003 00:43:20 -0700 (PDT) Received: from unknown (vpn-129-150-17-211.SFBay.Sun.COM [129.150.17.211]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h4B7hEKQ856572; Sun, 11 May 2003 00:43:18 -0700 (PDT) Message-Id: <200305110743.h4B7hEKQ856572@jurassic.eng.sun.com> Date: Sun, 11 May 2003 00:48:54 -0700 (PDT) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: vivk@us.ibm.com Cc: ipoverib@ietf.org, rbrabson@us.ibm.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VcQ6OnzKwT0FQ5llIdaxjw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 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: , Vivek, >>> >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > >> >>> > connected routers. [snip] The specific mechanism for a sender to >>> > forward packets to routers are left to implementations". At a >>> > minimum, I think the exact implementation needs to be specified. >>> >>> Why? (The draft strives to avoid dictating implementation details that >>> do not affect interoperability.) >> >>For interoperatibilty. The requirement is the host and router must agree >>on using a common mechanism for exchanging the IP multicast packet. >>Implementations are free to choose a mechanism as long as all other >>implementations with which they communicate also choose to implement the >>same mechanism. I don't think this is an area where we can or should punt > >>- a minimal, common approach needs to be mandated such that all IPoIB >>nodes implement that mechanism so that any two IPoIB nodes will >>interoperate. > >I still don't see any problem you may have in mind. As long as a sender >gets the pkt to the router, why it matter how it gets there? E.g., >routers will listen to both the broadcast and the all-router multicast >addresses. Does it matter which address a pkt is sent to? > > As I noted in my previous mail... the onus is on the router. The >router is required to listen to multicast packets on both: a) all-router >MGID or b) broadcast-GID > >We could make that explicit in the draft. I'm not sure we need to restate various properties that are required of IP already (unless they are actually not required). >The second option, which >apparently Roy favours is to specify that the nodes must, if the relevant >MGID doesn't exist, send the packet to the MGID corresponding to the >all-router MGID. See my response to Roy (sorry for the delay). I'd suggest the following paragraph: A) An IB multicast group must be explicitly created through the SA before it can be used. This implies that in order to send a packet destined for an IP multicast address, the IPoIB implementation must check with the SA on the outbound link first for a "MCMemberRecord" that matches the MGID. If one does exist, the MLID associated with the multicast group is used as the DLID for the packet. Otherwise, it implies no member exists on the local link. If the scope of the IP multicast group is beyond link-local, and routers exist on the local subnet, the packet SHOULD be forwarded to locally connected IP routers through the use of the all-router multicast group or the broadcast group. This is to allow local routers to forward the packet to multicast listeners on remote networks. The all-router multicast group is preferred over the broadcast group for better efficiency >This option is fine but it then adds another requirement: > > All IPoIB nodes MUST request creation request for all-router MGID > whether the corresponding IP layer joins the all-router IP address or > not. > I don't think the above is necessary. This is restating the requirement of IBA when sending a MC pkt, just like repeating the requirement of IP on joining the IP all-host MC group etc. >If the fall-back is the broadcast-GID then the end-nodes do not have to do >anything special. > >The current option allows the sender to choose between taking the simple >route of 'fall-back to broadcast GID' vs. 'must join all-router MGID'. > >I am ok with either case and if the 'must join all-router MGID' case is >preferable then we can specify that instead. > > >> >>> > The >>> > text suggests using all-router multicast group or the broadcast >>group. >>> > If a router is required to create the all-router multicast group (see > >> >>> > the previous comment), then wouldn't it be sufficient to check for >>the >>> > existence of the all-router multicast group and, if it exists, send >>to >>> > that? If it doesn't exist, then there can't be any multicast routers > >> >>> > on the link, and since there aren't any local listeners there are no >>> > on-link listeners there isn't any need to send the packet. >>> >>> Don't the code sinppet following 9.B match pretty much what you >>described >>> above? >> >>Yes, it does, and if the text matched the code snippet then I wouldn't >>have an issue. But the text which supports the code snippet doesn't. > >I can remove the text if it causes any confusion. I thought it is very >obvious if no router exists then there is no need to forward (as >illustrated by the code snippet). > >>The >>text basically says you could send to the all-router multicast group OR >>the broadcast group. And either should work, as long as the receiving >>IPoIB node MUST accept the IP multicast packets regardless of the IB group > >>over which they are received (I'm not sure I've seen this explicitly >>stated in the draft, but I may have missed it). > >I thought this is required by IP already. But please tell me if I'm >wrong. > >>But do we really need to >>have multiple mechanisms to accomplish the same result? Wouldn't we be >>better off just choosing one and going with that? And how are we going to > >>find multiple interoperable implementations for each option when the draft > >>puts no limits on the approaches which can be taken? > >The multiple mechanisms were not there in the earlier draft, but were >requested later by my co-author. I personally don't see any harm with >it but I don't mind taking it out if Vivek agrees with you. > > >Don't remember, could have on reasoning as described above. I think you wanted (and I concurred) to allow the case if IB multicast doesn't work, either due to implementation problems, bugs, flaws in the spec..., one can fall back to broadcast (although not encouraged). Jerry > >I think we can take it out and replace it with the condition that the >packets are sent to the all-router MGID AND all IPoIB nodes (because any >can be a sender) need to request creation report for all-router MGID and >then IB_Join it. > > >>> > >>> > And shouldn't the IPoIB sender subscribe to the IB multicast group >>> > creation events using a wildcard MGID so that it can >>> > "SendOnlyNonMember" join the group if a listener appears on the local > >> >>> > IB subnet, or "SendOnlyNonMember" join the all-routers group if a >>> > router appears on-link and creates the all-routers multicast group? >>> > And doesn't it need to subscribe to the IB multicast group deletion >>> > events so that it knows when to switch back to sending to the >>> > all-router multicast group and/or stop sending? >>> >>> Aren't you saying the same thing (more or less) as what is described in >>> the section following the code snippet? >> >>You are right - I must have missed the text. But you need to change the >>"should" to a "MUST" in that paragraph. > >Since the caching part is a "should", the subscription part ought to be >a "should" too, right? > >> >>> > >>> > But I'm wondering why a node needs to do this at all. Wouldn't it >>> > make more sense for the IPoIB node instead create the multicast group > >> >>> > and join the group so that IPoIB multicast routers can join the >>group? >>> > Yes, the IPoIB sender will need create the group as a "FullMember", >>> > but this seems to provide a simpler mapping of IP multicast to IB >>> > multicast. >>> >>> While what you suggested may simplify the procedure, it essentially >>> removes the difference between a multicast sender and a multicast >>receiver, >>> which is wrong. In the IP multicast model a multicast sender doesn't >>need >>> to be a member of a multicast group to send. The draft has tried to >>> keep the same distinction. >> >>However, you are mapping the IP multicast model to the IB multicast model, > >>and the two are not the same. The reality is a sender must join an IB >>multicast group in order to send to it (albeit as a "SendOnlyNonMember"), > >This is the big difference that was debated in IBTA. > >>and this step does not exist in the IP model. I imagine that the vast >>majority of the code/complexity of an IPoIB implementation is going to be >>dealing with IB multicasting. I was hoping there was some way to reduce >>both at an IPoIB host. Maybe it is just wishful thinking. > >I actually have the same philosophy as well. I'm always against complexity >unless it's fully justified. But IB multicast just works differently than >IP multicast. We have gone through a number of alternatives and the >current one seemed to a good balance between complexity and correctness. >I don't remember all the tradeoffs but if we simply require a sender >to be a full-member, how would one know when to leave a group, when to >delete a group..., etc. Also wouldn't it enable anyone to write a silly >sender program to try to send to a million different addresses and cause >all the IB multicast resources to be used up? (The join call by >IP_ADD_MEMBERSHIP at least places some resource limitation.) > > Yes, a major consideration has been the limited multicast resources >avaialble in IB. Some other issues were such as the case I described a >little while back: there is a very large chance of the router not receiving >the packet when the sender the group due to the possible delay in the >report reaching the router and the router IB_joining the group etc. > > >> >>By the way, after thinking about this a little more, I'm not sure that >>creating a group as I suggested makes sense in all cases. For instance, >>it is only useful for an IP multicast group which has a scope greater than > >>link-local. For link-local scope, only nodes directly attached to the >>IPoIB link are able to receive the packet. Creating the group for the >>purpose of forwarding to an IPoIB multicast router is simply wasteful, as >>the IPoIB multicast router will not be able to forward the packet to >>another IP link. >> >>A similar optimization can also be taken with the current approach >>described in this draft - for an IP multicast group with link-local scope, > >>if the IB MGID for that IP multicast group does not exist then an IPoIB >>node really doesn't need to send the multicast packet to the all-router >>MGID or broadcast GID. > >Correct. This level of details can arguably be left to implementation >because it doesn't affect interoperability. But I think this optimization >is simple and useful enough that I'll add a note to the draft. > > Agreed. > >> >>> >- Section 9.0 also indicates that "A multicast sender must join the >>> > target multicast group as a "SendOnlyNonMember" before outgoing >>> > messages from it can be successfully routed." This text should be >>> > clarified to indicate this is only true if the node has not already >>> > joined the group as either a "FullMember" or "SendOnlyNonMember". The > >> >>> > If-Then-Else logic below correctly shows this behavior, but this >>> > paragraph does not reflect that behavior. >>> >>> Although your comment is correct, I'd argue this kind of details can >>> be found in the IBA spec. It has nothing to do with IPoIB in particular, >>> So the question becomes how much IBA info we need to repeat in an IPoIB >>RFC. >>> Since the code sippet already covers this correctly, if you still >>believe >>> this needs to be clarified i can certain add more text to it. >> >>My feeling is enough to describe HOW an IPoIB node will USE the IBA >>services, and this is one of those cases. I would prefer to see the text >>clarified if you do another revision of the draft, but given the code >>snippet describes the correct behavior I wouldn't hold this draft up just >>to clarify this paragraph. > >Ok. > >> >>> >- Section 9.0 indicates that "For the rest of attributes, it is >>> > recommended the same values from the all-node multicast/broadcast >>> > group be used." Should this instead say "For the rest of the >>> > attributes, the same values from the all-node multicast/broadcast >>> > group SHOULD be used." Regardless of the wording, this text seems to >>> > contradict the Section 7.0 which states a node must "use the rest of >>> > the link attributes associated with the group for all future >>> > communication on the link. If Section 7.0 is correct, should this be > >> >>> > a MUST instead of a SHOULD? And, if not, under what circumstances >>> > would a node choose to not use the same values? >>> >>> 7.0 describes the attributes used by a node when conducting unicast >>> communication. 9.0 describes the attributes used to create a multicast >>> group, i.e., for multicast communication. So the question is: >>> Must path attributes used for unicast match with those for multicast? >>> >>> The flexibility allowed in the multicast case in the current draft is >>> deliberate. I don't know in reality if this is useful, or even good to >>> have. (Comments are welcome.) My design principle has been to not to >>> make something a requirement unless it is needed for interoperability. >> >>Flexibility is often times good, but so is describing a minimal set of >>functions necessary for interoperability. If a node selects link >>attributes when creating an MGID which does not match the broadcast GID's >>attributes, then it is possible that not all nodes which are members of >>the IPoIB link will be able to support those attributes. If this happens, > >>then the two nodes will not be able to communicate using the IP multicast >>group mapped to the MGID. All of a sudden, an IPoIB node can't send an >>ARP request or Neighbor Solicitation to another node. > >I think some of these "deliberate" flexibility (or ambuguity) came from >the ambuguity of IB itself in some of the mutlicast attributes such as >SL, TClass..., etc. It is not clear to me if they must or even can >follow the ones for unicast (i.e. described by the broadcast group) >in all cases. > >> >>Perhaps it would be better to state that a node which creates a multicast >>group MUST use the same values for the attributes as the all-node >>multicast/broadcast group, but a node joining a multicast group must not >>verify the values match. If the node joining the group can't support the >>values for the multicast group, then it should log the error. That way, a > >>future RFC could describe why/when/how a node would choose to use >>different values for the link attributes but still be able to interoperate > >>with IPoIB nodes. > >I'll leave the above for IB folks to comment. > >Jerry > >> >>Roy > >_______________________________________________ >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 Sun May 11 03:43:15 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 DAA29249 for ; Sun, 11 May 2003 03:43:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4B78Be30011 for ipoverib-archive@odin.ietf.org; Sun, 11 May 2003 03:08:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4B78BB30008 for ; Sun, 11 May 2003 03:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29228 for ; Sun, 11 May 2003 03:42:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ElVk-0007kI-00 for ipoverib-web-archive@ietf.org; Sun, 11 May 2003 03:44:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ElVj-0007kF-00 for ipoverib-web-archive@ietf.org; Sun, 11 May 2003 03:44:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4B779B29275; Sun, 11 May 2003 03:07:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4B76IB29079 for ; Sun, 11 May 2003 03:06:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29198 for ; Sun, 11 May 2003 03:40:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ElTv-0007k0-00 for ipoverib@ietf.org; Sun, 11 May 2003 03:42:51 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19ElTu-0007jv-00 for ipoverib@ietf.org; Sun, 11 May 2003 03:42:50 -0400 Received: from jurassic.eng.sun.com ([129.146.89.50]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4B7hKPH012673; Sun, 11 May 2003 00:43:20 -0700 (PDT) Received: from unknown (vpn-129-150-17-211.SFBay.Sun.COM [129.150.17.211]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h4B7hEKQ856572; Sun, 11 May 2003 00:43:18 -0700 (PDT) Message-Id: <200305110743.h4B7hEKQ856572@jurassic.eng.sun.com> Date: Sun, 11 May 2003 00:48:54 -0700 (PDT) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt To: vivk@us.ibm.com Cc: ipoverib@ietf.org, rbrabson@us.ibm.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VcQ6OnzKwT0FQ5llIdaxjw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 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: , Vivek, >>> >- Section 9.0 indicates that "The packet SHOULD be forwarded to locally > >> >>> > connected routers. [snip] The specific mechanism for a sender to >>> > forward packets to routers are left to implementations". At a >>> > minimum, I think the exact implementation needs to be specified. >>> >>> Why? (The draft strives to avoid dictating implementation details that >>> do not affect interoperability.) >> >>For interoperatibilty. The requirement is the host and router must agree >>on using a common mechanism for exchanging the IP multicast packet. >>Implementations are free to choose a mechanism as long as all other >>implementations with which they communicate also choose to implement the >>same mechanism. I don't think this is an area where we can or should punt > >>- a minimal, common approach needs to be mandated such that all IPoIB >>nodes implement that mechanism so that any two IPoIB nodes will >>interoperate. > >I still don't see any problem you may have in mind. As long as a sender >gets the pkt to the router, why it matter how it gets there? E.g., >routers will listen to both the broadcast and the all-router multicast >addresses. Does it matter which address a pkt is sent to? > > As I noted in my previous mail... the onus is on the router. The >router is required to listen to multicast packets on both: a) all-router >MGID or b) broadcast-GID > >We could make that explicit in the draft. I'm not sure we need to restate various properties that are required of IP already (unless they are actually not required). >The second option, which >apparently Roy favours is to specify that the nodes must, if the relevant >MGID doesn't exist, send the packet to the MGID corresponding to the >all-router MGID. See my response to Roy (sorry for the delay). I'd suggest the following paragraph: A) An IB multicast group must be explicitly created through the SA before it can be used. This implies that in order to send a packet destined for an IP multicast address, the IPoIB implementation must check with the SA on the outbound link first for a "MCMemberRecord" that matches the MGID. If one does exist, the MLID associated with the multicast group is used as the DLID for the packet. Otherwise, it implies no member exists on the local link. If the scope of the IP multicast group is beyond link-local, and routers exist on the local subnet, the packet SHOULD be forwarded to locally connected IP routers through the use of the all-router multicast group or the broadcast group. This is to allow local routers to forward the packet to multicast listeners on remote networks. The all-router multicast group is preferred over the broadcast group for better efficiency >This option is fine but it then adds another requirement: > > All IPoIB nodes MUST request creation request for all-router MGID > whether the corresponding IP layer joins the all-router IP address or > not. > I don't think the above is necessary. This is restating the requirement of IBA when sending a MC pkt, just like repeating the requirement of IP on joining the IP all-host MC group etc. >If the fall-back is the broadcast-GID then the end-nodes do not have to do >anything special. > >The current option allows the sender to choose between taking the simple >route of 'fall-back to broadcast GID' vs. 'must join all-router MGID'. > >I am ok with either case and if the 'must join all-router MGID' case is >preferable then we can specify that instead. > > >> >>> > The >>> > text suggests using all-router multicast group or the broadcast >>group. >>> > If a router is required to create the all-router multicast group (see > >> >>> > the previous comment), then wouldn't it be sufficient to check for >>the >>> > existence of the all-router multicast group and, if it exists, send >>to >>> > that? If it doesn't exist, then there can't be any multicast routers > >> >>> > on the link, and since there aren't any local listeners there are no >>> > on-link listeners there isn't any need to send the packet. >>> >>> Don't the code sinppet following 9.B match pretty much what you >>described >>> above? >> >>Yes, it does, and if the text matched the code snippet then I wouldn't >>have an issue. But the text which supports the code snippet doesn't. > >I can remove the text if it causes any confusion. I thought it is very >obvious if no router exists then there is no need to forward (as >illustrated by the code snippet). > >>The >>text basically says you could send to the all-router multicast group OR >>the broadcast group. And either should work, as long as the receiving >>IPoIB node MUST accept the IP multicast packets regardless of the IB group > >>over which they are received (I'm not sure I've seen this explicitly >>stated in the draft, but I may have missed it). > >I thought this is required by IP already. But please tell me if I'm >wrong. > >>But do we really need to >>have multiple mechanisms to accomplish the same result? Wouldn't we be >>better off just choosing one and going with that? And how are we going to > >>find multiple interoperable implementations for each option when the draft > >>puts no limits on the approaches which can be taken? > >The multiple mechanisms were not there in the earlier draft, but were >requested later by my co-author. I personally don't see any harm with >it but I don't mind taking it out if Vivek agrees with you. > > >Don't remember, could have on reasoning as described above. I think you wanted (and I concurred) to allow the case if IB multicast doesn't work, either due to implementation problems, bugs, flaws in the spec..., one can fall back to broadcast (although not encouraged). Jerry > >I think we can take it out and replace it with the condition that the >packets are sent to the all-router MGID AND all IPoIB nodes (because any >can be a sender) need to request creation report for all-router MGID and >then IB_Join it. > > >>> > >>> > And shouldn't the IPoIB sender subscribe to the IB multicast group >>> > creation events using a wildcard MGID so that it can >>> > "SendOnlyNonMember" join the group if a listener appears on the local > >> >>> > IB subnet, or "SendOnlyNonMember" join the all-routers group if a >>> > router appears on-link and creates the all-routers multicast group? >>> > And doesn't it need to subscribe to the IB multicast group deletion >>> > events so that it knows when to switch back to sending to the >>> > all-router multicast group and/or stop sending? >>> >>> Aren't you saying the same thing (more or less) as what is described in >>> the section following the code snippet? >> >>You are right - I must have missed the text. But you need to change the >>"should" to a "MUST" in that paragraph. > >Since the caching part is a "should", the subscription part ought to be >a "should" too, right? > >> >>> > >>> > But I'm wondering why a node needs to do this at all. Wouldn't it >>> > make more sense for the IPoIB node instead create the multicast group > >> >>> > and join the group so that IPoIB multicast routers can join the >>group? >>> > Yes, the IPoIB sender will need create the group as a "FullMember", >>> > but this seems to provide a simpler mapping of IP multicast to IB >>> > multicast. >>> >>> While what you suggested may simplify the procedure, it essentially >>> removes the difference between a multicast sender and a multicast >>receiver, >>> which is wrong. In the IP multicast model a multicast sender doesn't >>need >>> to be a member of a multicast group to send. The draft has tried to >>> keep the same distinction. >> >>However, you are mapping the IP multicast model to the IB multicast model, > >>and the two are not the same. The reality is a sender must join an IB >>multicast group in order to send to it (albeit as a "SendOnlyNonMember"), > >This is the big difference that was debated in IBTA. > >>and this step does not exist in the IP model. I imagine that the vast >>majority of the code/complexity of an IPoIB implementation is going to be >>dealing with IB multicasting. I was hoping there was some way to reduce >>both at an IPoIB host. Maybe it is just wishful thinking. > >I actually have the same philosophy as well. I'm always against complexity >unless it's fully justified. But IB multicast just works differently than >IP multicast. We have gone through a number of alternatives and the >current one seemed to a good balance between complexity and correctness. >I don't remember all the tradeoffs but if we simply require a sender >to be a full-member, how would one know when to leave a group, when to >delete a group..., etc. Also wouldn't it enable anyone to write a silly >sender program to try to send to a million different addresses and cause >all the IB multicast resources to be used up? (The join call by >IP_ADD_MEMBERSHIP at least places some resource limitation.) > > Yes, a major consideration has been the limited multicast resources >avaialble in IB. Some other issues were such as the case I described a >little while back: there is a very large chance of the router not receiving >the packet when the sender the group due to the possible delay in the >report reaching the router and the router IB_joining the group etc. > > >> >>By the way, after thinking about this a little more, I'm not sure that >>creating a group as I suggested makes sense in all cases. For instance, >>it is only useful for an IP multicast group which has a scope greater than > >>link-local. For link-local scope, only nodes directly attached to the >>IPoIB link are able to receive the packet. Creating the group for the >>purpose of forwarding to an IPoIB multicast router is simply wasteful, as >>the IPoIB multicast router will not be able to forward the packet to >>another IP link. >> >>A similar optimization can also be taken with the current approach >>described in this draft - for an IP multicast group with link-local scope, > >>if the IB MGID for that IP multicast group does not exist then an IPoIB >>node really doesn't need to send the multicast packet to the all-router >>MGID or broadcast GID. > >Correct. This level of details can arguably be left to implementation >because it doesn't affect interoperability. But I think this optimization >is simple and useful enough that I'll add a note to the draft. > > Agreed. > >> >>> >- Section 9.0 also indicates that "A multicast sender must join the >>> > target multicast group as a "SendOnlyNonMember" before outgoing >>> > messages from it can be successfully routed." This text should be >>> > clarified to indicate this is only true if the node has not already >>> > joined the group as either a "FullMember" or "SendOnlyNonMember". The > >> >>> > If-Then-Else logic below correctly shows this behavior, but this >>> > paragraph does not reflect that behavior. >>> >>> Although your comment is correct, I'd argue this kind of details can >>> be found in the IBA spec. It has nothing to do with IPoIB in particular, >>> So the question becomes how much IBA info we need to repeat in an IPoIB >>RFC. >>> Since the code sippet already covers this correctly, if you still >>believe >>> this needs to be clarified i can certain add more text to it. >> >>My feeling is enough to describe HOW an IPoIB node will USE the IBA >>services, and this is one of those cases. I would prefer to see the text >>clarified if you do another revision of the draft, but given the code >>snippet describes the correct behavior I wouldn't hold this draft up just >>to clarify this paragraph. > >Ok. > >> >>> >- Section 9.0 indicates that "For the rest of attributes, it is >>> > recommended the same values from the all-node multicast/broadcast >>> > group be used." Should this instead say "For the rest of the >>> > attributes, the same values from the all-node multicast/broadcast >>> > group SHOULD be used." Regardless of the wording, this text seems to >>> > contradict the Section 7.0 which states a node must "use the rest of >>> > the link attributes associated with the group for all future >>> > communication on the link. If Section 7.0 is correct, should this be > >> >>> > a MUST instead of a SHOULD? And, if not, under what circumstances >>> > would a node choose to not use the same values? >>> >>> 7.0 describes the attributes used by a node when conducting unicast >>> communication. 9.0 describes the attributes used to create a multicast >>> group, i.e., for multicast communication. So the question is: >>> Must path attributes used for unicast match with those for multicast? >>> >>> The flexibility allowed in the multicast case in the current draft is >>> deliberate. I don't know in reality if this is useful, or even good to >>> have. (Comments are welcome.) My design principle has been to not to >>> make something a requirement unless it is needed for interoperability. >> >>Flexibility is often times good, but so is describing a minimal set of >>functions necessary for interoperability. If a node selects link >>attributes when creating an MGID which does not match the broadcast GID's >>attributes, then it is possible that not all nodes which are members of >>the IPoIB link will be able to support those attributes. If this happens, > >>then the two nodes will not be able to communicate using the IP multicast >>group mapped to the MGID. All of a sudden, an IPoIB node can't send an >>ARP request or Neighbor Solicitation to another node. > >I think some of these "deliberate" flexibility (or ambuguity) came from >the ambuguity of IB itself in some of the mutlicast attributes such as >SL, TClass..., etc. It is not clear to me if they must or even can >follow the ones for unicast (i.e. described by the broadcast group) >in all cases. > >> >>Perhaps it would be better to state that a node which creates a multicast >>group MUST use the same values for the attributes as the all-node >>multicast/broadcast group, but a node joining a multicast group must not >>verify the values match. If the node joining the group can't support the >>values for the multicast group, then it should log the error. That way, a > >>future RFC could describe why/when/how a node would choose to use >>different values for the link attributes but still be able to interoperate > >>with IPoIB nodes. > >I'll leave the above for IB folks to comment. > >Jerry > >> >>Roy > >_______________________________________________ >IPoverIB mailing list >IPoverIB@ietf.org >https://www1.ietf.org/mailman/listinfo/ipoverib > > > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon May 12 17:54: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 RAA05133 for ; Mon, 12 May 2003 17:54:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CLJRB04059; Mon, 12 May 2003 17:19:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CLIZB04033 for ; Mon, 12 May 2003 17:18:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05051 for ; Mon, 12 May 2003 17:52:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FLFU-0004xU-00 for ipoverib@ietf.org; Mon, 12 May 2003 17:54:20 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19FLFT-0004xP-00 for ipoverib@ietf.org; Mon, 12 May 2003 17:54:19 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4CLslkc258242; Mon, 12 May 2003 17:54:47 -0400 Received: from w-vkashyap95.des.sequent.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4CLsjGr128946; Mon, 12 May 2003 15:54:46 -0600 Date: Mon, 12 May 2003 14:54:45 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: "H.K. Jerry Chu" cc: vivk@us.ibm.com, , Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt In-Reply-To: <200305110743.h4B7hEKQ856572@jurassic.eng.sun.com> Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Jerry, I believe you mean that the packet MUST be forwarded to the routers if they exist using one of all-router MGID or the broadcast-MGID. It at present could convey the meanning that one SHOULD forward the packet ie. decide not to forward the packet in some cases. How about rewriting it along the following lines: > > See my response to Roy (sorry for the delay). I'd suggest the following > paragraph: > > A) An IB multicast group must be explicitly created through the SA > before it can be used. > > This implies that in order to send a packet destined for an IP > multicast address, the IPoIB implementation must check with the SA on > the outbound link first for a "MCMemberRecord" that matches the MGID. > If one does exist, the MLID associated with the multicast group is > used as the DLID for the packet. Otherwise, it implies no member > exists on the local link. If the scope of the IP multicast group is > beyond link-local, and routers exist on the local subnet, the packet > SHOULD be forwarded to locally connected IP routers through the use > of the all-router multicast group or the broadcast group. This is to "...Otherwise, it implies no member exists on the local link. If the scope of the IP multicast packet is beyond link-local, the packet MUST be sent to the on-link routers to forward using one of (a) MGID mapped from the IP all-routers group (b) the Broadcast-GID. It is RECOMMENDED that the sender forward the packet using the MGID derived from the IP all-router multicast address. The all-router MGID is created as a result of the router's joining the all-router IP group. If such a group does not exist then the sender can assume that there are no routers on the link. Therefore if the sender has failed to IB_join the all-routers MGID or otherwise determined that the MGID doesn't exist the sender SHOULD NOT attempt to send the packet on the broadcast GID. Alternatively, as noted above, a sender MAY choose to transmit the packet directly on the broadcast-GID without checking the presence of the all-routers MGID." Thoughts? Vivek > allow local routers to forward the packet to multicast listeners on > remote networks. The all-router multicast group is preferred over the > broadcast group for better efficiency ... Vivek _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon May 12 17:54: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 RAA05147 for ; Mon, 12 May 2003 17:54:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CLKS304159 for ipoverib-archive@odin.ietf.org; Mon, 12 May 2003 17:20:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CLKSB04156 for ; Mon, 12 May 2003 17:20:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05122 for ; Mon, 12 May 2003 17:54:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FLHI-0004ya-00 for ipoverib-web-archive@ietf.org; Mon, 12 May 2003 17:56:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FLHI-0004yW-00 for ipoverib-web-archive@ietf.org; Mon, 12 May 2003 17:56:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CLJRB04059; Mon, 12 May 2003 17:19:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CLIZB04033 for ; Mon, 12 May 2003 17:18:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05051 for ; Mon, 12 May 2003 17:52:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FLFU-0004xU-00 for ipoverib@ietf.org; Mon, 12 May 2003 17:54:20 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19FLFT-0004xP-00 for ipoverib@ietf.org; Mon, 12 May 2003 17:54:19 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4CLslkc258242; Mon, 12 May 2003 17:54:47 -0400 Received: from w-vkashyap95.des.sequent.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4CLsjGr128946; Mon, 12 May 2003 15:54:46 -0600 Date: Mon, 12 May 2003 14:54:45 -0700 (Pacific Daylight Time) From: Vivek Kashyap To: "H.K. Jerry Chu" cc: vivk@us.ibm.com, , Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt In-Reply-To: <200305110743.h4B7hEKQ856572@jurassic.eng.sun.com> Message-ID: X-X-Sender: kashyapv@imap.linux.ibm.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Jerry, I believe you mean that the packet MUST be forwarded to the routers if they exist using one of all-router MGID or the broadcast-MGID. It at present could convey the meanning that one SHOULD forward the packet ie. decide not to forward the packet in some cases. How about rewriting it along the following lines: > > See my response to Roy (sorry for the delay). I'd suggest the following > paragraph: > > A) An IB multicast group must be explicitly created through the SA > before it can be used. > > This implies that in order to send a packet destined for an IP > multicast address, the IPoIB implementation must check with the SA on > the outbound link first for a "MCMemberRecord" that matches the MGID. > If one does exist, the MLID associated with the multicast group is > used as the DLID for the packet. Otherwise, it implies no member > exists on the local link. If the scope of the IP multicast group is > beyond link-local, and routers exist on the local subnet, the packet > SHOULD be forwarded to locally connected IP routers through the use > of the all-router multicast group or the broadcast group. This is to "...Otherwise, it implies no member exists on the local link. If the scope of the IP multicast packet is beyond link-local, the packet MUST be sent to the on-link routers to forward using one of (a) MGID mapped from the IP all-routers group (b) the Broadcast-GID. It is RECOMMENDED that the sender forward the packet using the MGID derived from the IP all-router multicast address. The all-router MGID is created as a result of the router's joining the all-router IP group. If such a group does not exist then the sender can assume that there are no routers on the link. Therefore if the sender has failed to IB_join the all-routers MGID or otherwise determined that the MGID doesn't exist the sender SHOULD NOT attempt to send the packet on the broadcast GID. Alternatively, as noted above, a sender MAY choose to transmit the packet directly on the broadcast-GID without checking the presence of the all-routers MGID." Thoughts? Vivek > allow local routers to forward the packet to multicast listeners on > remote networks. The all-router multicast group is preferred over the > broadcast group for better efficiency ... Vivek _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Thu May 29 07:30:50 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 HAA27314 for ; Thu, 29 May 2003 07:30:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TBTOB12445; Thu, 29 May 2003 07:29:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TBK5B12023 for ; Thu, 29 May 2003 07:20:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26881; Thu, 29 May 2003 07:20:04 -0400 (EDT) Message-Id: <200305291120.HAA26881@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, 29 May 2003 07:20:04 -0400 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibmib-tc-mib-03.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-03.txt Pages : 9 Date : 2003-5-28 This memo describes Textual Conventions and OBJECT-IDENTITIES for use in definitions of management information for IP Over InfiniBand (IPOVERIB) networks. The intent is that these TEXTUAL CONVENTIONs (TCs) will be imported and used in IPOVERIB related MIB modules A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-03.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-03.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-03.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-5-29072730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ibmib-tc-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29072730.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 May 29 07:30: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 HAA27328 for ; Thu, 29 May 2003 07:30:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TBUMD12505 for ipoverib-archive@odin.ietf.org; Thu, 29 May 2003 07:30:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TBUMB12502 for ; Thu, 29 May 2003 07:30:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27288 for ; Thu, 29 May 2003 07:30:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LLaN-0005YW-00 for ipoverib-web-archive@ietf.org; Thu, 29 May 2003 07:28:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LLaM-0005YR-00 for ipoverib-web-archive@ietf.org; Thu, 29 May 2003 07:28:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TBTOB12445; Thu, 29 May 2003 07:29:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TBK5B12023 for ; Thu, 29 May 2003 07:20:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26881; Thu, 29 May 2003 07:20:04 -0400 (EDT) Message-Id: <200305291120.HAA26881@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, 29 May 2003 07:20:04 -0400 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibmib-tc-mib-03.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-03.txt Pages : 9 Date : 2003-5-28 This memo describes Textual Conventions and OBJECT-IDENTITIES for use in definitions of management information for IP Over InfiniBand (IPOVERIB) networks. The intent is that these TEXTUAL CONVENTIONs (TCs) will be imported and used in IPOVERIB related MIB modules A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-03.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-03.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-03.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-5-29072730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ibmib-tc-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29072730.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib