Network Working Group T. Morin Internet-Draft G. Cauchie Intended status: Informational France Telecom - Orange Labs Expires: August 28, 2008 February 25, 2008 Multicast blackhole mitigation with PIM adjacency conditions on routing announcements draft-morin-mboned-mcast-blackhole-mitigation-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract In a network running PIM-SM, multicast traffic can fail to be properly routed and forwarded during some period of time after a topology change, when unicast routing converges to a new path using a new next-hop before multicast routing adjacencies are fully setup with this new next-hop. At this point, a blackhole appears in the multicast topology and persists until the PIM adjacency become fully setup. This document describes different procedures aiming at Morin & Cauchie Expires August 28, 2008 [Page 1] Internet-Draft Multicast blackhole mitigation February 2008 avoiding such blackholes, focusing on the use of non-congruent unicast routing that takes into account the status of PIM adjacencies. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Ineffective PIM Adjacency . . . . . . . . . . . . . . . . 3 3.2. Problem description . . . . . . . . . . . . . . . . . . . 4 3.3. Partial solutions . . . . . . . . . . . . . . . . . . . . 4 3.4. Applicability to SSM and non-SSM multicast . . . . . . . . 5 4. PIM-adjacency-based non-congruent MRIB . . . . . . . . . . . . 5 4.1. Strategy description . . . . . . . . . . . . . . . . . . . 5 4.2. Criterias . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Prune links on which PIM is not enabled . . . . . . . 6 4.2.2. Prune links with no received PIM Hello . . . . . . . . 6 4.2.3. Prune links with no sent PIM Hello . . . . . . . . . . 7 4.2.4. Other criteria . . . . . . . . . . . . . . . . . . . . 7 5. Alternative proposal . . . . . . . . . . . . . . . . . . . . . 7 6. Interoperability considerations . . . . . . . . . . . . . . . 7 7. Recommandations . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Morin & Cauchie Expires August 28, 2008 [Page 2] Internet-Draft Multicast blackhole mitigation February 2008 1. Introduction In a network running PIM-SM [RFC4601], multicast traffic can fail to be routed during some period of time after a topology change, when unicast routing protocols converge before the PIM-SM multicast routing protocol adjacencies are fully setup, causing blackholing of multicast traffic. This document describes different procedures aiming at avoiding such blackholes. Section 3 describes the problem statement, and following Section 4 and Section 5 describe possible solutions to mitigate theses blackholes. 2. Terminology This document is essentially using terminology from unicast routing protocols and from the PIM-SM specifications [RFC4601]. Moreover, throughout this document the "MT-IGP" term designates an IGP able to carry information about multiple network topology. Example of such IGP are: MT-ISIS [I-D.ietf-isis-wg-multi-topology], MI-ISIS [I-D.previdi-isis-mi], MT-OSPFv2 [RFC4915], MT-OSPFv3 [I-D.ietf-ospf-mt-ospfv3], MI-OSPF [I-D.acee-ospf-multi-instance]. 3. Problem statement 3.1. Ineffective PIM Adjacency In a number of situations, the status of a link can be "up" without the PIM adjacency being fully setup. Possible causes for this kind of situations are : o PIM is unconfigured on one or both ends of the link (not yet configured, or misconfigured) o a bug or hardware failure is inducing unreliability or delay in sending or receiving PIM Hello messages o no PIM Hello has been received yet by one of the routers, but that router would require having received a PIM Hello before sending PIM Join to a neighbor On this last point, note that it seems that [RFC4601] does not clearly tell if a router should or should not delay sending PIM Joins on a link toward a router from which it hasn't yet received any PIM Hello message. The procedures described in [RFC4601] are so that it Morin & Cauchie Expires August 28, 2008 [Page 3] Internet-Draft Multicast blackhole mitigation February 2008 can take up to seconds (up to 5s, by default) before a neighbor will send a PIM Hello triggered by a Hello sent by a new neighbor on the link. Operational experience shows that all of these situations occur, even frequently for some of them. A similar problem affects the LDP protocol, for which a solution is also being studied[I-D.ietf-mpls-igp-sync]. 3.2. Problem description The generic problem targeted by this document is when the unicast routing protocol starts to consider a link as available for unicast routing (e.g.. a new link, or a flapping link coming up) but the PIM adjacency on this link is ineffective (see section above), causing PIM Joins to fail to be propagated further, and resulting in a blackhole for the corresponding multicast traffic. This problem can occur in a few distinct situations: o IGP case : in an autonomous system, the IGP can disseminate information relative to a new link before PIM-SM is fully setup on this link o EGP case : when a link between two ASBRs comes up, the EGP (typically BGP) can possibly advertise the new routes received from the neighbor ASBR before PIM is fully effective on this link o multicast BGP/MPLS VPN case : similar to the EGP case Partial solutions to the issues presented above do exist based on implementation or unicast routing tuning, but fail to cover all plausible blackhole causes. 3.3. Partial solutions A first solution is to relax how PIM behaves and do not require a router to having received or sent a Hello to/from a neighbor before accepting/sending a Join from/to the neighbor. This solution somehow partially defeats the purpose of PIM Hello procedures, that include advertisements of parameters and capabilities between neighbors, and would fail if the use of Hellos is extended to carry information that impacts how Join or Prune are sent, but still appears to be effective given the current use of Hello messages. It remains however a partial solution to the problem exposed here, since it doesn't cover the misconfiguration cases. Morin & Cauchie Expires August 28, 2008 [Page 4] Internet-Draft Multicast blackhole mitigation February 2008 A second solution is to improve the PIM procedures for setting up an adjacency, so that the delay before sending a triggered hello or replying to a hello of a new neighbor is reduced to zero (current specifications use a random timer between 0 and Triggered_hello_delay, which defaults to 5s). That solution is an improvement upon the previous one, but still remains a partial solution to the problem described in this document, since it doesn't cover misconfiguration cases. 3.4. Applicability to SSM and non-SSM multicast The PIM-SM multicast routing protocol is using unicast routes (the MRIB) to decide how PIM Join messages should be routed toward the source (in the SPT case) or the RP (in the RPT case). In this document we will only describe the SSM/SPT case, for the sake of clarity, but all statements equally apply to the non-SSM/RPT case, using the RP instead of the multicast source. 4. PIM-adjacency-based non-congruent MRIB 4.1. Strategy description Most unicast routing protocols have been extended, or are being extended to support semantic extensions to advertise unicast routes that will be used specifically for multicast routing : MT-ISIS [I-D.ietf-isis-wg-multi-topology], MI-ISIS [I-D.previdi-isis-mi], MT- OSPF [RFC4915], MP-BGP SAFI 2 [RFC4760], MP-BGP SAFI 129 VPNv4 routes [I-D.ietf-l3vpn-2547bis-mcast-bgp]. When one or more of these extensions are in use, PIM-SM will be configured to use the distinct RIB populated by them as its MRIB (the RIB used for RPF lookups). In such a case, the MRIB is said to be "non-congruent" to the unicast RIB. The issues described in this document can be fully or partially addressed by the use of a non-congruent MRIB that takes into account the status of the PIM-SM adjacencies. A link or the associated next hop won't populate the MRIB based only on the status of the link for the unicast routing protocol, but only if conditions are verified on the status of the PIM adjacency. More specifically: o in the case of a link where a link-state protocol (typically an IGP) is used, the link (and the routes directed routed through it) will not be advertised in the multicast-specific topology if it is known that the PIM adjacency is not ready. o in the case of a link where a distance vector protocol (e.g.. BGP) is used, the routes received from a neighbor on that link, Morin & Cauchie Expires August 28, 2008 [Page 5] Internet-Draft Multicast blackhole mitigation February 2008 that pertain to the multicast-specific RIB (e.g.. SAFI 2 routes in the case of BGP) will not be re-advertised. Different facts can be taken into account by the local router to decide whether the PIM adjacency is ready or not. Different routers in a domain can have a different policy for this decision process : the more specific is the information taken into account, the more black-holes are expected to be avoided ; but in any case, there will always be some improvements over just using non-congruent routing. 4.2. Criterias This sections details the different facts that can be taken into account to decide that a PIM adjacency is effective or not. 4.2.1. Prune links on which PIM is not enabled This is the most basic criteria, which consist in including in the multicast topology, only links on which PIM is administratively enabled. It typically allows to cover cases of PIM misconfiguration where PIM is not enabled on both sides of a link. 4.2.2. Prune links with no received PIM Hello This consists in not including in the multicast topology, links on which no PIM Hello was received yet (or for which the PIM Neighbor Liveness Timer expired). This is particularly relevant if the local PIM-SM implementation requires having received PIM Hellos from a neighbor before sending a Join toward this neighbor. 4.2.2.1. IGP on LAN specific case An IGP like OSPF or ISIS elects a node that will be responsible of creating a pseudo nodes for the LAN and each node on the LAN will then announce an adjacency with this pseudo-node. There is not such notion as a pseudo-node in PIM-SM, PIM adjacencies on a LAN being setup between all PIM routers on the LAN. In the case of an IGP on a LAN the "prune links with no received PIM Hello" criteria translates into requiring the router that created the pseudo node to prune links between the pseudo-node and routers from which it didn't receive a Hello (or for which the Neighbor Liveness Timer expired). Morin & Cauchie Expires August 28, 2008 [Page 6] Internet-Draft Multicast blackhole mitigation February 2008 4.2.3. Prune links with no sent PIM Hello This consists in not including in the multicast topology, the links on which no PIM Hello was sent yet. This is particularly relevant during the randomized period of time between a Hello being received by a new neighbor and a triggered Hello being sent. 4.2.4. Other criteria Other criteria may be considered, like not including links the received PIM Hello would lack the indication of a required Hello option, or an unknown PIM protocol version, etc. 5. Alternative proposal An alternative mechanism to the one described in previous section would consist in using infinite metrics for a link until where PIM is enabled until the PIM adjacency is fully setup. This alternative has the advantage of not requiring the use of a multi-topology IGP (in the IGP case) or of SAFI 2 routing (in the EGP case), but has the drawback of impacting unicast traffic, causing perturbations of unicast routing during the period of time where the PIM adjacency is not fully setup yet. For this reason, this alternative is not favored and not described further in this document. 6. Interoperability considerations Both mechanisms described in this memo do not cause any interoperability issue. The decision to use or not use non-congruent unicast routing for multicast routing has to be made consistently across a routing domain, but the decision to apply or not apply the specific procedures described in this document, and the policy to decide whether or not a link will be used for multicast routing, can be a purely local procedure. The worst situation that could occur is not seeing any improvement over the initial situation where no specific procedure is used, and where blackholing of multicast traffic is more likely to occur. For these reason, this document is only intended as a guideline for implementors, and only target the informational status. Morin & Cauchie Expires August 28, 2008 [Page 7] Internet-Draft Multicast blackhole mitigation February 2008 7. Recommandations To prevent misconfiguration cases, it is RECOMMENDED to make procedures in 4.2.1 best practice (Prune links with no received PIM Hello from the multicast-RPF-specific unicast topology) when a non- congruent multicast routing technique is used. It is RECOMMENDED to make procedures in 4.2.2 and 4.2.3 best practice when a non-congruent multicast routing technique is used, if the plain PIM procedures of [RFC4601] for sending and receiving Hello are used by at least one router on the link, and they need not be used if improved Hello adjacency procedures, such as described in Section 3.3, are known to be used by all routers on a link. Updating [RFC4601] to improve the PIM adjacency setup time should strongly be considered. Logging is RECOMMENDED when a router choses to not include a link for multicast routing. Operator feedback through the router management interface is RECOMMENDED, both in the management interface section related to unicast protocols which are used to implement the non-congruency, and in the section related to PIM-SM. 8. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 9. Security Considerations The procedures in this document are believed to not introduce any specific issue introduced compared to multicast routing done with PIM-SM [RFC4601]. 10. Acknowledgements The authors want to thank Bruno Decraene and Toerless Eckert for discussions that helped to shape this proposal. Morin & Cauchie Expires August 28, 2008 [Page 8] Internet-Draft Multicast blackhole mitigation February 2008 11. References [I-D.acee-ospf-multi-instance] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Multi- Instance Extensions", draft-acee-ospf-multi-instance-01 (work in progress), February 2008. [I-D.ietf-isis-wg-multi-topology] Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in IS-IS", draft-ietf-isis-wg-multi-topology-12 (work in progress), November 2007. [I-D.ietf-l3vpn-2547bis-mcast-bgp] Aggarwal, R., "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-04 (work in progress), November 2007. [I-D.ietf-mpls-igp-sync] Jork, M., "LDP IGP Synchronization", draft-ietf-mpls-igp-sync-00 (work in progress), September 2007. [I-D.ietf-ospf-mt-ospfv3] Mirtorabi, S. and A. Roy, "Multi-topology routing in OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in progress), July 2007. [I-D.previdi-isis-mi] Previdi, S., "IS-IS Multi-instance", draft-previdi-isis-mi-00 (work in progress), May 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. Morin & Cauchie Expires August 28, 2008 [Page 9] Internet-Draft Multicast blackhole mitigation February 2008 Authors' Addresses Thomas Morin France Telecom - Orange Labs 2 avenue Pierre Marzin Lannion 22307 France Email: thomas.morin@orange-ftgroup.com Gregory Cauchie France Telecom - Orange Labs 38-40 rue du General Leclerc Issy Les Moulineaux 92794 France Email: gregory.cauchie@orange-ftgroup.com Morin & Cauchie Expires August 28, 2008 [Page 10] Internet-Draft Multicast blackhole mitigation February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Morin & Cauchie Expires August 28, 2008 [Page 11]