Subject: Re: question about timers

From: Bill Fenner <[email-masked]>
Date: Thu, 3 Dec 1998 09:20:34 PST

I think the entry timer should win, although you're right that the spec
as written has problems with allowing black holes.  See my message,
"PIM-DM forwarding entry timers need to be refreshed by prunes too"

http://www3.juniper.net/~pusateri/pim/1998-html/0230.html

for a solution to the black hole problem.

Another black hole, which I didn't mention in my earlier messages about
timers, is possible due to an ambiguity in the spec.  The spec doesn't
say when the upstream router starts its prune timer when processing a
prune on a multi-access LAN; if it starts it after the prune-delay
(e.g. R2 sends prune with 210 second timer, R1 delays 3 seconds to wait
for prune-overrides then prunes; does it set the interface prune timer
to 210 or 207 seconds?) then there can be a 3 second black hole after
R2's state expires but R1's state hasn't.

If R1 starts the prune timer when it receives the prune, then even if
traffic is no longer flowing and no more group members are present
downstream, R1 will send a graft upstream 3 seconds before its prune
expires.  This graft is wasted; the state could have timed out.  The
wasted graft issue is addressed in my message, "Prune timers in
PIM-DM", at

http://www3.juniper.net/~pusateri/pim/1998-html/0229.html

  Bill

---

From: Liming Wei <[email-masked]>
Date: Thu, 3 Dec 1998 18:49:14 -0800 (PST)

> From: Bill Fenner <[email-masked]>
> 

Bill,

Sorry for the late response. Here is an exerpt from the spec, that
I think you missed. The blackhole you stated should not exist.

  If the prune timers on different outgoing  interfaces  are  different,
  the  pruned  interface  with  the  shortest remaining timer may expire
  first and turn the negative cache entry into  forwarding  state.  When
  this  happens,  a  graft should be triggered upstream. When a negative
  cache entry turns into a forward entry,  the  entry  timer  should  be
  restarted  with  the  default  expiration  timer. Once the (S,G) entry
  times out, it will be recreated when the next multicast packet or join
  arrives.

-Liming

---

From: Bill Fenner <[email-masked]>
Date: Thu, 3 Dec 1998 18:53:49 PST

Liming,

  No downstream prunes time out in the scenario in the "PIM-DM
forwarding entry timers need to be refreshed by prunes too" message
that I referred to, so I'm not sure why you're referring to that
section of the spec.  I am aware of that portion of the spec; the
"Prune timers in PIM-DM" message addresses the problem that I have
with it.

  Bill

---

From: Gerhard Gessler <[email-masked]>
Date: Fri, 04 Dec 1998 13:16:26 +0100

Bill Fenner wrote:
> as written has problems with allowing black holes.

Hi Bill,

I´m not sure whether I understand you correct.
You say that the entry timer (the exiration timer of the (S,G)-entry ??)
should win (-> is considered first).
If this is true then there is really the possibility of a black hole.
But if we consider the prune timer of the pruned outgoing interface
first (-> the prune timer wins and turns the pruned oif into forwarding
state) than there is no possiblity of a black hole in this special
scenario as long as the source keeps on sending.

> See my message,
I have checked the scenario and I agree that refreshing the prune timers
is a possible solution. The work to be done in the routers should not be
a big deal as they have to listen to prune-messages anyway to do a
prune-override if needed.

> R2's state expires but R1's state hasn't.
Thats true. Actually I think that the interaction between timers and
their priority if they time out simultaneous is not always clear in the
specification (see my question about timers).

> http://www3.juniper.net/~pusateri/pim/1998-html/0229.html
Seems to make sense.

   Gerhard

-- 
---------------------------------------------------
Gerhard Geßler

IABG mbH, Abteilung CC31
Einsteinstr. 20
85521 Ottobrunn

Tel. (089) 6088 3539
Fax: (089) 6088 2845

E-Mail: [email-masked]

---

From: Bill Fenner <[email-masked]>
Date: Fri, 4 Dec 1998 08:36:48 PST

In message <[email-masked]>you write:
>I'm not sure whether I understand you correct.

I'm saying that the entry timer should be considered first and the
spec should be modified to prevent the black hole.

On the other hand, PIM-DM already sends lots of grafts, so maybe
it's more in the spirit of the protocol to add more grafts.

  Bill

---

From: Gerhard Gessler <[email-masked]>
Date: Mon, 07 Dec 1998 16:04:01 +0100

>   times out, it will be recreated when the next multicast packet or join
The problem we address here is that the oif-list of the (S,G)-entry
contains only one interface. Thats why both timers (expiration timer and
prune timer) are started with the same time [holdtime], expire at the
same time and there is no other prune timer that turns the (S,G)-entry
from pruned-state into forwarding-state before the expiration timer
expires.
I.e. if the expiration timer of the (S,G)-entry wins (as Bill says) the
entry is deleted. This can result in a black hole in some cases.

   Gerhard

IABG mbH, Abteilung CC31
Einsteinstr. 20
85521 Ottobrunn

Tel. (089) 6088 3539
Fax: (089) 6088 2845

E-Mail: [email-masked]