Subject: [pim] (S,G,RPT) state

From: "Srikanth Rao" <[email-masked]>
Date: Tue, 12 Jun 2007 16:27:23 -0700

Hi,

When a upstream PIM router receives (*, G) prune as a result of
RPTJoinDesired(G) becoming false in a downstream router, there doesn't
seem to be any mention in PIM-SM draft/RFC about visiting the (S, G,
RPT) states for the group. Since the downstream router suppresses the
(S, G, RPT) join in this scenario (ref: triggered SGRPT messages, in the
RFC), there won't be any explicit message received to clean up the DS
state on the upstream routers. The side effect of this is it leaves a
stale (S, G, RPT) state, until the ET expires for this DS interface. Has
anybody seen/addressed this issue or is it just left to the
implementation?

Thanks

-Srikanth

I am referring to the following clip from the draft/RFC, applicable to
downstream router.

PruneDesired(S,G,rpt)->FALSE
      See macro above.  This transition is only relevant in the "Pruned"
      state.
 
      If the router is in the Pruned(S,G,rpt) state, and
      PruneDesired(S,G,rpt) changes to FALSE, this could be because the
      router no longer has RPTJoinDesired(G) true, or it now wishes to
      receive traffic from S again.  If it is the former, then this
<<<< suppressed on the DS router
      transition should not happen, but instead the
      "RPTJoinDesired(G)->FALSE" transition should happen.  Thus, this
      transition should be interpreted as "PruneDesired(S,G,rpt)->FALSE
      AND RPTJoinDesired(G)==TRUE".

            The action is to send a Join(S,G,rpt) to RPF'(S,G,rpt).

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

---

From: John Zwiebel <[email-masked]>
Date: Tue, 12 Jun 2007 18:25:29 -0700

On Jun 12, 2007, at 4:27 PM, Srikanth Rao wrote:

> RPTJoinDesired(G) becoming false in a downstream router, there  
> doesn’t seem to be any mention in PIM-SM draft/RFC about visiting  
> the (S, G, RPT) states for the group. Since the downstream router  
> suppresses the (S, G, RPT) join in this scenario (ref: triggered  
> SGRPT messages, in the RFC), there won’t be any explicit message  
> received to clean up the DS state on the upstream routers. The side  
> effect of this is it leaves a stale (S, G, RPT) state, until the ET  
> expires for this DS interface. Has anybody seen/addressed this  
> issue or is it just left to the implementation?
>
>
The only reason to have (S,G,RP-bit) state is to stop forwarding down  
the shared-tree.
If the shared-tree goes away, the (S,G,R) state should go away also.

But you can do what you want.  :-)