There are two basic models for mVPN deployment: Classic mVPN and NG mVPN.
The Classic mVPN version (PIM/GRE) is based on the Draft Rosen and requires PIM in the Core of the provider network to be able to support mVPN traffic. This requirement introduces new protocols (PIM) and encapsulation mechanisms (mGRE) in the control and data planes. As we will discuss here, this model has a poor scalability and flexibility.
NG mVPN model (BGP/MPLS) uses the same protocols used in MPLS L3 VPN unicast service (RFC 2547, RFC 4364 BGP MPLS VPNs) but with some extensions to the control and data plane protocols as necessary to be able to support multicast traffic. This model retains the good scalability and flexibility of the unicast VPN service.
MPLS L3 VPN Multicast
MPLS L3 VPN Unicast and Multicast
Overlay, Signaling, Control Plane
Underlay, Transport, Data Plane, Multicast Distribution Trees (MDT)
PIM/GRE - mGRE tunneling
MDTs per VRF in Global RT
mLDP, P2MP TE, IR
Core tree types
Default MDT, Data MDT
Default MDT, Data MDT, Partitioned MDT
Classic mVPN (PIM/GRE)
Classic mVPN model is the original solution for transporting multicast data between customer sites over a SP multicast-enabled core. This model is based on the Virtual Router (VR) model, where each VR in the VPN domain is running an instance of a routing protocol in charge of exchanging VPN reachability information between VRs.
The Classic model uses different instances of a routing protocol (PIM) among PEs. One instance per mVPN. This means that we’ll end up with one different control plane per mVPN, and as a consequence, with a large number of routing peers and adjacencies per PE device.
PIM is a soft state protocol and it is timer-based by design. This means that if the number of mVPN grows, control plane traffic needed to maintain PIM adjacencies will grow with it, limiting the scalability of the overall solution.
In the underlay, this model uses PIM too. PIM in the underlay is needed to setup specific mVPN tunnels (mGRE) between PE devices (MDTs). These tunnels are logical tunnels that interconnect mVRF instances and can be used as a regular link. Customer routing protocol data is tunneled over them, resulting in coupling between the data and control planes.
NG mVPN (BGP/MPLS)
NG mVPN model defines an extension of the MPLS L3 VPN unicast model for multicast traffic. This model is based on the Aggregated Routing (AR) VPN model. In the aggregated routing model a backbone routing protocol is responsible for disseminating the VPN membership and reachability information for all the VPNs.
With NG mVPN model, one single instance of a routing protocol (BGP) carries mVPN routing information for all the mVPN, resulting in routing information aggregation in one common control plane. In this case, the routing protocol only needs one adjacency per pair of edge devices (PE devices in full-mesh) or one adjacency per Route Reflector (RR).
BGP is a hard-state protocol, meaning that it uses incremental updates when there is a change on the routing information and is not based on timers and periodic information refresh, helping to keep a quieter control plane.
The data plane setup supports different tunneling technologies and it’s not limited to PIM. mLDP, P2MP TE and IR can be used as encapsulation mechanisms maintaining the same control plane (BGP) and allowing for aggregation in the data plane.
The exchange of routing information is decoupled from the transport of mVPN data as the control plane protocol doesn’t use the data plane tunnels to perform the routing information exchange. There is not a dependency between planes as in the previous model.
The introduction of BGP as a control plane protocol in this model brings some solution advantages seen in the MPLS L3 VPN unicast case, like scalability, hierarchy and aggregation. There are as well some other capabilities specific to the multicast case that should be considered, like end-point Auto Discovery (AD) and Automatic Tunnel Binding (ATB) incorporated into the BGP multicast AF (mVPNv4 and mVPNv6).
The inter-AS integration is not easy for inter-AS options B and C when using the Classic model. In the control plane, this model needs direct exchange of control plane traffic (PIM) across PEs. IN PIM/GRE models the interconnection between PE devices NEED TO BE DIRECTLY CONNECTED (Emulated LAN).
In the data plane, all the SPs must support mGRE tunneling in the core and their PE peer each other directly. The PE devices need to look like directly connected even if they belong to different AS, and this is rarely a desirable situation.
NG model inter-AS integration is much more flexible, allowing for different tunneling technologies in different AS and segmented inter-as trees support. BGP/MPLS based routing can be able to consider inter-PE distance and take that into account into the mVPN route selection process (not possible with Emulated LAN).
In this case, PE devices don’t need to be directly connected to each other as in the PIM/GRE case.
This table summarizes the most relevant mVPN design topics by comparing side-by-side the Classical and NG model.
Virtual Router (VR) Model
Aggregated Routing (AR) Model
Control plane protocol
Routing protocol instances
1 per mVPN
1 BGP instance
Number of adjacencies
1 per PE per mVPN instance
1 per RR per PE
Routing information aggregation
Coupling between data and control planes
Soft State (Timer based)
Hard State (BGP Update based)
Suboptimal (emulated LAN)
Optimizable (BGP distances)
mLDP, P2MP TE, IR
Tunneling protocol flexibility
BGP tunnel auto discovery and binding
No, 1 MDT per mVPN (minimum)
Hierarchical control plane
High (due to lack of aggregation)
Low (due to PIM)
High (due to BGP)
Hard (new protocols)
Easy (extensions to existing protocols)
mVPN Additional References
These normative references could be useful for obtaining additional information of Classic and NG mVPN models.
- Network based IP VPN Architecture
- Draft Rosen
- NG mVPN solution
- Multicast BGP extensions
I hope you find it useful.