| Internet-Draft | PIM Source Fanout Trace | July 2026 |
| Mishra | Expires 21 January 2027 | [Page] |
Mtrace version 2 traces an IP multicast path by walking from a last-hop router or rendezvous point toward the source. That model is efficient for a single receiver path, but it does not directly answer the operational question of where a multicast source fans out downstream without issuing separate traces from many receiver-side locations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 21 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC8487] defines Mtrace version 2 (Mtrace2), which allows a multicast path to be traced by starting at a Last-Hop Router (LHR) or Rendezvous Point (RP) and walking upstream toward the source. This receiver-to-source model is useful for diagnosing a single receiver path, but it does not directly provide source-rooted visibility into the downstream multicast fanout tree.¶
Operationally, there are cases where an operator needs to start from the source side and discover the downstream fanout for an exact multicast flow. Examples include finding all receiver branches for a high-rate IPTV flow, identifying the branch where forwarding stops, or validating whether a source-rooted tree reaches all expected receiver edges. With only the receiver-to-source model, the operator must know candidate receivers or last-hop routers in advance and issue many separate traces. This is inefficient and can miss branches that are unknown to the operator.¶
This limitation also affects automated tree health monitoring. If an operator wants to continuously probe the health of a multicast tree, an Mtrace2-only approach requires originating one or more receiver-side probes for each candidate branch during every polling interval. As the number of sources, groups, receivers, VRFs, and polling frequency grow, this can result in N probes every T seconds, with each probe requiring control-plane processing on routers along the traced path. Repeated per-branch probing can therefore become CPU intensive and does not scale as a general mechanism for monitoring whole-tree health.¶
A source-to-receiver fanout tracing mechanism is therefore needed to complement Mtrace2 by allowing an operator to discover downstream forwarding branches, termination points, and failure points for an exact multicast flow from the source-side root. The desired approach is one where a single source-rooted probe can provide enough information about the downstream tree to identify reachable branches and failure points, while reducing the amount of repeated control-plane work required from the network.¶
To be added.¶
To be added.¶
To be added.¶
To be added.¶
To be added.¶
To be added.¶
To be added.¶
To be added.¶
To be added.¶
To be added.¶
To be added.¶
To be added.¶
To be added.¶