[j-nsp] P2MP LSP

Mark Tinka mtinka at globaltransit.net
Thu Jul 1 03:40:17 EDT 2010


On Thursday 01 July 2010 02:44:12 am David water wrote:

> So from your replies: it look like we have already
>  provisioned P2MP tunnel right?

When setting up the NG-MVPN infrastructure, you'd typically 
provision the p2mp LSP's prior to enabling the MVPN itself 
(I think you could also do it fron-to-back, but only if 
you're really bored, hehe).

>  Then in document they
>  talk about static lsp and dynamic LSP configuration then
>  what is it all about?

Alright, I see what you mean - my experience is only with 
static p2mp LSP's which, as you know, are manually 
provisioned.

Dynamic p2mp LSP's are based on a template with pre-defined 
constraints that allow for dynamic creation of p2mp LSP's 
after MVPN membership information has been exchanged using 
the MVPN Auto-discovery infrastructure.

Dynamic p2mp LSP's won't work until they are associated with 
an MPVN instance and membership information is received.

Dynamic p2mp LSP's allow you to aggregate constraints so you 
can use them for multiple MVPN's. This helps reduce on the 
amount of configuration operators need to perform.

In our case, since the p2mp LSP's are unidirectional, and 
implemented only on the Sender PE router, and only when we 
know a Receiver PE router has interested listeners behind 
it, adding an extra line for a new Receiver PE router 
(static) is trivial and doesn't hurt scalability.

> Now about PMSI attribute if tunnel is already built then
>  why do we need to communicate the PMSI information?
>  Still bit confused about the PMSI attribute usage.

Basically, the tunnel provides a data plane over which 
Multicast traffic will be forwarded. But for traffic to be 
forwarded down this tunnel, there must be control plane 
information that tells the router to use this tunnel as the 
interface through which the traffic is to be forwarded.

The PMSI BGP attribute is distributed along with the MVPN 
Auto-discovery NLRI, via BGP. This attribute is generally 
originated by the Sender PE router, as the Sender PE router 
typically sets up the P-tunnel.

The PMSI attribute contains important information about the 
P-tunnel, key among which are:

	- Tunnel Type
	- Tunnel Identifier

"Tunnel Type" determines the "Tunnel Identifier". The 
"Tunnel Type" is normally how the tunnel is signaled. There 
are 7 methods, but the key ones I find are:

	- RSVP-TE (p2mp LSP's)
	- mLDP (p2mp + mp2mp LSP's)
	- PIM-SM/SSM/Bidir tree(s)

If RSVP-TE is used to signal the LSP, MPLS is used to 
forward traffic. If it is PIM-SM, that becomes IP/GRE. In 
either case, BGP signals all this control plane information 
via the PMSI attribute.

This is the information the PMSI attribute is useful for, so 
that the right methods are used to forward data down the P-
tunnel.

I'd refer you to Section 5 of 'draft-ietf-l3vpn-2547bis-
mcast-bgp-08.txt' which contains some good detail.

Hope this helps.

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/20100701/ea790610/attachment.bin>


More information about the juniper-nsp mailing list