OT:Draft Rosen vs BGP/MPLS MCAST VPN

From: Karim Jamali <karim.jamali_at_gmail.com>
Date: Fri, 4 Nov 2011 18:28:54 +0200

Hi All,

I have been going through the Draft Rosen vs MCAST VPN & I am trying to
collect the pieces together. I would appreciate any feedback on this.

*Draft Rosen:*
1) PIM is used as the multicast protocol & run between PE/CE and is
extended on a per VRF basis in what is called the C-PIM. By doing this, the
PEs on a per VRF/VPN basis are able to exchange the multicast routing
information (PIM Joins/Prunes) across the SP network. In addition to this,
a default MDT (Multicast Distribution Tree) will have to be allocated per
VPN at a minimum.
The negative sides about this is that every router in the SP side including
the P routers will need to maintain all the multicast routing states. The
use of the default MDT will mean that every PE will receive the traffic
regardless if a CE requested a PIM join or not which may mean wasted
bandwidth. One workaround would be to use data MDTs in which only the PEs
requiring the multicast stream will join, however this will mean additional
multicast states in the P network. So to sum up:
a)C-PIM is used between the PEs to extend the PIM domain for the customer
across the SP network.
b)P-PIM is a PIM instance that runs in the Provider network that is used to
encapsulate the multicast traffic/multicast control traffic and pass it
across the SP network.
c) All multicast control/traffic is encapsulated in GRE (where the source
is the PE connected to the CE having the source) and the destination is the
default MDT multicast address and which in turn encapsulates the original
customer multicast stream/join.

My question is that for default MDTs/Data MDTs everything has to be
configured manually on every PE & how does this really reflect the joins
coming from the customers & modify the PE-PE tunnels within the provider
network.

*MBGP/MPLS Multicast VPN*
The amount of BGP extensions in this is crazy. The way I understand this is
as follows:
a)PIM is still running between the CE/PE on a per VRF/VPN basis.
b)BGP has been extended in such a manner to convert the PIM Joins/Prunes by
adding the MCAST NLRI. The PIM Join message (C-S,C-G) is conveyed as a BGP
update (C-Multicast Route) sent to the other PE. What's interesting also is
that a new extended community has been added in such a way that the BGP
update is only sent to the PE which has the source. C-Multicast route
includes rd/route targets join (S,G).
c)The problem now is how to determine the PEs that will be part of the MDT.
I-PMSI Autodiscovery BGP Route are sent from all the PEs as part of the BGP
MCAST NLRI. This is similar to the default MDT in the Draft Rosen case. The
PE owning the source will also add the PSMI to the I-PMSI-A-D route which
contains a tunnel ID.
d)The same tunnel ID will be also be conveyed in the RSVP Path messages.
e) In PIM SSM, the sources are already known by a means outside PIM, when
PIM ASM Sparse mode is used, the RP is intro ducted and a BGP source active
message is also sent to the other PEs to let them know that a source exists.

The two questions that I have regarding this:
a)How does the PMSI Attribute help in specifying which VRF the traffic
belongs to when the tunnels are setup using LDP/RSVP.
Is the traffic labeled by any means with the tunnel ID..etc?
b)Regarding I-PMSI Autodiscovery BGP routes are these only sent by PEs who
have clients or from all PEs, and what is the method to make the I-PMSI-A-D
in close conjunction to the IGMP/PIM Joins by the CEs.

Apologies for the long post, I would truly appreciate your support on
understanding this more.

Thanks

-- 
KJ
Blogs and organic groups at http://www.ccie.net
Received on Fri Nov 04 2011 - 18:28:54 ART

This archive was generated by hypermail 2.2.0 : Thu Dec 01 2011 - 06:29:31 ART