From magma-bounces@ietf.org Wed Dec 06 06:18:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrukX-0006rS-9E; Wed, 06 Dec 2006 06:15:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrukW-0006rI-3Q for magma@ietf.org; Wed, 06 Dec 2006 06:15:40 -0500 Received: from 59-124-182-147.hinet-ip.hinet.net ([59.124.182.147] helo=zyadd226.zyxel.com.tw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrukT-0007H4-4x for magma@ietf.org; Wed, 06 Dec 2006 06:15:40 -0500 Received: from zytwfe02.ZyXEL.com ([172.23.5.50]) by smtp.zyxel.com.tw with InterScan Messaging Security Suite; Wed, 06 Dec 2006 19:15:45 +0800 Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zytwfe02.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 19:15:56 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 19:15:54 +0800 Received: from 1194201 ([172.23.17.51]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 19:15:53 +0800 Message-ID: <006001c71928$9311c4f0$2101a8c0@1194201> From: "Yu-Jung Lee" To: Date: Wed, 6 Dec 2006 19:20:45 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 06 Dec 2006 11:15:53.0986 (UTC) FILETIME=[E501AE20:01C71927] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [magma] questions about RFC4605 -- IGMP/MLD multicast proxy X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2006180003==" Errors-To: magma-bounces@ietf.org This is a multi-part message in MIME format. --===============2006180003== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C7196B.A1291E10" This is a multi-part message in MIME format. ------=_NextPart_000_005D_01C7196B.A1291E10 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi, In RFC 4605, it defines that a proxy device has a single upstream = interface and one or more downstream interfaces. What's the reason for = the restriction of only one upstream interface? Also, it is said in the = RFC that the proxy device MUST NOT perform the router portion of = IGMP/MLD on its upstream interface. There's no restriction on performing = the host portion of IGMP/MLD on the downstream interfaces. Does that = mean it's okay to send reports to downstream interfaces? Won't it cause = problems if the hosts attached to downstream interfaces support reports = suppression?=20 BR, Yu-Jung ------=_NextPart_000_005D_01C7196B.A1291E10 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi,
 
In RFC 4605, it defines that a proxy = device has a=20 single upstream interface and one or more downstream=20 interfaces. What's the reason = for the=20 restriction of only one upstream interface? Also, it is said in the RFC = that the=20 proxy device MUST NOT perform the router portion of IGMP/MLD on its = upstream=20 interface. There's no restriction on performing the host portion of IGMP/MLD on the downstream = interfaces.=20 Does that mean it's okay to send reports to downstream interfaces? = Won't it=20 cause problems if the hosts attached to downstream interfaces = support=20 reports suppression? 
 
 
BR,
Yu-Jung
 
------=_NextPart_000_005D_01C7196B.A1291E10-- --===============2006180003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma --===============2006180003==-- From magma-bounces@ietf.org Thu Dec 07 17:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRy8-0001Bg-8z; Thu, 07 Dec 2006 17:43:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRy7-0001Bb-LH for magma@ietf.org; Thu, 07 Dec 2006 17:43:55 -0500 Received: from bay0-omc2-s26.bay0.hotmail.com ([65.54.246.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsRy4-00044o-9k for magma@ietf.org; Thu, 07 Dec 2006 17:43:55 -0500 Received: from hotmail.com ([64.4.35.13]) by bay0-omc2-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Dec 2006 14:43:51 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 Dec 2006 14:43:51 -0800 Message-ID: Received: from 216.31.211.11 by by12fd.bay12.hotmail.msn.com with HTTP; Thu, 07 Dec 2006 22:43:49 GMT X-Originating-IP: [216.31.211.11] X-Originating-Email: [klltm@hotmail.com] X-Sender: klltm@hotmail.com From: "K T" To: magma@ietf.org Bcc: Date: Thu, 07 Dec 2006 22:43:49 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 Dec 2006 22:43:51.0630 (UTC) FILETIME=[2AD00EE0:01C71A51] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [magma] windowx xp igmpv3 X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org Hi, I am using Linux 2.6 kernel as IGMPv3 Router connected to Windows XP machine acting as a IGMPv3 Client. When I start Videolan player client to play a video from a particular video server (by selecting source specific filtering IP) it sends a IGMPv3 report to linux IGMPv3 router and video plays fine. But, when I stop the video, XP machines sends IGMPv3 report with BLOCK_OLD_SOURCES. Then, LInux router sends a group-source specific query to the XP machine for which XP machine reponds again withe same message sayign BLOCK_OLD_SOURCE. Is this the right way of doing? I thought once you send a group-source spefici query and if the client machine is not using that multicast group it should not even respond to this query. That way LInux machine can clean up its state for that multicast group. BTW, I am trying to do IGMP proxying at router interface of linux. Can you please repond with your opinion. Thank you BC _________________________________________________________________ MSN Shopping has everything on your holiday list. Get expert picks by style, age, and price. Try it! http://shopping.msn.com/content/shp/?ctId=8000,ptnrid=176,ptnrdata=200601&tcode=wlmtagline _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Thu Dec 07 21:53:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsVqA-00084p-8L; Thu, 07 Dec 2006 21:51:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsVq9-00084h-6m for magma@ietf.org; Thu, 07 Dec 2006 21:51:57 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsVq7-00058t-HM for magma@ietf.org; Thu, 07 Dec 2006 21:51:57 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9X006YSP2VHU@szxga01-in.huawei.com> for magma@ietf.org; Fri, 08 Dec 2006 10:47:19 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9X009PRP2U4G@szxga01-in.huawei.com> for magma@ietf.org; Fri, 08 Dec 2006 10:47:19 +0800 (CST) Received: from c50408 ([10.111.12.80]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9X00443P2TKU@szxml03-in.huawei.com> for magma@ietf.org; Fri, 08 Dec 2006 10:47:18 +0800 (CST) Date: Fri, 08 Dec 2006 10:47:17 +0800 From: Cao Wei Subject: Re: [magma] windowx xp igmpv3 To: K T , magma@ietf.org Message-id: <002d01c71a73$2ca6d240$500c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org Hi, Maybe the second one is a re-trasmitted message. In section 5.1 of IGMPv3(Action on Change of Interface State): To cover the possibility of the State-Change Report being missed by one or more multicast routers, it is retransmitted [Robustness Variable] - 1 more times, at intervals chosen at random from the range (0, [Unsolicited Report Interval]). And by default, the value of Robutsness Varible is 2. Cao Wei ----- Original Message ----- From: "K T" To: Sent: Friday, December 08, 2006 6:43 AM Subject: [magma] windowx xp igmpv3 > Hi, > > I am using Linux 2.6 kernel as IGMPv3 Router connected to Windows XP machine > acting as a IGMPv3 Client. When I start Videolan player client to play a > video from a particular video server (by selecting source specific filtering > IP) it sends a IGMPv3 report to linux IGMPv3 router and video plays fine. > > But, when I stop the video, XP machines sends IGMPv3 report with > BLOCK_OLD_SOURCES. Then, LInux router sends a group-source specific query to > the XP machine for which XP machine reponds again withe same message sayign > BLOCK_OLD_SOURCE. Is this the right way of doing? I thought once you send > a group-source spefici query and if the client machine is not using that > multicast group it should not even respond to this query. That way LInux > machine can clean up its state for that multicast group. BTW, I am trying > to do IGMP proxying at router interface of linux. > > Can you please repond with your opinion. > > Thank you > BC > > _________________________________________________________________ > MSN Shopping has everything on your holiday list. Get expert picks by style, > age, and price. Try it! > http://shopping.msn.com/content/shp/?ctId=8000,ptnrid=176,ptnrdata=200601&tcode=wlmtagline > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma > _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Sun Dec 10 00:20:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtH5I-0004xg-Gx; Sun, 10 Dec 2006 00:18:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtH5H-0004xY-2g for magma@ietf.org; Sun, 10 Dec 2006 00:18:43 -0500 Received: from [203.196.196.71] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtH5C-0004K6-79 for magma@ietf.org; Sun, 10 Dec 2006 00:18:43 -0500 Received: from blr-mail.netd.com (BLR-MAIL.NETD.COM [127.0.0.1]) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id kBA5R3RC030455; Sun, 10 Dec 2006 10:57:05 +0530 From: "tajay" To: magma@ietf.org Date: Sun, 10 Dec 2006 10:57:02 +0530 Message-Id: <20061210052334.M45650@blr-mail.netd.com> X-Mailer: Open WebMail 2.30 20040103 X-OriginatingIP: 59.92.167.75 (tajay) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@blr-mail.netd.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [magma] PIM : detecting duplicate packet X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org Hi, Most of the opimization algorithms in PIM depends on detecting duplicate packets. e.g (1) sending register stop once RP starts receiving duplicate packets (2) DR @ source sends prunes (S,G) from RPTree whenever it receives duplicate packets from source. Is there any specific way to identify duplicate packets? And how feasible it is to detect duplicate packets at very high rate traffic? Ajay -- Open WebMail Project (http://openwebmail.org) _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Sun Dec 10 12:34:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtSYN-0003Y3-0Q; Sun, 10 Dec 2006 12:33:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtSYL-0003Xw-6w for magma@ietf.org; Sun, 10 Dec 2006 12:33:29 -0500 Received: from [203.196.196.71] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtSYJ-0004py-AF for magma@ietf.org; Sun, 10 Dec 2006 12:33:29 -0500 Received: from blr-mail.netd.com (BLR-MAIL.NETD.COM [127.0.0.1]) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id kBAHfeRC026720; Sun, 10 Dec 2006 23:11:40 +0530 From: "tajay" To: Jean-Jacques.Pansiot@crc.u-strasbg.fr, tajay Subject: Re: [magma] PIM : detecting duplicate packet Date: Sun, 10 Dec 2006 23:11:40 +0530 Message-Id: <20061210173316.M66582@blr-mail.netd.com> In-Reply-To: <20061210174911.ygtyi6z0o488wos4@webmail.u-strasbg.fr> References: <20061210052334.M45650@blr-mail.netd.com> <20061210174911.ygtyi6z0o488wos4@webmail.u-strasbg.fr> X-Mailer: Open WebMail 2.30 20040103 X-OriginatingIP: 59.92.167.75 (tajay) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@blr-mail.netd.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: magma@ietf.org X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org Hi, I am confused about behaviour on lan interfaec. On the lan interface we can have multiple neighbors on the same interface that time incoming interface remains same but still packet can come from different neighbors. I am just giving one simple network topology as example. R1 R2 | | | | |----------------| | | | R3 | | Receiver R3 has RPF_interface(S)= R1 and RPF_interface(RP) = R2 After switching to SPTree R3 may receive 2 packets..?? or following topology RP | | | Rs------Sender | | | Rr | | Receiver In above topology at Rr, RPF_interface(S) and RPF_interface(RP) are same. Ajay -- Open WebMail Project (http://openwebmail.org) ---------- Original Message ----------- From: Jean-Jacques.Pansiot@crc.u-strasbg.fr To: tajay Cc: magma@ietf.org Sent: Sun, 10 Dec 2006 17:49:11 +0100 Subject: Re: [magma] PIM : detecting duplicate packet > Quoting tajay : > > > Hi, > Hello, > You dont really need to detect that a packet is duplicated. > It is sufficient to detect if a native multicast packet from a > given source S has been received by the incoming interface of the > source tree for S > (and this interface is different from the incoming interface of the > shared tree for the same group) > > cheers > Jean-Jacques > > > Most of the opimization algorithms in PIM depends on detecting > > duplicate packets. > > e.g > > (1) sending register stop once RP starts receiving duplicate packets > > (2) DR @ source sends prunes (S,G) from RPTree whenever it receives duplicate > > packets from source. > > > > Is there any specific way to identify duplicate packets? And how feasible it > > is to detect duplicate packets at very high rate traffic? > > > > Ajay > > > > > > -- > > Open WebMail Project (http://openwebmail.org) > > > > > > _______________________________________________ > > magma mailing list > > magma@ietf.org > > https://www1.ietf.org/mailman/listinfo/magma > > ------- End of Original Message ------- _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Mon Dec 11 09:07:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtloR-00076h-0V; Mon, 11 Dec 2006 09:07:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtloP-00076W-Rg for magma@ietf.org; Mon, 11 Dec 2006 09:07:21 -0500 Received: from [203.196.196.71] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtloM-0007ZH-5J for magma@ietf.org; Mon, 11 Dec 2006 09:07:21 -0500 Received: from netd.com ([10.91.2.5]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id kBBEFtRC023311; Mon, 11 Dec 2006 19:46:02 +0530 Message-ID: <457D6576.8000701@netd.com> Date: Mon, 11 Dec 2006 19:34:38 +0530 From: AJAY THAKUR User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: magma@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [magma] PIM : reserve address range 239.x.x.x range X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org Hi, While processing PIM join/prune packets do we need to have any check for administratively scoped multicast address range. Can PIM router accept it blindly ? Ajay _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Mon Dec 11 13:19:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtpjt-0003yd-Rg; Mon, 11 Dec 2006 13:18:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtpjs-0003xA-Rw for magma@ietf.org; Mon, 11 Dec 2006 13:18:56 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtpf6-0001x6-VV for magma@ietf.org; Mon, 11 Dec 2006 13:14:02 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 11 Dec 2006 10:14:00 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kBBIE0fd030454; Mon, 11 Dec 2006 10:14:00 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBBIDpW8020313; Mon, 11 Dec 2006 10:14:00 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 10:13:49 -0800 Received: from [171.70.224.103] ([171.70.224.103]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 10:13:49 -0800 In-Reply-To: <20061210052334.M45650@blr-mail.netd.com> References: <20061210052334.M45650@blr-mail.netd.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2932B327-79BF-4101-8FC9-775FCBAF9A44@cisco.com> Content-Transfer-Encoding: 7bit From: John Zwiebel Subject: Re: [magma] PIM : detecting duplicate packet Date: Mon, 11 Dec 2006 10:13:58 -0800 To: tajay X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 11 Dec 2006 18:13:49.0802 (UTC) FILETIME=[1B6C4CA0:01C71D50] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1943; t=1165860840; x=1166724840; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[magma]=20PIM=20=3A=20detecting=20duplicate=20packet |Sender:=20; bh=iGS8wskRMxr/dTl6pa4hEisBrUqzypu3ENy4hM4IMg4=; b=bbq8TSSQqpGCQu5pqIHGzcAl2hlS7d84vDefwObPhIbkQficRXBp95IZ1WeTseN592hZgtsp 2oIBiBMl5Bp9Pq6kHRX6eIy0xLWpm3kotQ59PfGA604Y6YVsU1z398B5; Authentication-Results: sj-dkim-4; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: magma@ietf.org X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org On Dec 9, 2006, at 9:27 PM, tajay wrote: > Hi, > Most of the opimization algorithms in PIM depends on detecting > duplicate packets. > e.g > (1) sending register stop once RP starts receiving duplicate packets > (2) DR @ source sends prunes (S,G) from RPTree whenever it receives > duplicate > packets from source. > > Is there any specific way to identify duplicate packets? And how > feasible it > is to detect duplicate packets at very high rate traffic? To correct a slight misunderstanding, it isn't "duplicate" packets that are being detected, but the arrival of packets on an alternate network path. It is 'assumed' that this will ensure there is no loss of data when switching from the RP-tree to the shortest-path, or from pim registration to the shortest-path. And you have #2 wrong, it isn't the DR at the source, but it is the last-hop router, which may or may not be the DR, that joins to the spt. To be honest, it has never been clearly shown that the complications of such a data-path switch are really useful. In fact, some applications have been shown to croak (or at least not handle well) reception of duplicate packets. You might consider: -- On the last hop router, as soon as receipt of a mpacket down the shared-path creates (S,G) state, immediately sending (S,G,R) prunes while at the same time sending (S,G) joins for the SPT. You will lose some mpackets, but your application probably hasn't had the chance to figure out that there really is data available. -- On the RP, as soon as a PIM-register is received sending a register-stop at the same time you send an (S,G) join. Again, you will lose some mpackets, but it hasn't been shown that applications would recognize this loss. These two suggestions do not comply with the PIM RFC. Its your choice whether or not you think its important enough. z _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Mon Dec 11 13:20:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtpky-0004Am-5b; Mon, 11 Dec 2006 13:20:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtpkw-0004Ad-Kz for magma@ietf.org; Mon, 11 Dec 2006 13:20:02 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtpks-0003Ud-8R for magma@ietf.org; Mon, 11 Dec 2006 13:20:02 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 11 Dec 2006 10:19:57 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBBIJvF6006484; Mon, 11 Dec 2006 10:19:57 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBBIJkix020727; Mon, 11 Dec 2006 10:19:53 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 10:19:49 -0800 Received: from [171.70.224.103] ([171.70.224.103]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 10:19:49 -0800 In-Reply-To: <20061210173316.M66582@blr-mail.netd.com> References: <20061210052334.M45650@blr-mail.netd.com> <20061210174911.ygtyi6z0o488wos4@webmail.u-strasbg.fr> <20061210173316.M66582@blr-mail.netd.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <091C12A5-305C-4E1C-BEF9-CF4D948DB2CC@cisco.com> Content-Transfer-Encoding: 7bit From: John Zwiebel Subject: Re: [magma] PIM : detecting duplicate packet Date: Mon, 11 Dec 2006 10:19:58 -0800 To: tajay X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 11 Dec 2006 18:19:49.0660 (UTC) FILETIME=[F1EA45C0:01C71D50] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3280; t=1165861197; x=1166725197; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[magma]=20PIM=20=3A=20detecting=20duplicate=20packet |Sender:=20; bh=LeygIBMaHoo2kuwzOD87+HBhu3kt+RrSXCvw9ncH4YQ=; b=pzIJDUngPvOamXXzpYdxa0lGtd49ZumpDe8WFut8aqREWCA1/YgGgBUzXME+3TeA9QdXKazN 5QWI3ysaJmz8AmqWQAuiWMwTm3wTkuKi3oajT70gvSkgXhLviRKcAwce; Authentication-Results: sj-dkim-1; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: magma@ietf.org, Jean-Jacques.Pansiot@crc.u-strasbg.fr X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org These topologies are not the same. In the first the RFC expects you to create (S,G) state but continues to receive mpackets down the RPT until there is an assert from R1 which signals that data is indeed arriving on the SPT. To get the assert, there are indeed duplicate packets on the LAN. In the second case, since the RPF to the RP and the RPF to the source are the same router (Rs), there isn't anyway for Rr to know if the SPT is completely set up (assuming more routers between Rs and the source), so Rr marks the SPT as up as soon as it creates (S,G) state. On Dec 10, 2006, at 9:41 AM, tajay wrote: > Hi, > I am confused about behaviour on lan interfaec. > On the lan interface we can have multiple neighbors on the same > interface that time incoming interface remains same but still > packet can come from different neighbors. > > I am just giving one simple network topology as example. > > > > R1 R2 > | | > | | > |----------------| > | > | > | > R3 > | > | > Receiver > > R3 has > RPF_interface(S)= R1 and > RPF_interface(RP) = R2 > After switching to SPTree R3 may receive 2 packets..?? > > > > or following topology > > > > RP > | > | > | > Rs------Sender > | > | > | > Rr > | > | > Receiver > In above topology at Rr, RPF_interface(S) and RPF_interface(RP) > are same. > > > Ajay > > > -- > Open WebMail Project (http://openwebmail.org) > > > ---------- Original Message ----------- > From: Jean-Jacques.Pansiot@crc.u-strasbg.fr > To: tajay > Cc: magma@ietf.org > Sent: Sun, 10 Dec 2006 17:49:11 +0100 > Subject: Re: [magma] PIM : detecting duplicate packet > >> Quoting tajay : >> >>> Hi, >> Hello, >> You dont really need to detect that a packet is duplicated. >> It is sufficient to detect if a native multicast packet from a >> given source S has been received by the incoming interface of the >> source tree for S >> (and this interface is different from the incoming interface of the >> shared tree for the same group) >> >> cheers >> Jean-Jacques >> >>> Most of the opimization algorithms in PIM depends on detecting >>> duplicate packets. >>> e.g >>> (1) sending register stop once RP starts receiving duplicate packets >>> (2) DR @ source sends prunes (S,G) from RPTree whenever it >>> receives duplicate >>> packets from source. >>> >>> Is there any specific way to identify duplicate packets? And how >>> feasible it >>> is to detect duplicate packets at very high rate traffic? >>> >>> Ajay >>> >>> >>> -- >>> Open WebMail Project (http://openwebmail.org) >>> >>> >>> _______________________________________________ >>> magma mailing list >>> magma@ietf.org >>> https://www1.ietf.org/mailman/listinfo/magma >>> > ------- End of Original Message ------- > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Mon Dec 11 13:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtpwh-0002fW-4O; Mon, 11 Dec 2006 13:32:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtpwf-0002fI-Kh for magma@ietf.org; Mon, 11 Dec 2006 13:32:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtpwb-00062y-KT for magma@ietf.org; Mon, 11 Dec 2006 13:32:09 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 11 Dec 2006 10:32:05 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kBBIW4GK019449; Mon, 11 Dec 2006 10:32:04 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kBBIW4da014215; Mon, 11 Dec 2006 10:32:04 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 10:32:04 -0800 Received: from [171.70.224.103] ([171.70.224.103]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 10:32:04 -0800 In-Reply-To: <457D6576.8000701@netd.com> References: <457D6576.8000701@netd.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Zwiebel Subject: Re: [magma] PIM : reserve address range 239.x.x.x range Date: Mon, 11 Dec 2006 10:32:12 -0800 To: AJAY THAKUR X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 11 Dec 2006 18:32:04.0280 (UTC) FILETIME=[A7C86380:01C71D52] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=459; t=1165861924; x=1166725924; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[magma]=20PIM=20=3A=20reserve=20address=20range=20239 .x.x.x=20range |Sender:=20; bh=tU5rjLZe+BAYGrcYsrthR2UryA860K8nS1P1+T0s0Ns=; b=C0aEtuE7mWq9mBU3Kk0Iq12kXOSxWJkbMAl5n86XRZkG2NfMuO3tRBgBEEMgmveKTq/7OXtQ sjieS3ufsC2AcbfXWv2FNDwZXY9lIH1C9LkWYzSWoZ2xmHi6gG/cfLlN; Authentication-Results: sj-dkim-8; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: magma@ietf.org X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org You have to configure your router to be on the administrative boundary. On Dec 11, 2006, at 6:04 AM, AJAY THAKUR wrote: > Hi, > While processing PIM join/prune packets do we need > to have any check for administratively scoped multicast > address range. Can PIM router accept it blindly ? > > Ajay > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Tue Dec 12 07:12:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu6UO-0007SG-RH; Tue, 12 Dec 2006 07:12:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu6UN-0007S2-B4 for magma@ietf.org; Tue, 12 Dec 2006 07:12:03 -0500 Received: from [203.196.196.71] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu6UK-00017J-Fu for magma@ietf.org; Tue, 12 Dec 2006 07:12:03 -0500 Received: from netd.com ([10.91.2.5]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id kBCCKFRC019758; Tue, 12 Dec 2006 17:50:21 +0530 Message-ID: <457E9BD5.1030007@netd.com> Date: Tue, 12 Dec 2006 17:38:53 +0530 From: AJAY THAKUR User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: magma@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [magma] multicast traceroute updated draft X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org HI, Can somebody please let me know which is updated draft for multicast traceroute or multicast ping functionlity. Ajay _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Wed Dec 13 15:46:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guaz3-0006Na-OM; Wed, 13 Dec 2006 15:45:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guaz2-0006L4-HM for magma@ietf.org; Wed, 13 Dec 2006 15:45:44 -0500 Received: from [203.196.196.71] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guayz-00022S-HT for magma@ietf.org; Wed, 13 Dec 2006 15:45:44 -0500 Received: from BLR-MAIL.NETD.COM (BLR-MAIL.NETD.COM [127.0.0.1]) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id kBDKwrxV025350 for ; Thu, 14 Dec 2006 02:28:53 +0530 Received: from localhost (tajay@localhost) by BLR-MAIL.NETD.COM (8.12.8/8.12.8/Submit) with ESMTP id kBDKwgk9025280 for ; Thu, 14 Dec 2006 02:28:47 +0530 Date: Thu, 14 Dec 2006 02:28:40 +0530 (IST) From: tajay@netd.com To: magma@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@blr-mail.netd.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [magma] PIM query X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org Hello all, I have doubt in the following network topology. Please tell me whether this is valid scenario? 1 2 3 4 RCV------DR@RCV--------RP--------DR@SRC-------SRC | | | 5 | |-----------------------| RCV : uses igmpv2 to join group G DR@RCV : is DR at receiver. RP : Rendezvous point DR@SRC : is DR at source SRC : multicasr sender Number 1,2,3,4,5 indiate interface index just for simplifying the description. NOTE THAT : "RP has route to SRC through DR@RCV." and assume that DR@RCV does not switch to SPT b'cos threshold configured in DR@RCV is infinity. I am confused about who sends periodic join(S,G)...DR@RCV or RP ? AJay _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Wed Dec 13 16:41:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GubqR-00074V-AV; Wed, 13 Dec 2006 16:40:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GubqQ-00072y-JO for magma@ietf.org; Wed, 13 Dec 2006 16:40:54 -0500 Received: from smtp10.poczta.interia.pl ([80.48.65.10] helo=smtp4.poczta.interia.pl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GubqP-0003WX-86 for magma@ietf.org; Wed, 13 Dec 2006 16:40:54 -0500 Received: by smtp4.poczta.interia.pl (INTERIA.PL, from userid 502) id E6C53376B81; Wed, 13 Dec 2006 22:40:51 +0100 (CET) Received: from poczta.interia.pl (f08.poczta.interia.pl [10.217.2.8]) by smtp4.poczta.interia.pl (INTERIA.PL) with ESMTP id 8D4DB376A07 for ; Wed, 13 Dec 2006 22:40:44 +0100 (CET) Received: by poczta.interia.pl (Postfix, from userid 502) id B743616A42B; Wed, 13 Dec 2006 22:40:42 +0100 (CET) Received: from localhost (localhost.interia.pl [127.0.0.1]) by poczta.interia.pl (Postfix) with ESMTP id 654C716A42E for ; Wed, 13 Dec 2006 22:40:30 +0100 (CET) Date: 13 Dec 2006 22:40:30 +0100 From: tbartcz@interia.pl To: magma@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE X-ORIGINATE-IP: 194.187.181.11 IMPORTANCE: Normal X-MSMAIL-PRIORITY: Normal X-PRIORITY: 3 X-Mailer: PSE3 Message-Id: <20061213214030.654C716A42E@poczta.interia.pl> X-EMID: ed40acc X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [magma] DVMRP question X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org =0AHello,=0AAnybody can please tell me where is DVMRP described. As far as = I know RFC 1075 initially describing this protocol is not valid any more. I= have seen some draft documents covering this topic created by Mr. T. Pusat= eri. The last that I found is draft-ietf-idmr-dvmrp-v3-11.txt. Can anybody = please tell me whether it is the newest and the right document describing c= urrent status of DVMRP?=0AThanks in advance=0ATomasz Bartczak=0A=0A ---------------------------------------------------------------------- Najlepszy prezent dla najlepszego mezczyzny? Wygrywaj swiateczne prezenty na http://link.interia.pl/f19d7 >> _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Wed Dec 13 20:51:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gufj3-0003cd-6p; Wed, 13 Dec 2006 20:49:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gufj1-0003cI-R0 for magma@ietf.org; Wed, 13 Dec 2006 20:49:31 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gufj0-00016S-1E for magma@ietf.org; Wed, 13 Dec 2006 20:49:31 -0500 Received: by ug-out-1314.google.com with SMTP id 72so305033ugd for ; Wed, 13 Dec 2006 17:49:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gVoMtyRd3c1q8QNhGsxxHlXIZ8cI8vUcFawYR0vhJdqFXgacKr2E6Kp5ilQ/ue2dmGLxtK4RKTV/3QcdpYZhoszpfOejwRw8zNPYjnIOEcqmlu41RXyx0/RyNw5z/SJc4FXscBBbiuqShxL/0mSkxoOsfe4KL24n0sYdto2yPxw= Received: by 10.78.136.9 with SMTP id j9mr368509hud.1166060968797; Wed, 13 Dec 2006 17:49:28 -0800 (PST) Received: by 10.78.179.7 with HTTP; Wed, 13 Dec 2006 17:49:28 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 20:49:28 -0500 From: "Marshall Eubanks" To: "tbartcz@interia.pl" Subject: Re: [magma] DVMRP question In-Reply-To: <20061213214030.654C716A42E@poczta.interia.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061213214030.654C716A42E@poczta.interia.pl> X-Spam-Score: 0.5 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: magma@ietf.org X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org I would move this conversation to Mboned or PIM (depending on your interest) as MAGMA is largely dormant. DVMRP is not used much, so I am not sure that On 13 Dec 2006 22:40:30 +0100, tbartcz@interia.pl wrote: > > Hello, > Anybody can please tell me where is DVMRP described. As far as I know RFC 1075 initially describing this protocol is not valid any more. I have seen some draft documents covering this topic created by Mr. T. Pusateri. The last that I found is draft-ietf-idmr-dvmrp-v3-11.txt. Can anybody please tell me whether it is the newest and the right document describing current status of DVMRP? > Thanks in advance > Tomasz Bartczak > The status of DVRMP is mostly historic - this draft is intended to be infomational. The draft is under IESG evaluation - https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1615&rfc_flag=0 (or http://tinyurl.com/ymaoq5 ) and https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1615&rfc_flag=0 (or http://tinyurl.com/yffkfm ) show that the current (2006-07-20) state of this document is IESG Evaluation::Revised ID Needed . I do not think that there are plans to push this through rapidly. If you want to implement it draft-ietf-idmr-dvmrp-v3-11.txt needs some implementations, so I would encourage you to use that, but RFC 1075 certainly works. You might also want to look at draft-ietf-idmr-dvmrp-v3-as-01 and I suspect that at this point Tom might want some assistance, so if this is really important to you, you might consider volunteering to help with the new draft. Regards Marshall > > > ---------------------------------------------------------------------- > Najlepszy prezent dla najlepszego mezczyzny? > Wygrywaj swiateczne prezenty na http://link.interia.pl/f19d7 >> > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma > _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Thu Dec 14 01:55:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GukTv-0000F6-IP; Thu, 14 Dec 2006 01:54:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GukTu-0000Er-3W for magma@ietf.org; Thu, 14 Dec 2006 01:54:14 -0500 Received: from web53513.mail.yahoo.com ([206.190.39.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GukTn-0000SJ-E0 for magma@ietf.org; Thu, 14 Dec 2006 01:54:14 -0500 Received: (qmail 53757 invoked by uid 60001); 14 Dec 2006 06:53:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=uQEi7Qqao0SFPOZClES9pQANH8yLCFh9EBI8QNaieI8JIii397qNXM8DR7y14/o8WaFKmHKdY+fmCthe4JS8Th5COAQN3SeEhygS/pDt9kR6PIzPPiHA+HyAtdYmWMIejUINcmJHQcLQlSlPGFfdfguy9M5aI5l9C+vYuQhAHTU=; X-YMail-OSG: 3SyPgDMVM1kPd84DmmsN3GixxTOAnknohmbqQxenEeLwAUuZuoVFD43UTnOG5MEikfrB4d8JrQg1dKpvsTy.O2M2pQid4AtiwAAngfb.9mFipDBlB9hPwCaq9G9h8s7opw7dDisAE1okQ4vy1iJx2mHuyLawAda5ZmN687E7FGoxXLyRDCz74qbO0iJq Received: from [59.145.141.130] by web53513.mail.yahoo.com via HTTP; Wed, 13 Dec 2006 22:53:57 PST Date: Wed, 13 Dec 2006 22:53:57 -0800 (PST) From: Princy Elizabeth Subject: Re: Re: [magma] IGMP report suppression To: tbartcz@interia.pl, Christy L Norman In-Reply-To: <20061105200156.0540D4B3237@poczta.interia.pl> MIME-Version: 1.0 Message-ID: <152537.53301.qm@web53513.mail.yahoo.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: magma@ietf.org X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0109654148==" Errors-To: magma-bounces@ietf.org --===============0109654148== Content-Type: multipart/alternative; boundary="0-1185337463-1166079237=:53301" Content-Transfer-Encoding: 8bit --0-1185337463-1166079237=:53301 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, My apologies for the extreme delay in replying to this thread. I happened to look at the IGMPV3 RFC again just recently. IMHO, section 5.2 rule 1 that Christy referred to, suggests spreading out the transmission of reports over the interval (0, Max Response Time) only in cases where the response to a general query results in generation of more than one report because all current state records cannot be fit into a single report due to the MTU limitation. The RFC advises packing as many CURRENT_STATE records as possible into a single report message and when the number of reports is more than 1, spread the transmission over the MRT interval. So even in the case where a single host is a member of an extremely large number of groups, IGMP V3 would still generate less reports (maybe 2-3 per host depending on the MTU) as compared to V1/V2 (10 per host). I am not sure if this is what Tomasz was also implying. So thought of adding my interpretation also to the thread. I'd like to hear your views on this. Regards, Princy tbartcz@interia.pl wrote: Hello, I hope that you do not mind that I has joined your discussion. I was recently studying IGMPv3 quite hard in order to get all ins and outs of this protocol version. I agree with the preceding speaker that in case of IGMPv1 and v2 reports are suppressed in order to reduce the traffic. I also share the view that there is no point to suppress receiver Reports messages in case of IGMPv3 due to the issue with sources. However I not quite get the intention of the second part of the email. Let's extend the example presented in the first reply. Assume that we have Ethernet segment with then receivers, ten groups and 100 sources in each group. As it was mentioned earlier we will have 10 Report messages in reply to Query message in case of IGMPv1 and v2. Each Report message will concern to different group. Due to report suppression only one receiver will answer per group and the Reports will be sent per group address. In case of IGMPv3 situation is a bit different. All router will answer to Query message but they will not sent separate Report message for each group. Each one of receivers will sent just one Report message, on address 224.0.0.22, containing information about reception stage for each of 10 groups. Since there is only one message sent by receiver it has information about many groups. Moreover information for each group contains list of sources (in our case there are 100 sources so the list can be quite long). As a result Report messages in case of IGMPv3 are quite large. For that reason RFC 3376 states: "Instead of using a single interface timer, implementations are recommended to spread transmission of such Report messages over the interval (0, [Max Resp Time])." Advising to not set single Report message in response to Query but divide it and sent it spread over some time interval. Nevertheless it does not seem to me that this behavior is similar to behavior of IGMPv1 and v2 because all receivers will sent Report message for one particular group. Not like in case of IGMPv1 and v2 where only one router answers per group. What are your views on that? Do you are with me? Regards Tomasz Bartczak Christy L Norman napisał(a): I agree with the answer to Parit's question. IGMPv1 and v2 reports can be suppressed to reduce unnecessary traffic. However, in regards to the reason for the absence of report suppression in v3 - I believe it is due to the presence of sources in an IGMPv3 report. One record could easily be omitted from a report (record suppression?). All listeners to a group may have different sources making up their per-interface states and to check the sources of all hosts' reports would be a bit of work for the host. In addition to this reason, RFC 2236 states in 5.2, "Instead of using a single interface timer, implementations are recommended to spread transmission of such Report messages over the interval (0, [Max Resp Time])." In this case, the operation will be much like IGMPv1 & v2 - but report suppression isn't required if you happen to be implementing that method of reporting - because of the issue with the sources. Do you agree? - Christy Princy Elizabeth 11/02/2006 11:32 PM To P K S , magma@ietf.org cc Subject Re: [magma] IGMP report suppression IGMP V1 and V2 reports are sent per group. Consider a LAN with 10 hosts each interested in the same 10 groups. If reports suppression were not employed, every Query interval there would be 10 reports sent out by each of the 10 hosts ==> 100 reports which unnecessarily increase the traffic on the LAN. For the router, it is sufficient to know that there is one interested member for a group on the LAN. So 1 report per group would have sufficed. This precisely is what is done through report suppression. In IGMP V3, a single report can contain the report for all the groups a host is interested in. Thus there is no need for report suppression here since the number of reports would be generally, equal to the number of hosts only. I hope that clarifies your query. - Princy P K S wrote: Why is the IGMP report suppression required in the first place? Regards Parit _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma --------------------------------- Get your email and see which of your friends are online - Right on the new Yahoo.com _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma ---------------------------------------------------------------------- Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e_______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-1185337463-1166079237=:53301 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
 
My apologies for the extreme delay in replying to this thread. I happened to look at the IGMPV3 RFC again just recently.
 
IMHO, section 5.2 rule 1 that Christy referred to, suggests spreading  out the transmission of reports over the interval (0, Max Response Time) only in cases where the response to a general query results in generation of more than one report because all current state records cannot be fit into a single report due to the MTU limitation. The RFC advises packing as many CURRENT_STATE records as possible into a single report message and when the number of reports is more than 1, spread the transmission over the MRT interval. So even in the case where a single host is a member of an extremely large number of groups, IGMP V3 would still generate less reports (maybe 2-3 per host depending on the MTU) as compared to V1/V2 (10 per host). I am not sure if this is what Tomasz was also implying. So thought of adding my interpretation also to the thread. I'd like to hear your views on this.
 
Regards,
Princy

tbartcz@interia.pl wrote:
Hello,
I hope that you do not mind that I has joined your discussion.
I was recently studying IGMPv3 quite hard in order to get all ins and outs of this protocol version. I agree with the preceding speaker that in case of IGMPv1 and v2 reports are suppressed in order to reduce the traffic. I also share the view that there is no point to suppress receiver Reports messages in case of IGMPv3 due to the issue with sources.

However I not quite get the intention of the second part of the email. Let's extend the example presented in the first reply. Assume that we have Ethernet segment with then receivers, ten groups and 100 sources in each group. As it was mentioned earlier we will have 10 Report messages in reply to Query message in case of IGMPv1 and v2. Each Report message will concern to different group. Due to report suppression only one receiver will answer per group and the Reports will be sent per group address.
In case of IGMPv3 situation is a bit different. All router will answer to Query message but they will not sent separate Report message for each group. Each one of receivers will sent just one Report message, on address 224.0.0.22, containing information about reception stage for each of 10 groups. Since there is only one message sent by receiver it has information about many groups. Moreover information for each group contains list of sources (in our case there are 100 sources so the list can be quite long). As a result Report messages in case of IGMPv3 are quite large. For that reason RFC 3376 states:
 "Instead of using a single interface timer, implementations are recommended to spread transmission of such Report messages over the interval (0, [Max Resp Time])."
Advising to not set single Report message in response to Query but divide it and sent it spread over some time interval. Nevertheless it does not seem to me that this behavior is similar to behavior of  IGMPv1 and v2 because all receivers will sent Report message for one particular group. Not like in case of IGMPv1 and v2 where only one router answers per group. What are your views on that? Do you are with me?

Regards
Tomasz Bartczak
Christy L Norman napisał(a):

I agree with the answer to Parit's question. IGMPv1 and v2 reports can be suppressed to reduce unnecessary traffic. However, in regards to the reason for the absence of report suppression in v3 - I believe it is due to the presence of sources in an IGMPv3 report. One record could easily be omitted from a report (record suppression?). All listeners to a group may have different sources making up their per-interface states and to check the sources of  all hosts' reports would be a bit of work for the host.  

In addition to this reason, RFC 2236 states in 5.2,  "Instead of using a single interface timer, implementations are recommended to spread transmission of such Report messages over the interval (0, [Max Resp Time])."  In this case, the operation will be much like IGMPv1 & v2 - but report suppression isn't required if you happen to be implementing that method of reporting - because of the issue with the sources.

Do you agree?

- Christy



Princy Elizabeth <princyte@yahoo.com>
11/02/2006 11:32 PM
To
 P K S <paritoshkshah@gmail.com>, magma@ietf.org
cc
Subject
 Re: [magma] IGMP report suppression





IGMP V1 and V2 reports are sent per group. Consider a LAN with 10 hosts each interested in the same 10 groups. If reports suppression were not employed, every Query interval there would be 10 reports sent out by each of the 10 hosts ==> 100 reports which unnecessarily increase the traffic on the LAN. For the router, it is sufficient to know that there is one interested member for a group on the LAN. So 1 report per group would have sufficed. This precisely is what is done through report suppression. In IGMP V3, a single report can contain the report for all the groups a host is interested in. Thus there is no need for report suppression here since the number of reports would be generally, equal to the number of hosts only.
 
I hope that clarifies your query.
 
- Princy


P K S <paritoshkshah@gmail.com> wrote:
Why is the IGMP report suppression required in the first place?
 
Regards
 Parit
_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma
Get your email and see which of your friends are online - Right on the new Yahoo.com _______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma


----------------------------------------------------------------------
Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma
_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-1185337463-1166079237=:53301-- --===============0109654148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma --===============0109654148==-- From magma-bounces@ietf.org Thu Dec 14 04:00:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GumRf-0007vl-2P; Thu, 14 Dec 2006 04:00:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GumRc-0007vN-Vv for magma@ietf.org; Thu, 14 Dec 2006 04:00:00 -0500 Received: from web53508.mail.yahoo.com ([206.190.37.69]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GumRX-0001pS-Kt for magma@ietf.org; Thu, 14 Dec 2006 04:00:00 -0500 Received: (qmail 4460 invoked by uid 60001); 14 Dec 2006 08:59:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dPR0V7FG5j62KDurL6GLOgWln2cxwjao933/iuCwpL5VG/zzg73T+HdW3xyvS99sMa8F03b4iRIklOYnH1xo6VTUbp6DUKQN5nsM9647qx7rxQDTaIsoLW6Im6seej/KJ6rWMPUcxypttRDf5PTC1Skk7vREHL6cxJJOO6D0z6w= ; Message-ID: <20061214085955.4458.qmail@web53508.mail.yahoo.com> X-YMail-OSG: bL1paK8VM1nJaqDE2kbFX7U.Sv22QXQlEP33iSopSrtiwUqoxZXuPuanDrGwWBfHMok7R9H_bkf.FKjGnJhTTnVZP8w9HVOAwIhil1UdaExd9QTRyWVTXbEYFwUcGOud_GOQNdYndQy7Kzsd2gsYCx628XcQLARzNMTgOLbGlYinBxFZdhFj6jIabQ8L Received: from [59.145.141.130] by web53508.mail.yahoo.com via HTTP; Thu, 14 Dec 2006 00:59:55 PST Date: Thu, 14 Dec 2006 00:59:55 -0800 (PST) From: Princy Elizabeth To: magma@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [magma] IGMPV3 Report scheduling X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092380213==" Errors-To: magma-bounces@ietf.org --===============0092380213== Content-Type: multipart/alternative; boundary="0-237991209-1166086795=:2636" Content-Transfer-Encoding: 8bit --0-237991209-1166086795=:2636 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I had a question on the scheduling of reports by an IGMPV3 hosts. The RFC requires an IGMP host to retransmit its State Change Records for a group "robustness variable" number of times. In case of further state change occuring prior to all the retransmissions being complete, the state changes are merged and transmitted immediately. This terminates retransmission of the first state change record and becomes the first of "robustness variable" retransmissions for the combined state change record. However, I am not clear on what happens if a general query is received before the "robustness variable" retransmissions are complete? Which of the following happens: a) The timer for the state change record retransmission for the group is cancelled and all pending retransmissions for the state change record are also cancelled. Response to the general query is sent instead after a random interval between 0 to MRT? OR b) The timer for the state change record retransmission for the group cancelled but pending retransmissions for the state change record are not cancelled. Number of pending retransmissions for the state change record is decremented by 1. Response to the general query is sent after a random interval between 0 to MRT? If the number of pending retransmissions is not 0, the timer is restarted to resend the state change record after some random between 0 to "unsolicited report interval" I think (a) is the correct approach but I'd be grateful if someone could confirm the same. Thanks and regards, Princy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-237991209-1166086795=:2636 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi,
 
I had a question on the scheduling of reports by an IGMPV3 hosts. The RFC requires an IGMP host to retransmit its State Change Records for a group "robustness variable" number of times. In case of further state change occuring prior to all the retransmissions being complete, the state changes are merged and transmitted immediately. This terminates retransmission of the first state change record and becomes the first of "robustness variable" retransmissions for the combined state change record. However, I am not clear on what happens if a general query is received before the "robustness variable" retransmissions are complete? Which of the following happens:
 
a) The timer for the state change record retransmission for the group is cancelled and all pending retransmissions for the state change record are also cancelled. Response to the general query is sent instead after a random interval between 0 to MRT?
 
OR
 
b) The timer for the state change record retransmission for the group cancelled but pending retransmissions for the state change record are not cancelled. Number of pending retransmissions for the state change record is decremented by 1. Response to the general query is sent after a random interval between 0 to MRT? If the number of pending retransmissions is not 0, the timer is restarted to resend the state change record after some random  between 0 to "unsolicited report interval"
 
I think (a) is the correct approach but I'd be grateful if someone could confirm the same.
 
Thanks and regards,
Princy

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-237991209-1166086795=:2636-- --===============0092380213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma --===============0092380213==-- From magma-bounces@ietf.org Thu Dec 14 16:18:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guxx8-0000Fm-MP; Thu, 14 Dec 2006 16:17:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guxx7-0000Fe-Gt for magma@ietf.org; Thu, 14 Dec 2006 16:17:17 -0500 Received: from web7713.mail.in.yahoo.com ([202.86.4.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Guxx4-0003NO-KS for magma@ietf.org; Thu, 14 Dec 2006 16:17:17 -0500 Received: (qmail 10748 invoked by uid 60001); 14 Dec 2006 21:17:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qc/zI5JpkiH3DFizf2B5dSWc7i6heRubUxL1QDrp43pqwG/D90WowkM8+lA9VgNKrP4wZ8bIUNK7qllC5c0jCKCYfqoKpGl61A2jIZQS3pjCKXA0mx6zrXfWKSMqs0lfPKkv7BFXr+LIjRsLvrxSRyq5edWLjWNOmRvkwIpmFu8= ; Message-ID: <20061214211701.10746.qmail@web7713.mail.in.yahoo.com> X-YMail-OSG: .GiT3eMVM1nRCWHiw.8EB3S6hjIHDKys2DbhKMLen2yD4VbnFXBBJSJxYmlcklqPSEy65Aa5EdMFBBox_TYnvloz7jf1oZsP4o_fmvvI2fOhnjX1Kko_Bg-- Received: from [59.92.197.170] by web7713.mail.in.yahoo.com via HTTP; Thu, 14 Dec 2006 21:17:01 GMT Date: Thu, 14 Dec 2006 21:17:01 +0000 (GMT) From: ajay thakur To: magma@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [magma] calculating inherited_olist(S,G) X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0440855873==" Errors-To: magma-bounces@ietf.org --===============0440855873== Content-Type: multipart/alternative; boundary="0-1948957602-1166131021=:10608" Content-Transfer-Encoding: 8bit --0-1948957602-1166131021=:10608 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I have doubt about inherited_olist(S,G) calculation. inherited_olist(S,G) is the olist that is relevant for forwarding a packet from S to G using both source- specific and group-specific state. My doubt is if RPF_INTERFACE(S) is found in the inherited_olist(S,G) then do we remove RPF_INTERFACE(S) from inherited_olist(S,G) ? Is it implemenation dependent? Thanks, Ajay --------------------------------- Find out what India is talking about on - Yahoo! Answers India Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW --0-1948957602-1166131021=:10608 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 

Hi,
I have doubt about inherited_olist(S,G) calculation. 

inherited_olist(S,G) is the olist that is relevant for 
forwarding a packet from S to G using both source-
specific and group-specific state. 

My doubt is if RPF_INTERFACE(S) is found in the
inherited_olist(S,G) then do we remove RPF_INTERFACE(S)
from inherited_olist(S,G) ? Is it implemenation dependent?

Thanks,
Ajay

Find out what India is talking about on - Yahoo! Answers India
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW --0-1948957602-1166131021=:10608-- --===============0440855873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma --===============0440855873==-- From magma-bounces@ietf.org Fri Dec 15 08:10:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvCpI-00009E-OV; Fri, 15 Dec 2006 08:10:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvCpH-00008l-H9 for magma@ietf.org; Fri, 15 Dec 2006 08:10:11 -0500 Received: from web7710.mail.in.yahoo.com ([202.86.4.48]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GvCpD-00010l-IY for magma@ietf.org; Fri, 15 Dec 2006 08:10:11 -0500 Received: (qmail 37490 invoked by uid 60001); 15 Dec 2006 13:09:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=WC/M5buLwUQmdvCTZE4ptjmElqG0Frk1JCttgI1qRIoIahoWTCWszdcId8PBO0g29JD05q/7Zed0CnZQmDNZtf//zRfjJg/vEIrY3Pn/b96B95xfBd8ekAnAH6TXz27SYEglG2Gjahb7Gb7qjLwW9AjZjOyXZLRGh5NuNveaTvY=; X-YMail-OSG: SHz4O8IVM1lD_eEvxQzoFo7bT2pHitx9u0s2fufpf4e_QYB3LSJPtMWjRJSd2oabkUGGKC.USIt.JPPRC0X6vzZ5aAN3Cu_oncGCrQsgLtf9iFB.dPUMqQ-- Received: from [203.196.196.74] by web7710.mail.in.yahoo.com via HTTP; Fri, 15 Dec 2006 13:09:59 GMT Date: Fri, 15 Dec 2006 13:09:59 +0000 (GMT) From: ajay thakur Subject: Re: [magma] calculating inherited_olist(S,G) To: Jean-Jacques Pansiot In-Reply-To: <45827654.7090609@crc.u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <311952.36344.qm@web7710.mail.in.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: magma@ietf.org X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: magma-bounces@ietf.org HI, Thanks for your reply. But I have seen some problem b'cos of this sort behaviour. Whatever you said makes sense while forwarding packets. But in some macros we use inherited_olist(S,G) (e.g. RP uses this macro to decide whether to send register stop message or not). I have seen some miss behaviour of routers because of this type of usage. Ajay --- Jean-Jacques Pansiot wrote: > ajay thakur wrote: > > Hi, > > I have doubt about inherited_olist(S,G) > calculation. > > > > inherited_olist(S,G) is the olist that is relevant > for > > forwarding a packet from S to G using both source- > > specific and group-specific state. > > > > My doubt is if RPF_INTERFACE(S) is found in the > > inherited_olist(S,G) then do we remove > RPF_INTERFACE(S) > > from inherited_olist(S,G) ? Is it implemenation > dependent? > > > if you look at the full description, you can see > > oiflist = inherited_olist(S,G) > > and then > > oiflist = oiflist (-) iif > > so the incoming interface iif (which must be the > RPF(S) interface if you use (S,G) tree) > is removed from oiflist > > Jean-Jacques > > > > > Thanks, > > Ajay > > > > > > > ------------------------------------------------------------------------ > > Find out what India is talking about on - Yahoo! > Answers India > > > > > Send FREE SMS to your friend's mobile from Yahoo! > Messenger Version 8. > > Get it NOW > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > magma mailing list > > magma@ietf.org > > https://www1.ietf.org/mailman/listinfo/magma > > > > Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-bounces@ietf.org Thu Dec 21 09:27:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOsL-0008UA-6d; Thu, 21 Dec 2006 09:26:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOsJ-0008ST-4s for magma@ietf.org; Thu, 21 Dec 2006 09:26:23 -0500 Received: from web7701.mail.in.yahoo.com ([202.86.4.39]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GxOnc-0001Sx-Sj for magma@ietf.org; Thu, 21 Dec 2006 09:21:35 -0500 Received: (qmail 90159 invoked by uid 60001); 21 Dec 2006 14:21:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=dYAr7VVP/eO8uiijLgIcMhw14fzl5xr7U0XvO1GjSYH1MLK2JIsqaMGSthVBxTYFABTewEdssBZu4Ug3hADiQbbn2/rgZeIPhJ/ovYcbnfdse8Cwz4jg3V+O7LzRKPnKPLAz/deEZoN3fEsNVyjbET8A6isP9yC83NhWvrD1Eog=; X-YMail-OSG: oORYlL0VM1l0VMd_aQgntZW7h4FpJL1OeHxAXD3Z8N8CGaG9oLdB6sYIlG_NLP4KdSZJyy1hiOUXzLW0mFuYqW2AM45I3tyMrakBGZsGTw0d_PXBog5sLqCUaHbThauLJn.II8_Z0U7KsiLmyk28G13JRAHX9lbptzAjeJ683XDbJA-- Received: from [203.196.196.74] by web7701.mail.in.yahoo.com via HTTP; Thu, 21 Dec 2006 14:21:29 GMT Date: Thu, 21 Dec 2006 14:21:29 +0000 (GMT) From: ajay thakur To: magma@ietf.org MIME-Version: 1.0 Message-ID: <694213.89155.qm@web7701.mail.in.yahoo.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [magma] rfc 4601 : joinDesired(s,g) X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1201788010==" Errors-To: magma-bounces@ietf.org --===============1201788010== Content-Type: multipart/alternative; boundary="0-2003595725-1166710889=:89155" Content-Transfer-Encoding: 8bit --0-2003595725-1166710889=:89155 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, In register packet state machine : at the time of moving register tunnel interface to JOIN state we add "VI" into immediate_olist(S,G) So if we add interface to immdediate_olist(S,G), joinDesired(S,G) becomes true, which causes DR @ source to send join(S,G) towards RP. bool JoinDesired(S,G) { return( immediate_olist(S,G) != NULL OR ( KeepaliveTimer(S,G) is running AND inherited_olist(S,G) != NULL ) ) } But as per, "3.2. Phase Two: Register-Stop" says that RP initiates (S,G) towards source after receiving encapsulated packet. So i guess whoever start first forms (S,G) tree..Is that right ? What if DR@src removes the VI interface from immediate_olist (S,G) after receiving register stop from RP? Then DR @ souce will send prune(S,G) towards RP ? Thanks, Ajay Thakur Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php --0-2003595725-1166710889=:89155 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi,
In register packet state machine :   at the time of moving register tunnel interface to JOIN state we add "VI" into immediate_olist(S,G)

So if we add interface to immdediate_olist(S,G), joinDesired(S,G) becomes true, which causes DR @ source to send join(S,G) towards RP. 

bool JoinDesired(S,G) {
     return( immediate_olist(S,G) != NULL
          OR ( KeepaliveTimer(S,G) is running
              AND inherited_olist(S,G) != NULL ) )
    }


But as per,

"3.2.  Phase Two: Register-Stop"
says that RP initiates (S,G) towards source after 
receiving encapsulated packet. 

So i guess whoever start first forms (S,G) tree..Is that
right ? 

What if DR@src removes the VI interface from 
immediate_olist (S,G) after receiving register stop from
RP? Then DR @ souce will send prune(S,G) towards RP ?


Thanks,
Ajay Thakur


Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php --0-2003595725-1166710889=:89155-- --===============1201788010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma --===============1201788010==--