Subject: Re: [pim] Prune Pending Timer 5s

From: "Sundeep Singatwaria" <[email-masked]>
Date: Sun, 2 Dec 2001 22:53:47 -0800

----- Original Message -----
From: John Zwiebel <[email-masked]>
To: Singatwaria, Sundeep [SC7:370:EXCH] <[email-masked]>
Cc: pim <[email-masked]>
Sent: Friday, November 30, 2001 3:28 PM
Subject: Re: [pim] Prune Pending Timer 5s

> Sundeep Singatwaria wrote:
> >
> > Could the authors explain why we have a prune pending timer of 5 seconds
in
> > the new draft. 2236 has it as 70s
>
> 2236 is IGMPv2.

I mean 2362 - bungled couple of numbers.
>
> -- The RP only has to prune once.
> -- (S,G,R) prunes are only valid on "inherited" olists
> -- The (S,G) join received by r1 makes it an "immediate" olist.
>
> FWIW, at cisco when this problem first came up we ignored
> (S,G,R) prunes for (S,G) entries.

Ignoring the prunes will have data coming from both RP and SG tree.

> Data may flow for an extra
> 3 minutes, but that's no big deal.
>

Why only 3 minutes.

> >
> > Consider following scenarios.
> >
> > Case 1:
> >
> > sender
> > r1           r2 (RP)
> > |               |
> > -------------- multiaccess LAN
> > |               |
> > r3            r4
> > receiver
> >
> > r3 upstream for RP is r2 and r3 upstream towards source is r1. When r3
> > switches to SPT it will
> > prune the RP tree and will receive data from r1. so the only check done
is
> > upstream router address is different - no same iif check - else we will
> > forever get the data from the RP tree
> >
> > Source ->r1 -> r2(RP) ->r3->receiver
> >
> > r1, r2 and r3 are on the same subnet. R3 upstream for source is r1 and
r2 is
> > configured as the RP. r3 will send a prune towards RP and join towards
> > source. (S,G) joins towards source and (*,G) join + (S,G,RPT) prune at
the
> > RP can go at different times. So R2 with every S,G,RPT prune will prune
off
> > the S,G tree also.
> > This will stop the traffic till the next S,G join repairs the state. So
the
> > receiver will never receive data continously.
> >
> > With 70s PPT r2 will cancel the PPT when it receives a join every 60s.
so
> > traffic will never stop. However with 5s PPT traffic will stop
> > intermittently.
> >
> > Sundeep
> >
> > _______________________________________________
> > Pim-external mailing list
> > [email-masked]
> > http://mailist.procket.com/mailman/listinfo/pim-external

---

From: John Zwiebel <[email-masked]>
Date: Mon, 03 Dec 2001 09:33:29 -0800

> Ignoring the prunes will have data coming from both RP and SG tree.

aren't you sending (*,G) joins with (S,G,RP-bit) prunes toward the RP?
That's why 3 minutes.

The prunes are ignored when you have (S,G).  The path to the RP
(r2) will have (S,G) state but the lan won't be in the OIF list for
that source.

In any case only one packet gets forwarded on to the receivers since
an assert would turn that off.

A more "interesting" problem would be having one path to a receiver
wanting to join the SPT and a different receiver wanting to stay on
the RP-tree.  Perhaps that was what you were describing?

In that case an assert process would happen every time a (*,G) only 
join was sent.  Still no black holes or

---

From: "Sundeep Singatwaria" <[email-masked]>
Date: Mon, 3 Dec 2001 10:48:31 -0800

----- Original Message -----
From: John Zwiebel <[email-masked]>
To: Singatwaria, Sundeep [SC7:370:EXCH] <[email-masked]>
Cc: pim <[email-masked]>
Sent: Monday, December 03, 2001 9:33 AM
Subject: Re: [pim] Prune Pending Timer 5s

> (r2) will have (S,G) state but the lan won't be in the OIF list for

Are you suggesting that S,G,RPT prunes must always be ignored when there
is a (S,G) state.

---

From: John Zwiebel <[email-masked]>
Date: Mon, 03 Dec 2001 13:42:15 -0800

> Are you suggesting that S,G,RPT prunes must always be ignored when there

No, never said anything like that.  I explained that an (S,G,R) prune
can not always be accepted on an (S,G) entry and that at Cisco we
"solved" the problem by ignoring those prunes.  That reference was 
entirely historical but _may_ be a solution for _some_ vendors.

The new pim spec clearly makes a distinction between an inherited and
an immediate olist entry.  If you can implement that, then you should.
If you can't then ignoring the (S,G,R) prune would be an acceptable
alternative since it does work fine.  The only downside is that
there _may_ be data for a given S being forwarded down the shared-tree
when it isn't necessary.  But once the (S,G) entry on a given router
has a NULL olist, which will happen because that router isn't receiving
(S,G) JOINs. Then that router too will start sending (S,G,R) prunes
(in topologies and cases where it matters -- not in all cases which
are way too numerous here to go into.)

So, if you want to revisit your question, I am saying that a router
with (S,G) state and a non-NULL olist, that hasn't implemented
'inherited/immediate' olists can be fully interoperable with the new
pim spec by ignoring (S,G,R) prunes.  If you are concerned with the
possibility of data flowing down the shared tree for an extra 3 minutes
(or 3.5 minutes depending on which expiration timer you use) I'd have
to ask why you care?  I advocate implementing hysteresis in PIM for
some topological configurations.  It isn't that important to prune
off a a branch immediately, one of those branches being the X-line
between the source and the RP, since -- depending on how receivers
leave and join the multicast group -- you can easily find yourself in
a situation where you are generating lots of control traffic as members
join and leave the multicast group.

---

From: demir <[email-masked]>
Date: Mon, 3 Dec 2001 14:16:01 -0800 (PST)

I am not very familiar with this thread. I have a question:

Why the tymer is set to 5s?

Dr. Alper K. Demir