A global bank runs trader voice squawk boxes where every desk both sends and receives bursty group traffic, creating many senders, sparse receivers, and heavy source-registration churn with PIM-SM. How should bidirectional PIM be designed for this many-to-many application?
Select an answer to reveal the explanation.
Short Explanation
When your traders all jump in at once, it's like a party line where everyone's talking — you don't want a separate line for each voice. Bidirectional PIM gives you one shared tree through your RP with DF election, so there's no registration churn.
Full Explanation
Bidirectional PIM builds a single shared bidirectional tree rooted at the rendezvous point where the designated forwarder on each link forwards traffic toward and away from the RP, so both sources and receivers use the same (*,G) state with no source registration, SPT switchover, or per-source state, ideal for many-to-many sparse applications. Scaling PIM sparse mode preserves per-source (S,G) and registration churn that overwhelms the RP with bursty senders and complicates inter-domain MSDP. Migrating to SSM requires a single known source and IGMPv3 INCLUDE joins, which mismatches many senders that change dynamically. Tuning dense mode still floods then prunes, wasting bandwidth and maintaining per-source state that scales poorly for many-to-many voice. For the exam, associate bidirectional PIM with many-to-many, shared tree only, and no registration; in practice verify RP placement, DF election, and that hardware supports bidirectional groups before migration.