Brkipm 3017

mVPN Deployment Models
BRKIPM-3017
IJsbrand Wijnands – Principal Engineer

Luc De Ghein - Technical Leader Services
Agenda
• Introduction
– mVPN Default MDT GRE Recap
• Building Blocks
• Deployment Models (Profiles)
– mVPN – GRE
– In-band signaling
– mVPN – mLDP
– Partitioned MDT
– mVPN over P2MP TE
– Ingress Replication
• mVPN Conclusion
BRKIPM-3017 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Before We Start
• P- is Provider
• C- is Customer
– E.g. C-(S,G) is an S,G of a customer, so likely in a VRF
• Only IPv4 mentioned
– All applies equally to IPv6
– Similar configuration, other address family
• Rosen renamed to “Default MDT”
Introduction
mVPN Default MDT GRE - Recap
PIM on the edge
Unicast routing in overlay across MPLS PIM join
Mcast signalling in overlay
Mcast through core – GRE encap IPv4 MDT For Default MDT Group
Configured on PE per VRF
PIM join
PIM join CE
Leaf PE Receiver
CE
Receiver Leaf PE
PIM join
CE
Leaf PE
PIM join Receiver
PIM join
CE
Receiver Leaf PE CE
Leaf PE Receiver
PIM PIM PIM
Default-MDT created in core using PIM BiDir

SSM
Sparse mode
PIM on the edge
Unicast routing in overlay across MPLS PIM hello/join
Mcast through core – GRE encap BGP vpnv4/6 ON Default MDT Group
1 Default MDT per VPN
PIM hello
PIM hello
CE
Leaf PE Receiver
CE
Receiver Leaf PE PIM hello
CE
Leaf PE
Receiver
PIM hello
PIM hello
CE
Receiver Leaf PE CE
Leaf PE Source
Per VRF: Default MDT vpnv4 or vpnv6 needed to have unicast plane
PIM hello’s and other PIM signalling
Unicast plane needed to make RPF succeed
Default-MDT emulates a virtual LAN
PIM on the edge
Unicast routing in overlay across MPLS PIM hello/join
Mcast through core – GRE encap BGP vpnv4/6 ON Default MDT Group
1 Default MDT per VPN
PIM join
PIM hello
PIM hello
CE
Leaf PE Receiver
CE
Receiver Leaf PE PIM hello
CE
Leaf PE
Receiver
PIM hello
PIM hello
CE
Receiver Leaf PE CE
Leaf PE Source
PIM join
Per VRF: Default MDT vpnv4 or vpnv6 needed to have unicast plane
PIM hello’s and other PIM signalling
Unicast plane needed to make RPF succeed
Default-MDT emulates a virtual LAN
PIM on the edge
Unicast routing in overlay across MPLS mcast data
Mcast through core – GRE encap
CE
Leaf PE
CE
Receiver Leaf PE
CE
Leaf PE
CE
Leaf PE CE
Leaf PE Source
Mcast traffic on Default MDT is received by all PE’s attached to that VPN
Even if that PE has no receiver in VRF for the (*,G) or (S,G)
PIM on the edge
forward data
CE
Leaf PE
CE
Receiver Leaf PE
drop data CE
Leaf PE
CE
Leaf PE CE
Leaf PE Source
Mcast traffic on Default MDT is received by all PE’s attached to that VPN
Even if that PE has no receiver in VRF for the (*,G) or (S,G)
PIM on the edge
CE
Leaf PE
CE
Receiver Leaf PE
CE
Leaf PE
CE
Receiver Leaf PE CE
Leaf PE Source
PIM on the edge
CE
Leaf PE
CE
Receiver Leaf PE
traffic rate
exceeds thresholdCE
Leaf PE
CE
Receiver Leaf PE CE
Leaf PE Source
Data MDT PIM message

Join TLV carries C-(S,G) & P-group
PIM on the edge
I have receiver:
I join
CE
Leaf PE
CE
Receiver Leaf PE
traffic rate
exceeds thresholdCE
Leaf PE
CE
Receiver Leaf PE CE
Leaf PE Source

PIM on the edge
I have receiver:
I join
CE
Leaf PE
CE
Receiver Leaf PE
I have receiver: traffic rate
I join exceeds thresholdCE
Leaf PE
CE
Receiver Leaf PE CE
Leaf PE Source

PIM on the edge
I have no receivers:
I have receiver: I ignore
I join
CE
Leaf PE
CE
Receiver Leaf PE
I have receiver: traffic rate
I join exceeds thresholdCE
Leaf PE
CE
Receiver Leaf PE CE
Leaf PE Source

PIM on the edge PIM join
Unicast routing in overlay across MPLS
Mcast signalling in overlay For Data MDT Group
Range of groups
CE mcast data
Leaf PE
CE
Receiver Leaf PE
CE
Leaf PE
CE
Receiver Leaf PE CE
Leaf PE Source
For high rate sources, data-MDT created

Removes traffic from default-MDT to offload PE’s that did not join stream
Range of groups
CE mcast data
Leaf PE
PIM Data-MDT Join TLV CE
Receiver Leaf PE
C-(S,G)
CE
P-Group Leaf PE
CE
Receiver Leaf PE CE
Leaf PE Source

Range of groups
PIM join CE mcast data

Leaf PE
Receiver Leaf PE
C-(S,G)
CE
P-Group Leaf PE
PIM join
CE
Receiver Leaf PE CE
Leaf PE Source

Range of groups

Leaf PE
Receiver Leaf PE
C-(S,G)
CE
P-Group Leaf PE
PIM join
CE
Receiver Leaf PE CE
Leaf PE Source

Range of groups

Leaf PE
Receiver Leaf PE
C-(S,G)
CE
P-Group Leaf PE
PIM join
CE
Receiver Leaf PE CE
Leaf PE Source

mVPN – The Old Style
PIM core plane

CE PE
PE CE
mVPN – The Old Style
PIM PIM in overlay PIM VPN plane
PIM core plane

CE PE
PE CE
Why Label Switched Multicast ?
• Past
– 1 solution
– mVPN based on GRE (Default MDT GRE)
• Now and Future

– NG mVPN
– LSM (Label Switched Multicast) in core
• Shared control plane with unicast
• Less protocols to manage in the core In other words = no PIM/IP
• Shared forwarding plane with unicast Multicast in the core
• Only MPLS as encapsulation
• Fast Restoration (FRR)
LSM Solution Space
Encapsulation/Forwarding IP/GRE LSM Unicast MPLS
LSM Solution Space
Core Tree Signaling PIM MLDP P2MP TE IR
LSM Solution Space
C-Multicast Signaling (PE-PE) PIM
LSM Solution Space
C-Multicast Signaling (PE-PE) PIM BGP
LSM Solution Space
C-Multicast Signaling (PE-PE) PIM BGP None
LSM Solution Space
IPv4 IPv6
Service Native Native
LSM Solution Space
IPv4 IPv6 IPv4 IPv6
Service Native Native mVPN mVPN
LSM Solution Space
IPv4 IPv6 IPv4 IPv6
Service Native Native mVPN mVPN VPLS
Building Blocks
Signaling in the Core
Protocols for Building Multicast LSPs
• Multipoint LDP (mLDP)
– Extensions to LDP
– Support both P2MP and MP2MP LSP
– RFC 6388
• RSVP-TE P2MP
– Extensions to unicast RSVP-TE
– RFC 4875
• Unicast MPLS + Ingress Replication (IR)

– Use unicast
– No additional signaling in core
New LSP Types
Point to Multipoint Multipoint to Multipoint
IP/MPLS IP/MPLS
PM2P LSP MP2MP LSP
 Replication of traffic in core

 Allows only the root of the P2MP LSP to inject  Replication of traffic in core
packets into the tree  Bidirectional
 Signaled with MLDP  All the leafs of the LSP can inject and receive
Path based on IP routing packets from the LSP
 Signaled with RSVP-TE  Signaled with multicast LDP (mLDP)
Constraint-based / explicit routing  Path based on IP routing
Admission control
New LSP Types
IP/MPLS IP/MPLS
PM2P LSP MP2MP LSP

Admission control
New LSP Types
IP/MPLS IP/MPLS
PM2P LSP MP2MP LSP

Admission control
New LSP Types
IP/MPLS IP/MPLS
PM2P LSP MP2MP LSP

Admission control
Core Tree Types
Multi-Directional Inclusive PMSI
MI-PMSI
aka Default MDT
All connected
One MP2MP tree or

Full mesh of P2MP trees
PMSI = Provider Multicast Service Interface
Core Tree Types
Multi-Directional Inclusive PMSI Selective PMSI
MI-PMSI S-PMSI
aka Default MDT aka Data MDT

Unidirectional – some
All connected
connected
One MP2MP tree or

One P2MP tree
Core Tree Types
Multi-Directional Inclusive PMSI Selective PMSI Multidirectional Selective PMSI
MI-PMSI S-PMSI MS-PMSI
aka Default MDT aka Data MDT aka Partitioned MDT

Unidirectional – some Uni- or Bidirectional – some
All connected
connected connected
One MP2MP tree or

One P2MP tree One P2MP or MP2MP tree
PIM
PIM Signaling in the Core
• IP Multicast routing in the core

• PIM in the core
• Used by Default MDT GRE model
mLDP
MLDP Overview
• LSPs are build from the leaf to the root
• Supports P2MP and MP2MP LSPs
– mLDP with MP2MP provides great scalability advantages for “any to any” topologies
• “any to any” communication applications:
– mVPN supporting Bidirectional PIM
– mVPN Default MDT model default MDT
– If a provider does not want tree state per ingress PE source
• Supports Fast Reroute (FRR) via RSVP TE unicast backup path

• No periodic signaling, reliable using TCP
• Control plane is P2MP or MP2MP
• Data plane is P2MP
• Scalable due to receiver driven tree building
• Supports MP2MP
• Does not support traffic engineering
LSP Types and Forwarding
P2MP tree packet replication and forwarding
P#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface 23
20 23 [ipv4 10.100.1.6 232.1.1.1] \ 20

0 Et1/0 10.1.1.1
18 [ipv4 10.100.1.6 232.1.1.1] \
0 Et3/0 10.1.3.3
18
MP2MP tree
P#show mpls forwarding-table 21
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface 19
23
19 21
19
[mdt 1000:2000 0]
[mdt 1000:2000 0]
912
\
33516
\
Et2/0
Et1/0
10.1.2.2
10.1.1.1
} 24
20
20 24 [mdt 1000:2000 0] \ 19
23
21
24
[mdt 1000:2000
[mdt 1000:2000
0]
0]
1932
1932
\
\
Et3/0
Et2/0
10.1.3.3
10.1.2.2 } MP2MP LSP is combination
19 [mdt 1000:2000 0]
33940
912
\
Et3/0
Et1/0
10.1.3.3
10.1.1.1
} of P2MP LSPs
P2MP TE
RSVP-TE Overview
• LSPs are build from the head-end to the tail-end
• Supports only P2MP LSPs
• Supports traffic engineering
– Bandwidth reservation
– Explicit routing
– Fast ReRoute
• Signaling is periodic
• P2P technology at control plane
– Inherits P2P scaling limitations
• P2MP at the data plane
– Packet replication in the core
RSVP-TE P2MP
Signalling
1. P2MP TE tunnels with explicit-path
2. P2MP TE tunnels with dynamic path Receiver
3. P2MP Auto-Tunnels Leaf CE
Receiver
CE
Leaf
Ingress
Source Router
(Root)
Receiver
Leaf CE
RSVP-TE P2MP
Signalling
Receiver
BGP Auto Discovery leaf updates
CE
or static configuration Leaf
Ingress
Source Router
(Root)
Receiver
Leaf CE
• The Leafs sends a BGP Auto Discovery message to notify the ingress PE
RSVP-TE P2MP
Signalling
Receiver
CE
Ingress
Source Router
(Root)
Path Receiver
Leaf CE
• The ingress sends RSVP-TE Path messages to the leaves
RSVP-TE P2MP
Signalling
Receiver
CE
Ingress
Source Router
(Root)
Path Receiver
Leaf CE
RSVP-TE P2MP
Signalling
Receiver
CE
Ingress
Source Router
(Root)
Resv Path Receiver
Leaf CE
• The leaves respond with RSVP-TE Resv messages
Comparisons Core Protocols
PIM mLDP P2MP TE
Mature / Well known Enhancement to existing protocol Enhancement to existing protocol
Soft state (periodic refresh) Hard state (no periodic updates) Soft state (periodic refresh)
Dynamic tree building Dynamic tree building Dynamic tree building
GRE enacpsulation MPLS encapsulation MPLS encapsulation
No Fast Restoration Fast Restoration (povided by MPLS TE) Fast Restoration
No bandwidth reservation No bandwidth reservation Bandwidth reservation

P2MP trees only P2MP and MP2MP trees P2MP trees only
Inter-as and CsC Inter-as and CsC Inter-as, but no CsC
High complexity Medium complexity High complexity
Medium core state Medium core state High core state
C- state present in core with Data MDT C- state present in core with Data MDT
All C- state in core with in-band signaling
Follows unicast routing Follows unicast routing Allows explicit or bandwidth contraint
routing
Suitable for all mcast applications Suitable for all mcast applications Mostly suitable for video delivery
Best for many-to-many Best for few-to-many
Customer Signalling
Protocols for Assigning Flows to LSPs
• Static
• PIM
– RFC 6513
• BGP Customer Multicast (C-Mcast)
– RFC 6514
– Also describes Auto-Discovery
• mLDP In-band signaling
– RFC 6826
Flow Mapping
• Overview
Flow Mapping
• Overview
PIM PIM
Source PE PE Receiver
S1,S2
MPLS cloud
PIM in Overlay
Flow Mapping
• Overview
PIM
PIM PIM
S1,S2
MPLS cloud
PIM in Overlay
Flow Mapping
• Overview
PIM
PIM PIM PIM PIM
Source PE PE Receiver Source PE PE Receiver

S1,S2
MPLS cloud S1,S2
MPLS cloud
PIM in Overlay BGP in Overlay
Flow Mapping
• Overview
PIM BGP
PIM PIM PIM PIM

S1,S2
MPLS cloud S1,S2
MPLS cloud
Flow Mapping
• Overview
PIM BGP
PIM PIM PIM PIM

S1,S2
MPLS cloud S1,S2
MPLS cloud
PIM PIM
S1,S2
MPLS cloud
Static
Flow Mapping
• Overview
PIM BGP
PIM PIM PIM PIM

S1,S2
MPLS cloud S1,S2
MPLS cloud
static map static map
PIM PIM
S1,S2
MPLS cloud
Static
Flow Mapping
• Overview
PIM BGP
PIM PIM PIM PIM

S1,S2
MPLS cloud S1,S2
MPLS cloud
static map static map
PIM PIM PIM PIM

S1,S2
MPLS cloud S1,S2
MPLS cloud
Static Inband
Flow Mapping
• Overview
PIM BGP
PIM PIM PIM PIM

S1,S2
MPLS cloud S1,S2
MPLS cloud
mLDP → PIM PIM → mLDP

static map static map translation translation
PIM PIM PIM PIM

S1,S2
MPLS cloud S1,S2
MPLS cloud
Static Inband
Flow Mapping
• Static
• Today mostly applicable to RSVP-TE P2MP

• Static configuration of multicast flows per LSP
• Allows aggregation of multiple flows in a single LSP
Flow Mapping
• PIM
• Dynamically assigning flows to an LSP by running PIM over the LSP

• Works over MP2MP and PPMP LSP types
• Mostly applicable (but not limited) to mVPN - Default MDT
• No changes to PIM in order to support this
• Allows aggregation of multiple flows in a single LSP
Flow Mapping
• Auto Discovery
• Auto Discovery (AD)

– The process of discovering all the PEs with members in a given mVPN
• Used to establish the MDT in the SP core
• Can also be used to discover set of PEs interested in a given C-group
(to enable S-PMSI creation)
– S-PMSI = Data MDT
• Used to advertise address of originating PE and tunnel attribute
information (i.e. which kind of tunnel)
BGP IPv4/IPv6 MVPN Address Family
• Specified in RFC 4271, using BGP Multiprotocol Extensions [RFC4760] with an AFI of 1 or 2
and an SAFI of MCAST-VPN
• Used for advertisement of AD routes
• Used for advertisement of C-mcast routes (*,G) and (S,G)
• Two new extended communities (used by vpnv4/6 prefixes, so SAFI 128):
– VRF route import (replacing connector attribute, i.e. storing route originator IP address/used to import
mcast routes, similart to RT for unicast routes)
– Source AS (advertise AS information: used for inter-AS mVPN)
• New BGP attributes

– PMSI Tunnel Attribute (PTA) (contains information about advertised tunnel)
– PPMP label attribute (upstream generated label used by the downstream clients to send unicast
messages towards the source)
• The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the

MCAST-VPN NLRI
• When AF IPv4 MVPN is not used: AD IPv4 MDT is still needed (Default MDT GRE profile)
A New Found Role for BGP
Auto-Discovery Multicast Signalling
Discoverying PE endpoints automatically Control plane replacing PIM

• Replacing manual configuration in case • Shared tree (*,G)
of MPLS TE • Source tree (S,G)
• Replacing some PIM signalling,
signalling Data MDT Joins, Prunes, Hellos
• New BGP address family

• PMSI Tunnel Attribute (PTA) information
• Describes the core tree (PIM, mLDP, MPLS TE, IR)
• Prefix (NLRI)
• Source, Group, Originator, Route Distinguisher
BGP Auto Discovery + C-Signalling
36
BRKIPM-3017 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public
Inside the BGP update
PMSI Tunnel Attribute (PTA)

Flags 0-6 – Reserved
(1 octet) 7 – L – Leaf information required
0 No tunnel information present
1 RSVP-TE P2MP LSP
2 mLDP P2MP LSP
3 PIM-SSM Tree
Tunnel type
4 PIM-SM Tree
(1 octet)
5 PIM-Bidir Tree
6 Ingress Replication
7 mLDP MP2MP LSP
8 Transport Tunnel
MPLS label (3
MPLS label
octects)
1 RSVP-TE P2MP LSP - <Extended Tunnel ID, Reserved, Tunnel ID, P2MP ID>
2 mLDP P2MP LSP - <P2MP FEC Element>
3 PIM-SSM Tree - <P- Root Node Address, P-Multicast Group>
Tunnel 4 PIM-SM Tree - <Sender Address, P-Multicast Group>

Identifier 5 PIM-Bidir Tree - <Sender Address, P-Multicast Group>
(variable)
6 Ingress replication - <unicast tunnel endpoint IP address of the local PE that is to be
this PE’s receiving endpoint address for the tunnel>
7 mLDP MP2MP LSP - <MP2MP FEC Element>
8 Transport Tunnel - <Source PE Address, Local Number>
36
PMSI Tunnel Attribute (PTA) mcast vpn NLRI

0 No tunnel information present 1 Intra-AS I-PMSI A-D route
1 RSVP-TE P2MP LSP 2 Inter-AS I-PMSI A-D route
2 mLDP P2MP LSP 3 S-PMSI A-D route
3 PIM-SSM Tree Route type (1 octet) 4 Leaf A-D route
Tunnel type 5 Source Active A-D route
4 PIM-SM Tree
(1 octet) 6 Shared Tree Join route
5 PIM-Bidir Tree
6 Ingress Replication 7 Source Tree Join route
7 mLDP MP2MP LSP Length in octets of the Route Type specific field of
8 Transport Tunnel Length (1 octet)
MCAST-VPN NLRI
MPLS label (3 One or more of the following:
MPLS label
octects)
RD (8 octets)
Route type specific MCAST source length (1 octet)
(variable length) MCAST source (variable)
Identifier MCAST group length (1 octet)
5 PIM-Bidir Tree - <Sender Address, P-Multicast Group>
(variable) MCAST group (variable)
this PE’s receiving endpoint address for the tunnel> Originating router’s IP address
36
PMSI Tunnel Attribute (PTA) mcast vpn NLRI

0 No tunnel information present 1 Intra-AS I-PMSI A-D route
1 RSVP-TE P2MP LSP 2 Inter-AS I-PMSI A-D route
2 mLDP P2MP LSP 3 S-PMSI A-D route AD type
3 PIM-SSM Tree Route type (1 octet) 4 Leaf A-D route
Tunnel type 5 Source Active A-D route
4 PIM-SM Tree
(1 octet) 6 Shared Tree Join route
5 PIM-Bidir Tree C type
6 Ingress Replication 7 Source Tree Join route
7 mLDP MP2MP LSP Length in octets of the Route Type specific field of
8 Transport Tunnel Length (1 octet)
MCAST-VPN NLRI
MPLS label (3 One or more of the following:
MPLS label
octects)
RD (8 octets)
Route type specific MCAST source length (1 octet)
(variable length) MCAST source (variable)
Identifier MCAST group length (1 octet)
5 PIM-Bidir Tree - <Sender Address, P-Multicast Group>
(variable) MCAST group (variable)
this PE’s receiving endpoint address for the tunnel> Originating router’s IP address
36
Flow Mapping – BGP Route Types
Route Type Name AD or C-mcast Usage
1 Intra-AS I-PMSI A-D AD Advertise member PE

route
AD type
2 Inter-AS I-PMSI A-D AD Same as type 1, but for inter-AS
route C type
3 S-PMSI A-D route AD Advertised by Source PE to signal Data/Partitioned MDT
4 Leaf A-D route AD Advertised by Receiver-PE as a response to type 3 route

with leaf info required flag set
5 Source Active A-D route AD Advertised by Source PE with active source to facilitate
SPT switchover
6 Shared Tree Join route C-mcast Advertise (*,G) by Receiver PE
7 Source Tree Join route C-mcast Advertise (S,G) by Receiver PE
Flow Mapping
BGP Customer-Multicast
• BGP Customer Multicast (C-Mcast) signalling on overlay

• Tail-end driven updates is not a natural fit to BGP
– BGP is good in one-2-many, not many-2-one
• In mVPN context, PIM is still the PE-CE multicast protocol
• Easy for SSM
• Complex to understand/troubleshoot for ASM
Flow Mapping
In-Band Signaling
• Only works with mLDP

• Multicast flow information encoded in the mLDP FEC
• Each customer mcast flow creates state on the core routers
– Scaling is the same as with Default MDT with every C-(S,G) on a Data MDT
• IPv4 and IPv6 multicast in global or VPN context
• Typical for SSM or PIM Sparse mode sources
• IPTV walled-garden deployment
• RFC 6826 – mLDP In-Band Signaling for P2MP and MP2MP LSPs
Comparisons – Customer Signaling Protocols
PIM BGP
Older protocol, proven, well known New enhancement to existing protocol
No changes needed New procedures (troubleshooting!)

Complex with ASM, but well known Complex for ASM
Soft state (periodic refresh) Hard state (no periodic updates)
Info driven to specific PE router Info driven to all PE routers
PIM adjacencies to all PE routers BGP adjacencies to all PE routers

but likely only to RRs
Medium scalability Very high scalability
BGP Signalling
Build Default MDT config
MPLS cloud
driven Receiver
Source CE PE PE CE
BGP Signalling
I-PMSI (type 1) I-PMSI (type 1)

MPLS cloud
driven Receiver
Source CE PE PE CE
BGP Signalling

MPLS cloud
driven Receiver
Source CE PE PE CE
PIM
Relay PIM Join
driven MPLS cloud
Receiver
RP CE RP-PE PE CE
BGP Signalling

MPLS cloud
driven Receiver
Source CE PE PE CE
Share Tree Join (type 6) PIM (*,G) Join
PIM
Relay PIM Join
driven MPLS cloud
Receiver
RP CE RP-PE PE CE
BGP Signalling

MPLS cloud
driven Receiver
Source CE PE PE CE
PIM
Relay PIM Join
driven MPLS cloud
Receiver
RP CE RP-PE PE CE
PIM
Relay PIM Join
driven MPLS cloud
Receiver
Source CE PE PE CE
BGP Signalling

MPLS cloud
driven Receiver
Source CE PE PE CE
PIM
Relay PIM Join
driven MPLS cloud
Receiver
RP CE RP-PE PE CE
Source Tree Join (type 7) PIM (S,G) Join
PIM
Relay PIM Join
driven MPLS cloud
Receiver
Source CE PE PE CE
BGP Signalling

MPLS cloud
driven Receiver
Source CE PE PE CE
PIM
Relay PIM Join
driven MPLS cloud
Receiver
RP CE RP-PE PE CE
PIM
Relay PIM Join
driven MPLS cloud
Receiver
Source CE PE PE CE
data
Build Data MDT
driven MPLS cloud
Receiver
Source CE PE PE CE
BGP Signalling

MPLS cloud
driven Receiver
Source CE PE PE CE
PIM
Relay PIM Join
driven MPLS cloud
Receiver
RP CE RP-PE PE CE
PIM
Relay PIM Join
driven MPLS cloud
Receiver
Source CE PE PE CE
Data MDT
threshold crossed S-PMSI (type 3)
data
Build Data MDT
driven MPLS cloud
Receiver
Source CE PE PE CE
Configuration – BGP-AD & C-mcast Signalling
IOS IOS-XR
vrf definition one router pim
rd 1:3 vrf one
route-target export 1:1 address-family ipv4

Switch to BGP as C-mcast
route-target import 1:1 signalling protocol rpf topology route-policy rpf-for-one
! mdt c-multicast-routing bgp
address-family ipv4 Specify PIM or BGP migration route-policy pim-to-BGP
mdt overlay use-bgp announce-pim-join-tlv
mdt auto-discovery mldp pim-tlv-announce
exit-address-family BGP AD multicast-routing
address-family ipv4
Specify to use PIM “Data MDT Join bgp auto-discovery mldp | pim | ir | p2mp-te
TLV” in dual PIM/BGP network
BGP AD
BGP Signalling
config Partitioned
Type 3
driven MDT MPLS cloud
Receiver
Source CE PE PE CE
BGP Signalling
LSP Identifier is [*,*]
PEs routers indicate they are willing to
participate in the MS-PMSI (Partitioned MDT)
MS-PMSI (type 3) MS-PMSI (type 3)

[*,*] [*,*]
config Partitioned
Type 3
Receiver
Source CE PE PE CE
BGP Signalling

[*,*] [*,*]
config Partitioned
Type 3
Receiver
Source CE PE PE CE
PIM Partitioned
Type 3
Receiver
Source CE PE PE CE
P2MP TE
Auto-Tunnels
BGP Signalling

[*,*] [*,*]
config Partitioned
Type 3
Receiver
Source CE PE PE CE
Source Tree Join (type 7) PIM (S,G) Join 1
PIM Partitioned
Type 3
Receiver
Source CE PE PE CE
P2MP TE
Auto-Tunnels
BGP Signalling

[*,*] [*,*]
config Partitioned
Type 3
Receiver
Source CE PE PE CE
Source Tree Join (type 7) PIM (S,G) Join 1

type 4 [*,*]
2
PIM Partitioned
Type 3
Receiver
Source CE PE PE CE
P2MP TE
Auto-Tunnels LSP Identifier is [*,*]
PE indicates it is egress PE
Head end needs to signal P2MP TE to egress PE
BGP Signalling for Sparse mode
RP
CE
PE3
PE1 PE2
Receiver Source
(S1, G) (S1, G)
RP
CE
PE3
1
PIM (*,G) Join
PE1 PE2
Receiver Source
(S1, G) (S1, G)
RP
CE
PE3
1
PIM (*,G) Join
PE1 PE2
Receiver Source
(S1, G) (S1, G)
RP
PIM (*,G) Join

CE
3
PE3
1
PIM (*,G) Join
PE1 PE2
Receiver Source
(S1, G) (S1, G)
RP 4
Registering
PIM (*,G) Join

CE
3
PE3
1
PIM (*,G) Join
PE1 PE2
Receiver Source
(S1, G) (S1, G)
RP 4
PIM (S,G) Join

Registering
PIM (*,G) Join

CE
3 5
PE3
1
PIM (*,G) Join
PE1 PE2
Receiver Source
(S1, G) (S1, G)
RP 4
PIM (S,G) Join

Registering
PIM (*,G) Join

CE
3 5
PE3
6
1
PIM (*,G) Join
PE1 PE2
Receiver Source
(S1, G) (S1, G)
RP 4
PIM (S,G) Join

Registering
PIM (*,G) Join

CE
3 5
PE3
6
1 7
PIM (*,G) Join PIM (S,G) Join
PE1 PE2
Receiver Source
(S1, G) (S1, G)
RP 4
PIM (S,G) Join

Registering
PIM (*,G) Join

CE
3 5
PE3
6
1 7
PE1 PE2
Receiver Source
(S1, G) (S,G) Traffic (S1, G)
RP 4
PIM (S,G) Join

Registering
PIM (*,G) Join

CE
3 5
PE3
6
1 7
9
PE1 Source Active A-D route (type 5) PE2
Receiver Source
RP 4
PIM (S,G) Join

Registering
PIM (*,G) Join

CE
3 5
PE3
6
1 7
9
PE1 Source Active A-D route (type 5) PE2
Receiver Source
10 creates (S,G) and uses
RPF peer PE2 8
BGP Signalling - Routes For Your
Reference
DRP/0/3/CPU1:Router#show bgp ipv4 mvpn vrf one
Route Distinguisher: 1:2 (default for vrf one
*>i[1][10.1.100.1]/40 10.1.100.1 100 0 i Intra-AS I-PMSI AD Route

*>i [3][1:1][*][*][10.100.1.1]/14
10.100.1.1 0 100 0 ?
Partitioned MDT
*>i[4][3][1:2][32][10.2.2.9][32][225.1.1.1][10.1.100.2][10.1.100.5]/224
Data MDT advertised by Source PE
10.1.100.5 100 0 i
*>i[4][3][1:2][32][10.2.100.9][32][225.1.1.1][10.1.100.2][10.1.100.1]/224
10.1.100.1 100 0 i
Leaf AD Route
*>i[5][32][10.2.2.9][32][225.1.1.1]/88
10.1.100.2 100 0 i Source Active Route
*>i[6][1:5][1][32][10.2.100.12][32][225.1.1.1]/184
10.1.100.1 100 0 i (*,G) Join Route
*>i[7][1:2][1][32][10.2.2.9][32][232.1.1.1]/184
10.1.100.1 100 0 i
(S,G) Join Route
R-PE or Source-PE
BGP Signalling - Routes For Your
Reference
DRP/0/3/CPU1:Router#show bgp ipv4 mvpn vrf one
Route Distinguisher: 1:2 (default for vrf one
*>i[1][10.1.100.1]/40 10.1.100.1 100 0 i Intra-AS I-PMSI AD Route

*>i [3][1:1][*][*][10.100.1.1]/14
10.100.1.1 0 100 0 ?
Partitioned MDT
*>i[4][3][1:2][32][10.2.2.9][32][225.1.1.1][10.1.100.2][10.1.100.5]/224
Data MDT advertised by Source PE
10.1.100.5 100 0 i
*>i[4][3][1:2][32][10.2.100.9][32][225.1.1.1][10.1.100.2][10.1.100.1]/224
10.1.100.1 100 0 i
Leaf AD Route
*>i[5][32][10.2.2.9][32][225.1.1.1]/88
10.1.100.2 100 0 i Source Active Route
*>i[6][1:5][1][32][10.2.100.12][32][225.1.1.1]/184
10.1.100.1 100 0 i (*,G) Join Route
*>i[7][1:2][1][32][10.2.2.9][32][232.1.1.1]/184
10.1.100.1 100 0 i
(S,G) Join Route
R-PE or Source-PE
BGP AD - Example
DRP/0/3/CPU0:Router#show bgp ipv4 mvpn vrf one [1][10.1.100.1]/40
BGP routing table entry for [1][10.1.100.1]/40, Route Distinguisher: 1:2
Paths: (1 available, best #1, not advertised to EBGP peer)
Not advertised to any peer
Path #1: Received by speaker 0
Local
10.1.100.1 (metric 30) from 10.1.100.7 (21.21.21.21)
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 624
Community: no-export
Extended community: RT:1:1
Originator: 21.21.21.21, Cluster list: 10.1.100.7
PMSI: flags 0x00, type 1, label 0, ID 0x000003e8000003e80a016401
Source VRF: default, Source Route Distinguisher: 1:1
BGP AD - Example
BGP routing table entry for [1][10.1.100.1]/40, Route Distinguisher: 1:2 NLRI
Local
10.1.100.1 (metric 30) from 10.1.100.7 (21.21.21.21)
BGP AD - Example
originator IP address
Not advertised to any peer type = 1: Intra-AS I-PMSI A-D route
Local
10.1.100.1 (metric 30) from 10.1.100.7 (21.21.21.21)
BGP AD - Example
Local
10.1.100.1 (metric 30) from 10.1.100.7 (21.21.21.21)
PTA
BGP AD - Example
Local
10.1.100.1 (metric 30) from 10.1.100.7 (21.21.21.21)
PTA
type = 1
P2MP TE Tunnel
BGP AD - Example
Local
10.1.100.1 (metric 30) from 10.1.100.7 (21.21.21.21)
PTA
type = 1 BGP does not need to

advertise MPLS label for TE
P2MP TE Tunnel
BGP AD - Example
Local
10.1.100.1 (metric 30) from 10.1.100.7 (21.21.21.21)
PTA
0x000003e8 : tunnel-id 1000

type = 1 BGP does not need to Tunnel 0x000003e8 : p2mp ID 1000
advertise MPLS label for TE Identifier 0x0a016401 : Extended Tunnel ID 10.1.100.1
P2MP TE Tunnel
BGP C-Signalling
• On Default MDTmodels with C-PIM signalling, data traffic needs to be
monitored
– On Default/Data tree to detect duplicate forwarders over MDT and trigger the assert
process
– On Default MDT to perform SPT switchover (switchover from (*,G) to (S,G))
• On Default MDT models with C-BGP signalling

– There is only one forwarder on MDT
• There are no asserts
– The BGP Type 5 routes are used for SPT switchover on PEs
Type 4 Leaf AD Routes
• Used to track type 3 S-PMSI (Data MDT) routes
• Needed when RR is deployed
• If the Source PE sets the Leaf-Info-required flag on type 3 routes, the Receiver PE
responds with a type 4 route
Migration
Core migration: core-trees co-existence
PIM core tree
Migration
Flexible policy to do core tree selection
• Per multicast Group
PIM core tree • Per multicast Source
• Per Source ingress router
• ...
Migration
• ...
mLDP core tree
Migration
• ...
I can chose
either one
mLDP core tree
Migration
• ...
I can chose
either one
mLDP core tree
Overlay signalling migration: PIM to BGP Flexible policy to do migration from PIM
to BGP overlay signalling

• Per multicast Source
• ...
Migration
• ...
I can chose
either one
mLDP core tree

PIM • Per Source ingress router
• ...
Migration
• ...
I can chose
either one
mLDP core tree

PIM • Per Source ingress router
BGP
• ...
Migrating Core Tree
Core tree selection can be based on C-S, C-G, Source PE
route-policy rpf-for-one
if destination in (225.1.1.0/24) then

If C-Group is 10.2.2.10 then use Default MDT GRE
set core-tree pim-default
endif
if source in (10.2.2.10) then
set core-tree mldp-partitioned-p2mp If C-Source is 10.2.2.10 then use Partitioned mLDP

endif
if next-hop in (10.1.100.9) then

If Source-PE is 10.1.100.9 then use mLDP Inband
set core-tree mldp-inband
endif
if next-hop in (10.1.100.11/32) then

If Source-PE is 10.1.100.11 then use Default MDT mLDP
set core-tree mldp-default
endif
end-policy
Migration PIM to BGP for C-mcast Signalling
router pim
vrf one
address-family ipv4
rpf topology route-policy rpf-for-one
mdt c-multicast-routing pim
migration route-policy pim-to-BGP Migration route policy for C-mcast signalling

!
interface GigabitEthernet0/1/0/0
enable
route-policy pim-to-BGP
if destination in (10.1.100.2/32) then

If source-PE is 10.1.100.2 then use BGP
set c-multicast-routing bgp
else use PIM for C-mcast signalling
endif
pass
end-policy
Flow Mapping
Summary
• Static
– Mostly applicable to RSVP-TE
• PIM
– Well known, used since the introduction of mVPN over GRE in 2000
• BGP A-D
– Useful where head-end assigns the flows to the LSP
• BGP C-mcast
– Alternative to PIM in mVPN context
– Might be required in dual vendor networks
• mLDP In-band signalling
– Method to stitch a PIM tree to a mLDP LSP without any additional signaling
Deployment Models
Models
Models
overlay signaling
core protocol core tree
protocol
Models
overlay signaling
core protocol core tree
protocol
• Default MDT (Rosen)

• Inband Signalling
• Static Mapping – P2MP TE
• Partitioned MDT
Configuration
• All unicast must be up and running
• IPv4 MDT is needed for Default MDT GRE model
• Enable multicast-routing/PIM on the edge
– Global or VRF interface to CE
• Enable mLDP/P2MP TE on core
• IOS
mLDP enabled by default, if MPLS LDP is enabled
• IOS-XR
mpls ldp
mldp
• Specify the mVPN model

mVPN Model - Configuration – IOS-XR
multicast-routing Specify the mVPN model
vrf one
address-family ipv4
mdt mldp in-band-signaling ipv4
mdt partitioned mldp ipv4 p2mp (bidir)
mdt partitioned mldp ipv4 mp2mp (bidir)
mdt partitioned ingress-replication
mdt mldp in-band-signaling ipv4
mdt default mldp ipv4 <root> MP2MP core-tree with IPv4 Root address
mdt default mldp p2mp (partitioned)(bidir) P2MP core-tree
mdt default ingress-replication
mdt default <ipv4-group>
mdt default (ipv4) <ipv4-group> partitioned
mdt data <ipv4-group/length>
mdt data <max nr of data groups> (threshold)
mdt static p2mp-te tunnel-te <0-65535>
mdt static tunnel-mte <0-65535>
mVPN Model - Configuration IOS-XR
Specify RPF to core-tree
router pim
vrf one
address-family ipv4
rpf topology route-policy rpf-for-one
interface GigabitEthernet0/0/0/9
RP/0/RP1/CPU0:Router(config-rpl)#set core-tree ?
ingress-replication-default Ingress Replication Default MDT core
ingress-replication-partitioned Ingress Replication Partitioned MDT core
mldp-default MLDP Default MDT core
mldp-inband MLDP Inband core
mldp-partitioned-mp2mp MLDP Partitioned MP2MP MDT core
mldp-partitioned-p2mp MLDP Partitioned P2MP MDT core
p2mp-te-default P2MP TE Default MDT core
pim-default PIM Default MDT core
mVPN Model - Configuration IOS
vrf definition one
rd 1:3
vpn id 1:1 vpn id needs to be configured

for Default MDT
route-target export 1:1
route-target import 1:1
!
address-family ipv4
mdt default 232.100.1.1
Default and Data IPv4 groups for this VRF in
global context for Default MDT GRE
mdt data 232.100.100.0 0.0.0.255
mdt partitioned mldp p2mp Partitioned P2MP
mdt default mpls mldp 10.1.100.7 Root address of mLDP MP2MP tree
mdt default mpls mldp p2mp Default MDT over full mesh P2MP mLDP
mdt data mpls mldp 100 Data MDTs for mLDP
!
enables mLDP inband signalling for the VRF
ip multicast vrf one mpls mldp
ip pim vrf one mpls source Loopback0
Default MDT GRE
Default MDT mVPN over GRE – Default MDT
Default MDT
PIM join
PIM join
CE Receiver
Leaf PE
Receiver CE
Leaf PE
CE
Leaf PE Receiver
CE
Receiver Leaf PE CE Receiver
Leaf PE
• Default-MDT created in core using single IPv4 mcast group

• PIM used for Customer route signaling over default-MDT
• Default-MDT emulates a virtual LAN
Default MDT mVPN over GRE – Data MDT
CE Receiver
Leaf PE
Source CE Leaf PE
CE
Leaf PE Receiver
CE Leaf PE CE
Leaf PE
 For high rate sources data-MDT created using P2MP LSPs

 Removes traffic from default-MDT to offload PE’s that did not join stream
 Creation of data-MDT is signalled dynamically using MDT Join messages or BGP A-D routes
 Only PEs with receivers join Data MDT
traffic rate
exceeds threshold
CE Receiver
Leaf PE
Source CE Leaf PE
CE
Leaf PE Receiver
CE Leaf PE CE
Leaf PE

PIM Data-MDT Join TLV
traffic rate C-(S,G)
exceeds threshold P-group
CE Receiver
Leaf PE
Source CE Leaf PE
CE
Leaf PE Receiver
CE Leaf PE CE
Leaf PE

traffic rate C-(S,G)
exceeds threshold P-group
Data-MDT
CE Receiver
Leaf PE
Source CE Leaf PE
CE
Leaf PE Receiver
CE Leaf PE CE
Leaf PE

In-band Signaling VPN Context
RD
RD CE Receiver
R-PE
Source CE Root-PE
S1,S2
RD
RD CE Receiver
CE Root-PE
R-PE RD
Source MPLS cloud
S1 CE Receiver
• PIM (S,G) VPN tree is mapped to a mLDP P2MP LSP

• Root PE is learned via BGP Next-Hop of the VPNv4 Source address route
• R-PE may use SSM Mapping if Receiver is not SSM aware
• RD of the source VRF is included in the mLDP FEC to allow overlapping (S,G) addresses
PIM (S1,G)
RD
RD CE Receiver
R-PE
Source CE Root-PE
S1,S2
RD
RD CE Receiver
CE Root-PE
R-PE RD
Source MPLS cloud
S1 CE Receiver

PIM (S1,G)
P2MP LSP FEC {RD,S1,G}
P2MP LSP FEC {RD,S1,G} RD
RD CE Receiver
R-PE
Source CE Root-PE
S1,S2
RD
RD CE Receiver
CE Root-PE
R-PE RD
Source MPLS cloud
S1 CE Receiver

PIM (S1,G)
PIM (S1,G)
PIM (S2,G)
RD CE Receiver
R-PE
Source CE Root-PE
S1,S2
RD
RD CE Receiver
CE Root-PE
R-PE RD
Source MPLS cloud
S1 CE Receiver

PIM (S1,G)
PIM (S1,G)
PIM (S2,G)
RD CE Receiver
R-PE
Source CE Root-PE
S1,S2
RD
RD CE Receiver
CE Root-PE
R-PE RD
Source MPLS cloud
S1 PIM (S1,G)
CE Receiver

PIM (S1,G)
PIM (S1,G)
PIM (S2,G)
RD CE Receiver
R-PE
Source CE Root-PE
S1,S2
RD
RD CE Receiver
CE Root-PE
R-PE RD
Source MPLS cloud
S1 PIM (S1,G)
CE Receiver

PIM (S1,G)
PIM (S2,G)
PIM (S1,G) P2MP LSP FEC {RD,S1,G}
RD CE Receiver
R-PE
Source CE Root-PE
S1,S2
RD
RD CE Receiver
CE Root-PE
R-PE RD
Source MPLS cloud
S1 PIM (S1,G)
CE Receiver

PIM (S1,G)
P2MP LSP FEC {RD,S1,G} PIM (S2,G)
PIM (S2,G)
RD CE Receiver
R-PE
Source CE Root-PE
S1,S2
PIM (S1,G)
PIM (S1,G)
RD
RD CE Receiver
CE Root-PE
R-PE RD
Source MPLS cloud
S1 PIM (S1,G)
CE Receiver

in-band signalling
In-band Signaling VPN Context model also exists in
PIM (S1,G)
PIM (S2,G)
global context
PIM (S2,G)
RD CE Receiver
R-PE
Source CE Root-PE
S1,S2
PIM (S1,G)
PIM (S1,G)
RD
RD CE Receiver
CE Root-PE
R-PE RD
Source MPLS cloud
S1 PIM (S1,G)
CE Receiver

• Multicast flow information encoded in the mLDP FEC
• No aggregation possible
– You cannot map multiple multicast flows onto one LSP
• Scalability
– Is like Default MDT, where every (S,G) is on a Data MDT
Default MDT Model mVPN over mLDP
Default MDT mVPN over mLDP – Default MDT
Default MDT
PIM join
PIM join
CE Receiver
Leaf PE
CE
Receiver Leaf PE
CE
Leaf PE Receiver
CE
Receiver Leaf PE CE
Leaf PE Receiver
• Default-MDT created in core using single MP2MP LSP

– By configuration
– Any core router is specified as root
• PIM or BGP used for Customer route signalling over default-MDT

• Default-MDT emulates a virtual LAN
Default MDT mVPN over mLDP – Data MDT
CE Receiver
Leaf PE
Source CE Leaf PE
CE
Leaf PE Receiver
CE Leaf PE CE
Leaf PE
• For high rate sources data-MDT created using P2MP LSPs

• Removes traffic from default-MDT to offload PE’s that did not join stream
• Creation of data-MDT is signaled dynamically using MDT Join messages or BGP A-D routes
traffic rate
exceeds threshold
CE Receiver
Leaf PE
Source CE Leaf PE
CE
Leaf PE Receiver
CE Leaf PE CE
Leaf PE

C-(S,G)
FEC Element
traffic rate
exceeds threshold
CE Receiver
Leaf PE
Source CE Leaf PE
CE
Leaf PE Receiver
CE Leaf PE CE
Leaf PE

C-(S,G)
FEC Element
traffic rate
exceeds threshold
Data-MDT
CE Receiver
Leaf PE
Source CE Leaf PE
CE
Leaf PE Receiver
CE Leaf PE CE
Leaf PE

C-(S,G)
FEC Element
traffic rate FEC element
exceeds threshold
Data-MDT root
vpn-id
CE Receiver
Leaf PE PMSI ID
Source CE Leaf PE
CE
Leaf PE Receiver
CE Leaf PE CE
Leaf PE

Default MDT mVPN over mLDP
• Known from Default MDT GRE
– same principles/architecture
• Default MDT = one MP2MP LSP (opaque type MDT), created as soon as the root is
configured on the leaf(s)
• Data MDT is P2MP LSP (opaque type MDT), signaled by PIM by ingress PE upon
reaching threshold rate
• No need to configure IPv4 multicast in core

• Avoiding cumbersome design/management/provisioning of IPv4 multicast
Groups for Default MDT or IPv4 Group ranges for Data MDTs per customer
VRF/PE
• PIM or BGP signaling in overlay
Default MDT mVPN over mLDP – BGP AD
• No need for BGP AD to autodiscover the PEs
– Root is known by configuration
• BGP AD signaling can be used instead of PIM Join TLV signaling

– When Data MDT threshold is crossed
– AF IPv4 mvpn is used to advertise (C-S, C-G) to S-PMSI tunnel binding
IOS IOS-XR
vrf definition one multicast-routing
address-family ipv4 vrf one
mdt auto-discovery mldp pim-tlv-announce address-family ipv4
mdt default mpls mldp 10.1.100.7 bgp auto-discovery mldp
mdt data mpls mldp 100
router bgp 1
router bgp 1 address-family ipv4 mvpn
address-family ipv4 mvpn vrf one
neighbor 10.1.100.7 activate address-family ipv4 mvpn
neighbor 10.1.100.7 send-community extended
Default MDT mVPN over mLDP - Data MDT BGP AD
CE
Leaf PE Receiver
Source CE Leaf PE
CE
Leaf PE
Receiver
CE Leaf PE CE
Leaf PE
traffic rate
exceeds threshold
CE
Leaf PE Receiver
Source CE Leaf PE
CE
Leaf PE
Receiver
CE Leaf PE CE
Leaf PE
BGP IPv4 mvpn update
PMSI type
FEC Element
FEC type
adress family
Root
vpn-id
traffic rate PMSI ID
exceeds threshold
Data-MDT
CE
Leaf PE Receiver
Source CE Leaf PE
CE
Leaf PE
Receiver
CE Leaf PE CE
Leaf PE
Default MDT Co-Existence/Migration
• Default MDT GRE and Default MDT mLDP can co-exist, even in one VRF
– GRE is preferred if both are present
• Migration is possible from Default MDT GRE to Default MDT mLDP
mGRE
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
Receiver
(S1, G)
CE (S2, G)
Source PE2
CE
(S2,G) PE4

• Steps
mGRE
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
Receiver
(S1, G)
CE (S2, G)
Source PE2
CE
(S2,G) PE4

• Steps
1. Enable mLDP in core
mGRE
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
Receiver
(S1, G)
CE (S2, G)
Source PE2
CE
(S2,G) PE4

• Steps
2. Migrate per PE, per VRF at a time
• Preference command/RPL to prefer mLDP over GRE
mGRE
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
Receiver
(S1, G)
CE (S2, G)
Source PE2
CE
(S2,G) PE4

• Steps
mGRE mLDP
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
Receiver
(S1, G)
CE (S2, G)
Source PE2
CE
(S2,G) PE4

• Steps
mdt preference mldp
mGRE mLDP
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
Receiver
(S1, G)
CE (S2, G)
Source PE2
CE
(S2,G) PE4

• Steps
mdt preference mldp
mGRE mLDP
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
Receiver
(S1, G)
CE (S2, G)
Source PE2
CE
(S2,G) PE4

• Steps
mdt preference mldp
mGRE mLDP
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G) mdt preference mldp
Receiver
(S1, G)
CE (S2, G)
Source PE2
CE
(S2,G) PE4

• Steps
3. Remove Default MDT GRE when all VRFs/PEs are in Default MDT mLDP mdt preference mldp
mLDP
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G) mdt preference mldp
Receiver
(S1, G)
CE (S2, G)
Source PE2
CE
(S2,G) PE4
IOS IOS-XR
vrf definition one route-policy rpf-for-one

rd 1:3 RPF topology mLDP used set core-tree mldp-default
vpn id 1:1
route-target export 1:1 multicast-routing
route-target import 1:1 vrf one
! address-family ipv4
address-family ipv4 mdt source Loopback0
mdt preference mldp Prefer mldp over GRE mdt data 232.100.100.0/24
mdt default mpls mldp 10.1.100.7 mdt default ipv4 232.100.1.1
mdt data mpls mldp 100 mdt default mldp ipv4 10.1.100.7
mdt default 232.100.1.1 mdt data 100
mdt data 232.100.100.0 0.0.0.255 interface all enable
Both Default MDT mLDP and Default MDT GRE configured

(and signaled)
Default MDT mVPN over mLDP
Summary
• Default-MDT created using MP2MP LSP

• Functionality as you know, but instead of GRE, MPLS encapsulation and mLDP
replaces PIM/multicast in core
• MP2MP is more scalable than PIM SM/SSM since no per PE state created in
provider core
• BGP A-D support for Data-MDTs
Default MDT Model mVPN over mLDP – Full
Mesh P2MP
Default MDT mVPN over mLDP – Default MDT is
Full Mesh P2MP
CE
Leaf PE Receiver
CE
Leaf PE
Receiver
CE
Leaf PE
Receiver
CE
Receiver Leaf PE CE
Leaf PE Receiver
• Default-MDT created in core using full mesh of P2MP LSPs

• Each PE is root of one P2MP mLDP LSP
• BGP AD must be enabled!
• Might be used when interoperating
• P2MP might be easier understood than MP2MP
Full Mesh P2MP
CE
Leaf PE Receiver
CE
Leaf PE
Receiver
CE
Leaf PE
Receiver
CE
Receiver Leaf PE CE
Leaf PE Receiver

Full Mesh P2MP
CE
Leaf PE Receiver
CE
Leaf PE
Receiver
CE
Leaf PE
Receiver
CE
Receiver Leaf PE CE
Leaf PE Receiver

Full Mesh P2MP
CE
Leaf PE Receiver
CE
Leaf PE
Receiver
CE
Leaf PE
Receiver
CE
Receiver Leaf PE CE
Leaf PE Receiver

Full Mesh P2MP
Default MDT
CE
Leaf PE Receiver
CE
Leaf PE
Receiver
CE
Leaf PE
Receiver
CE
Receiver Leaf PE CE
Leaf PE Receiver

Partitioned MDT mVPN over mLDP
Introduction
• Dynamic version of Default MDT model
• Key difference
– MDT built only when customer traffic needs to be transported across core
• Address issues in Default MDT model
– Optimizes deployments where customer sources are mostly co-located in few sites
– Supports Anycast sources
– With Default MDT -> Default MDT-> Asserts
– Default MDT is MP2MP or P2MP
– Data MDT is always P2MP
– Reduces the number of PIM neighbors
– PIM neighborship is unidirectional: egress PE sees ingress PEs as PIM neighbors
Auto Discovery of Candidate PE’s
Receiver
(S1, G)
CE
PE 3
Source CE PE 1
(S1,G)
Receiver
CE (S2, G)
BGP RR PE 4
Receiver
(S1, G)
CE PE 2 (S2, G)
Source CE
PE 5
(S2,G)
• Initially there is no (default) MDT

• Candidate PE’s advertise their LSP identifier as [*,*] wildcard S-PMSI via BGP AD, we
call this the MS-PMSI
• In this example PE1 and PE2 are candidates
• Note, using BGP AD MVPN SAFI is optional, Cisco also supports it without
BGP MVPN SAFI
[*,*] PE1
mLDP ID X Receiver
(S1, G)
CE
PE 3
Source CE PE 1
(S1,G)
Receiver
CE (S2, G)
BGP RR PE 4
Receiver
(S1, G)
CE (S2, G)
Source
PE 2 BGP MVPN SAFI CE
PE 5
(S2,G)
[*,*] PE2
mLDP ID Y

BGP MVPN SAFI
[*,*] PE1
mLDP ID X Receiver
(S1, G)
CE
PE 3
Source CE PE 1
(S1,G)
Receiver
CE (S2, G)
BGP RR PE 4
Receiver
(S1, G)
CE (S2, G)
Source
PE 2 BGP MVPN SAFI CE
PE 5
(S2,G)
[*,*] PE2
mLDP ID Y

Setting up the MDT
MP2MP or P2MP LSP
Receiver
(S1, G)
CE
PE3
Source CE PE1 BGP MVPN SAFI
(S1,G)
Receiver
[*,*] PE1, mLDP X (S2, G)
CE
[*,*] PE2, mLDP Y PE4
Receiver
(S1, G)
CE (S2, G)
Source PE2 CE
(S2,G) PE5
Setting up the MDT
MP2MP or P2MP LSP
PIM join
(S1,G)
Receiver
(S1, G)
CE
PE3
(S1,G)
Receiver
[*,*] PE1, mLDP X (S2, G)
CE
Receiver
(S1, G)
CE (S2, G)
Source PE2 CE
(S2,G) PE5
• PE3 determines that S1 is reachable via PE1 by doing a RIB lookup
Setting up the MDT
MP2MP or P2MP LSP
PIM join
(S1,G)
Receiver
(S1, G)
CE
PE3
(S1,G)
Receiver
[*,*] PE1, mLDP X (S2, G)
CE
Receiver
(S1, G)
CE (S2, G)
Source PE2 CE
(S2,G) PE5

• PE3 joins the [*,*] mLDP LSP as advertised by BGP AD for PE1
Setting up the MDT
MP2MP or P2MP LSP
PIM join
(S1,G)
Receiver
(S1, G)
CE
PE3
(S1,G)
Receiver
[*,*] PE1, mLDP X (S2, G)
CE
Receiver
(S1, G)
CE (S2, G)
Source PE2 CE
(S2,G) PE5

• When the mLDP LSP is ready, PE3 sends PIM join. Tree is either MP2MP or P2MP
Setting up the MDT
MP2MP or P2MP LSP
PIM join
(S1,G)
Multicast packet Receiver
(S1, G)
CE
PE3
(S1,G)
Receiver
[*,*] PE1, mLDP X (S2, G)
CE
Receiver
(S1, G)
CE (S2, G)
Source PE2 CE
(S2,G) PE5

Setting up the MDT
MP2MP or P2MP LSP
PIM join
(S1,G)
(S1, G)
CE
PE3
(S1,G)
Receiver
[*,*] PE1, mLDP X (S2, G)
CE
Receiver
(S1, G)
CE (S2, G)
Source PE2 CE
(S2,G) PE5

• PE5 joins same (S1,G) it follows same procedures as PE3
Setting up the MDT
MP2MP or P2MP LSP
PIM join
(S1,G)
(S1, G)
CE
PE3
(S1,G)
Receiver
[*,*] PE1, mLDP X (S2, G)
CE
Receiver
(S1, G)
CE (S2, G)
Source PE2 CE
(S2,G) PE5

• PE5 joins same (S1,G) it follows same procedures as PE3
• PE4 does not see P-MDT traffic and signalling for (S1,G)
Setting up the MDT
MP2MP or P2MP LSP
Multicast packet
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
BGP MVPN SAFI Receiver
CE (S2, G)
[*,*] PE1, mLDP X PE4
[*,*] PE2, mLDP Y Receiver

(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)
Setting up the MDT
MP2MP or P2MP LSP PIM join
Multicast packet (S2,G)
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
CE (S2, G)

(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)
Setting up the MDT
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
CE (S2, G)

(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)

Setting up the MDT
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
CE (S2, G)

(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)

• PE2 joins (S2,G) in customer site and forwards packet down LSP
Setting up the MDT
MP2MP or P2MP LSP
Multicast packet
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
CE (S2, G)

(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)

Setting up the MDT
MP2MP or P2MP LSP
Multicast packet
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
CE (S2, G)

(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)

• PE5 now joins (S2,G) and follows same procedures as PE4
Setting up the MDT
MP2MP or P2MP LSP
Multicast packet
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
CE (S2, G)

(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)

• PE5 now joins (S2,G) and follows same procedures as PE4
Control Tree
•C-PIM is SM or BiDir
RP
•How do the PE & C-routers learn RP? BSR
P2MP LSP: PE1 is root
Receiver mapping
(S1, G) agent
CE
PE3
CE
Source PE1
(S1,G)
Receiver
CE (S2, G)
PE4
Receiver
(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)
• Control tree = additional P2MP tree

• Only for RP discovery traffic (AutoRP and BSR)
• Not needed for any other model than the partitioned model
• BGP-AD must be enabled
• When an egress PE receives this AD route, it will join the P2MP tree
Control Tree
•C-PIM is SM or BiDir
RP
•How do the PE & C-routers learn RP? BSR
P2MP LSP: PE1 is root
Receiver mapping
(S1, G) agent
CE
PE3
CE
Source PE1
(S1,G)
Receiver
CE (S2, G)
PE4
Receiver
(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)
P2MP Control Tree
• Control tree = additional P2MP tree

• Only for RP discovery traffic (AutoRP and BSR)
• Not needed for any other model than the partitioned model
• BGP-AD must be enabled
• When an egress PE receives this AD route, it will join the P2MP tree
Summary
• Only PIM join sent towards root
• Only root (ingress PE) is seen as PIM adjacency - unidirectionally
• Core tree is either MP2MP or P2MP
– If PIM bidir needs to be supported, MP2MP is required
• BGP A-D used to signal core tree [*,*]

• BGP A-D used/needed to signal data-MDT
– BGP is needed because Partitioned MDT does not lead to full mesh of PIM across core tree (Default MDT)
• PIM or BGP as overlay signalling protocol

• No core state if no customer traffic
• Optimised when sources are co-located in few sites
• Smaller PIM broadcast domain than Default MDT mLDP
– Fewer unnecessary PIM Join/Prune messages
– No asserts (only one root per P-MDT)
VRF Static over P2MP TE
Receiver
(S1, G)
CE
PE3
CE PE1
Source
(S1,G) MPLS TE needs to be
enabled for OSPF and ISIS
with the same configuration
Receiver
(S1, G)
as for P2P MPLS TE
CE (S2, G)
PE5
Receiver
(S1, G)
CE
PE3
CE PE1
Source
Receiver
(S1, G)
as for P2P MPLS TE
CE (S2, G)
PE5
• Static mapping of C-(S,G) onto MTE tunnels, on PE headend
P2MP TE LSP
Receiver
(S1, G)
CE
PE3
CE PE1
Source
Receiver
(S1, G)
as for P2P MPLS TE
CE (S2, G)
PE5

• Egress PEs (leaves of P2MP TE tunnel) is statically configured destination list
BGP Update (S,G)
Route type 3 S-PMSI A-D route S-PMSI update is used to

P2MP TE LSP map C-(S,G) in VRF to tailend
Tunnel type 1 - RSVP-TE P2MP LSP
includes RD
of P2MP TE tunnel (MPLS
BGP Update (S,G)
label is incoming label)
multicast packet
Receiver
(S1, G)
CE
PE3
CE PE1
Source
Receiver
(S1, G)
as for P2P MPLS TE
CE (S2, G)
PE5

BGP Update (S,G)

includes RD
BGP Update (S,G)
PIM join
multicast packet (S1,G)
Receiver
(S1, G)
CE
PE3
CE PE1
Source
Receiver
(S1, G)
as for P2P MPLS TE
CE (S2, G)
PE5

BGP Update (S,G)

includes RD
BGP Update (S,G)
PIM join
Receiver
(S1, G)
CE
PE3
CE PE1
Source
PIM join
(S1,G)
Receiver
(S1, G)
as for P2P MPLS TE
CE (S2, G)
PE5

• There is no C-mcast signalling in overlay
static over P2MP TE
model also exists in
VRF Static over P2MP TE global context
BGP Update (S,G)

includes RD
BGP Update (S,G)
PIM join
Receiver
(S1, G)
CE
PE3
CE PE1
Source
PIM join
(S1,G)
Receiver
(S1, G)
as for P2P MPLS TE
CE (S2, G)
PE5

• There is no C-mcast signalling in overlay
mVPN Default MDT over P2MP TE
Full mesh of P2MP TE LSPs
Receiver
(S1, G)
CE
MPLS TE needs to be
PE3
CE
PE1
Source
(S1,G)
as for P2P MPLS TE
Receiver
(S1, G)
CE (S2, G)
PE5
Receiver
(S1, G)
CE
MPLS TE needs to be
PE3
CE
PE1
Source
(S1,G)
as for P2P MPLS TE
Receiver
(S1, G)
CE (S2, G)
PE5
• Default MDT is full mesh of Static P2MP TE tunnels - Data MDT is possible
Receiver
(S1, G)
CE
MPLS TE needs to be
PE3
CE
PE1
Source
(S1,G)
as for P2P MPLS TE
Receiver
(S1, G)
CE (S2, G)
PE5
• BGP AD is required
Receiver
(S1, G)
CE
MPLS TE needs to be
PE3
CE
PE1
Source
(S1,G)
as for P2P MPLS TE
Receiver
(S1, G)
CE (S2, G)
PE5
• BGP AD is required
• PIM or BGP C-signalling in overlay
Partitoned MDT over P2MP TE
Partitioned MDT mVPN over P2MP TE
Setting up the MDT
P2MP LSP
Multicast packet
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
BGP MVPN SAFI
Receiver
[*,*] PE1, mLDP X CE (S2, G)
Receiver
(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)
Setting up the MDT
P2MP LSP PIM join
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
BGP MVPN SAFI
Receiver
[*,*] PE1, mLDP X CE (S2, G)
Receiver
(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)
• Same model as for Partitioned MDT over mLDP
Setting up the MDT
P2MP LSP
Multicast packet
Receiver
(S1, G)
CE
PE3
CE
Source PE1
(S1,G)
BGP MVPN SAFI
Receiver
[*,*] PE1, mLDP X CE (S2, G)
Receiver
(S1, G)
CE PE2 (S2, G)
Source CE
PE5
(S2,G)
• Same model as for Partitioned MDT over mLDP
Ingress Replication (IR)
Receiver
(S1, G)
CE CE
PE1 PE3
Source
(S1,G)
Receiver
unicast LSPs (S1, G)
CE
PE5
Receiver
(S1, G)
CE CE
PE1 PE3
Source
• Existing unicast LSPs are used (LDP or TE) (S1,G)
• BGP AD is needed
Receiver
CE
PE5
BGP Update
Example of BGP
Route type 4 (Leaf AD)) (*, *) S-PMSI
signalling for
Tunnel type 1 – Ingress Replication
Partitioned MDT mVPN label
S-PMSI (type 3) [*,*] S-PMSI (type 3) [*,*]

PTA = IR PTA = IR
Used by the egress PE to identify LI flag set LI flag set
the multicast IR data packet and

associate with one VRF
Receiver
(S1, G)
CE CE
PE1 PE3
Source
Receiver
CE
PE5
BGP Update
Example of BGP
signalling for
Partitioned MDT mVPN label Type 6/7

PTA = IR PTA = IR
the multicast IR data packet and

associate with one VRF PIM join
(S1,G)
Receiver
(S1, G)
CE CE
PE1 PE3
Source
Receiver
CE
PE5
BGP Update
Example of BGP
signalling for

PTA = IR PTA = IR
the multicast IR data packet and multicast packet

(S1,G)
Receiver
(S1, G)
CE CE
PE1 mVPN Unicast LSP
PE3
Source
Label Label
Receiver
CE
PE5
BGP Update
Example of BGP
signalling for

PTA = IR PTA = IR
the multicast IR data packet and multicast packet

(S1,G)
Receiver
(S1, G)
CE CE
PE1 mVPN Unicast LSP
PE3
Source
Label Label
Receiver
• Default-MDT (Default MDT-like) and Partitioned MDT PE5
CE
is supported (both with Data-MDT)
• PIM and BGP signalling in overlay is supported
Summary
• Using a P2MP LSP is not efficient
• Replication on the ingress PE
• Can be used for interop issues
• Transport mcast across MPLS on a part/segment of the network
• Can be done if amount of mcast traffic is really low
Inter-AS & CsC
Make sure ASBRs have VPNv4/v6 and IPv4/v6 MVPN routes
• Inter-AS in case no VRF is configured
– GRE: Option C
– mLDP: Option B & C • IOS
router bgp 1
– P2MP TE: Options B & C address-family ipv4 mvpn
no bgp default route-target filter
• CsC • IOS-XR
– Recursive FEC needed router bgp 1
address-family ipv4 mvpn
retain route-target all|route-policy
Inter-AS & CsC
– GRE: Option C
router bgp 1
• CsC • IOS-XR
IOS-XR
multicast-routing
vrf one
address-family ipv4
bgp auto-discovery mldp
inter-as
removes the no-export community

Inter-AS & CsC
– GRE: Option C
router bgp 1
• CsC • IOS-XR
IOS-XR
multicast-routing
vrf one IOS-XR

mpls ldp
address-family ipv4
Needed for:
mldp
bgp auto-discovery mldp
• Unified MPLS
recursive-fec
inter-as • Inter-AS Option B
• BGP-free core
removes the no-export community
Segmented mVPN
non-segmented inter-as multicast tunnel non-segmented seamless multicast tunnel
RR RR
PE1 P1 ASBR1 ASBR2 P2 PE2 PE1 ABR1 ABR2 PE2

Inter-Area
MPLS iBGP + label iBGP + label iBGP + label
(RFC3107) (RFC3107) (RFC3107)
*Seamless MPLS = Unified MPLS

Segmented mVPN
RR RR

Inter-Area
(RFC3107) (RFC3107) (RFC3107)
segmented inter-as multicast tunnel segmented seamless multicast tunnel
segment 1 segment 2 segment 3 segment 1 segment 2 segment 3
RR RR
Inter-Area
(RFC3107) (RFC3107) (RFC3107)

Segmented mVPN
RR RR

Inter-Area
(RFC3107) (RFC3107) (RFC3107)
segmented inter-as multicast tunnel segmented seamless multicast tunnel
segment 1 segment 2 segment 3 segment 1 segment 2 segment 3
RR RR
Inter-Area
(RFC3107) (RFC3107) (RFC3107)
stitching
Segmented mVPN can be for
Global or VPN contex
Segmented mVPN
Applies to
route-types
1, 3, 4 & 5
not for 6 & 7
segment 1 segment 2 segment n
...
PE P A(S)BR A(S)BR
or PE
PE can set color (new extended community)
Used to have downstream A(S)BR/PE select
the appropriate tunnel
Segmented mVPN
Applies to
route-types
1, 3, 4 & 5
not for 6 & 7
Segments can be
mLDP, IR, MPLS segment 1 segment 2 segment n
P2MP TE type, mixed
...
PE P A(S)BR A(S)BR
or PE
Segmented mVPN
Applies to
route-types
1, 3, 4 & 5
not for 6 & 7
Segments can be
P2MP TE type, mixed
...
PE P A(S)BR A(S)BR
or PE
Regeneration of ipv4/6 mvpn routes
Segmented mVPN
Applies to
route-types
1, 3, 4 & 5 I-PMSI/S-PMSI AD Route
PMSI Tunnel Attr
not for 6 & 7
Inter-ara P2MP Next-Hop
Extended Community
Segments can be
P2MP TE type, mixed
...
PE P A(S)BR A(S)BR
or PE
Segmented mVPN
I-PMSI/S-PMSI AD Route
Applies to Original PTA
route-types “encapsulated” in
I-PMSI/S-PMSI AD Route ATTR_SET Attr ATTR_SET Attr
1, 3, 4 & 5
PMSI Tunnel Attr PMSI Tunnel Attr
not for 6 & 7
Extended Community
Segments can be
P2MP TE type, mixed
...
PE P A(S)BR A(S)BR
or PE
Segmented mVPN
Applies to New PTA for new
Original PTA
PMSI Tunnel Attr Segment (can be
any tunnel type)
1, 3, 4 & 5
not for 6 & 7
Extended Community
Segments can be
P2MP TE type, mixed
...
PE P A(S)BR A(S)BR
or PE
Segmented mVPN
Original PTA
any tunnel type)
1, 3, 4 & 5
not for 6 & 7
Inter-ara P2MP Next-Hop Inter-ara P2MP Next-Hop
Extended Community Changed NH Extended Community
Segments can be
P2MP TE type, mixed
...
PE P A(S)BR A(S)BR
or PE
Segmented mVPN
Original PTA
any tunnel type)
1, 3, 4 & 5
not for 6 & 7
Inter-ara P2MP Next-Hop Inter-ara P2MP Next-Hop
Extended Community Changed NH Extended Community
MPLS switching
dataplane
Segments can be
P2MP TE type, mixed
...
PE P A(S)BR A(S)BR
or PE
LSM Conclusion
Deployment Models
Overlay
Model Type core protocol signallng
Deployment Models
Overlay
mLDP inband mLDP none

signallng
Deployment Models
Overlay

signallng
Static Mapping - P2MP TE static mapping

P2MP TE
Deployment Models
Overlay

signallng

P2MP TE
PIM
Default MDT mLDP
model
P2MP TE
Ingress
Replication
Deployment Models
Overlay

signallng

P2MP TE
PIM Default is full mesh P2MP

Default MDT mLDP
model Default is MP2MP
P2MP TE
Ingress Default is full mesh

Replication unicast MPLS LSP
Deployment Models
Overlay

signallng

P2MP TE

PIM
Default MDT mLDP
P2MP TE
Ingress Default is full mesh BGP

Deployment Models
Overlay

signallng

P2MP TE

PIM
Default MDT mLDP
P2MP TE
Ingress Default is full mesh BGP

MP2MP
PIM
mLDP P2MP
Partitioned MDT
Ingress
Replication BGP
P2MP TE
Conclusion
• LSM provides unified unicast/multicast forwarding
• Many, many choices (27 mVPN models)
• It depends on the application and the scalability/feature requirements which protocol is preferred
• mLDP is the safe choice - mLDP is general purpose choice
– Inband signalling is for walled garden
– Partitioned MDT is optimal for few sources/few sites
– P2MP TE is for bandwidth reservation and video distribution (few source sites)
– Default MDT model is for anyone (else)
• PIM is still the PE-CE multicast signalling protocol

• PIM or BGP as overlay protocol (except for inband signalling and static mapping)
• BGP needed as overlay protocol when scale is needed
– Perhaps BGP is natural choice when already needed for Auto Discovery
• With NG mVPN, you can choose any model (per VPN/customer) !
– Even per-source/per-group/next-hop with flexible route-policy (RPL)
Stateless Multicast
Bit Indexed Explicit Replication
(BIER)
Multicast Solutions Today Have Complex Challenges
• Complex Control Plane
– PIM has many modes and corner
cases requiring specialized expertise
to deploy, troubleshoot, and maintain
• State Impacted Convergence
– More trees results in slower network
convergence times
– PIM adds tree state for every
application flow
• Receiver Driven Paths
– Multicast often takes an unexpected,
different path than unicast
BIER – Bit Indexed Explicit Replication
• No Multicast Flow State
– Multi-point unicast reachability
• No Multicast Tree-building Control
Plane
• Fast Convergence
– Unicast convergence times
• No unwanted traffic in MVPN
– True explicit replication
– No trade-off between unwanted traffic
or excessive state
• No Data-Driven Events
Now serving BIER 2015
• Advanced Development Project
• IOS-XR EFT 2015
• bier@cisco.com
Questions?
Call to Action
• Visit the World of Solutions for
– Cisco Campus
– Walk in Labs
– Technical Solution Clinics
• Meet the Engineer
• Lunch time Table Topics
• DevNet zone related labs and sessions
• Recommended Reading: for reading material and further resources for this
session, please visit www.pearson-books.com/CLMilan2015
Complete Your Online Session Evaluation
• Please complete your online session
evaluations after each session.
Complete 4 session evaluations
& the Overall Conference Evaluation
(available from Thursday)
to receive your Cisco Live T-shirt.
• All surveys can be completed via

the Cisco Live Mobile App or the
Communication Stations

Brkipm 3017

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Brkipm 3017

Hochgeladen von

Copyright:

Verfügbare Formate

mVPN Deployment Models

IJsbrand Wijnands – Principal Engineer

Configured on PE per VRF

PIM PIM PIM

Default-MDT created in core using PIM BiDir

1 Default MDT per VPN

1 Default MDT per VPN

Data MDT PIM message

Data MDT PIM message

Data MDT PIM message

Data MDT PIM message

For high rate sources, data-MDT created

For high rate sources, data-MDT created

PIM join CE mcast data

For high rate sources, data-MDT created

PIM join CE mcast data

For high rate sources, data-MDT created

PIM join CE mcast data

For high rate sources, data-MDT created

PIM core plane

PIM PIM in overlay PIM VPN plane

PIM core plane

• Now and Future

Encapsulation/Forwarding IP/GRE LSM Unicast MPLS

Core Tree Signaling PIM MLDP P2MP TE IR

Encapsulation/Forwarding IP/GRE LSM Unicast MPLS

C-Multicast Signaling (PE-PE) PIM

Core Tree Signaling PIM MLDP P2MP TE IR

Encapsulation/Forwarding IP/GRE LSM Unicast MPLS

C-Multicast Signaling (PE-PE) PIM BGP

Core Tree Signaling PIM MLDP P2MP TE IR

Encapsulation/Forwarding IP/GRE LSM Unicast MPLS

C-Multicast Signaling (PE-PE) PIM BGP None

Core Tree Signaling PIM MLDP P2MP TE IR

Encapsulation/Forwarding IP/GRE LSM Unicast MPLS

Service Native Native

C-Multicast Signaling (PE-PE) PIM BGP None

Core Tree Signaling PIM MLDP P2MP TE IR

Encapsulation/Forwarding IP/GRE LSM Unicast MPLS

Service Native Native mVPN mVPN

C-Multicast Signaling (PE-PE) PIM BGP None

Core Tree Signaling PIM MLDP P2MP TE IR

Encapsulation/Forwarding IP/GRE LSM Unicast MPLS

Service Native Native mVPN mVPN VPLS

C-Multicast Signaling (PE-PE) PIM BGP None

Core Tree Signaling PIM MLDP P2MP TE IR

Encapsulation/Forwarding IP/GRE LSM Unicast MPLS

• Unicast MPLS + Ingress Replication (IR)

PM2P LSP MP2MP LSP

 Replication of traffic in core

PM2P LSP MP2MP LSP

 Replication of traffic in core

PM2P LSP MP2MP LSP

 Replication of traffic in core

PM2P LSP MP2MP LSP

 Replication of traffic in core

aka Default MDT

One MP2MP tree or

aka Default MDT aka Data MDT

One MP2MP tree or

aka Default MDT aka Data MDT aka Partitioned MDT

One MP2MP tree or

• IP Multicast routing in the core