Subject: Sending Prune(*,G)/(S,G,rpt)s along with a Join(*,*,RP)

From: Ardas Cilingiroglu <[email-masked]>
Date: Thu, 16 Aug 2001 16:18:32 -0400

Just like sending Prune(S,G,rpt)s along with a
Join(*,G) (section 4.4.8 of the pim-sm draft),
Prune(*,G) and Prune(S,G,rpt)s might need to
be sent along with a Join(*,*,RP).

Define inherited_olist(*,G) =
    joins(*,*,RP(G)) (+) joins(*,G) (+)
    pim_include(*,G) (-) lost_assert(*,G)

The following pseudocode determines whether to
send a Prune(*,G) along with a Join(*,*,RP),
(should be run for each (*,G) where RP(G) == RP):

if (JoinDesired(*,*,RP(G)) AND
    inherited_olist(*,G) == NULL)
{
    # Note: all (*,*,RP(G)) olist interfaces
    # has lost (*,G) assert
    add Prune(*,G) to the compound message
}
else if (RPF(*,*,RP) != RPF'(*,G)) {
    # Note: there was a (*,G) assert and the
    # RPF neighbor for (*,G) is different
    add Prune(*,G) to the compound message
}

The pseudocode in section 4.4.8 should be used
to determine whether to send a Prune(S,G,rpt)
along with a Join(*,*,RP), (should be run
for each (S,G) where RP(G) == RP and Prune(*,G)
is not being sent along with the Join(*,*,RP)).

Thanks,
Ardas

---

From: Marian Stagarescu <[email-masked]>
Date: Fri, 17 Aug 2001 10:25:06 -0400 (EDT)

hello,

in a scenario like below 

---+   0+-------+1   1+------+
src|----|  DR   |--+--|  RP  |
---+    +-------+  |  +------+ 
                   |
               receiver

what should be the ordered list of steps that triggers
traffic to be forwarded to receiver ?

here is my problem:

I noticed that a DR (I am looking at the USC open src
implementation of PIM-SM) delays the forwarding of packets when the RP
is a cisco ios 12.0(9) but works right away (no delay) when RP is a 
cisco ios 12.1. 

I wondered is there is incompleteness in the pim-sm spec 
that introduced such behavior in some implementations.

here is what I see that "should" happen: 

1) Activate source
   a. Source packets are received at (DR): (S,G) created
   b. DR sends register to RP
   c. RP creates (S,G) and (*,G)
   d. RP sends register-stop to DR.
   (no receiver yet)

2) Activate receiver: issues IGMP on the LAN between DR and RP.
   a. DR receives IGMP joins. 
      creates (*,G) with oif = {1} 
      forwards packets.
   b. same igmp join is received also at RP but discarded (not DR)

   c) packets forwarded on lan between RP and DR are received at RP.
      RP creates (*,G) but because is not the DR will have a NULL oif.

what i observed is that:

1) source starts:

a.DR sends Registers
b.DR receives register stops
c.DR receives (periodic) PIM Prune for this (S,G) toward S.
d.DR prunes oif[{1}.

2) receiver starts:

upon receiving IGMP DR does not create the MFC entry for forwarding 
but rather waits (can be up to few minutes)

Question: maybe on a PIM Join from RP ? 
question: or a timer to expire previously pruned (by RP) OIF={1}   

any idea how this can be fixed ? 

thanks,
marian stagarescu

---

From: John Zwiebel <[email-masked]>
Date: Fri, 17 Aug 2001 10:28:57 -0700

Marian: 12.0(9) is "so old" that you shouldn't be using it as
a frame of reference.  FWIW, the new pim spec is very complete
and detailed.  There is lots of room to interpret what is required
and how to implement it, but the final result has to be what they
have detailed.

At this point in the life of PIM, no one has implemented the new
spec.  That doesn't mean that folks aren't working on it.  But
if they say they are "done" with it, they aren't being honest with 
you, because it hasn't been widely deployed to find all the 
implementation corner cases.

And the spec doesn't spell out some "rules" that can help simplify
the understanding required of the protocol.  My favorite is
the "X-line", term I made up, that defines the path from the source
to the RP.  Lots of "cool stuff" happens here and this is where
most implementations mess up.  Note that 12.0 doesn't have the
"X-flag" in it which should give you a clue about how useful it is
in a demanding multicast environment.  (After all, I'm not that 
original).

Your problem can be "fixed" by making sure you aren't running IOS
versions that are so old as to be useless.  (I worked on them, I 
ought to know, it isn't a "perjoritive" attack on Cisco, its my
"fault".)

I'm not saying that the latest IOS version will fix all your problems.
The guys there are working as fast as they can to get multicast stable
and to implement the new spec.  Bug them for what you want.
"cs-ipmulticast.cisco.com" 

z

Marian Stagarescu wrote:
> _______________________________________________
> Pim-external mailing list
> [email-masked]
> http://mailist.procket.com/mailman/listinfo/pim-external

---

From: Marian Stagarescu <[email-masked]>
Date: Fri, 17 Aug 2001 14:11:42 -0400 (EDT)

john,

I agree with you (upgrade ios, indeed I tested my scenario with 12.1 and
up and works) but I have customers that do not want this upgrade so i
wondered if there is something I can do on my side (open-src pimd changes)
to fix this problem: some sort of patch for this case.

any ways, I started to go over the new draft (pim-sm-v2-new-03) but as
you said is not out there. I'll use it as a reference but for now all i
have is few weeks to make this work with the old implementations.

personally i hope to find the time to work an the open-src upgrade to this
draft. so far I commited to pavlin some new features and bug fixes to
pimd-alpha-29.6. 

going back to the problem all i wanted to know was if there is 
a way to make this work (with 12.0's).

my setup is quite simple and I will not need all features 
but definitely i'm not welcoming early bugs either.

the X-flag is not there indeed so "turning around" will not happen.

again, going back to the problem:

I'll focus only on my side (pimd) and describe the states:

I receive (s,g) prune toward S.
(s,g) entry set to:
oif {1} pruned.

delay (2 minutes)

(s,g) entry set to:
outgoing oif = {1}
pruned oif = null; (expired ?)
leaves oif = {1}

what triggers the (s,g) entry to be changed ?
is an external condition (pim JP msg from RP) or an internal timer ?

thanks again,
marian stagarescu

On Fri, 17 Aug 2001,