Subject: [pim] Update_SPTbit(S,G)

From: "Ju, Yu" <[email-masked]>
Date: Thu, 27 Jun 2002 17:15:13 -0400

Hi,

When a packet arrives, the (S,G) SPTbit is updated as follows:

     void
     Update_SPTbit(S,G,iif) {
       if ( iif == RPF_interface(S)
             AND JoinDesired(S,G) == TRUE
             AND ( DirectlyConnected(S) == TRUE
                   OR RPF_interface(S) != RPF_interface(RP)
                   OR inherited_olist(S,G,rpt) == NULL
                   OR RPF'(S,G) == RPF'(*,G) ) ) {
          Set SPTbit(S,G) to TRUE
       }
     }

So if the condition is not satisfied, the SPTbit(S,G) is not set to TRUE and
keep its previous value which could be TRUE. 
So once SPTbit(S,G) is set to TRUE, it will never be set back to FALSE until
(S,G) state times out.  Am I right? Is this why PIM-SM does not provide a
mechanism to switch back from SPT tree to RPT tree?

Thanks,

Yu
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Mark Handley <[email-masked]>
Date: Thu, 27 Jun 2002 14:26:06 -0700

>Is this why PIM-SM does not provide a

We took a policy decision, after spending a lot of time looking at the
issue, that on balance the complication you need to add to make
switching back work flawlessly is simply not worth the benefits.  I
don't recall all the issues anymore, but there were many.

Cheers,
	Mark

---

From: John Zwiebel <[email-masked]>
Date: Thu, 27 Jun 2002 17:22:19 -0700

> mechanism to switch back from SPT tree to RPT tree?

I recommend you not go down that path.  how do you decide when
to move from the SPT to the RPT?  What kind of hysteresis will you
install to make sure that you don't flip-flop back and forth causing
lost packets and/or duplicate packets at every switch.

Remember, the general consensus (meaning me, myself and I -- maybe
a couple other folks) is that PIM-SM has not shown itself to be
of long-term use and that the multicast community 'should' be moving
to bi-dir PIM and SSM (mostly SSM right now) as quickly as possible.

There are a number of app developers who disagree on that point, and
they have a valid position since they want the network to track all
the users so they don't have to set up a separate report (IGMPv3) for
each participant.

However, I have not heard anyone suggest the requirement to back to
the shared-path is required or even desired.  There are some
companies that have a need to stay on the shared-tree because of the
large number of multicast groups they are sending to.  These folks
have "solved" the problem by placing their sources directly connected to
the RP.  If they had to depend on PIM registers to encapsulate
data to the RP for distribution down the shared-tree, they would need
something other than a router to handle the traffic load.

So, in summary, yes you can probably kludge something to move back
to the RPT, but it isn't required and won't be used and has not proven
viable.

2cents.