Subject: Re: Question on PIM-SM

From: Isidor Kouvelas <[email-masked]>
Date: Wed, 01 Mar 2000 18:49:24 -0800

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: Mohit Talwar <[email-masked]>
Date: Wed, 1 Mar 2000 18:00:14 -0800

---

thoughts, please?
mohit.

>-----Original Message-----
>From: Isidor Kouvelas [mailto:[email-masked]]
>Sent: Wednesday, March 01, 2000 2:33 PM
>To: Mohit Talwar
>Cc: Chirayu Shah; [email-masked]
>Subject: Re: Question on PIM-SM 
>
>
>
>This is addressed in issue 11 on the web page at:
>
>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.
>>>
>>>
>>
>