230 likes | 415 Views
MVPN Revisited draft-mnapierala-mvpn-rev-00. IETF 68 March 2007 Maria Napierala. Summary of the Proposal. C-source is discovered based on 1 st C-S packet received on C-shared tree (PIM-SM) and on 1 st (C-S, C-G) Join (PIM-SSM)
E N D
MVPN Revisiteddraft-mnapierala-mvpn-rev-00 IETF 68 March 2007 Maria Napierala IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
Supporting Anycast C-RPs Static/Anycast C-RP can be supported in one of following ways: • Using IGP cost in the best route selection to static C-RP (default static C-RP selection) • 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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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 IETF 68, L3VPN WG
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) IETF 68, L3VPN WG