Subject: RE: Question on PIM-SM

From: Mohit Talwar <[email-masked]>
Date: Thu, 2 Mar 2000 10:11:31 -0800

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:[email-masked]]
>Sent: Wednesday, March 01, 2000 8:00 PM
>To: Isidor Kouvelas; Mohit Talwar
>Cc: Chirayu Shah; [email-masked]
>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:[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:
>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: Isidor Kouvelas <[email-masked]>
Date: Thu, 02 Mar 2000 14:18:09 -0800

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