[c-nsp] P2MP MPLS TE

Mark Tinka mtinka at globaltransit.net
Mon Sep 19 09:49:47 EDT 2011


On Monday, September 19, 2011 07:58:57 PM Vitkovsky, Adam 
wrote:

> I'm a bit confused with this one
> Is anyone using this in the production network please?
> I'd like to understand in which scenarios these p2mp
> te-tunnels are being used Was this only meant for m-cast
> carried in the Global table? I see how mldp can
> supersede the GRE as well as the default and data MDTs
> in MVPNs -but don't see how I'd leverage p2mp mpls-te to
> carry multicast in the SP core I would really appreciate
> if anyone could shed some light on the technology or
> point out some meaningful documentation

We're heavy users of NG-MVPN (Next Generation MVPN), an 
application that relies on p2mp LSP's to operate.

We're using it to deploy IPTv services to our FTTH 
customers, where p2mp LSP's are used as pseudo-replication 
points in the network to distribute Multicast traffic toward 
interested Receiver PE routers.

As of now, the most mature NG-MVPN implementation is that 
from Juniper, even though p2mp LSP capabilities are well 
supported in IOS XR (and IOS, IOS XE, IIRC); our NG-MVPN 
network comprises a Cisco CRS box participating as a P-node 
in this, reliably and effectively replicating Multicast 
traffic alongside Juniper routers via p2mp LSP's. 

However, the Cisco solution (as of today) does not support 
the MVPN infrastructure that goes along with p2mp LSP's. As 
such, it's only useful in a P role, although Cisco are heavy 
on mLDP.

We're using NG-MVPN in a VRF, not the global table. It 
really is just a regular l3vpn VRF, but with more 
intelligence for the control plane (PIM, BGP) and data plane 
(MPLS).

We like NG-MVPN because:

	a) Removes the need to run PIM in the core.

	b) Removes the need to run Tunnel PIC's on
	   participating routers (an issue Juniper face
	   particularly on early router models, not so much
	   on more modern ones like the MX).

	c) Ability to provide FRR support for the p2mp
	   LSP's.

	d) Use of MPLS as a forwarding mechanism, without
   	   any extra special requirements.

	e) Quick and easy deployment in MPLS-enabled
	   networks that have no previous Multicast
	   support.


NG-MVPN is different from regular Multicast in that:

	1. Where you used PIM for the control plane, you now
	   use BGP.

	2. Where you used IP/GRE for the data plane, you now
	   use MPLS (with the help of RSVP).

Hope this helps.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20110919/0401628e/attachment-0001.pgp>


More information about the cisco-nsp mailing list