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

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?
> > 
> > 
> 
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim
> 

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

---

From: Suresh Boddapati <[email-masked]>
Date: Sat, 13 Mar 2004 12:52:34 -0800 (PST)

Shankar,
Nicely put. I guess I have ended up steering the
conversation towards when an upstream router can time
out a downstream (S,G,Rpt) state. This was not my
original intention. My original intention was
regarding disallowing the combination of a (*,G) Prune
and an (S,G,Rpt) Join. That said, I have some specific
comments inline which elaborate on it further. 

> (S,G,rpt) states. That is 
 
I agree. As I mentioned in my previous emails, we
would take out the (S,G,Rpt) state only if we dont
have a (*,*,RP) downstream state on this interface and
we receive a (*,G) Prune. We would do the same when we
receive a (*,*,RP) Prune, but now we would have to go
through all (S,G,Rpt)s and check their downstream
state to see if we can take it out. In my mind, this
is a more complex check than just sending an (S,G,Rpt)
Join. 

> To me it doesnt matter. perhaps depends on how one's
> implementation maintains a (S,G,rpt) state.
I agree it is pretty much an academic discussion when
the (S,G,Rpt) state can time out. But more than when
the state can time out, what seems wrong is
disallowing the combination of a (*,G) Prune and an
(S,G,Rpt) Join. Please read below further. 

> 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. 
> 
It's not as complicated as you think. On the
downstream router, PruneDesired becomes false only if
RPTJoinDesired becomes false which would happen only
if JoinDesired for both (*,G) and (*,*,RP) are false.
So the downstream router knows exactly whether it
should send an (S,G,Rpt) Join or not. The only problem
is that the combination of sending a (*,G) Prune and
an (S,G,Rpt) Join being disallowed causes it to not
send it. Which I feel is unnecessary. There is a clear
cut case here where JoinDesired  becomes false causing
a (*,G) Prune and an (S,G,Rpt) Join to be sent at the
same time and we are suppressing the (S,G,Rpt) Join
just because we are sending a (*,G) Prune. The
combination might seem meaningless at first, but if
you want to be pedantic about it, one can argue that
since Joins are followed by Prunes in the packet, we
are first joining the shared tree only to prune it off
later. I like to cleanup things as soon as I am done
with them. If you say it is left to the
implementation, I am fine with it. But please do not
put something in the draft that says a router SHOULD
NOT generate such a combination. Hope I have conveyed
my point.

Suresh

---

From: Suresh Boddapati <[email-masked]>
Date: Sat, 13 Mar 2004 12:52:34 -0800 (PST)

Shankar,

Suresh

---

From: "Shankar Vasudevan" <[email-masked]>
Date: Mon, 15 Mar 2004 12:42:48 +0530

Hi Suresh,

 You have overlooked section 4.5.9. When we carefully analyse the
state transition guidelines given there, we wont have a (S,G,rpt) join
generated in the first place ! ( and we wont be having this discussion :-))

I am quoting the following lines from draft-ietf-pim-sm-v2-new-09.txt
section 4.5.9

"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
 ==READ CAREFULLY=>    receive traffic from S again.  If it is the former,
then this
 ==READ CAREFULLY=>    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)."

it says, IF PruneDesired(S,G,rpt) is false JUST COZ RPTJoinDesired(G) is
false,
then this transition (i.e "PruneDesired(S,G,rpt)-> FALSE") SHOULD NOT
happen. and it
is clearly said that we should treat only the "RPTJoinDesired(G) -> FALSE"
transition.
Hence we would have only the state transition to NJ and nothing more.

Hope we are in synch.

Best Regards,
Shankar

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of Suresh
>Boddapati
>Sent: Sunday, March 14, 2004 2:23 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [pim] (*,G) Prune and (S,G,Rpt) state
>
>
>Shankar,

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: "Shankar Vasudevan" <[email-masked]>
Date: Mon, 15 Mar 2004 12:42:48 +0530

Hi Suresh,

Hope we are in synch.

Best Regards,
Shankar

---

From: Suresh Boddapati <[email-masked]>
Date: Mon, 15 Mar 2004 08:00:54 -0800 (PST)

Shankar,

Thanks. I did overlook what you pointed out. Makes me
wonder why it was put in the first place. Whether you
send the RPT Join or not, the only thing getting
effected is when the upstream RPT state times out.
Nobody cares about when that times out, so I guess
it's fine. I just dont see the benefit of saving the
transmission of an (S,G,Rpt) Join when PruneDesired
becomes false due to RPTJoinDesired becoming false.
Seems like it would have been just fine not to special
case it and let the protocol handle it.
It definitely does no harm (unless somebody
erroneously thought that it would actually cause
traffic to flow down the shared tree) and it
definitely has an added benefit of clearing the
upstream state without the upstream router having to
worry about it upon reception of a (*,G) or (*,*,RP)
Prune, if it wishes to clear it early. Or maybe it was
pure semantics that resulted in this - the argument
that it is meaningless to send a Join to the shared
tree for a specific source, when you already have
pruned yourself from it for the entire group - a
little flawed one precisely because there could be
(*,*,RP) state upstream due to which the upstream
router is not supposed to touch the downstream
(S,G,Rpt) state upon reception of a Prune. In any
case, it's fine by me. Thanks once again.

Suresh

--- Shankar Vasudevan <[email-masked]>
wrote:
> >From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Suresh
> >Boddapati
> >> 1) Why dont we remove (S,G,rpt) states on
> receiving
> >> (*,G) prune?
> >>
> >>  The draft was written with (*, *, RP) also in
> mind.
> >> Hence on reception of
> >> 2) Why shouldn't I send a (S,G,rpt) Join along
> with
> >> (*,G) prune ?
> >>
> >> If we should take care of (*,*,RP) situation
> which
> >> the draft covers, then while
=== message truncated ===

---

From: Suresh Boddapati <[email-masked]>
Date: Mon, 15 Mar 2004 08:00:54 -0800 (PST)

Shankar,

Suresh