<?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-discovery-00">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>

  <front>
    <title abbrev="PIM Source Discovery">PIM Source Discovery for ASM Deployments</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>
        This document discusses the operational challenges of Any-Source
        Multicast deployments that use PIM Sparse Mode and explores whether
        PIM extensions can simplify source discovery and operational behavior
        while preserving the host-facing ASM service model.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Problem Statement">
      <t>
        <xref target="RFC7761"/> defines Protocol Independent Multicast -
        Sparse Mode (PIM-SM).  PIM-SM supports the Any-Source Multicast (ASM)
        service model by building shared trees rooted at a Rendezvous Point
        (RP) for multicast groups, and by optionally switching to source trees
        after sources are discovered.
      </t>
      <t>
        ASM has been widely deployed in operational networks.  In many
        deployments, especially IPTV deployments, the ASM service model is not
        only a network design choice but also part of the host and application
        behavior.  A network operator cannot always remove ASM simply by
        changing the network.  Moving away from ASM may require changes on
        receivers, applications, middleware, or customer premises devices.  In
        IPTV networks, the number of set-top boxes can be in the millions, so
        requiring all end hosts to be upgraded or replaced is often not
        operationally practical.
      </t>
      <t>
        The PIM architecture defines the RP as the point where receivers and
        sources meet in the ASM model.  Multiple mechanisms have been specified
        or deployed to configure or discover the RP, including static
        configuration and dynamic discovery mechanisms.  In addition, MSDP
        <xref target="RFC3618"/> has been defined to support source discovery
        across PIM-SM domains, allowing RPs in different domains to advertise
        active sources to one another.  These mechanisms solve important parts
        of the ASM problem space, but they also add operational dependencies
        around RP placement, RP discovery, inter-domain source discovery,
        filtering policy, scaling, and troubleshooting.
      </t>
      <t>
        As a result, the overall ASM deployment experience can become difficult
        for operators.  The network may need to maintain RP state, source
        registration behavior, RP discovery behavior, MSDP peering and policy,
        and multicast forwarding state across many groups, sources, domains,
        and administrative boundaries.  When service behavior is incorrect, the
        operator often has to reason across several control-plane mechanisms
        before determining whether the issue is host signaling, RP discovery,
        source registration, MSDP source advertisement, PIM Join/Prune state,
        or multicast forwarding.
      </t>
      <t>
        There is therefore a need to explore whether the ASM deployment
        experience can be simplified without requiring a disruptive migration
        of existing end hosts away from ASM.  This document is intended to
        examine possible PIM extensions that can improve source discovery and
        operational behavior while preserving compatibility with deployed ASM
        host behavior.
      </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 Source Discovery Extensions">
      <t>To be added.</t>
    </section>

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

    <section title="Relationship to Existing ASM Mechanisms">
      <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.7761.xml"/>
    </references>
    <references title="Informative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3618.xml"/>
    </references>
  </back>
</rfc>
