TOC 
Network Working GroupT. Morin
Internet-DraftG. Cauchie
Intended status: InformationalFrance Telecom - Orange Labs
Expires: May 15, 2008November 12, 2007


Multicast blackhole mitigation with PIM adjacency conditions on routing announcements
draft-morin-mboned-mcast-blackhole-mitigation-00

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 May 15, 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 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].



Table of Contents

1.  Introduction
2.  Terminology
3.  Problem statement
    3.1.  Ineffective PIM Adjacency
    3.2.  Problem description
    3.3.  Applicability to SSM and non-SSM multicast
4.  PIM-adjacency-based non-congruent MRIB
    4.1.  Strategy description
    4.2.  Criterias
        4.2.1.  Prune links on which PIM is not enabled
        4.2.2.  Prune links with no received PIM Hello
        4.2.3.  Prune links with no sent PIM Hello
        4.2.4.  Other criteria
5.  Alternative proposal
6.  Interoperability considerations
7.  Recommandations
8.  IANA Considerations
9.  Security Considerations
10.  Acknowledgements
11.  References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

In a network running PIM-SM (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) [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 (Problem statement) describes the problem statement, and following Section 4 (PIM-adjacency-based non-congruent MRIB) and Section 5 (Alternative proposal) describe possible solutions to mitigate theses blackholes.



 TOC 

2.  Terminology

This document is essentially using terminology from unicast routing protocols and from the PIM-SM specifications (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) [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 (Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” October 2005.) [I‑D.ietf‑isis‑wg‑multi‑topology], MI-ISIS (Previdi, S., “IS-IS Multi-instance,” May 2007.) [I‑D.previdi‑isis‑mi], MT-OSPFv2 (Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, “Multi-Topology (MT) Routing in OSPF,” June 2007.) [RFC4915], MT-OSPFv3 (Mirtorabi, S. and A. Roy, “Multi-topology routing in OSPFv3 (MT-OSPFv3),” July 2007.) [I‑D.ietf‑ospf‑mt‑ospfv3], MI-OSPF (Lindem, A., “OSPF Multi-Instance Extensions,” September 2007.) [I‑D.acee‑ospf‑multi‑instance].



 TOC 

3.  Problem statement



 TOC 

3.1.  Ineffective PIM Adjacency

In a number of situations a link status can be up without the PIM adjacency to be fully setup. Possible causes for this kind of situations are :

On this last point, note that it seems that [RFC4601] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) 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] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) are so that it can take up to <Triggered_Hello_Delay> 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] (Jork, M., “LDP IGP Synchronization,” September 2007.).



 TOC 

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:

Partial solutions to the issues presented above do exist based on implementation or unicast routing tuning, but fail to cover all plausible blackhole causes.



 TOC 

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



 TOC 

4.  PIM-adjacency-based non-congruent MRIB



 TOC 

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 (Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” October 2005.) [I‑D.ietf‑isis‑wg‑multi‑topology], MI-ISIS (Previdi, S., “IS-IS Multi-instance,” May 2007.) [I‑D.previdi‑isis‑mi], MT-OSPF (Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, “Multi-Topology (MT) Routing in OSPF,” June 2007.) [RFC4915], MP-BGP SAFI 2 (Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4,” January 2007.) [RFC4760], MP-BGP SAFI 129 VPNv4 routes (Aggarwal, R., “BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs,” July 2007.) [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 adjcencies. 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. To do this, a router would keep an adjacent link out of the multicast-specific routing topology until the PIM status on this link is ok:

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.

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.



 TOC 

4.2.2.1.  IGP on LAN specific case

In the case of an IGP on a LAN the "prune links with no received PIM Hello" criteria need to be further specified.

Indeed, 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.

[TBC]



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

7.  Recommandations

[ To be completed based on discussion on the above.]

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.



 TOC 

8.  IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.



 TOC 

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 (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) [RFC4601].



 TOC 

10.  Acknowledgements

The authors want to thank Bruno Decraene and Toerless Eckert for discussions that helped to shape this proposal.



 TOC 

11.  References

[I-D.acee-ospf-multi-instance] Lindem, A., “OSPF Multi-Instance Extensions,” draft-acee-ospf-multi-instance-00 (work in progress), September 2007 (TXT).
[I-D.ietf-isis-wg-multi-topology] Przygienda, T., “M-ISIS: Multi Topology (MT) Routing in IS-IS,” draft-ietf-isis-wg-multi-topology-11 (work in progress), October 2005 (TXT).
[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-03 (work in progress), July 2007 (TXT).
[I-D.ietf-mpls-igp-sync] Jork, M., “LDP IGP Synchronization,” draft-ietf-mpls-igp-sync-00 (work in progress), September 2007 (TXT).
[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 (TXT).
[I-D.previdi-isis-mi] Previdi, S., “IS-IS Multi-instance,” draft-previdi-isis-mi-00 (work in progress), May 2007 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” RFC 4601, August 2006 (TXT).
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4,” RFC 4760, January 2007 (TXT).
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, “Multi-Topology (MT) Routing in OSPF,” RFC 4915, June 2007 (TXT).


 TOC 

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 Gnral Leclerc
  Issy Les Moulineaux 92794
  France
Email:  gregory.cauchie@orange-ftgroup.com


 TOC 

Full Copyright Statement

Intellectual Property