Subject: [pim] (S,G) expiration timer for pim-dm

From: "James Huang" <[email-masked]>
Date: Mon, 22 Apr 2002 13:21:14 -0700

Hi all,

The latest pim-dm spec does not have any description for the expiration timer of (S,G) entries.  
Section 5.6 "Timing out multicast forwarding entries" in draft-ietf-idmr-pim-dm-06.txt has some description but the document is more than four years old.
Shouldn't the management of the expiration timer be standardized?  Should the timer be updated only upon receiving (S,G) data packets or should it also be updated when a state-refresh message or prune message is received??  What bothers me is that the following scenario may occur if the expiration timer is not standardized.

Suppose a downstream router R2 ages out a (S,G) entry before its upstream router R1 does. If the source S becomes active again after the (S,G) entry in R2 is aged out but before R1 ages out its (S,G) entry and suppose R1's interface toward R2 is in the pruned state, then R2 will not be able to receive (S,G) traffic from R1 and re-create (S,G) entry until R1 times out the prune timer of its downstream interface.  Now if R2 receives a igmp (*,G) join during this period, it will not be able to send a graft(S,G) message toward the source.  So the receiver will not receive (S,G) traffic either.

Regards,
James Huang

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Mon, 22 Apr 2002 15:46:09 -0700

You are looking at the wrong spec.

Go to "draft-ietf-pim-dm-new-v2-01.txt"

FWIW: you might want to reexamine your need for
implementing dense-mode PIM.

On Monday, April 22, 2002, at 01:21 PM, James Huang wrote:

> Section 5.6 "Timing out multicast forwarding entries" in 
> draft-ietf-idmr-pim-dm-06.txt has some description but the document is 
> more than four years old.
> Shouldn't the management of the expiration timer be standardized?  
> Should the timer be updated only upon receiving (S,G) data packets or 
> should it also be updated when a state-refresh message or prune message 
> is received??  What bothers me is that the following scenario may occur 
> if the expiration timer is not standardized.
>
> Suppose a downstream router R2 ages out a (S,G) entry before its 
> upstream router R1 does. If the source S becomes active again after the 
> (S,G) entry in R2 is aged out but before R1 ages out its (S,G) entry 
> and suppose R1's interface toward R2 is in the pruned state, then R2 
> will not be able to receive (S,G) traffic from R1 and re-create (S,G) 
> entry until R1 times out the prune timer of its downstream interface.  
> Now if R2 receives a igmp (*,G) join during this period, it will not be 
> able to send a graft(S,G) message toward the source.  So the receiver 
> will not receive (S,G) traffic either.
>
>
> Regards,
> James Huang
>