1 / 23

MVPN Revisited draft-mnapierala-mvpn-rev-00

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)

adanne
Download Presentation

MVPN Revisited draft-mnapierala-mvpn-rev-00

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MVPN Revisiteddraft-mnapierala-mvpn-rev-00 IETF 68 March 2007 Maria Napierala 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 IETF 68, L3VPN WG

  20. 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

  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 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 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) IETF 68, L3VPN WG

More Related