From pim-admin@ietf.org Thu Jan 1 23:49:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02946 for ; Thu, 1 Jan 2004 23:49:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHF6-0005hE-Qv; Thu, 01 Jan 2004 23:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHEV-0005gs-DO for pim@optimus.ietf.org; Thu, 01 Jan 2004 23:48:23 -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 XAA02936 for ; Thu, 1 Jan 2004 23:48:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHEQ-0001iO-00 for pim@ietf.org; Thu, 01 Jan 2004 23:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcHCP-0001f3-00 for pim@ietf.org; Thu, 01 Jan 2004 23:46:16 -0500 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1AcHBt-0001bk-00 for pim@ietf.org; Thu, 01 Jan 2004 23:45:41 -0500 Received: from huawei.com (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HQU007P4IL9BW@mta2.huawei.com> for pim@ietf.org; Fri, 02 Jan 2004 12:46:22 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HQU008N0IL834@mta2.huawei.com> for pim@ietf.org; Fri, 02 Jan 2004 12:46:21 +0800 (CST) Received: from DELL15 ([10.18.4.57]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HQUIQ401.508; Fri, 02 Jan 2004 12:49:16 +0800 Date: Fri, 02 Jan 2004 10:22:24 +0530 From: Prashant Jhingran Subject: RE: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-00.txt] To: "'Dino Farinacci'" Cc: pim@catarina.usc.edu, ycai@cisco.com, pusateri@juniper.net, lwei@redback.com Reply-to: prashantj@huawei.com Message-id: <000d01c3d0ec$36c2a110$3904120a@DELL15> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Dino, I shall try to explain my second point, kindly refer to the diagram on page 2 of the draft. Consider a case where SDR for a particular source S1 (e.g. S1, G) is also the anycast RP for the same group G (e.g. RP1 is the RP for group G besides being SDR for S1, G) or in simple words source S1 (S1, G) and RP for the group G are directly attached. In this case since there won't be any Register phase between source (S1) and the RP (RP1) therefore the RP/SDR (i.e. RP1) has to "explicitly form" a Register message with the required parameters as specified in the draft and then forward the same to all the configured anycast RP's (viz. RP2 and RP3). However in normal circumstances the following holds good: "RP1 is configured with RP2 and RP3's IP address. It will forward the Register message from S1's DR to both of them. RP1 will include it's own IP address as the source address for the PIM Register message." I would suggest you to include this particular scenario in the draft. Let me know in case of any ambiguity. Kind regards, Prashant Jhingran -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Dino Farinacci Sent: Thursday, January 01, 2004 5:25 AM To: prashantj@huawei.com Cc: pim@catarina.usc.edu; ycai@cisco.com; pusateri@juniper.net; lwei@redback.com Subject: Re: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-00.txt] >> 1. Anycast RP address (e.g. RPA) should be different from the addresses of >> the routers (e.g. RT1, RT2 and RT3) so that anycast RP's can uniquely >> identify each other and therefore can send the Register messages to all the >> configured anycast RP's for the particular group. Sure, I will add this. >> 2. Elaborate the scenario when SDR for a particular group is also the >> anycast RP for the same group. >> This may remove all the dependencies from the [2] and therefore reader may >> be able to understand without reading [2]. I don't understand your comment. Could you elaboarate a bit more? Thanks for the comments Prashant. Dino _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Thu Jan 1 23:50:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03018 for ; Thu, 1 Jan 2004 23:50:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHG7-0005kh-7V; Thu, 01 Jan 2004 23:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHFu-0005iO-JL for pim@optimus.ietf.org; Thu, 01 Jan 2004 23:49:54 -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 XAA02965 for ; Thu, 1 Jan 2004 23:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHFs-0001kq-00 for pim@ietf.org; Thu, 01 Jan 2004 23:49:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcHDw-0001gi-00 for pim@ietf.org; Thu, 01 Jan 2004 23:47:51 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHC5-0001br-00 for pim@ietf.org; Thu, 01 Jan 2004 23:45:53 -0500 Received: from huawei.com (mta2.huawei.com [61.144.161.24]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i024jKJK086536 for ; Thu, 1 Jan 2004 20:45:23 -0800 (PST) (envelope-from prashantj@huawei.com) Received: from huawei.com (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HQU007OWIL9BW@mta2.huawei.com> for pim@catarina.usc.edu; Fri, 02 Jan 2004 12:46:22 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HQU008MUIL834@mta2.huawei.com> for pim@catarina.usc.edu; Fri, 02 Jan 2004 12:46:21 +0800 (CST) Received: from DELL15 ([10.18.4.57]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HQUIQ401.508; Fri, 02 Jan 2004 12:49:16 +0800 Date: Fri, 02 Jan 2004 10:22:24 +0530 From: Prashant Jhingran Subject: RE: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-00.txt] To: "'Dino Farinacci'" Cc: pim@catarina.usc.edu, ycai@cisco.com, pusateri@juniper.net, lwei@redback.com Reply-to: prashantj@huawei.com Message-id: <000d01c3d0ec$36c2a110$3904120a@DELL15> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Dino, I shall try to explain my second point, kindly refer to the diagram on page 2 of the draft. Consider a case where SDR for a particular source S1 (e.g. S1, G) is also the anycast RP for the same group G (e.g. RP1 is the RP for group G besides being SDR for S1, G) or in simple words source S1 (S1, G) and RP for the group G are directly attached. In this case since there won't be any Register phase between source (S1) and the RP (RP1) therefore the RP/SDR (i.e. RP1) has to "explicitly form" a Register message with the required parameters as specified in the draft and then forward the same to all the configured anycast RP's (viz. RP2 and RP3). However in normal circumstances the following holds good: "RP1 is configured with RP2 and RP3's IP address. It will forward the Register message from S1's DR to both of them. RP1 will include it's own IP address as the source address for the PIM Register message." I would suggest you to include this particular scenario in the draft. Let me know in case of any ambiguity. Kind regards, Prashant Jhingran -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Dino Farinacci Sent: Thursday, January 01, 2004 5:25 AM To: prashantj@huawei.com Cc: pim@catarina.usc.edu; ycai@cisco.com; pusateri@juniper.net; lwei@redback.com Subject: Re: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-00.txt] >> 1. Anycast RP address (e.g. RPA) should be different from the addresses of >> the routers (e.g. RT1, RT2 and RT3) so that anycast RP's can uniquely >> identify each other and therefore can send the Register messages to all the >> configured anycast RP's for the particular group. Sure, I will add this. >> 2. Elaborate the scenario when SDR for a particular group is also the >> anycast RP for the same group. >> This may remove all the dependencies from the [2] and therefore reader may >> be able to understand without reading [2]. I don't understand your comment. Could you elaboarate a bit more? Thanks for the comments Prashant. Dino _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Thu Jan 1 23:52:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03076 for ; Thu, 1 Jan 2004 23:52:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHIP-0005uV-Ld for pim-archive@odin.ietf.org; Thu, 01 Jan 2004 23:52:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i024qPRx022713 for pim-archive@odin.ietf.org; Thu, 1 Jan 2004 23:52:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHIP-0005uG-Ff for pim-web-archive@optimus.ietf.org; Thu, 01 Jan 2004 23:52:25 -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 XAA03067 for ; Thu, 1 Jan 2004 23:52:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHIN-0001sE-00 for pim-web-archive@ietf.org; Thu, 01 Jan 2004 23:52:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcHGO-0001nN-00 for pim-web-archive@ietf.org; Thu, 01 Jan 2004 23:50:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcHFG-0001jo-00 for pim-web-archive@ietf.org; Thu, 01 Jan 2004 23:49:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHF6-0005hE-Qv; Thu, 01 Jan 2004 23:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHEV-0005gs-DO for pim@optimus.ietf.org; Thu, 01 Jan 2004 23:48:23 -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 XAA02936 for ; Thu, 1 Jan 2004 23:48:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHEQ-0001iO-00 for pim@ietf.org; Thu, 01 Jan 2004 23:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcHCP-0001f3-00 for pim@ietf.org; Thu, 01 Jan 2004 23:46:16 -0500 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1AcHBt-0001bk-00 for pim@ietf.org; Thu, 01 Jan 2004 23:45:41 -0500 Received: from huawei.com (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HQU007P4IL9BW@mta2.huawei.com> for pim@ietf.org; Fri, 02 Jan 2004 12:46:22 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HQU008N0IL834@mta2.huawei.com> for pim@ietf.org; Fri, 02 Jan 2004 12:46:21 +0800 (CST) Received: from DELL15 ([10.18.4.57]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HQUIQ401.508; Fri, 02 Jan 2004 12:49:16 +0800 Date: Fri, 02 Jan 2004 10:22:24 +0530 From: Prashant Jhingran Subject: RE: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-00.txt] To: "'Dino Farinacci'" Cc: pim@catarina.usc.edu, ycai@cisco.com, pusateri@juniper.net, lwei@redback.com Reply-to: prashantj@huawei.com Message-id: <000d01c3d0ec$36c2a110$3904120a@DELL15> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Dino, I shall try to explain my second point, kindly refer to the diagram on page 2 of the draft. Consider a case where SDR for a particular source S1 (e.g. S1, G) is also the anycast RP for the same group G (e.g. RP1 is the RP for group G besides being SDR for S1, G) or in simple words source S1 (S1, G) and RP for the group G are directly attached. In this case since there won't be any Register phase between source (S1) and the RP (RP1) therefore the RP/SDR (i.e. RP1) has to "explicitly form" a Register message with the required parameters as specified in the draft and then forward the same to all the configured anycast RP's (viz. RP2 and RP3). However in normal circumstances the following holds good: "RP1 is configured with RP2 and RP3's IP address. It will forward the Register message from S1's DR to both of them. RP1 will include it's own IP address as the source address for the PIM Register message." I would suggest you to include this particular scenario in the draft. Let me know in case of any ambiguity. Kind regards, Prashant Jhingran -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Dino Farinacci Sent: Thursday, January 01, 2004 5:25 AM To: prashantj@huawei.com Cc: pim@catarina.usc.edu; ycai@cisco.com; pusateri@juniper.net; lwei@redback.com Subject: Re: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-00.txt] >> 1. Anycast RP address (e.g. RPA) should be different from the addresses of >> the routers (e.g. RT1, RT2 and RT3) so that anycast RP's can uniquely >> identify each other and therefore can send the Register messages to all the >> configured anycast RP's for the particular group. Sure, I will add this. >> 2. Elaborate the scenario when SDR for a particular group is also the >> anycast RP for the same group. >> This may remove all the dependencies from the [2] and therefore reader may >> be able to understand without reading [2]. I don't understand your comment. Could you elaboarate a bit more? Thanks for the comments Prashant. Dino _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Thu Jan 1 23:54:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03183 for ; Thu, 1 Jan 2004 23:54:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHJo-0005vO-1V for pim-archive@odin.ietf.org; Thu, 01 Jan 2004 23:53:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i024rqJ9022768 for pim-archive@odin.ietf.org; Thu, 1 Jan 2004 23:53:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHJn-0005v9-SK for pim-web-archive@optimus.ietf.org; Thu, 01 Jan 2004 23: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 XAA03118 for ; Thu, 1 Jan 2004 23:53:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHJl-0001xP-00 for pim-web-archive@ietf.org; Thu, 01 Jan 2004 23:53:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcHHz-0001qe-00 for pim-web-archive@ietf.org; Thu, 01 Jan 2004 23:52:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcHG8-0001mD-00 for pim-web-archive@ietf.org; Thu, 01 Jan 2004 23:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHG7-0005kh-7V; Thu, 01 Jan 2004 23:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcHFu-0005iO-JL for pim@optimus.ietf.org; Thu, 01 Jan 2004 23:49:54 -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 XAA02965 for ; Thu, 1 Jan 2004 23:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHFs-0001kq-00 for pim@ietf.org; Thu, 01 Jan 2004 23:49:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcHDw-0001gi-00 for pim@ietf.org; Thu, 01 Jan 2004 23:47:51 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcHC5-0001br-00 for pim@ietf.org; Thu, 01 Jan 2004 23:45:53 -0500 Received: from huawei.com (mta2.huawei.com [61.144.161.24]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i024jKJK086536 for ; Thu, 1 Jan 2004 20:45:23 -0800 (PST) (envelope-from prashantj@huawei.com) Received: from huawei.com (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HQU007OWIL9BW@mta2.huawei.com> for pim@catarina.usc.edu; Fri, 02 Jan 2004 12:46:22 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HQU008MUIL834@mta2.huawei.com> for pim@catarina.usc.edu; Fri, 02 Jan 2004 12:46:21 +0800 (CST) Received: from DELL15 ([10.18.4.57]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HQUIQ401.508; Fri, 02 Jan 2004 12:49:16 +0800 Date: Fri, 02 Jan 2004 10:22:24 +0530 From: Prashant Jhingran Subject: RE: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-00.txt] To: "'Dino Farinacci'" Cc: pim@catarina.usc.edu, ycai@cisco.com, pusateri@juniper.net, lwei@redback.com Reply-to: prashantj@huawei.com Message-id: <000d01c3d0ec$36c2a110$3904120a@DELL15> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Dino, I shall try to explain my second point, kindly refer to the diagram on page 2 of the draft. Consider a case where SDR for a particular source S1 (e.g. S1, G) is also the anycast RP for the same group G (e.g. RP1 is the RP for group G besides being SDR for S1, G) or in simple words source S1 (S1, G) and RP for the group G are directly attached. In this case since there won't be any Register phase between source (S1) and the RP (RP1) therefore the RP/SDR (i.e. RP1) has to "explicitly form" a Register message with the required parameters as specified in the draft and then forward the same to all the configured anycast RP's (viz. RP2 and RP3). However in normal circumstances the following holds good: "RP1 is configured with RP2 and RP3's IP address. It will forward the Register message from S1's DR to both of them. RP1 will include it's own IP address as the source address for the PIM Register message." I would suggest you to include this particular scenario in the draft. Let me know in case of any ambiguity. Kind regards, Prashant Jhingran -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Dino Farinacci Sent: Thursday, January 01, 2004 5:25 AM To: prashantj@huawei.com Cc: pim@catarina.usc.edu; ycai@cisco.com; pusateri@juniper.net; lwei@redback.com Subject: Re: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-00.txt] >> 1. Anycast RP address (e.g. RPA) should be different from the addresses of >> the routers (e.g. RT1, RT2 and RT3) so that anycast RP's can uniquely >> identify each other and therefore can send the Register messages to all the >> configured anycast RP's for the particular group. Sure, I will add this. >> 2. Elaborate the scenario when SDR for a particular group is also the >> anycast RP for the same group. >> This may remove all the dependencies from the [2] and therefore reader may >> be able to understand without reading [2]. I don't understand your comment. Could you elaboarate a bit more? Thanks for the comments Prashant. Dino _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Sat Jan 3 12:43:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07370 for ; Sat, 3 Jan 2004 12:43:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acpng-0001Xi-NO; Sat, 03 Jan 2004 12:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acpn9-0001WG-S5 for pim@optimus.ietf.org; Sat, 03 Jan 2004 12:42: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 MAA07321 for ; Sat, 3 Jan 2004 12:42:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acpn8-0000ev-00 for pim@ietf.org; Sat, 03 Jan 2004 12:42:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcplB-0000YN-00 for pim@ietf.org; Sat, 03 Jan 2004 12:40:26 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acpiy-0000R7-00 for pim@ietf.org; Sat, 03 Jan 2004 12:38:39 -0500 Received: from dmz2.procket.com (dmz2.procket.com [65.174.124.37]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i03HbbJK095281 for ; Sat, 3 Jan 2004 09:37:37 -0800 (PST) (envelope-from dino@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i03JhDOt045570; Sat, 3 Jan 2004 11:43:14 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i03HbPYB018720; Sat, 3 Jan 2004 09:37:25 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i03HbPTN025920; Sat, 3 Jan 2004 09:37:25 -0800 Date: Sat, 3 Jan 2004 09:37:25 -0800 Message-Id: <200401031737.i03HbPTN025920@dino-pc.procket.com> From: Dino Farinacci To: prashantj@huawei.com CC: pim@catarina.usc.edu, ycai@cisco.com, pusateri@juniper.net, lwei@redback.com In-reply-to: <000d01c3d0ec$36c2a110$3904120a@DELL15> (message from Prashant Jhingran on Fri, 02 Jan 2004 10:22:24 +0530) Subject: Re: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-00.txt] References: <000d01c3d0ec$36c2a110$3904120a@DELL15> 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , >> In this case since there won't be any Register phase between source (S1) and >> the RP (RP1) therefore the RP/SDR (i.e. RP1) has to "explicitly form" a >> Register message with the required parameters as specified in the draft and >> then forward the same to all the configured anycast RP's (viz. RP2 and RP3). This is explained in various PIM drafts. Either provision in the implementation must be made to deal with this case, or you generalize the mechanism to internally build a Register message and send it to yourself (so reecived Register processing is the same for any directly connected source -- even when it is yourself). >> I would suggest you to include this particular scenario in the draft. However, this scenario is "when to send Registers" as a functioning DR. The PIM draft really has the details to this. The Anycast-PIM draft specifies when and how Registers are *forwarded*. >> Let me know in case of any ambiguity. It is clear now. Thanks. Dino _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Sat Jan 3 12:47:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07512 for ; Sat, 3 Jan 2004 12:47:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcprC-0001e9-Ex for pim-archive@odin.ietf.org; Sat, 03 Jan 2004 12:46:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i03HkcKD006325 for pim-archive@odin.ietf.org; Sat, 3 Jan 2004 12:46:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcprC-0001dw-8j for pim-web-archive@optimus.ietf.org; Sat, 03 Jan 2004 12:46:38 -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 MAA07476 for ; Sat, 3 Jan 2004 12:46:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcprA-0000vm-00 for pim-web-archive@ietf.org; Sat, 03 Jan 2004 12:46:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcppJ-0000ok-00 for pim-web-archive@ietf.org; Sat, 03 Jan 2004 12:44:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Acpnx-0000ic-00 for pim-web-archive@ietf.org; Sat, 03 Jan 2004 12:43:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acpng-0001Xi-NO; Sat, 03 Jan 2004 12:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acpn9-0001WG-S5 for pim@optimus.ietf.org; Sat, 03 Jan 2004 12:42: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 MAA07321 for ; Sat, 3 Jan 2004 12:42:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acpn8-0000ev-00 for pim@ietf.org; Sat, 03 Jan 2004 12:42:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcplB-0000YN-00 for pim@ietf.org; Sat, 03 Jan 2004 12:40:26 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acpiy-0000R7-00 for pim@ietf.org; Sat, 03 Jan 2004 12:38:39 -0500 Received: from dmz2.procket.com (dmz2.procket.com [65.174.124.37]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i03HbbJK095281 for ; Sat, 3 Jan 2004 09:37:37 -0800 (PST) (envelope-from dino@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i03JhDOt045570; Sat, 3 Jan 2004 11:43:14 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i03HbPYB018720; Sat, 3 Jan 2004 09:37:25 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i03HbPTN025920; Sat, 3 Jan 2004 09:37:25 -0800 Date: Sat, 3 Jan 2004 09:37:25 -0800 Message-Id: <200401031737.i03HbPTN025920@dino-pc.procket.com> From: Dino Farinacci To: prashantj@huawei.com CC: pim@catarina.usc.edu, ycai@cisco.com, pusateri@juniper.net, lwei@redback.com In-reply-to: <000d01c3d0ec$36c2a110$3904120a@DELL15> (message from Prashant Jhingran on Fri, 02 Jan 2004 10:22:24 +0530) Subject: Re: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-00.txt] References: <000d01c3d0ec$36c2a110$3904120a@DELL15> Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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 >> In this case since there won't be any Register phase between source (S1) and >> the RP (RP1) therefore the RP/SDR (i.e. RP1) has to "explicitly form" a >> Register message with the required parameters as specified in the draft and >> then forward the same to all the configured anycast RP's (viz. RP2 and RP3). This is explained in various PIM drafts. Either provision in the implementation must be made to deal with this case, or you generalize the mechanism to internally build a Register message and send it to yourself (so reecived Register processing is the same for any directly connected source -- even when it is yourself). >> I would suggest you to include this particular scenario in the draft. However, this scenario is "when to send Registers" as a functioning DR. The PIM draft really has the details to this. The Anycast-PIM draft specifies when and how Registers are *forwarded*. >> Let me know in case of any ambiguity. It is clear now. Thanks. Dino _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From mailman-admin@ietf.org Fri Jan 9 12:53:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18284 for ; Fri, 9 Jan 2004 12:53:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0p5-0003A5-M2 for pim-archive@lists.ietf.org; Fri, 09 Jan 2004 12:53:27 -0500 Date: Fri, 09 Jan 2004 12:53:27 -0500 Message-ID: <20040109175327.9164.45181.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: pim-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, pim-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for pim-archive@lists.ietf.org: List Password // URL ---- -------- pim@ietf.org urahne https://www1.ietf.org/mailman/options/pim/pim-archive%40lists.ietf.org From pim-admin@ietf.org Fri Jan 23 10:43:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06118 for ; Fri, 23 Jan 2004 10:43:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3RZ-0002DD-CL; Fri, 23 Jan 2004 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3RF-0002CX-J2 for pim@optimus.ietf.org; Fri, 23 Jan 2004 10:41: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 KAA06076 for ; Fri, 23 Jan 2004 10:41:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3RD-0003QC-00 for pim@ietf.org; Fri, 23 Jan 2004 10:41:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3QK-0003Pk-00 for pim@ietf.org; Fri, 23 Jan 2004 10:40:44 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Q8-0003Ov-00 for pim@ietf.org; Fri, 23 Jan 2004 10:40:33 -0500 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jan 2004 15:39:59 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803580EEA@baker.datcon.co.uk> From: James Lingard To: "'pim@ietf.org'" Date: Fri, 23 Jan 2004 15:39:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" 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 Subject: [pim] Error in PIM-SM forwarding rules Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Hi, I am new to PIM and have recently been studying the PIM-SM draft. I believe that there may be an error in the forwarding rules in the current draft (draft-ietf-pim-sm-v2-new-08.txt, Section 4.2), which could cause a router with only (*,G) forwarding state to incorrectly stop forwarding traffic from a particular source. The problem is with the clause 'if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined )' Why is the second test 'UpstreamJPState(S,G) == Joined' and not 'SPTbit(S,G) == TRUE'? It appears that as they stand the rules would cause a router with only (*,G) forwarding state to stop forwarding traffic from S if SPTbit(S,G) were set to TRUE. This may happen in the following scenario. Suppose that all of the following are true. - RPF_interface(RP(G)) == RPF_interface(S) - JoinDesired(*,G) == TRUE - JoinDesired(S,G) == FALSE - (S,G) Assert state-machine is in NoInfo state If now a Preferred (S,G) Assert is received on RPF_interface(RP(G)), the (S,G) Assert state-machine will switch to the "I Am Assert Loser" state, performing Actions A6 which cause SPTbit(S,G) to be set to TRUE. Once this has happened, any (S,G) traffic received on RPF_interface(RP(G)) will not be forwarded, because neither 'iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined' nor 'iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE' will be true. Moreover, this isn't a transient problem but will continue until either SPTbit(S,G) is reset to FALSE or JoinDesired(S,G) becomes TRUE, which may be some time in the future. Is it intentional that SPTbit(S,G) could be TRUE while JoinDesired(S,G) is FALSE? If this is intentional, then the forwarding rules need to be changed by replacing 'UpstreamJPState(S,G) == Joined' with 'SPTbit(S,G) == TRUE' in the place described above. If this is not intentional, then the rules for setting SPTbit(S,G) in the (S,G) Assert state-machine must be amended so that this situation cannot occur. Please let me know if I'm missing something, or if this genuinely is an error. Thanks, James. --- James Lingard Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: James.Lingard@dataconnection.com Web: http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Jan 23 10:57:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06893 for ; Fri, 23 Jan 2004 10:57:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3gG-0003Mf-B4 for pim-archive@odin.ietf.org; Fri, 23 Jan 2004 10:57:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NFvCNY012932 for pim-archive@odin.ietf.org; Fri, 23 Jan 2004 10:57:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3gG-0003MV-6r for pim-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 10:57:12 -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 KAA06791 for ; Fri, 23 Jan 2004 10:57:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3gD-0004Ml-00 for pim-web-archive@ietf.org; Fri, 23 Jan 2004 10:57:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3eT-00043G-00 for pim-web-archive@ietf.org; Fri, 23 Jan 2004 10:55:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak3d9-0003ow-01 for pim-web-archive@ietf.org; Fri, 23 Jan 2004 10:54: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 1Ak3SC-0007ET-40 for pim-web-archive@ietf.org; Fri, 23 Jan 2004 10:42:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3RZ-0002DD-CL; Fri, 23 Jan 2004 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3RF-0002CX-J2 for pim@optimus.ietf.org; Fri, 23 Jan 2004 10:41: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 KAA06076 for ; Fri, 23 Jan 2004 10:41:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3RD-0003QC-00 for pim@ietf.org; Fri, 23 Jan 2004 10:41:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3QK-0003Pk-00 for pim@ietf.org; Fri, 23 Jan 2004 10:40:44 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Q8-0003Ov-00 for pim@ietf.org; Fri, 23 Jan 2004 10:40:33 -0500 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jan 2004 15:39:59 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803580EEA@baker.datcon.co.uk> From: James Lingard To: "'pim@ietf.org'" Date: Fri, 23 Jan 2004 15:39:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [pim] Error in PIM-SM forwarding rules Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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 Hi, I am new to PIM and have recently been studying the PIM-SM draft. I believe that there may be an error in the forwarding rules in the current draft (draft-ietf-pim-sm-v2-new-08.txt, Section 4.2), which could cause a router with only (*,G) forwarding state to incorrectly stop forwarding traffic from a particular source. The problem is with the clause 'if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined )' Why is the second test 'UpstreamJPState(S,G) == Joined' and not 'SPTbit(S,G) == TRUE'? It appears that as they stand the rules would cause a router with only (*,G) forwarding state to stop forwarding traffic from S if SPTbit(S,G) were set to TRUE. This may happen in the following scenario. Suppose that all of the following are true. - RPF_interface(RP(G)) == RPF_interface(S) - JoinDesired(*,G) == TRUE - JoinDesired(S,G) == FALSE - (S,G) Assert state-machine is in NoInfo state If now a Preferred (S,G) Assert is received on RPF_interface(RP(G)), the (S,G) Assert state-machine will switch to the "I Am Assert Loser" state, performing Actions A6 which cause SPTbit(S,G) to be set to TRUE. Once this has happened, any (S,G) traffic received on RPF_interface(RP(G)) will not be forwarded, because neither 'iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined' nor 'iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE' will be true. Moreover, this isn't a transient problem but will continue until either SPTbit(S,G) is reset to FALSE or JoinDesired(S,G) becomes TRUE, which may be some time in the future. Is it intentional that SPTbit(S,G) could be TRUE while JoinDesired(S,G) is FALSE? If this is intentional, then the forwarding rules need to be changed by replacing 'UpstreamJPState(S,G) == Joined' with 'SPTbit(S,G) == TRUE' in the place described above. If this is not intentional, then the rules for setting SPTbit(S,G) in the (S,G) Assert state-machine must be amended so that this situation cannot occur. Please let me know if I'm missing something, or if this genuinely is an error. Thanks, James. --- James Lingard Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: James.Lingard@dataconnection.com Web: http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Jan 23 12:04:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11469 for ; Fri, 23 Jan 2004 12:04:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4hx-00023s-Qr; Fri, 23 Jan 2004 12:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4hl-00020t-Ve for pim@optimus.ietf.org; Fri, 23 Jan 2004 12:02: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 MAA11418 for ; Fri, 23 Jan 2004 12:02:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4hk-0001us-00 for pim@ietf.org; Fri, 23 Jan 2004 12:02:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4gn-0001sA-00 for pim@ietf.org; Fri, 23 Jan 2004 12:01:50 -0500 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4fv-0001nW-00 for pim@ietf.org; Fri, 23 Jan 2004 12:00:56 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i0NJ94pL020158; Fri, 23 Jan 2004 11:09:04 -0800 (PST) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i0NH0GYB027451; Fri, 23 Jan 2004 09:00:16 -0800 (PST) Received: from [10.1.5.25] ([10.1.5.25]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 09:00:16 -0800 In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F803580EEA@baker.datcon.co.uk> References: <53F74F5A7B94D511841C00B0D0AB16F803580EEA@baker.datcon.co.uk> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9D6F4B32-4DC5-11D8-8EF3-0003936A6062@procket.com> Content-Transfer-Encoding: 7bit Cc: "'pim@ietf.org'" From: John Zwiebel Subject: Re: [pim] Error in PIM-SM forwarding rules Date: Fri, 23 Jan 2004 09:00:15 -0800 To: James Lingard X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 23 Jan 2004 17:00:16.0525 (UTC) FILETIME=[5FECEBD0:01C3E1D2] 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 23, 2004, at 7:39 AM, James Lingard wrote: > > The problem is with the clause > > 'if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined )' > > Why is the second test 'UpstreamJPState(S,G) == Joined' and not > 'SPTbit(S,G) > == TRUE'? It appears that as they stand the rules would cause a > router with > only (*,G) forwarding state to stop forwarding traffic from S if > SPTbit(S,G) > were set to TRUE. If a router has only (*,G) state then this line would be false and you'd fall through to the next elseif which defines how to forward on the shared tree. You can't set the SPT bit until after you've received traffic on the (S,G) because that is when you can decide to start sending the (S,G,R) prunes to stop that traffic from coming down the shared tree. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Jan 23 12:06:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11612 for ; Fri, 23 Jan 2004 12:06: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 1Ak4kc-0002Jn-4E for pim-archive@odin.ietf.org; Fri, 23 Jan 2004 12:05:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NH5kdg008907 for pim-archive@odin.ietf.org; Fri, 23 Jan 2004 12:05:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4kb-0002Ja-Vv for pim-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 12:05:46 -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 MAA11554 for ; Fri, 23 Jan 2004 12:05:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4ka-00024B-00 for pim-web-archive@ietf.org; Fri, 23 Jan 2004 12:05:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4ja-0001zU-00 for pim-web-archive@ietf.org; Fri, 23 Jan 2004 12:04:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak4ic-0001wm-00 for pim-web-archive@ietf.org; Fri, 23 Jan 2004 12:03:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4hx-00023s-Qr; Fri, 23 Jan 2004 12:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4hl-00020t-Ve for pim@optimus.ietf.org; Fri, 23 Jan 2004 12:02: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 MAA11418 for ; Fri, 23 Jan 2004 12:02:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4hk-0001us-00 for pim@ietf.org; Fri, 23 Jan 2004 12:02:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4gn-0001sA-00 for pim@ietf.org; Fri, 23 Jan 2004 12:01:50 -0500 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4fv-0001nW-00 for pim@ietf.org; Fri, 23 Jan 2004 12:00:56 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i0NJ94pL020158; Fri, 23 Jan 2004 11:09:04 -0800 (PST) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i0NH0GYB027451; Fri, 23 Jan 2004 09:00:16 -0800 (PST) Received: from [10.1.5.25] ([10.1.5.25]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 09:00:16 -0800 In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F803580EEA@baker.datcon.co.uk> References: <53F74F5A7B94D511841C00B0D0AB16F803580EEA@baker.datcon.co.uk> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9D6F4B32-4DC5-11D8-8EF3-0003936A6062@procket.com> Content-Transfer-Encoding: 7bit Cc: "'pim@ietf.org'" From: John Zwiebel Subject: Re: [pim] Error in PIM-SM forwarding rules Date: Fri, 23 Jan 2004 09:00:15 -0800 To: James Lingard X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 23 Jan 2004 17:00:16.0525 (UTC) FILETIME=[5FECEBD0:01C3E1D2] Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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 On Jan 23, 2004, at 7:39 AM, James Lingard wrote: > > The problem is with the clause > > 'if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined )' > > Why is the second test 'UpstreamJPState(S,G) == Joined' and not > 'SPTbit(S,G) > == TRUE'? It appears that as they stand the rules would cause a > router with > only (*,G) forwarding state to stop forwarding traffic from S if > SPTbit(S,G) > were set to TRUE. If a router has only (*,G) state then this line would be false and you'd fall through to the next elseif which defines how to forward on the shared tree. You can't set the SPT bit until after you've received traffic on the (S,G) because that is when you can decide to start sending the (S,G,R) prunes to stop that traffic from coming down the shared tree. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Jan 23 12:16:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12047 for ; Fri, 23 Jan 2004 12:16:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4uX-0003aG-Rk; Fri, 23 Jan 2004 12:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4tZ-0003Yr-MI for pim@optimus.ietf.org; Fri, 23 Jan 2004 12:15: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 MAA12008 for ; Fri, 23 Jan 2004 12:14:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4tY-0002c0-00 for pim@ietf.org; Fri, 23 Jan 2004 12:15:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4sc-0002Yq-00 for pim@ietf.org; Fri, 23 Jan 2004 12:14:02 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak4sC-0002VK-00 for pim@ietf.org; Fri, 23 Jan 2004 12:13:36 -0500 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jan 2004 17:13:02 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803580EED@baker.datcon.co.uk> From: James Lingard To: "'Mark Handley'" Cc: "'pim@ietf.org'" Subject: RE: [pim] Error in PIM-SM forwarding rules Date: Fri, 23 Jan 2004 17:12:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Hi Mark, Thanks for the quick response. See comment below. > -----Original Message----- > From: Mark Handley [mailto:M.Handley@cs.ucl.ac.uk] > Sent: 23 January 2004 16:20 > To: James Lingard > Cc: 'pim@ietf.org' > Subject: Re: [pim] Error in PIM-SM forwarding rules > > >Suppose that all of the following are true. > > > >- RPF_interface(RP(G)) == RPF_interface(S) > >- JoinDesired(*,G) == TRUE > >- JoinDesired(S,G) == FALSE > >- (S,G) Assert state-machine is in NoInfo state > > > >If now a Preferred (S,G) Assert is received on > >RPF_interface(RP(G)), the (S,G) Assert state-machine will switch > >to the "I Am Assert Loser" state, performing Actions A6 which > >cause SPTbit(S,G) to be set to TRUE. Once this has happened, > >any (S,G) traffic received on RPF_interface(RP(G)) will not be > >forwarded, because neither... > > The rules for transitioning from "NoInfo" to "I Am Assert > Loser" state are: > > Receive Preferred Assert with RPT bit clear AND > AssertTrackingDesired(S,G,I)==TRUE > We're interested in (S,G) Asserts, either because I is a > downstream interface for which we have (S,G) or (*,G) > forwarding state, or because I is the upstream > interface for S and we have (S,G) forwarding state. The > received assert that has a better metric than our own, so > we do not win the Assert. We transition to "I am Assert > Loser" and perform actions A6. > > Ok, so taking a look at AssertTrackingDesired(S,G,I): > > AssertTrackingDesired(S,G,I) = > (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) > (+) ( pim_include(*,G) (-) pim_exclude(S,G) ) > (-) lost_assert(*,G) > (+) joins(S,G) ) ) > OR (local_receiver_include(S,G,I) == TRUE > AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me))) > OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE)) > OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE) > AND (SPTbit(S,G) == FALSE)) > > The first clause (I in ...) only applies to downstream interfaces, > which isn't the case here. local_receiver_include is false. > JoinDesired(S,G) is false because the keepalivetimer isn't > running. SPTbit(S,G) is false. > > So AssertTrackingDesired will be false. We won't track this assert. > As we won't track the assert, SPTbit won't be set. But AssertTrackingDesired(S,G) _will_ be true, because the final clause '(RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE) AND (SPTbit(S,G) == FALSE)' will be true (as each part is true by assumption). Cheers, James. --- James Lingard Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: James.Lingard@dataconnection.com Web: http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Jan 23 12:18:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12132 for ; Fri, 23 Jan 2004 12:18:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4wD-0003nw-QT for pim-archive@odin.ietf.org; Fri, 23 Jan 2004 12:17:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NHHjfV014618 for pim-archive@odin.ietf.org; Fri, 23 Jan 2004 12:17:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4wD-0003nf-LZ for pim-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 12:17:45 -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 MAA12116 for ; Fri, 23 Jan 2004 12:17:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4wC-0002hq-00 for pim-web-archive@ietf.org; Fri, 23 Jan 2004 12:17:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4vK-0002gW-00 for pim-web-archive@ietf.org; Fri, 23 Jan 2004 12:16:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak4uc-0002et-00 for pim-web-archive@ietf.org; Fri, 23 Jan 2004 12:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4uX-0003aG-Rk; Fri, 23 Jan 2004 12:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4tZ-0003Yr-MI for pim@optimus.ietf.org; Fri, 23 Jan 2004 12:15: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 MAA12008 for ; Fri, 23 Jan 2004 12:14:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4tY-0002c0-00 for pim@ietf.org; Fri, 23 Jan 2004 12:15:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4sc-0002Yq-00 for pim@ietf.org; Fri, 23 Jan 2004 12:14:02 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak4sC-0002VK-00 for pim@ietf.org; Fri, 23 Jan 2004 12:13:36 -0500 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jan 2004 17:13:02 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803580EED@baker.datcon.co.uk> From: James Lingard To: "'Mark Handley'" Cc: "'pim@ietf.org'" Subject: RE: [pim] Error in PIM-SM forwarding rules Date: Fri, 23 Jan 2004 17:12:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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 Hi Mark, Thanks for the quick response. See comment below. > -----Original Message----- > From: Mark Handley [mailto:M.Handley@cs.ucl.ac.uk] > Sent: 23 January 2004 16:20 > To: James Lingard > Cc: 'pim@ietf.org' > Subject: Re: [pim] Error in PIM-SM forwarding rules > > >Suppose that all of the following are true. > > > >- RPF_interface(RP(G)) == RPF_interface(S) > >- JoinDesired(*,G) == TRUE > >- JoinDesired(S,G) == FALSE > >- (S,G) Assert state-machine is in NoInfo state > > > >If now a Preferred (S,G) Assert is received on > >RPF_interface(RP(G)), the (S,G) Assert state-machine will switch > >to the "I Am Assert Loser" state, performing Actions A6 which > >cause SPTbit(S,G) to be set to TRUE. Once this has happened, > >any (S,G) traffic received on RPF_interface(RP(G)) will not be > >forwarded, because neither... > > The rules for transitioning from "NoInfo" to "I Am Assert > Loser" state are: > > Receive Preferred Assert with RPT bit clear AND > AssertTrackingDesired(S,G,I)==TRUE > We're interested in (S,G) Asserts, either because I is a > downstream interface for which we have (S,G) or (*,G) > forwarding state, or because I is the upstream > interface for S and we have (S,G) forwarding state. The > received assert that has a better metric than our own, so > we do not win the Assert. We transition to "I am Assert > Loser" and perform actions A6. > > Ok, so taking a look at AssertTrackingDesired(S,G,I): > > AssertTrackingDesired(S,G,I) = > (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) > (+) ( pim_include(*,G) (-) pim_exclude(S,G) ) > (-) lost_assert(*,G) > (+) joins(S,G) ) ) > OR (local_receiver_include(S,G,I) == TRUE > AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me))) > OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE)) > OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE) > AND (SPTbit(S,G) == FALSE)) > > The first clause (I in ...) only applies to downstream interfaces, > which isn't the case here. local_receiver_include is false. > JoinDesired(S,G) is false because the keepalivetimer isn't > running. SPTbit(S,G) is false. > > So AssertTrackingDesired will be false. We won't track this assert. > As we won't track the assert, SPTbit won't be set. But AssertTrackingDesired(S,G) _will_ be true, because the final clause '(RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE) AND (SPTbit(S,G) == FALSE)' will be true (as each part is true by assumption). Cheers, James. --- James Lingard Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: James.Lingard@dataconnection.com Web: http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Sat Jan 24 06:39:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05782 for ; Sat, 24 Jan 2004 06:39:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkM7w-0006Rc-Qr; Sat, 24 Jan 2004 06:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkM7P-0006PU-RN for pim@optimus.ietf.org; Sat, 24 Jan 2004 06:38: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 GAA05752 for ; Sat, 24 Jan 2004 06:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkM7L-0001x2-00 for pim@ietf.org; Sat, 24 Jan 2004 06:38:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkM6X-0001vG-00 for pim@ietf.org; Sat, 24 Jan 2004 06:37:33 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkM67-0001s4-00 for pim@ietf.org; Sat, 24 Jan 2004 06:37:08 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0OBaXS31071; Sat, 24 Jan 2004 13:36:34 +0200 Date: Sat, 24 Jan 2004 13:36:33 +0200 (EET) From: Pekka Savola To: pim@ietf.org cc: Lehtonen Rami , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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=AWL autolearn=no version=2.60 Subject: [pim] New I-D on PIM-SM multicast routing security (fwd) Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , FYI, There are already some suggestions for enhancements, maybe worth considering for the PIM-SM revisions. And more in the works. Initial feedback from the "protocol side" would be greatly appreciated. :-) ---------- Forwarded message ---------- Date: Sat, 24 Jan 2004 13:34:15 +0200 (EET) From: Pekka Savola To: mboned@lists.uoregon.edu Cc: Lehtonen Rami , dmm@1-4-5.net Subject: New I-D on PIM-SM multicast routing security Hello all, When discussing the security properties of Embedded RP at the last IETF, it was identified that it would be useful to analyze the multicast routing security issues in general. So, me, Rami Lehtonen and Dave Meyer got down to it. Here's the result. The main thing it lacks at the moment are concrete proposals on which kind of rate-limiting (etc.) mechanisms would be useful. We'd like to get feedback/discussion on that (and other comments are also very welcome). http://www.ietf.org/internet-drafts/draft-savola-mboned-mroutesec-00.txt Comments welcome. Rami acts as the editor of the document. Pekka, Rami & Dave ---------- Forwarded message ---------- Date: Fri, 23 Jan 2004 16:00:05 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-savola-mboned-mroutesec-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PIM-SM Multicast Routing Security Issues and Enhancements Author(s) : P. Savola Filename : draft-savola-mboned-mroutesec-00.txt Pages : 17 Date : 2004-1-23 This memo describes security threats for the larger (intra-domain, or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any Source Multicast (ASM) model, Source-Specific Multicast (SSM) model, and the ASM model enhanced by the Embedded RP group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations to mitigate these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-mboned-mroutesec-00.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-savola-mboned-mroutesec-00.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-savola-mboned-mroutesec-00.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. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Sat Jan 24 06:40:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05812 for ; Sat, 24 Jan 2004 06:40:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkM9M-0006Yl-8v for pim-archive@odin.ietf.org; Sat, 24 Jan 2004 06:40:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0OBeSqR025207 for pim-archive@odin.ietf.org; Sat, 24 Jan 2004 06:40:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkM9M-0006YT-2h for pim-web-archive@optimus.ietf.org; Sat, 24 Jan 2004 06:40: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 GAA05809 for ; Sat, 24 Jan 2004 06:40:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkM9I-00022q-00 for pim-web-archive@ietf.org; Sat, 24 Jan 2004 06:40:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkM8O-00020p-00 for pim-web-archive@ietf.org; Sat, 24 Jan 2004 06:39:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkM86-0001yL-00 for pim-web-archive@ietf.org; Sat, 24 Jan 2004 06:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkM7w-0006Rc-Qr; Sat, 24 Jan 2004 06:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkM7P-0006PU-RN for pim@optimus.ietf.org; Sat, 24 Jan 2004 06:38: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 GAA05752 for ; Sat, 24 Jan 2004 06:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkM7L-0001x2-00 for pim@ietf.org; Sat, 24 Jan 2004 06:38:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkM6X-0001vG-00 for pim@ietf.org; Sat, 24 Jan 2004 06:37:33 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkM67-0001s4-00 for pim@ietf.org; Sat, 24 Jan 2004 06:37:08 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0OBaXS31071; Sat, 24 Jan 2004 13:36:34 +0200 Date: Sat, 24 Jan 2004 13:36:33 +0200 (EET) From: Pekka Savola To: pim@ietf.org cc: Lehtonen Rami , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [pim] New I-D on PIM-SM multicast routing security (fwd) Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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=AWL autolearn=no version=2.60 FYI, There are already some suggestions for enhancements, maybe worth considering for the PIM-SM revisions. And more in the works. Initial feedback from the "protocol side" would be greatly appreciated. :-) ---------- Forwarded message ---------- Date: Sat, 24 Jan 2004 13:34:15 +0200 (EET) From: Pekka Savola To: mboned@lists.uoregon.edu Cc: Lehtonen Rami , dmm@1-4-5.net Subject: New I-D on PIM-SM multicast routing security Hello all, When discussing the security properties of Embedded RP at the last IETF, it was identified that it would be useful to analyze the multicast routing security issues in general. So, me, Rami Lehtonen and Dave Meyer got down to it. Here's the result. The main thing it lacks at the moment are concrete proposals on which kind of rate-limiting (etc.) mechanisms would be useful. We'd like to get feedback/discussion on that (and other comments are also very welcome). http://www.ietf.org/internet-drafts/draft-savola-mboned-mroutesec-00.txt Comments welcome. Rami acts as the editor of the document. Pekka, Rami & Dave ---------- Forwarded message ---------- Date: Fri, 23 Jan 2004 16:00:05 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-savola-mboned-mroutesec-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PIM-SM Multicast Routing Security Issues and Enhancements Author(s) : P. Savola Filename : draft-savola-mboned-mroutesec-00.txt Pages : 17 Date : 2004-1-23 This memo describes security threats for the larger (intra-domain, or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any Source Multicast (ASM) model, Source-Specific Multicast (SSM) model, and the ASM model enhanced by the Embedded RP group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations to mitigate these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-mboned-mroutesec-00.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-savola-mboned-mroutesec-00.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-savola-mboned-mroutesec-00.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. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Sun Jan 25 17:39:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20120 for ; Sun, 25 Jan 2004 17:39:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AksuD-0004jd-Dg; Sun, 25 Jan 2004 17:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak44A-0006Io-8v for pim@optimus.ietf.org; Fri, 23 Jan 2004 11:21:54 -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 LAA09848 for ; Fri, 23 Jan 2004 11:21:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak449-0000Dv-00 for pim@ietf.org; Fri, 23 Jan 2004 11:21:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak43g-0000Aw-00 for pim@ietf.org; Fri, 23 Jan 2004 11:21:24 -0500 Received: from aardvark.cs.ucl.ac.uk ([128.16.11.150]) by ietf-mx with esmtp (Exim 4.12) id 1Ak42a-00000f-00 for pim@ietf.org; Fri, 23 Jan 2004 11:20:16 -0500 Received: from aardvark.cs.ucl.ac.uk (localhost [127.0.0.1]) by aardvark.cs.ucl.ac.uk (8.12.9p2/8.12.8) with ESMTP id i0NGKBxo002072; Fri, 23 Jan 2004 16:20:11 GMT (envelope-from mjh@aardvark.cs.ucl.ac.uk) From: Mark Handley X-Organisation: UCL To: James Lingard cc: "'pim@ietf.org'" Subject: Re: [pim] Error in PIM-SM forwarding rules In-reply-to: Your message of "Fri, 23 Jan 2004 15:39:46 GMT." <53F74F5A7B94D511841C00B0D0AB16F803580EEA@baker.datcon.co.uk> Date: Fri, 23 Jan 2004 16:20:11 +0000 Message-ID: <2071.1074874811@aardvark.cs.ucl.ac.uk> 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , >I am new to PIM and have recently been studying the PIM-SM draft. I believe >that there may be an error in the forwarding rules in the current draft >(draft-ietf-pim-sm-v2-new-08.txt, Section 4.2), which could cause a router >with only (*,G) forwarding state to incorrectly stop forwarding traffic from >a particular source. > >The problem is with the clause > > 'if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined )' > >Why is the second test 'UpstreamJPState(S,G) == Joined' and not 'SPTbit(S,G) >== TRUE'? It appears that as they stand the rules would cause a router with >only (*,G) forwarding state to stop forwarding traffic from S if SPTbit(S,G) >were set to TRUE. This may happen in the following scenario. > >Suppose that all of the following are true. > >- RPF_interface(RP(G)) == RPF_interface(S) >- JoinDesired(*,G) == TRUE >- JoinDesired(S,G) == FALSE >- (S,G) Assert state-machine is in NoInfo state > >If now a Preferred (S,G) Assert is received on RPF_interface(RP(G)), the >(S,G) Assert state-machine will switch to the "I Am Assert Loser" state, >performing Actions A6 which cause SPTbit(S,G) to be set to TRUE. Once this >has happened, any (S,G) traffic received on RPF_interface(RP(G)) will not be >forwarded, because neither... The rules for transitioning from "NoInfo" to "I Am Assert Loser" state are: Receive Preferred Assert with RPT bit clear AND AssertTrackingDesired(S,G,I)==TRUE We're interested in (S,G) Asserts, either because I is a downstream interface for which we have (S,G) or (*,G) forwarding state, or because I is the upstream interface for S and we have (S,G) forwarding state. The received assert that has a better metric than our own, so we do not win the Assert. We transition to "I am Assert Loser" and perform actions A6. Ok, so taking a look at AssertTrackingDesired(S,G,I): AssertTrackingDesired(S,G,I) = (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) (+) ( pim_include(*,G) (-) pim_exclude(S,G) ) (-) lost_assert(*,G) (+) joins(S,G) ) ) OR (local_receiver_include(S,G,I) == TRUE AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me))) OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE)) OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE) AND (SPTbit(S,G) == FALSE)) The first clause (I in ...) only applies to downstream interfaces, which isn't the case here. local_receiver_include is false. JoinDesired(S,G) is false because the keepalivetimer isn't running. SPTbit(S,G) is false. So AssertTrackingDesired will be false. We won't track this assert. As we won't track the assert, SPTbit won't be set. Thus I don't think the problem you describe can happen, at least not in the way you suggest. Of course I could have overlooked something... Cheers, Mark _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Sun Jan 25 17:40:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20200 for ; Sun, 25 Jan 2004 17:40:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aksvf-0004rW-Dy for pim-archive@odin.ietf.org; Sun, 25 Jan 2004 17:40:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0PMeVqS018684 for pim-archive@odin.ietf.org; Sun, 25 Jan 2004 17:40:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aksvf-0004rH-8H for pim-web-archive@optimus.ietf.org; Sun, 25 Jan 2004 17:40:31 -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 RAA20192 for ; Sun, 25 Jan 2004 17:40:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aksvc-0005TI-00 for pim-web-archive@ietf.org; Sun, 25 Jan 2004 17:40:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aksuj-0005Qp-00 for pim-web-archive@ietf.org; Sun, 25 Jan 2004 17:39:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AksuU-0005OV-00 for pim-web-archive@ietf.org; Sun, 25 Jan 2004 17:39:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AksuD-0004jd-Dg; Sun, 25 Jan 2004 17:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak44A-0006Io-8v for pim@optimus.ietf.org; Fri, 23 Jan 2004 11:21:54 -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 LAA09848 for ; Fri, 23 Jan 2004 11:21:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak449-0000Dv-00 for pim@ietf.org; Fri, 23 Jan 2004 11:21:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak43g-0000Aw-00 for pim@ietf.org; Fri, 23 Jan 2004 11:21:24 -0500 Received: from aardvark.cs.ucl.ac.uk ([128.16.11.150]) by ietf-mx with esmtp (Exim 4.12) id 1Ak42a-00000f-00 for pim@ietf.org; Fri, 23 Jan 2004 11:20:16 -0500 Received: from aardvark.cs.ucl.ac.uk (localhost [127.0.0.1]) by aardvark.cs.ucl.ac.uk (8.12.9p2/8.12.8) with ESMTP id i0NGKBxo002072; Fri, 23 Jan 2004 16:20:11 GMT (envelope-from mjh@aardvark.cs.ucl.ac.uk) From: Mark Handley X-Organisation: UCL To: James Lingard cc: "'pim@ietf.org'" Subject: Re: [pim] Error in PIM-SM forwarding rules In-reply-to: Your message of "Fri, 23 Jan 2004 15:39:46 GMT." <53F74F5A7B94D511841C00B0D0AB16F803580EEA@baker.datcon.co.uk> Date: Fri, 23 Jan 2004 16:20:11 +0000 Message-ID: <2071.1074874811@aardvark.cs.ucl.ac.uk> Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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 >I am new to PIM and have recently been studying the PIM-SM draft. I believe >that there may be an error in the forwarding rules in the current draft >(draft-ietf-pim-sm-v2-new-08.txt, Section 4.2), which could cause a router >with only (*,G) forwarding state to incorrectly stop forwarding traffic from >a particular source. > >The problem is with the clause > > 'if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined )' > >Why is the second test 'UpstreamJPState(S,G) == Joined' and not 'SPTbit(S,G) >== TRUE'? It appears that as they stand the rules would cause a router with >only (*,G) forwarding state to stop forwarding traffic from S if SPTbit(S,G) >were set to TRUE. This may happen in the following scenario. > >Suppose that all of the following are true. > >- RPF_interface(RP(G)) == RPF_interface(S) >- JoinDesired(*,G) == TRUE >- JoinDesired(S,G) == FALSE >- (S,G) Assert state-machine is in NoInfo state > >If now a Preferred (S,G) Assert is received on RPF_interface(RP(G)), the >(S,G) Assert state-machine will switch to the "I Am Assert Loser" state, >performing Actions A6 which cause SPTbit(S,G) to be set to TRUE. Once this >has happened, any (S,G) traffic received on RPF_interface(RP(G)) will not be >forwarded, because neither... The rules for transitioning from "NoInfo" to "I Am Assert Loser" state are: Receive Preferred Assert with RPT bit clear AND AssertTrackingDesired(S,G,I)==TRUE We're interested in (S,G) Asserts, either because I is a downstream interface for which we have (S,G) or (*,G) forwarding state, or because I is the upstream interface for S and we have (S,G) forwarding state. The received assert that has a better metric than our own, so we do not win the Assert. We transition to "I am Assert Loser" and perform actions A6. Ok, so taking a look at AssertTrackingDesired(S,G,I): AssertTrackingDesired(S,G,I) = (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) (+) ( pim_include(*,G) (-) pim_exclude(S,G) ) (-) lost_assert(*,G) (+) joins(S,G) ) ) OR (local_receiver_include(S,G,I) == TRUE AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me))) OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE)) OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE) AND (SPTbit(S,G) == FALSE)) The first clause (I in ...) only applies to downstream interfaces, which isn't the case here. local_receiver_include is false. JoinDesired(S,G) is false because the keepalivetimer isn't running. SPTbit(S,G) is false. So AssertTrackingDesired will be false. We won't track this assert. As we won't track the assert, SPTbit won't be set. Thus I don't think the problem you describe can happen, at least not in the way you suggest. Of course I could have overlooked something... Cheers, Mark _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Jan 27 20:21:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08297 for ; Tue, 27 Jan 2004 20:21:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleNA-00018z-05; Tue, 27 Jan 2004 20:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleMJ-00015Z-FK for pim@optimus.ietf.org; Tue, 27 Jan 2004 20:19:11 -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 UAA08105 for ; Tue, 27 Jan 2004 20:19:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AleMH-0005y2-00 for pim@ietf.org; Tue, 27 Jan 2004 20:19:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AleLH-0005pQ-00 for pim@ietf.org; Tue, 27 Jan 2004 20:18:08 -0500 Received: from nn7.excitenetwork.com ([207.159.120.61] helo=xprdmailfe2.nwk.excite.com) by ietf-mx with esmtp (Exim 4.12) id 1AleKP-0005fj-00 for pim@ietf.org; Tue, 27 Jan 2004 20:17:13 -0500 Received: by xprdmailfe2.nwk.excite.com (Postfix, from userid 110) id F240B8AEAF; Tue, 27 Jan 2004 20:16:43 -0500 (EST) To: pim@ietf.org Received: from [203.180.124.14] by xprdmailfe2.nwk.excite.com via HTTP; Tue, 27 Jan 2004 20:16:43 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ab0ec0e5e86bd0b0eae8fc3eaff26398 Reply-To: aruts@excite.com From: "" MIME-Version: 1.0 X-Sender: aruts@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> Date: Tue, 27 Jan 2004 20:16:43 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [pim] PIM BSM fragmentation Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I would like to know why fragmentation support (read fragmentation tag) is required at PIM level when IP is already doing it. Thanks, ARUT _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Tue Jan 27 20:23:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08612 for ; Tue, 27 Jan 2004 20:23:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlePn-0001Ri-WF for pim-archive@odin.ietf.org; Tue, 27 Jan 2004 20:22:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S1Mlik005552 for pim-archive@odin.ietf.org; Tue, 27 Jan 2004 20:22:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlePn-0001RT-Op for pim-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 20:22:47 -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 UAA08520 for ; Tue, 27 Jan 2004 20:22:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlePl-0006Xl-00 for pim-web-archive@ietf.org; Tue, 27 Jan 2004 20:22:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AleOm-0006Ma-00 for pim-web-archive@ietf.org; Tue, 27 Jan 2004 20:21:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AleNa-0006Aq-00 for pim-web-archive@ietf.org; Tue, 27 Jan 2004 20:20:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleNA-00018z-05; Tue, 27 Jan 2004 20:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleMJ-00015Z-FK for pim@optimus.ietf.org; Tue, 27 Jan 2004 20:19:11 -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 UAA08105 for ; Tue, 27 Jan 2004 20:19:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AleMH-0005y2-00 for pim@ietf.org; Tue, 27 Jan 2004 20:19:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AleLH-0005pQ-00 for pim@ietf.org; Tue, 27 Jan 2004 20:18:08 -0500 Received: from nn7.excitenetwork.com ([207.159.120.61] helo=xprdmailfe2.nwk.excite.com) by ietf-mx with esmtp (Exim 4.12) id 1AleKP-0005fj-00 for pim@ietf.org; Tue, 27 Jan 2004 20:17:13 -0500 Received: by xprdmailfe2.nwk.excite.com (Postfix, from userid 110) id F240B8AEAF; Tue, 27 Jan 2004 20:16:43 -0500 (EST) To: pim@ietf.org Received: from [203.180.124.14] by xprdmailfe2.nwk.excite.com via HTTP; Tue, 27 Jan 2004 20:16:43 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ab0ec0e5e86bd0b0eae8fc3eaff26398 Reply-To: aruts@excite.com From: "" MIME-Version: 1.0 X-Sender: aruts@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> Date: Tue, 27 Jan 2004 20:16:43 -0500 (EST) Content-Transfer-Encoding: 7bit Subject: [pim] PIM BSM fragmentation Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I would like to know why fragmentation support (read fragmentation tag) is required at PIM level when IP is already doing it. Thanks, ARUT _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Jan 27 20:28:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08876 for ; Tue, 27 Jan 2004 20:28:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleUr-0001gN-Dm; Tue, 27 Jan 2004 20:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleU6-0001fe-RX for pim@optimus.ietf.org; Tue, 27 Jan 2004 20:27:14 -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 UAA08828 for ; Tue, 27 Jan 2004 20:27:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AleU4-00070T-00 for pim@ietf.org; Tue, 27 Jan 2004 20:27:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AleT8-0006wz-00 for pim@ietf.org; Tue, 27 Jan 2004 20:26:15 -0500 Received: from smtp2.procket.com ([65.174.124.37] helo=dmz2.procket.com) by ietf-mx with esmtp (Exim 4.12) id 1AleSr-0006tF-00 for pim@ietf.org; Tue, 27 Jan 2004 20:25:57 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i0S3VUOt056691; Tue, 27 Jan 2004 19:31:30 -0800 (PST) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i0S1PIYB009256; Tue, 27 Jan 2004 17:25:18 -0800 (PST) Received: from [127.0.0.1] ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Jan 2004 17:25:18 -0800 In-Reply-To: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> References: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: John Zwiebel , pim@ietf.org From: John Zwiebel Subject: Re: [pim] PIM BSM fragmentation Date: Tue, 27 Jan 2004 17:25:19 -0800 To: aruts@excite.com X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 28 Jan 2004 01:25:18.0544 (UTC) FILETIME=[96FD1500:01C3E53D] 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Jan 27, 2004, at 5:16 PM, "" wrote: > > I would like to know why fragmentation support (read fragmentation > tag) is required at PIM level when IP is already doing it. > Because if IP does it, it may not include all the source for a given group within the same packet. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Tue Jan 27 20:30:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08954 for ; Tue, 27 Jan 2004 20:30:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleWr-0001mG-Tw for pim-archive@odin.ietf.org; Tue, 27 Jan 2004 20:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S1U5rF006826 for pim-archive@odin.ietf.org; Tue, 27 Jan 2004 20:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleWr-0001m1-OU for pim-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 20:30:05 -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 UAA08923 for ; Tue, 27 Jan 2004 20:30:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AleWp-00079f-00 for pim-web-archive@ietf.org; Tue, 27 Jan 2004 20:30:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AleVr-00076J-00 for pim-web-archive@ietf.org; Tue, 27 Jan 2004 20:29:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AleUz-00073b-00 for pim-web-archive@ietf.org; Tue, 27 Jan 2004 20:28:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleUr-0001gN-Dm; Tue, 27 Jan 2004 20:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleU6-0001fe-RX for pim@optimus.ietf.org; Tue, 27 Jan 2004 20:27:14 -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 UAA08828 for ; Tue, 27 Jan 2004 20:27:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AleU4-00070T-00 for pim@ietf.org; Tue, 27 Jan 2004 20:27:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AleT8-0006wz-00 for pim@ietf.org; Tue, 27 Jan 2004 20:26:15 -0500 Received: from smtp2.procket.com ([65.174.124.37] helo=dmz2.procket.com) by ietf-mx with esmtp (Exim 4.12) id 1AleSr-0006tF-00 for pim@ietf.org; Tue, 27 Jan 2004 20:25:57 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i0S3VUOt056691; Tue, 27 Jan 2004 19:31:30 -0800 (PST) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i0S1PIYB009256; Tue, 27 Jan 2004 17:25:18 -0800 (PST) Received: from [127.0.0.1] ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Jan 2004 17:25:18 -0800 In-Reply-To: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> References: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: John Zwiebel , pim@ietf.org From: John Zwiebel Subject: Re: [pim] PIM BSM fragmentation Date: Tue, 27 Jan 2004 17:25:19 -0800 To: aruts@excite.com X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 28 Jan 2004 01:25:18.0544 (UTC) FILETIME=[96FD1500:01C3E53D] Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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 On Jan 27, 2004, at 5:16 PM, "" wrote: > > I would like to know why fragmentation support (read fragmentation > tag) is required at PIM level when IP is already doing it. > Because if IP does it, it may not include all the source for a given group within the same packet. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Jan 28 02:58:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18155 for ; Wed, 28 Jan 2004 02:58:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlkZJ-0007IH-Jz; Wed, 28 Jan 2004 02:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlkYl-0007Dg-CL for pim@optimus.ietf.org; Wed, 28 Jan 2004 02:56: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 CAA18027 for ; Wed, 28 Jan 2004 02:56:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlkYh-0003OE-00 for pim@ietf.org; Wed, 28 Jan 2004 02:56:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlkXo-0003JK-00 for pim@ietf.org; Wed, 28 Jan 2004 02:55:29 -0500 Received: from nn7.excitenetwork.com ([207.159.120.61] helo=xprdmailfe2.nwk.excite.com) by ietf-mx with esmtp (Exim 4.12) id 1AlkWv-00039P-00 for pim@ietf.org; Wed, 28 Jan 2004 02:54:33 -0500 Received: by xprdmailfe2.nwk.excite.com (Postfix, from userid 110) id 27D1A8AE91; Wed, 28 Jan 2004 02:54:05 -0500 (EST) To: ben@layer8.net, jzwiebel@procket.com Received: from [203.180.124.14] by xprdmailfe2.nwk.excite.com via HTTP; Wed, 28 Jan 2004 02:54:05 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ab0ec0e5e86bd0b0eae8fc3eaff26398 Reply-To: aruts@excite.com From: "" MIME-Version: 1.0 X-Sender: aruts@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: aruts@excite.com, pim@ietf.org Message-Id: <20040128075405.27D1A8AE91@xprdmailfe2.nwk.excite.com> Date: Wed, 28 Jan 2004 02:54:05 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [pim] I Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, IP actually does reassembly before it gives it to PIM and PIM receives the complete packet intact.I have seen it work! So, I don`t understand the need for a fragmentation flag! Thanks, Arut --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: From: Benjamin Black [mailto: ben@layer8.net] To: jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Date: Tue, 27 Jan 2004 19:54:05 -0800 Subject: Re: [pim] PIM BSM fragmentation put a slightly different way:

PIM can generate a message larger than the maximum size for a single IP
packet, so it must be able to reassemble things when a single PIM
message is fragmented over multiple IP packets.


ben

On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at 5:16 PM, "" wrote:
>
>>
>> I would like to know why fragmentation support (read fragmentation
>> tag) is required at PIM level when IP is already doing it.
>>
>
> Because if IP does it, it may not include all the source for a given
> group within the same
> packet.
>
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www1.ietf.org/mailman/listinfo/pim
>
>

_______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Jan 28 02:59:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18219 for ; Wed, 28 Jan 2004 02:59:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alkbk-0007aV-Dk for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 02:59:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S7xWRa029141 for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 02:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alkbj-0007Zv-IN for pim-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 02:59:31 -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 CAA18179 for ; Wed, 28 Jan 2004 02:59:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alkbf-0003h4-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 02:59:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alkam-0003bx-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 02:58:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alka7-0003XC-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 02:57:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlkZJ-0007IH-Jz; Wed, 28 Jan 2004 02:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlkYl-0007Dg-CL for pim@optimus.ietf.org; Wed, 28 Jan 2004 02:56: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 CAA18027 for ; Wed, 28 Jan 2004 02:56:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlkYh-0003OE-00 for pim@ietf.org; Wed, 28 Jan 2004 02:56:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlkXo-0003JK-00 for pim@ietf.org; Wed, 28 Jan 2004 02:55:29 -0500 Received: from nn7.excitenetwork.com ([207.159.120.61] helo=xprdmailfe2.nwk.excite.com) by ietf-mx with esmtp (Exim 4.12) id 1AlkWv-00039P-00 for pim@ietf.org; Wed, 28 Jan 2004 02:54:33 -0500 Received: by xprdmailfe2.nwk.excite.com (Postfix, from userid 110) id 27D1A8AE91; Wed, 28 Jan 2004 02:54:05 -0500 (EST) To: ben@layer8.net, jzwiebel@procket.com Received: from [203.180.124.14] by xprdmailfe2.nwk.excite.com via HTTP; Wed, 28 Jan 2004 02:54:05 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ab0ec0e5e86bd0b0eae8fc3eaff26398 Reply-To: aruts@excite.com From: "" MIME-Version: 1.0 X-Sender: aruts@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: aruts@excite.com, pim@ietf.org Message-Id: <20040128075405.27D1A8AE91@xprdmailfe2.nwk.excite.com> Date: Wed, 28 Jan 2004 02:54:05 -0500 (EST) Content-Transfer-Encoding: 7bit Subject: [pim] I Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, IP actually does reassembly before it gives it to PIM and PIM receives the complete packet intact.I have seen it work! So, I don`t understand the need for a fragmentation flag! Thanks, Arut --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: From: Benjamin Black [mailto: ben@layer8.net] To: jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Date: Tue, 27 Jan 2004 19:54:05 -0800 Subject: Re: [pim] PIM BSM fragmentation put a slightly different way:

PIM can generate a message larger than the maximum size for a single IP
packet, so it must be able to reassemble things when a single PIM
message is fragmented over multiple IP packets.


ben

On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at 5:16 PM, "" wrote:
>
>>
>> I would like to know why fragmentation support (read fragmentation
>> tag) is required at PIM level when IP is already doing it.
>>
>
> Because if IP does it, it may not include all the source for a given
> group within the same
> packet.
>
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www1.ietf.org/mailman/listinfo/pim
>
>

_______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Jan 28 06:37:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26446 for ; Wed, 28 Jan 2004 06:37:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alo0E-0006VM-4T; Wed, 28 Jan 2004 06:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alnzq-0006UW-30 for pim@optimus.ietf.org; Wed, 28 Jan 2004 06:36:38 -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 GAA26412 for ; Wed, 28 Jan 2004 06:36:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alnzl-00079X-00 for pim@ietf.org; Wed, 28 Jan 2004 06:36:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alnyp-00074q-00 for pim@ietf.org; Wed, 28 Jan 2004 06:35:36 -0500 Received: from web8201.mail.in.yahoo.com ([203.199.70.114]) by ietf-mx with smtp (Exim 4.12) id 1AlnyR-0006zl-00 for pim@ietf.org; Wed, 28 Jan 2004 06:35:11 -0500 Message-ID: <20040128113359.94758.qmail@web8201.mail.in.yahoo.com> Received: from [203.200.49.220] by web8201.mail.in.yahoo.com via HTTP; Wed, 28 Jan 2004 11:33:59 GMT Date: Wed, 28 Jan 2004 11:33:59 +0000 (GMT) From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?= Subject: Re: [pim] I To: aruts@excite.com, ben@layer8.net, jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org In-Reply-To: <20040128075405.27D1A8AE91@xprdmailfe2.nwk.excite.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-150707449-1075289639=:94440" Content-Transfer-Encoding: 8bit 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=HTML_MESSAGE autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , --0-150707449-1075289639=:94440 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi jzwiebel, Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol. I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message. Thanx, Jags wrote: Hi, IP actually does reassembly before it gives it to PIM and PIM receives the complete packet intact.I have seen it work! So, I don`t understand the need for a fragmentation flag! Thanks, Arut --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: From: Benjamin Black [mailto: ben@layer8.net] To: jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Date: Tue, 27 Jan 2004 19:54:05 -0800 Subject: Re: [pim] PIM BSM fragmentation put a slightly different way: PIM can generate a message larger than the maximum size for a single IP packet, so it must be able to reassemble things when a single PIM message is fragmented over multiple IP packets. ben On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > On Jan 27, 2004, at 5:16 PM, "" wrote: > >> >> I would like to know why fragmentation support (read fragmentation >> tag) is required at PIM level when IP is already doing it. >> > > Because if IP does it, it may not include all the source for a given > group within the same > packet. > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.Download now. --0-150707449-1075289639=:94440 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi jzwiebel,
   Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol.
    I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message.
 
Thanx,
Jags

<aruts@excite.com> wrote:

Hi,

IP actually does reassembly before it gives it to PIM and
PIM receives the complete packet intact.I have seen it work!

So, I don`t understand the need for a fragmentation flag!

Thanks,
Arut




--- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote:
From: Benjamin Black [mailto: ben@layer8.net]
To: jzwiebel@procket.com
Cc: aruts@excite.com, pim@ietf.org
Date: Tue, 27 Jan 2004 19:54:05 -0800
Subject: Re: [pim] PIM BSM fragmentation

put a slightly different way:

PIM can generate a message larger than the maximum size for a single IP
packet, so it must be able to reassemble things when a single PIM
message is fragmented over multiple IP packets.


ben

On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at 5:16 PM, "" wrote:
>
>>
>> I would like to know why fragmentation support (read fragmentation
>> tag) is required at PIM level when IP is already doing it.
>>
>
> Because if IP does it, it may not include all the source for a given
> group within the same
> packet.
>
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www1.ietf.org/mailman/listinfo/pim
>
>



_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

_______________________________________________
pim mailing list
pim@ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. --0-150707449-1075289639=:94440-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Jan 28 06:39:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26534 for ; Wed, 28 Jan 2004 06:39:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alo2Z-0006ua-Hl for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 06:39:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SBdRRR026562 for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 06:39:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alo2Z-0006uJ-Bq for pim-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 06:39: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 GAA26505 for ; Wed, 28 Jan 2004 06:39:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alo2V-0007No-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 06:39:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alo1Y-0007J2-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 06:38:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alo0d-0007EZ-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 06:37:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alo0E-0006VM-4T; Wed, 28 Jan 2004 06:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alnzq-0006UW-30 for pim@optimus.ietf.org; Wed, 28 Jan 2004 06:36:38 -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 GAA26412 for ; Wed, 28 Jan 2004 06:36:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alnzl-00079X-00 for pim@ietf.org; Wed, 28 Jan 2004 06:36:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alnyp-00074q-00 for pim@ietf.org; Wed, 28 Jan 2004 06:35:36 -0500 Received: from web8201.mail.in.yahoo.com ([203.199.70.114]) by ietf-mx with smtp (Exim 4.12) id 1AlnyR-0006zl-00 for pim@ietf.org; Wed, 28 Jan 2004 06:35:11 -0500 Message-ID: <20040128113359.94758.qmail@web8201.mail.in.yahoo.com> Received: from [203.200.49.220] by web8201.mail.in.yahoo.com via HTTP; Wed, 28 Jan 2004 11:33:59 GMT Date: Wed, 28 Jan 2004 11:33:59 +0000 (GMT) From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?= Subject: Re: [pim] I To: aruts@excite.com, ben@layer8.net, jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org In-Reply-To: <20040128075405.27D1A8AE91@xprdmailfe2.nwk.excite.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-150707449-1075289639=:94440" Content-Transfer-Encoding: 8bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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=HTML_MESSAGE autolearn=no version=2.60 --0-150707449-1075289639=:94440 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi jzwiebel, Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol. I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message. Thanx, Jags wrote: Hi, IP actually does reassembly before it gives it to PIM and PIM receives the complete packet intact.I have seen it work! So, I don`t understand the need for a fragmentation flag! Thanks, Arut --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: From: Benjamin Black [mailto: ben@layer8.net] To: jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Date: Tue, 27 Jan 2004 19:54:05 -0800 Subject: Re: [pim] PIM BSM fragmentation put a slightly different way: PIM can generate a message larger than the maximum size for a single IP packet, so it must be able to reassemble things when a single PIM message is fragmented over multiple IP packets. ben On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > On Jan 27, 2004, at 5:16 PM, "" wrote: > >> >> I would like to know why fragmentation support (read fragmentation >> tag) is required at PIM level when IP is already doing it. >> > > Because if IP does it, it may not include all the source for a given > group within the same > packet. > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.Download now. --0-150707449-1075289639=:94440 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi jzwiebel,
   Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol.
    I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message.
 
Thanx,
Jags

<aruts@excite.com> wrote:

Hi,

IP actually does reassembly before it gives it to PIM and
PIM receives the complete packet intact.I have seen it work!

So, I don`t understand the need for a fragmentation flag!

Thanks,
Arut




--- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote:
From: Benjamin Black [mailto: ben@layer8.net]
To: jzwiebel@procket.com
Cc: aruts@excite.com, pim@ietf.org
Date: Tue, 27 Jan 2004 19:54:05 -0800
Subject: Re: [pim] PIM BSM fragmentation

put a slightly different way:

PIM can generate a message larger than the maximum size for a single IP
packet, so it must be able to reassemble things when a single PIM
message is fragmented over multiple IP packets.


ben

On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at 5:16 PM, "" wrote:
>
>>
>> I would like to know why fragmentation support (read fragmentation
>> tag) is required at PIM level when IP is already doing it.
>>
>
> Because if IP does it, it may not include all the source for a given
> group within the same
> packet.
>
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www1.ietf.org/mailman/listinfo/pim
>
>



_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

_______________________________________________
pim mailing list
pim@ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. --0-150707449-1075289639=:94440-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Jan 28 07:13:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27745 for ; Wed, 28 Jan 2004 07:13:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloZ2-0000uH-2Y; Wed, 28 Jan 2004 07:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloYl-0000tF-IU for pim@optimus.ietf.org; Wed, 28 Jan 2004 07:12:43 -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 HAA27660 for ; Wed, 28 Jan 2004 07:12:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AloYl-0002QK-00 for pim@ietf.org; Wed, 28 Jan 2004 07:12:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AloXY-0002Bj-00 for pim@ietf.org; Wed, 28 Jan 2004 07:11:29 -0500 Received: from web8201.mail.in.yahoo.com ([203.199.70.114]) by ietf-mx with smtp (Exim 4.12) id 1AloW3-0001vz-00 for pim@ietf.org; Wed, 28 Jan 2004 07:09:55 -0500 Message-ID: <20040128120925.1691.qmail@web8201.mail.in.yahoo.com> Received: from [203.126.136.220] by web8201.mail.in.yahoo.com via HTTP; Wed, 28 Jan 2004 12:09:25 GMT Date: Wed, 28 Jan 2004 12:09:25 +0000 (GMT) From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?= Subject: Re: [pim] I To: Rajamanickam jaganbabu , aruts@excite.com, ben@layer8.net, jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org In-Reply-To: <20040128113359.94758.qmail@web8201.mail.in.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-245777593-1075291765=:1589" Content-Transfer-Encoding: 8bit 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=HTML_MESSAGE autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , --0-245777593-1075291765=:1589 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sorry, i have over looked.. It is possible when the MTU is more than 65565 bytes which is very possible in the case of OC interfaces. Rajamanickam jaganbabu wrote:Hi jzwiebel, Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol. I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message. Thanx, Jags wrote: Hi, IP actually does reassembly before it gives it to PIM and PIM receives the complete packet intact.I have seen it work! So, I don`t understand the need for a fragmentation flag! Thanks, Arut --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: From: Benjamin Black [mailto: ben@layer8.net] To: jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Date: Tue, 27 Jan 2004 19:54:05 -0800 Subject: Re: [pim] PIM BSM fragmentation put a slightly different way: PIM can generate a message larger than the maximum size for a single IP packet, so it must be able to reassemble things when a single PIM message is fragmented over multiple IP packets. ben On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > On Jan 27, 2004, at 5:16 PM, "" wrote: > >> >> I would like to know why fragmentation support (read fragmentation >> tag) is required at PIM level when IP is already doing it. >> > > Because if IP does it, it may not include all the source for a given > group within the same > packet. > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.Download now. --0-245777593-1075291765=:1589 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Sorry, i have over looked.. It is possible when the MTU is more than 65565 bytes which is very possible in the case of OC interfaces.

Rajamanickam jaganbabu <jaganbabu_pim@yahoo.co.in> wrote:
Hi jzwiebel,
   Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol.
    I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message.
 
Thanx,
Jags

<aruts@excite.com> wrote:

Hi,

IP actually does reassembly before it gives it to PIM and
PIM receives the complete packet intact.I have seen it work!

So, I don`t understand the need for a fragmentation flag!

Thanks,
Arut




--- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote:
From: Benjamin Black [mailto: ben@layer8.net]
To: jzwiebel@procket.com
Cc: aruts@excite.com, pim@ietf.org
Date: Tue, 27 Jan 2004 19:54:05 -0800
Subject: Re: [pim] PIM BSM fragmentation

put a slightly different way:

PIM can generate a message larger than the maximum size for a single IP
packet, so it must be able to reassemble things when a single PIM
message is fragmented over multiple IP packets.


ben

On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at 5:16 PM, "" wrote:
>
>>
>> I would like to know why fragmentation support (read fragmentation
>> tag) is required at PIM level when IP is already doing it.
>>
>
> Because if IP does it, it may not include all the source for a given
> group within the same
> packet.
>
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www1.ietf.org/mailman/listinfo/pim
>
>



_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

_______________________________________________
pim mailing list
pim@ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now.

Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. --0-245777593-1075291765=:1589-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Jan 28 07:15:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27828 for ; Wed, 28 Jan 2004 07:15: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 1Aloaa-0001Ai-Tm for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 07:14:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SCEaj0004498 for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 07:14:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aloaa-0001AT-N4 for pim-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 07:14:36 -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 HAA27822 for ; Wed, 28 Jan 2004 07:14:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aloaa-0002cS-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 07:14:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AloZd-0002XY-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 07:13:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AloZ9-0002SM-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 07:13:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloZ2-0000uH-2Y; Wed, 28 Jan 2004 07:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloYl-0000tF-IU for pim@optimus.ietf.org; Wed, 28 Jan 2004 07:12:43 -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 HAA27660 for ; Wed, 28 Jan 2004 07:12:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AloYl-0002QK-00 for pim@ietf.org; Wed, 28 Jan 2004 07:12:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AloXY-0002Bj-00 for pim@ietf.org; Wed, 28 Jan 2004 07:11:29 -0500 Received: from web8201.mail.in.yahoo.com ([203.199.70.114]) by ietf-mx with smtp (Exim 4.12) id 1AloW3-0001vz-00 for pim@ietf.org; Wed, 28 Jan 2004 07:09:55 -0500 Message-ID: <20040128120925.1691.qmail@web8201.mail.in.yahoo.com> Received: from [203.126.136.220] by web8201.mail.in.yahoo.com via HTTP; Wed, 28 Jan 2004 12:09:25 GMT Date: Wed, 28 Jan 2004 12:09:25 +0000 (GMT) From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?= Subject: Re: [pim] I To: Rajamanickam jaganbabu , aruts@excite.com, ben@layer8.net, jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org In-Reply-To: <20040128113359.94758.qmail@web8201.mail.in.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-245777593-1075291765=:1589" Content-Transfer-Encoding: 8bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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=HTML_MESSAGE autolearn=no version=2.60 --0-245777593-1075291765=:1589 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sorry, i have over looked.. It is possible when the MTU is more than 65565 bytes which is very possible in the case of OC interfaces. Rajamanickam jaganbabu wrote:Hi jzwiebel, Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol. I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message. Thanx, Jags wrote: Hi, IP actually does reassembly before it gives it to PIM and PIM receives the complete packet intact.I have seen it work! So, I don`t understand the need for a fragmentation flag! Thanks, Arut --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: From: Benjamin Black [mailto: ben@layer8.net] To: jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Date: Tue, 27 Jan 2004 19:54:05 -0800 Subject: Re: [pim] PIM BSM fragmentation put a slightly different way: PIM can generate a message larger than the maximum size for a single IP packet, so it must be able to reassemble things when a single PIM message is fragmented over multiple IP packets. ben On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > On Jan 27, 2004, at 5:16 PM, "" wrote: > >> >> I would like to know why fragmentation support (read fragmentation >> tag) is required at PIM level when IP is already doing it. >> > > Because if IP does it, it may not include all the source for a given > group within the same > packet. > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.Download now. --0-245777593-1075291765=:1589 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Sorry, i have over looked.. It is possible when the MTU is more than 65565 bytes which is very possible in the case of OC interfaces.

Rajamanickam jaganbabu <jaganbabu_pim@yahoo.co.in> wrote:
Hi jzwiebel,
   Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol.
    I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message.
 
Thanx,
Jags

<aruts@excite.com> wrote:

Hi,

IP actually does reassembly before it gives it to PIM and
PIM receives the complete packet intact.I have seen it work!

So, I don`t understand the need for a fragmentation flag!

Thanks,
Arut




--- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote:
From: Benjamin Black [mailto: ben@layer8.net]
To: jzwiebel@procket.com
Cc: aruts@excite.com, pim@ietf.org
Date: Tue, 27 Jan 2004 19:54:05 -0800
Subject: Re: [pim] PIM BSM fragmentation

put a slightly different way:

PIM can generate a message larger than the maximum size for a single IP
packet, so it must be able to reassemble things when a single PIM
message is fragmented over multiple IP packets.


ben

On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at 5:16 PM, "" wrote:
>
>>
>> I would like to know why fragmentation support (read fragmentation
>> tag) is required at PIM level when IP is already doing it.
>>
>
> Because if IP does it, it may not include all the source for a given
> group within the same
> packet.
>
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www1.ietf.org/mailman/listinfo/pim
>
>



_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

_______________________________________________
pim mailing list
pim@ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now.

Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. --0-245777593-1075291765=:1589-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Jan 28 10:02:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02901 for ; Wed, 28 Jan 2004 10:02:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlrCa-0005R0-Ug; Wed, 28 Jan 2004 10:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlrC9-00054q-RK for pim@optimus.ietf.org; Wed, 28 Jan 2004 10:01:34 -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 KAA02868 for ; Wed, 28 Jan 2004 10:01:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlrC7-0000Ue-00 for pim@ietf.org; Wed, 28 Jan 2004 10:01:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlrB8-0000QQ-00 for pim@ietf.org; Wed, 28 Jan 2004 10:00:31 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AlrAC-0000MT-00 for pim@ietf.org; Wed, 28 Jan 2004 09:59:36 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i0SExVqC004658 for ; Wed, 28 Jan 2004 07:59:31 -0700 (MST) Received: from il06exm10.corp.mot.com (il06exm10.corp.mot.com [10.0.111.10]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i0SEwBup025440 for ; Wed, 28 Jan 2004 08:58:11 -0600 Received: by il06exm10 with Internet Mail Service (5.5.2657.2) id ; Wed, 28 Jan 2004 08:59:29 -0600 Message-ID: From: Cormier Chris-ACC125 To: "'Rajamanickam jaganbabu'" , aruts@excite.com, ben@layer8.net, jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Subject: RE: [pim] I Date: Wed, 28 Jan 2004 08:59:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E5AF.52231CFA" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_FONTCOLOR_BLUE, HTML_MESSAGE,HTML_TAG_BALANCE_BODY,MIME_BASE64_TEXT, MIME_HTML_NO_CHARSET autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E5AF.52231CFA Content-Type: text/plain If you drop 1 IP fragment of the RP set, you would lose the whole RP set. If you drop a single PIM fragment, you can still recover the rest of the RP set. -cgc -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org] On Behalf Of Rajamanickam jaganbabu Sent: Wednesday, January 28, 2004 4:09 AM To: Rajamanickam jaganbabu; aruts@excite.com; ben@layer8.net; jzwiebel@procket.com Cc: aruts@excite.com; pim@ietf.org Subject: Re: [pim] I Sorry, i have over looked.. It is possible when the MTU is more than 65565 bytes which is very possible in the case of OC interfaces. Rajamanickam jaganbabu wrote: Hi jzwiebel, Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol. I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message. Thanx, Jags wrote: Hi, IP actually does reassembly before it gives it to PIM and PIM receives the complete packet intact.I have seen it work! So, I don`t understand the need for a fragmentation flag! Thanks, Arut --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: From: Benjamin Black [mailto: ben@layer8.net] To: jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Date: Tue, 27 Jan 2004 19:54:05 -0800 Subject: Re: [pim] PIM BSM fragmentation put a slightly different way: PIM can generate a message larger than the maximum size for a single IP packet, so it must be able to reassemble things when a single PIM message is fragmented over multiple IP packets. ben On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > On Jan 27, 2004, at 5:16 PM, "" wrote: > >> >> I would like to know why fragmentation support (read fragmentation >> tag) is required at PIM level when IP is already doing it. >> > > Because if IP does it, it may not include all the source for a given > group within the same > packet. > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. ------_=_NextPart_001_01C3E5AF.52231CFA Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjEyNzYiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz0zMTg0NDU2MTQtMjgwMTIwMDQ+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5JZiB5b3UgDQpkcm9wIDEgSVAgZnJh Z21lbnQgb2YgdGhlIFJQIHNldCwgeW91IHdvdWxkIGxvc2UgdGhlIHdob2xlIFJQIHNldC4gSWYg eW91IGRyb3AgYSANCnNpbmdsZSBQSU0gZnJhZ21lbnQsIHlvdSBjYW4gc3RpbGwgcmVjb3ZlciB0 aGUgcmVzdCBvZiB0aGUgUlAgDQpzZXQuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9MzE4NDQ1NjE0LTI4MDEyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiAN CnNpemU9Mj4tY2djPC9GT05UPjwvU1BBTj48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5 bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJVj48L0RJVj4NCiAgPERJViBjbGFzcz1PdXRs b29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCANCiAg ZmFjZT1UYWhvbWEgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206 PC9CPiANCiAgcGltLWFkbWluQGlldGYub3JnIFttYWlsdG86cGltLWFkbWluQGlldGYub3JnXSA8 Qj5PbiBCZWhhbGYgT2YgDQogIDwvQj5SYWphbWFuaWNrYW0gamFnYW5iYWJ1PEJSPjxCPlNlbnQ6 PC9CPiBXZWRuZXNkYXksIEphbnVhcnkgMjgsIDIwMDQgNDowOSANCiAgQU08QlI+PEI+VG86PC9C PiBSYWphbWFuaWNrYW0gamFnYW5iYWJ1OyBhcnV0c0BleGNpdGUuY29tOyBiZW5AbGF5ZXI4Lm5l dDsgDQogIGp6d2llYmVsQHByb2NrZXQuY29tPEJSPjxCPkNjOjwvQj4gYXJ1dHNAZXhjaXRlLmNv bTsgDQogIHBpbUBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtwaW1dIEk8QlI+PEJS PjwvRk9OVD48L0RJVj4NCiAgPERJVj5Tb3JyeSwgaSBoYXZlIG92ZXIgbG9va2VkLi4gSXQgaXMg cG9zc2libGUgd2hlbiB0aGUgTVRVIGlzIG1vcmUgdGhhbiANCiAgNjU1NjUgYnl0ZXMgd2hpY2gg aXMgdmVyeSBwb3NzaWJsZSBpbiB0aGUgY2FzZSBvZiBPQyANCiAgaW50ZXJmYWNlcy48QlI+PEJS PjxCPjxJPlJhamFtYW5pY2thbSBqYWdhbmJhYnUgDQogICZsdDtqYWdhbmJhYnVfcGltQHlhaG9v LmNvLmluJmd0OzwvST48L0I+IHdyb3RlOiANCiAgPEJMT0NLUVVPVEUgY2xhc3M9cmVwbGJxIA0K ICBzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZU OiAjMTAxMGZmIDJweCBzb2xpZCI+DQogICAgPERJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPg0KICAgIDxESVY+SGkganp3aWViZWwsPC9ESVY+DQogICAgPERJVj4mbmJzcDsm bmJzcDsgQXJ1dHMgaXMgcmlnaHQsIElQIHdpbGwgdGFrZSBjYXJlIG9mIGZyYWdtZW50L2RlZnJh Z21lbnQgDQogICAgdGhlIHBhY2tldHMsIHNvIGkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byB0YWtl IGNhcmUgb2YgZnJhZ21lbnQvZGVmcmFnbWVudCBpbiANCiAgICB0aGUgYXBwbGljYXRpb24gbGV2 ZWwgKFBJTSBwcm90b2NvbCBsZXZlbCkuJm5ic3A7QnV0IEkgY2FuJ3QgaW1hZ2luZSB0aGUgDQog ICAgY2FzZSB3aGVyZSBteSBNVFUgaXMgbW9yZSB0aGFuIDY1NTY1IGJ5dGVzLCB3aGljaCBJUCBj YW4ndCBob2xkLiBJIHRoaW5rIGl0IA0KICAgIGlzIE9rIHRvIHJlbW92ZSB0aGUgZnJhZ21lbnRh dGlvbiBvdmVyaGVhZCBpbiB0aGUgUElNIHByb3RvY29sLjwvRElWPg0KICAgIDxESVY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEkgdGhpbmsgdGhpcyB3aWxsIGFwcGx5IGZvciBhbGwgdGhlIGZyYWdtZW50 YXRpb24gDQogICAgd2hpY2ggUElNIGlzIHN1cHBvcnRpbmcsIEZvciBleGFtcGxlIGV2ZW4gaW4g UElNIFNNIHdoaWxlIHNlbmRpbmcgdGhlIA0KICAgIFJlZ2lzdGVyIG1lc3NhZ2UuPC9ESVY+DQog ICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPlRoYW54LDwvRElWPg0KICAgIDxESVY+SmFn czxCUj48L0RJVj48L0ZPTlQ+PC9ESVY+PEJSPjxCPjxJPiZsdDthcnV0c0BleGNpdGUuY29tJmd0 OzwvST48L0I+IA0KICAgIHdyb3RlOjwvRElWPg0KICAgIDxCTE9DS1FVT1RFIGNsYXNzPXJlcGxi cSANCiAgICBzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRF Ui1MRUZUOiAjMTAxMGZmIDJweCBzb2xpZCI+PEJSPkhpLDxCUj48QlI+SVAgDQogICAgICBhY3R1 YWxseSBkb2VzIHJlYXNzZW1ibHkgYmVmb3JlIGl0IGdpdmVzIGl0IHRvIFBJTSBhbmQ8QlI+UElN IHJlY2VpdmVzIHRoZSANCiAgICAgIGNvbXBsZXRlIHBhY2tldCBpbnRhY3QuSSBoYXZlIHNlZW4g aXQgd29yayE8QlI+PEJSPlNvLCBJIGRvbmB0IHVuZGVyc3RhbmQgDQogICAgICB0aGUgbmVlZCBm b3IgYSBmcmFnbWVudGF0aW9uIA0KICAgICAgZmxhZyE8QlI+PEJSPlRoYW5rcyw8QlI+QXJ1dDxC Uj48QlI+PEJSPjxCUj48QlI+LS0tIE9uIFR1ZSAwMS8yNywgQmVuamFtaW4gDQogICAgICBCbGFj ayAmbHQ7IGJlbkBsYXllcjgubmV0ICZndDsgd3JvdGU6PEJSPkZyb206IEJlbmphbWluIEJsYWNr IFttYWlsdG86IA0KICAgICAgYmVuQGxheWVyOC5uZXRdPEJSPlRvOiBqendpZWJlbEBwcm9ja2V0 LmNvbTxCUj5DYzogYXJ1dHNAZXhjaXRlLmNvbSwgDQogICAgICBwaW1AaWV0Zi5vcmc8QlI+RGF0 ZTogVHVlLCAyNyBKYW4gMjAwNCAxOTo1NDowNSAtMDgwMDxCUj5TdWJqZWN0OiBSZTogDQogICAg ICBbcGltXSBQSU0gQlNNIGZyYWdtZW50YXRpb248QlI+PEJSPnB1dCBhIHNsaWdodGx5IGRpZmZl cmVudCANCiAgICAgIHdheTo8QlI+PEJSPlBJTSBjYW4gZ2VuZXJhdGUgYSBtZXNzYWdlIGxhcmdl ciB0aGFuIHRoZSBtYXhpbXVtIHNpemUgZm9yIGEgDQogICAgICBzaW5nbGUgSVAgPEJSPnBhY2tl dCwgc28gaXQgbXVzdCBiZSBhYmxlIHRvIHJlYXNzZW1ibGUgdGhpbmdzIHdoZW4gYSANCiAgICAg IHNpbmdsZSBQSU0gPEJSPm1lc3NhZ2UgaXMgZnJhZ21lbnRlZCBvdmVyIG11bHRpcGxlIElQIA0K ICAgICAgcGFja2V0cy48QlI+PEJSPjxCUj5iZW48QlI+PEJSPk9uIEphbiAyNywgMjAwNCwgYXQg NToyNSBQTSwgSm9obiBad2llYmVsIA0KICAgICAgd3JvdGU6PEJSPjxCUj4mZ3Q7PEJSPiZndDsg T24gSmFuIDI3LCAyMDA0LCBhdCA1OjE2IFBNLCAiIiANCiAgICAgIDxBUlVUU0BFWENJVEUuQ09N Pndyb3RlOjxCUj4mZ3Q7PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IEkgd291bGQgbGlrZSB0byAN CiAgICAgIGtub3cgd2h5IGZyYWdtZW50YXRpb24gc3VwcG9ydCAocmVhZCBmcmFnbWVudGF0aW9u IDxCUj4mZ3Q7Jmd0OyB0YWcpIGlzIA0KICAgICAgcmVxdWlyZWQgYXQgUElNIGxldmVsIHdoZW4g SVAgaXMgYWxyZWFkeSBkb2luZyANCiAgICAgIGl0LjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7PEJSPiZn dDsgQmVjYXVzZSBpZiBJUCBkb2VzIGl0LCBpdCBtYXkgbm90IGluY2x1ZGUgDQogICAgICBhbGwg dGhlIHNvdXJjZSBmb3IgYSBnaXZlbiA8QlI+Jmd0OyBncm91cCB3aXRoaW4gdGhlIHNhbWU8QlI+ Jmd0OyANCiAgICAgIHBhY2tldC48QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgDQogICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7IHBpbSBt YWlsaW5nIA0KICAgICAgbGlzdDxCUj4mZ3Q7IHBpbUBpZXRmLm9yZzxCUj4mZ3Q7IA0KICAgICAg aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGltPEJSPiZndDs8QlI+Jmd0 OzxCUj48QlI+PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxCUj5Kb2luIA0KICAgICAgRXhjaXRlISAtIGh0dHA6Ly93d3cuZXhjaXRlLmNvbTxC Uj5UaGUgbW9zdCBwZXJzb25hbGl6ZWQgcG9ydGFsIG9uIHRoZSANCiAgICAgIFdlYiE8QlI+PEJS Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPnBpbSBt YWlsaW5nIA0KICAgICAgbGlzdDxCUj5waW1AaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGltPC9CTE9DS1FVT1RFPg0KICAgIDxQPjxGT05UIGZhY2U9 YXJpYWwgc2l6ZT0tMT48QSBocmVmPSJodHRwOi8vaW4ubW9iaWxlLnlhaG9vLmNvbS8iIA0KICAg IHRhcmdldD1fYmxhbms+PEI+WWFob28hIEluZGlhIE1vYmlsZTwvQT46PC9CPiBSaW5ndG9uZXMs IFdhbGxwYXBlcnMsIFBpY3R1cmUgDQogICAgTWVzc2FnZXMgYW5kIG1vcmUuIDxGT05UIGZhY2U9 YXJpYWwgc2l6ZT0tMT5Eb3dubG9hZCA8QSANCiAgICBocmVmPSJodHRwOi8vaW4ubW9iaWxlLnlh aG9vLmNvbS8iIA0KICB0YXJnZXQ9X2JsYW5rPjxCPm5vdzwvQT48L0I+LjwvRk9OVD48L1A+PC9C TE9DS1FVT1RFPjwvRElWPjwvRk9OVD4NCiAgPFA+PEZPTlQgZmFjZT1hcmlhbCBzaXplPS0xPjxB IGhyZWY9Imh0dHA6Ly9pbi5tb2JpbGUueWFob28uY29tIiANCiAgdGFyZ2V0PV9ibGFuaz48Qj5Z YWhvbyEgSW5kaWEgTW9iaWxlPC9BPjo8L0I+IFJpbmd0b25lcywgV2FsbHBhcGVycywgUGljdHVy ZSANCiAgTWVzc2FnZXMgYW5kIG1vcmUuIDxGT05UIGZhY2U9YXJpYWwgc2l6ZT0tMT5Eb3dubG9h ZCA8QSANCiAgaHJlZj0iaHR0cDovL2luLm1vYmlsZS55YWhvby5jb20iIA0KICB0YXJnZXQ9X2Js YW5rPjxCPm5vdzwvQT48L0I+LjwvRk9OVD48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT48L0JPRFk+ PC9IVE1MPg0K ------_=_NextPart_001_01C3E5AF.52231CFA-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Jan 28 10:04:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03043 for ; Wed, 28 Jan 2004 10:04:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlrEE-0006rF-Ve for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 10:03:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SF3gUW026355 for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 10:03:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlrEE-0006r0-Q6 for pim-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 10:03:42 -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 KAA02999 for ; Wed, 28 Jan 2004 10:03:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlrEC-0000fU-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 10:03:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlrDF-0000ao-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 10:02:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlrCn-0000Vg-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 10:02:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlrCa-0005R0-Ug; Wed, 28 Jan 2004 10:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlrC9-00054q-RK for pim@optimus.ietf.org; Wed, 28 Jan 2004 10:01:34 -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 KAA02868 for ; Wed, 28 Jan 2004 10:01:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlrC7-0000Ue-00 for pim@ietf.org; Wed, 28 Jan 2004 10:01:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlrB8-0000QQ-00 for pim@ietf.org; Wed, 28 Jan 2004 10:00:31 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AlrAC-0000MT-00 for pim@ietf.org; Wed, 28 Jan 2004 09:59:36 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i0SExVqC004658 for ; Wed, 28 Jan 2004 07:59:31 -0700 (MST) Received: from il06exm10.corp.mot.com (il06exm10.corp.mot.com [10.0.111.10]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i0SEwBup025440 for ; Wed, 28 Jan 2004 08:58:11 -0600 Received: by il06exm10 with Internet Mail Service (5.5.2657.2) id ; Wed, 28 Jan 2004 08:59:29 -0600 Message-ID: From: Cormier Chris-ACC125 To: "'Rajamanickam jaganbabu'" , aruts@excite.com, ben@layer8.net, jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Subject: RE: [pim] I Date: Wed, 28 Jan 2004 08:59:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E5AF.52231CFA" Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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=2.2 required=5.0 tests=HTML_FONTCOLOR_BLUE, HTML_MESSAGE,HTML_TAG_BALANCE_BODY,MIME_BASE64_TEXT, MIME_HTML_NO_CHARSET autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E5AF.52231CFA Content-Type: text/plain If you drop 1 IP fragment of the RP set, you would lose the whole RP set. If you drop a single PIM fragment, you can still recover the rest of the RP set. -cgc -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org] On Behalf Of Rajamanickam jaganbabu Sent: Wednesday, January 28, 2004 4:09 AM To: Rajamanickam jaganbabu; aruts@excite.com; ben@layer8.net; jzwiebel@procket.com Cc: aruts@excite.com; pim@ietf.org Subject: Re: [pim] I Sorry, i have over looked.. It is possible when the MTU is more than 65565 bytes which is very possible in the case of OC interfaces. Rajamanickam jaganbabu wrote: Hi jzwiebel, Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol. I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message. Thanx, Jags wrote: Hi, IP actually does reassembly before it gives it to PIM and PIM receives the complete packet intact.I have seen it work! So, I don`t understand the need for a fragmentation flag! Thanks, Arut --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: From: Benjamin Black [mailto: ben@layer8.net] To: jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Date: Tue, 27 Jan 2004 19:54:05 -0800 Subject: Re: [pim] PIM BSM fragmentation put a slightly different way: PIM can generate a message larger than the maximum size for a single IP packet, so it must be able to reassemble things when a single PIM message is fragmented over multiple IP packets. ben On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > On Jan 27, 2004, at 5:16 PM, "" wrote: > >> >> I would like to know why fragmentation support (read fragmentation >> tag) is required at PIM level when IP is already doing it. >> > > Because if IP does it, it may not include all the source for a given > group within the same > packet. > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. ------_=_NextPart_001_01C3E5AF.52231CFA Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjEyNzYiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz0zMTg0NDU2MTQtMjgwMTIwMDQ+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5JZiB5b3UgDQpkcm9wIDEgSVAgZnJh Z21lbnQgb2YgdGhlIFJQIHNldCwgeW91IHdvdWxkIGxvc2UgdGhlIHdob2xlIFJQIHNldC4gSWYg eW91IGRyb3AgYSANCnNpbmdsZSBQSU0gZnJhZ21lbnQsIHlvdSBjYW4gc3RpbGwgcmVjb3ZlciB0 aGUgcmVzdCBvZiB0aGUgUlAgDQpzZXQuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9MzE4NDQ1NjE0LTI4MDEyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiAN CnNpemU9Mj4tY2djPC9GT05UPjwvU1BBTj48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5 bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJVj48L0RJVj4NCiAgPERJViBjbGFzcz1PdXRs b29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCANCiAg ZmFjZT1UYWhvbWEgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206 PC9CPiANCiAgcGltLWFkbWluQGlldGYub3JnIFttYWlsdG86cGltLWFkbWluQGlldGYub3JnXSA8 Qj5PbiBCZWhhbGYgT2YgDQogIDwvQj5SYWphbWFuaWNrYW0gamFnYW5iYWJ1PEJSPjxCPlNlbnQ6 PC9CPiBXZWRuZXNkYXksIEphbnVhcnkgMjgsIDIwMDQgNDowOSANCiAgQU08QlI+PEI+VG86PC9C PiBSYWphbWFuaWNrYW0gamFnYW5iYWJ1OyBhcnV0c0BleGNpdGUuY29tOyBiZW5AbGF5ZXI4Lm5l dDsgDQogIGp6d2llYmVsQHByb2NrZXQuY29tPEJSPjxCPkNjOjwvQj4gYXJ1dHNAZXhjaXRlLmNv bTsgDQogIHBpbUBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtwaW1dIEk8QlI+PEJS PjwvRk9OVD48L0RJVj4NCiAgPERJVj5Tb3JyeSwgaSBoYXZlIG92ZXIgbG9va2VkLi4gSXQgaXMg cG9zc2libGUgd2hlbiB0aGUgTVRVIGlzIG1vcmUgdGhhbiANCiAgNjU1NjUgYnl0ZXMgd2hpY2gg aXMgdmVyeSBwb3NzaWJsZSBpbiB0aGUgY2FzZSBvZiBPQyANCiAgaW50ZXJmYWNlcy48QlI+PEJS PjxCPjxJPlJhamFtYW5pY2thbSBqYWdhbmJhYnUgDQogICZsdDtqYWdhbmJhYnVfcGltQHlhaG9v LmNvLmluJmd0OzwvST48L0I+IHdyb3RlOiANCiAgPEJMT0NLUVVPVEUgY2xhc3M9cmVwbGJxIA0K ICBzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZU OiAjMTAxMGZmIDJweCBzb2xpZCI+DQogICAgPERJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPg0KICAgIDxESVY+SGkganp3aWViZWwsPC9ESVY+DQogICAgPERJVj4mbmJzcDsm bmJzcDsgQXJ1dHMgaXMgcmlnaHQsIElQIHdpbGwgdGFrZSBjYXJlIG9mIGZyYWdtZW50L2RlZnJh Z21lbnQgDQogICAgdGhlIHBhY2tldHMsIHNvIGkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byB0YWtl IGNhcmUgb2YgZnJhZ21lbnQvZGVmcmFnbWVudCBpbiANCiAgICB0aGUgYXBwbGljYXRpb24gbGV2 ZWwgKFBJTSBwcm90b2NvbCBsZXZlbCkuJm5ic3A7QnV0IEkgY2FuJ3QgaW1hZ2luZSB0aGUgDQog ICAgY2FzZSB3aGVyZSBteSBNVFUgaXMgbW9yZSB0aGFuIDY1NTY1IGJ5dGVzLCB3aGljaCBJUCBj YW4ndCBob2xkLiBJIHRoaW5rIGl0IA0KICAgIGlzIE9rIHRvIHJlbW92ZSB0aGUgZnJhZ21lbnRh dGlvbiBvdmVyaGVhZCBpbiB0aGUgUElNIHByb3RvY29sLjwvRElWPg0KICAgIDxESVY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEkgdGhpbmsgdGhpcyB3aWxsIGFwcGx5IGZvciBhbGwgdGhlIGZyYWdtZW50 YXRpb24gDQogICAgd2hpY2ggUElNIGlzIHN1cHBvcnRpbmcsIEZvciBleGFtcGxlIGV2ZW4gaW4g UElNIFNNIHdoaWxlIHNlbmRpbmcgdGhlIA0KICAgIFJlZ2lzdGVyIG1lc3NhZ2UuPC9ESVY+DQog ICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPlRoYW54LDwvRElWPg0KICAgIDxESVY+SmFn czxCUj48L0RJVj48L0ZPTlQ+PC9ESVY+PEJSPjxCPjxJPiZsdDthcnV0c0BleGNpdGUuY29tJmd0 OzwvST48L0I+IA0KICAgIHdyb3RlOjwvRElWPg0KICAgIDxCTE9DS1FVT1RFIGNsYXNzPXJlcGxi cSANCiAgICBzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRF Ui1MRUZUOiAjMTAxMGZmIDJweCBzb2xpZCI+PEJSPkhpLDxCUj48QlI+SVAgDQogICAgICBhY3R1 YWxseSBkb2VzIHJlYXNzZW1ibHkgYmVmb3JlIGl0IGdpdmVzIGl0IHRvIFBJTSBhbmQ8QlI+UElN IHJlY2VpdmVzIHRoZSANCiAgICAgIGNvbXBsZXRlIHBhY2tldCBpbnRhY3QuSSBoYXZlIHNlZW4g aXQgd29yayE8QlI+PEJSPlNvLCBJIGRvbmB0IHVuZGVyc3RhbmQgDQogICAgICB0aGUgbmVlZCBm b3IgYSBmcmFnbWVudGF0aW9uIA0KICAgICAgZmxhZyE8QlI+PEJSPlRoYW5rcyw8QlI+QXJ1dDxC Uj48QlI+PEJSPjxCUj48QlI+LS0tIE9uIFR1ZSAwMS8yNywgQmVuamFtaW4gDQogICAgICBCbGFj ayAmbHQ7IGJlbkBsYXllcjgubmV0ICZndDsgd3JvdGU6PEJSPkZyb206IEJlbmphbWluIEJsYWNr IFttYWlsdG86IA0KICAgICAgYmVuQGxheWVyOC5uZXRdPEJSPlRvOiBqendpZWJlbEBwcm9ja2V0 LmNvbTxCUj5DYzogYXJ1dHNAZXhjaXRlLmNvbSwgDQogICAgICBwaW1AaWV0Zi5vcmc8QlI+RGF0 ZTogVHVlLCAyNyBKYW4gMjAwNCAxOTo1NDowNSAtMDgwMDxCUj5TdWJqZWN0OiBSZTogDQogICAg ICBbcGltXSBQSU0gQlNNIGZyYWdtZW50YXRpb248QlI+PEJSPnB1dCBhIHNsaWdodGx5IGRpZmZl cmVudCANCiAgICAgIHdheTo8QlI+PEJSPlBJTSBjYW4gZ2VuZXJhdGUgYSBtZXNzYWdlIGxhcmdl ciB0aGFuIHRoZSBtYXhpbXVtIHNpemUgZm9yIGEgDQogICAgICBzaW5nbGUgSVAgPEJSPnBhY2tl dCwgc28gaXQgbXVzdCBiZSBhYmxlIHRvIHJlYXNzZW1ibGUgdGhpbmdzIHdoZW4gYSANCiAgICAg IHNpbmdsZSBQSU0gPEJSPm1lc3NhZ2UgaXMgZnJhZ21lbnRlZCBvdmVyIG11bHRpcGxlIElQIA0K ICAgICAgcGFja2V0cy48QlI+PEJSPjxCUj5iZW48QlI+PEJSPk9uIEphbiAyNywgMjAwNCwgYXQg NToyNSBQTSwgSm9obiBad2llYmVsIA0KICAgICAgd3JvdGU6PEJSPjxCUj4mZ3Q7PEJSPiZndDsg T24gSmFuIDI3LCAyMDA0LCBhdCA1OjE2IFBNLCAiIiANCiAgICAgIDxBUlVUU0BFWENJVEUuQ09N Pndyb3RlOjxCUj4mZ3Q7PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IEkgd291bGQgbGlrZSB0byAN CiAgICAgIGtub3cgd2h5IGZyYWdtZW50YXRpb24gc3VwcG9ydCAocmVhZCBmcmFnbWVudGF0aW9u IDxCUj4mZ3Q7Jmd0OyB0YWcpIGlzIA0KICAgICAgcmVxdWlyZWQgYXQgUElNIGxldmVsIHdoZW4g SVAgaXMgYWxyZWFkeSBkb2luZyANCiAgICAgIGl0LjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7PEJSPiZn dDsgQmVjYXVzZSBpZiBJUCBkb2VzIGl0LCBpdCBtYXkgbm90IGluY2x1ZGUgDQogICAgICBhbGwg dGhlIHNvdXJjZSBmb3IgYSBnaXZlbiA8QlI+Jmd0OyBncm91cCB3aXRoaW4gdGhlIHNhbWU8QlI+ Jmd0OyANCiAgICAgIHBhY2tldC48QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgDQogICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7IHBpbSBt YWlsaW5nIA0KICAgICAgbGlzdDxCUj4mZ3Q7IHBpbUBpZXRmLm9yZzxCUj4mZ3Q7IA0KICAgICAg aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGltPEJSPiZndDs8QlI+Jmd0 OzxCUj48QlI+PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxCUj5Kb2luIA0KICAgICAgRXhjaXRlISAtIGh0dHA6Ly93d3cuZXhjaXRlLmNvbTxC Uj5UaGUgbW9zdCBwZXJzb25hbGl6ZWQgcG9ydGFsIG9uIHRoZSANCiAgICAgIFdlYiE8QlI+PEJS Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPnBpbSBt YWlsaW5nIA0KICAgICAgbGlzdDxCUj5waW1AaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGltPC9CTE9DS1FVT1RFPg0KICAgIDxQPjxGT05UIGZhY2U9 YXJpYWwgc2l6ZT0tMT48QSBocmVmPSJodHRwOi8vaW4ubW9iaWxlLnlhaG9vLmNvbS8iIA0KICAg IHRhcmdldD1fYmxhbms+PEI+WWFob28hIEluZGlhIE1vYmlsZTwvQT46PC9CPiBSaW5ndG9uZXMs IFdhbGxwYXBlcnMsIFBpY3R1cmUgDQogICAgTWVzc2FnZXMgYW5kIG1vcmUuIDxGT05UIGZhY2U9 YXJpYWwgc2l6ZT0tMT5Eb3dubG9hZCA8QSANCiAgICBocmVmPSJodHRwOi8vaW4ubW9iaWxlLnlh aG9vLmNvbS8iIA0KICB0YXJnZXQ9X2JsYW5rPjxCPm5vdzwvQT48L0I+LjwvRk9OVD48L1A+PC9C TE9DS1FVT1RFPjwvRElWPjwvRk9OVD4NCiAgPFA+PEZPTlQgZmFjZT1hcmlhbCBzaXplPS0xPjxB IGhyZWY9Imh0dHA6Ly9pbi5tb2JpbGUueWFob28uY29tIiANCiAgdGFyZ2V0PV9ibGFuaz48Qj5Z YWhvbyEgSW5kaWEgTW9iaWxlPC9BPjo8L0I+IFJpbmd0b25lcywgV2FsbHBhcGVycywgUGljdHVy ZSANCiAgTWVzc2FnZXMgYW5kIG1vcmUuIDxGT05UIGZhY2U9YXJpYWwgc2l6ZT0tMT5Eb3dubG9h ZCA8QSANCiAgaHJlZj0iaHR0cDovL2luLm1vYmlsZS55YWhvby5jb20iIA0KICB0YXJnZXQ9X2Js YW5rPjxCPm5vdzwvQT48L0I+LjwvRk9OVD48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT48L0JPRFk+ PC9IVE1MPg0K ------_=_NextPart_001_01C3E5AF.52231CFA-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Jan 28 10:48:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05329 for ; Wed, 28 Jan 2004 10:48:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alrv7-0004iL-74; Wed, 28 Jan 2004 10:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alrul-0004hk-I6 for pim@optimus.ietf.org; Wed, 28 Jan 2004 10:47: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 KAA05309 for ; Wed, 28 Jan 2004 10:47:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alrui-0004L7-00 for pim@ietf.org; Wed, 28 Jan 2004 10:47:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alrto-0004GZ-00 for pim@ietf.org; Wed, 28 Jan 2004 10:46:41 -0500 Received: from [203.197.140.35] (helo=fsnt.future.futsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Alrsz-000470-00 for pim@ietf.org; Wed, 28 Jan 2004 10:45:50 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Wed, 28 Jan 2004 19:49:27 +0530 Received: from girishkg (girishkg.future.futsoft.com [10.6.4.88]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i0SECwM21191; Wed , 28 Jan 2004 19:42:58 +0530 Reply-To: From: "girishkg" To: "'Rajamanickam jaganbabu'" , , , Cc: , Subject: RE: [pim] I Date: Wed, 28 Jan 2004 19:44:22 +0530 Message-ID: <003b01c3e5a9$07d773e0$5804060a@future.futsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C3E5D7.218FAFE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20040128113359.94758.qmail@web8201.mail.in.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,EXCUSE_16, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C3E5D7.218FAFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, I feel fragmentation in PIM is required in the case of sending a JP packet more than 65535 byte. This can happen when we are sending a (*,G) Join and S,G,Rpt prunes along with it. The SGRpt state machine expects all the sources (which need to be pruned for the shared path )along with (*,.G) Join in the same JP message. I think John Zwiebel meant this in his reply. Thanks Girish -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Rajamanickam jaganbabu Sent: Wednesday, 28 January 2004 5:04 PM To: aruts@excite.com; ben@layer8.net; jzwiebel@procket.com Cc: aruts@excite.com; pim@ietf.org Subject: Re: [pim] I Hi jzwiebel, Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol. I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message. Thanx, Jags wrote: Hi, IP actually does reassembly before it gives it to PIM and PIM receives the complete packet intact.I have seen it work! So, I don`t understand the need for a fragmentation flag! Thanks, Arut --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: From: Benjamin Black [mailto: ben@layer8.net] To: jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Date: Tue, 27 Jan 2004 19:54:05 -0800 Subject: Re: [pim] PIM BSM fragmentation put a slightly different way: PIM can generate a message larger than the maximum size for a single IP packet, so it must be able to reassemble things when a single PIM message is fragmented over multiple IP packets. ben On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > On Jan 27, 2004, at 5:16 PM, "" wrote: > >> >> I would like to know why fragmentation support (read fragmentation >> tag) is required at PIM level when IP is already doing it. >> > > Because if IP does it, it may not include all the source for a given > group within the same > packet. > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_003C_01C3E5D7.218FAFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi=20 All,
I feel=20 fragmentation in PIM is required in the case of sending a JP packet more th= an=20 65535 byte. This can happen when we are sending a (*,G) Join and S,G,Rpt pr= unes=20 along with it. The SGRpt state machine expects all the sources (which need = to be=20 pruned for the shared path )along with (*,.G) Join in the same JP=20 message.
 
I=20 think John Zwiebel meant this in his reply.
 
Thanks
Girish
 
-----Original Message-----
From: pim-admin@ietf.org=20 [mailto:pim-admin@ietf.org]On Behalf Of Rajamanickam=20 jaganbabu
Sent: Wednesday, 28 January 2004 5:04 PM
To:=20 aruts@excite.com; ben@layer8.net; jzwiebel@procket.com
Cc:=20 aruts@excite.com; pim@ietf.org
Subject: Re: [pim= ]=20 I

Hi jzwiebel,
   Aruts is right, IP will take care of fragment/defragmen= t the=20 packets, so i don't think we need to take care of fragment/defragment in = the=20 application level (PIM protocol level). But I can't imagine the case= where my MTU is more than 65565 bytes, which IP can't hold. I think it i= s Ok=20 to remove the fragmentation overhead in the PIM protocol.
    I think this will apply for all the fragmentation= which PIM is supporting, For example even in PIM SM while sending the Re= gister=20 message.
 
Thanx,
Jags

<aruts@excite.com>=20 wrote:

Hi,

IP=20 actually does reassembly before it gives it to PIM and
PIM receives = the=20 complete packet intact.I have seen it work!

So, I don`t understa= nd=20 the need for a fragmentation=20 flag!

Thanks,
Arut




--- On Tue 01/27, Benja= min=20 Black < ben@layer8.net > wrote:
From: Benjamin Black [mailto:= ben@layer8.net]
To: jzwiebel@procket.com
Cc: aruts@excite.com,= pim@ietf.org
Date: Tue, 27 Jan 2004 19:54:05 -0800
Subject: Re: = [pim]=20 PIM BSM fragmentation

put a slightly different way:

PIM c= an=20 generate a message larger than the maximum size for a single IP
pac= ket,=20 so it must be able to reassemble things when a single PIM
message i= s=20 fragmented over multiple IP packets.


ben

On Jan 27, 2= 004,=20 at 5:25 PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at= 5:16=20 PM, "" wrote:
>
>>
>> I would= like=20 to know why fragmentation support (read fragmentation
>> tag)= is=20 required at PIM level when IP is already doing=20 it.
>>
>
> Because if IP does it, it may not inclu= de=20 all the source for a given
> group within the same
>=20 packet.
>
>
>=20 _______________________________________________
> pim mailing=20 list
> pim@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/pim
>
>


<= BR>_______________________________________________
Join=20 Excite! - http://www.excite.com
The most personalized portal on the= Web!

_______________________________________________
pim mai= ling=20 list
pim@ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Yahoo! India Mobile: Ringtones, Wallpapers, Pi= cture=20 Messages and more. Download now.



***************************************************************************=
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************=
------=_NextPart_000_003C_01C3E5D7.218FAFE0-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Jan 28 10:50:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05393 for ; Wed, 28 Jan 2004 10:50:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alrwg-0004oi-RY for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 10:49:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SFnctq018510 for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 10:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alrwg-0004oT-Je for pim-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 10:49:38 -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 KAA05385 for ; Wed, 28 Jan 2004 10:49:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alrwd-0004Us-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 10:49:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alrvj-0004Qa-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 10:48:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlrvG-0004M5-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 10:48:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alrv7-0004iL-74; Wed, 28 Jan 2004 10:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alrul-0004hk-I6 for pim@optimus.ietf.org; Wed, 28 Jan 2004 10:47: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 KAA05309 for ; Wed, 28 Jan 2004 10:47:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alrui-0004L7-00 for pim@ietf.org; Wed, 28 Jan 2004 10:47:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alrto-0004GZ-00 for pim@ietf.org; Wed, 28 Jan 2004 10:46:41 -0500 Received: from [203.197.140.35] (helo=fsnt.future.futsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Alrsz-000470-00 for pim@ietf.org; Wed, 28 Jan 2004 10:45:50 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Wed, 28 Jan 2004 19:49:27 +0530 Received: from girishkg (girishkg.future.futsoft.com [10.6.4.88]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i0SECwM21191; Wed , 28 Jan 2004 19:42:58 +0530 Reply-To: From: "girishkg" To: "'Rajamanickam jaganbabu'" , , , Cc: , Subject: RE: [pim] I Date: Wed, 28 Jan 2004 19:44:22 +0530 Message-ID: <003b01c3e5a9$07d773e0$5804060a@future.futsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C3E5D7.218FAFE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20040128113359.94758.qmail@web8201.mail.in.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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.2 required=5.0 tests=AWL,EXCUSE_16, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C3E5D7.218FAFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, I feel fragmentation in PIM is required in the case of sending a JP packet more than 65535 byte. This can happen when we are sending a (*,G) Join and S,G,Rpt prunes along with it. The SGRpt state machine expects all the sources (which need to be pruned for the shared path )along with (*,.G) Join in the same JP message. I think John Zwiebel meant this in his reply. Thanks Girish -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Rajamanickam jaganbabu Sent: Wednesday, 28 January 2004 5:04 PM To: aruts@excite.com; ben@layer8.net; jzwiebel@procket.com Cc: aruts@excite.com; pim@ietf.org Subject: Re: [pim] I Hi jzwiebel, Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol. I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message. Thanx, Jags wrote: Hi, IP actually does reassembly before it gives it to PIM and PIM receives the complete packet intact.I have seen it work! So, I don`t understand the need for a fragmentation flag! Thanks, Arut --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: From: Benjamin Black [mailto: ben@layer8.net] To: jzwiebel@procket.com Cc: aruts@excite.com, pim@ietf.org Date: Tue, 27 Jan 2004 19:54:05 -0800 Subject: Re: [pim] PIM BSM fragmentation put a slightly different way: PIM can generate a message larger than the maximum size for a single IP packet, so it must be able to reassemble things when a single PIM message is fragmented over multiple IP packets. ben On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > On Jan 27, 2004, at 5:16 PM, "" wrote: > >> >> I would like to know why fragmentation support (read fragmentation >> tag) is required at PIM level when IP is already doing it. >> > > Because if IP does it, it may not include all the source for a given > group within the same > packet. > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_003C_01C3E5D7.218FAFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
I feel=20 fragmentation in PIM is required in the case of sending a JP packet more th= an=20 65535 byte. This can happen when we are sending a (*,G) Join and S,G,Rpt pr= unes=20 along with it. The SGRpt state machine expects all the sources (which need = to be=20 pruned for the shared path )along with (*,.G) Join in the same JP=20 message.
 
I=20 think John Zwiebel meant this in his reply.
 
Thanks
Girish
 
-----Original Message-----
From: pim-admin@ietf.org=20 [mailto:pim-admin@ietf.org]On Behalf Of Rajamanickam=20 jaganbabu
Sent: Wednesday, 28 January 2004 5:04 PM
To:=20 aruts@excite.com; ben@layer8.net; jzwiebel@procket.com
Cc:=20 aruts@excite.com; pim@ietf.org
Subject: Re: [pim= ]=20 I

Hi jzwiebel,
   Aruts is right, IP will take care of fragment/defragmen= t the=20 packets, so i don't think we need to take care of fragment/defragment in = the=20 application level (PIM protocol level). But I can't imagine the case= where my MTU is more than 65565 bytes, which IP can't hold. I think it i= s Ok=20 to remove the fragmentation overhead in the PIM protocol.
    I think this will apply for all the fragmentation= which PIM is supporting, For example even in PIM SM while sending the Re= gister=20 message.
 
Thanx,
Jags

<aruts@excite.com>=20 wrote:

Hi,

IP=20 actually does reassembly before it gives it to PIM and
PIM receives = the=20 complete packet intact.I have seen it work!

So, I don`t understa= nd=20 the need for a fragmentation=20 flag!

Thanks,
Arut




--- On Tue 01/27, Benja= min=20 Black < ben@layer8.net > wrote:
From: Benjamin Black [mailto:= ben@layer8.net]
To: jzwiebel@procket.com
Cc: aruts@excite.com,= pim@ietf.org
Date: Tue, 27 Jan 2004 19:54:05 -0800
Subject: Re: = [pim]=20 PIM BSM fragmentation

put a slightly different way:

PIM c= an=20 generate a message larger than the maximum size for a single IP
pac= ket,=20 so it must be able to reassemble things when a single PIM
message i= s=20 fragmented over multiple IP packets.


ben

On Jan 27, 2= 004,=20 at 5:25 PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at= 5:16=20 PM, "" wrote:
>
>>
>> I would= like=20 to know why fragmentation support (read fragmentation
>> tag)= is=20 required at PIM level when IP is already doing=20 it.
>>
>
> Because if IP does it, it may not inclu= de=20 all the source for a given
> group within the same
>=20 packet.
>
>
>=20 _______________________________________________
> pim mailing=20 list
> pim@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/pim
>
>


<= BR>_______________________________________________
Join=20 Excite! - http://www.excite.com
The most personalized portal on the= Web!

_______________________________________________
pim mai= ling=20 list
pim@ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Yahoo! India Mobile: Ringtones, Wallpapers, Pi= cture=20 Messages and more. Download now.



***************************************************************************=
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************=
------=_NextPart_000_003C_01C3E5D7.218FAFE0-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Jan 28 12:34:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15945 for ; Wed, 28 Jan 2004 12:34:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltZg-0007b1-P0; Wed, 28 Jan 2004 12:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltZS-0007al-I2 for pim@optimus.ietf.org; Wed, 28 Jan 2004 12:33: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 MAA15887 for ; Wed, 28 Jan 2004 12:33:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AltZR-0003vK-00 for pim@ietf.org; Wed, 28 Jan 2004 12:33:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AltYZ-0003qE-00 for pim@ietf.org; Wed, 28 Jan 2004 12:32:52 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AltY5-0003kM-00 for pim@ietf.org; Wed, 28 Jan 2004 12:32:21 -0500 Received: from [12.161.102.11] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 2150756; Wed, 28 Jan 2004 12:32:15 -0500 Date: Wed, 28 Jan 2004 12:32:21 -0500 Subject: Re: [pim] I Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: aruts@excite.com, ben@layer8.net, jzwiebel@procket.com, pim@ietf.org To: Rajamanickam jaganbabu From: Marshall Eubanks In-Reply-To: <20040128113359.94758.qmail@web8201.mail.in.yahoo.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.553) 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: quoted-printable Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I would never assume that fragmentation at the IP level is present on any network - many turn it off - and it also puts you into the router CPU, so it is much more likely to be dropped. So application layer fragmentation has a lot of advantages. It seems odd to have it there and not elsewhere, but I would not remove it. (It's a little late to change BSR now anyway.) Regards Marshall Eubanks On Wednesday, January 28, 2004, at 06:33 AM, Rajamanickam jaganbabu=20 wrote: > Hi jzwiebel, > =A0=A0 Aruts is right, IP will take care of fragment/defragment the=20 > packets, so i don't think we need to take care of fragment/defragment=20= > in the application level (PIM protocol level).=A0But I can't imagine = the=20 > case where my MTU is more than 65565 bytes, which IP can't hold. I=20 > think it is Ok to remove the fragmentation overhead in the PIM=20 > protocol. > =A0=A0=A0 I think this will apply for all the fragmentation which PIM = is=20 > supporting, For example even in PIM SM while sending the Register=20 > message. > =A0 > Thanx, > Jags > > wrote: > > > Hi, > > IP actually does reassembly before it gives it to PIM and > PIM receives the complete packet intact.I have seen it work! > > So, I don`t understand the need for a fragmentation flag! > > Thanks, > Arut > > > > > --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: > From: Benjamin Black [mailto: ben@layer8.net] > To: jzwiebel@procket.com > Cc: aruts@excite.com, pim@ietf.org > Date: Tue, 27 Jan 2004 19:54:05 -0800 > Subject: Re: [pim] PIM BSM fragmentation > > put a slightly different way: > > PIM can generate a message larger than the maximum size for a single = IP > packet, so it must be able to reassemble things when a single PIM > message is fragmented over multiple IP packets. > > > ben > > On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > > > > On Jan 27, 2004, at 5:16 PM, "" wrote: > > > >> > >> I would like to know why fragmentation support (read fragmentation > >> tag) is required at PIM level when IP is already doing it. > >> > > > > Because if IP does it, it may not include all the source for a given > > group within the same > > packet. > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www1.ietf.org/mailman/listinfo/pim > > > > > > > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.=20= > Download now. > > T.M. Eubanks e-mail : marshall.eubanks@telesuite.com http://www.telesuite.com _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Jan 28 12:36:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16018 for ; Wed, 28 Jan 2004 12:36:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltbQ-0007nZ-BH for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 12:35:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SHZm3w029977 for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 12:35:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltbQ-0007nQ-6O for pim-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 12:35: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 MAA16011 for ; Wed, 28 Jan 2004 12:35:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AltbO-00048k-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 12:35:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AltaZ-00043P-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 12:34:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alta7-0003xT-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 12:34:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltZg-0007b1-P0; Wed, 28 Jan 2004 12:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltZS-0007al-I2 for pim@optimus.ietf.org; Wed, 28 Jan 2004 12:33: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 MAA15887 for ; Wed, 28 Jan 2004 12:33:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AltZR-0003vK-00 for pim@ietf.org; Wed, 28 Jan 2004 12:33:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AltYZ-0003qE-00 for pim@ietf.org; Wed, 28 Jan 2004 12:32:52 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AltY5-0003kM-00 for pim@ietf.org; Wed, 28 Jan 2004 12:32:21 -0500 Received: from [12.161.102.11] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 2150756; Wed, 28 Jan 2004 12:32:15 -0500 Date: Wed, 28 Jan 2004 12:32:21 -0500 Subject: Re: [pim] I Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: aruts@excite.com, ben@layer8.net, jzwiebel@procket.com, pim@ietf.org To: Rajamanickam jaganbabu From: Marshall Eubanks In-Reply-To: <20040128113359.94758.qmail@web8201.mail.in.yahoo.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: quoted-printable Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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: quoted-printable Content-Transfer-Encoding: quoted-printable I would never assume that fragmentation at the IP level is present on any network - many turn it off - and it also puts you into the router CPU, so it is much more likely to be dropped. So application layer fragmentation has a lot of advantages. It seems odd to have it there and not elsewhere, but I would not remove it. (It's a little late to change BSR now anyway.) Regards Marshall Eubanks On Wednesday, January 28, 2004, at 06:33 AM, Rajamanickam jaganbabu=20 wrote: > Hi jzwiebel, > =A0=A0 Aruts is right, IP will take care of fragment/defragment the=20 > packets, so i don't think we need to take care of fragment/defragment=20= > in the application level (PIM protocol level).=A0But I can't imagine = the=20 > case where my MTU is more than 65565 bytes, which IP can't hold. I=20 > think it is Ok to remove the fragmentation overhead in the PIM=20 > protocol. > =A0=A0=A0 I think this will apply for all the fragmentation which PIM = is=20 > supporting, For example even in PIM SM while sending the Register=20 > message. > =A0 > Thanx, > Jags > > wrote: > > > Hi, > > IP actually does reassembly before it gives it to PIM and > PIM receives the complete packet intact.I have seen it work! > > So, I don`t understand the need for a fragmentation flag! > > Thanks, > Arut > > > > > --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: > From: Benjamin Black [mailto: ben@layer8.net] > To: jzwiebel@procket.com > Cc: aruts@excite.com, pim@ietf.org > Date: Tue, 27 Jan 2004 19:54:05 -0800 > Subject: Re: [pim] PIM BSM fragmentation > > put a slightly different way: > > PIM can generate a message larger than the maximum size for a single = IP > packet, so it must be able to reassemble things when a single PIM > message is fragmented over multiple IP packets. > > > ben > > On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > > > > On Jan 27, 2004, at 5:16 PM, "" wrote: > > > >> > >> I would like to know why fragmentation support (read fragmentation > >> tag) is required at PIM level when IP is already doing it. > >> > > > > Because if IP does it, it may not include all the source for a given > > group within the same > > packet. > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www1.ietf.org/mailman/listinfo/pim > > > > > > > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.=20= > Download now. > > T.M. Eubanks e-mail : marshall.eubanks@telesuite.com http://www.telesuite.com _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Jan 28 12:54:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16980 for ; Wed, 28 Jan 2004 12:54:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Altt3-0001PY-7w; Wed, 28 Jan 2004 12: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 1Altsg-0001Mr-DZ for pim@optimus.ietf.org; Wed, 28 Jan 2004 12:53:38 -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 MAA16931 for ; Wed, 28 Jan 2004 12:53:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Altse-0005wl-00 for pim@ietf.org; Wed, 28 Jan 2004 12:53:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Altrg-0005rR-00 for pim@ietf.org; Wed, 28 Jan 2004 12:52:37 -0500 Received: from pollen.cs.concordia.ca ([132.205.44.61] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Altqg-0005ic-00 for pim@ietf.org; Wed, 28 Jan 2004 12:51:34 -0500 Received: from cs.concordia.ca (bill@cedar [132.205.44.76]) by pollen.cs.concordia.ca (8.12.10+Sun/8.12.10) with ESMTP id i0SHlOc9011865; Wed, 28 Jan 2004 12:47:27 -0500 (EST) Message-ID: <4017F5AB.3040609@cs.concordia.ca> Date: Wed, 28 Jan 2004 12:47:23 -0500 From: William Atwood Organization: Concordia University - Department of Computer Science User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: girishkg@future.futsoft.com CC: "'Rajamanickam jaganbabu'" , aruts@excite.com, ben@layer8.net, jzwiebel@procket.com, pim@ietf.org Subject: Re: [pim] I References: <003b01c3e5a9$07d773e0$5804060a@future.futsoft.com> In-Reply-To: <003b01c3e5a9$07d773e0$5804060a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit What is (perhaps) more to the point--- If a PIM implementation has something to send, and it sends it to IP as a (say) 30000-byte object, then this will be cut up into (approximately) 1500-byte pieces by IP. These 20 pieces will be sent on the medium. If _any_one_ of them gets lost, the only possible recovery action is to send the entire 30000 bytes again. If a PIM implementation discovers the actual MTU of the path (there is an RFC on how to do this, I don't remember the number), and does its own fragmentation to reduce the size of the objects given to IP so that they match the capabilities of the media on the path, then PIM can recover from individual packets being lost, rather than from 30000-byte objects being lost. Two additional points: 1) If the probability of losing one fragment is 1%, the probability of losing at least one of 20 fragments is 20%. These are not very good odds... It is much better to resend one or two 1500-byte pieces than to resend a 30000-byte piece (which itself would have a 20% probability of being lost). 2) For IPv6, fragmentation is (in general) forbidden; the protocol above IP (PIM, in this case) is _required_ to discover the Path MTU, and reduce the size of the objects it sends. The same should be done for IPv4, as much as possible. The overall conclusions are: 1) a fragmentation bit is clearly necessary, and 2) even if the Path MTU cannot be discovered, no PIM implementation should ever send objects larger than (1500 bytes minus the various protocol headers). Bill Atwood girishkg wrote: > Hi All, > I feel fragmentation in PIM is required in the case of sending a JP > packet more than 65535 byte. This can happen when we are sending a (*,G) > Join and S,G,Rpt prunes along with it. The SGRpt state machine expects > all the sources (which need to be pruned for the shared path )along with > (*,.G) Join in the same JP message. > > I think John Zwiebel meant this in his reply. > > Thanks > Girish > > > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of > Rajamanickam jaganbabu > Sent: Wednesday, 28 January 2004 5:04 PM > To: aruts@excite.com; ben@layer8.net; jzwiebel@procket.com > Cc: aruts@excite.com; pim@ietf.org > Subject: Re: [pim] I > > Hi jzwiebel, > Aruts is right, IP will take care of fragment/defragment the > packets, so i don't think we need to take care of > fragment/defragment in the application level (PIM protocol > level). But I can't imagine the case where my MTU is more than 65565 > bytes, which IP can't hold. I think it is Ok to remove the > fragmentation overhead in the PIM protocol. > I think this will apply for all the fragmentation which PIM is > supporting, For example even in PIM SM while sending the Register > message. > > Thanx, > Jags > > wrote: > > > Hi, > > IP actually does reassembly before it gives it to PIM and > PIM receives the complete packet intact.I have seen it work! > > So, I don`t understand the need for a fragmentation flag! > > Thanks, > Arut > > > > > --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: > From: Benjamin Black [mailto: ben@layer8.net] > To: jzwiebel@procket.com > Cc: aruts@excite.com, pim@ietf.org > Date: Tue, 27 Jan 2004 19:54:05 -0800 > Subject: Re: [pim] PIM BSM fragmentation > > put a slightly different way: > > PIM can generate a message larger than the maximum size for a > single IP > packet, so it must be able to reassemble things when a single PIM > message is fragmented over multiple IP packets. > > > ben > > On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > > > > On Jan 27, 2004, at 5:16 PM, "" wrote: > > > >> > >> I would like to know why fragmentation support (read > fragmentation > >> tag) is required at PIM level when IP is already doing it. > >> > > > > Because if IP does it, it may not include all the source for > a given > > group within the same > > packet. > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www1.ietf.org/mailman/listinfo/pim > > > > > > > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > Yahoo! India Mobile : Ringtones, > Wallpapers, Picture Messages and more. Download now > . > > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** -- Dr. J.W. Atwood, Eng., Professor tel: +1 (514) 848-2424 x3046 Department of Computer Science fax: +1 (514) 848-2830 Concordia University LB927-9 email: bill@cs.Concordia.ca 1455 de Maisonneuve Blvd. West http://www.cs.Concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Jan 28 12:56:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17027 for ; Wed, 28 Jan 2004 12:56: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 1Altui-0001l2-H1 for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 12:55:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SHtioS006756 for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 12:55:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Altui-0001kt-8R for pim-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 12:55:44 -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 MAA17017 for ; Wed, 28 Jan 2004 12:55:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Altug-00068P-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 12:55:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alttk-00063a-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 12:54:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlttJ-0005yd-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 12:54:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Altt3-0001PY-7w; Wed, 28 Jan 2004 12: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 1Altsg-0001Mr-DZ for pim@optimus.ietf.org; Wed, 28 Jan 2004 12:53:38 -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 MAA16931 for ; Wed, 28 Jan 2004 12:53:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Altse-0005wl-00 for pim@ietf.org; Wed, 28 Jan 2004 12:53:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Altrg-0005rR-00 for pim@ietf.org; Wed, 28 Jan 2004 12:52:37 -0500 Received: from pollen.cs.concordia.ca ([132.205.44.61] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Altqg-0005ic-00 for pim@ietf.org; Wed, 28 Jan 2004 12:51:34 -0500 Received: from cs.concordia.ca (bill@cedar [132.205.44.76]) by pollen.cs.concordia.ca (8.12.10+Sun/8.12.10) with ESMTP id i0SHlOc9011865; Wed, 28 Jan 2004 12:47:27 -0500 (EST) Message-ID: <4017F5AB.3040609@cs.concordia.ca> Date: Wed, 28 Jan 2004 12:47:23 -0500 From: William Atwood Organization: Concordia University - Department of Computer Science User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: girishkg@future.futsoft.com CC: "'Rajamanickam jaganbabu'" , aruts@excite.com, ben@layer8.net, jzwiebel@procket.com, pim@ietf.org Subject: Re: [pim] I References: <003b01c3e5a9$07d773e0$5804060a@future.futsoft.com> In-Reply-To: <003b01c3e5a9$07d773e0$5804060a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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.2 required=5.0 tests=EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit What is (perhaps) more to the point--- If a PIM implementation has something to send, and it sends it to IP as a (say) 30000-byte object, then this will be cut up into (approximately) 1500-byte pieces by IP. These 20 pieces will be sent on the medium. If _any_one_ of them gets lost, the only possible recovery action is to send the entire 30000 bytes again. If a PIM implementation discovers the actual MTU of the path (there is an RFC on how to do this, I don't remember the number), and does its own fragmentation to reduce the size of the objects given to IP so that they match the capabilities of the media on the path, then PIM can recover from individual packets being lost, rather than from 30000-byte objects being lost. Two additional points: 1) If the probability of losing one fragment is 1%, the probability of losing at least one of 20 fragments is 20%. These are not very good odds... It is much better to resend one or two 1500-byte pieces than to resend a 30000-byte piece (which itself would have a 20% probability of being lost). 2) For IPv6, fragmentation is (in general) forbidden; the protocol above IP (PIM, in this case) is _required_ to discover the Path MTU, and reduce the size of the objects it sends. The same should be done for IPv4, as much as possible. The overall conclusions are: 1) a fragmentation bit is clearly necessary, and 2) even if the Path MTU cannot be discovered, no PIM implementation should ever send objects larger than (1500 bytes minus the various protocol headers). Bill Atwood girishkg wrote: > Hi All, > I feel fragmentation in PIM is required in the case of sending a JP > packet more than 65535 byte. This can happen when we are sending a (*,G) > Join and S,G,Rpt prunes along with it. The SGRpt state machine expects > all the sources (which need to be pruned for the shared path )along with > (*,.G) Join in the same JP message. > > I think John Zwiebel meant this in his reply. > > Thanks > Girish > > > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of > Rajamanickam jaganbabu > Sent: Wednesday, 28 January 2004 5:04 PM > To: aruts@excite.com; ben@layer8.net; jzwiebel@procket.com > Cc: aruts@excite.com; pim@ietf.org > Subject: Re: [pim] I > > Hi jzwiebel, > Aruts is right, IP will take care of fragment/defragment the > packets, so i don't think we need to take care of > fragment/defragment in the application level (PIM protocol > level). But I can't imagine the case where my MTU is more than 65565 > bytes, which IP can't hold. I think it is Ok to remove the > fragmentation overhead in the PIM protocol. > I think this will apply for all the fragmentation which PIM is > supporting, For example even in PIM SM while sending the Register > message. > > Thanx, > Jags > > wrote: > > > Hi, > > IP actually does reassembly before it gives it to PIM and > PIM receives the complete packet intact.I have seen it work! > > So, I don`t understand the need for a fragmentation flag! > > Thanks, > Arut > > > > > --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: > From: Benjamin Black [mailto: ben@layer8.net] > To: jzwiebel@procket.com > Cc: aruts@excite.com, pim@ietf.org > Date: Tue, 27 Jan 2004 19:54:05 -0800 > Subject: Re: [pim] PIM BSM fragmentation > > put a slightly different way: > > PIM can generate a message larger than the maximum size for a > single IP > packet, so it must be able to reassemble things when a single PIM > message is fragmented over multiple IP packets. > > > ben > > On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > > > > On Jan 27, 2004, at 5:16 PM, "" wrote: > > > >> > >> I would like to know why fragmentation support (read > fragmentation > >> tag) is required at PIM level when IP is already doing it. > >> > > > > Because if IP does it, it may not include all the source for > a given > > group within the same > > packet. > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www1.ietf.org/mailman/listinfo/pim > > > > > > > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > > Yahoo! India Mobile : Ringtones, > Wallpapers, Picture Messages and more. Download now > . > > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** -- Dr. J.W. Atwood, Eng., Professor tel: +1 (514) 848-2424 x3046 Department of Computer Science fax: +1 (514) 848-2830 Concordia University LB927-9 email: bill@cs.Concordia.ca 1455 de Maisonneuve Blvd. West http://www.cs.Concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Jan 28 14:38:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22628 for ; Wed, 28 Jan 2004 14:38:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlvVh-0001S7-Vv; Wed, 28 Jan 2004 14:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlvVd-0001Q2-D2 for pim@optimus.ietf.org; Wed, 28 Jan 2004 14:37:57 -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 OAA22593 for ; Wed, 28 Jan 2004 14:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlvVa-0001N3-00 for pim@ietf.org; Wed, 28 Jan 2004 14:37:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlvUb-0001HG-00 for pim@ietf.org; Wed, 28 Jan 2004 14:36:54 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AlvUG-0001BL-00 for pim@ietf.org; Wed, 28 Jan 2004 14:36:32 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 320F02D486C for ; Wed, 28 Jan 2004 14:36:02 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 58237-01-97 for ; Wed, 28 Jan 2004 14:36:01 -0500 (EST) Received: from nexthop.com (ctbrown.nexthop.com [65.247.36.75]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CF6002D487E for ; Wed, 28 Jan 2004 14:34:36 -0500 (EST) From: Christopher Thomas Brown To: pim@ietf.org Date: Wed, 28 Jan 2004 14:34:22 -0500 Message-Id: <20040128193436.CF6002D487E@aa-mx1.nexthop.com> X-Virus-Scanned: by amavisd-new at nexthop.com 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 Subject: [pim] PIM packet fragmentation Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , After reading much of this discussion, it seems many people are still confused on the subject of fragmentation. PIM calls for specialized fragmentation in only two places: register messages and bootstrap messages. In a register message, one includes an encapsulating IP header and a PIM header along with the IP data packet. This new header adds 28 bytes to the packet. It is possible for a multicast data packet to be upto 65535 bytes in length. Adding the 28 bytes to such a packet is not possible without fragmentation. The PIM specification provides for how such fragmentation should be done. In a bootstrap message, specialized fragmentation is performed for mainly for reasons others have specified. That it is better to lose a fragment for one group than to lose the whole message because one IP fragment is lost. Additionally, it is possible to generation a bootstrap message that is be larger than 65535 if one included enough group ranges. So the specialized fragmentation helps here as well. No other message includes any form of specialized fragmentation. However, for Join/Prune messages it is prudent for reasons already mentioned to send joins and prunes spread out over a number of messages so that IP fragmentation does not occur. Additionally, one is limited by the maximum packet size in the number of s,g,rpt prunes that can be included with a *,g join. Chris _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Jan 28 14:40:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22731 for ; Wed, 28 Jan 2004 14:40:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlvXZ-0001hp-6n for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 14:39:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SJdvaX006553 for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 14:39:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlvXZ-0001hc-35 for pim-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 14:39:57 -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 OAA22705 for ; Wed, 28 Jan 2004 14:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlvXW-0001bd-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 14:39:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlvWb-0001Uk-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 14:38:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlvVv-0001OA-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 14:38:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlvVh-0001S7-Vv; Wed, 28 Jan 2004 14:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlvVd-0001Q2-D2 for pim@optimus.ietf.org; Wed, 28 Jan 2004 14:37:57 -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 OAA22593 for ; Wed, 28 Jan 2004 14:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlvVa-0001N3-00 for pim@ietf.org; Wed, 28 Jan 2004 14:37:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlvUb-0001HG-00 for pim@ietf.org; Wed, 28 Jan 2004 14:36:54 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AlvUG-0001BL-00 for pim@ietf.org; Wed, 28 Jan 2004 14:36:32 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 320F02D486C for ; Wed, 28 Jan 2004 14:36:02 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 58237-01-97 for ; Wed, 28 Jan 2004 14:36:01 -0500 (EST) Received: from nexthop.com (ctbrown.nexthop.com [65.247.36.75]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CF6002D487E for ; Wed, 28 Jan 2004 14:34:36 -0500 (EST) From: Christopher Thomas Brown To: pim@ietf.org Date: Wed, 28 Jan 2004 14:34:22 -0500 Message-Id: <20040128193436.CF6002D487E@aa-mx1.nexthop.com> X-Virus-Scanned: by amavisd-new at nexthop.com Subject: [pim] PIM packet fragmentation Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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 After reading much of this discussion, it seems many people are still confused on the subject of fragmentation. PIM calls for specialized fragmentation in only two places: register messages and bootstrap messages. In a register message, one includes an encapsulating IP header and a PIM header along with the IP data packet. This new header adds 28 bytes to the packet. It is possible for a multicast data packet to be upto 65535 bytes in length. Adding the 28 bytes to such a packet is not possible without fragmentation. The PIM specification provides for how such fragmentation should be done. In a bootstrap message, specialized fragmentation is performed for mainly for reasons others have specified. That it is better to lose a fragment for one group than to lose the whole message because one IP fragment is lost. Additionally, it is possible to generation a bootstrap message that is be larger than 65535 if one included enough group ranges. So the specialized fragmentation helps here as well. No other message includes any form of specialized fragmentation. However, for Join/Prune messages it is prudent for reasons already mentioned to send joins and prunes spread out over a number of messages so that IP fragmentation does not occur. Additionally, one is limited by the maximum packet size in the number of s,g,rpt prunes that can be included with a *,g join. Chris _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Jan 28 20:21:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10537 for ; Wed, 28 Jan 2004 20:21:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0rc-00018g-RK; Wed, 28 Jan 2004 20:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0rW-00018T-2d for pim@optimus.ietf.org; Wed, 28 Jan 2004 20:20:59 -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 UAA10530 for ; Wed, 28 Jan 2004 20:20:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am0rT-0006Tl-00 for pim@ietf.org; Wed, 28 Jan 2004 20:20:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am0qZ-0006P3-00 for pim@ietf.org; Wed, 28 Jan 2004 20:19:56 -0500 Received: from nn7.excitenetwork.com ([207.159.120.61] helo=xprdmailfe10.nwk.excite.com) by ietf-mx with esmtp (Exim 4.12) id 1Am0q7-0006KB-00 for pim@ietf.org; Wed, 28 Jan 2004 20:19:27 -0500 Received: by xprdmailfe10.nwk.excite.com (Postfix, from userid 110) id A28033D28; Wed, 28 Jan 2004 20:18:56 -0500 (EST) To: bill@cs.concordia.ca, girishkg@future.futsoft.com Subject: Re: [pim] I Received: from [203.180.124.14] by xprdmailfe10.nwk.excite.com via HTTP; Wed, 28 Jan 2004 20:18:56 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ab0ec0e5e86bd0b0eae8fc3eaff26398 Reply-To: aruts@excite.com From: "" MIME-Version: 1.0 X-Sender: aruts@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: jaganbabu_pim@yahoo.co.in, aruts@excite.com, ben@layer8.net, jzwiebel@procket.com, pim@ietf.org Message-Id: <20040129011856.A28033D28@xprdmailfe10.nwk.excite.com> Date: Wed, 28 Jan 2004 20:18:56 -0500 (EST) 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,EXCUSE_16,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks Bill and everybody else! Probably, the same argument holds good for a JOIN/PRUNE message.It doesn`t have any fragmentation tag? Arut --- On Wed 01/28, William Atwood < bill@cs.concordia.ca > wrote: From: William Atwood [mailto: bill@cs.concordia.ca] To: girishkg@future.futsoft.com Cc: jaganbabu_pim@yahoo.co.in, aruts@excite.com, ben@layer8.net, jzwiebel@procket.com, pim@ietf.org Date: Wed, 28 Jan 2004 12:47:23 -0500 Subject: Re: [pim] I What is (perhaps) more to the point---

If a PIM implementation has something to send, and it sends it to IP as
a (say) 30000-byte object, then this will be cut up into (approximately)
1500-byte pieces by IP. These 20 pieces will be sent on the medium. If
_any_one_ of them gets lost, the only possible recovery action is to
send the entire 30000 bytes again.

If a PIM implementation discovers the actual MTU of the path (there is
an RFC on how to do this, I don't remember the number), and does its own
fragmentation to reduce the size of the objects given to IP so that they
match the capabilities of the media on the path, then PIM can recover
from individual packets being lost, rather than from 30000-byte objects
being lost.

Two additional points:
1) If the probability of losing one fragment is 1%, the probability of
losing at least one of 20 fragments is 20%. These are not very good
odds... It is much better! to resend one or two 1500-byte pieces than to
resend a 30000-byte piece (which itself would have a 20% probability of
being lost).
2) For IPv6, fragmentation is (in general) forbidden; the protocol above
IP (PIM, in this case) is _required_ to discover the Path MTU, and
reduce the size of the objects it sends. The same should be done for
IPv4, as much as possible.

The overall conclusions are:
1) a fragmentation bit is clearly necessary, and
2) even if the Path MTU cannot be discovered, no PIM implementation
should ever send objects larger than (1500 bytes minus the various
protocol headers).

Bill Atwood

girishkg wrote:
> Hi All,
> I feel fragmentation in PIM is required in the case of sending a JP
> packet more than 65535 byte. This can happen when we are sending a (*,G)
> Join and S,G,Rpt prunes along with it. The SGRpt state machine expects
> all the sources (which need to be pruned for the s! hared path )along with
> (*,.G) Join in the same JP message.
>
> I think John Zwiebel meant this in his reply.
>
> Thanks
> Girish
>
>
> -----Original Message-----
> From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of
> Rajamanickam jaganbabu
> Sent: Wednesday, 28 January 2004 5:04 PM
> To: aruts@excite.com; ben@layer8.net; jzwiebel@procket.com
> Cc: aruts@excite.com; pim@ietf.org
> Subject: Re: [pim] I
>
> Hi jzwiebel,
> Aruts is right, IP will take care of fragment/defragment the
> packets, so i don't think we need to take care of
> fragment/defragment in the application level (PIM protocol
> level). But I can't imagine the case where my MTU is more than 65565
> bytes, which IP can't hold. I think it is Ok to remove the
> fragmentation overhead in the PIM protocol.
> I think this will apply for all the fragmentation which PIM is
> supporting, For example ! even in PIM SM while sending the Register
> message.
>
> Thanx,
> Jags
>
> wrote:
>
>
> Hi,
>
> IP actually does reassembly before it gives it to PIM and
> PIM receives the complete packet intact.I have seen it work!
>
> So, I don`t understand the need for a fragmentation flag!
>
> Thanks,
> Arut
>
>
>
>
> --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote:
> From: Benjamin Black [mailto: ben@layer8.net]
> To: jzwiebel@procket.com
> Cc: aruts@excite.com, pim@ietf.org
> Date: Tue, 27 Jan 2004 19:54:05 -0800
> Subject: Re: [pim] PIM BSM fragmentation
>
> put a slightly different way:
>
> PIM can generate a message larger than the maximum size for a
> single IP
> packet, so it must be able to re! assemble things when a single PIM
> message is fragmented o ve r multiple IP packets.
>
>
> ben
>
> On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote:
>
> >
> > On Jan 27, 2004, at 5:16 PM, "" wrote:
> >
> >>
> >> I would like to know why fragmentation support (read
> fragmentation
> >> tag) is required at PIM level when IP is already doing it.
> >>
> >
> > Because if IP does it, it may not include all the source for
> a given
> > group within the same
> > packet.
> >
> >
> > _______________________________________________
> > pim mailing list
> > pim@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pim
> >
> >
>
>
>
> _______________________________________________
> Join Excite! - http://www.excite.com
> T! he most personalized portal on the Web!
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www1.ietf.org/mailman/listinfo/pim
>
> Yahoo! India Mobile : Ringtones,
> Wallpapers, Picture Messages and more. Download now
> .
>
>
>
> ***************************************************************************
> This message is proprietary to Future Software Limited (FSL)
> and is intended solely for the use of the individual to whom it
> is addressed. It may contain privileged or confidential information
> and should not be circulated or used for any purpose other than for
> what it is intended.
>
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient,
> you are notified that you are strictly pr! ohibited from using,
> copying, altering, or disclosing the content s of this message.
> FSL accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including
> damage from virus.
> ***************************************************************************

--

Dr. J.W. Atwood, Eng., Professor tel: +1 (514) 848-2424 x3046
Department of Computer Science fax: +1 (514) 848-2830
Concordia University LB927-9 email: bill@cs.Concordia.ca
1455 de Maisonneuve Blvd. West http://www.cs.Concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

_______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Jan 28 20:23:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10615 for ; Wed, 28 Jan 2004 20:23:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0tS-0001I4-UA for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 20:22:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T1MsUY004956 for pim-archive@odin.ietf.org; Wed, 28 Jan 2004 20:22:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0tS-0001Hr-NI for pim-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 20:22:54 -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 UAA10597 for ; Wed, 28 Jan 2004 20:22:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am0tQ-0006fm-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 20:22:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am0sX-0006aY-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 20:21:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Am0ro-0006VI-00 for pim-web-archive@ietf.org; Wed, 28 Jan 2004 20:21:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0rc-00018g-RK; Wed, 28 Jan 2004 20:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0rW-00018T-2d for pim@optimus.ietf.org; Wed, 28 Jan 2004 20:20:59 -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 UAA10530 for ; Wed, 28 Jan 2004 20:20:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am0rT-0006Tl-00 for pim@ietf.org; Wed, 28 Jan 2004 20:20:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am0qZ-0006P3-00 for pim@ietf.org; Wed, 28 Jan 2004 20:19:56 -0500 Received: from nn7.excitenetwork.com ([207.159.120.61] helo=xprdmailfe10.nwk.excite.com) by ietf-mx with esmtp (Exim 4.12) id 1Am0q7-0006KB-00 for pim@ietf.org; Wed, 28 Jan 2004 20:19:27 -0500 Received: by xprdmailfe10.nwk.excite.com (Postfix, from userid 110) id A28033D28; Wed, 28 Jan 2004 20:18:56 -0500 (EST) To: bill@cs.concordia.ca, girishkg@future.futsoft.com Subject: Re: [pim] I Received: from [203.180.124.14] by xprdmailfe10.nwk.excite.com via HTTP; Wed, 28 Jan 2004 20:18:56 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ab0ec0e5e86bd0b0eae8fc3eaff26398 Reply-To: aruts@excite.com From: "" MIME-Version: 1.0 X-Sender: aruts@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: jaganbabu_pim@yahoo.co.in, aruts@excite.com, ben@layer8.net, jzwiebel@procket.com, pim@ietf.org Message-Id: <20040129011856.A28033D28@xprdmailfe10.nwk.excite.com> Date: Wed, 28 Jan 2004 20:18:56 -0500 (EST) Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast 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,EXCUSE_16,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Bill and everybody else! Probably, the same argument holds good for a JOIN/PRUNE message.It doesn`t have any fragmentation tag? Arut --- On Wed 01/28, William Atwood < bill@cs.concordia.ca > wrote: From: William Atwood [mailto: bill@cs.concordia.ca] To: girishkg@future.futsoft.com Cc: jaganbabu_pim@yahoo.co.in, aruts@excite.com, ben@layer8.net, jzwiebel@procket.com, pim@ietf.org Date: Wed, 28 Jan 2004 12:47:23 -0500 Subject: Re: [pim] I What is (perhaps) more to the point---

If a PIM implementation has something to send, and it sends it to IP as
a (say) 30000-byte object, then this will be cut up into (approximately)
1500-byte pieces by IP. These 20 pieces will be sent on the medium. If
_any_one_ of them gets lost, the only possible recovery action is to
send the entire 30000 bytes again.

If a PIM implementation discovers the actual MTU of the path (there is
an RFC on how to do this, I don't remember the number), and does its own
fragmentation to reduce the size of the objects given to IP so that they
match the capabilities of the media on the path, then PIM can recover
from individual packets being lost, rather than from 30000-byte objects
being lost.

Two additional points:
1) If the probability of losing one fragment is 1%, the probability of
losing at least one of 20 fragments is 20%. These are not very good
odds... It is much better! to resend one or two 1500-byte pieces than to
resend a 30000-byte piece (which itself would have a 20% probability of
being lost).
2) For IPv6, fragmentation is (in general) forbidden; the protocol above
IP (PIM, in this case) is _required_ to discover the Path MTU, and
reduce the size of the objects it sends. The same should be done for
IPv4, as much as possible.

The overall conclusions are:
1) a fragmentation bit is clearly necessary, and
2) even if the Path MTU cannot be discovered, no PIM implementation
should ever send objects larger than (1500 bytes minus the various
protocol headers).

Bill Atwood

girishkg wrote:
> Hi All,
> I feel fragmentation in PIM is required in the case of sending a JP
> packet more than 65535 byte. This can happen when we are sending a (*,G)
> Join and S,G,Rpt prunes along with it. The SGRpt state machine expects
> all the sources (which need to be pruned for the s! hared path )along with
> (*,.G) Join in the same JP message.
>
> I think John Zwiebel meant this in his reply.
>
> Thanks
> Girish
>
>
> -----Original Message-----
> From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of
> Rajamanickam jaganbabu
> Sent: Wednesday, 28 January 2004 5:04 PM
> To: aruts@excite.com; ben@layer8.net; jzwiebel@procket.com
> Cc: aruts@excite.com; pim@ietf.org
> Subject: Re: [pim] I
>
> Hi jzwiebel,
> Aruts is right, IP will take care of fragment/defragment the
> packets, so i don't think we need to take care of
> fragment/defragment in the application level (PIM protocol
> level). But I can't imagine the case where my MTU is more than 65565
> bytes, which IP can't hold. I think it is Ok to remove the
> fragmentation overhead in the PIM protocol.
> I think this will apply for all the fragmentation which PIM is
> supporting, For example ! even in PIM SM while sending the Register
> message.
>
> Thanx,
> Jags
>
> wrote:
>
>
> Hi,
>
> IP actually does reassembly before it gives it to PIM and
> PIM receives the complete packet intact.I have seen it work!
>
> So, I don`t understand the need for a fragmentation flag!
>
> Thanks,
> Arut
>
>
>
>
> --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote:
> From: Benjamin Black [mailto: ben@layer8.net]
> To: jzwiebel@procket.com
> Cc: aruts@excite.com, pim@ietf.org
> Date: Tue, 27 Jan 2004 19:54:05 -0800
> Subject: Re: [pim] PIM BSM fragmentation
>
> put a slightly different way:
>
> PIM can generate a message larger than the maximum size for a
> single IP
> packet, so it must be able to re! assemble things when a single PIM
> message is fragmented o ve r multiple IP packets.
>
>
> ben
>
> On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote:
>
> >
> > On Jan 27, 2004, at 5:16 PM, "" wrote:
> >
> >>
> >> I would like to know why fragmentation support (read
> fragmentation
> >> tag) is required at PIM level when IP is already doing it.
> >>
> >
> > Because if IP does it, it may not include all the source for
> a given
> > group within the same
> > packet.
> >
> >
> > _______________________________________________
> > pim mailing list
> > pim@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pim
> >
> >
>
>
>
> _______________________________________________
> Join Excite! - http://www.excite.com
> T! he most personalized portal on the Web!
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www1.ietf.org/mailman/listinfo/pim
>
> Yahoo! India Mobile : Ringtones,
> Wallpapers, Picture Messages and more. Download now
> .
>
>
>
> ***************************************************************************
> This message is proprietary to Future Software Limited (FSL)
> and is intended solely for the use of the individual to whom it
> is addressed. It may contain privileged or confidential information
> and should not be circulated or used for any purpose other than for
> what it is intended.
>
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient,
> you are notified that you are strictly pr! ohibited from using,
> copying, altering, or disclosing the content s of this message.
> FSL accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including
> damage from virus.
> ***************************************************************************

--

Dr. J.W. Atwood, Eng., Professor tel: +1 (514) 848-2424 x3046
Department of Computer Science fax: +1 (514) 848-2830
Concordia University LB927-9 email: bill@cs.Concordia.ca
1455 de Maisonneuve Blvd. West http://www.cs.Concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

_______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim