Routing
Routing

Multicast streams in Provider network

‎11-14-2018 04:59 AM

Hi there.

 

Pretty new to multicast, but here goes:

 

Company I work for now has a next-gen MVPN network going with over 1500 multicast streams in total, traffic is about 10Gbps of streams.

We have PE routers in place that are all RR-clients of the P-routers.

Now, all but 2 PE routers are in our back to back datacenters, where bandwidth is no issue, but two PE routers are in remote locations.

Even with no active receivers on these PE routers, the entire multicast vrf is streamed that way, eating up our bandwidth.

I guess this is per design (inclusive tree?), but I cannot get my head around selective tree setup.

Since we are running over 1500 MCG's, selective tree based on wildcards, could prove to be a brainbreaker as well..

Basically we want to oly have streams there that are requested by active receivers.. 

 

Is there any other way to limit the streams that are flooded to these remote PE's?

 

Any ideas?

6 REPLIES 6
Routing

Re: Multicast streams in Provider network

‎11-14-2018 06:40 AM

Are these remote sites stub and not transit sites? Are you using P2MP LSPs?

Routing

Re: Multicast streams in Provider network

‎11-14-2018 10:55 AM
yes these are stub sites and we are running p2mp lsp's
Routing

Re: Multicast streams in Provider network

‎12-05-2018 04:23 AM

anyone?

Routing

Re: Multicast streams in Provider network

‎12-12-2018 08:12 AM

Hi Jaffa,

 

Apparently you described ng-mvpn setup with I-PMSI (Inclusive-PMSI) data plane.

Inclusive here means that all PEs in the ng-mvps domain will receive all mcast traffic,

event if they do not have active receivers.

 

To avoid this unnecessary consumption of bandwidth, you might want to change

data plane to S-PMSI (Selective-PMSI). With S-PMSI only interested in mcast flow

PE would receive it.

 

Obviously changing mode from I-PMSI to S-PMSI would increase the number of

states/tunnels in the ng-mvpn domain. Juniper boxes can easily hande this, but

there is some vendors who cannot (especially if you are using RSVP for signaling).

So, if you have multivendor environment you need to consider this increase in

amount of states.

 

To lear more about I-PMSI/S-PMSI you might refer to the following docs:

https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/vpns-configuring-point-to-...

https://www.juniper.net/documentation/en_US/junos/topics/concept/ptunnels-dataplane-setup-signaling....

 

Also there is a great book - "MPLS in the SDN Era" with great theory and

examples. If you are planning to dive deep into the ng-mvpn, I would highly

reccomend to get this book.

 

Hope this help. Also if it answers you question, please mart it as a solution.

 

Best regards,

Alex

Routing

Re: Multicast streams in Provider network

‎12-12-2018 10:32 AM
Hey Alex,
Thanks for your reply!
I already was diving into the selective setup, but cant get my head around it.
We have over 1500 Multicast Groups, so need to specify tunnel for each?
In the documentation it states that you have to specify the group address. This would not seem very scalable with so many groups flying around..
Am i missing something?
J.
Routing

Re: Multicast streams in Provider network

‎12-13-2018 07:18 AM

Hi Jaffa,

 

So, probably you already get the general idea, with I-PMSI you have one

tunnel for dataplane for each PE. In case of RSVP signaling it is p2mp LSP

tree with root at the source PE.

And with S-PMSI in worst case scenario you have one tunnel per group.

As I wrote S-PMSI will increase complexity of control plane.

 

To answer your specific question:

>We have over 1500 Multicast Groups, so need to specify tunnel for each? 

First, you do not need to specify each tunnel manually.

I do not have experience with mLDP for S-PMSI, but with RSVP you just 

configure a template under [protocols mpls label-switched-path] stanza

and then attach this template to your ng-mvpn RI (routing-instance).

Second, when you use S-PMSI you have few options to control amont 

of dynamically generated tunnels:

> threshold-rate kbps

It will keep all mcast flows below specific rate on I-PMSI tunnel.

And will create S-PMSI tunnels only for "fat" flows which over specific rate.

When the rate of mcast flow drops lower the rate value itgoes back to

I-PMSI tunnel.

 

> tunnel-limit number;

This option allows you to limit number of dynamically created S-PMSI tunnels.

 

So, usually at the beginning you have one I-PMSI tunnel, and than for "fat"

mcast flows new S-PMSI tunnels created dynamically.

 

Also you have means to finally tune for which *,G or S,G you want to use S-PMSI

with "group" statement, for sure you can use 224/4 group or alias "wildcard-group-inet".

 

So, to answer you second question, no you do not need to specify each

group as /32 you can use 224/4 or anything in between. Also you can use 

"wildcard-group-inet" which is an alias for 224/4.

 

To conclude, I would suggest you to play with your flavor (RSVP/mLDP) of

I-PMSI/S-PMSI in the lab to get the feeling. And then you can specify a test

mcast group with "group" statement under [provider-tunnel] stanza and safely

play with it in production.

 

Thanks,

Alex