Subject: [pim] (*,G) Prune and (S,G,Rpt) state

From: Suresh Boddapati <[email-masked]>
Date: Thu, 11 Mar 2004 23:38:40 -0800 (PST)

There seems to be a contradiction in the draft
regarding the (S,G,Rpt) Prune state. Consider a simple
example where you have a (*,G) state as well as an
(S,G,Rpt) Prune state in a router. It has sent both
the (*,G) Join and the (S,G,Rpt) Prune to its upstream
router. Consider that both are sent to the same nbr.
Now, suppose that JoinDesired becomes false for (*,G)
on the downstream router. As a result, a (*,G) Prune
and an (S,G,Rpt) Join need to be sent out
(since PruneDesired also becomes false for the
(S,G,Rpt) state).

Now section 4.10.5.1 states while discussing invalid
combinations..

"o The combination of a (*,G) Prune and a (S,G,rpt)
 Join is also not generated. (S,G,rpt) Joins are only
 sent when the router is receiving  all traffic for a 
group on the shared tree and it wishes to indicate a
  change for the particular source. As a (*,G) prune 
indicates that the router no longer wishes to receive 
shared tree traffic, the (S,G,rpt)  Join would be
meaningless."

In the table following it, the combination has a "?"
mark which means that a router SHOULD NOT generate
such a combination.

This is in direct contradiction with Section 4.5.4
which states in the Notes section
"Receiving a Prune(*,G) does not affect the (S,G,rpt)
 downstream state machine."

In the example mentioned above, if the downstream
router does not send the (S,G,Rpt) Join along with the
(*,G) Prune, the upstream router will not clear the
(S,G,Rpt) state upon receiving the (*,G) Prune and
will keep it until it times out.

Either reception of a (*,G) Prune should clear the
(S,G,Rpt) state or the combination should be allowed. 

Comments?

Suresh

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

---

From: "Shankar Vasudevan" <[email-masked]>
Date: Sat, 13 Mar 2004 18:30:17 GMT

Hi Suresh,

Two things we are arguing about : 

1) Why dont we remove (S,G,rpt) states on receiving (*,G) prune? 

  I think we should not restrict ourselves to one particular scenario.
 The draft was written with (*, *, RP) also in mind. Hence on reception of 
a (*,G) prune we cannot assume that the (S,G,rpt) prune received earlier is invalid. 

If your router doesnot process (*,*,RP) messages then we can safely
assume that (*,G) prune would mean removal of (S,G,rpt) states. That is 
left to you. 

2) Why shouldn't I send a (S,G,rpt) Join along with (*,G) prune ? 

  with the current approach, I agree that it will take a while to get
rid of the (S,G,rpt) states, i.e when the timer expires.
But how does it matter if the state is removed immediately or after sometime ? 
To me it doesnt matter. perhaps depends on how one's implementation maintains a (S,G,rpt) state.

If we should take care of (*,*,RP) situation which the draft covers, then while 
sending (S,G,rpt) join the down stream router should check if it had already sent a (*,*,RP) join and if this shared tree come under that RP, etc and the upstream router should check if it has a (*,*, RP) join on that interface and then decide to act on the (S,G,rpt) join this would require other downstream router on that interface to send a overriding (S,G,rpt) prunes etc.. and hence a mess of a situation. This would happen for each (S,G,rpt) state ! I dont like such a complicated approach. 

If we remove the (*,*,RP) scenarios from the draft, then what you say makes sense.
Till the (*,*,RP) regime exists, this is the simplest way to handle the scenario. 

Best Regards,
Shankar

> --- John Zwiebel <[email-masked]> wrote:
> > Please don't go down this path of reasoning.
> > A (*,G) prune means that the shared path is torn
> > down.
> > Since (S,G,R) state only exists to keep a particular
> > (S,G)
> > from being forwarded down the shared tree, once the
> > shared tree is gone, there's no need for (S,G,R)
> > state.
> I think we are in violent agreement here. My point is
> the state machine does not allow for the (S,G,Rpt)
> state to be taken out. The (S,G,Rpt) State remains in
> Pruned state on the upstream router until the timer
> expires. If the draft said that (S,G,Rpt) state can
> move to NoInfo, it would be fine.
> 
> > 
> > However, if you decide you want to keep (S,G,R)
> > state,
> > please consider that this state is kept alive by
> > the receipt of (S,G,R) prunes from downstream
> > routers.
> > The last-hop that sent the (*,G) prune will no
> > longer
> > be sending (S,G,R) prunes.  This state will time
> > out.
> > 
> Yes. I am just saying that this state can transition
> to No Info much earlier when the (*,G) Prune is
> received and does not have to time out much later. 
> 
> > If you decide to send the (S,G,R) join, then the
> > router
> > should add in OIF so one ends up with state that has
> > a
> > non-null olist and supposedly data will be forwarded
> > down
> > the (S,G,R) path.
> > 
> > Since the original need for (S,G,R) state is to keep
> > packets from flowing down the shared tree, you've
> > now
> > violated that.
> 
> I dont see how this will happen. If you have an
> (S,G,Rpt) state in state Pruned, receiving an
> (S,G,Rpt) Join will take it out of that state. It will
> get added to the oif list only if there is a (*,G)
> state. If there isnt, then it will not have any
> effect, since the oiflist of (S,G,Rpt) is a strict
> subset of (*,G)'s oif list. If you have an (S,G,Rpt)
> state in any other state, the Join will not have any
> effect. So I dont see how that interface will end up
> in the oif list and cause traffic to be forwarded.
> Can you clarify?
> > 
> > 
> 
>