PIM Flooding Mechanism and Source Discovery Enhancements
draft-ietf-pim-pfm-forwarding-enhancements-08

Network Working Group                                           A. Gopal
Internet-Draft                                                 S. Venaas
Intended status: Experimental                        Cisco Systems, Inc.
Expires: 26 February 2027                                         F. Meo
                                                          25 August 2026

        PIM Flooding Mechanism and Source Discovery Enhancements
             draft-ietf-pim-pfm-forwarding-enhancements-08

Abstract

   The Protocol Independent Multicast (PIM) Flooding Mechanism (PFM) is
   an experimental extension that provides a generic hop-by-hop message
   exchange framework for distributing multicast information among PIM
   routers.  Existing PFM procedures enable efficient source discovery
   without reliance on Rendezvous Points, shared trees, or initial data
   registers.

   This document specifies further experimental enhancements to PFM
   forwarding behavior to improve efficiency and scalability.  In
   particular, it introduces mechanisms to reduce redundant message
   transmission over multiple parallel links and extends the encoding of
   multicast information through additional Type-Length-Value (TLV)
   structures and sub-TLVs to convey richer flow-related data.  These
   enhancements optimize control-plane overhead while preserving
   interoperability with existing PFM procedures, enabling more
   efficient dissemination of multicast state in PIM networks.

Status of This Memo

   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 26 February 2027.

Gopal, et al.           Expires 26 February 2027                [Page 1]
Internet-Draft         PIM Forwarding Enhancements           August 2026

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  PIM PFM Sub-TLV . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Group Source Info TLV . . . . . . . . . . . . . . . . . .   4
     2.2.  Group Source Info TLV Hello option  . . . . . . . . . . .   5
     2.3.  Considerations for using the Group Source Info TLV  . . .   6
   3.  PIM PFM forwarding optimization . . . . . . . . . . . . . . .   7
     3.1.  RFC 6395 Compliance . . . . . . . . . . . . . . . . . . .   7
     3.2.  PFM optimization Hello option . . . . . . . . . . . . . .   7
     3.3.  Sample PFM Topology . . . . . . . . . . . . . . . . . . .   8
     3.4.  PFM message handling with Relaxed-RPF enabled . . . . . .   8
     3.5.  Maintenance of PFM_OPT_IF . . . . . . . . . . . . . . . .   9
     3.6.  PFM message forwarding to sender  . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   PIM Flooding Mechanism [RFC8364] is an experimental extension that
   allows a PIM router in the network to originate a PFM message to
   distribute announcements of active sources to its PIM neighbors
   [RFC7761].  Each receiving PIM neighbor then processes the PFM
   message and forwards it further in accordance with RFC8364.  To
   prevent loops, the originator address as defined in Section 3.1
   [RFC8364] is used for Reverse Path Forwarding (RPF) checking at each
   router.  This RPF check is defined in Section 3.4.1 [RFC8364].
   Periodic PFM messages are exchanged to keep the multicast information
   updated across the PIM domain (Section 3.4.2 [RFC8364])

Gopal, et al.           Expires 26 February 2027                [Page 2]
Internet-Draft         PIM Forwarding Enhancements           August 2026

   The TLV defined in [RFC8364] for source discovery conveys only source
   and group information.  It does not provide a mechanism to include
   additional attributes describing a multicast flow.

   In addition, PFM messages are flooded on all PIM-enabled links.  When
   two routers maintain multiple PIM adjacencies, identical PFM messages
   are transmitted across each link.  Receivers perform RPF checks and
   discard duplicates as needed.  This behavior introduces unnecessary
   processing overhead, both periodically and upon source discovery.

   This document defines two further independent experimental
   enhancements to PFM message exchange:

   1.  A new TLV that supports Sub-TLVs, enabling the inclusion of
       additional flow-related information.  This enhancement is
       specified in Section 2.

   2.  An optimization for PFM message exchange across multiple PIM
       adjacencies between the same pair of routers.  By leveraging PIM
       Router-IDs [RFC6395], routers can identify such adjacencies and
       limit message transmission to a subset of links, reducing
       redundant processing.  This optimization applies to point-to-
       point links and does not alter behavior on shared LANs.  This
       enhancement is specified in Section 3.

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Terminology

   PFM-SD:  PIM Flooding Mechanism and Source-Discovery

   FHR:  First-Hop Router

   RPF:  Reverse Path Forwarding

   Relaxed-RPF:  A modified RPF validation procedure in which a router
      may accept a PFM message on an interface other than the single
      standard RPF interface when the PFM optimization conditions in
      this document are met.

   GSI:  Group Source Info

Gopal, et al.           Expires 26 February 2027                [Page 3]
Internet-Draft         PIM Forwarding Enhancements           August 2026

   GSH:  Group Source Holdtime

2.  PIM PFM Sub-TLV

   PFM-SD [RFC8364] defines a Group Source Holdtime (GSH) TLV for
   announcing active sources.  The GSH TLV conveys only source and group
   information.  This document defines an extension that allows PIM
   routers to exchange additional information associated with multicast
   sources.

2.1.  Group Source Info TLV

   This document defines a new GSI TLV (Type TBD1).  The GSI TLV is
   functionally similar to the GSH TLV but applies to a single (S,G)
   entry and supports the inclusion of Sub-TLVs to convey additional
   flow-specific information.  Support for the GSI TLV is advertised
   using a PIM Hello option (TBD2), as described in Section 2.2 If a
   router encounters a Sub-TLV type it does not recognize, it MUST
   ignore that Sub-TLV and continue processing the enclosing GSI TLV and
   any remaining Sub-TLVs.  An unrecognized Sub-TLV MUST NOT cause the
   router to discard the enclosing GSI TLV or the PFM message.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |T|         Type = TBD1         |          Length               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~             Group Address (Encoded-Group format)              ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~             Source Address (Encoded-Unicast format)           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Holdtime           |        Type Sub-TLV 1         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Length Sub-TLV 1        |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
    ~                         Value Sub-TLV 1                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                               ...                             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type Sub-TLV n         |       Length Sub-TLV n        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                          Value Sub-TLV n                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note: In the figure above, "~" denotes variable-length fields.

   The format of the GSI TLV is as follows:

Gopal, et al.           Expires 26 February 2027                [Page 4]
Internet-Draft         PIM Forwarding Enhancements           August 2026

   T-bit (1 bit):  As defined in [RFC8364].

   Type: (15 bits):  Set to TBD1.

   Length (16 bits):  The length, in octets, of the Value field
      including all the sub-TLVs.

   Group Address:  The multicast group address encoded as specified in
      Section 4.9.1 of [RFC7761].  The length of this field depends on
      the address family: 64 bits for IPv4 native encoding, 160 bits for
      IPv6.  Figure represents the IPv4 native encoding format.

   Source Address:  The unicast source address encoded as specified in
      Section 4.9.1 of [RFC7761].  The length of this field depends on
      the address family: 48 bits for IPv4 native encoding, 160 bits for
      IPv6.  Figure represents the IPv4 native encoding format.

   Holdtime (16 bits):  The lifetime, in seconds, for the advertised
      (S,G) information.

   Sub-TLVs:  Zero or more Sub-TLVs MAY be included.  Each Sub-TLV
      consists of:

      Type (16 bits):  The Sub-TLV Type.  Values for this field are
         assigned by IANA.

      Length (16 bits):  The length, in octets, of the Value field.  The
         length may be 0 if no value is present.

      Value:  The content of the Sub-TLV, whose format is determined by
         the Sub-TLV Type.

2.2.  Group Source Info TLV Hello option

   A PIM router indicates support for the GSI TLV defined in this
   document by including the Group Source Info TLV Hello option in PIM
   Hello messages.  The format of the Hello option is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OptionType = TBD2       |           Length = 0          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   OptionType (16 bits):  TBD2

   OptionLength (16 bits):  0

Gopal, et al.           Expires 26 February 2027                [Page 5]
Internet-Draft         PIM Forwarding Enhancements           August 2026

   The presence of this option signifies that the router supports the
   GSI TLV.

2.3.  Considerations for using the Group Source Info TLV

   Routers that support the GSI TLV and have GSI TLV usage enabled MUST
   track which neighbors advertise support for the GSI TLV via the Hello
   option (Section 2.2).  This tracking is beneficial in heterogeneous
   networks where only certain routers support the GSI TLV.  Routers
   that advertise support for the GSI TLV via the Hello option MUST use
   GSI TLVs by default when all neighbors on the outgoing interface
   support the GSI TLV.  An implementation MUST provide a configuration
   knob to disable GSI TLV usage; when disabled, the router MUST NOT
   advertise the Hello option and MUST NOT originate GSI TLVs.

   Operationally, enabling GSI TLV usage is justified when routers need
   to signal flow-specific attributes using Sub-TLVs and when peers on
   the path support the GSI TLV.  In mixed-capability or staged-
   deployment environments where such signaling is not required,
   operators can keep GSI TLV usage disabled and rely on GSH TLVs as
   specified in [RFC8364].

   Both the GSH TLV (defined in [RFC8364]) and the GSI TLV defined in
   this document can coexist in the same PFM message.  The GSH TLV
   remains available for backward compatibility and for cases where Sub-
   TLVs are not needed.  The GSI TLV is used when routers need to convey
   additional flow-specific information via Sub-TLVs.  When both GSH and
   GSI TLVs are present for the same (S,G), GSI takes precedence and GSH
   serves as fallback for neighbors that do not support the GSI TLV.

   When GSI TLV usage is enabled, a router that supports the GSI TLV:

   *  MUST advertise its capability by including the Hello option
      (OptionType TBD2) in PIM Hello messages.

   *  MUST track, per PIM interface, whether all neighbors support the
      GSI TLV.  The scope and persistence of this state are
      implementation-specific.  An implementation MAY retain this state
      for operational visibility even when GSI TLV usage is disabled.

   *  If acting as a First Hop Router (FHR), MUST originate a GSI TLV
      when all neighbors on the outgoing interface support the GSI TLV.

   *  If acting as an FHR, MUST originate a GSH TLV [RFC8364] when any
      neighbor on the outgoing interface does not support the GSI TLV.

   *  MUST forward the GSI TLV unchanged on interfaces where all
      neighbors support the GSI TLV.

Gopal, et al.           Expires 26 February 2027                [Page 6]
Internet-Draft         PIM Forwarding Enhancements           August 2026

   *  MUST convert each GSI TLV to a GSH TLV [RFC8364] where there are
      interfaces with at least one neighbor that does not support the
      GSI TLV, and forward the converted GSH TLVs only on those
      interfaces.  The conversion MUST preserve the group, source, and
      holdtime fields, and MUST ignore Sub-TLVs.  Multiple (S,G) entries
      for the same group SHOULD be aggregated into a single GSH TLV.
      This aggregation is RECOMMENDED and is not a mandatory compliance
      requirement.  However, it MUST still send GSI TLVs on all
      interfaces where the neighbors do support it.

3.  PIM PFM forwarding optimization

3.1.  RFC 6395 Compliance

   To apply the forwarding optimization defined in this document, PIM
   routers MUST advertise a Router-ID as specified in [RFC6395].  Within
   a PIM VRF, a router MUST use the same 4-octet Router-ID in PIM Hello
   messages on all interfaces and MUST cache Router-IDs learned from
   neighbors.  Within a PIM VRF, a router MUST identify interfaces with
   a single neighbor sharing the same Router-ID, indicating multiple
   adjacencies to that neighbor.  This identification is necessary for
   applying the forwarding optimization defined in this document.
   Router-IDs are assumed to be unique within the PIM domain.  If this
   assumption is violated, the optimization defined in this document
   cannot be applied.

3.2.  PFM optimization Hello option

   A PIM router indicates support for the forwarding optimization by
   including the PFM Optimization Hello option (OptionType TBD3) in PIM
   Hello messages.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OptionType = TBD3       |           Length = 0          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   OptionType (16 bits):  TBD3

   OptionLength (16 bits):  0

   A router that supports this optimization MUST track, per interface,
   whether all neighbors support the option.  This tracking is
   beneficial in heterogeneous networks where only certain routers
   support the optimization.

Gopal, et al.           Expires 26 February 2027                [Page 7]
Internet-Draft         PIM Forwarding Enhancements           August 2026

   For each learned Router-ID, the router MUST maintain a set of
   interfaces, denoted as PFM_OPT_IF, that satisfy both of the following
   conditions:

   *  The neighbor with this Router-ID is the sole PIM neighbor on this
      interface.

   *  The neighbor is advertising the PFM optimization option TBD3 on
      this interface.

   PFM message exchange MAY be optimized on interfaces in the PFM_OPT_IF
   set.  This is discussed in Section 3.4.

3.3.  Sample PFM Topology

                            Router C
                               |
                               | LAN 1
                               |
        Router A --------------------------------- Router B
           |                                          |
           |----------------- Link L1 ----------------|
           |                                          |
           |----------------- Link L2 ----------------|
           |                                          |
           |----------------- Link L3 ----------------|
           |__________________________________________|
                               |
                               | LAN 2
                               |
                            Router D

               Figure 1: Four Router Network Topology Example

   This figure is schematic and not intended to imply a specific
   physical layout.  It depicts two routers (A and B) connected by three
   parallel point-to-point links (L1, L2, L3), with shared LAN segments
   (LAN 1 and LAN 2) attached to Routers C and D.

3.4.  PFM message handling with Relaxed-RPF enabled

   When two routers maintain multiple adjacencies and are the only
   neighbors on those links, PFM messages are typically transmitted on
   all links and filtered by RPF checks at the receiver.  This results
   in redundant processing.  If both routers advertise Router-IDs and
   support the optimization, each router forms a PFM_OPT_IF set
   containing eligible interfaces.

Gopal, et al.           Expires 26 February 2027                [Page 8]
Internet-Draft         PIM Forwarding Enhancements           August 2026

   Implementations can experience transient states while link failures
   are being detected and propagated.  During such intervals, a PFM
   message sent on the selected interface can be lost or delayed if that
   interface fails before the sender updates its PFM_OPT_IF state.  This
   is not unique to the optimization in this document and can also occur
   in regular PFM operation when a message is sent on the selected RPF
   path and that path fails.  Implementations SHOULD apply robust and
   timely link-failure detection and update forwarding/interface-
   selection state promptly.  Even if one message is lost, subsequent
   periodic PFM messages refresh state.

   When Relaxed-RPF is enabled:

   *  A sender MUST select a single interface from its PFM_OPT_IF set
      for PFM transmission to that neighbor.  The selection method is
      implementation-specific.

   *  On shared LANs, the sender MUST send PFM messages as normal since
      optimization cannot be applied when there are more than two
      routers on the network segment.

   *  A receiver that supports Relaxed-RPF MUST:

      -  Determine the expected RPF interface using standard procedures.

      -  Accept a PFM message received on any interface in the
         PFM_OPT_IF set if both sender and receiver support the
         optimization.

      -  Otherwise, perform standard RPF validation.

   Referring to Figure 1, when Router A originates or forwards a PFM
   message, it transmits the message on one of links L1, L2, or L3.
   This behavior reduces processing overhead on point-to-point links.
   The selection of the interface from the PFM_OPT_IF set is
   implementation-specific.  Router A also sends the message on both LAN
   1 and LAN 2 so Routers C and D receive the message.

3.5.  Maintenance of PFM_OPT_IF

   Routers MUST update the PFM_OPT_IF set upon neighbor or capability
   changes:

Gopal, et al.           Expires 26 February 2027                [Page 9]
Internet-Draft         PIM Forwarding Enhancements           August 2026

   *  Neighbor Addition: If the new neighbor is the sole neighbor on the
      interface and advertises both a Router-ID and the optimization
      option, the interface MUST be added to the corresponding
      PFM_OPT_IF set.  If no set exists, it MUST be created.  If a
      second neighbor appears on the interface, the interface MUST be
      removed from the PFM_OPT_IF set.

   *  Neighbor Removal: After a neighbor removal event, if exactly one
      neighbor remains and it advertises both a Router-ID and the
      optimization option, the interface MUST be added to the PFM_OPT_IF
      set for that Router-ID.  If no set exists, it MUST be created.

   *  Router-ID Changes: If a neighbor starts advertising a Router-ID
      and satisfies all conditions, the interface MUST be added to the
      PFM_OPT_IF set.  If a neighbor stops advertising a Router-ID, the
      interface MUST be removed from the PFM_OPT_IF set for that Router-
      ID.  If the set becomes empty, it MUST be deleted.

   *  Optimization Capability Changes: If a neighbor starts advertising
      the optimization option and satisfies all conditions, the
      interface MUST be added to the PFM_OPT_IF set.  If a neighbor
      stops advertising the optimization option, the interface MUST be
      removed from the PFM_OPT_IF set for that Router-ID.  If the set
      becomes empty, it MUST be deleted.

   These procedures apply during topology changes, configuration
   updates, and software upgrades or downgrades.  Routers MUST maintain
   accurate PFM_OPT_IF state for each Router-ID.

3.6.  PFM message forwarding to sender

   When the TBD3 optimization is enabled on a PIM router, the router
   MUST NOT forward a PFM message on a link if both of the following
   conditions are true: (1) the link has only one neighbor, and (2) that
   neighbor's Router-ID matches the Router-ID of the router that
   originated the PFM message.  It is sufficient for the neighbor to
   advertise only the Router-ID, without any additional optimization
   options, since this information alone ensures the message is not sent
   back to its original sender, thereby reducing unnecessary PFM message
   forwarding.

Gopal, et al.           Expires 26 February 2027               [Page 10]
Internet-Draft         PIM Forwarding Enhancements           August 2026

4.  Security Considerations

   When it comes to general PIM message security, see [RFC7761].  For
   PFM security see [RFC8364].  This optimization relies on correct
   Router-ID and capability advertisement in PIM Hellos, as well as
   general PIM hello integrity.  For the new PFM TLV, the security
   considerations are the same as for the existing PFM TLV defined in
   [RFC8364].

5.  IANA Considerations

   All registries referenced in this section are under the "Protocol
   Independent Multicast (PIM) Parameters" registry group.

   This document requires the assignment of a new PFM TLV Type TBD1 in
   the "PIM Flooding Mechanism Message Types" registry.

           PIM Flooding Mechanism Message Types

         Type            Name           Reference
       -----------------------------------------------
         TBD1       Group Source Info   [This document]

   Also, a new registry "PIM Flooding Mechanism Group Source Info Sub-
   TLV Types" registry needs to be created.  Assignments for the new
   registry are to be made according to the policy "IETF Review" as
   defined in [RFC8126].  The initial content of the registry should be:

           PIM Flooding Mechanism
         Group Source Info Sub-TLV Types

         Type            Name           Reference
       -----------------------------------------------
           0-32767      Unassigned

   This document requires the assignment of two new PIM Hello Options:

                         PIM Hello Options

         Value   Length   Name              Reference
       --------------------------------------------------
         TBD2      0     GSI TLV support   [This document]
         TBD3      0     PFM Optimization  [This document]

Gopal, et al.           Expires 26 February 2027               [Page 11]
Internet-Draft         PIM Forwarding Enhancements           August 2026

6.  Acknowledgments

   The authors would like to acknowledge Carlos Pignataro, David Dong,
   Éric Vyncke, Gunter Van de Velde, Ketan Talaulikar, Mahesh
   Jethanandani, Mike McBride, Mohamed Boucadair, and Roman Danyliw for
   their feedback on this document.

7.  Normative References

   [RFC6395]  Gulrajani, S. and S. Venaas, "An Interface Identifier (ID)
              Hello Option for PIM", RFC 6395, DOI 10.17487/RFC6395,
              October 2011, <https://www.rfc-editor.org/info/rfc6395>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8364]  Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM
              Flooding Mechanism (PFM) and Source Discovery (SD)",
              RFC 8364, DOI 10.17487/RFC8364, March 2018,
              <https://www.rfc-editor.org/info/rfc8364>.

Authors' Addresses

   Ananya Gopal
   Cisco Systems, Inc.
   Tasman Drive
   San Jose,  CA 95134
   United States of America
   Email: ananygop@cisco.com

Gopal, et al.           Expires 26 February 2027               [Page 12]
Internet-Draft         PIM Forwarding Enhancements           August 2026

   Stig Venaas
   Cisco Systems, Inc.
   Tasman Drive
   San Jose,  CA 95134
   United States of America
   Email: svenaas@cisco.com

   Francesco Meo
   Email: fran.meo@gmail.com

Gopal, et al.           Expires 26 February 2027               [Page 13]