Subject: Re: join(s,g) on shared tree

From: Arup Acharya <[email-masked]>
Date: Wed, 20 Jan 99 13:51:30 EST

-     All a (S,G,R) join or prune means to to send this state up the shared-tree.
-     If you didn't have state for (S,G,R) prior to receiving an (S,G,R) join,
-     the receiver could treat it as a noop provided it had (*,G) state.

what if I had no (*, G) state or (S, G, R) state prior to receiving
a (S, G, R) join ? if the intended action is to create (S, G, R)
state (to recv traffic from S via the shared tree), then that should
be included in the protocol definition to ensure the intended 
semantics?
 
- >> maybe it'd be worthwhile to consider how igmpv3 will effect the
- >> current pim spec (if at all).  i.e., is it as simple has having a DR
- >> send (s,g) join/prunes in addition to the (*,g) joins it sends now?
- 
-     Well, when a host sends a report for (S,G), it is requesting data only
-     from source S sending to group G. The most efficient way to provide the
-     delivery service is with a source-tree. 

Right..efficient in terms of e2e delay, but not necessarily in terms of
of network-state (as you indicate below)

-     However, if the router is
-     already receiving data from G on the shared-tree and the delay requirements
-     are met, there is no reason to set up (S,G) state (since it may already
-     be getting data from the S). I think it is safe to leave these decisions
-     for the implementation.

Not sure if this is  a purely implementation choice or should be part
of the protocol definition....
arup