[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