Subject: RE: [pim] PIM-SM: timer value computation for join suppression

From: James Lingard <[email-masked]>
Date: Thu, 14 Oct 2004 20:26:29 +0100

Mark,

I've just come across this old email of yours which doesn't seem to have had
any further discussion on the mailing list.  My responses are inline.

PIM-SM authors,

I think that Mark has a good point about the potential Join message
implosion if t_joinsuppress is determined by the received Holdtime.  It
would be nice to see this addressed in the draft.

Regards,
James.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mark Doll
> Sent: 12 August 2004 13:41
> To: [email-masked]
> Subject: [pim] PIM-SM: timer value computation for join suppression
> 
> I'm confused about the Join(*,*,RP)/(*,G)/(S,G) timer value 
> computation when suppressing joins.
> 
> The spec states:
> 
>            Let t_joinsuppress be the minimum of t_suppressed and the
>            HoldTime from the Join/Prune message triggering this event.
>            If the Join Timer is set to expire in less than 
>            t_joinsuppress
>            seconds, reset it so that it expires after t_joinsuppress
>            seconds.  If the Join Timer is set to expire in more than
>            t_joinsuppress seconds, leave it unchanged.
> 
> 
> Let's assume HoldTime is small enough to determine the value of 
> t_joinsuppress (presumably the routers on the link have been 
> configured with a different t_periodic) and the router sending this
> Join message stops sending periodic Joins (i.e. the router has gone
> down or a subsequent Prune message has been lost). Since the
> upstream router sets its Expiry Timer to exactly the same value,
> this seems to be a race condition.

If the Holdtime of the message is small enough to determine the value of
t_joinsuppress, it must be less than 1.1 * t_periodic for those routers, and
so it must be (much) less than those routers' Holdtimes.  Therefore, in the
normal case, the upstream router won't set its Expiry Timer to the Holdtime
of the message, since its Expiry Timer will already be running with a larger
period.  So there in no race condition.

Admittedly, if the previous two Join messages from the router with the
larger Holdtime have been lost, then a race condition could arise.  However,
I suspect that this is not a case that the authors had considered important.

> And this might also cause a Join
> message implosion if there are more than two downstream routers with
> Join state.

I agree that this looks like a problem.  I think better definitions of
t_suppressed and t_joinsuppress would be something like:

  t_suppressed = t_periodic when Suppression_Enabled(I) is true, 0 otherwise
  t_joinsuppress = rand(1.0 * min(t_periodic, Holdtime), 1.4 *
min(t_periodic, Holdtime)) 

so that the randomization takes place in every case.

> And of course there is no protection against lost Join messages any
> more as it is the case when the Join Timer periodically fires 3.5
> times during a HoldTime period allowing for two Join messages to be
> lost.
> 
> And what's the motivation behind leaving the Join Timer 
> unchanged when its value is greater than t_joinsuppress? If, again
> the router sending periodic Joins stops doing so, the Expiry Timer
> at the upstream router expires after Holdtime. So the upstream
> router loses Join state since the Join is still suppressed, because
> the Join Timer has not been reduced to HoldTime = t_joinsuppress.

This is not true, because the upstream router can never decrease its Expiry
Timer as a result of receiving a Join message.  Inevitably, the protection
against lost Join messages is marginally weakened by Join suppression, but
it is not removed.

> So why not specifying something like:
> 
>            Reset the Join Timer to the minimum of t_suppressed and
>            HoldTime/3.5*rand(1.1,1.4), where HoldTime is the HoldTime
>            from the Join/Prune message triggering this event.
> 
> Since I'm not a PIM guru I might have overlooked something really 
> important and all the above can never happen. In this case I'm sorry 
> for bothering you with all this...
> 
> Sincerly, Mark Doll.

-- 
James Lingard
Data Connection Ltd (DCL)
http://www.dataconnection.com/

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Mark Doll <[email-masked]>
Date: Fri, 15 Oct 2004 11:17:33 +0200

Hi James,

thanks for your answer!

James Lingard wrote:
> Timer as a result of receiving a Join message.  [...]

Yes, I've missed that cruical point at that time. So this was never a 
problem. What remains is the join message implosion problem, as you've 
pointed out. But I think that my proposal

>>           from the Join/Prune message triggering this event.

amended by (since the upstream neighbor never decreases it's Exiry Timer 
due to a join message)

              If the Join Timer is set to expire in more
              than t_joinsuppress seconds, leave it unchanged.

is more appropriate than your proposal

> so that the randomization takes place in every case.

I think, t_joinsuppress must not be greater than Holdtime from the 
message, as it is the case with your proposal. Otherwise we risk losing 
join state at our upstream neighbor, because we might send our join 
message too late.

- Mark.