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: "Ketan Talaulikar" <[email-masked]>
Date: Fri, 12 Mar 2004 14:10:55 +0530

> (since PruneDesired also becomes false for the

Please refer to section 4.5.9 and the action descriptions of
"PruneDesired(S,G,rpt)->FALSE" and "RPTJoinDesired(G)->FALSE". This explains
how the above situation is handled.

> shared tree traffic, the (S,G,rpt)  Join would be

The reason why it should not be generated is because it is redundant and
infact contradictory. (*,G) prune implies we dont want traffic on the RPT
while the (S,G,rpt)join implies that we want traffic for a particular S on
the RPT !!!!

>  downstream state machine."

The intention of this statement is to separate the downstream (*,G) and
(S,G,rpt) pruned states to take care of the (*,*,RP) scenario as well. Note
that (S,G,rpt)pruned state can exist without (*,G) if there exists (*,*,RP)
joined state. Hence the separate RPTJoinDesired(G) macro and the separate
handling for the two reasons for "PruneDesired(S,G,rpt)->FALSE" transition.

> (S,G,Rpt) state or the combination should be allowed.

The reason why the (S,G,rpt) state cannot be cleared is because there can be
a (*,*,RP). So this blanket action is not correct.

--
Ketan TALAULIKAR
FutureSoft
www.futsoft.com
Work: +91-44-24330550
Mobile: +91-9840088601

***************************************************************************
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: "Ketan Talaulikar" <[email-masked]>
Date: Fri, 12 Mar 2004 14:10:55 +0530

--
Ketan TALAULIKAR
FutureSoft
www.futsoft.com
Work: +91-44-24330550
Mobile: +91-9840088601

---

From: Suresh Boddapati <[email-masked]>
Date: Fri, 12 Mar 2004 09:03:33 -0800 (PST)

> "PruneDesired(S,G,rpt)->FALSE" and
> "RPTJoinDesired(G)->FALSE". This explains
I am obviously talking about a case where the router
does not have (*,*,RP) state (in the example I
mentioned). So both RPTJoinDesired and PruneDesired
will become FALSE and cause an (S,G,Rpt) Join to be
triggered.

> while the (S,G,rpt)join implies that we want traffic
Obviously. That does not answer my question though.
Per the draft, the (S,G,Rpt) state on the upstream
router does not get cleared in this situation until
the timer expires. (S,G,Rpt) state does not return to
No Info when it could have. The contradiction that I
am pointing out is that at one place we assume that
(*,G) Prune does not effect (S,G,Rpt) Prune state
(again assume there is no (*,*,RP) in the picture
please) and at another place, we assume that sending
(S,G,Rpt) Join is meaningless since (*,G) Prune means
we do not want traffic from the shared tree.

I am not saying that we should clear (S,G,Rpt) state
upon receiving a (*,G) Prune blindly. If we allow the
(S,G,Rpt) Join to be sent along with the (*,G) Prune,
it will cleanly clear the (S,G,Rpt) state. Certainly,
the protocol can handle this. 
Otherwise, a more complex way would be to add extra
checks to see if (*,*,RP) state is not present on that
downstream interface and clear the (S,G,Rpt) state if
you receive a (*,G) Prune and a similar check when you
receive a (*,*,RP) Prune. 

Allowing the (S,G,Rpt) Join to be sent along with the
(*,G) Prune to delete the (S,G,Rpt) Prune state keeps
things simple and correct.

Suresh

---

From: Suresh Boddapati <[email-masked]>
Date: Fri, 12 Mar 2004 09:03:33 -0800 (PST)

Suresh

---

From: John Zwiebel <[email-masked]>
Date: Fri, 12 Mar 2004 09:47:01 -0800

> things simple and correct.

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.

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.

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.

---

From: John Zwiebel <[email-masked]>
Date: Fri, 12 Mar 2004 09:47:01 -0800

---

From: Suresh Boddapati <[email-masked]>
Date: Fri, 12 Mar 2004 10:43:39 -0800 (PST)

> shared tree is gone, there's no need for (S,G,R)
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.

> be sending (S,G,R) prunes.  This state will time
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. 

> packets from flowing down the shared tree, you've

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?

---

From: Suresh Boddapati <[email-masked]>
Date: Fri, 12 Mar 2004 10:43:39 -0800 (PST)