Subject: RE: [pim] Question on PIM Assert FSM

From: "Loke, Swee" <[email-masked]>
Date: Mon, 10 Feb 2003 13:44:41 -0500

Thanks for the response. More comments below.
 
> On Friday, February 7, 2003, at 09:45 AM, Loke, Swee wrote:
> 
> > Hi,
> >
> > I have questions on PIM Assert FSM in the new draft.
> >
> >
> > Receiver---|       better path
> >            |---R1----.......---R10(RP).....
> >            | i1                /
> >            |                  /
> >            |---R2(DR)---...--/
> >              i2
> >
> > In this example, R1 and R2 are on the same subnet (connected
> > via i1 and i2 respectively) as the receiver. R2 is the DR.
> > The receiver joins (*,G1) for which R10 is the RP. R1 has
> > better path to the R10 and it is R2's RPF(R10) neighbour.
> >
> > And R1 (non DR) will keep (*,G1) oif=null.
> 
> If R1 is the RPF neighbor for R2 for the RP-address then
> it will be R2 that has a NULL olist not R1.

Sorry, the oif=null was before R2 sends the triggered upstream join.
I should have either mentioned the IGMP join later or included
i1 in the oif list. 

> > Since R2 is the DR, it keeps the route (*,G1) iif = i2
> >                                               oif = {i2}
> 
> This is correct and implementation specific.  Some implementations
> will not have I2 in the Olist.  Some will.  The important thing
> is that R2 as the DR is responsible for sending (*,G) joins toward the
> RP and in the way you describe this scenario, those joins
> will be sent to R1 which means R1 will not have a NULL Olist.

Correct.  

> > Question 1:
> > Is this legal, to have iif==oif? If PIM removes the iif
> > from the oif list, R2 will end up with oif(*,G1)=null and
> > will send a prune instead of a join, and delete the entry).
> 
> Which it obviously can't do.  Whether or not you put the
> OIF in the Olist is implementation specific.  Cisco does
> not put the OIF in the OLIST, but does mark the (*,G)
> with the knowledge that the IGMP cache is non-null.
> 
> >
> > Question 2:
> > Assume it is legal in pim to have iif in the oif list, and R2 keeps
> > that entry, and R2 sends pim join to R1, and R1 will just add
> > i2 to its oif.
> 
> There is no need for an assert here.  The RPF for R2 is through
> R1.  R2 is not going to forward a packet received on I2 back out
> I2.

Ya, but if we can trigger assert in this scenario (maybe based
on iif=oif in R2 or something else), R1 will become the assert
winner and R2 doesn't need to send periodic join to R1 anymore. 
It just seemed more efficient that way... I just wonder why we
don't trigger an assert in this case.
 
> > In the PIM Assert FSM, if traffic doesn't arrive, there is nothing
> > to trigger the Assert. In the NoInfo state, only receiving an
> > assert or data can transition it to a different state. Hence at
> > the mean time, R2 has to send periodic joins upstream to R1 (assume
> > it doesn't delete i2 from the oif(*,G1) list) and that doesn't seem
> > efficient. If we allow the transition for R2 to become Assert Winner
> > earlier, R2 will not need to send periodic join to R1 for(*,G1)
> > anymore.
> >
> > Please let me know if I miss something in the new draft.
> >
> > Thanks,
> > swee
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Mon, 10 Feb 2003 11:00:32 -0800

If you are suggesting that R2 should trigger an assert to
hand off DR functions to R1, I suppose one could, but I
doubt you are going to get any implementers to change what
they have now since there doesn't appear to be much of
a gain in functionality and its important to keep the DR as
the DR to avoid confusion when trying to debug a network
problem.