I think it often helps to use the old PIM-SM vs. PIM-DM example, where one might be more beneficial than the other depending on how sparse or densely distributed your receivers are. I-PMSIs certainly make a lot more sense for cable providers and other similar networks where content must be distributed to a bunch of head-end devices before being sent to set-top boxes, similar to your network Mark.
On the other hand, S-PMSIs definitely make sense where receivers are more sparsely distributed and bandwidth considerations are paramount so relieving unnecessary replication state is desired. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Sep 19, 2011, at 9:45 PM, Mark Tinka <[email protected]> wrote: > On Friday, September 16, 2011 09:46:41 PM Krasimir Avramski > wrote: > >> Hi, >> >> It is normal behavior with inclusive P-tunnels (in your >> case P2MP lsps).It is default without explicit selective >> configuration. > > Indeed. > > We initially started out with I-PMSI's and then wanted to > shift to S-PMSI's, but then since we needed to deploy MPEG > probes at every Receiver PE router to record video signal > quality (and because any router configured with the NG-MVPN > routing instance has at least one IPTv customer), keeping I- > PMSI's makes sense. > > If you don't expect a Receiver PE router to ever have > Multicast receivers, you likely won't be setting P-tunnels > towards it in the first place :-). > > Now the annoying bit is when you use 'vrf-table-label' and a > P router generates two copies of every Multicast packet > toward a bud node. Quite annoying. > > Cheers, > > Mark. > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
