[j-nsp] P2MP LSP

[Mark Tinka]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100712/e839e16d/attachment.bin>