[j-nsp] Next Gen MVPN flooding assistance

[Stefan Fouant]

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 <mtinka at globaltransit.net> 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 juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp