<?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="std"
     ipr="trust200902"
     docName="draft-mankamana-pim-source-fanout-trace-00">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>

  <front>
    <title abbrev="PIM Source Fanout Trace">PIM Source Fanout Trace for multicast flow</title>

    <author initials="M" surname="Mishra" fullname="Mankamana Mishra">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>821 Alder Drive</street>
          <region>Milpitas, CA 95035</region>
          <country>United States of America</country>
        </postal>
        <email>mankamis@cisco.com</email>
      </address>
    </author>

    <date year="2026" month="July" day="20"/>
    <area>Routing</area>
    <workgroup>PIM Working Group</workgroup>

    <abstract>
      <t>
        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.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Problem Statement">
      <t>
        <xref target="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.
      </t>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
    </section>

    <section title="Requirements Language">
      <t>To be added.</t>
    </section>

    <section title="Terminology">
      <t>To be added.</t>
    </section>

    <section title="Applicability">
      <t>To be added.</t>
    </section>

    <section title="Protocol Overview">
      <t>To be added.</t>
    </section>

    <section title="Capability Discovery">
      <t>To be added.</t>
    </section>

    <section title="PIM SFTrace Message">
      <t>To be added.</t>
    </section>

    <section title="SFTrace TLV Format">
      <t>To be added.</t>
    </section>

    <section title="Router Behavior">
      <t>To be added.</t>
    </section>

    <section title="Relationship to Mtrace2">
      <t>To be added.</t>
    </section>

    <section title="Security Considerations">
      <t>To be added.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>To be added.</t>
    </section>

    <section title="Open Issues">
      <t>To be added.</t>
    </section>

    <section title="Acknowledgements">
      <t>To be added.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8487.xml"/>
    </references>
  </back>
</rfc>
