1 Multicast Routing Blackhole Avoidance draft-asati-pim-multicast-routing-blackhole-avoid-00 Rajiv Asati Mike McBride IETF 72, Dublin.

Slides:



Advertisements
Similar presentations
Universidade do Minho A Framework for Multi-Class Based Multicast Routing TNC 2002 Maria João Nicolau, António Costa, Alexandre Santos {joao, costa,
Advertisements

March 2010IETF 77, MPLS WG1 Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs draft-rekhter-pim-sm-over-mldp-01.txt Y. Rekhter, Juniper Networks R.
Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 1 Multicast in BGP/MPLS VPNs and VPLS draft-raggarwa-l3vpn-mvpn-vpls-mcast-
Computer Networking A Top-Down Approach Chapter 4.7.
Mobile and Wireless Computing Institute for Computer Science, University of Freiburg Western Australian Interactive Virtual Environments Centre (IVEC)
1 Internet Networking Spring 2004 Tutorial 7 Multicast Routing Protocols.
1 Internet Networking Spring 2006 Tutorial 7 DVMRP.
Routing So how does the network layer do its business?
Slide Set 15: IP Multicast. In this set What is multicasting ? Issues related to IP Multicast Section 4.4.
Internet Networking Spring 2002
1 Spring Semester 2007, Dept. of Computer Science, Technion Internet Networking recitation #5 Mobile Ad-Hoc Networks TBRPF.
MULTICASTING Network Security.
IETF San Francisco Multicast-only Fast ReRoute (MoFRR)
Multicast Routing Protocols NETE0514 Presented by Dr.Apichan Kanjanavapastit.
IGP Multicast Architecture Lucy Yong, Weiguo Hao, Donald Eastlake Andrew Qu, Jon Hudson, Uma Chunduri November 2014 Honolulu USA draft-yong-rtgwg-igp-mutlicast-arch-00.
© Janice Regan, CMPT 128, CMPT 371 Data Communications and Networking BGP, Flooding, Multicast routing.
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Link-State Routing Protocols Routing Protocols and Concepts – Chapter 10.
Multicast Routing Algorithms n Multicast routing n Flooding and Spanning Tree n Forward Shortest Path algorithm n Reversed Path Forwarding (RPF) algorithms.
IP Multicast Lecture 3: PIM-SM Carl Harris Communications Network Services Virginia Tech.
Chapter 22 Network Layer: Delivery, Forwarding, and Routing Part 5 Multicasting protocol.
Draft-li-mpls-network-virtualization-framework-00IETF 88 SPRING WG1 Framework of Network Virtualization Based on MPLS Global Label draft-li-mpls-network-virtualization-framework-00.
IGP Multicast Architecture Lucy Yong, Weiguo Hao, Donald Eastlake Andrew Qu, Jon Hudson, Uma Chunduri November 2014 Honolulu USA draft-yong-rtgwg-igp-mutlicast-arch-00.
Multicast Routing Protocols. The Need for Multicast Routing n Routing based on member information –Whenever a multicast router receives a multicast packet.
Distance-vector Multicast Routing Protocol (DVMRP)
1 © 2003, Cisco Systems, Inc. All rights reserved. CCNA 3 v3.0 Module 2 Single-Area OSPF.
© J. Liebeherr, All rights reserved 1 Multicast Routing.
Draft-atlas-rtgwg-mrt-mc-arch-00IETF 83 RTGWG: 29 Mar IP/LDP Fast-Reroute Using Maximally Redundant Trees draft-ietf-rtgwg-mrt-frr-architecture-01.
Multrans Path Optimization draft-zhou-mboned-multrans-path-optimization-02 Cathy ZHOU Qiong SUN IETF 84, Vancouver.
PIM MTID point on draft-ietf-pim-mtid-01 PIM Working Group IETF 75 meeting Stockholm (Sweden) July 2009.
Saeed Darvish Pazoki – MCSE, CCNA Abstracted From: Cisco Press – ICND 2 – 10 EIGRP 1.
1 Spring Semester 2009, Dept. of Computer Science, Technion Internet Networking recitation #7 DVMRP.
Draft-ietf-pim-source- discovery-bsr-01 IJsbrand Wijnands, Stig Venaas, Michael Brig,
Draft-ietf-fecframe-config-signaling-02 1 FEC framework Configuration Signaling draft-ietf-fecframe-config-signaling-02.txt IETF 76 Rajiv Asati.
Base Specification for Multicast in BGP/MPLS VPNs draft-raggarwa-l3vpn-2547-mvpn-00.txt Rahul Aggarwal Juniper Networks.
Draft-asati-bgp-mpls-blackhole-avoidance-00.txt1 BGP/MPLS Traffic Blackhole Avoidance Proposal draft-asati-bgp-mpls-blackhole-avoidance-00 Rajiv Asati.
LDP extension for Inter-Area LSP draft-decraene-mpls-ldp-interarea-04 Bruno DecraeneFrance Telecom / Orange Jean-Louis Le RouxFrance Telecom / Orange Ina.
PIM-BIDIR RP Resiliency Jeffrey Zhang, Kurt Windisch, Jaroslaw Adam Gralak Juniper Networks 88 th IETF, Vancouver.
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Link-State Routing Protocols Routing Protocols and Concepts – Chapter 10.
Draft-li-rtgwg-igp-ext-mrt-frr-00IETF 85 RTGWG1 Applicability of LDP Multi-Topology for Unicast Fast-reroute Using Maximally Redundant Trees draft-li-rtgwg-ldp-mt-mrt-frr-01.
Extension of the MLD proxy functionality to support multiple upstream interfaces 1 Luis M. Contreras Telefónica I+D Carlos J. Bernardos Universidad Carlos.
IP Multicast Lecture 4: PIM-SM Carl Harris Communications Network Services Virginia Tech.
1 IETF-70 draft-akhter-bmwg-mpls-meth MPLS Benchmarking Methodology draft-akhter-bmwg-mpls-meth-03 IETF 70 Aamer Akhter / Rajiv Asati /
82 nd Taipei Protection Mechanisms for LDP P2MP/MP2MP LSP draft-zhao-mpls-mldp-protections-00.txt Quintin Zhao, Emily Chen, Huawei.
1 Group Communications: Reverse Path Multicast Dr. Rocky K. C. Chang 19 March, 2002.
IS-IS Extension For Building Distribution Trees draft-yong-isis-ext-4-distribution-tree-01 Lucy Yong, Weiguo Hao, Donald Eastlake Andrew Qu, Jon Hudson.
Engineering Workshops 96 ASM. Engineering Workshops 97 ASM Allows SPTs and RPTs RP: –Matches senders with receivers –Provides network source discovery.
85th IETF – Atlanta, USA J. Asghar IJ. Wijnands S.Krishnaswawy V. Arya draft-asghar-pim-explicit-rpf-vector-00
Avoiding Unnecessary Upstream Traffic in Bidir-PIM Jeffrey Zhang Weesan Lee Juniper Networks 82th IETF, Taipei.
86th IETF – Orlando, USA J. Asghar IJ. Wijnands S.Krishnaswawy V. Arya draft-asghar-pim-explicit-rpf-vector-01
Multicast Outline Multicast Introduction and Motivation DVRMP.
MVPN Update Continued work on both architecture draft and BGP-MVPN draft Seeing “light at end of tunnel” ☺ Progress since last time: Carrier’s carrier.
Multi-Instances ISIS Extension draft-ietf-isis-mi-08.txt
Multi Topology Routing (MTR) for OSPF
ISIS Flooding Reduction in MSDC
IETF Taiwan draft-wijnands-pim-source-discovery-bsr-00
IP Multicast Fast Reroute follow-up on draft-dimitri-rtgwg-mfrr-framework-00 RTG Working Group IETF 75 meeting Stockholm (Sweden) July 2009.
FAR: A Fault-avoidance Routing Method for Data Center Networks with Regular Topology Please send.
Summary Issued adoption call for draft-zhou-pim-vrrp.
draft-pim-with-ipv4-prefix-over-ipv6-nh
IS-IS Flooding Reduction in MSDC
Chapter 10 Link State Routing Protocols
Dynamic Routing Protocols part3 B
Optional Read Slides: Network Multicast
PIM Backup DR Mankamana Mishra IETF-102
draft-pim-with-ipv4-prefix-over-ipv6-nh
draft-liu-pim-mofrr-tilfa-00
draft-ietf-pim-ipv4-prefix-over-ipv6-nh
draft-ietf-pim-ipv4-prefix-over-ipv6-nh-01
Presenter: Raunak Banthia
Presentation transcript:

1 Multicast Routing Blackhole Avoidance draft-asati-pim-multicast-routing-blackhole-avoid-00 Rajiv Asati Mike McBride IETF 72, Dublin

2 Agenda Background Problem Statement –Root Cause Solution Advantage Next Steps

3 Background In a network, interface DOWN and UP events may happen. There are scenarios in which multicast traffic may get dropped after the local interface UP event or metric change etc. This draft proposes a simple and straight- forward solution for such scenarios.

4 Problem The multicast traffic is dropped wherever the related multicast tree is disrupted. Is there a mcast tree disruption in this sequence ?? 1.Multicast tree is set up to deliver the traffic as R1 -> R2 -> R3 2.Interface between R1 and R3 comes UP 3.R1-R3 interface becomes usable per unicast routing IGP/BGP 4.R3 calculates the new RPF interface for source to be R1-R3 int. 5.R3 changes the multicast tree to be R1 -> R3 6.R3 sends PIM join to R1 and PIM Prune to R3 7.What if the R1-R3 int doesn’t yet have the PIM adjacency !!!  R1R2R3 SourceReceiver Traffic flow PIM message Yes, Multicast tree is disrupted.

5 Problem The multicast tree gets disrupted either on R1 or R3, and traffic gets blackholed. R1R2R3 SourceReceiver Traffic flow PIM message Traffic drop R1R2R3 SourceReceiver R1 may not even include R1-R3 link in the OIL lacking PIM adj. The blackhole continues until the PIM adjacency is established on R1-R3. Traffic flow

6 Root Cause Firstly, the PIM neighbor establishment on an interface may take longer –than the total time taken to establish unicast routing neighbor on that interface, determine the new RPF neighbor, if any, and update the corresponding multicast route entry(s). Secondly, a multicast routing entry may be updated with the new RPF neighbor information immediately after the unicast routing convergence. –There is no check for whether the RPF neighbor is also the PIM neighbor prior to this update. The latter is really what that causes the disruption in multicast tree.

7 Solution The solution is to replace the current RPF neighbor with the new RPF neighbor for a multicast routing entry ONLY if the new RPF neighbor is determined to be the PIM neighbor. SourceReceiver The RPF neighbor is not the PIM neighbor yet, don’t disrupt the tree. R1R2R3 Traffic flow

8 Solution The solution is to replace the current RPF neighbor with the new RPF neighbor for a multicast routing entry ONLY if the new RPF neighbor is determined to be the PIM neighbor. SourceReceiver R1R2R3 Traffic flow The RPF neighbor is now the PIM neighbor, update the multicast tree.

9 Solution Details (Section 3.1) The multicast routing sequence becomes as following – 1.New RPF neighbor is determined after the unicast routing convergence. 2.Check whether the new RPF neighbor is also PIM neighbor on the RPF interface 3.If it is not, then initiate the PIM neighbor establishment procedure by sending PIM Hellos etc. on the new RPF interface, and wait. 4.If it is, then update the multicast forwarding entry by replacing the old RPF neighbor (and interface) information with the new RPF neighbor (and interface) information 5.Send the PIM Join message for the related multicast routes (S,G or *,G). 6.Send the PIM Prune message to the old RPF neighbor for the related multicast routes (S,G or *,G)

10 Advantage This solution ensures that the multicast distribution tree is not disrupted unnecessarily and the multicast traffic is not blackholed just because a link comes UP. –Of course, the multicast distribution tree may not be able to make use of the changed topology i.e. new link for brief time period. –Paves the way for make-before-break (section 3.2) Simple and straight-forward PIM based solution. Changes are local to the router. No interoperability desired.

11 Next Steps Incorporate the feedback received so far. –Will update the section 4 in the next version. Request WG Adoption (as an informational draft)!!!

12 Comparison with other solutions This solution nicely avoids the tree disruption due to the local link Up event. This draft does not attempt to address the tree disruption due to remote link Up event. –Well, it is out of scope for any hop-by-hop protocol (since it is not a link-state protocol). LDP based MPLS LSP, for example. For the remote link Up event, a solution based on having incongruent multicast topology and dedicated SPF for that topology may be desired. However, it comes with the baggage that may not be suited for every network - –Should incongruence be mandatory or optional? –Should the multi-topology be really mandated ? –Should the router be forced to have multiple RIBs with common information? –Can the operations/troubleshooting network mgt applications deal with multi- topology etc. right away? –Will there be any negative impact on ucast or mcast convergence ?