Subject: PIM-DM forwarding entry timers need to be refreshed by prunes too

From: Bill Fenner <[email-masked]>
Date: Tue, 17 Nov 1998 16:33:37 PST

Currently, the PIM-DM spec says that the timer for a forwarding entry
is refreshed to [Data-Timeout] when data flows, and if the oiflist is
empty it is set to the maximum of the downstream prunes.  This can
cause transient black holes for busrty sources; the timers also have to
be extended when sending a prune upstream or when not overriding a
prune that another router has sent upstream.  In addition, the timer
should include the entire lifetime of all downstream prunes, no matter
whether the oiflist is empty or not.

Scenario:  A, B, C share a LAN.  A is the upstream towards source S, B
and C have no other neighbors.  There is a group member behind B and
C.

At time t, S stops sending, so A, B and C stop updating their timers.
They all currently expire at t+[Data-Timeout] = t+210.

At time t+60 seconds, the group member behind B leaves.  B sends a
prune upstream with 210 seconds as the prune hold time.  C cancels the
prune because the member behind C has not left.

At time t+200 seconds, the group member behind C leaves.  C sends a
prune upstream with 210 seconds as the hold time.  A refreshes its
forwarding cache entry for (S,G) with the downstream prune hold time as
described in the 3rd paragraph of section 5.6 .  The interface will be
pruned until t+410.

At time t+210, B and C delete their forwarding entries.

At time t+215, a new group member appears behind B.  B sends no graft,
since it has no forwarding entry.

At time t+220, S starts sending again.  However, A's interface is still
pruned and will remain so until t+410.

Therefore, the group member behind B sees a black hole until t+410.

When C sends the prune upstream, and when B hears C's prune, they both
need to refresh their forwarding entry timers for the lifetime of the
prune.

To see why the timer should include the entire lifetime of all
downstream prunes whether or not the oiflist is null, imagine the same
topology, with the addition of an additional link on A with a group
member present, and S stops sending at time t.  A's group member never
leaves, so it never satisfies the "Once all interfaces ... are pruned"
condition.

Continue with the same series of events; consider the prune that C
sends at t+200.  C, for the reason stated above, will refresh its
forwarding entry to expire at t+410.  However, A does not refresh its
timer since when the oiflist is not empty it only refreshes on data
flow.

At t+210, A's timer expires, so it deletes the forwarding entry.

At t+220, S starts sending again, so A creates a new (S,G) and
populates the oiflists, including the interface towards B and C.
Section 5.2.1 seems to almost say that prunes aren't retransmitted on
LANs(*), so neither B nor C retransmit their prunes.  Therefore, this
LAN is a white hole until t+410 when C's prune expires.  This isn't
that big a deal with prune retransmission (it'll only be a white hole
for the prune delay time).

  Bill

* - the exact wording is "PIM-Prune messages must not be sent on LANs
in response to each ... packet".  This sounds like it might have been
intended to mean that prunes in response to traffic flowing on negative
cache entries must be rate-limited, but also might be interpreted to
mean that you never send a prune.

---

From: Liming Wei <[email-masked]>
Date: Tue, 17 Nov 1998 21:12:00 -0800 (PST)

> X-UIDL: 065bc1caa54a0e868e482fa7cabdc960
> X-SMAP-Received-From: outside
> From: Bill Fenner <[email-masked]>
> Date: Tue, 17 Nov 1998 16:33:37 PST
> Sender: [email-masked]
> Precedence: bulk
> 

It means an implementation should not be triggered to send a prune for
each data packet it received.

I'll need to check the other scenarios.

-Liming

---

From: Bill Fenner <[email-masked]>
Date: Wed, 18 Nov 1998 00:39:40 PST

>each data packet it received.

Does that mean that it's OK to send a prune for every other data packet?

  Bill