Subject: [pim] Question on (*,G) Assert FSM and (S,G,RPT) FSM

From: Christopher Thomas Brown <[email-masked]>
Date: Mon, 02 May 2005 17:03:32 -0400

I have run into a couple of issues recently for which I can't figure out
the reasoning.  Perhaps someone here will be able to enlighten me on
them.

1) In a topology like

SR1     SR2      SR3
 |       |        |
 RP1    RP2(BSR)  P1
-+-------+--------+-

SR1 SR2 and SR3 are senders and receivers for the same group G.
Initially, only RP2 and P1 are running. P1 is switched to the SPT for
SR2. Then RP1 is started with a better priority. RP1 sends a (*,G)
Assert due to the traffic from SR2. RP1's interface to the common
network is then brought down. After RP1's CRP holdtime expires RP2 and
P1 switch to using RP2 as the RP again. However RPF'(*,G) for P1 still
points to RP1 because RP1's neighbor liveness timer has not expired (due
to the (*,G) Assert state).

It seems like (*,G) Assert fsm state should transition to No Info if the
address for RP(G) changes but the (*,G) Assert FSM does not have such a
transition.  This is not a major problem since the state should time out
through either the neighbor liveness timer or the assert timer in a
relatively short time, but I was curious what others think of this
issue.

2) In a topology like

       S
P1+----+------+P2
|               |
|              RP
|               |
+------+--------+
       P3
       |
       R

Initially S is registered to the RP by P2 and forwards down the RPT to
R.  Then P3 switches to the SPT where RPF'(S) is P1. P1 sends an
assert(S,G) which causes the switch to the SPT on P3 to complete.
P3 sends a triggered (S,G,RPT) prune to P1 because it is RPF'(S,G,RPT)
due to the assert(S,G) state.  However, the periodic S,G,RPT prune is
included with the *,G join which goes to RPF'(*,G) ie RP.

I could not make sense out of sending the (S,G,RPT) prune to P1. Why
would we ever want to send a triggered (S,G,RPT) prune to any router
other than RPF'(*,G)? Yet, that seems what the specification would have
us do.

I'd appreciate whatever insight anyone has on these two issues.

Thanks,
Chris

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

---

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 02 May 2005 18:13:04 -0700

> the reasoning.  Perhaps someone here will be able to enlighten me on

If RP1's interface to the common network is brought down gracefully,
then RP1 is suppose to send a Hello message with zero Hello
holdtime. Hence, P1 will immediately timeout RP1 as a neighbor and
the corresponding Assert state.
If RP1 crashes and there is no Hello message with zero holdtime,
then other bad things will happen as well. For example, service
disruption until the crashed RP is timeout by the BSR, etc.

> |              RP

Just for the sake of easier description, let me add another router
P4 between P3 and RP:

       S
P1+----+------+P2
|               |
|              RP
|               |
|              P4
|               |
+------+--------+
       P3
       |
       R

In the setup you describe I believe P3 is not the only router that
originates the triggered (S,G,rpt) Prune. PruneDesired(S,G,rpt) will
become true for P4 as well, so P4 will originate (S,G,rpt) Prune on
its own toward the RP.

Yes, indeed, it appears that the triggered (S,G,rpt) Prune
originated by P3 will go to P1 which I agree is a bit odd. However,
that Prune message is harmless, modulo the fact that it may trigger
transition in the downstream (S,G,rpt) state machine of P1 from NI
to PP.
That transition may create a temporary (S,G,rpt) entry
(implementation-specific), which should timeout after a while. In
the mean time the data packets will be forwarded because of the
(S,G) state.

I believe this is one of those examples that could be optimized to
avoid the unnecessary (S,G,rpt) prune message, but the danger is
adding more complicated rules or increasing the risk of breaking
existing rules.

Regards,
Pavlin