On Wednesday 30 June 2010 09:30:10 pm Humair Ali wrote:

> I think it depends on the size of your network ,to see
>  which is more appropriate, and the setup of the network.
> 
> The larger your network, the better to use selective P
>  tunnels, the smaller then better to use inclusive trees
> 
> The reason is,  using inclusive trees on large size
>  network  means keeping ressources and state accross all
>  PE, where some of PE's potentially will be used very few
>  times .

Our reasoning behind which method we can use is typically 
based on one of two things:

        a) While I-PMSI's would mean all Receiver PE routers are
           involved in the Multicast routing domain, despite
           whether they have listeners or not, we reckon that NG-
           MVPN RSI's would only be configured on a Receiver PE
           router if it handled requests for at least one listener.
           So basically, if we have no listeners downstream of a
           Receiver PE router, no need to have MCAST-VPN NLRI going
           down that way, much less an NG-MVPN RSI configuration.

        b) We could integrate S-PMSI's with RSVP-TE's traffic
           engineering capabilities to guide "very important"
           Multicast traffic down what we think would be the very
           best path.

So they both have use-cases, although we would still be 
working mostly with I-PMSI's in our particular application.

> But the real question is how much more state does it
>  create , in proportion, between inclusive P tunnels and
>  selective , and is it worth the processing on all PE
>  routers compared to a slightly higher burden on few PE
>  routers ?

Regarding the amount of control and forwarding state in the 
core, well, we haven't pushed our network that hard to 
figure anything out other than what we can both read and 
theorize from the spec.

I am waiting for mLDP, however, and would like to see how 
this factors in, although I doubt our application would push 
it that hard, either.

Cheers,

Mark.

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to