From owner-pim@catarina.usc.edu Wed Mar 1 16:15:18 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13324 for ; Wed, 1 Mar 2000 16:15:17 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA00308 for pim-list; Wed, 1 Mar 2000 13:04:05 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA00303 for ; Wed, 1 Mar 2000 13:04:02 -0800 (PST) Received: from bacardi.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by bacardi.torrentnet.com (8.9.2/8.9.2) with ESMTP id QAA13550 for ; Wed, 1 Mar 2000 16:03:45 -0500 (EST) Message-Id: <200003012103.QAA13550@bacardi.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: pim@catarina.usc.edu Subject: Question on PIM-SM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Mar 2000 16:03:45 -0500 From: Chirayu Shah Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, I had a question on periodic join/prunes sent to the RP in the following configuration: h1 | --------r1------ | | r2 r3 | | | | | r4 | | | | | r5 (RP) | | ------------------- | r6 | h2 r5 is the RP for 235.1.1.1. h1 is the source, h2 is the receiver. The shortest path from r6 to h1 is through r2. The following sequence of events occur: a. h2 joins a group (235.1.1.1) b. h1 sends to 235.1.1.1 c. After sometime, r6 realizes that the data rate has exceeded and switches to SPT (h2->r6->r2->r1->h1). So finally, r6 has a (*,g) entry and a (s,g)SPT entry. My question is: what does r6 put in the j/p message that it sends to r5? My guess is: join list: (*,235.1.1.1) prune list: (h1,235.1.1.1) with RPT bit set and WC bit cleared (an (S,G)RPT prune). But I couldn't find the section which describes this scenario. It would help if someone could point out which rule applies here. Thanks. Chirayu. From owner-pim@catarina.usc.edu Wed Mar 1 16:54:06 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13999 for ; Wed, 1 Mar 2000 16:54:04 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA00579 for pim-list; Wed, 1 Mar 2000 13:45:15 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from uniwest1.redstonecom.com (mail.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA00574 for ; Wed, 1 Mar 2000 13:45:13 -0800 (PST) Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Mar 2000 16:45:05 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C1CC7EE@uniwest1.redstonecom.com> From: "Shekhar, Ravi" To: Chirayu Shah , pim@catarina.usc.edu Subject: RE: Question on PIM-SM Date: Wed, 1 Mar 2000 16:45:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi Chirayu, In this scenario, there is no way for r6 to know if it has switched to SPT, i.e. it cannot distinguish if its recving data from r2 or r5 (unless you do MAC source address check). So r6 will not send an RPT prune to r5. Instead, r2 and r5 will assert, as both will have interface connecting to r6 in their oifs, when data gets forwarded on that interface. And then r5 will lose assert (due to RPT bit set in pref), leaving r2 to forward the data. - Ravi Shekhar. > Hi, > I had a question on periodic join/prunes sent to the RP in > the following configuration: > > > h1 > | > --------r1------ > | | > r2 r3 > | | > | | > | r4 > | | > | | > | r5 (RP) > | | > ------------------- > | > r6 > | > h2 > > r5 is the RP for 235.1.1.1. > h1 is the source, h2 is the receiver. > The shortest path from r6 to h1 is through r2. The following sequence > of events occur: > a. h2 joins a group (235.1.1.1) > b. h1 sends to 235.1.1.1 > c. After sometime, r6 realizes that the data rate has exceeded > and switches to SPT (h2->r6->r2->r1->h1). > > So finally, r6 has a (*,g) entry and a (s,g)SPT entry. > > My question is: what does r6 put in the j/p message that it sends > to r5? My guess is: > > join list: (*,235.1.1.1) > prune list: (h1,235.1.1.1) with RPT bit set and WC bit cleared > (an (S,G)RPT prune). > > But I couldn't find the section which describes this scenario. > It would help if someone could point out which rule applies here. > > Thanks. > Chirayu. > > > From owner-pim@catarina.usc.edu Wed Mar 1 17:02:14 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14258 for ; Wed, 1 Mar 2000 17:02:12 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA00647 for pim-list; Wed, 1 Mar 2000 13:52:38 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id NAA00642 for ; Wed, 1 Mar 2000 13:52:36 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Mar 2000 13:41:19 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Mar 2000 13:41:19 -0800 Message-ID: <19398D273324D3118A2B0008C7E9A5690A1EFCB1@SIT.platinum.corp.microsoft.com> From: Mohit Talwar To: Chirayu Shah , pim@catarina.usc.edu Subject: RE: Question on PIM-SM Date: Wed, 1 Mar 2000 13:41:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > h1 > | > --------r1------ > | | > r2 r3 > | | > | | > | r4 > | | > | | > | r5 (RP) > | | > ------------------- > | > r6 > | > h2 > >r5 is the RP for 235.1.1.1. >h1 is the source, h2 is the receiver. >The shortest path from r6 to h1 is through r2. The following sequence >of events occur: >a. h2 joins a group (235.1.1.1) >b. h1 sends to 235.1.1.1 >c. After sometime, r6 realizes that the data rate has exceeded >and switches to SPT (h2->r6->r2->r1->h1). > >So finally, r6 has a (*,g) entry and a (s,g)SPT entry. in this scenario, an assert election will take place on the LAN between r2 and r5. r2 will win since it has an (S,G) entry while r5 has (*,G). r5 will create an (S,G)RPT bit entry. (section 3.5.2, "Receiving Assert on OIF", 1) note that r6 will not set the SPT bit for its (s,g) entry!!! so its JoinPrune message to r5 has only > join list: (*,235.1.1.1) hope i haven't overlooked anything. mohit. > >My question is: what does r6 put in the j/p message that it sends >to r5? My guess is: > > join list: (*,235.1.1.1) > prune list: (h1,235.1.1.1) with RPT bit set and WC bit cleared > (an (S,G)RPT prune). > >But I couldn't find the section which describes this scenario. >It would help if someone could point out which rule applies here. > >Thanks. >Chirayu. > > From owner-pim@catarina.usc.edu Wed Mar 1 17:42:49 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15334 for ; Wed, 1 Mar 2000 17:42:45 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA01164 for pim-list; Wed, 1 Mar 2000 14:34:28 -0800 (PST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA01159 for ; Wed, 1 Mar 2000 14:34:24 -0800 (PST) Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id OAA26459; Wed, 1 Mar 2000 14:57:13 -0800 (PST) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA10375; Wed, 1 Mar 2000 14:33:15 -0800 (PST) Message-Id: <200003012233.OAA10375@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Mohit Talwar cc: Chirayu Shah , pim@catarina.usc.edu Subject: Re: Question on PIM-SM In-reply-to: Your message of "Wed, 01 Mar 2000 13:41:14 PST." <19398D273324D3118A2B0008C7E9A5690A1EFCB1@SIT.platinum.corp.microsoft.com> Date: Wed, 01 Mar 2000 14:33:15 -0800 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk This is addressed in issue 11 on the web page at: http://www.aciri.org/fenner/mcast/pim/sm/issues.html thanks Isidor Mohit Talwar writes: >> h1 >> | >> --------r1------ >> | | >> r2 r3 >> | | >> | | >> | r4 >> | | >> | | >> | r5 (RP) >> | | >> ------------------- >> | >> r6 >> | >> h2 >> >>r5 is the RP for 235.1.1.1. >>h1 is the source, h2 is the receiver. >>The shortest path from r6 to h1 is through r2. The following sequence >>of events occur: >>a. h2 joins a group (235.1.1.1) >>b. h1 sends to 235.1.1.1 >>c. After sometime, r6 realizes that the data rate has exceeded >>and switches to SPT (h2->r6->r2->r1->h1). >> >>So finally, r6 has a (*,g) entry and a (s,g)SPT entry. > > >in this scenario, an assert election will take place >on the LAN between r2 and r5. r2 will win since it >has an (S,G) entry while r5 has (*,G). r5 will create >an (S,G)RPT bit entry. >(section 3.5.2, "Receiving Assert on OIF", 1) > >note that r6 will not set the SPT bit for its (s,g) >entry!!! so its JoinPrune message to r5 has only > >> join list: (*,235.1.1.1) > >hope i haven't overlooked anything. >mohit. > > >> >>My question is: what does r6 put in the j/p message that it sends >>to r5? My guess is: >> >> join list: (*,235.1.1.1) >> prune list: (h1,235.1.1.1) with RPT bit set and WC bit cleared >> (an (S,G)RPT prune). >> >>But I couldn't find the section which describes this scenario. >>It would help if someone could point out which rule applies here. >> >>Thanks. >>Chirayu. >> >> > From owner-pim@catarina.usc.edu Wed Mar 1 21:57:52 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21453 for ; Wed, 1 Mar 2000 21:57:49 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id SAA02484 for pim-list; Wed, 1 Mar 2000 18:50:16 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id SAA02479 for ; Wed, 1 Mar 2000 18:50:14 -0800 (PST) Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA13855; Wed, 1 Mar 2000 18:50:15 -0800 (PST) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA10601; Wed, 1 Mar 2000 18:49:25 -0800 (PST) Message-Id: <200003020249.SAA10601@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Mohit Talwar cc: Isidor Kouvelas , Chirayu Shah , pim@catarina.usc.edu Subject: Re: Question on PIM-SM In-reply-to: Your message of "Wed, 01 Mar 2000 18:00:14 PST." <19398D273324D3118A2B0008C7E9A5690A1EFE26@SIT.platinum.corp.microsoft.com> Date: Wed, 01 Mar 2000 18:49:24 -0800 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk Mohit Talwar writes: >on the more general problem discussed in... >http://www.aciri.org/fenner/mcast/pim/sm/issues.html > >PIM-SM issue #32: (*,G) joins undoing (S,G) Asserts > >"After an (S,G) assert has happened, the DR or (*,G) assert winner has >(S,G)RPTbit state with a null oiflist. A (*,G) join from a downstream >router can add the interface back on the (S,G)RPTbit oiflist, undo the >upstream pruning, and cause even more frequent periodic flooding than >just the basic assert mechanism does. > >Downstream routers that have more general state need to create (S,G)RPT >state when receiving Asserts with the RPF neighbor set to the assert >winner. They can then include (S,G)RPT-bit prunes with their (*,G) joins >so that their periodic (*,G) joins don't undo the Asserts (in the case >of multiple upstreams). This will reduce the flooding period to the assert >expiration time." > >--- > >the solution proposes setting up an (S,G) RPT entry in downstream routers >which would otherwise end up sending (*,G) joins and undoing the assert. >i believe that we can get the same behaviour by creating an (S,G)SPT entry! >this entry would result in sending a (S,G) prune towards the RP and an >(S,G) join towards the assert winner. The (S,G)SPT entry may have a different incomming interface to the (*,G) entry. >This does not require monitoring the LAN for (S,G) prunes and seems >(to me :) to fit better within the existing set of rules (which state that >when the OutgoingInterfaceList of an (S,G)RPT entry is the same as that >of the (*,G), the (S,G) RPT entry should be deleted. There are also issues about how to maintain and more importantly time-out the (S,G)SPT state and revert back to the shared tree... thanks Isidor From owner-pim@catarina.usc.edu Wed Mar 1 23:46:09 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24181 for ; Wed, 1 Mar 2000 23:46:08 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id UAA02919 for pim-list; Wed, 1 Mar 2000 20:31:04 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id UAA02914 for ; Wed, 1 Mar 2000 20:31:03 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Mar 2000 18:00:13 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Mar 2000 18:00:13 -0800 Message-ID: <19398D273324D3118A2B0008C7E9A5690A1EFE26@SIT.platinum.corp.microsoft.com> From: Mohit Talwar To: Isidor Kouvelas , Mohit Talwar Cc: Chirayu Shah , pim@catarina.usc.edu Subject: RE: Question on PIM-SM Date: Wed, 1 Mar 2000 18:00:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk on the more general problem discussed in... http://www.aciri.org/fenner/mcast/pim/sm/issues.html PIM-SM issue #32: (*,G) joins undoing (S,G) Asserts "After an (S,G) assert has happened, the DR or (*,G) assert winner has (S,G)RPTbit state with a null oiflist. A (*,G) join from a downstream router can add the interface back on the (S,G)RPTbit oiflist, undo the upstream pruning, and cause even more frequent periodic flooding than just the basic assert mechanism does. Downstream routers that have more general state need to create (S,G)RPT state when receiving Asserts with the RPF neighbor set to the assert winner. They can then include (S,G)RPT-bit prunes with their (*,G) joins so that their periodic (*,G) joins don't undo the Asserts (in the case of multiple upstreams). This will reduce the flooding period to the assert expiration time." --- the solution proposes setting up an (S,G) RPT entry in downstream routers which would otherwise end up sending (*,G) joins and undoing the assert. i believe that we can get the same behaviour by creating an (S,G)SPT entry! this entry would result in sending a (S,G) prune towards the RP and an (S,G) join towards the assert winner. This does not require monitoring the LAN for (S,G) prunes and seems (to me :) to fit better within the existing set of rules (which state that when the OutgoingInterfaceList of an (S,G)RPT entry is the same as that of the (*,G), the (S,G) RPT entry should be deleted. thoughts, please? mohit. >-----Original Message----- >From: Isidor Kouvelas [mailto:kouvelas@cisco.com] >Sent: Wednesday, March 01, 2000 2:33 PM >To: Mohit Talwar >Cc: Chirayu Shah; pim@catarina.usc.edu >Subject: Re: Question on PIM-SM > > > >This is addressed in issue 11 on the web page at: http://www.aciri.org/fenner/mcast/pim/sm/issues.html > >thanks >Isidor > > >Mohit Talwar writes: >>> h1 >>> | >>> --------r1------ >>> | | >>> r2 r3 >>> | | >>> | | >>> | r4 >>> | | >>> | | >>> | r5 (RP) >>> | | >>> ------------------- >>> | >>> r6 >>> | >>> h2 >>> >>>r5 is the RP for 235.1.1.1. >>>h1 is the source, h2 is the receiver. >>>The shortest path from r6 to h1 is through r2. The following >sequence >>>of events occur: >>>a. h2 joins a group (235.1.1.1) >>>b. h1 sends to 235.1.1.1 >>>c. After sometime, r6 realizes that the data rate has exceeded >>>and switches to SPT (h2->r6->r2->r1->h1). >>> >>>So finally, r6 has a (*,g) entry and a (s,g)SPT entry. >> >> >>in this scenario, an assert election will take place >>on the LAN between r2 and r5. r2 will win since it >>has an (S,G) entry while r5 has (*,G). r5 will create >>an (S,G)RPT bit entry. >>(section 3.5.2, "Receiving Assert on OIF", 1) >> >>note that r6 will not set the SPT bit for its (s,g) >>entry!!! so its JoinPrune message to r5 has only >> >>> join list: (*,235.1.1.1) >> >>hope i haven't overlooked anything. >>mohit. >> >> >>> >>>My question is: what does r6 put in the j/p message that it sends >>>to r5? My guess is: >>> >>> join list: (*,235.1.1.1) >>> prune list: (h1,235.1.1.1) with RPT bit set and WC bit cleared >>> (an (S,G)RPT prune). >>> >>>But I couldn't find the section which describes this scenario. >>>It would help if someone could point out which rule applies here. >>> >>>Thanks. >>>Chirayu. >>> >>> >> > From owner-pim@catarina.usc.edu Thu Mar 2 09:45:45 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13899 for ; Thu, 2 Mar 2000 09:45:45 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id GAA04934 for pim-list; Thu, 2 Mar 2000 06:37:46 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from packetbdc.packettech.com ([198.112.190.11]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id GAA04929 for ; Thu, 2 Mar 2000 06:37:45 -0800 (PST) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 09:41:47 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D3BA0D1@packetbdc.packettech.com> From: Billy Ng To: "'Mohit Talwar'" , Isidor Kouvelas Cc: Chirayu Shah , pim@catarina.usc.edu Subject: RE: Question on PIM-SM Date: Thu, 2 Mar 2000 09:41:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-pim@catarina.usc.edu Precedence: bulk The solution that we have on this is that after we create (S,G) and sending the SPT join to the source as a result of threshold, the next data packet will cause the assert to happen. In this case, we will check to see whether the upstream neighbors between the (S,G) and (*,G) is the same. If different, then we set the SPT bit and generate a (S,G) prune toward the shared tree. --Billy -----Original Message----- From: Mohit Talwar [mailto:mohitt@Exchange.Microsoft.com] Sent: Wednesday, March 01, 2000 8:00 PM To: Isidor Kouvelas; Mohit Talwar Cc: Chirayu Shah; pim@catarina.usc.edu Subject: RE: Question on PIM-SM on the more general problem discussed in... http://www.aciri.org/fenner/mcast/pim/sm/issues.html PIM-SM issue #32: (*,G) joins undoing (S,G) Asserts "After an (S,G) assert has happened, the DR or (*,G) assert winner has (S,G)RPTbit state with a null oiflist. A (*,G) join from a downstream router can add the interface back on the (S,G)RPTbit oiflist, undo the upstream pruning, and cause even more frequent periodic flooding than just the basic assert mechanism does. Downstream routers that have more general state need to create (S,G)RPT state when receiving Asserts with the RPF neighbor set to the assert winner. They can then include (S,G)RPT-bit prunes with their (*,G) joins so that their periodic (*,G) joins don't undo the Asserts (in the case of multiple upstreams). This will reduce the flooding period to the assert expiration time." --- the solution proposes setting up an (S,G) RPT entry in downstream routers which would otherwise end up sending (*,G) joins and undoing the assert. i believe that we can get the same behaviour by creating an (S,G)SPT entry! this entry would result in sending a (S,G) prune towards the RP and an (S,G) join towards the assert winner. This does not require monitoring the LAN for (S,G) prunes and seems (to me :) to fit better within the existing set of rules (which state that when the OutgoingInterfaceList of an (S,G)RPT entry is the same as that of the (*,G), the (S,G) RPT entry should be deleted. thoughts, please? mohit. >-----Original Message----- >From: Isidor Kouvelas [mailto:kouvelas@cisco.com] >Sent: Wednesday, March 01, 2000 2:33 PM >To: Mohit Talwar >Cc: Chirayu Shah; pim@catarina.usc.edu >Subject: Re: Question on PIM-SM > > > >This is addressed in issue 11 on the web page at: http://www.aciri.org/fenner/mcast/pim/sm/issues.html > >thanks >Isidor > > >Mohit Talwar writes: >>> h1 >>> | >>> --------r1------ >>> | | >>> r2 r3 >>> | | >>> | | >>> | r4 >>> | | >>> | | >>> | r5 (RP) >>> | | >>> ------------------- >>> | >>> r6 >>> | >>> h2 >>> >>>r5 is the RP for 235.1.1.1. >>>h1 is the source, h2 is the receiver. >>>The shortest path from r6 to h1 is through r2. The following >sequence >>>of events occur: >>>a. h2 joins a group (235.1.1.1) >>>b. h1 sends to 235.1.1.1 >>>c. After sometime, r6 realizes that the data rate has exceeded >>>and switches to SPT (h2->r6->r2->r1->h1). >>> >>>So finally, r6 has a (*,g) entry and a (s,g)SPT entry. >> >> >>in this scenario, an assert election will take place >>on the LAN between r2 and r5. r2 will win since it >>has an (S,G) entry while r5 has (*,G). r5 will create >>an (S,G)RPT bit entry. >>(section 3.5.2, "Receiving Assert on OIF", 1) >> >>note that r6 will not set the SPT bit for its (s,g) >>entry!!! so its JoinPrune message to r5 has only >> >>> join list: (*,235.1.1.1) >> >>hope i haven't overlooked anything. >>mohit. >> >> >>> >>>My question is: what does r6 put in the j/p message that it sends >>>to r5? My guess is: >>> >>> join list: (*,235.1.1.1) >>> prune list: (h1,235.1.1.1) with RPT bit set and WC bit cleared >>> (an (S,G)RPT prune). >>> >>>But I couldn't find the section which describes this scenario. >>>It would help if someone could point out which rule applies here. >>> >>>Thanks. >>>Chirayu. >>> >>> >> > From owner-pim@catarina.usc.edu Thu Mar 2 13:53:26 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22709 for ; Thu, 2 Mar 2000 13:53:24 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA05870 for pim-list; Thu, 2 Mar 2000 10:46:12 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from packetbdc.packettech.com ([198.112.190.11]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA05865 for ; Thu, 2 Mar 2000 10:46:10 -0800 (PST) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 13:50:13 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D3BA0D4@packetbdc.packettech.com> From: Billy Ng To: "'Mohit Talwar'" , Billy Ng , cshah@torrentnet.com, kouvelas@cisco.com Cc: pim@catarina.usc.edu Subject: RE: Question on PIM-SM Date: Thu, 2 Mar 2000 13:50:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Mohit, > -----Original Message----- > From: Mohit Talwar [mailto:mohitt@Exchange.Microsoft.com] > Sent: Thursday, March 02, 2000 12:12 PM > To: Billy Ng; cshah@torrentnet.com; kouvelas@cisco.com > Cc: pim@catarina.usc.edu > Subject: RE: Question on PIM-SM > > > hi billy, isidor, > > i am thinking of > > S RP > . . > . . > . . > R1 R2 > | | > ------------------ > | | > R3 R4 > > Router State RPF-Neighbor > R3 (S,G) R1 > R4 (*,G) R2 > R1 (S,G) towards S > R2 (*,G) towards RP > > an assert election would result in R2 creating an (S,G) RPT bit entry > and sending (S,G) prunes upstream (if the OIL of S,G)RPT is > NULL). but > as per the existing set of rules the JoinPrune message from R4 to R2 > would "...add the interface back on the (S,G)RPT OIL, undo > the upstream > pruning..." which rule is this? If R4 sends a (S,G)RPT prune to R2, R2 should remove the OIF toward where the prune came in on. more below: > > the solution u propose in > > >http://www.aciri.org/fenner/mcast/pim/sm/issues.html > > > >PIM-SM issue #32: (*,G) joins undoing (S,G) Asserts > > proposes (if i understand correctly) setting up an (S,G)RPT > entry in R4, if R4 is the last hop and it switches, it should not have a (S,G)RPT because there is a (S,G) and will have SPT bit set when data comes in. --Billy > monitoring (S,G)Join/Prune to R1 to refresh/timeout this entry. > > and my question is, why can't we create an (S,G)SPT entry in > R4 instead. > this would result in sending a (S,G) prune to R2 and (S,G) join to R1. > this (S,G)SPT entry has the same incoming interface as the (*,G) entry > but a different upstream neighbor, just as in the solution u > propose to > issue 11. the entry is Refreshed/TimedOut depending on the > data rate, > as is the case with all (S,G)SPT entries. > > i am sorry isidor, but i don't understand your objection to this, > could u please elaborate? > > thanx, > mohit. > > > >-----Original Message----- > > > > > >The solution that we have on this is that after we create (S,G) > >and sending the SPT join to the source as a result of threshold, > >the next data packet will cause the assert to happen. In this > >case, we will check to see whether the upstream neighbors > between the > >(S,G) and (*,G) is the same. If different, then we set the SPT bit > >and generate a (S,G) prune toward the shared tree. > > > >--Billy > > > >-----Original Message----- > >From: Mohit Talwar [mailto:mohitt@Exchange.Microsoft.com] > >Sent: Wednesday, March 01, 2000 8:00 PM > >To: Isidor Kouvelas; Mohit Talwar > >Cc: Chirayu Shah; pim@catarina.usc.edu > >Subject: RE: Question on PIM-SM > > > > > >on the more general problem discussed in... > >http://www.aciri.org/fenner/mcast/pim/sm/issues.html > > > >PIM-SM issue #32: (*,G) joins undoing (S,G) Asserts > > > >"After an (S,G) assert has happened, the DR or (*,G) assert > winner has > >(S,G)RPTbit state with a null oiflist. A (*,G) join from a > downstream > >router can add the interface back on the (S,G)RPTbit > oiflist, undo the > >upstream pruning, and cause even more frequent periodic flooding than > >just the basic assert mechanism does. > > > >Downstream routers that have more general state need to > create (S,G)RPT > >state when receiving Asserts with the RPF neighbor set to the assert > >winner. They can then include (S,G)RPT-bit prunes with their > >(*,G) joins > >so that their periodic (*,G) joins don't undo the Asserts > (in the case > >of multiple upstreams). This will reduce the flooding period > >to the assert > >expiration time." > > > >--- > > > >the solution proposes setting up an (S,G) RPT entry in > >downstream routers > >which would otherwise end up sending (*,G) joins and undoing > >the assert. > >i believe that we can get the same behaviour by creating an > >(S,G)SPT entry! > >this entry would result in sending a (S,G) prune towards the > RP and an > >(S,G) join towards the assert winner. > > > >This does not require monitoring the LAN for (S,G) prunes and seems > >(to me :) to fit better within the existing set of rules > >(which state that > >when the OutgoingInterfaceList of an (S,G)RPT entry is the > >same as that > >of the (*,G), the (S,G) RPT entry should be deleted. > > > >thoughts, please? > >mohit. > > > > > >>-----Original Message----- > >>From: Isidor Kouvelas [mailto:kouvelas@cisco.com] > >>Sent: Wednesday, March 01, 2000 2:33 PM > >>To: Mohit Talwar > >>Cc: Chirayu Shah; pim@catarina.usc.edu > >>Subject: Re: Question on PIM-SM > >> > >> > >> > >>This is addressed in issue 11 on the web page at: > >http://www.aciri.org/fenner/mcast/pim/sm/issues.html > >> > >>thanks > >>Isidor > >> > >> > >>Mohit Talwar writes: > >>>> h1 > >>>> | > >>>> --------r1------ > >>>> | | > >>>> r2 r3 > >>>> | | > >>>> | | > >>>> | r4 > >>>> | | > >>>> | | > >>>> | r5 (RP) > >>>> | | > >>>> ------------------- > >>>> | > >>>> r6 > >>>> | > >>>> h2 > >>>> > >>>>r5 is the RP for 235.1.1.1. > >>>>h1 is the source, h2 is the receiver. > >>>>The shortest path from r6 to h1 is through r2. The following > >>sequence > >>>>of events occur: > >>>>a. h2 joins a group (235.1.1.1) > >>>>b. h1 sends to 235.1.1.1 > >>>>c. After sometime, r6 realizes that the data rate has exceeded > >>>>and switches to SPT (h2->r6->r2->r1->h1). > >>>> > >>>>So finally, r6 has a (*,g) entry and a (s,g)SPT entry. > >>> > >>> > >>>in this scenario, an assert election will take place > >>>on the LAN between r2 and r5. r2 will win since it > >>>has an (S,G) entry while r5 has (*,G). r5 will create > >>>an (S,G)RPT bit entry. > >>>(section 3.5.2, "Receiving Assert on OIF", 1) > >>> > >>>note that r6 will not set the SPT bit for its (s,g) > >>>entry!!! so its JoinPrune message to r5 has only > >>> > >>>> join list: (*,235.1.1.1) > >>> > >>>hope i haven't overlooked anything. > >>>mohit. > >>> > >>> > >>>> > >>>>My question is: what does r6 put in the j/p message that it sends > >>>>to r5? My guess is: > >>>> > >>>> join list: (*,235.1.1.1) > >>>> prune list: (h1,235.1.1.1) with RPT bit set and WC bit cleared > >>>> (an (S,G)RPT prune). > >>>> > >>>>But I couldn't find the section which describes this scenario. > >>>>It would help if someone could point out which rule applies here. > >>>> > >>>>Thanks. > >>>>Chirayu. > >>>> > >>>> > >>> > >> > > > From owner-pim@catarina.usc.edu Thu Mar 2 15:03:10 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24237 for ; Thu, 2 Mar 2000 15:03:08 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA06283 for pim-list; Thu, 2 Mar 2000 11:49:46 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id LAA06278 for ; Thu, 2 Mar 2000 11:49:44 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Mar 2000 10:11:32 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Mar 2000 10:11:32 -0800 Message-ID: <19398D273324D3118A2B0008C7E9A5690A1EFF3F@SIT.platinum.corp.microsoft.com> From: Mohit Talwar To: Billy Ng , cshah@torrentnet.com, kouvelas@cisco.com Cc: pim@catarina.usc.edu Subject: RE: Question on PIM-SM Date: Thu, 2 Mar 2000 10:11:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk hi billy, isidor, i am thinking of S RP . . . . . . R1 R2 | | ------------------ | | R3 R4 Router State RPF-Neighbor R3 (S,G) R1 R4 (*,G) R2 R1 (S,G) towards S R2 (*,G) towards RP an assert election would result in R2 creating an (S,G) RPT bit entry and sending (S,G) prunes upstream (if the OIL of S,G)RPT is NULL). but as per the existing set of rules the JoinPrune message from R4 to R2 would "...add the interface back on the (S,G)RPT OIL, undo the upstream pruning..." the solution u propose in >http://www.aciri.org/fenner/mcast/pim/sm/issues.html > >PIM-SM issue #32: (*,G) joins undoing (S,G) Asserts proposes (if i understand correctly) setting up an (S,G)RPT entry in R4, monitoring (S,G)Join/Prune to R1 to refresh/timeout this entry. and my question is, why can't we create an (S,G)SPT entry in R4 instead. this would result in sending a (S,G) prune to R2 and (S,G) join to R1. this (S,G)SPT entry has the same incoming interface as the (*,G) entry but a different upstream neighbor, just as in the solution u propose to issue 11. the entry is Refreshed/TimedOut depending on the data rate, as is the case with all (S,G)SPT entries. i am sorry isidor, but i don't understand your objection to this, could u please elaborate? thanx, mohit. >-----Original Message----- > > >The solution that we have on this is that after we create (S,G) >and sending the SPT join to the source as a result of threshold, >the next data packet will cause the assert to happen. In this >case, we will check to see whether the upstream neighbors between the >(S,G) and (*,G) is the same. If different, then we set the SPT bit >and generate a (S,G) prune toward the shared tree. > >--Billy > >-----Original Message----- >From: Mohit Talwar [mailto:mohitt@Exchange.Microsoft.com] >Sent: Wednesday, March 01, 2000 8:00 PM >To: Isidor Kouvelas; Mohit Talwar >Cc: Chirayu Shah; pim@catarina.usc.edu >Subject: RE: Question on PIM-SM > > >on the more general problem discussed in... >http://www.aciri.org/fenner/mcast/pim/sm/issues.html > >PIM-SM issue #32: (*,G) joins undoing (S,G) Asserts > >"After an (S,G) assert has happened, the DR or (*,G) assert winner has >(S,G)RPTbit state with a null oiflist. A (*,G) join from a downstream >router can add the interface back on the (S,G)RPTbit oiflist, undo the >upstream pruning, and cause even more frequent periodic flooding than >just the basic assert mechanism does. > >Downstream routers that have more general state need to create (S,G)RPT >state when receiving Asserts with the RPF neighbor set to the assert >winner. They can then include (S,G)RPT-bit prunes with their >(*,G) joins >so that their periodic (*,G) joins don't undo the Asserts (in the case >of multiple upstreams). This will reduce the flooding period >to the assert >expiration time." > >--- > >the solution proposes setting up an (S,G) RPT entry in >downstream routers >which would otherwise end up sending (*,G) joins and undoing >the assert. >i believe that we can get the same behaviour by creating an >(S,G)SPT entry! >this entry would result in sending a (S,G) prune towards the RP and an >(S,G) join towards the assert winner. > >This does not require monitoring the LAN for (S,G) prunes and seems >(to me :) to fit better within the existing set of rules >(which state that >when the OutgoingInterfaceList of an (S,G)RPT entry is the >same as that >of the (*,G), the (S,G) RPT entry should be deleted. > >thoughts, please? >mohit. > > >>-----Original Message----- >>From: Isidor Kouvelas [mailto:kouvelas@cisco.com] >>Sent: Wednesday, March 01, 2000 2:33 PM >>To: Mohit Talwar >>Cc: Chirayu Shah; pim@catarina.usc.edu >>Subject: Re: Question on PIM-SM >> >> >> >>This is addressed in issue 11 on the web page at: >http://www.aciri.org/fenner/mcast/pim/sm/issues.html >> >>thanks >>Isidor >> >> >>Mohit Talwar writes: >>>> h1 >>>> | >>>> --------r1------ >>>> | | >>>> r2 r3 >>>> | | >>>> | | >>>> | r4 >>>> | | >>>> | | >>>> | r5 (RP) >>>> | | >>>> ------------------- >>>> | >>>> r6 >>>> | >>>> h2 >>>> >>>>r5 is the RP for 235.1.1.1. >>>>h1 is the source, h2 is the receiver. >>>>The shortest path from r6 to h1 is through r2. The following >>sequence >>>>of events occur: >>>>a. h2 joins a group (235.1.1.1) >>>>b. h1 sends to 235.1.1.1 >>>>c. After sometime, r6 realizes that the data rate has exceeded >>>>and switches to SPT (h2->r6->r2->r1->h1). >>>> >>>>So finally, r6 has a (*,g) entry and a (s,g)SPT entry. >>> >>> >>>in this scenario, an assert election will take place >>>on the LAN between r2 and r5. r2 will win since it >>>has an (S,G) entry while r5 has (*,G). r5 will create >>>an (S,G)RPT bit entry. >>>(section 3.5.2, "Receiving Assert on OIF", 1) >>> >>>note that r6 will not set the SPT bit for its (s,g) >>>entry!!! so its JoinPrune message to r5 has only >>> >>>> join list: (*,235.1.1.1) >>> >>>hope i haven't overlooked anything. >>>mohit. >>> >>> >>>> >>>>My question is: what does r6 put in the j/p message that it sends >>>>to r5? My guess is: >>>> >>>> join list: (*,235.1.1.1) >>>> prune list: (h1,235.1.1.1) with RPT bit set and WC bit cleared >>>> (an (S,G)RPT prune). >>>> >>>>But I couldn't find the section which describes this scenario. >>>>It would help if someone could point out which rule applies here. >>>> >>>>Thanks. >>>>Chirayu. >>>> >>>> >>> >> > From owner-pim@catarina.usc.edu Thu Mar 2 17:31:22 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29984 for ; Thu, 2 Mar 2000 17:31:21 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA06930 for pim-list; Thu, 2 Mar 2000 14:18:59 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA06925 for ; Thu, 2 Mar 2000 14:18:57 -0800 (PST) Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA28755; Thu, 2 Mar 2000 14:19:00 -0800 (PST) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA11135; Thu, 2 Mar 2000 14:18:09 -0800 (PST) Message-Id: <200003022218.OAA11135@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Mohit Talwar cc: Billy Ng , cshah@torrentnet.com, kouvelas@cisco.com, pim@catarina.usc.edu Subject: Re: Question on PIM-SM In-reply-to: Your message of "Thu, 02 Mar 2000 10:11:31 PST." <19398D273324D3118A2B0008C7E9A5690A1EFF3F@SIT.platinum.corp.microsoft.com> Date: Thu, 02 Mar 2000 14:18:09 -0800 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk Your proposal does not work in the topology below: RP . . R1 | ------------------- | | | R2 R3 R4---- Receiver . . . . Source Assume: - R2 needs to stay on the shared tree because it has more receivers behind it. - The shortest path to the source from the point of R4 is through R3. - The shortest path from R2 to the source is not through the LAN. Here R2 is the router that needs to create the (S,G)RPT state when the assert is sent. You cannot create (S,G) state because it will have a different RPF interface. thanks Isidor Mohit Talwar writes: >hi billy, isidor, > >i am thinking of > > S RP > . . > . . > . . > R1 R2 > | | >------------------ > | | > R3 R4 > >Router State RPF-Neighbor >R3 (S,G) R1 >R4 (*,G) R2 >R1 (S,G) towards S >R2 (*,G) towards RP > >an assert election would result in R2 creating an (S,G) RPT bit entry >and sending (S,G) prunes upstream (if the OIL of S,G)RPT is NULL). but >as per the existing set of rules the JoinPrune message from R4 to R2 >would "...add the interface back on the (S,G)RPT OIL, undo the upstream >pruning..." > >the solution u propose in > >>http://www.aciri.org/fenner/mcast/pim/sm/issues.html >> >>PIM-SM issue #32: (*,G) joins undoing (S,G) Asserts > >proposes (if i understand correctly) setting up an (S,G)RPT entry in R4, >monitoring (S,G)Join/Prune to R1 to refresh/timeout this entry. > >and my question is, why can't we create an (S,G)SPT entry in R4 instead. >this would result in sending a (S,G) prune to R2 and (S,G) join to R1. >this (S,G)SPT entry has the same incoming interface as the (*,G) entry >but a different upstream neighbor, just as in the solution u propose to >issue 11. the entry is Refreshed/TimedOut depending on the data rate, >as is the case with all (S,G)SPT entries. > >i am sorry isidor, but i don't understand your objection to this, >could u please elaborate? > >thanx, >mohit. From owner-pim@catarina.usc.edu Mon Mar 6 11:53:22 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14357 for ; Mon, 6 Mar 2000 11:53:21 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA26247 for pim-list; Mon, 6 Mar 2000 08:40:19 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA26242 for ; Mon, 6 Mar 2000 08:40:17 -0800 (PST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Mon, 6 Mar 2000 11:37:48 -0500 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G2B0KJ90; Mon, 6 Mar 2000 11:28:14 -0500 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FXSMFB50; Mon, 6 Mar 2000 11:28:06 -0500 Message-ID: <38C3DC39.918BCFCA@nortelnetworks.com> Date: Mon, 06 Mar 2000 11:26:33 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: PIM Mailing List Subject: Updated PIM over IPv6 draft Content-Type: multipart/mixed; boundary="------------527E13FA5571A00D6EC67235" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------527E13FA5571A00D6EC67235 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I have updated the PIM over IPv6 draft and submitted it to the I-D editor. The major change in this revision is how the PIM header checksum is calculated. Please direct comments to either the authors or the mailing list. Thanks, Brian -- Brian Haberman Nortel Networks haberman@nortelnetworks.com --------------527E13FA5571A00D6EC67235 Content-Type: text/plain; charset=us-ascii; name="pimv6.txt" Content-Disposition: inline; filename="pimv6.txt" Content-Transfer-Encoding: 7bit PIM Working Group B. Haberman Internet Draft H. Sandick draft-ietf-pim-ipv6-03.txt Nortel Networks November 1999 G. Kump Expires May 2000 IBM Protocol Independent Multicast Routing in the Internet Protocol Version 6 (IPv6) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document outlines recommendations in the use of the Protocol Independent Multicast routing protocol to support Internet Protocol version 6. It describes the changes needed in order to handle the differences between IPv6 and IPv4 and conform to the logic introduced by other routing protocols enabled for IPv6. 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Introduction This document describes protocol clarifications within the Protocol Independent Multicast routing protocol [PIM-SM, PIM-DM] for efficiently routing to multicast groups communicating with the Internet Protocol version 6 (IPv6) [RFC 2460]. This document will only describe recommendations for making PIM conform to practices implemented by other IPv6 routing protocols. The existing PIM drafts should be referenced for actual protocol operation. Haberman, Sandick, Kump 1 Internet Draft PIM for IPv6 November 1999 3. Definitions and Assumptions - Link Local Address: A local-use, non-routable unicast IPv6 address [RFC 2373] - All-PIM-Routers multicast address: A permanently assigned link- scoped IPv6 multicast address for the PIM protocol [RFC 2375] It is assumed that a router running PIM for IPv6 will have a network unique, domain-wide reachable IPv6 address that will be used for multiple hop messages. 4. Protocol Impact The following will outline changes to the values used in the PIM protocol messages in order to utilize standard IPv6 protocol features. All messages will be affected by the change to the checksum field in the PIM header. For most messages, other changes involve the addresses used in the IPv6 and PIM headers. 4.1 PIM Header Checksum The checksum field in the PIM [RFC 2375] header covers the entire PIM message. When running PIM over IPv6, it must use the standard checksum calculation for IPv6 applications: the 16-bit one's complement of the one's complement sum of the entire contents of the packet, starting with the PIM packet header, and prepending a "pseudo-header" of IPv6 header fields, as specified in [RFC 2460, section 8.1]. The "Upper- Layer Packet Length" in the pseudo-header is set to the length of the PIM message. The Next Header value used in the pseudo-header is 103. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before performing the checksum calculation. Before computing the checksum, the checksum field in the PIM packet header is set to 0. 4.2 Hello Message When sending a Hello Message, a PIM router must use a different set of IPv6 addresses in the IPv6 header. The IPv6 destination address must be the All-PIM-Routers multicast address. The IPv6 source address must be the IPv6 link local address of the interface on which the message is being forwarded. The link local address in the source address field will be used to determine neighbor adjacency and for Designated Router (DR) election. 4.3 Register Message The Register Message is addressed to the domain-wide reachable IPv6 address of the Rendezvous Point (RP). The source address of the message is the domain-wide reachable IPv6 address of the DR. The DR sending the Register Message obtains the domain-wide reachable IPv6 address of the RP from the local RP-set information. 4.4 Register-Stop Message Haberman, Sandick, Kump 2 Internet Draft PIM for IPv6 November 1999 The Register-Stop Message is addressed in the same manner as the Register Message. The RP addresses the message to the domain-wide reachable IPv6 address of the DR. The source address is the domain- wide reachable address of the RP. The RP obtains the domain-wide reachable address of the DR from the source address field of the Register Message received from the DR. 4.5 Join/Prune, Graft, and Graft-Ack Messages In the transmission of a Join/Prune, Graft, or Graft-Ack Message, a router sets the IPv6 destination address to the All-PIM-Routers multicast address. The IPv6 source address is set to the link local address of the interface on which the message is forwarded. The Upstream Neighbor Address field is set to the link local address of the next hop router, which is obtained from the RPF lookup. If a link local address cannot be obtained for the upstream neighbor, the Upstream Neighbor Address field is set to a known IPv6 address for that neighbor. 4.6 Bootstrap Message When sending a Bootstrap Message, a PIM router sets the IPv6 destination address field to the All-PIM-Routers multicast address. The source address is set to the link local address of the interface on which the message is forwarded. The Bootstrap Router (BSR) Address is set to the domain-wide reachable IPv6 address of the BSR. 4.7 Assert Message The Assert Message has an IPv6 destination address of the All-PIM- Routers multicast address and an IPv6 source address of the link local address of the interface forwarding the message. The link local address in the IPv6 source address field is used to resolve ties in the assert process. Downstream routers save the winning assert router's link local address to resolve any future RPF requirements. 4.8 Candidate-RP-Advertisement Message The Candidate-RP-Advertisement Message uses the domain-wide reachable IPv6 address of the BSR as the IPv6 destination address. The source address is a domain-wide reachable IPv6 address unique to the candidate RP. The RP Address field is set to a domain-wide reachable IPv6 address of the candidate RP. Each candidate RP router creates this message and unicasts it to the BSR. 5. IPv6 Address Scoping With the introduction of scoped addresses in IPv6, new issues arise in the distribution of scoped routes and the forwarding of packets containing scoped addresses. With regards to the PIM protocol, the main scoping issue involves the bootstrap mechanism. The bootstrap mechanism is a centralized function, e.g. there is one bootstrap server per PIM domain. If the PIM-SM domain is not a subset of the scoped address domain then the bootstrap mechanism, in its current form, cannot support scoped RP addresses and scoped group addresses. Haberman, Sandick, Kump 3 Internet Draft PIM for IPv6 November 1999 Therefore, in order for the bootstrap mechanism to function properly, the PIM domain must be a subset of the scoped address domain or all multiple hop messages must use globally reachable IPv6 addresses. 6. Security Considerations This document does not introduce any protocol changes that require additional security considerations above and beyond those described in the PIM protocol specifications. 7. References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1999. [PIM-SM] L. Wei, et. al, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", draft-ietf-pim-v2-sm-00.txt, October 1999. [PIM-DM] L. Wei, et. al, "Protocol Independent Multicast Version 2 Dense Mode Specification", draft-ietf-pim-v2-dm-03.txt, June 1999. [RFC 2460] R. Hinden and S. Deering, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC 2375] R. Hinden and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998. Haberman, Sandick, Kump 4 Authors' Addresses Brian Haberman Hal Sandick Nortel Networks 4309 Emperor Blvd. Suite 200 Durham, NC 27703 1-919-992-4439 1-919-992-9046 Email : haberman@nortelnetworks.com Email : hsandick@nortelnetworks.com Garry Kump IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 1-919-254-2395 Email: kump@us.ibm.com Haberman, Sandick, Kump 5 --------------527E13FA5571A00D6EC67235-- From owner-pim@catarina.usc.edu Mon Mar 6 20:09:55 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16047 for ; Mon, 6 Mar 2000 20:09:54 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA28786 for pim-list; Mon, 6 Mar 2000 16:50:41 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA28781; Mon, 6 Mar 2000 16:50:38 -0800 (PST) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id QAA57191; Mon, 6 Mar 2000 16:50:57 -0800 (PST) Message-Id: <200003070050.QAA57191@rumi.usc.edu> To: "Brian Haberman" cc: PIM Mailing List Subject: Re: Updated PIM over IPv6 draft In-reply-to: Your message of "Mon, 06 Mar 2000 11:26:33 EST." <38C3DC39.918BCFCA@nortelnetworks.com> Date: Mon, 06 Mar 2000 16:50:57 -0800 From: Pavlin Ivanov Radoslavov Sender: owner-pim@catarina.usc.edu Precedence: bulk > All, > I have updated the PIM over IPv6 draft and > submitted it to the I-D editor. The major change > in this revision is how the PIM header checksum > is calculated. Please direct comments to either > the authors or the mailing list. > > Thanks, > Brian > > -- > Brian Haberman > Nortel Networks > haberman@nortelnetworks.com > 4.1 PIM Header Checksum > > The checksum field in the PIM [RFC 2375] header covers the > entire PIM ~~~~~~~~~~ Isn't this suppose to be a reference to RFC 2362 (the PIM-SM RFC) and to the PIM-DM spec? Also, the PIM-SM spec says that the data portion in the Register messages is excluded from the checksum (without distinguishing between IPv4 and IPv6). Does this draft overwrites this rule by saying that the PIM Register checksum for IPv6 should include the data portion? Thanks, Pavlin From owner-pim@catarina.usc.edu Tue Mar 7 09:03:47 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04275 for ; Tue, 7 Mar 2000 09:03:45 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id FAA31361 for pim-list; Tue, 7 Mar 2000 05:46:18 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id FAA31355; Tue, 7 Mar 2000 05:46:16 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Tue, 7 Mar 2000 07:46:19 -0600 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G2D8MA7Z; Tue, 7 Mar 2000 07:44:47 -0600 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FXSMFD82; Tue, 7 Mar 2000 08:44:48 -0500 Message-ID: <38C50776.94F293B4@nortelnetworks.com> Date: Tue, 07 Mar 2000 08:43:19 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Pavlin Ivanov Radoslavov CC: PIM Mailing List Subject: Re: Updated PIM over IPv6 draft References: <200003070050.QAA57191@rumi.usc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pavlin, Pavlin Ivanov Radoslavov wrote: > > 4.1 PIM Header Checksum > > > > The checksum field in the PIM [RFC 2375] header covers the > > entire PIM > ~~~~~~~~~~ > > Isn't this suppose to be a reference to RFC 2362 (the PIM-SM RFC) > and to the PIM-DM spec? Yes, it should be the PIM specs. > > Also, the PIM-SM spec says that the data portion in the Register > messages is excluded from the checksum (without distinguishing > between IPv4 and IPv6). Does this draft overwrites this rule by > saying that the PIM Register checksum for IPv6 should include the > data portion? No, the only change to the checksum field is to include the pseudo-IP header. Thanks, Brian -- Brian Haberman Nortel Networks haberman@nortelnetworks.com From owner-pim@catarina.usc.edu Fri Mar 10 06:35:52 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01919 for ; Fri, 10 Mar 2000 06:35:51 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id DAA48050 for pim-list; Fri, 10 Mar 2000 03:30:39 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id DAA48045 for ; Fri, 10 Mar 2000 03:30:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29443; Fri, 10 Mar 2000 06:30:13 -0500 (EST) Message-Id: <200003101130.GAA29443@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pim@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pim-bidir-00.txt Date: Fri, 10 Mar 2000 06:30:12 -0500 Sender: owner-pim@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Bi-directional Protocol Independent Multicast Author(s) : M. Handley, I. Kouvelas, L. Vicisano Filename : draft-ietf-pim-bidir-00.txt Pages : 22 Date : 09-Mar-00 This document discusses Bi-directional PIM, a variant of PIM Sparse- Mode [1] that builds bi-directional shared trees connecting multicast sources and receivers. Bi-directional trees are built using a fail- safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multi- cast data is natively forwarded from sources to the Rendezvous-Point without requiring source-specific state. The DF election takes place at RP discovery time and provides a default route to the RP thus eliminating the requirement for data-driven protocol events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-bidir-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-bidir-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-ietf-pim-bidir-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000309140414.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-bidir-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-bidir-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309140414.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pim@catarina.usc.edu Fri Mar 10 09:52:28 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08791 for ; Fri, 10 Mar 2000 09:52:23 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id GAA48629 for pim-list; Fri, 10 Mar 2000 06:45:22 -0800 (PST) Received: from sophia.inria.fr (root@sophia.inria.fr [138.96.32.20]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id GAA48624 for ; Fri, 10 Mar 2000 06:45:13 -0800 (PST) Received: from sophia.inria.fr by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id PAA10295 for ; Fri, 10 Mar 2000 15:44:39 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host ra.inria.fr [138.96.32.72] claimed to be sophia.inria.fr Message-ID: <38C90978.1FE14934@sophia.inria.fr> Date: Fri, 10 Mar 2000 15:40:56 +0100 From: Fethi Filali Organization: INRIA Sophia-Antipolis X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.9-19mdk i586) X-Accept-Language: en MIME-Version: 1.0 To: pim@catarina.usc.edu Subject: C-RPs and C-BSR Priorities Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit hi, How priority value is computed for a candidate-BSR and how priority value is computed for a candidate-RP when it sends a Candidate-RP-Advertisement to the BSR. Are these priorities should be equal to the DR-priorities or there is another policy used. It was not indicated neither in the RFC nor in the last draft. Fethi. -- ~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~ | Fethi Filali | http://www.inria.fr/rodeo/filali | | PhD Student, INRIA | Office Phone:(+334/04) 92 38 76 70 | | Fax:(+334/04) 92 38 79 78 | Mobile Phone:(+336/06) 20 32 85 73 | ~-------------------------------------------------------------------~ From owner-pim@catarina.usc.edu Tue Mar 14 06:27:36 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22920 for ; Tue, 14 Mar 2000 06:27:34 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id DAA98283 for pim-list; Tue, 14 Mar 2000 03:21:45 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id DAA98278 for ; Tue, 14 Mar 2000 03:21:43 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20192; Tue, 14 Mar 2000 06:21:13 -0500 (EST) Message-Id: <200003141121.GAA20192@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pim@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pim-ipv6-03.txt Date: Tue, 14 Mar 2000 06:21:13 -0500 Sender: owner-pim@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Protocol Independent Multicast Routing in the Internet Protocol Version 6 (IPv6) Author(s) : H. Sandick, G. Kump, B. Haberman Filename : draft-ietf-pim-ipv6-03.txt Pages : 5 Date : 13-Mar-00 This document outlines recommendations in the use of the Protocol Independent Multicast routing protocol to support Internet Protocol version 6. It describes the changes needed in order to handle the differences between IPv6 and IPv4 and conform to the logic introduced by other routing protocols enabled for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-ipv6-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-ipv6-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-ipv6-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000313140000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-ipv6-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-ipv6-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000313140000.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pim@catarina.usc.edu Tue Mar 14 11:06:25 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11948 for ; Tue, 14 Mar 2000 11:06:23 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA99255 for pim-list; Tue, 14 Mar 2000 08:00:44 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA99250 for ; Tue, 14 Mar 2000 08:00:43 -0800 (PST) Received: from garnet.juniper.net (garnet.juniper.net [208.197.169.237]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id HAA07704 for ; Tue, 14 Mar 2000 07:59:44 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id HAA71728 for ; Tue, 14 Mar 2000 07:59:44 -0800 (PST) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200003141559.HAA71728@garnet.juniper.net> To: pim@catarina.usc.edu Subject: No PIM working group meeting MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71725.953049584.1@garnet.juniper.net> Date: Tue, 14 Mar 2000 07:59:44 -0800 From: Tom Pusateri Sender: owner-pim@catarina.usc.edu Precedence: bulk We're not planning on having a PIM meeting in Adelaide since the only topics I've heard mention of are also going to be played in other working group meetings. We're in an unusual state right now since most of the primary PIM document authors have moved on to start-ups or other things and new people are needed to back-fill those roles. Hopefully we will see some forward progress on the documents real soon now but if we don't, we might want to consider publishing what we have as informational or experimental. If you have an interest and putting a bit of effort into the documents please contact myself or Liming. Thanks, Tom From owner-pim@catarina.usc.edu Tue Mar 14 11:29:06 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21173 for ; Tue, 14 Mar 2000 11:29:02 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA99479 for pim-list; Tue, 14 Mar 2000 08:24:01 -0800 (PST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA99472 for ; Tue, 14 Mar 2000 08:23:56 -0800 (PST) Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA25181; Tue, 14 Mar 2000 08:48:24 -0800 (PST) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id IAA16662; Tue, 14 Mar 2000 08:22:52 -0800 (PST) Message-Id: <200003141622.IAA16662@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Tom Pusateri cc: pim@catarina.usc.edu Subject: Re: No PIM working group meeting In-reply-to: Your message of "Tue, 14 Mar 2000 07:59:44 PST." <200003141559.HAA71728@garnet.juniper.net> Date: Tue, 14 Mar 2000 08:22:52 -0800 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk I would like to present some of the issues we have found with the PIM-SM draft. There are several serious problems with the current draft and feedback from the working group on the proposed solutions would be helpful. The complete set of issues can be found on the web page at: http://www.aciri.org/fenner/mcast/pim/sm/issues.html thanks Isidor Tom Pusateri writes: >We're not planning on having a PIM meeting in Adelaide since >the only topics I've heard mention of are also going to be >played in other working group meetings. > >We're in an unusual state right now since most of the primary >PIM document authors have moved on to start-ups or other things >and new people are needed to back-fill those roles. > >Hopefully we will see some forward progress on the documents >real soon now but if we don't, we might want to consider >publishing what we have as informational or experimental. > >If you have an interest and putting a bit of effort into >the documents please contact myself or Liming. > >Thanks, >Tom From owner-pim@catarina.usc.edu Tue Mar 14 11:36:00 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24199 for ; Tue, 14 Mar 2000 11:35:58 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA99627 for pim-list; Tue, 14 Mar 2000 08:31:49 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA99622 for ; Tue, 14 Mar 2000 08:31:48 -0800 (PST) Received: from garnet.juniper.net (garnet.juniper.net [208.197.169.237]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id IAA11334; Tue, 14 Mar 2000 08:30:49 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id IAA73086; Tue, 14 Mar 2000 08:30:48 -0800 (PST) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200003141630.IAA73086@garnet.juniper.net> To: Isidor Kouvelas cc: Tom Pusateri , pim@catarina.usc.edu, pusateri@juniper.net Subject: Re: No PIM working group meeting In-Reply-To: Message from Isidor Kouvelas of "Tue, 14 Mar 2000 08:22:52 PST." <200003141622.IAA16662@kouvelas-u10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <73081.953051448.1@garnet.juniper.net> Date: Tue, 14 Mar 2000 08:30:48 -0800 From: Tom Pusateri Sender: owner-pim@catarina.usc.edu Precedence: bulk How much time would you like. The other topics I heard of were: PIM-SO Trials from Sprintlabs PIM Lite from Cain/Sandick PIM for IPv6 from Habermann Can these peole send time estimates as well? Thanks, Tom In message <200003141622.IAA16662@kouvelas-u10.cisco.com> you write: > >I would like to present some of the issues we have found with the >PIM-SM draft. There are several serious problems with the current >draft and feedback from the working group on the proposed solutions >would be helpful. The complete set of issues can be found on the web >page at: http://www.aciri.org/fenner/mcast/pim/sm/issues.html > >thanks >Isidor > > >Tom Pusateri writes: >>We're not planning on having a PIM meeting in Adelaide since >>the only topics I've heard mention of are also going to be >>played in other working group meetings. >> >>We're in an unusual state right now since most of the primary >>PIM document authors have moved on to start-ups or other things >>and new people are needed to back-fill those roles. >> >>Hopefully we will see some forward progress on the documents >>real soon now but if we don't, we might want to consider >>publishing what we have as informational or experimental. >> >>If you have an interest and putting a bit of effort into >>the documents please contact myself or Liming. >> >>Thanks, >>Tom From owner-pim@catarina.usc.edu Tue Mar 14 13:48:03 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16269 for ; Tue, 14 Mar 2000 13:47:56 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA00877 for pim-list; Tue, 14 Mar 2000 10:43:21 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from siara.com (netscreen [209.10.58.71] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA00872 for ; Tue, 14 Mar 2000 10:43:20 -0800 (PST) Received: from yoo-hoo.mtv.siara.com (yoo-hoo.mtv.siara.com [192.168.40.63]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id KAA04395; Tue, 14 Mar 2000 10:41:20 -0800 (PST) Received: (from lwei@localhost) by yoo-hoo.mtv.siara.com (8.9.3-LCCHA/8.9.3/lccha Siara client 1.6) id KAA23729; Tue, 14 Mar 2000 10:41:20 -0800 (PST) Date: Tue, 14 Mar 2000 10:41:20 -0800 (PST) Message-Id: <200003141841.KAA23729@yoo-hoo.mtv.siara.com> From: Liming Wei To: pim@catarina.usc.edu Cc: pusateri@juniper.net In-reply-to: <200003141559.HAA71728@garnet.juniper.net> (message from Tom Pusateri on Tue, 14 Mar 2000 07:59:44 -0800) Subject: Re: No PIM working group meeting Reply-to: lwei@redback.com Sender: owner-pim@catarina.usc.edu Precedence: bulk Folks, I will not be going to Australia for the next IETF, but will review draft submissions for the working group. Tom has agreed to run the next meeting. WRT to the spec updates, I have not been able to keep up with all the inquiries in the past couple of months. We have convinced Yiqun Cai (ycai@cisco.com), a veteran in multicast routing, to act as the primary editor, while I serve as a co-editor. Yiqun has started to work on the spec, but please keep in mind that he also has a day job. The plan is to complete another revision before the next IETF after the current one. Our priority is still to clarify the spec, correct remaining mistakes, and filling in missing pieces. We do not plan to put in any new mechanisms in the PIM version 2 spec. We will try to cover questions raised by members of the WG, on the WG mailing list or via individual emails. Thanks, -Liming ---------- > From: Tom Pusateri > > We're not planning on having a PIM meeting in Adelaide since > the only topics I've heard mention of are also going to be > played in other working group meetings. > > We're in an unusual state right now since most of the primary > PIM document authors have moved on to start-ups or other things > and new people are needed to back-fill those roles. > > Hopefully we will see some forward progress on the documents > real soon now but if we don't, we might want to consider > publishing what we have as informational or experimental. > > If you have an interest and putting a bit of effort into > the documents please contact myself or Liming. > > Thanks, > Tom > From owner-pim@catarina.usc.edu Tue Mar 14 16:09:43 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12551 for ; Tue, 14 Mar 2000 16:09:42 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA01882 for pim-list; Tue, 14 Mar 2000 13:05:22 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA01877 for ; Tue, 14 Mar 2000 13:05:21 -0800 (PST) Received: from garnet.juniper.net (garnet.juniper.net [208.197.169.237]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id NAA02539; Tue, 14 Mar 2000 13:03:58 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id NAA83709; Tue, 14 Mar 2000 13:03:58 -0800 (PST) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200003142103.NAA83709@garnet.juniper.net> To: Tom Pusateri cc: pim@catarina.usc.edu, pusateri@juniper.net Subject: Re: No PIM working group meeting In-Reply-To: Message from Tom Pusateri of "Tue, 14 Mar 2000 07:59:44 PST." <200003141559.HAA71728@garnet.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83706.953067838.1@garnet.juniper.net> Date: Tue, 14 Mar 2000 13:03:58 -0800 From: Tom Pusateri Sender: owner-pim@catarina.usc.edu Precedence: bulk Well, the scheduling people say we missed the cutoff and we can't get a time slot. Unless you hear otherwise, it looks like we can't have a meeting even if we wanted to. Tom From owner-pim@catarina.usc.edu Wed Mar 15 22:48:18 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28285 for ; Wed, 15 Mar 2000 22:48:17 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA12163 for pim-list; Wed, 15 Mar 2000 19:43:20 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id TAA12158 for ; Wed, 15 Mar 2000 19:43:19 -0800 (PST) Received: from localhost (nbhaskar@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA27149; Wed, 15 Mar 2000 19:42:17 -0800 (PST) Message-Id: <200003160342.TAA27149@omega.cisco.com> To: pim@catarina.usc.edu cc: nbhaskar@cisco.com, kouvelas@cisco.com Subject: Source-Specific PIM draft Date: Wed, 15 Mar 2000 19:42:17 -0800 From: Nidhi Bhaskar Sender: owner-pim@catarina.usc.edu Precedence: bulk The following draft has been submitted to the ID directories and will be presented in the Adelaide IETF. Thanks, Nidhi. ---------------------------------------------------------------------- INTERNET-DRAFT PIM-SS Nidhi Bhaskar Expires 10 September 2000 cisco Systems Isidor Kouvelas cisco Systems 10 March, 2000 Source-Specific Protocol Independent Multicast Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Source-Specific PIM (PIM-SS) is a variant of PIM Sparse-Mode that only builds source specific shortest path trees. These trees are built directly on receiving group membership reports that request a given source. PIM-SS precludes the building of shared trees, effectively par- titioning the different source trees from one another. For this reason it is specifically suited for existing multicast applications for which there is expected and intended to be exactly one source. Source-Specific PIM can co-exist with PIM-SM. It uses a subset of PIM-SM messages and lends itself to incremental deployment. Bhaskar, Kouvelas [Page 1] INTERNET-DRAFT PIM-SS 10 March 2000 Table of Contents Abbreviations ..................................................... 3 1. Introduction .................................................. 4 2. Definitions ................................................... 4 3. Protocol Details .............................................. 5 4. PIM-SS Packet Formats ......................................... 7 5. Interoperability with legacy routers .......................... 8 6. Security Considerations ....................................... 9 References ........................................................ 10 Bhaskar, Kouvelas [Page 2] INTERNET-DRAFT PIM-SS 10 March 2000 Abbreviations PIM Protocol Independent Multicast SSM Source-Specific Multicast [1] SM Sparse Mode SS Source-Specific RP Rendezvous Point DR Designated Router Bhaskar, Kouvelas [Page 3] INTERNET-DRAFT PIM-SS 10 March 2000 1. Introduction PIM Sparse Mode [2] Designated Routers (DR) with local membership rely on the shared Rendezvous Point (RP) tree to learn about active sources for a group. In most cases the DR switches to the shortest path tree for source S when it receives a data packet from S via the shared tree. It then prunes the source S off the shared tree to eliminate duplicates. Additional mechanisms, like Register messages/MSDP, are required to inform the RP of active sources. Joining the shared tree is important to support the many-to-many multi- cast model of RFC 1112 where the set of sources can vary during the lifetime of the session. However, if the application requires that only a single well-known source be allowed to send to a group, the complexity of setting up a shared tree to learn about this source is unnecessary. Even worse, it does not provide the correct service model as it allows any host to send to the group. A large portion of existing multicast content has exactly one source with a well-known address. Clearly, if this source address can be pro- vided to the last hop DR with the initial group membership request by the host it would be much more efficient for the DR to immediately build a shortest path tree to the source. Since source trees for multiple sources sending to the same group address are independent of each other, this is especially suited for one-to-many communication. This document describes a simplified version of PIM-Sparse Mode (PIM-SM) to support these one-to-many applications. We refer to this variant as Source-Specific PIM (PIM-SS). PIM-SS in conjunction with the IGMPv3 extensions for Source-Specific Multicast described in [1] provides the Source-Specific Multicast service model [1] suitable for one-to-many communication. The rest of this document in organized into 6 sections. Section 2 has some Definitions, section 3 describes PIM-SS operation, section 4 details packet formats, section 5 describes interoperability considera- tions in the presence of legacy routers and finally section 6 discusses security issues. 2. Definitions SSM is the Source-Specific Multicast model described in [1]. The SSM range refers to any class D address range designated for SSM. Unless otherwise stated, all PIM-SS protocol actions are used for groups in the SSM range. A source specific membership report is a request to join a group G that Bhaskar, Kouvelas [Page 4] INTERNET-DRAFT PIM-SS 10 March 2000 also specifies the source the host is interested in. IGMP v3 INCLUDE {srclist} report is an example. This document assumes that the reader is familiar with the PIM-SM proto- col [2]. In particular, the concepts of (S,G) and (*,G) state and their component fields (olist, iif, ...) are used. Unless otherwise stated, an (S,G) entry in this text refers to (S,G) state with RP-bit set to 0. I.e., (S,G) state associated with the source specific shortest path tree. Also, none of the PIM-SM rules for the SPT-bit associated with an (S,G) entry are applicable to PIM-SS. In this document "Standard PIM-SM SPT procedures" refers to the subset of PIM-SM protocol actions that are associated with source trees as defined in [2] Unless otherwise stated, (S,G) Join/Prune messages are associated with the source specific shortest path tree, i.e., have the WC and RPT bits set to 0. Finally, default values for relevant timers are the ones given in [2]. 3. Protocol Details PIM-SS is a sparse mode protocol that ONLY builds source specific shor- test path trees. PIM-SS uses a subset of standard PIM-SM messages [2] to set up these distribution trees. A last hop DR is responsible for ori- ginating (S,G) Join/Prune messages in response to source specific membership reports. Intermediate PIM-SS routers propagate these (S,G) Join/Prune messages towards the source. PIM-SS SHOULD be used for group ranges designated for SSM [1]. In most deployment scenarios PIM-SS will co-exist with other flavors of PIM operating in different group address ranges. 3.1. Tree Building and Maintenance This section specifies the rules for creation and maintenance of the shortest path trees. 3.1.1. Joining the Source Tree On receiving membership indication for a given source and group the fol- lowing actions are taken by a last hop DR: o If no (S,G) state exists for the source and group, then an (S,G) entry is created. Bhaskar, Kouvelas [Page 5] INTERNET-DRAFT PIM-SS 10 March 2000 o The interface on which the membership report was received is added to the olist of the (S,G) entry iff it is not the same as the incoming interface. o A triggered (S,G) Join is sent to the RPF neighbour for the source if the olist transitioned from Null to non-Null OR if membership indica- tion on the iif for the source resulted in the creation of the (S,G) entry. o Standard PIM-SM SPT procedures [2] are used to update timers associ- ated with the (S,G) entry. Note, that no actions associated with the SPT-bit are taken for the route entry. o In addition, the (S,G) entry is kept alive as long as there is reported membership for that source and group. A PIM-SS router MUST ignore all non-source-specific membership reports (such as IGMP v2 host reports) for groups in the SSM range. On receiving a PIM (S,G) Join for some SSM group G the router takes the following actions: o If no (S,G) entry exists, it creates one. o The interface on which the Join was received is added to the olist of the (S,G) entry iff it is not the same as the incoming interface. o Standard PIM-SM SPT procedures are used for updating timers and ori- ginating an (S,G) Join for the upstream PIM neighbour towards the source. 3.1.2. Leaving the Source Tree On receiving notification that no local members on an interface wish to receive traffic for a source and group, the DR takes the following actions: o It uses Standard PIM-SM SPT procedures for removing the interface from the olist. All actions are associated with the corresponding (S,G) entry. o Additionally, if the olist for the (S,G) entry goes to NULL AND there is no local membership on the RPF interface towards the source, the DR triggers an (S,G) Prune towards the upstream PIM neighbour. On receiving an (S,G) Prune from its downstream neighbour a PIM-SS router uses Standard PIM-SM SPT procedures for originating (S,G) Prunes, updating timers and updating the olist of the entry. Bhaskar, Kouvelas [Page 6] INTERNET-DRAFT PIM-SS 10 March 2000 3.1.3. Tree Maintenance In the steady state all PIM-SS routers follow the standard PIM-SM SPT maintenance rules. In addition, PIM-SS routers MUST continue to ori- ginate periodic (S,G) Joins for an (S,G) entry with a NULL olist if there is local membership on the iif of the entry. Standard PIM-SM SPT procedures are used in the event of a unicast rout- ing change. However, any rules associated with the SPT-bit for the (S,G) route entry do not apply. 3.1.4. Operation over Multi-Access Networks DR election procedures are the same as those specified for PIM-SM in [2]. Standard PIM-SM Join/Prune suppression SHOULD be used for (S,G) Join/Prune messages. The standard PIM-SM Assert mechanism MUST be used to resolve multiple cases when multiple forwarders send (S,G) traffic to the same LAN. Note, however, that all Asserts originated by PIM-SS routers are associated with source trees and MUST always have the MSB of the metric preference (RPT bit) set to 0. 3.2. Multicast Data Packet Processing On receiving a data packet with source address S destination address G, a PIM-SS router MUST perform an exact-match lookup in its forwarding database for S and G. If no matching (S,G) entry is found the packet MUST be dropped. Note that this is different from the longest match lookup done in PIM-SM. If a matching (S,G) entry is found a standard PIM iif check MUST be per- formed. If the packet fails, it MUST be dropped, otherwise the packet MUST be forwarded out all interfaces in the entry's olist. 3.3. Inter-Domain Multicast PIM-SS only builds source-specific shortest-path trees towards the source. Therefore, no additional protocol mechanisms, such as MSDP, are required for inter-domain multicast. 4. PIM-SS Packet Formats The following subset of PIM-SM messages defined in [2] is used by PIM- SS: Bhaskar, Kouvelas [Page 7] INTERNET-DRAFT PIM-SS 10 March 2000 o PIM Hello o PIM Join/Prune o PIM Assert The packet formats for these messages are those specified in [2]. In addition PIM-SS Join/Prune messages MUST have the WC and RP bits set to 0. And PIM-SS Assert messages MUST have the MSB of the metric preference field, the RPT bit, set to 0. 5. Interoperability with legacy routers This section covers the rules for operating in the presence of legacy PIM routers. In the most common deployment scenario domains will incre- mentally upgrade routers and run both PIM-SS and other flavors of PIM but in different group ranges. For PIM-SS to work in this scenario legacy PIM routers MUST consider the SSM range to be sparse. This is because PIM-SM routers can understand the compatible PIM-SS (S,G) Joins/Prune messages and propagate them upstream. This makes it possible to deploy Source-Specific Multicast by upgrading only the last hop DRs to be PIM-SS capable. However, mixed topologies of legacy and upgraded routers may result the following invalid messages for the SSM range: o A legacy first hop DR may send Registers for directly connected sources sending to the SSM group range. o Legacy routers may originate/propagate (*,G)/(S,G) RP-bit Join/Prune messages for the SSM group range. o A legacy router may send (*,G) Asserts for groups in the SSM range. The following interoperability procedures are defined for PIM-SS routers in mixed networks : o A PIM-SS router MUST ignore any shared tree Join/Prune messages that are addressed to it. I.e., all (*,G) or (S,G) RP-bit Joins/Prunes. o A PIM-SS router SHOULD override all prunes targeted at the RPF neigh- bour towards the source with (S,G) Joins to ensure robust forwarding of data on the shortest path tree. o A PIM-SS router SHOULD respond to (*,G) Assert messages with PIM-SS Asserts. Bhaskar, Kouvelas [Page 8] INTERNET-DRAFT PIM-SS 10 March 2000 The following configuration or implementation procedures are recommended for PIM-SM RPs that are SSM aware : o A PIM-SS aware RP MUST respond to all Register packets for the SSM group range with a Register-Stop message. It SHOULD do no further processing of the Register packet. o The RP SHOULD not originate or propagate MSDP advertisements for the SSM group range. 6. Security Considerations All PIM-SS control messages MAY use IPsec to address security concerns. Bhaskar, Kouvelas [Page 9] INTERNET-DRAFT PIM-SS 10 March 2000 References [1] Holbrook, Cain "Source-Specific Multicast", draft-holbrook-ssm- 00.txt, March 2000 [2] Estrin et all. "Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification", draft-ietf-pim-v2-sm-01.txt, October 1999 Bhaskar, Kouvelas [Page 10] INTERNET-DRAFT PIM-SS 10 March 2000 Authors' Addresses Nidhi Bhaskar nbhaskar@cisco.com Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Isidor Kouvelas kouvelas@cisco.com Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Bhaskar, Kouvelas [Page 11] From owner-pim@catarina.usc.edu Thu Mar 16 00:12:54 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28660 for ; Thu, 16 Mar 2000 00:12:54 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id VAA12465 for pim-list; Wed, 15 Mar 2000 21:09:48 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id VAA12460 for ; Wed, 15 Mar 2000 21:09:47 -0800 (PST) Received: from garnet.juniper.net (garnet.juniper.net [208.197.169.237]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id VAA22435; Wed, 15 Mar 2000 21:08:14 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id VAA42601; Wed, 15 Mar 2000 21:08:13 -0800 (PST) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200003160508.VAA42601@garnet.juniper.net> To: pim@catarina.usc.edu cc: agenda@ietf.org Subject: PIM Working Group is back on MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42598.953183293.1@garnet.juniper.net> Date: Wed, 15 Mar 2000 21:08:13 -0800 From: Tom Pusateri Sender: owner-pim@catarina.usc.edu Precedence: bulk We have got a slot on Monday from 9:30-11:30 am. Thanks to our Area Directors who helped work it out. Here is the agenda. Please send me corrections/additions real soon now. PIM Sparse mode spec issues (Kouvelas, 30 min) http://www.aciri.org/fenner/mcast/pim/sm/issues.html PIM-SO Trials from Sprintlabs (Bhattacharyya, 20 min) draft-bhattach-diot-PIMSO-00.txt (not in ID directory yet) PIM-SM Rules for Single-Source Multicast (Sandick, 20 min) draft-sandick-pimsm-ssmrules-00.txt (not in ID directory yet) Source Specific PIM (Kouvelas, 15 min) http://www.ietf.org/internet-drafts/draft-bhaskar-pim-ss-00.txt PIM for IPv6 update (Habermann, 10 min) http://www.ietf.org/internet-drafts/draft-ietf-pim-ipv6-03.txt Thanks, Tom From owner-pim@catarina.usc.edu Thu Mar 16 12:56:23 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09860 for ; Thu, 16 Mar 2000 12:56:23 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA14743 for pim-list; Thu, 16 Mar 2000 09:46:53 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA14738 for ; Thu, 16 Mar 2000 09:46:52 -0800 (PST) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Thu, 16 Mar 2000 11:46:18 -0600 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HAZTMFYY; Thu, 16 Mar 2000 12:46:02 -0500 Received: from nortelnetworks.com (HSANDICK [132.245.252.107]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G9S05PR3; Thu, 16 Mar 2000 12:46:00 -0500 Message-ID: <38D11DC5.766766B7@nortelnetworks.com> Date: Thu, 16 Mar 2000 12:45:41 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Hal Sandick" Reply-To: "Hal Sandick" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Pusateri CC: pim@catarina.usc.edu Subject: Re: PIM Working Group is back on References: <200003160508.VAA42601@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tom, I just checked our draft is now in the ID directory: http://www.ietf.org/internet-drafts/draft-sandick-pimsm-ssmrules-00.txt Regards, Hal Sandick Tom Pusateri wrote: > > We have got a slot on Monday from 9:30-11:30 am. > Thanks to our Area Directors who helped work it out. > > Here is the agenda. Please send me corrections/additions real soon now. > > PIM Sparse mode spec issues (Kouvelas, 30 min) > http://www.aciri.org/fenner/mcast/pim/sm/issues.html > PIM-SO Trials from Sprintlabs (Bhattacharyya, 20 min) > draft-bhattach-diot-PIMSO-00.txt (not in ID directory yet) > PIM-SM Rules for Single-Source Multicast (Sandick, 20 min) > draft-sandick-pimsm-ssmrules-00.txt (not in ID directory yet) > Source Specific PIM (Kouvelas, 15 min) > http://www.ietf.org/internet-drafts/draft-bhaskar-pim-ss-00.txt > PIM for IPv6 update (Habermann, 10 min) > http://www.ietf.org/internet-drafts/draft-ietf-pim-ipv6-03.txt > > Thanks, > Tom From owner-pim@catarina.usc.edu Mon Mar 20 23:48:36 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25542 for ; Mon, 20 Mar 2000 23:48:34 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id UAA38492 for pim-list; Mon, 20 Mar 2000 20:40:44 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id UAA38487 for ; Mon, 20 Mar 2000 20:40:34 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 21 Mar 2000 10:17:55 +0530 Received: from subraln.future.futsoft.com ([10.0.14.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id JAA15077 for ; Tue, 21 Mar 2000 09:56:16 +0530 Received: by localhost with Microsoft MAPI; Tue, 21 Mar 2000 10:08:11 +0530 Message-Id: <01BF931D.5CE04700.subraln@future.futsoft.com> From: "L.N.Subramanian" Reply-To: "subraln@future.futsoft.com" To: "'pim@catarina.usc.edu'" Subject: Clarification for the need for SPT tree bet. Source & RP. Date: Tue, 21 Mar 2000 10:08:10 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, I have a small question. When the source sends Packets to the RP, it encapsulates in Register Messages and Unicasts. It stops sending Encapsulated Messages whwn receives a Register-Stop Msg frm RP. But I think the path taken by Register Packets and Normal Multicat Forwarding bet RP and DR of Source is the same. So even after switching to SPT tree by RP, the data rate remains the same. So I dont understand the condition on which the RP switches to SPT tree. Help me in this regard. Subramanian.L.N From owner-pim@catarina.usc.edu Tue Mar 21 00:26:51 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09853 for ; Tue, 21 Mar 2000 00:26:50 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id VAA38763 for pim-list; Mon, 20 Mar 2000 21:22:27 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from ficon-tech.com ([12.10.198.190]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id VAA38757 for ; Mon, 20 Mar 2000 21:22:16 -0800 (PST) Received: from ficon-tech.com (renu.india.ficon-tech.com [172.25.1.111] (may be forged)) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id KAA16186; Tue, 21 Mar 2000 10:40:46 +0530 (IST) (envelope-from ragarwal@ficon-tech.com) Message-ID: <38D704D6.A2ACAE17@ficon-tech.com> Date: Tue, 21 Mar 2000 10:42:54 +0530 From: Renu Agarwal Organization: Ficon Technology India Pvt Ltd., X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "subraln@future.futsoft.com" , "'pim@catarina.usc.edu'" Subject: Re: Clarification for the need for SPT tree bet. Source & RP. References: <01BF931D.5CE04700.subraln@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Subramanian, The data rate shall be increased slightly due to saving of the encapsulation effort at DR and decapsulation effort at the RP. The data path shall remain same in both the cases. Also, after switching to SPT, the data packets shall be forwarded directly by the kernel while in previous case the data forwarding had to be done by the user process at least at the DR. (taking a reference to Pimd implementation on unix kind of environment). Hope it answers your question, Regards, Renu "L.N.Subramanian" wrote: > > Hi, > I have a small question. When the source sends Packets to the RP, it encapsulates in Register Messages and Unicasts. > It stops sending Encapsulated Messages whwn receives a Register-Stop Msg frm RP. But I think the path taken by > Register Packets and Normal Multicat Forwarding bet RP and DR of Source is the same. So even after switching to > SPT tree by RP, the data rate remains the same. So I dont understand the condition on which the RP switches > to SPT tree. > Help me in this regard. > > Subramanian.L.N From owner-pim@catarina.usc.edu Tue Mar 21 01:19:44 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01498 for ; Tue, 21 Mar 2000 01:19:42 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id WAA39173 for pim-list; Mon, 20 Mar 2000 22:16:35 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from hetnet.nl (net090s.hetnet.nl [194.151.104.183]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id WAA39168 for ; Mon, 20 Mar 2000 22:16:33 -0800 (PST) Received: from pecan ([63.202.82.205]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.387.38); Tue, 21 Mar 2000 07:14:27 +0100 Message-ID: <003001bf92fc$802cd960$0c0a0a0a@icsi.berkeley.edu> From: "Wilbert de Graaf" To: , References: <01BF931D.5CE04700.subraln@future.futsoft.com> Subject: Re: Clarification for the need for SPT tree bet. Source & RP. Date: Mon, 20 Mar 2000 22:12:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Subramanian, I think it's not the source encapsulating the multicast traffic in pim-register but it's designated router (DR) does. So if multiple routers are connected to the source, and a path exists between a non-DR and the RP which is shorter/better than the path between DR and RP, the SPT will not be from DR to RP. After all, the DR was mereley based on the ip-address, right ? But about the treshold and the decision for the RP start to build a SPT towards the source (and send the join), I think the point is not that traffic will be more or less between both situations (#1 data-in-register-messages, #2 SPT-between-RP-and-source). I think the point is that encapsulated multicast data will consume way more resources (cpu time for all intermediate routers), and the path might less optimal than the SPT from RP to the source. At some point, it's simply worth investing efforts to switch to the more optimal situation: the SPT from the source to RP. - Wilbert ----- Original Message ----- From: L.N.Subramanian To: Sent: Monday, March 20, 2000 8:38 PM Subject: Clarification for the need for SPT tree bet. Source & RP. > Hi, > I have a small question. When the source sends Packets to the RP, it encapsulates in Register Messages and Unicasts. > It stops sending Encapsulated Messages whwn receives a Register-Stop Msg frm RP. But I think the path taken by > Register Packets and Normal Multicat Forwarding bet RP and DR of Source is the same. So even after switching to > SPT tree by RP, the data rate remains the same. So I dont understand the condition on which the RP switches > to SPT tree. > Help me in this regard. > > Subramanian.L.N > From owner-pim@catarina.usc.edu Tue Mar 21 07:37:07 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22580 for ; Tue, 21 Mar 2000 07:37:06 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id EAA40714 for pim-list; Tue, 21 Mar 2000 04:33:12 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id EAA40709 for ; Tue, 21 Mar 2000 04:33:01 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 21 Mar 2000 18:11:03 +0530 Received: from subraln.future.futsoft.com ([10.0.14.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id RAA28458; Tue, 21 Mar 2000 17:49:25 +0530 Received: by localhost with Microsoft MAPI; Tue, 21 Mar 2000 18:01:29 +0530 Message-Id: <01BF935F.7B6A3F40.subraln@future.futsoft.com> From: "L.N.Subramanian" Reply-To: "subraln@future.futsoft.com" To: "'eddy@isi.edu'" Cc: "'pim@catarina.usc.edu'" Subject: Doubts PIM Date: Tue, 21 Mar 2000 18:01:27 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, As in RFC 2362 , A router sends a periodic Join/Prune message to each distinct RPF neighbor associated with each (S,G), (*,G) and (*,*,RP) entry. Join/Prune messages are only sent if the RPF neighbor is a PIM neighbor. A periodic Join/Prune message sent to a particular RPF neighbor is constructed as follows: 1 Each router determines the RP for a (*,G) entry by using the hash function described. The RP address (with RPT and WCbits set) is included in the join list of a periodic Join/Prune message under the following conditions: a The Join/Prune message is being sent to the RPF neighbor toward the RP for an active (*,G) or (*,*,RP) entry, and b The outgoing interface list in the (*,G) or (*,*,RP) entry is non-NULL, or the router is the DR on the same interface as the RPF neighbor. I dont understand the the second condition in 1 b? How it helps in sending Periodic Join Message. 2) With what Version of IGMP does PIM can operate? And if Querier in IGMP v2 is diiferent from DR on the LAN, then how does the DR knows about Group Information.This is b'cos the Election Procedure for DR and IGMP V2 Querier are contradictory. - Subramanian.L.N From owner-pim@catarina.usc.edu Tue Mar 21 11:10:14 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09062 for ; Tue, 21 Mar 2000 11:10:13 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA41422 for pim-list; Tue, 21 Mar 2000 08:03:48 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA41417 for ; Tue, 21 Mar 2000 08:03:47 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 95F971E029; Tue, 21 Mar 2000 11:03:08 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA18538; Tue, 21 Mar 2000 11:03:07 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA11939; Tue, 21 Mar 2000 08:02:24 -0800 (PST) Message-Id: <200003211602.IAA11939@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: subraln@future.futsoft.com Subject: Re: Doubts PIM Cc: eddy@isi.edu, pim@catarina.usc.edu Date: Tue, 21 Mar 2000 08:02:24 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk > I dont understand the the second condition in 1 b? How it helps in >sending Periodic Join Message. It allows a "downstream" DR with no downstream group members (so it has an empty OIF list) to still send Joins to get traffic to the network it's the DR for. Bad ASCII art: RP | R1 | R2 | ----------------------------------- | | H DR In this case,it's the DR's job to get the traffic from the RP since H is interested, but the DR has an empty oiflist so the first half of 1b would prevent it from sending a join to R2. >2) With what Version of IGMP does PIM can operate? Any. > And if Querier in IGMP v2 is diiferent from DR on the LAN, then how >does the DR knows about Group Information. That's how IGMP works; non-Queriers know group membership also. Bill From owner-pim@catarina.usc.edu Wed Mar 22 09:02:32 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26533 for ; Wed, 22 Mar 2000 09:02:31 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id AAA46272 for pim-list; Wed, 22 Mar 2000 00:45:30 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id AAA46264 for ; Wed, 22 Mar 2000 00:45:06 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 22 Mar 2000 14:22:14 +0530 Received: from subraln.future.futsoft.com ([10.0.14.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id OAA08822; Wed, 22 Mar 2000 14:03:31 +0530 Received: by localhost with Microsoft MAPI; Wed, 22 Mar 2000 14:12:29 +0530 Message-Id: <01BF9408.A8266140.subraln@future.futsoft.com> From: "L.N.Subramanian" Reply-To: "subraln@future.futsoft.com" To: "'Bill Fenner'" Cc: "'eddy@isi.edu'" , "'pim@catarina.usc.edu'" Subject: RE: Doubts PIM Date: Wed, 22 Mar 2000 14:12:28 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-pim@catarina.usc.edu Precedence: bulk -----Original Message----- From: Bill Fenner [SMTP:fenner@research.att.com] Sent: Tuesday, March 21, 2000 9:32 PM To: subraln@kailash.future.futsoft.com Cc: eddy@isi.edu; pim@catarina.usc.edu Subject: Re: Doubts PIM > I dont understand the the second condition in 1 b? How it helps in >sending Periodic Join Message. It allows a "downstream" DR with no downstream group members (so it has an empty OIF list) to still send Joins to get traffic to the network it's the DR for. Bad ASCII art: RP | R1 | R2 | ----------------------------------- | | H DR In this case,it's the DR's job to get the traffic from the RP since H is interested, but the DR has an empty oiflist so the first half of 1b would prevent it from sending a join to R2. [L.N.Subramanian] How can a DR distingish between the groups it has learnt from downstream host-group members and that learnt in the other interface as Host H is, i.e; 1 2 H1------R1---------R2 | H2 suppose say R1 is the DR on interface 1 & 2. Host H1 joins for group G1 (*,G1) at R1 iif oif 2 1 From H2 for G2 2 - [oif = NULL right?] suppose H1 takes its membership out of G1, then (*,G1) iif =2 oif = Null Now will R1 send Join for group G1? It sends Periodic Join for G2. How does it distinguish between Groups learnt from different interfaces when the Oif = NULL. >2) With what Version of IGMP does PIM can operate? Any. > And if Querier in IGMP v2 is diiferent from DR on the LAN, then how >does the DR knows about Group Information. That's how IGMP works; non-Queriers know group membership also. Bill From owner-pim@catarina.usc.edu Wed Mar 22 09:34:51 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08119 for ; Wed, 22 Mar 2000 09:34:50 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id GAA00741 for pim-list; Wed, 22 Mar 2000 06:29:21 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id GAA00736 for ; Wed, 22 Mar 2000 06:29:19 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 059324CE2D; Wed, 22 Mar 2000 09:29:19 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA10174; Wed, 22 Mar 2000 09:29:18 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id GAA21868; Wed, 22 Mar 2000 06:28:35 -0800 (PST) Message-Id: <200003221428.GAA21868@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: subraln@future.futsoft.com Subject: RE: Doubts PIM Cc: eddy@isi.edu, pim@catarina.usc.edu Date: Wed, 22 Mar 2000 06:28:34 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk The spec is a little ambiguous on what exactly happens when H1 leaves the group; I think what should happen is that R1 deletes its (*,G1) state but what might happen is that the (*,G1) state has to time out. If the latter, then R1 will send useless (*,G1) joins while the state is timing out. Bill (Obviously you can only immediately delete the state on loss of local group membership if you don't have any downstream neighbors that have sent you (*,G) joins.) From owner-pim@catarina.usc.edu Mon Mar 27 03:58:53 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14492 for ; Mon, 27 Mar 2000 03:58:52 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id AAA23392 for pim-list; Mon, 27 Mar 2000 00:34:52 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id AAA23387 for ; Mon, 27 Mar 2000 00:34:42 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 27 Mar 2000 14:12:49 +0530 Received: from sabaris.future.futsoft.com (rosario.future.futsoft.com [10.0.2.1]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id NAA18067 for ; Mon, 27 Mar 2000 13:53:16 +0530 Received: by localhost with Microsoft MAPI; Mon, 27 Mar 2000 14:02:20 +0530 Message-Id: <01BF97F5.114FFE20.sabaris@future.futsoft.com> From: sabarivel s To: "'pim@catarina.usc.edu'" Subject: clarification Date: Mon, 27 Mar 2000 14:02:18 +0530 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Can multiple Multicast Routing Protocols run on an Interface? if yes, is there any such implementation? - sabari From owner-pim@catarina.usc.edu Mon Mar 27 10:59:28 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21025 for ; Mon, 27 Mar 2000 10:59:27 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA24739 for pim-list; Mon, 27 Mar 2000 07:51:30 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from griffin.aciri.org (griffin.aciri.org [192.150.187.12]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA24734 for ; Mon, 27 Mar 2000 07:51:28 -0800 (PST) Received: from hetnet.nl (localhost.aciri.org [127.0.0.1]) by griffin.aciri.org (8.9.3/8.9.3) with ESMTP id HAA25841; Mon, 27 Mar 2000 07:50:52 -0800 (PST) (envelope-from wilbertdg@hetnet.nl) Message-ID: <38DF835C.5CE17FAD@hetnet.nl> Date: Mon, 27 Mar 2000 07:50:52 -0800 From: Wilbert de Graaf X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.36 i386) X-Accept-Language: en MIME-Version: 1.0 To: sabarivel s CC: "'pim@catarina.usc.edu'" Subject: Re: clarification References: <01BF97F5.114FFE20.sabaris@future.futsoft.com> Content-Type: multipart/mixed; boundary="------------1154C132CC9594EB46151ADD" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------1154C132CC9594EB46151ADD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hi, > Can multiple Multicast Routing Protocols run on an Interface? if yes, is there any such implementation? Sabari, Althugh I haven't it running myself, I cannot tell what could be wrong with it. The routing protocols use different protocol types / numbers, so that part is safe. And each of the implementations (pimd, mrouted, ...) just manipulates the multicast routing tables. The kernel just forwards / routes using this very same table so there shouldn't be a problem too. - Wilbert --------------1154C132CC9594EB46151ADD Content-Type: text/x-vcard; charset=us-ascii; name="wilbertdg.vcf" Content-Description: Card for Wilbert de Graaf Content-Disposition: attachment; filename="wilbertdg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:de Graaf;Wilbert x-mozilla-html:FALSE url:http://home.hetnet.nl/~wilbertdg/ org:KPN Research adr:;;;;;; version:2.1 email;internet:wilbertdg@hetnet.nl x-mozilla-cpt:;0 fn:Wilbert de Graaf end:vcard --------------1154C132CC9594EB46151ADD-- From owner-pim@catarina.usc.edu Mon Mar 27 11:28:50 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21224 for ; Mon, 27 Mar 2000 11:28:46 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA24917 for pim-list; Mon, 27 Mar 2000 08:21:59 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from uniwest1.redstonecom.com (mail.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA24912 for ; Mon, 27 Mar 2000 08:21:58 -0800 (PST) Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 11:22:51 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C3688BD@uniwest1.redstonecom.com> From: "Shekhar, Ravi" To: Wilbert de Graaf , sabarivel s Cc: "'pim@catarina.usc.edu'" Subject: RE: clarification Date: Mon, 27 Mar 2000 11:22:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk > > Hi, > > Can multiple Multicast Routing > Protocols run on an Interface? if yes, is there any such > implementation? Usually not, unless there is some cordination between the routing protocols themselves (like sparse-dense mode of PIM). For instance one problem could be, if the two multicast protocols running on the same interface happen to choose different upstream routers to get the data, router will end up receiving duplicate data. - Ravi Shekhar. > > Sabari, > > Althugh I haven't it running myself, I cannot tell what could > be wrong with it. The routing protocols use different protocol > types / numbers, so that part is safe. And each of the > implementations (pimd, mrouted, ...) just manipulates the multicast > routing tables. The kernel just forwards / routes using this > very same table so there shouldn't be a problem too. > > - Wilbert > > From owner-pim@catarina.usc.edu Tue Mar 28 01:13:11 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06267 for ; Tue, 28 Mar 2000 01:13:11 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id WAA28137 for pim-list; Mon, 27 Mar 2000 22:04:36 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id WAA28132 for ; Mon, 27 Mar 2000 22:04:34 -0800 (PST) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Tue, 28 Mar 2000 00:04:34 -0600 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H3HTJH1C; Tue, 28 Mar 2000 01:04:12 -0500 Received: from nortelnetworks.com (HSANDICK [132.245.139.189]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNT9GN92; Tue, 28 Mar 2000 01:04:08 -0500 Message-ID: <38E04B26.A6B5EE92@nortelnetworks.com> Date: Tue, 28 Mar 2000 01:03:18 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Hal Sandick" Reply-To: "Hal Sandick" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sabarivel s CC: "'pim@catarina.usc.edu'" Subject: Re: clarification References: <01BF97F5.114FFE20.sabaris@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sabari, I have worked withed a code base (used by two different router vendors) that supported this feature. As others have noted "stuff" was done so that : - only one input interface was chosen for an entry - output interfaces only transmitted one copy of a packet. Regards, Hal sabarivel s wrote: > > Hi, > Can multiple Multicast Routing Protocols run on an Interface? if yes, is there any such implementation? > > - sabari From owner-pim@catarina.usc.edu Tue Mar 28 02:15:14 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17213 for ; Tue, 28 Mar 2000 02:15:13 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id XAA28511 for pim-list; Mon, 27 Mar 2000 23:05:45 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id XAA28482 for ; Mon, 27 Mar 2000 23:05:20 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 28 Mar 2000 12:43:59 +0530 Received: from sabaris.future.futsoft.com (rosario.future.futsoft.com [10.0.2.1]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA04885 for ; Tue, 28 Mar 2000 12:24:26 +0530 Received: by localhost with Microsoft MAPI; Tue, 28 Mar 2000 12:33:30 +0530 Message-Id: <01BF98B1.D32DF120.sabaris@future.futsoft.com> From: sabarivel s To: "'pim@catarina.usc.edu'" Subject: doubts regarding assert mechanism in PIM SM Date: Tue, 28 Mar 2000 12:33:30 +0530 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit hi , i have some doubts regarding the assert mechanism (refer PIM -sm rfc 2362 section 3.5) 1) in the section 3.5.2.2 Receving asserts on an entry's incoming interface doubt : if the assert does not match the entry exactly it is ignored.What do u mean by exact entry in this context ? is the RPT bit of the assert messages are taken care in this case? i.e if the RPT bit is cleared exact matching entry is (s,g) and if RPT bit is exact matching entry is (*,G) . Is it so? doubt : When the RPF neighbour changes Assert timer has to be started .. and random delay join timer also need to be started. Which timer has to be started first? 2) in the same section 3.5.2.2. point no 2 is If the downstream routers have downstream members and if the assert caused the RPF neighbour to change the downstream routers must trigger a join/prune message to inform the upstream router that packets are to be forwarded on the multiaccess network. doubt: whether a prune has to be sent to the old RPF neighbour? if prune is to be sent ,whether join/prune suppression timer has to be started by other routers parallel to it? when the downstream routers don't have downstream members what to do? thanks in advance with regards sabaris From owner-pim@catarina.usc.edu Tue Mar 28 05:54:15 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19370 for ; Tue, 28 Mar 2000 05:54:14 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA29583 for pim-list; Tue, 28 Mar 2000 02:47:23 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA29578 for ; Tue, 28 Mar 2000 02:47:10 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 28 Mar 2000 16:25:35 +0530 Received: from subraln.future.futsoft.com ([10.0.14.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA10635 for ; Tue, 28 Mar 2000 16:06:02 +0530 Received: by localhost with Microsoft MAPI; Tue, 28 Mar 2000 16:15:13 +0530 Message-Id: <01BF98D0.CBFF7800.subraln@future.futsoft.com> From: "L.N.Subramanian" Reply-To: "subraln@future.futsoft.com" To: "'pim@catarina.usc.edu'" Subject: Clarification in Tree Mnt Timers in PIM. Date: Tue, 28 Mar 2000 16:15:11 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, When is the Entry Timer for (S,G) RPT Entry Started. If an new Interface is added to the Oif list of (S,G) RPT -bit (receiving (*,G) Join ) is the Entry Timer restarted for the (S,G)RPT Bit Entry. L.N. Subramanian. From owner-pim@catarina.usc.edu Tue Mar 28 08:38:05 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20735 for ; Tue, 28 Mar 2000 08:38:05 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id FAA30108 for pim-list; Tue, 28 Mar 2000 05:32:06 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id FAA30103 for ; Tue, 28 Mar 2000 05:31:58 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 28 Mar 2000 19:10:42 +0530 Received: from subraln.future.futsoft.com ([10.0.14.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id SAA14025 for ; Tue, 28 Mar 2000 18:51:09 +0530 Received: by localhost with Microsoft MAPI; Tue, 28 Mar 2000 19:00:23 +0530 Message-Id: <01BF98E7.DEDF32A0.subraln@future.futsoft.com> From: "L.N.Subramanian" Reply-To: "subraln@future.futsoft.com" To: "'pim@catarina.usc.edu'" Subject: Clarification in Assert Handling in PIM Date: Tue, 28 Mar 2000 19:00:22 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, If the Number of Parallel Upstream Routers is greater than 2, how does the other Routers determine who is the Assert loser/Winner.When is the Assert Process stopped.Or When is the case where the Assert Timer is restarted? Does the Routers deciding the Assert Winner, always do Lookup for Source S of the Data Packet/Enc Unicast Source Address in Assert Msg OR If the Data Packet is received in a oif of (*,G) Entry , Will the Lookup be towards Source S or the RP? - Subramanian. L.N From owner-pim@catarina.usc.edu Wed Mar 29 00:50:31 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05145 for ; Wed, 29 Mar 2000 00:50:29 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id VAA34235 for pim-list; Tue, 28 Mar 2000 21:45:06 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from ficon-tech.com ([12.10.198.190]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id VAA34230 for ; Tue, 28 Mar 2000 21:45:00 -0800 (PST) Received: from ficon-tech.com (renu.india.ficon-tech.com [172.25.1.111] (may be forged)) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id LAA98750; Wed, 29 Mar 2000 11:05:15 +0530 (IST) (envelope-from ragarwal@ficon-tech.com) Message-ID: <38E196EB.2E60493@ficon-tech.com> Date: Wed, 29 Mar 2000 11:08:51 +0530 From: Renu Agarwal Organization: Ficon Technology India Pvt Ltd., X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: sabarivel s CC: "'pim@catarina.usc.edu'" Subject: Re: doubts regarding assert mechanism in PIM SM References: <01BF98B1.D32DF120.sabaris@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello sabarivel, Please see my replies. Hope it helps, Renu sabarivel s wrote: > > hi , > i have some doubts regarding the assert mechanism (refer PIM -sm rfc 2362 > section 3.5) > > 1) in the section 3.5.2.2 Receving asserts on an entry's incoming interface > > doubt : if the assert does not match the entry exactly it is ignored.What > do u mean by exact entry in this context ? > is the RPT bit of the assert messages are taken care in this case? > i.e if the RPT bit is cleared exact matching entry is (s,g) > and if RPT bit is exact matching entry is (*,G) . Is it so? If RPT-bit is set then depending on the group address present match it exactly with (*,G) or (*,*, RP). else match with (S,G)entry > > doubt : When the RPF neighbour changes Assert timer has to be started .. > and random delay join timer also need to be started. > Which timer has to be started first? The timers has to be started simultaneously. In my opinion, the sequence is immaterial. > > 2) in the same section 3.5.2.2. point no 2 is > If the downstream routers have downstream members and if the assert caused > the RPF neighbour to change the downstream routers must trigger a > join/prune message to inform the upstream router that packets are to be > forwarded on the multiaccess network. > > doubt: whether a prune has to be sent to the old RPF neighbour? if prune is > to be sent ,whether join/prune suppression timer > has to be started by other routers parallel to it? The RFC nowhere specifies the prune is to be sent. It assumes that the old RPF shall automatically time-out the entry in absence of join-prune message. > when the downstream routers don't have downstream members what to > do? This is totally different case. If a downstream router has no downstream members or routers using that entry, this entry shall any way be deleted/timed-out. > > thanks in advance > with regards > sabaris From owner-pim@catarina.usc.edu Wed Mar 29 01:09:53 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05900 for ; Wed, 29 Mar 2000 01:09:53 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id WAA34350 for pim-list; Tue, 28 Mar 2000 22:04:48 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id WAA34345 for ; Tue, 28 Mar 2000 22:04:32 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 29 Mar 2000 11:43:16 +0530 Received: from subraln.future.futsoft.com ([10.0.14.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA25977 for ; Wed, 29 Mar 2000 11:23:43 +0530 Received: by localhost with Microsoft MAPI; Wed, 29 Mar 2000 11:32:50 +0530 Message-Id: <01BF9972.837A1200.subraln@future.futsoft.com> From: "L.N.Subramanian" Reply-To: "subraln@future.futsoft.com" To: "'pim@catarina.usc.edu'" Subject: Clarification in Oif Timer & Entry Timer in PIM Date: Wed, 29 Mar 2000 11:32:45 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, Consider the Setup 1 2 1 2 1 -----R1----------R2--------RP (*,G) iif oif R1 2 - R2 2 - RP - - If R1 sends Periodic Prune for RP RPT , WC Bits Set, what is the Action taken by R2 on receiving it? Is the Entry timer restarted ? --Subramanian. From owner-pim@catarina.usc.edu Wed Mar 29 01:20:27 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07276 for ; Wed, 29 Mar 2000 01:20:27 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id WAA34482 for pim-list; Tue, 28 Mar 2000 22:17:38 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id WAA34477 for ; Tue, 28 Mar 2000 22:17:33 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 29 Mar 2000 11:56:14 +0530 Received: from subraln.future.futsoft.com ([10.0.14.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA26424 for ; Wed, 29 Mar 2000 11:36:40 +0530 Received: by localhost with Microsoft MAPI; Wed, 29 Mar 2000 11:45:48 +0530 Message-Id: <01BF9974.538A6CA0.subraln@future.futsoft.com> From: "L.N.Subramanian" Reply-To: "subraln@future.futsoft.com" To: "'pim@catarina.usc.edu'" Subject: Data Forwading. Date: Wed, 29 Mar 2000 11:45:47 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, Current state : The Oif Timer for an Route Entry is reduced to Oif Deletion Delay upon receiving a Prune. Input : Data Packet in the iif of the Entry. Action : Is Packet forwaded or not ? -- Subramanian From owner-pim@catarina.usc.edu Wed Mar 29 09:17:24 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21194 for ; Wed, 29 Mar 2000 09:17:23 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id GAA36450 for pim-list; Wed, 29 Mar 2000 06:10:11 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from packetbdc.riverdelta.com ([198.112.190.11]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id GAA36445 for ; Wed, 29 Mar 2000 06:10:09 -0800 (PST) Received: by PACKETBDC with Internet Mail Service (5.5.2448.0) id ; Wed, 29 Mar 2000 09:15:19 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D3BA112@PACKETBDC> From: Billy Ng To: "'Renu Agarwal'" , sabarivel s Cc: "'pim@catarina.usc.edu'" Subject: RE: doubts regarding assert mechanism in PIM SM Date: Wed, 29 Mar 2000 09:15:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-pim@catarina.usc.edu Precedence: bulk The assert loser shuts itself off at the OI on the upstream, and if that OI is the last one, it will trigger a prune upstream. Therefore, there is no need for the downstream to send the prune when it switches its RPF neighbor. --Billy > -----Original Message----- > From: Renu Agarwal [mailto:ragarwal@ficon-tech.com] > Sent: Tuesday, March 28, 2000 11:39 PM > To: sabarivel s > Cc: 'pim@catarina.usc.edu' > Subject: Re: doubts regarding assert mechanism in PIM SM > > > Hello sabarivel, > Please see my replies. > > Hope it helps, > > Renu > sabarivel s wrote: > > > > hi , > > i have some doubts regarding the assert mechanism (refer > PIM -sm rfc 2362 > > section 3.5) > > > > 1) in the section 3.5.2.2 Receving asserts on an entry's > incoming interface > > > > doubt : if the assert does not match the entry exactly it > is ignored.What > > do u mean by exact entry in this context ? > > is the RPT bit of the assert messages are taken > care in this case? > > i.e if the RPT bit is cleared exact matching > entry is (s,g) > > and if RPT bit is exact matching entry is (*,G) . Is it so? > > If RPT-bit is set then depending on the group address present match it > exactly with (*,G) or (*,*, RP). > > else > match with (S,G)entry > > > > > doubt : When the RPF neighbour changes Assert timer has to > be started .. > > and random delay join timer also need to be started. > > Which timer has to be started first? > > The timers has to be started simultaneously. In my opinion, > the sequence > is immaterial. > > > > 2) in the same section 3.5.2.2. point no 2 is > > If the downstream routers have downstream members and if > the assert caused > > the RPF neighbour to change the downstream routers must trigger a > > join/prune message to inform the upstream router that > packets are to be > > forwarded on the multiaccess network. > > > > doubt: whether a prune has to be sent to the old RPF > neighbour? if prune is > > to be sent ,whether join/prune suppression timer > > has to be started by other routers parallel to it? > The RFC nowhere specifies the prune is to be sent. It assumes that the > old RPF shall automatically time-out the entry in absence of > join-prune > message. > > > when the downstream routers don't have downstream > members what to > > do? > This is totally different case. If a downstream router has no > downstream > members or routers using that entry, this entry shall any way be > deleted/timed-out. > > > > thanks in advance > > with regards > > sabaris > From owner-pim@catarina.usc.edu Fri Mar 31 02:02:12 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06727 for ; Fri, 31 Mar 2000 02:02:11 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id WAA44699 for pim-list; Thu, 30 Mar 2000 22:51:31 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id WAA44694 for ; Thu, 30 Mar 2000 22:51:24 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 31 Mar 2000 12:08:03 +0530 Received: from subraln.future.futsoft.com ([10.0.14.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA07262 for ; Fri, 31 Mar 2000 11:48:26 +0530 Received: by localhost with Microsoft MAPI; Fri, 31 Mar 2000 11:57:36 +0530 Message-Id: <01BF9B08.4E750A00.subraln@future.futsoft.com> From: "L.N.Subramanian" Reply-To: "subraln@future.futsoft.com" To: "'pim@catarina.usc.edu'" Subject: Doubts in PIM (S,G) Entries. Date: Fri, 31 Mar 2000 11:57:32 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, When a Join for Source S is received and the Receiving Router has (*,G) Entry oif = Null and (S,G) Entry oif = Null What happens? Or Can this state happen at all? When a Join for RP Wc = Set RPT = Set is received and the Receiving Router has (*,G) Entry oif = Null and (S,G) Entry oif = Null iif (*,G) ! = iif (S,G) Action : Pl Tell my answer is right Make (*,G) & (S,G) State to forwading state. Output : Send Join twd Source Join 0 0 Send Join Twd RP, Prune list = Source S (Join 11 + Prune 0 1) Am I right? 3) Now for the above shud the SPT bit be cleared if it is set or it wi\ould have been Cleared when (S,G) Entry has Null Oif List. Regards, Subramanian.L.N From owner-pim@catarina.usc.edu Fri Mar 31 04:46:21 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11424 for ; Fri, 31 Mar 2000 04:46:20 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id BAA45206 for pim-list; Fri, 31 Mar 2000 01:35:07 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id BAA45201 for ; Fri, 31 Mar 2000 01:35:03 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 31 Mar 2000 15:11:22 +0530 Received: from subraln.future.futsoft.com ([10.0.14.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id OAA11254 for ; Fri, 31 Mar 2000 14:51:46 +0530 Received: by localhost with Microsoft MAPI; Fri, 31 Mar 2000 15:01:01 +0530 Message-Id: <01BF9B21.EE008220.subraln@future.futsoft.com> From: "L.N.Subramanian" Reply-To: "subraln@future.futsoft.com" To: "'pim@catarina.usc.edu'" Date: Fri, 31 Mar 2000 15:01:00 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, What is meant by "Complete Match" in Join/Suppression Handling. Does it mean Join for RP will only match with (*,G) Entry in the Receiving Router Or (*,G) Join Or (*,G) Prune can match with (S,G) Entries if the receiving router does not have (*,G) Entry. Wud like to have ur advice/warning/..... Regards, Subramanian.L.N From owner-pim@catarina.usc.edu Fri Mar 31 05:27:47 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11689 for ; Fri, 31 Mar 2000 05:27:45 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA45787 for pim-list; Fri, 31 Mar 2000 02:22:30 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futusoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA45782 for ; Fri, 31 Mar 2000 02:21:27 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 31 Mar 2000 15:59:47 +0530 Received: from sabaris.future.futsoft.com (rosario.future.futsoft.com [10.0.2.1]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id PAA12214 for ; Fri, 31 Mar 2000 15:40:12 +0530 Received: by localhost with Microsoft MAPI; Fri, 31 Mar 2000 15:49:21 +0530 Message-Id: <01BF9B28.AE941280.sabaris@future.futsoft.com> From: sabarivel s To: "'pim@catarina.usc.edu'" Subject: doubts regarding register message Date: Fri, 31 Mar 2000 15:49:20 +0530 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit hi , i have doubt in pim-sm rfc2362 section 3.3.2 (receiving register messages and sending register stops) 1) the rfc states: when a register message is received and if there is a (*,*,RP) entry but no (*,G) entry and register received does not have the null-register bit set to 1, a (*,G) or (S,G) entry is created. doubt : regarding above statement when (*,G) entry is created and when (S,G) entry is created ? 2) whether a register message can have both border bit and Null register bit set ?? Thanks in advance with regards sabari From owner-pim@catarina.usc.edu Fri Mar 31 21:08:12 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20815 for ; Fri, 31 Mar 2000 21:08:11 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id RAA48829 for pim-list; Fri, 31 Mar 2000 17:57:53 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from web1506.mail.yahoo.com (web1506.mail.yahoo.com [128.11.23.184]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id RAA48824 for ; Fri, 31 Mar 2000 17:57:50 -0800 (PST) Received: (qmail 3075 invoked by uid 60001); 1 Apr 2000 01:57:50 -0000 Message-ID: <20000401015750.3074.qmail@web1506.mail.yahoo.com> Received: from [216.52.8.3] by web1506.mail.yahoo.com; Fri, 31 Mar 2000 17:57:50 PST Date: Fri, 31 Mar 2000 17:57:50 -0800 (PST) From: "=?iso-8859-1?q?Rajendran=20G.?=" Subject: RP hashing To: pim@catarina.usc.edu MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi All, I am trying to set up a multiast test bed for my research. I am using Gated routers and a cisco 3600 (with 12.0 s/w) in the setup. For RP hashing, I get different results with Gated and Cisco. In a simple case. Group: 239.255.0.0/16 C-RPs: 130.1.1.12, 132.1.1.14 (both with priority 0) Hash Mask len: 30 bits For a group 239.255.1.1: Gated always elects 130.1.1.14 and Cisco elects 132.1.1.12. I tried to compute the hash value by hand and it seems Gated picks the right one (as 130.1.1.12's hash value is less than 132.1.1.14's for this G 239.255.1.1). Does anyone know such problem with Gated or Cisco. Thanks for your inputs. Raj __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com