Subject: Re: [pim] Pim-SM AssertWinner(S,G) state machine

From: Greg Schwendimann <[email-masked]>
Date: Mon, 23 May 2005 11:37:24 -0400

I understand that the upstream neighbor is not taken into account,
however when I lose a neighbor my RPF change and may cause could assert
to become false? 

router1 -- router2 -- router3

If router3 were to stop sending hellos he would be removed from the
mrib?  This would cause router2 to no longer have an rpf, so nothing
would change?  If there were another router on the same network as
router2 and router1 wouldn't router2 need to send an assert cancel so
that the other router would have a chance to re-assert and possible win
now?

On Mon, 2005-04-18 at 21:32, Pavlin Radoslavov wrote:
> > 	I was wondering what would be the effect on an assert winner if his
> > upstream router were to stop sending hello messages (aka pim is turned
> > off) but the routing topology is not changed.  Would CouldAssert become
> > false?
> 
> According to the CouldAssert(S,G,I) and CouldAssert(*,G,I) macros,
> the state of the upstream neighbor router is not taken into
> account.
> 
> Pavlin

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

---

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 23 May 2005 13:16:27 -0700

> that the other router would have a chance to re-assert and possible win

First thing that should happen when the MRIB changes after router3
went down is that router2 should send a Join message toward the new
upstream router. This should pull-down the traffic via the new
upstream and things should continue to work so router2 doesn't need
to send an Assert cancel. Though, the next time router2 resends its
Assert message, if the assert metric of that message has changed,
this may trigger the election of a new Assert winner.

If the new upstream router is router1 (or another router on the
router1 -- router2 subnet), then CouldAssert for the router2's
interface toward router1 will automatically become false because of
the "(RPF_interface(S) != I)" or "(RPF_interface(RP(G)) != I)"
check.

If the MRIB itself didn't change after router3 was taken down, then
there is not much you can do, because in general this is a MRIB
problem that can break the multicast connectivity even if you don't
have Assert state.

Regards,
Pavlin