1 / 7

IETF 74 th meeting, San Francisco – L3VPN WG

Multicast VPN fast fail-over draft-morin-l3vpn-mvpn-fast-failover-00 Wim Henderickx , Praveen Muley – Alcatel Lucent Thomas Morin – FT Orange Yakov Rekhter, Rahul Aggarwal – Juniper. IETF 74 th meeting, San Francisco – L3VPN WG. Introduction. Goal

dusty
Download Presentation

IETF 74 th meeting, San Francisco – L3VPN WG

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. Multicast VPN fast fail-overdraft-morin-l3vpn-mvpn-fast-failover-00 Wim Henderickx, Praveen Muley – Alcatel Lucent Thomas Morin – FT Orange Yakov Rekhter, Rahul Aggarwal – Juniper IETF 74th meeting, San Francisco – L3VPN WG

  2. Introduction • Goal • Minimize connectivity restoration time for multicast VPN services in the presence of failures • Relying on rerouting for multicast connectivity restorationtypically involves: • Waiting for unicast routing to converge • Additional signaling to restore multicast forwarding state (“join”) • That may not be fast enough for certain multicast applications... • Certain multicast applications often have high availability expectations • This work proposes tools to provide fast connectivity restoration for multicast VPN traffic: • Two complementary mechanisms providing different levels of failure coverage and restoration performance • Focus on upstream failures in the provider scope: • Upstream PE failures • Core node/link failures • (other failures too, depending on the strategy implemented)

  3. UMH selection based on tunnel status • UMH selection taking into account tunnel status • Reminder: • “UMH Selection” specifies procedures by which a downstream PE determines the PE from which it will receive a said multicast flow (C-S, C-G) • In the current spec, “UMH Selection” is done solely based on the VPN unicast routing information • Does not take into account the state of the P-tunnel that the selected UMH uses to send (C-S, C-G) to the local PE • Idea: let UMH procedures take into account the state of the P-tunnel from the selected/primary UMH to the PE • Make “UMH Selection” on a (downstream) PE switch to a backup (upstream) PE as soon as the (downstream) PE determines that the P-tunnel from the selected/primary (upstream) PE is down, without waiting for unicast VPN convergence • Different possible ways for a PE to detect that a P-tunnel from the selected/primary UMH to the PE is down: • P2MP OAM (Multipoint BFD) • Traffic counters • P-Tunnel signaling (RSVP-TE PathTear) • IGP tunnel root tracking • … • Key: avoid waiting for unicast convergence

  4. Standby BGP C-Multicast route • Standby BGP C-Multicast route • Idea : prepare the backup PE so that it is ready to become UMH when the primary PE fails • How ? • Besides advertising a normal (C-S,C-G) C-multicast Tree Join route to the nominal upstream PE, downstream PEs advertise a Standby C-multicast Tree Join route to the backup upstream PE • The backup upstream PE prepares for a possible failure (e.g. by joining the source) • The backup upstream PE monitors the reachability of C-S through the nominal/primary PE • On failure, traffic is forwarded by backup PE • Failure detection can be done, for instance: • based on P2MP OAM • based on unicast VPN reachability to C-S • Key: avoid additional signaling at failure time

  5. Standby C-multicast route - Example Standby BGP C-multicast route Secondaryupstream PE receivers ? source downstreamCE upstreamCE PrimaryupstreamPE downstreamPE receivers "normal" BGP C-multicast route Warm standbyExample

  6. Different protection levels • Cold standby • Backup PE joins towards the CE only after it detects failure of the primary PE • Warm standby • Backup PE is ready to send traffic when it detects the failure of the primary PE (backup PE is “pre-joined” toward the CE) • Hot standby • Backup PE sends the traffic before the failure occurs • Downstream PE switch to backup tunnel based on VPN unicast routes • Hot leaf standby • Backup PE sends the traffic before the failure occurs • Downstream PE switch to backup tunnel based on tunnel status

  7. Conclusion • Wrap up: two simple mechanisms to reduce connectivity restoration time for multicast traffic in a VPN context, for upstream failures in the provider scope (upstream PE & core failures) • UMH Selection based on P-tunnel status : avoid waiting for unicast convergence • Standby C-multicast route : avoid signaling at failure-time by preparing the backup upstream PE • These mechanisms can be used, each one alone or together, depending on the failure coverage and level of protection wanted • Different levels of protection: cold, warm, hot, leaf hot • Working group feedback ?

More Related