From exim@www1.ietf.org Mon Jan 5 16:22:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04713 for ; Mon, 5 Jan 2004 16:22:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdcAY-000596-9k for ipoverib-archive@odin.ietf.org; Mon, 05 Jan 2004 16:21:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05LLoEB019776 for ipoverib-archive@odin.ietf.org; Mon, 5 Jan 2004 16:21:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdcAY-00058t-5E for ipoverib-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 16:21:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04672 for ; Mon, 5 Jan 2004 16:21:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdcAR-0006bj-00 for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 16:21:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adc32-0006K9-00 for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 16:14:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Adbyf-00063Y-00 for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 16:09:33 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Adbfv-0006ae-WF for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 15:50:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adbfm-0003yL-SN; Mon, 05 Jan 2004 15:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbfD-0003x5-I5 for ipoverib@optimus.ietf.org; Mon, 05 Jan 2004 15:49:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03308 for ; Mon, 5 Jan 2004 15:49:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbfC-00057C-00 for ipoverib@ietf.org; Mon, 05 Jan 2004 15:49:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbdF-0004tQ-00 for ipoverib@ietf.org; Mon, 05 Jan 2004 15:47:27 -0500 Received: from kairos.dsa.uqam.ca ([132.208.43.57]) by ietf-mx with esmtp (Exim 4.12) id 1AdbbD-0004hU-00 for ipoverib@ietf.org; Mon, 05 Jan 2004 15:45:19 -0500 Received: from mobilebill (Kairos.dsa.uqam.ca [132.208.43.57]) by Kairos.dsa.uqam.ca (8.11.4/8.11.4) with ESMTP id i05KKv114009 for ; Mon, 5 Jan 2004 15:20:57 -0500 From: "bill" To: Subject: RE: [Ipoverib] GID clarifications Date: Mon, 5 Jan 2004 12:44:36 -0800 Message-ID: <000001c3d3cc$bc068980$f5d912c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3FD53C10.13C4B2EF@Sun.COM> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Looks like there are good reasons to clean up the definition of the GID to be used (Making it SHOULD use GID0) I think that is concensus that everyone can live with. Objections ? Bill -----Original Message----- From: ipoverib-admin@ietf.org [mailto:ipoverib-admin@ietf.org] On Behalf Of Kanoj Sarcar Sent: Monday, December 08, 2003 7:06 PM To: Michael Krause Cc: ipoverib@ietf.org Subject: Re: [Ipoverib] GID clarifications Michael Krause wrote: > > At 08:22 PM 12/7/2003 -0800, H.K. Jerry Chu wrote: > >Mike, Hi, Michael, thanks for providing the IBTA context about multiple GIDs and path selection. > > > > >At 06:04 PM 12/4/2003 -0800, bill wrote: > > >>Ok, let me ask a few questions to lead us toward concensus > > > > > >As the author of the IB spec for chapter 4, I'll attempt to provide > > >some clarifications. > > > > > >>1) Does anyone give a compelling reason to use anything but GID0 > > >>for IPoIB > > >>- what is the benefit of doing this ? > > > > > >Multiple GIDs were provided as a method to: > > > > > >- Provide traffic segregation between subnets conceptually similar > > >to multi-LID usage within a single subnet. > > > >According to IBA 1.0a spec (i don't have 1.1 spec at hand), "A subnet > >shall have only one assigned GID prefix at any given time (at GID > >index 0)." It seems to me unless a CA port can be simultaneously > >connected to more than one IB subnet, the unique subnet prefix plus > >the default GID prefix (the link-local 0xFF80 prefix) are the only > >two possible values to have for the upper 64 bits of a GID. > > Correct. One can have either the default or an assigned thus all GID > share one or the other. > > > I wonder what the traffic seggregation between subnets you have in > > mind. > > The basic idea was one could encode in the lower 64 bits (these are > admin assigned if not the port EUI64 value) or through a combination > of other GRH attributes (e.g. TClass, Flow Label, etc.) one could > segregate traffic to take different paths when passing through a > router. The path selection would be implemented via selecting an > egress port and assigning an appropriate next router hop / endnode > LID. It seems to me that for endports to influence which path to use for each UD packet, the SM and the endnodes need to exchange some information. I was under the impression that SL/VL information within a IBA subnet, and additionally Tclass etc between IBA subnets, would be sufficient; ie, segregation could be achieved with just these parameters, and would not need to extend to source GID. I am not sure whether your use of the word "or" above means that this is still a viable option. > > > >- Provide a method to support software / OS virtualization and > > >device sharing via using a unique global identifier independent of > > >the number of LIDs assigned (though one can take a similar approach > > >if the LMC value is greater than 0. > > > > > >I will note that there are many OSVs offering or starting to offer > > >virtualization services and while some initial implementations may > > >be focused on GID 0, this may not hold true in the coming few > > >years. > > > >Not sure what flavor of "virtualization" you're alluding to. If the > >virtualization is achieved through the use of multiple IB partitions, > >different IB partitions can safely share the same GID much like > >different Ethernet VLAN sharing the same MAC address. I don't see the > >need for multiple GIDs. > > Virtualization is nominally a function of address while partitions are > a function of segregation enforcement ala 802.1Q. While one can use > partitions, they are not seen by the underlying software while a GRH > is seen thus depending upon how it is implemented, how the remote peer > "sees" each target peer, etc. a GID is more flexible and may align > better with application usage. Please keep in mind I'm explaining how > the motivation for multiple GID from an IBA perspective. Now, can one > use a single GID with multiple P_Key and then have a unique IP-to-QP > mapping per resulting partition to achieve something similar? The > answer is yes, it is possible but that was not the intent of the IBTA > when this was first being debated. > > >Perhaps you meant virtualization like the hosting of multiple IP > >addressses with the same subnet prefix but different host numbers on > >the same NIC, this can be achieved through the use of multiple > >locally-assigned EUI-64s in IB, and I agree it is a useful feature to > >support. At least from the ipoib perspective, it is also possible to virtualize based on the QPN (using same Pkey), since that is part of the mac address. I do agree that virtualization based on GIDs is attractive. > > > > > > > >- Provide a method to constrain out some data flows are routed - > > >local vs. non-local subnet access given a GID can use either the > > >default or the SM assigned subnet prefix. > > > >Note that the draft currently recommends the use of the IB subnet > >prefix for the GID in IPoIB. Although the real requirement is that > >the GID must be reachable (i.e. routable) at the IB layer from any > >node within the scope of the IP link it belongs to, recommending the > >IB subnet prefix is less error prone as it continues to work even > >after the underlying IP link has been expanded to cover multiple IB > >subnets. > > Agreed. > > > > > > >>2) Does anyone have an implementation that uses anything but GID0 > > >>for > > IPoIB ? > > > > > >I believe it would be a mistake to limit support to just GID 0. IB > > >technology was designed to support a diverse set of usage models > > >that will evolve over time. The only potential problem was a DLPI > > >application raw level usage model which is (a) somewhat outside of > > >the scope of the IP over IB specification and (b) rather limited in > > >terms of usage within the industry. I don't really want to debate > > >the merits of raw DLPI but do acknowledge it is in use today on > > >Ethernet and other layer 2 interconnects. > > > Note that as has been pointed out, it is also possible for non DLPI apps to want to know the sender's L2 address (trivially possible on ethernet by looking at the received packet and picking out the source ethernet address). As you point out, this might be slightly out of scope, but here's an example that is within scope: imagine a node A with mac address M1 wants to know what IP address the RARP server will assign for a different mac address M2; it can fabricate a RARP message and broadcast it out; the RARP server must send the RARP response to M1 and not to M2. For this, the RARP server must be able to determine that the sender's L2 address is M1. Similarly, an ARP implementation might want to determine the sender of an ARP request and validate against the "sender hardware address" in the ARP message. I can't make a call on how extensive this type of usage is though. Thanks. Kanoj > > >>If I do not hear any counter arguments by next Friday - I would > > >>like to ask for concensus on MUST use GID0 > > > > > >Please consider this a counter argument and a vote against such a > > >movement. > > > >You are opposing requiring GID0, but are you ok with the current > >wording of RECOMMENDING the GID formed by the IB subnet prefix and > >the portGUID (the one assigned by the manufacturer)? > > I can live with RECOMMENDING not with MUST. > > >BTW, I'm confused by the use of GID0 as I thought in IBA spec. it > >means the one with the link-local prefix but I thought people wanted > >to use the one with the IB subnet prefix. > > GID 0 is just the guaranteed GID to be created via the combination of > the port GUID (manufacturer assigned GUID) and the subnet prefix. > > Mike > > >Jerry > > > > > > > >Mike > > > > > > > > >_______________________________________________ > > >IPoverIB mailing list > > >IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > >_______________________________________________ > >IPoverIB mailing list > >IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From exim@www1.ietf.org Mon Jan 5 18:46:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14141 for ; Mon, 5 Jan 2004 18:46:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeQ0-0004LO-Ct for ipoverib-archive@odin.ietf.org; Mon, 05 Jan 2004 18:45:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05NjuEt016694 for ipoverib-archive@odin.ietf.org; Mon, 5 Jan 2004 18:45:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeQ0-0004LB-9O for ipoverib-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 18:45:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14126 for ; Mon, 5 Jan 2004 18:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdePx-0003RQ-00 for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 18:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdeOa-0003JN-00 for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 18:44:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AdeNA-00035O-00 for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 18:43:00 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AdeNB-0002Bh-5B for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 18:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeNB-0004DU-M9; Mon, 05 Jan 2004 18:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeMy-0004D4-7w for ipoverib@optimus.ietf.org; Mon, 05 Jan 2004 18:42:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13751 for ; Mon, 5 Jan 2004 18:42:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdeMv-000349-00 for ipoverib@ietf.org; Mon, 05 Jan 2004 18:42:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdeLF-0002iQ-00 for ipoverib@ietf.org; Mon, 05 Jan 2004 18:41:02 -0500 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx with esmtp (Exim 4.12) id 1AdeIH-0001rh-00 for ipoverib@ietf.org; Mon, 05 Jan 2004 18:37:57 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel11.hp.com (Postfix) with ESMTP id 590171C00380 for ; Mon, 5 Jan 2004 15:37:55 -0800 (PST) Received: from mk731915.cup.hp.com ([15.244.170.179]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id i05NTDS16005 for ; Mon, 5 Jan 2004 15:29:13 -0800 (PST) Message-Id: <5.1.0.14.2.20040105153158.00a926b0@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 Jan 2004 15:36:45 -0800 To: From: Michael Krause Subject: RE: [Ipoverib] GID clarifications In-Reply-To: <000001c3d3cc$bc068980$f5d912c0@mobilebill> References: <3FD53C10.13C4B2EF@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 12:44 PM 1/5/2004 -0800, bill wrote: >Folks, > >Looks like there are good reasons to clean up the definition of the GID >to be used (Making it SHOULD use GID0) > >I think that is concensus that everyone can live with. > >Objections ? None. Some comments in-lined below. Mike >Bill > >-----Original Message----- >From: ipoverib-admin@ietf.org [mailto:ipoverib-admin@ietf.org] On Behalf >Of Kanoj Sarcar >Sent: Monday, December 08, 2003 7:06 PM >To: Michael Krause >Cc: ipoverib@ietf.org >Subject: Re: [Ipoverib] GID clarifications > > >Michael Krause wrote: > > > > At 08:22 PM 12/7/2003 -0800, H.K. Jerry Chu wrote: > > >Mike, > >Hi, > >Michael, thanks for providing the IBTA context about multiple GIDs and >path selection. > > > > > > > >At 06:04 PM 12/4/2003 -0800, bill wrote: > > > >>Ok, let me ask a few questions to lead us toward concensus > > > > > > > >As the author of the IB spec for chapter 4, I'll attempt to provide > > > > >some clarifications. > > > > > > > >>1) Does anyone give a compelling reason to use anything but GID0 > > > >>for IPoIB > > > >>- what is the benefit of doing this ? > > > > > > > >Multiple GIDs were provided as a method to: > > > > > > > >- Provide traffic segregation between subnets conceptually similar > > > >to multi-LID usage within a single subnet. > > > > > >According to IBA 1.0a spec (i don't have 1.1 spec at hand), "A subnet > > > >shall have only one assigned GID prefix at any given time (at GID > > >index 0)." It seems to me unless a CA port can be simultaneously > > >connected to more than one IB subnet, the unique subnet prefix plus > > >the default GID prefix (the link-local 0xFF80 prefix) are the only > > >two possible values to have for the upper 64 bits of a GID. > > > > Correct. One can have either the default or an assigned thus all GID > > share one or the other. > > > > > I wonder what the traffic seggregation between subnets you have in > > > mind. > > > > The basic idea was one could encode in the lower 64 bits (these are > > admin assigned if not the port EUI64 value) or through a combination > > of other GRH attributes (e.g. TClass, Flow Label, etc.) one could > > segregate traffic to take different paths when passing through a > > router. The path selection would be implemented via selecting an > > egress port and assigning an appropriate next router hop / endnode > > LID. > >It seems to me that for endports to influence which path to >use for each UD packet, the SM and the endnodes need to exchange >some information. I was under the impression that SL/VL information >within a IBA subnet, and additionally Tclass etc between IBA >subnets, would be sufficient; ie, segregation could be achieved with >just these parameters, and would not need to extend to source GID. I am >not sure whether your use of the word "or" above means that this is >still a viable option. It is still viable. > > > >- Provide a method to support software / OS virtualization and > > > >device sharing via using a unique global identifier independent of > > > >the number of LIDs assigned (though one can take a similar approach > > > > >if the LMC value is greater than 0. > > > > > > > >I will note that there are many OSVs offering or starting to offer > > > >virtualization services and while some initial implementations may > > > >be focused on GID 0, this may not hold true in the coming few > > > >years. > > > > > >Not sure what flavor of "virtualization" you're alluding to. If the > > >virtualization is achieved through the use of multiple IB partitions, > > > >different IB partitions can safely share the same GID much like > > >different Ethernet VLAN sharing the same MAC address. I don't see the > > > >need for multiple GIDs. > > > > Virtualization is nominally a function of address while partitions are > > > a function of segregation enforcement ala 802.1Q. While one can use > > partitions, they are not seen by the underlying software while a GRH > > is seen thus depending upon how it is implemented, how the remote peer > > > "sees" each target peer, etc. a GID is more flexible and may align > > better with application usage. Please keep in mind I'm explaining how > > > the motivation for multiple GID from an IBA perspective. Now, can one > > > use a single GID with multiple P_Key and then have a unique IP-to-QP > > mapping per resulting partition to achieve something similar? The > > answer is yes, it is possible but that was not the intent of the IBTA > > when this was first being debated. > > > > >Perhaps you meant virtualization like the hosting of multiple IP > > >addressses with the same subnet prefix but different host numbers on > > >the same NIC, this can be achieved through the use of multiple > > >locally-assigned EUI-64s in IB, and I agree it is a useful feature to > > > >support. > >At least from the ipoib perspective, it is also possible to >virtualize based on the QPN (using same Pkey), since that is >part of the mac address. I do agree that virtualization based on GIDs is >attractive. It is possible to use multiple QPN and one would expect that there would be a unique QP per GID or per whatever is the attribute being used to differentiate traffic. > > > > > > > > > > >- Provide a method to constrain out some data flows are routed - > > > >local vs. non-local subnet access given a GID can use either the > > > >default or the SM assigned subnet prefix. > > > > > >Note that the draft currently recommends the use of the IB subnet > > >prefix for the GID in IPoIB. Although the real requirement is that > > >the GID must be reachable (i.e. routable) at the IB layer from any > > >node within the scope of the IP link it belongs to, recommending the > > >IB subnet prefix is less error prone as it continues to work even > > >after the underlying IP link has been expanded to cover multiple IB > > >subnets. > > > > Agreed. > > > > > > > > > >>2) Does anyone have an implementation that uses anything but GID0 > > > >>for > > > IPoIB ? > > > > > > > >I believe it would be a mistake to limit support to just GID 0. IB > > > > >technology was designed to support a diverse set of usage models > > > >that will evolve over time. The only potential problem was a DLPI > > > >application raw level usage model which is (a) somewhat outside of > > > >the scope of the IP over IB specification and (b) rather limited in > > > > >terms of usage within the industry. I don't really want to debate > > > >the merits of raw DLPI but do acknowledge it is in use today on > > > >Ethernet and other layer 2 interconnects. > > > > > >Note that as has been pointed out, it is also possible for non DLPI apps >to want to know the sender's L2 address (trivially possible on ethernet by >looking at the received packet and picking out the source ethernet >address). As you point out, this might be slightly out of scope, but >here's an example that is within scope: imagine a node A with mac address >M1 wants to know what IP address the RARP server will assign for a >different mac address M2; it can fabricate a RARP message and broadcast it >out; the RARP server must send the RARP response to M1 and not to M2. For >this, the RARP server must be able to determine that the sender's L2 >address is M1. Similarly, an ARP implementation might want to >determine the sender of an ARP request and validate against the "sender >hardware address" in the ARP message. I can't make a call on how extensive >this type of usage is though. A lesson I've learned over the years in developing new technology is that "one can envision" many things which often are quite cool in various aspects. However, the world often moves to a different beat as technology commodization (economic) combined with "good enough" technology eliminates the "envision" cool idea for KISS. >Thanks. > >Kanoj > > > > > >>If I do not hear any counter arguments by next Friday - I would > > > >>like to ask for concensus on MUST use GID0 > > > > > > > >Please consider this a counter argument and a vote against such a > > > >movement. > > > > > >You are opposing requiring GID0, but are you ok with the current > > >wording of RECOMMENDING the GID formed by the IB subnet prefix and > > >the portGUID (the one assigned by the manufacturer)? > > > > I can live with RECOMMENDING not with MUST. > > > > >BTW, I'm confused by the use of GID0 as I thought in IBA spec. it > > >means the one with the link-local prefix but I thought people wanted > > >to use the one with the IB subnet prefix. > > > > GID 0 is just the guaranteed GID to be created via the combination of > > the port GUID (manufacturer assigned GUID) and the subnet prefix. > > > > Mike > > > > >Jerry > > > > > > > > > > >Mike > > > > > > > > > > > >_______________________________________________ > > > >IPoverIB mailing list > > > >IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > >_______________________________________________ > > >IPoverIB mailing list > > >IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > > > > _______________________________________________ > > IPoverIB mailing list > > IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > >_______________________________________________ >IPoverIB mailing list >IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > > >_______________________________________________ >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 exim@www1.ietf.org Mon Jan 5 19:40:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15814 for ; Mon, 5 Jan 2004 19:40:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfGN-0006e6-TA for ipoverib-archive@odin.ietf.org; Mon, 05 Jan 2004 19:40:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i060e3O9025532 for ipoverib-archive@odin.ietf.org; Mon, 5 Jan 2004 19:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfGK-0006dK-O0 for ipoverib-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 19:40:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15709 for ; Mon, 5 Jan 2004 19:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdfGI-00060U-00 for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 19:39:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfEz-0005oP-00 for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 19:38:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Adf8u-0005X1-00 for ipoverib-web-archive@ietf.org; Mon, 05 Jan 2004 19:32:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adf8b-0005zM-8k; Mon, 05 Jan 2004 19:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adf7d-0005wM-NX for ipoverib@optimus.ietf.org; Mon, 05 Jan 2004 19:31:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15419 for ; Mon, 5 Jan 2004 19:30:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adf7X-0005P9-00 for ipoverib@ietf.org; Mon, 05 Jan 2004 19:30:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adf2T-0005E2-00 for ipoverib@ietf.org; Mon, 05 Jan 2004 19:25:42 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1Adeze-00054G-00 for ipoverib@ietf.org; Mon, 05 Jan 2004 19:22:46 -0500 Received: from phys-bos-1.sfbay.sun.com ([129.146.14.23]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i060Lqj6020887 for ; Mon, 5 Jan 2004 16:21:52 -0800 (PST) Received: from Sun.COM (sr1-umpk-09.SFBay.Sun.COM [129.146.11.175]) by bos-mail1.sfbay.sun.com (Sun ONE Messaging Server 6.0 (built Sep 24 2003)) with ESMTP id <0HR1008AAL0FWT80@bos-mail1.sfbay.sun.com> for ipoverib@ietf.org; Mon, 05 Jan 2004 16:21:52 -0800 (PST) Date: Mon, 05 Jan 2004 16:21:51 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] GID clarifications To: Michael Krause Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3FF9FF9F.B9722101@Sun.COM> MIME-version: 1.0 X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.9 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3FD53C10.13C4B2EF@Sun.COM> <5.1.0.14.2.20040105153158.00a926b0@15.13.130.73> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Krause wrote: > > At 12:44 PM 1/5/2004 -0800, bill wrote: > >Folks, > > > >Looks like there are good reasons to clean up the definition of the GID > >to be used (Making it SHOULD use GID0) > > > >I think that is concensus that everyone can live with. > > > >Objections ? Hi, Given the previous discussions, I am willing to live with "SHOULD use GID0" in the interest of forward progress. > > None. Some comments in-lined below. See bottom of email for clarification. > > Mike > > >Bill > > > >-----Original Message----- > >From: ipoverib-admin@ietf.org [mailto:ipoverib-admin@ietf.org] On Behalf > >Of Kanoj Sarcar > >Sent: Monday, December 08, 2003 7:06 PM > >To: Michael Krause > >Cc: ipoverib@ietf.org > >Subject: Re: [Ipoverib] GID clarifications > > > > > >Michael Krause wrote: > > > > > > At 08:22 PM 12/7/2003 -0800, H.K. Jerry Chu wrote: > > > >Mike, > > > >Hi, > > > >Michael, thanks for providing the IBTA context about multiple GIDs and > >path selection. > > > > > > > > > > >At 06:04 PM 12/4/2003 -0800, bill wrote: > > > > >>Ok, let me ask a few questions to lead us toward concensus > > > > > > > > > >As the author of the IB spec for chapter 4, I'll attempt to provide > > > > > > >some clarifications. > > > > > > > > > >>1) Does anyone give a compelling reason to use anything but GID0 > > > > >>for IPoIB > > > > >>- what is the benefit of doing this ? > > > > > > > > > >Multiple GIDs were provided as a method to: > > > > > > > > > >- Provide traffic segregation between subnets conceptually similar > > > > >to multi-LID usage within a single subnet. > > > > > > > >According to IBA 1.0a spec (i don't have 1.1 spec at hand), "A subnet > > > > > >shall have only one assigned GID prefix at any given time (at GID > > > >index 0)." It seems to me unless a CA port can be simultaneously > > > >connected to more than one IB subnet, the unique subnet prefix plus > > > >the default GID prefix (the link-local 0xFF80 prefix) are the only > > > >two possible values to have for the upper 64 bits of a GID. > > > > > > Correct. One can have either the default or an assigned thus all GID > > > share one or the other. > > > > > > > I wonder what the traffic seggregation between subnets you have in > > > > mind. > > > > > > The basic idea was one could encode in the lower 64 bits (these are > > > admin assigned if not the port EUI64 value) or through a combination > > > of other GRH attributes (e.g. TClass, Flow Label, etc.) one could > > > segregate traffic to take different paths when passing through a > > > router. The path selection would be implemented via selecting an > > > egress port and assigning an appropriate next router hop / endnode > > > LID. > > > >It seems to me that for endports to influence which path to > >use for each UD packet, the SM and the endnodes need to exchange > >some information. I was under the impression that SL/VL information > >within a IBA subnet, and additionally Tclass etc between IBA > >subnets, would be sufficient; ie, segregation could be achieved with > >just these parameters, and would not need to extend to source GID. I am > >not sure whether your use of the word "or" above means that this is > >still a viable option. > > It is still viable. > > > > > >- Provide a method to support software / OS virtualization and > > > > >device sharing via using a unique global identifier independent of > > > > >the number of LIDs assigned (though one can take a similar approach > > > > > > >if the LMC value is greater than 0. > > > > > > > > > >I will note that there are many OSVs offering or starting to offer > > > > >virtualization services and while some initial implementations may > > > > >be focused on GID 0, this may not hold true in the coming few > > > > >years. > > > > > > > >Not sure what flavor of "virtualization" you're alluding to. If the > > > >virtualization is achieved through the use of multiple IB partitions, > > > > > >different IB partitions can safely share the same GID much like > > > >different Ethernet VLAN sharing the same MAC address. I don't see the > > > > > >need for multiple GIDs. > > > > > > Virtualization is nominally a function of address while partitions are > > > > > a function of segregation enforcement ala 802.1Q. While one can use > > > partitions, they are not seen by the underlying software while a GRH > > > is seen thus depending upon how it is implemented, how the remote peer > > > > > "sees" each target peer, etc. a GID is more flexible and may align > > > better with application usage. Please keep in mind I'm explaining how > > > > > the motivation for multiple GID from an IBA perspective. Now, can one > > > > > use a single GID with multiple P_Key and then have a unique IP-to-QP > > > mapping per resulting partition to achieve something similar? The > > > answer is yes, it is possible but that was not the intent of the IBTA > > > when this was first being debated. > > > > > > >Perhaps you meant virtualization like the hosting of multiple IP > > > >addressses with the same subnet prefix but different host numbers on > > > >the same NIC, this can be achieved through the use of multiple > > > >locally-assigned EUI-64s in IB, and I agree it is a useful feature to > > > > > >support. > > > >At least from the ipoib perspective, it is also possible to > >virtualize based on the QPN (using same Pkey), since that is > >part of the mac address. I do agree that virtualization based on GIDs is > >attractive. > > It is possible to use multiple QPN and one would expect that there would be > a unique QP per GID or per whatever is the attribute being used to > differentiate traffic. > > > > > > > > > > > > > > >- Provide a method to constrain out some data flows are routed - > > > > >local vs. non-local subnet access given a GID can use either the > > > > >default or the SM assigned subnet prefix. > > > > > > > >Note that the draft currently recommends the use of the IB subnet > > > >prefix for the GID in IPoIB. Although the real requirement is that > > > >the GID must be reachable (i.e. routable) at the IB layer from any > > > >node within the scope of the IP link it belongs to, recommending the > > > >IB subnet prefix is less error prone as it continues to work even > > > >after the underlying IP link has been expanded to cover multiple IB > > > >subnets. > > > > > > Agreed. > > > > > > > > > > > > >>2) Does anyone have an implementation that uses anything but GID0 > > > > >>for > > > > IPoIB ? > > > > > > > > > >I believe it would be a mistake to limit support to just GID 0. IB > > > > > > >technology was designed to support a diverse set of usage models > > > > >that will evolve over time. The only potential problem was a DLPI > > > > >application raw level usage model which is (a) somewhat outside of > > > > >the scope of the IP over IB specification and (b) rather limited in > > > > > > >terms of usage within the industry. I don't really want to debate > > > > >the merits of raw DLPI but do acknowledge it is in use today on > > > > >Ethernet and other layer 2 interconnects. > > > > > > > > >Note that as has been pointed out, it is also possible for non DLPI apps > >to want to know the sender's L2 address (trivially possible on ethernet by > >looking at the received packet and picking out the source ethernet > >address). As you point out, this might be slightly out of scope, but > >here's an example that is within scope: imagine a node A with mac address > >M1 wants to know what IP address the RARP server will assign for a > >different mac address M2; it can fabricate a RARP message and broadcast it > >out; the RARP server must send the RARP response to M1 and not to M2. For > >this, the RARP server must be able to determine that the sender's L2 > >address is M1. Similarly, an ARP implementation might want to > >determine the sender of an ARP request and validate against the "sender > >hardware address" in the ARP message. I can't make a call on how extensive > >this type of usage is though. > > A lesson I've learned over the years in developing new technology is that > "one can envision" many things which often are quite cool in various > aspects. However, the world often moves to a different beat as technology > commodization (economic) combined with "good enough" technology eliminates > the "envision" cool idea for KISS. I was not clear enough (ie, the above examples are not just envisioned ones): SUN's RARP server implementation does support 3rd party lookup, wherein the RARP response is sent by the server to the node M1 and not to M2 (in the example above). This is of course possible on ethernet by figuring out M1's address from the ethernet packet, but there is no similar mechanism on IPoIB (on IPoIB, the response can only be sent to the hardware address in the RARP packet, so no 3rd party lookup can be supported). I don't know how many people use this 3rd party lookup feature on ethernet (and I do realize RARP on IPoIB might not make sense given the transient nature of IPoIB mac address). I do not have an example of the ARP validation example mentioned above though. Thanks. Kanoj > > >Thanks. > > > >Kanoj > > > > > > > > >>If I do not hear any counter arguments by next Friday - I would > > > > >>like to ask for concensus on MUST use GID0 > > > > > > > > > >Please consider this a counter argument and a vote against such a > > > > >movement. > > > > > > > >You are opposing requiring GID0, but are you ok with the current > > > >wording of RECOMMENDING the GID formed by the IB subnet prefix and > > > >the portGUID (the one assigned by the manufacturer)? > > > > > > I can live with RECOMMENDING not with MUST. > > > > > > >BTW, I'm confused by the use of GID0 as I thought in IBA spec. it > > > >means the one with the link-local prefix but I thought people wanted > > > >to use the one with the IB subnet prefix. > > > > > > GID 0 is just the guaranteed GID to be created via the combination of > > > the port GUID (manufacturer assigned GUID) and the subnet prefix. > > > > > > Mike > > > > > > >Jerry > > > > > > > > > > > > > >Mike > > > > > > > > > > > > > > >_______________________________________________ > > > > >IPoverIB mailing list > > > > >IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > > > > > > >_______________________________________________ > > > >IPoverIB mailing list > > > >IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > _______________________________________________ > > > IPoverIB mailing list > > > IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > > > >_______________________________________________ > >IPoverIB mailing list > >IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > >_______________________________________________ > >IPoverIB mailing list > >IPoverIB@ietf.org > >https://www1.ietf.org/mailman/listinfo/ipoverib > > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From exim@www1.ietf.org Wed Jan 7 16:04:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01940 for ; Wed, 7 Jan 2004 16:04:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeKqr-0001Qk-Bp for ipoverib-archive@odin.ietf.org; Wed, 07 Jan 2004 16:04:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07L4TYI005498 for ipoverib-archive@odin.ietf.org; Wed, 7 Jan 2004 16:04:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeKqr-0001Qb-8l for ipoverib-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 16:04:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01885 for ; Wed, 7 Jan 2004 16:04:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeKqp-0003jV-00 for ipoverib-web-archive@ietf.org; Wed, 07 Jan 2004 16:04:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeKoz-0003cw-00 for ipoverib-web-archive@ietf.org; Wed, 07 Jan 2004 16:02:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeKoS-0003WW-00 for ipoverib-web-archive@ietf.org; Wed, 07 Jan 2004 16:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeKoT-0000hp-0B; Wed, 07 Jan 2004 16:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeKnh-0000hG-Uz for ipoverib@optimus.ietf.org; Wed, 07 Jan 2004 16:01:14 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01446; Wed, 7 Jan 2004 16:01:11 -0500 (EST) Message-Id: <200401072101.QAA01446@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: Wed, 07 Jan 2004 16:01:11 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibmib-tc-mib-04.txt Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-04.txt Pages : 9 Date : 2004-1-7 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-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-ibmib-tc-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-7152606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ibmib-tc-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-7152606.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From exim@www1.ietf.org Mon Jan 12 16:14:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20246 for ; Mon, 12 Jan 2004 16:14:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9Nv-0005i9-6c for ipoverib-archive@odin.ietf.org; Mon, 12 Jan 2004 16:14:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CLE7oa021949 for ipoverib-archive@odin.ietf.org; Mon, 12 Jan 2004 16:14:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9Nv-0005hw-2z for ipoverib-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 16:14:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20216 for ; Mon, 12 Jan 2004 16:14:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9Nt-0000ZM-00 for ipoverib-web-archive@ietf.org; Mon, 12 Jan 2004 16:14:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9MI-0000VN-00 for ipoverib-web-archive@ietf.org; Mon, 12 Jan 2004 16:12:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag9Kv-0000LY-00 for ipoverib-web-archive@ietf.org; Mon, 12 Jan 2004 16:11:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9Kv-0005bl-I0; Mon, 12 Jan 2004 16:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9Ks-0005bE-CO for ipoverib@optimus.ietf.org; Mon, 12 Jan 2004 16:10:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19709 for ; Mon, 12 Jan 2004 16:10:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9Kq-0000Kv-00 for ipoverib@ietf.org; Mon, 12 Jan 2004 16:10:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9Iq-00005R-00 for ipoverib@ietf.org; Mon, 12 Jan 2004 16:08:53 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9Gu-0007i9-00 for ipoverib@ietf.org; Mon, 12 Jan 2004 16:06:53 -0500 Received: from jurassic.eng.sun.com ([129.146.89.31]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0CL6qqV018959 for ; Mon, 12 Jan 2004 14:06:52 -0700 (MST) Received: from taipei (taipei.SFBay.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.11.Beta1+Sun/8.12.11.Beta1) with SMTP id i0CL6oQV143031 for ; Mon, 12 Jan 2004 13:06:52 -0800 (PST) Message-Id: <200401122106.i0CL6oQV143031@jurassic.eng.sun.com> Date: Mon, 12 Jan 2004 13:06:37 -0800 (PST) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" To: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: P9NR9rQsK8tgsMHod/m44g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_33 SunOS 5.10 sun4u sparc Subject: [Ipoverib] Seoul IETF (Feb 29 - Mar 5) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 The following is the Important Meeting Dates. Since the WG scheduling closes in one month, if you plan to attend and/or have presentation to make, please let Bill and I know ASAP. Now is also the time to book hotel. 59th IETF Meeting - Seoul, Korea Important Meeting Dates December 15, Monday - Working Group and BOF scheduling begins Week of December 15 - Registration begins February 9, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET February 12, Thursday - Working Group and BOF scheduling closes at 17:00 ET February 16, Monday - Internet Draft final submission cut-off at 09:00 ET February 16, Monday - Pre-Registration and Pre-payment cut-off at 12:00 noon ET February 23, Monday - Registration cancellation cut-off at 17:00 ET February 24, Tuesday - Working Group agendas due date at 12:00 ET February 29-March 5 - 59th IETF Meeting in Seoul, Korea April 2, Friday - Proceedings submission cutoff date by 17:00 ET, send to proceedings@ietf.org * All times are in US Eastern Time Jerry _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From exim@www1.ietf.org Tue Jan 20 17:37:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28825 for ; Tue, 20 Jan 2004 17:37:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj4UE-00070O-2r for ipoverib-archive@odin.ietf.org; Tue, 20 Jan 2004 17:36:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KMagl5026927 for ipoverib-archive@odin.ietf.org; Tue, 20 Jan 2004 17:36:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj4UD-00070B-VV for ipoverib-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 17:36:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28807 for ; Tue, 20 Jan 2004 17:36:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj4UB-0002X1-00 for ipoverib-web-archive@ietf.org; Tue, 20 Jan 2004 17:36:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj4TD-0002UE-00 for ipoverib-web-archive@ietf.org; Tue, 20 Jan 2004 17:35:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj4Sc-0002Ry-00 for ipoverib-web-archive@ietf.org; Tue, 20 Jan 2004 17:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj4Sb-0006wB-G8; Tue, 20 Jan 2004 17:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj4SF-0006vk-PO for ipoverib@optimus.ietf.org; Tue, 20 Jan 2004 17:34:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28738 for ; Tue, 20 Jan 2004 17:34:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj4SD-0002Qy-00 for ipoverib@ietf.org; Tue, 20 Jan 2004 17:34:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj4RM-0002P1-00 for ipoverib@ietf.org; Tue, 20 Jan 2004 17:33:45 -0500 Received: from kairos.dsa.uqam.ca ([132.208.43.57]) by ietf-mx with esmtp (Exim 4.12) id 1Aj4R5-0002M1-00 for ipoverib@ietf.org; Tue, 20 Jan 2004 17:33:27 -0500 Received: from mobilebill (Kairos.dsa.uqam.ca [132.208.43.57]) by Kairos.dsa.uqam.ca (8.11.4/8.11.4) with ESMTP id i0KM8Y129069 for ; Tue, 20 Jan 2004 17:08:34 -0500 From: "bill" To: Date: Tue, 20 Jan 2004 14:32:45 -0800 Message-ID: <000401c3dfa5$541b77b0$f5d912c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Ipoverib] WG Charter update 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am appending the text for a charter update that includes both the SM MIB and DHCP drafts as working group items. I plan on asking our area directors to approve this at the end of the week (well get the process started) so any feedback before then would be very useful Bill ============== InfiniBand is an emerging standard intended as an interconnect for processor and I/O systems and devices (see the Infiniband Trade Association web site at http://www.infinibandta.org for details). IP is one type of traffic (and a very important one) that could use this interconnect. InfiniBand would benefit greatly from a standardized method of handling IP traffic on IB fabrics. It is also important to be able to manage InfiniBand devices in a common way. This working group has two tasks: - specify the protocols and encapsulations to transport IPv4/v6 over an InfiniBand fabric, and DHCP mappings - specify a set of MIB objects to allow management of the InfiniBand fabric itself. The initial scope of the WG was limited to the use of the basic IB Unreliable Datagram (UD) transport mode for transporting IP over Infiniband. With that work mostly done, the scope has been extended to develop an optional mechanism for transporting IP over other IB transport modes. In particular, there is a desire to transport IP over one or both of IB's connected modes, which enable the use of a much larger MTU than the IB link MTU size. They also provide improved reliability and performance through the use of link level orderly and reliable delivery, and IB's automatic path migration (APM) feature. However, care must be taken to ensure that use of an IB reliable transport does not unduly interfere with the retransmission and congestion control mechanisms used by higher layers (e.g., TCP and SCTP). Other more advanced functionalities such as mapping IP QOS into IB-specific capabilities remain out of scope of the WG charter. Work items 1. Specify standards track procedures for transporting IP over IB. This includes: - supporting ARP/ND packets in order to map IP addresses into IB link-layer addresses. - define encapsulations for carrying ARP, IPv4 and IPv6 packets over IB - Define how to transport IP multicast over IB. - Define how DHCP will work over Infiniband 2. Specify a standards track channel adapter MIB that allows management of an InfiniBand channel adapter. There will require that InfiniBand types be added to the ifType defined by IANA 3. Specify a standards track baseboard management MIB that will allow management of specified device properties 4. Specify sample counter MIBs to allow InfiniBand sample counters to be exposed to external SNMP management applications 5. Specify a Subnet Manager MIB to allow management of the Infiniband Subnet manager 6. Specify an optional, standards track encapsulation for carrying IPv4 and IPv6 packets over either IB unreliable connections or reliable connections. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From exim@www1.ietf.org Wed Jan 21 16:29:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09693 for ; Wed, 21 Jan 2004 16:29:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPtp-0005rm-BA for ipoverib-archive@odin.ietf.org; Wed, 21 Jan 2004 16:28:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LLSXiB022546 for ipoverib-archive@odin.ietf.org; Wed, 21 Jan 2004 16:28:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPtp-0005rZ-7r for ipoverib-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:28:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09606 for ; Wed, 21 Jan 2004 16:28:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPtb-0002Q1-00 for ipoverib-web-archive@ietf.org; Wed, 21 Jan 2004 16:28:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPsf-0002O2-00 for ipoverib-web-archive@ietf.org; Wed, 21 Jan 2004 16:27:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPsL-0002Mc-00 for ipoverib-web-archive@ietf.org; Wed, 21 Jan 2004 16:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPsL-0005JZ-A1; Wed, 21 Jan 2004 16:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPrg-0005I9-3J for ipoverib@optimus.ietf.org; Wed, 21 Jan 2004 16:26:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09436; Wed, 21 Jan 2004 16:26:17 -0500 (EST) Message-Id: <200401212126.QAA09436@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: Wed, 21 Jan 2004 16:26:16 -0500 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ip-over-infiniband-06.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Transmission of IP over InfiniBand Author(s) : V. Kashyap Filename : draft-ietf-ipoib-ip-over-infiniband-06.txt Pages : 19 Date : 2004-1-21 This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link layer address to be used when resolving the IP addresses in 'IP over InfiniBand (IPoIB)' subnets. The document also describes the mapping from IP multicast addresse to InfiniBand multicast addresses. Additionally this document defines the setup and configuration of IPoIB links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband-06.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-06.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-06.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: <2004-1-21164147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ip-over-infiniband-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ip-over-infiniband-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-21164147.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From exim@www1.ietf.org Wed Jan 21 19:56:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19937 for ; Wed, 21 Jan 2004 19:56:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjT8B-0005Iv-Dk for ipoverib-archive@odin.ietf.org; Wed, 21 Jan 2004 19:55:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M0tZhT020385 for ipoverib-archive@odin.ietf.org; Wed, 21 Jan 2004 19:55:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjT8B-0005If-7j for ipoverib-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 19:55:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19931 for ; Wed, 21 Jan 2004 19:55:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjT89-00065K-00 for ipoverib-web-archive@ietf.org; Wed, 21 Jan 2004 19:55:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjT7A-00062d-00 for ipoverib-web-archive@ietf.org; Wed, 21 Jan 2004 19:54:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjT6j-00060I-00 for ipoverib-web-archive@ietf.org; Wed, 21 Jan 2004 19:54:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjT6f-0005CR-51; Wed, 21 Jan 2004 19:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjT68-0005BO-MM for ipoverib@optimus.ietf.org; Wed, 21 Jan 2004 19:53:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19834 for ; Wed, 21 Jan 2004 19:53:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjT66-0005yt-00 for ipoverib@ietf.org; Wed, 21 Jan 2004 19:53:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjT59-0005wD-00 for ipoverib@ietf.org; Wed, 21 Jan 2004 19:52:28 -0500 Received: from kairos.dsa.uqam.ca ([132.208.43.57]) by ietf-mx with esmtp (Exim 4.12) id 1AjT4G-0005sT-00 for ipoverib@ietf.org; Wed, 21 Jan 2004 19:51:32 -0500 Received: from mobilebill (Kairos.dsa.uqam.ca [132.208.43.57]) by Kairos.dsa.uqam.ca (8.11.4/8.11.4) with ESMTP id i0M0Qe102175 for ; Wed, 21 Jan 2004 19:26:40 -0500 From: "bill" To: Subject: FW: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ip-over-infiniband-06.txt - Last call timeout 30 Jan 2004 Date: Wed, 21 Jan 2004 16:50:51 -0800 Message-ID: <000e01c3e081$c9792a70$f5d912c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thank you for getting this out quickly Vivek. Since this is a small delta from the previous last call the timer is set to expire next Friday (30 Jan 2004). If there are no more comments prior to this time - I will forward it on to our area directors for consideration I would also appreciate mail from people saying - Looks great as well to help fill out the paperwork that needs to go with the submission to the IESG Bill -----Original Message----- From: ipoverib-admin@ietf.org [mailto:ipoverib-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, January 21, 2004 1:26 PM To: IETF-Announce: Cc: ipoverib@ietf.org Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ip-over-infiniband-06.txt 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 : Transmission of IP over InfiniBand Author(s) : V. Kashyap Filename : draft-ietf-ipoib-ip-over-infiniband-06.txt Pages : 19 Date : 2004-1-21 This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link layer address to be used when resolving the IP addresses in 'IP over InfiniBand (IPoIB)' subnets. The document also describes the mapping from IP multicast addresse to InfiniBand multicast addresses. Additionally this document defines the setup and configuration of IPoIB links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband- 06.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-06.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-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From exim@www1.ietf.org Fri Jan 23 14:56:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18588 for ; Fri, 23 Jan 2004 14:56:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7PD-0006Yc-Ce for ipoverib-archive@odin.ietf.org; Fri, 23 Jan 2004 14:55:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NJtpeh025205 for ipoverib-archive@odin.ietf.org; Fri, 23 Jan 2004 14:55:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7PD-0006YS-8u for ipoverib-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 14:55:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18535 for ; Fri, 23 Jan 2004 14:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak7PA-0001MR-00 for ipoverib-web-archive@ietf.org; Fri, 23 Jan 2004 14:55:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak7OF-0001JG-00 for ipoverib-web-archive@ietf.org; Fri, 23 Jan 2004 14:54:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak7NP-0001Hh-00 for ipoverib-web-archive@ietf.org; Fri, 23 Jan 2004 14:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7NQ-0006Qq-HF; Fri, 23 Jan 2004 14:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7NH-0006Qb-0I for ipoverib@optimus.ietf.org; Fri, 23 Jan 2004 14:53:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18486 for ; Fri, 23 Jan 2004 14:53:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak7NE-0001Gf-00 for ipoverib@ietf.org; Fri, 23 Jan 2004 14:53:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak7MH-0001G3-00 for ipoverib@ietf.org; Fri, 23 Jan 2004 14:52:50 -0500 Received: from kairos.dsa.uqam.ca ([132.208.43.57]) by ietf-mx with esmtp (Exim 4.12) id 1Ak7LV-0001Ep-00 for ipoverib@ietf.org; Fri, 23 Jan 2004 14:52:01 -0500 Received: from mobilebill (Kairos.dsa.uqam.ca [132.208.43.57]) by Kairos.dsa.uqam.ca (8.11.4/8.11.4) with ESMTP id i0NJR5111168; Fri, 23 Jan 2004 14:27:05 -0500 From: "bill" To: Cc: "'Margaret Wasserman'" , "'Thomas Narten'" Subject: RE: [Ipoverib] WG Charter update Date: Fri, 23 Jan 2004 11:51:21 -0800 Message-ID: <001001c3e1ea$48eb8fa0$6501a8c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <000401c3dfa5$541b77b0$f5d912c0@mobilebill> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here is the updated IPoIB charter that includes the DHCP and SM MIB drafts. I am also attaching an updated list of milestones (the ones listed as DONE on the website are still done - so not updated) Feb 04 Submit ARP/IP/Multicast encapsulation drafts for IESG Last Call Mar 04 Submit Infiniband-Like MIB for IESG Last Call Mar 04 Submit Channel Adapter MIB for IESG Last Call Mar 04 Submit Subnet Management Agent MIB for IESG Last Call Jun 04 Submit DHCP draft for IESG Last Call Jun 04 Submit initial Internet-Draft of Advanced Encapsulation over Connected Transports Nov 04 Subnet Subnet Manager MIB for IESG Last Call Mar 05 Submit initial Internet-Draft of Sample Counter MIB Bill -----Original Message----- From: ipoverib-admin@ietf.org [mailto:ipoverib-admin@ietf.org] On Behalf Of bill Sent: Tuesday, January 20, 2004 2:33 PM To: ipoverib@ietf.org Subject: [Ipoverib] WG Charter update I am appending the text for a charter update that includes both the SM MIB and DHCP drafts as working group items. I plan on asking our area directors to approve this at the end of the week (well get the process started) so any feedback before then would be very useful Bill ============== InfiniBand is an emerging standard intended as an interconnect for processor and I/O systems and devices (see the Infiniband Trade Association web site at http://www.infinibandta.org for details). IP is one type of traffic (and a very important one) that could use this interconnect. InfiniBand would benefit greatly from a standardized method of handling IP traffic on IB fabrics. It is also important to be able to manage InfiniBand devices in a common way. This working group has two tasks: - specify the protocols and encapsulations to transport IPv4/v6 over an InfiniBand fabric, and DHCP mappings - specify a set of MIB objects to allow management of the InfiniBand fabric itself. The initial scope of the WG was limited to the use of the basic IB Unreliable Datagram (UD) transport mode for transporting IP over Infiniband. With that work mostly done, the scope has been extended to develop an optional mechanism for transporting IP over other IB transport modes. In particular, there is a desire to transport IP over one or both of IB's connected modes, which enable the use of a much larger MTU than the IB link MTU size. They also provide improved reliability and performance through the use of link level orderly and reliable delivery, and IB's automatic path migration (APM) feature. However, care must be taken to ensure that use of an IB reliable transport does not unduly interfere with the retransmission and congestion control mechanisms used by higher layers (e.g., TCP and SCTP). Other more advanced functionalities such as mapping IP QOS into IB-specific capabilities remain out of scope of the WG charter. Work items 1. Specify standards track procedures for transporting IP over IB. This includes: - supporting ARP/ND packets in order to map IP addresses into IB link-layer addresses. - define encapsulations for carrying ARP, IPv4 and IPv6 packets over IB - Define how to transport IP multicast over IB. - Define how DHCP will work over Infiniband 2. Specify a standards track channel adapter MIB that allows management of an InfiniBand channel adapter. There will require that InfiniBand types be added to the ifType defined by IANA 3. Specify a standards track baseboard management MIB that will allow management of specified device properties 4. Specify sample counter MIBs to allow InfiniBand sample counters to be exposed to external SNMP management applications 5. Specify a Subnet Manager MIB to allow management of the Infiniband Subnet manager 6. Specify an optional, standards track encapsulation for carrying IPv4 and IPv6 packets over either IB unreliable connections or reliable connections. _______________________________________________ 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 exim@www1.ietf.org Sat Jan 31 21:58:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19747 for ; Sat, 31 Jan 2004 21:58:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7np-0000K2-O4 for ipoverib-archive@odin.ietf.org; Sat, 31 Jan 2004 21:57:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i112vfsq001229 for ipoverib-archive@odin.ietf.org; Sat, 31 Jan 2004 21:57:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7np-0000Jd-Hh for ipoverib-web-archive@optimus.ietf.org; Sat, 31 Jan 2004 21:57:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19732 for ; Sat, 31 Jan 2004 21:57:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An7nm-000067-00 for ipoverib-web-archive@ietf.org; Sat, 31 Jan 2004 21:57:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An7mn-0007m5-00 for ipoverib-web-archive@ietf.org; Sat, 31 Jan 2004 21:56:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1An7mB-0007eW-00 for ipoverib-web-archive@ietf.org; Sat, 31 Jan 2004 21:55:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7mD-0000FT-2f; Sat, 31 Jan 2004 21:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7lc-0000DV-Rb for ipoverib@optimus.ietf.org; Sat, 31 Jan 2004 21:55:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19630 for ; Sat, 31 Jan 2004 21:55:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An7lZ-0007cU-00 for ipoverib@ietf.org; Sat, 31 Jan 2004 21:55:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An7kc-0007XJ-00 for ipoverib@ietf.org; Sat, 31 Jan 2004 21:54:22 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1An7jq-0007Sd-00 for ipoverib@ietf.org; Sat, 31 Jan 2004 21:53:34 -0500 Received: from phys-bos-1.sfbay.sun.com ([129.146.14.23]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i112rZi5024784 for ; Sat, 31 Jan 2004 19:53:35 -0700 (MST) Received: from sun.com (vpn-129-150-16-209.SFBay.Sun.COM [129.150.16.209]) by bos-mail1.sfbay.sun.com (Sun ONE Messaging Server 6.0 (built Sep 24 2003)) with ESMTP id <0HSD00MQFXD7IX00@bos-mail1.sfbay.sun.com> for ipoverib@ietf.org; Sat, 31 Jan 2004 18:53:34 -0800 (PST) Date: Sat, 31 Jan 2004 18:53:23 -0800 From: Bill Strahm To: ipoverib@ietf.org Reply-to: Bill.Strahm@Sun.COM Message-id: <401C6A23.1080805@sun.com> Organization: VSP - HEES - SINS MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Content-Transfer-Encoding: 7bit Subject: [Ipoverib] Last call on Encapsulation draft - Extended to 4 Feb 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Members, I have had port 25 blocked to my personal e-mail account - and so haven't had access to e-mail all week. Needless to say it would be unfair of me to declare last call over when I couldn't get any objections sent personally to me. In that vein - if you have sent any last call issues - please resend them to me by COB on Wed (5 PM PST) and I will end last call at that time. Bill _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib