Subject: Re: switch back to pim shared tree

From: Bill Fenner <[email-masked]>
Date: Wed, 2 Aug 2000 16:17:41 -0400 (EDT)

Hal,

  It's not quite that *no* router can switch; it's just that not all routers
can switch.  It's a side effect of how you have to handle the RP-on-a-stick
problem:

                RP
                 |
                 |
                R1 
               /  \
              /    \
             R2    R3
             |      |
             M      S

M is a group member, S is a source.  R2 (M's DR) is joined to the
(*,G) tree due to M's group membership.  R3 is S's DR.  When S
starts sending, R3 Registers to the RP.  Let's say that the RP
chooses to create an SPT branch, so he sends an (S,G) Join to R1
which it propogates to R3.  When R1 starts getting the traffic from
R3, it sends an (S,G,rpt) prune to RP.  RP now has no reason to get
the traffic, so stops sending (S,G) joins.  R1 has to continue sending
(S,G) Joins in order to cause traffic to continue flowing.  This is
Cisco's "Turnaround rules".

Now consider the following topology:

                RP
                 |
                 |
     M2-R4------R1-----R3-S
                 |
                 |
                R2 
                 |
                M1

(note: this adds R4 with another member M2 but is otherwise equivalent
to the above topology).  Both R2 and R4 send (*,G) Joins to R1.  R3
Registers to the RP, data flows down the shared tree, RP starts sending
(S,G) joins, and R4 also starts sending (S,G) joins because it prefers
to create shortest-path trees (but R2 prefers the shared tree).  If R4
stops joining the (S,G) [e.g. because M2 has left, or because S's rate
has fallen below its threshold], R1 cannot stop joining since it can't
tell between this situation and the previous one.

Basically, once an SPT is set up, the portion between the shared tree
and the source cannot be torn down unless the source stops sending.

  Bill

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 2 Aug 2000 14:47:37 -0700

>>                 RP
>>                  |
>>                  |
>>                 R1 
>>                /  \
>>               /    \
>>              R2    R3
>>              |      |
>>              M      S
>> When R1 starts getting the traffic from

   To be precise, R1 doesn't start sending the (S,G,rpt) Prune at this time, it
   does so after it creates (S,G) state (from the RP join message) and the
   next time it's periodic Join/Prune message transmission timer expires.
   At that time, R1 sends a (S,G,rpt) Prune because the RPF neighbor for it's 
   (*,G) entry and (S,G) entry are different.

Dino

---

From: Isidor Kouvelas <[email-masked]>
Date: Thu, 03 Aug 2000 09:23:45 -0700

In message <[email-masked]>,
>   (*,G) entry and (S,G) entry are different.

Actually just receiving the (S,G) Join from the RP is not enough for
R1 to start sending (S,G,rpt) Prunes towards the RP. R1 also has to
wait for traffic to arrive on the (S,G) RPF interface so that the
SPTbit will be set.

thanks
Isidor

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 3 Aug 2000 10:49:09 -0700

>> wait for traffic to arrive on the (S,G) RPF interface so that the

    Yes, if you mean that R1 shouldn't prune S off the shared tree until it
    is sure it is geting data from S on the soruce tree, then this is true.

Dino