Subject: RE: PIM-SM join/prune suppression timer question

From: Ravi Shekhar <[email-masked]>
Date: Mon, 19 Jul 1999 14:56:32 -0400

> | The last two lines seem to suggest that "prunes" should also be 
> | suppressed.
> | Consider the case where there is an <S, G> entry with different 
> | IIFs for SPT and shared tree. It should not suppress its prunes 
> | towards RP(on the shared tree) even if the Join/Prune suppression 
> | timer is running to suppress joins towards S(on SPT).
> 
> Isn't the entry towards the RP a <*, G> entry? The join/suppression
> timers are per route entry. If you have a join/suppression timer
> on the <S, G> entry, then it should not effect sending prunes on the
> <*, G> entry.

In the case I was trying to describe, if its an <S, G>SPT entry,
- <S, G> join is sent towards S
- <*, G> join will be sent towards RP and an 
  <S, G> prune is also sent towards RP. 

My understanding is that <*, G>join suppression will happen based on 
suppression timer present in <*, G> route entry and <S, G>join suppression
will
happen based on suppression timer in <S, G> route entry.

But <S, G>prune should not be suppressed because of either of these two.
Text in the rfc specifies "While the timer is running, Join/Prune messages 
for the entry are not sent" which gives an impression that even <S, G>prunes

get suppressed.

It looks to me that either we need another suppression timer in <S,G> to 
suppress its prune towards RP, or it should not be suppressed at all.

- Ravi Shekhar.

---

From: Ravi <[email-masked]>
Date: Mon, 19 Jul 1999 13:48:13 -0700

Ravi Shekhar writes:

| > | The last two lines seem to suggest that "prunes" should also be 
| > | suppressed.
| > | Consider the case where there is an <S, G> entry with different 
| > | IIFs for SPT and shared tree. It should not suppress its prunes 
| > | towards RP(on the shared tree) even if the Join/Prune suppression 
| > | timer is running to suppress joins towards S(on SPT).
| > 
| > Isn't the entry towards the RP a <*, G> entry? The join/suppression
| > timers are per route entry. If you have a join/suppression timer
| > on the <S, G> entry, then it should not effect sending prunes on the
| > <*, G> entry.
| 
| In the case I was trying to describe, if its an <S, G>SPT entry,
| - <S, G> join is sent towards S
| - <*, G> join will be sent towards RP and an 
|   <S, G> prune is also sent towards RP. 
| 
| My understanding is that <*, G>join suppression will happen based on 
| suppression timer present in <*, G> route entry and <S, G>join suppression
| will
| happen based on suppression timer in <S, G> route entry.
| 
| But <S, G>prune should not be suppressed because of either of these two.
| Text in the rfc specifies "While the timer is running, Join/Prune messages 
| for the entry are not sent" which gives an impression that even <S, G>prunes
| 
| get suppressed.
| 
| It looks to me that either we need another suppression timer in <S,G> to 
| suppress its prune towards RP, or it should not be suppressed at all.

Join/Prune suppression timer is to avoid duplicate control traffic on the
LAN. If the <S, G> RPT entry has two different IIF's for the source and
the RP, then 
- the RPF router towards the S would trigger the message immediately.
- the RPF router towards the RP would trigger the message immediately.

Join/Prune suppression timer is only invoked if the received join/prune message
matches the IIF of the <*, *, RP> or <*, G> or <S, G> entry.

Ravi