[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