Subject: [pim] (S,G,rpt) prunes when DR for (S,G)

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Apr 2005 12:35:42 +0300 (EEST)

Hi,

We noticed what seemed to be strange behaviour.  When periodic joins 
(every 60 sec) are sent on a DR for a group (which is a direcly 
attached source) is both sending and receiving, (S,G,rpt) prune (for 
the S=directly attached source) is also attached to the message.

So, let's take an example.  Host 193.166.3.74 has joined 
(*,233.4.200.19) and is also sending to the group.  The DR's periodic 
join/prune message for the group includes about 70 sources which are 
joined.  The DR also attaches (193.166.3.74, 233.4.200.19, Rpt-bit) 
prune to that message.  That results in removing the (S,G) state 
between the DR and the RP, which in turn results in the DR re-starting 
registering and getting back a register stop and trying again (this 
happens every minute).

I can't figure out why the (S,G,rpt) prune is attached to the message. 
However, looking at the rules, it should be done (AFAICS), because:

  - SPTbit for (193.166.3.74,233.4.200.19) is true
  - there are no asserts (this is the single DR)
  - RPF(*,G) points downstream (towards the RP) while obviously
    RPF(S,G) points to the locally attached interface!

So, the implementation appears to ("validly" but with bad results) do 
a register/register-stop cycle (and removing state between the DR and 
RP) by the spec -- but I can't figure out why it should be doing so; 
it doesn't seem to make any sense!

Is the pseudocode flawed for the directly attached (S,G) or is there 
something I'm missing ?

............

4.5.8 (S,G,rpt) Periodic Messages
[...]

When a router is going to send a Join(*,G), it should use the 
following pseudocode, for each (S,G) for which it has state, to decide 
whether to include a Prune(S,G,rpt) in the compound Join/Prune 
message:

   if( SPTbit(S,G) == TRUE ) {
       # Note: If receiving (S,G) on the SPT, we only prune off the
       # shared tree if the RPF neighbors differ.
        if( RPF'(*,G) != RPF'(S,G) ) {
            add Prune(S,G,rpt) to compound message
        }
   }

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: "Venu Hemige" <[email-masked]>
Date: Mon, 25 Apr 2005 10:40:37 -0700

Pekka,

I suspect the problem you are seeing is related to the lack of handling
"turnaround rules". The draft does mention it but does not explain the
rules. Turnaround routers that are in the path from the source-DR and
the RP MUST start keep-alive timer if inherited_olist(S,G) is non-empty
in order to keep (S,G) state alive in the scenario that you mention.
There is pseudo-code in the draft (section 4.2) that addresses this:

if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND
|
    inherited_olist(S,G) != NULL ) {
|
        set KeepaliveTimer(S,G) to Keepalive_Period
|
 }

-Venu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Pekka Savola
> Sent: Thursday, April 21, 2005 2:36 AM
> To: [email-masked]
> Subject: [pim] (S,G,rpt) prunes when DR for (S,G)
> 
> Hi,
>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Apr 2005 08:44:37 +0300 (EEST)

Hi,

>        set KeepaliveTimer(S,G) to Keepalive_Period

Yes, in my case, the SPT and RPT have the equal path, so this triggers 
some side effects for the implementations:

   DR
    |
   RTR -- RP
    |
  Internet

The RP being there (without a direct link between DR and RP) is 
effectively a "turnaround" afaics.

However, after some offlist discussion (thanks!) and rereading the 
spec, I now realize I made a wrong assumption below.  I didn't realize 
that AFAICS (S,G,rpt) prunes should in no way affect (S,G) state, just 
provide an exception list to (*,G) state.   If my reading is correct 
(I believe it is), then the implementations that implement the RPT bit 
correctly should not be affected.