March 22 2007 IETF 68, L3VPN WG 1 MVPN Revisited draft-mnapierala-mvpn-rev-00 IETF 68 March 2007 Maria Napierala
Jan 13, 2016
March 22 2007 IETF 68, L3VPN WG 1
MVPN Revisited
draft-mnapierala-mvpn-rev-00
IETF 68 March 2007
Maria Napierala
March 22 2007 IETF 68, L3VPN WG 2
Summary of the Proposal• C-source is discovered based on 1st C-S packet received
on C-shared tree (PIM-SM) and on 1st (C-S, C-G) Join (PIM-SSM)
• PIM-SM C-trees are (by default) automatically triggered as SPTs by all egress PEs but there is no inter-PE RPT-to-SPT switchover initiated by C-routers
• If a source C-S is reachable via several PEs, downstream PE will choose its BGP best installed route to reach C-S. If multiple next-hops are installed the tie breaker is either highest IP address which is the default RFP selection method*
• PE joins only those tunnels that were announced by its best next hop to C-S
• Initial C-S traffic is dropped until the S-PMSI or UI-PMSI is built
* Or could be based on per multicast state load splitting but there is no standard method
March 22 2007 IETF 68, L3VPN WG 3
New Additions
• To be added in the next version (-01) of the draft• Support of C-Shared Trees• Support of C-Bidir Trees• Support of Anycast C-RPs
March 22 2007 IETF 68, L3VPN WG 4
Main Requirements• Multicast routing in VRF should follow its unicast routing
policy • Downstream PE should join only those tunnels that were
announced by its best next hop to C-S or C-RP– a tunnel to be used for C-S should not be created either before C-
source is discovered or after the source sends traffic natively on (C-S,C-G) state
• RPF neighbor (upstream PE) for C-S should be unique per set of VRFs with the same unicast routing policy towards the C-S– RPF neighbor selection should not include not installed BGP
routes because this might alter the expected traffic flows in MVPN
• Support of multiple RPF neighbors for Anycast C-RP is required
March 22 2007 IETF 68, L3VPN WG 5
Main Differences from Other Proposal• C-Multicast Routing:
– Point-to-point based not LAN-based RPF neighbor selection (no DR or DR-like election procedure)
– RPF neighbor selection includes only BGP installed routes
– RPF neighbor is unique to set of VRFs with the same unicast routing policy
– PE joins only those tunnels that were announced by its best next hop to C-S or C-RP
– PIM-like support of Anycast C-RPs: any downstream PE on a single C-RPT to closest C-RP
• C-Source Discovery– does not require PEs to participate in C-RP source
discovery process – different Source Discovery for PIM-SSM and PIM-SM
March 22 2007 IETF 68, L3VPN WG 6
Source Discovery in MVPN
• Proposed solution consists in ASM-like C-source discovery technique and results in the simplification of inter-PE multicast traffic patterns
• ASM C-source discovery process is “intercepted” by PE’s in order to extract C-source information
• Active C-sources become known in MVPN negligibly later than they would in plain ASM
March 22 2007 IETF 68, L3VPN WG 7
Bypassing Shared Trees in MVPN
• Knowledge about active sources is used to eliminate inter-PE shared tree (RPT) to shortest path tree (SPT) switchover and to simplify PE-to-PE inter-site multicast routing – there are no inter-PE (C-S,C-G,rtp) Prune
messages • In order to eliminate inter-site RPT-to-SPT
switchover, PIM control procedures in MVPN context need to be modified. Those modifications are straightforward
• Proposed modifications of PE-to-PE multicast routing do not require changes to PIM protocol in the customer domain
March 22 2007 IETF 68, L3VPN WG 8
Source Discovery Techniques
• Two source discovery techniques are defined, one for PIM-SM and one for PIM-SSM
• Active source C-S is discovered in MVPN when:
(PIM-SM): PE attached to C-RP receives the first (C-*, C-G) packet from C-S
(PIM-SSM): PE attached to C-S receives the first (C-S, C-G) join, either from directly connected CE or from another PE in MVPN
March 22 2007 IETF 68, L3VPN WG 9
Source Discovery in PIM-SM – 1
• When C-RP receives PIM Register from C-S, it extracts from it multicast data packet and sends it over the shared (C-*, C-G) tree
• PE attached to C-RP “snoops” for a packet received on (C-*,C-G) and extract from it C-source address - this is no different from the last hop router extracting source address from the first packet it receives on shared tree in plain ASM procedure
• When PE attached to C-RP receives the 1st multicast packet from the source C-S over (C-*,C- G) tree it sends (C-S, C-G, rpt) Prune towards C-RP and announces the active source C-S to all PE’s in the MVPN
• PE attached to C-RP does not forward (C-*, C-G) traffic on the interface leading to SP’s core network
March 22 2007 IETF 68, L3VPN WG 10
Source Discovery in PIM-SM – 2
• Upon receiving active C-S announcement message:– PE’s connected to C-S send tunnel announcements for
(C-S, C-G)– PE’s connected to receivers of C-G (i.e., egress PE’s)
convert (C-*, C-G) PIM Join/Prune messages received from locally attached CE’s to (C-S, C-G) PIM Join/Prune for all active sources C-S. Each egress PE will send (C-S, C-G) join to its best next-hop to C-S
• Any PE with (C-*, C-G) or (C-S, C-G) state that receives tunnel announcement for (C-S, C-G) with join the tunnel announced by its best next hop to C-S
March 22 2007 IETF 68, L3VPN WG 11
Source Discovery in PIM-SM – 3 C-Source Becomes Inactive
• When C-S stops sending traffic (C-S, C-G) state expires on PE’s attached to C-S
• PE’s attached to C-S sent source withdrawal message for (C-S, C-G)
• Egress PE’s stop joining tunnels announced for (C-S, C-G) and remove source and tunnel information
March 22 2007 IETF 68, L3VPN WG 12
Source Discovery in PIM-SM – 4 Dually Homed C-Receivers
• There could be scenario where a dually homed MVPN site with receiver(s) chooses a different next-hop PE depending on whether a shared (C-*,C-G) tree or source (C-S,C-G) tree is joined. In means that shared and source trees diverge at this site
• Egress PE on the C-RPT will receive (C-S,C-G,rtp) Prune message from its directly connected CE
• Egress PE on the C-RPT will prune itself off (C-S, C-G)-tree and the tunnel for (C-S,C-G) if there are no receivers for (C-*,G) or (S,G) attached to it
• Egress PE on C-SPT will join the tunnel for (C-S,C-G) if it was not joined yet
March 22 2007 IETF 68, L3VPN WG 13
Supporting Shared Trees
• MVPN customer might require to never switch to SPT’s for a particular C-G. The information of such C-groups has to be known to SP and has to be made known to PE’s with this MVPN
• A PE attached to a C-RP for C-G will be the root of the tunnel for all sources sending to C-G
March 22 2007 IETF 68, L3VPN WG 14
Supporting Shared Trees – 1• PE attached to C-RP, upon receiving (C-*, C-G) PIM Join
from another PE, follows normal ASM procedure• When PE attached to C-RP receives 1st multicast packet
over (C-*, C-G) tree (from any C-S), this PE forwards it to its OIL for (C-*, C-G) and announces the active group C-G and tunnel to be used for C-G traffic to all PE’s in the MVPN:– if MI-PMSI exists then the initial (C-*, C-G) packets could be sent
over this tunnel (more on this on slide 18)– if MI-PSMI does not exist and since UI-PMSI or S-PMSI tunnel for
C-G is not built yet, the initial (C-*, C-G) packets sent to the interface leading to SP’s core network will be dropped
• PE’s attached to receivers of C-G upon receiving the C-G announcement will join the tunnel announced by the best next hop to C-RP for C-G
March 22 2007 IETF 68, L3VPN WG 15
Supporting Shared Trees – 2
• (C-S, C-G) Joins/Prunes received from any site other than the site with C-RP for C-G will be dropped at PEs
• PE attached to C-S upon receiving 1st (C-S, C-G) Join (from C-RP) announces the tunnel to be used for (C-S, C-G) traffic
• PE’s attached to C-RP joins this tunnel
March 22 2007 IETF 68, L3VPN WG 16
Source Discovery for PIM-SM – Summary
• All (C-*, C-G) data traffic between PE’s is blocked and inter-PE RPT to SPT multicast traffic switching is eliminated
• Inter-PE (S,G,rpt) Prunes messages are eliminated
• Regardless of whether or not the traffic in C-network switched to SPT’s, PE-to-PE MVPN traffic is sent only on SPT’s
• All traffic to C-G can be kept on a shared tree if required
March 22 2007 IETF 68, L3VPN WG 17
Source Discovery in PIM-SSM• PE attached to C-S, upon receiving 1st (C-S, C-G) Join
from another PE or from a locally attached site, announces tunnel for (C-S, C-G) traffic
• Upon receiving tunnel announcement a PE connected to receiver(s) of (C-S, C-G) joins the tunnel announced by its best next hop to C-S
• When C-S stops sending traffic then (C-S, C-G) expires on PE’s attached to C-S and those PE’s sent tunnel withdrawal message for (C-S, C-G)
• Egress PE’s stop joining tunnels announced for (C-S, C-G) and (all PE’s) remove the tunnel information
March 22 2007 IETF 68, L3VPN WG 18
Choices for Handling Initial Packets Sent over C-RPT
• C-multicast traffic is dropped until S-PMSI is built• C-multicast traffic is dropped until UI-PMSI is built. UI-PMSI
should be announced during MVPN discovery and built upon receiving C-S active announcement message. The UI-PMSI and S-PMSI are rooted at the same ingress PE and hence there will no traffic shifts in the SP network when traffic is switched from UI-PMSI to S-PMSI
• Traffic from C-S is not dropped but sent on MI-PMSI, announced and built during MVPN discovery, until S-PMSI for C-S tunnel is announced and built– since the root of MI-PMSI might be different than the root of S-
PMSI, the C-S traffic might shift between two different tunnels– if PIM-on-LAN procedure is used for C-multicast routing the
Assert process will force the same single forwarder for entire MVPN. Hence, with PIM-on-LAN the initial C-RPT traffic cannot be sent over MI-PMSI
Since the initial traffic even if sent could be meaningless to receivers, there is no advantage in using MI-PMSI for C-traffic
March 22 2007 IETF 68, L3VPN WG 19
Handling Multiple Equal Cost Paths to C-S/C-RP
• If there are multiple next-hops to C-S or to dynamic C-RP installed by BGP in VRF, PE with the highest IP address is chosen as the next hop*
• If there are multiple next-hops to static C-RP installed by BGP in VRF, the closest PE (based on SP network IGP cost) is chosen as a next hop and only as a tie breaker the PE with the highest IP address
• IGP cost-based next-hop selection provides PIM-like support of Anycast C-RP’s: C-receivers join the closest Anycast C-RP across SP network– PE cannot distinguish multiple next hops to C-RP due to different
Anycast C-RPs or due to static/Anycast C-RP being dually homed with equal-cost. Hence, closest distance-based next hop selection could trigger more tunnels in SP network
*Or per multicast state load splitting could be but it is not standardized
March 22 2007 IETF 68, L3VPN WG 20
Supporting Anycast C-RPs
Static/Anycast C-RP can be supported in one of
following ways:
1. Using IGP cost in the best route selection to static C-RP (default static C-RP selection)
2. Tie breaker is always the highest IP address but VPN uses different unicast routing policies to reach different Anycast-RP’s serving C-G. This allows MVPN customer to define its Anycast C-RP selection
March 22 2007 IETF 68, L3VPN WG 21
Supporting C-Bidir – 1• PIM Bidir chooses single Designated Forwarder
(DF) for upstream packets (away from the source) on every network segment and point-to-point link– the DF election procedure eliminates parallel downstream
paths from any RP
• Two options of supporting C-Bidir Trees– all VRFs of the same VPN have to have the same unicast
routing policy; the best next hop to C-RP is chosen as a DF for C-RP’s bidirectional groups (tie breaker is the highest IP address)
– a group of VRFs with the same unicast routing policy uses unique (across MVPN) C-RP(s) with unique (across MVPN) bidirectional groups
March 22 2007 IETF 68, L3VPN WG 22
Supporting C-Bidir – 2
• Designated Forwarder PE upon receiving (C-*,C-G) Join from another PE announces the tunnel to be used for C-G traffic– for scalability, C-Bidir traffic should use MP2MP
tunnels in SP network (build with PIM Bidir or with MP2MP LSPs)
• If Designated Forwarder PE prunes interface leading to SP core network from its OIL for (C-*, C-G) (i.e., all remote PEs pruned themselves off (C-*, C-G) tree), this PE announces the tunnel withdrawal for C-G
March 22 2007 IETF 68, L3VPN WG 23
Additional Requirements
• Discovery of multipoint-to-multipoint/few applications (will be added to next version of the draft)
• Tunnel aggregation – receiver tracking• Support of C-BSR and C-Auto-RP
– still require default MI-PMSI– based on refresh mechanism (every 60 sec)