<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-pim-light-11" number="9739" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2025-03-04T15:44:00" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-pim-light-11" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9739" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="PIM Light">Protocol Independent Multicast Light (PIM Light)</title>
    <seriesInfo name="RFC" value="9739" stream="IETF"/>
    <author fullname="Hooman Bidgoli" initials="H" role="editor" surname="Bidgoli">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <postal>
          <street>March Road</street>
          <city>Ottawa</city>
          <region>Ontario</region>
          <code>K2K 2T6</code>
          <country>Canada</country>
        </postal>
        <email>hooman.bidgoli@nokia.com</email>
      </address>
    </author>
    <author fullname="Stig Venaas" initials="S." surname="Venaas">
      <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Tasman Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>stig@cisco.com</email>
      </address>
    </author>
    <author fullname="Mankamana Mishra" initials="M." surname="Mishra">
      <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Tasman Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>United States of America</country>
        </postal>
        <email>mankamis@cisco.com</email>
      </address>
    </author>
    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization showOnFrontPage="true">Juniper Networks</organization>
      <address>
        <postal>
          <city>Boston</city>
          <region>MA</region>
          <country>United States of America</country>
        </postal>
        <email>zzhang@juniper.net</email>
      </address>
    </author>
    <author fullname="Mike McBride" initials="M." surname="McBride">
      <organization showOnFrontPage="true">Futurewei Technologies Inc.</organization>
      <address>
        <postal>
          <city>Santa Clara</city>
          <region>CA</region>
          <country>United States of America</country>
        </postal>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>RTG</area>
    <workgroup>pim</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document specifies Protocol Independent Multicast Light (PIM
      Light) and the PIM Light Interface (PLI). A PLI does not need a PIM
      Hello message to accept PIM Join/Prune messages, and it can signal
      multicast states over networks that cannot support full PIM neighbor
      discovery, such as Bit Index Explicit Replication (BIER) networks that
      connect two or more PIM domains.  This document outlines the PIM Light
      protocol and procedures to ensure loop-free multicast traffic between
      two or more PIM Light routers.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9739" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pim-light-interface">PIM Light Interface</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-message-types-supported-by-">Message Types Supported by PIM Light</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-considerations-for-the-abse">Considerations for the Absence of Hello Message</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-join-attribute">Join Attribute</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dr-election">DR Election</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.3.1"><xref derivedContent="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pim-assert">PIM Assert</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pli-configuration">PLI Configuration</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-failures-in-plr-domain">Failures in PLR Domain</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reliable-transport-mechanis">Reliable Transport Mechanism for PIM Light</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pim-variants-not-supported">PIM Variants Not Supported</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document specifies procedures for Protocol Independent Multicast Light (PIM
      Light) and the PIM Light Interface (PLI). The PLI is a new type of
      PIM interface that allows signaling of PIM Join/Prune packets without
      full PIM neighbor discovery. A PLI is useful in scenarios where multicast
      states need to be signaled over networks or media that cannot support
      full PIM neighborship between routers or, alternatively,  where full PIM
      neighborship is not desired. These types of networks and media are
      called "PIM Light domains" within this document. Lack of full PIM
      neighborship will remove some PIM functionality as explained in <xref target="absence-hello" format="default" sectionFormat="of" derivedContent="Section 3.2"/> of this document. PIM Light only supports the PIM - Sparse Mode (PIM-SM) protocol, including PIM Source-Specific
      Multicast (PIM-SSM), as per <xref target="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/>. This document
      details procedures and considerations needed for PIM Light and the PLI to
      ensure efficient routing of multicast groups for specific deployment
      environments.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">

    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.

      </t>
      <t indent="0" pn="section-2-2">This document uses terminology from "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)" <xref target="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/>.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-pim-light-interface">PIM Light Interface</name>
      <t indent="0" pn="section-3-1"><xref section="4.3.1" sectionFormat="of" target="RFC7761" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#section-4.3.1" derivedContent="RFC7761"/> describes PIM neighbor
      discovery via Hello messages. <xref section="4.5" sectionFormat="of" target="RFC7761" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#section-4.5" derivedContent="RFC7761"/> notes that if a
      router receives a Join/Prune message from a particular IP source address
      and it has not seen a PIM Hello message from that source address, then
      the Join/Prune message <bcp14>SHOULD</bcp14> be discarded without further
      processing.</t>
      <t indent="0" pn="section-3-2">In certain scenarios, it is desirable to establish multicast states
      between two routers without forming a PIM neighborship.
      This can be necessary for various reasons, such as signaling multicast
      states upstream between multiple PIM domains over a network that is not
      optimized for PIM or that does not necessitate PIM neighbor establishment.
      An example is a Bit Index Explicit Replication (BIER) <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/> network connecting multiple PIM domains, where PIM
      Join/Prune messages are tunneled via BIER as specified in <xref target="I-D.ietf-bier-pim-signaling" format="default" sectionFormat="of" derivedContent="BIER-PIM"/>.</t>
      <t indent="0" pn="section-3-3">A PLI accepts Join/Prune messages from an
      unknown PIM router without requiring a PIM Hello message from the
      router. The absence of Hello messages on a PLI means there is no
      mechanism to discover neighboring PIM routers or their capabilities or
      to execute basic algorithms such as Designated Router (DR) election
      <xref target="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/>. Consequently, the PIM Light router does not
      create any general-purpose state for neighboring PIM routers and only
      processes Join/Prune messages from downstream routers in its multicast
      routing table. Processing these Join/Prune messages will introduce
      multicast states in a PIM Light router.</t>
      <t indent="0" pn="section-3-4">Due to these constraints, a PLI should be deployed in very specific
      scenarios where PIM-SM is not suitable. The applications or the networks
      on which PLIs are deployed <bcp14>MUST</bcp14> ensure that there is no
      multicast packet duplication, such as multiple upstream routers sending
      the same multicast stream to a single downstream router. For example,
      an implementation should ensure that DR election is done on upstream
      redundant PIM routers that are at the edge of the PIM Light domain to
      ensure that a single DR forwards the PIM Join message from the receiver
      to the source.
      </t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-message-types-supported-by-">Message Types Supported by PIM Light</name>
        <t indent="0" pn="section-3.1-1">The "PIM Message Types" registry <xref target="IANA-PIM-Mess-Types" format="default" sectionFormat="of" derivedContent="IANA-PIM-Mess-Types"/> lists the
        message types supported by PIM. PIM Light only supports the following
        message types in that registry:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.1-2">
          <li pn="section-3.1-2.1">
            <t indent="0" pn="section-3.1-2.1.1">type 1 (Register)</t>
          </li>
          <li pn="section-3.1-2.2">
            <t indent="0" pn="section-3.1-2.2.1">type 2 (Register Stop)</t>
          </li>
          <li pn="section-3.1-2.3">
            <t indent="0" pn="section-3.1-2.3.1">type 3 (Join/Prune)
            </t>
          </li>
          <li pn="section-3.1-2.4">
            <t indent="0" pn="section-3.1-2.4.1">type 8 (Candidate RP Advertisement)</t>
          </li>
          <li pn="section-3.1-2.5">
            <t indent="0" pn="section-3.1-2.5.1">type 13.0 (PIM Packed Null-Register)</t>
          </li>
          <li pn="section-3.1-2.6">
            <t indent="0" pn="section-3.1-2.6.1">type 13.1 (PIM Packed Register-Stop)</t>
          </li>
          <li pn="section-3.1-2.7">
            <t indent="0" pn="section-3.1-2.7.1">Any future PIM message types where the destination is a unicast IP address
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-3.1-3">No other message types are supported by PIM Light; other message types <bcp14>MUST NOT</bcp14> be processed if received on a PLI.</t>
      </section>
      <section numbered="true" toc="include" anchor="absence-hello" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-considerations-for-the-abse">Considerations for the Absence of Hello Message</name>
        <t indent="0" pn="section-3.2-1">Because Hello messages are not processed in a PIM Light domain, the
considerations in the subsections below should be taken into account.
</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-join-attribute">Join Attribute</name>
          <t indent="0" pn="section-3.2.1-1">Since a PLI does not use PIM Hello messages, it also does not
          support the Join Attribute option in PIM Hello as specified in
          <xref target="RFC5384" format="default" sectionFormat="of" derivedContent="RFC5384"/>. As such, PIM Light is unaware of its
          neighbor's capability to process Join Attributes and <bcp14>SHOULD NOT</bcp14>
          send a Join message containing a Join Attribute.</t>
          <t indent="0" pn="section-3.2.1-2">There are two cases in which a PLI can support a Join Attribute:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.1-3">
            <li pn="section-3.2.1-3.1">
              <t indent="0" pn="section-3.2.1-3.1.1">The neighbors on the PLI are known via
          configuration to be capable of processing the attribute.</t>
            </li>
            <li pn="section-3.2.1-3.2">
              <t indent="0" pn="section-3.2.1-3.2.1">Internet-Drafts and RFCs may dictate that certain Join
              Attributes are allowed to be used without explicit configuration
              of the PLI in certain scenarios. The details are left to those
              Internet-Drafts and RFCs.</t>
            </li>
          </ul>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2.2">
          <name slugifiedName="name-dr-election">DR Election</name>
          <t indent="0" pn="section-3.2.2-1">Due to the absence of Hello messages, DR election is not
          supported on a PIM Light router. The network design must ensure DR
          election occurs within the PIM domain, assuming the PIM Light domain
          interconnects PIM domains.</t>
          <t indent="0" pn="section-3.2.2-2">For instance, in a BIER domain connecting two PIM domains as in the figure below, a PLI
          can be used between BIER edge routers solely for multicast state
          communication and transmit only PIM Join/Prune messages.

  If there are redundant PIM routers at the edge of the BIER domain, they
  <bcp14>MUST</bcp14> establish PIM adjacency as per <xref target="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/> to prevent multicast stream duplication and to ensure DR
  election at the edge of the BIER domain.

	  For example, DR election
          could be between router D and F in the figure below.  When the Join
          or Prune message arrives from a PIM domain to the downstream BIER
          edge router, it can be forwarded over the BIER tunnel to the
          upstream BIER edge router only via the DR.</t>
          <artwork name="" type="" align="left" alt="" pn="section-3.2.2-3">
                   Bier edge router       Bier edge router 
          |--PIM domain--|--BIER domain (PLI)--|--PIM domain--| 
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--Host
          |       PIM Adj|         | |         |PIM Adj       |
          |------------( E )-------| |-------( F )------------|
                                         (DR election)
</artwork>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2.3">
          <name slugifiedName="name-pim-assert">PIM Assert</name>
          <t indent="0" pn="section-3.2.3-1">In scenarios where multiple PIM routers peer over a shared LAN or
          a point-to-multipoint medium, more than one upstream router may have
          valid forwarding state for a packet, which can potentially cause packet
          duplication. PIM Assert is used to select a single transmitter when
          such duplication is detected. According to <xref section="4.6" sectionFormat="of" target="RFC7761" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#section-4.6" derivedContent="RFC7761"/>, PIM Assert should only be accepted from a known PIM
          neighbor.</t>
          <t indent="0" pn="section-3.2.3-2">In PIM Light implementations, care must be taken to avoid
          duplicate streams arriving from multiple upstream PIM Light routers
          to a single downstream PIM Light router. If network design
          constraints prevent this, the implemented network architecture must
          take measures to avoid traffic duplication. For example, in a scenario with PIM
          Light over a BIER domain, a downstream IBBR (Ingress BIER
          Border Router) in a BIER domain can identify the nearest EBBRs
          (Egress BIER Border Routers) to the source using the Shortest Path
          First (SPF) algorithm with post-processing as described in Appendix A.1 of <xref target="I-D.ietf-bier-pim-signaling" format="default" sectionFormat="of" derivedContent="BIER-PIM"/>. If the
          downstream IBBR identifies two EBBRs, it can select one using a
          unique IP selection algorithm, such as choosing the EBBR with the
          lowest or highest IP address. If the selected EBBR goes offline, the
          downstream router can use the next EBBR based on the IP selection
          algorithm, which is beyond the scope of this document.</t>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-pli-configuration">PLI Configuration</name>
        <t indent="0" pn="section-3.3-1">Since a PLI doesn't require PIM Hello Messages and PIM neighbor
        adjacency is not checked for arriving Join/Prune messages, there needs
        to be a mechanism to enable PLIs on interfaces.
	Join/Prune messages not received from a PIM neighbor
	<bcp14>MUST</bcp14> be dropped unless PLI is enabled on the interface.
	In some cases, a PLI may be enabled
        automatically via an underlying mechanism on a logical interface. For
        example, in a BIER domain, a logical interface can connect two or more
        BIER edge routers as per <xref target="I-D.ietf-bier-pim-signaling" format="default" sectionFormat="of" derivedContent="BIER-PIM"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-failures-in-plr-domain">Failures in PLR Domain</name>
        <t indent="0" pn="section-3.4-1">Because Hello messages are not processed on the PLI, PLI
        failures may not be discovered in a PIM Light domain, and
        multicast routes will not be pruned toward the source on the PIM Light
        domain. This results in the upstream routers continuously sending multicast
        streams until the outgoing interface (OIF) expires.</t>
        <t indent="0" pn="section-3.4-2">Other protocols can be used to detect these failures in the PIM
        Light domain, and they can be implementation specific. As an example,
        the interface on which PIM Light is configured can be protected via
        Bidirectional Forwarding Detection (BFD) or similar technology. If BFD
        to the far-end PLI goes down and the PIM Light router is upstream and
        has an OIF for a multicast route (S,G), PIM must remove that PLI
        from its OIF list.</t>
        <t indent="0" pn="section-3.4-3">In another example, the PLI is configured automatically
        between the BIER Edge Routers (BERs) as in the figure below. When the Downstream BIER Edge
        Router (DBER) is no longer reachable on the Upstream BIER Edge Router
        (UBER), the UBER (which is also a PIM Light router) can prune the
        (S,G) advertised toward the source on the PIM domain to stop the
        transmission of the multicast stream.</t>
        <artwork name="" type="" align="left" alt="" pn="section-3.4-4">
                        UBER                 DBER 
          |--PIM domain--|--BIER domain (PLI)--|--PIM domain--| 
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--Host
                 &lt;--Prune (S,G)          &lt;failure on D&gt;
</artwork>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.5">
        <name slugifiedName="name-reliable-transport-mechanis">Reliable Transport Mechanism for PIM Light</name>
        <t indent="0" pn="section-3.5-1"><xref target="RFC6559" format="default" sectionFormat="of" derivedContent="RFC6559"/> defines a reliable transport mechanism called 
	PIM Over Reliable Transport (PORT) for PIM transmission of Join/Prune messages,
	using either TCP or SCTP as the transport protocol. Both TCP and SCTP use
	destination port number 8471. SCTP is explained in <xref target="RFC9260" format="default" sectionFormat="of" derivedContent="RFC9260"/> and
	is used as a second option for PORT. <xref target="RFC6559" format="default" sectionFormat="of" derivedContent="RFC6559"/> mentions that when
	a router is configured to use PIM over TCP on a given interface, it
	<bcp14>MUST</bcp14> include the PIM-over-TCP-Capable Hello Option in its Hello
	messages for that interface.  The same is true for SCTP; the router
	<bcp14>MUST</bcp14> include the PIM-over-SCTP-Capable Hello Option in its Hello messages
	on that interface.
        </t>
        <t indent="0" pn="section-3.5-2">These Hello options contain a Connection ID, which is an IPv4 or
        IPv6 address used to establish the SCTP or TCP connection.  For PORT
        using TCP, the Connection ID is used to determine which peer is
        doing an active transport open to the neighbor and which peer is doing
        passive transport open, as per <xref section="4" sectionFormat="of" target="RFC6559" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6559#section-4" derivedContent="RFC6559"/>.

	When the router is using SCTP, the Connection ID is not used to
	determine the active and passive peer since SCTP can handle call
	collision.
        </t>
        <t indent="0" pn="section-3.5-3">Because PIM Light lacks Hello messages, the PLI can be configured with the
        Connection ID (i.e., the IPv4 or IPv6 address used to establish the SCTP or TCP
        connection). For PIM Light using the TCP PORT option, each end of the PLI
        must be explicitly and correctly configured as being either active transport
        open or passive transport open to ensure that call collision is
        avoided.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.6">
        <name slugifiedName="name-pim-variants-not-supported">PIM Variants Not Supported</name>
        <t indent="0" pn="section-3.6-1">The following PIM variants are not supported with PIM Light and not
        covered by this document:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.6-2">
          <li pn="section-3.6-2.1">
            <t indent="0" pn="section-3.6-2.1.1">PIM - Dense Mode (PIM-DM) <xref target="RFC3973" format="default" sectionFormat="of" derivedContent="RFC3973"/></t>
          </li>
          <li pn="section-3.6-2.2">
            <t indent="0" pn="section-3.6-2.2.1">Bidirectional PIM (BIDIR-PIM) <xref target="RFC5015" format="default" sectionFormat="of" derivedContent="RFC5015"/></t>
          </li>
        </ul>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">This document has no IANA actions.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">Since PIM Light does not require PIM Hello messages and does not
      verify PIM neighbor adjacency for incoming Join/Prune messages, for security reasons, it is
      crucial that implementations ensure that only
      Join/Prune messages arriving at a configured PLI are processed. Any
      Join/Prune messages received on an interface that is not configured as a
      PLI <bcp14>MUST</bcp14> be discarded and not processed. Additionally, as a secondary
      line of defense, route policies <bcp14>SHOULD</bcp14> be implemented to process only
      the Join/Prune messages associated with the desired (S,G) pairs, while
      all other (S,G) pairs <bcp14>MUST</bcp14> be discarded and not processed.</t>
      <t indent="0" pn="section-5-2">Furthermore, because PIM Light can be used for signaling
      PIM-SM Join/Prune messages, the security considerations outlined in
      <xref target="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/> and <xref target="RFC4607" format="default" sectionFormat="of" derivedContent="RFC4607"/> <bcp14>SHOULD</bcp14> be considered where
      appropriate.</t>
      <t indent="0" pn="section-5-3">Per <xref section="6.1.1" sectionFormat="of" target="RFC7761" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#section-6.1.1" derivedContent="RFC7761"/>, only forged Join/Prune
      messages should be considered as a potential attack vector, as PIM Light
      does not process Hello or Assert messages. In addition, as detailed in <xref section="6.3" sectionFormat="of" target="RFC7761" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#section-6.3" derivedContent="RFC7761"/>, the authentication mechanisms described in <xref target="RFC5796" format="default" sectionFormat="of" derivedContent="RFC5796"/> can be applied to PIM Light via IPsec Encapsulating
      Security Payload (ESP) or, optionally, the Authentication Header
      (AH).</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-bier-pim-signaling" to="BIER-PIM"/>
    <references pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="IANA-PIM-Mess-Types" target="https://www.iana.org/assignments/pim-parameters" quoteTitle="true" derivedAnchor="IANA-PIM-Mess-Types">
          <front>
            <title>PIM Message Types</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC4607" target="https://www.rfc-editor.org/info/rfc4607" quoteTitle="true" derivedAnchor="RFC4607">
          <front>
            <title>Source-Specific Multicast for IP</title>
            <author fullname="H. Holbrook" initials="H." surname="Holbrook"/>
            <author fullname="B. Cain" initials="B." surname="Cain"/>
            <date month="August" year="2006"/>
            <abstract>
              <t indent="0">IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4607"/>
          <seriesInfo name="DOI" value="10.17487/RFC4607"/>
        </reference>
        <reference anchor="RFC5015" target="https://www.rfc-editor.org/info/rfc5015" quoteTitle="true" derivedAnchor="RFC5015">
          <front>
            <title>Bidirectional Protocol Independent Multicast (BIDIR-PIM)</title>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="I. Kouvelas" initials="I." surname="Kouvelas"/>
            <author fullname="T. Speakman" initials="T." surname="Speakman"/>
            <author fullname="L. Vicisano" initials="L." surname="Vicisano"/>
            <date month="October" year="2007"/>
            <abstract>
              <t indent="0">This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5015"/>
          <seriesInfo name="DOI" value="10.17487/RFC5015"/>
        </reference>
        <reference anchor="RFC5384" target="https://www.rfc-editor.org/info/rfc5384" quoteTitle="true" derivedAnchor="RFC5384">
          <front>
            <title>The Protocol Independent Multicast (PIM) Join Attribute Format</title>
            <author fullname="A. Boers" initials="A." surname="Boers"/>
            <author fullname="I. Wijnands" initials="I." surname="Wijnands"/>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <date month="November" year="2008"/>
            <abstract>
              <t indent="0">A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5384"/>
          <seriesInfo name="DOI" value="10.17487/RFC5384"/>
        </reference>
        <reference anchor="RFC5796" target="https://www.rfc-editor.org/info/rfc5796" quoteTitle="true" derivedAnchor="RFC5796">
          <front>
            <title>Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages</title>
            <author fullname="W. Atwood" initials="W." surname="Atwood"/>
            <author fullname="S. Islam" initials="S." surname="Islam"/>
            <author fullname="M. Siami" initials="M." surname="Siami"/>
            <date month="March" year="2010"/>
            <abstract>
              <t indent="0">RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5796"/>
          <seriesInfo name="DOI" value="10.17487/RFC5796"/>
        </reference>
        <reference anchor="RFC6559" target="https://www.rfc-editor.org/info/rfc6559" quoteTitle="true" derivedAnchor="RFC6559">
          <front>
            <title>A Reliable Transport Mechanism for PIM</title>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="IJ. Wijnands" initials="IJ." surname="Wijnands"/>
            <author fullname="S. Venaas" initials="S." surname="Venaas"/>
            <author fullname="M. Napierala" initials="M." surname="Napierala"/>
            <date month="March" year="2012"/>
            <abstract>
              <t indent="0">This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6559"/>
          <seriesInfo name="DOI" value="10.17487/RFC6559"/>
        </reference>
        <reference anchor="RFC7761" target="https://www.rfc-editor.org/info/rfc7761" quoteTitle="true" derivedAnchor="RFC7761">
          <front>
            <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
            <author fullname="B. Fenner" initials="B." surname="Fenner"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="H. Holbrook" initials="H." surname="Holbrook"/>
            <author fullname="I. Kouvelas" initials="I." surname="Kouvelas"/>
            <author fullname="R. Parekh" initials="R." surname="Parekh"/>
            <author fullname="Z. Zhang" initials="Z." surname="Zhang"/>
            <author fullname="L. Zheng" initials="L." surname="Zheng"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.</t>
              <t indent="0">This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="83"/>
          <seriesInfo name="RFC" value="7761"/>
          <seriesInfo name="DOI" value="10.17487/RFC7761"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8279" target="https://www.rfc-editor.org/info/rfc8279" quoteTitle="true" derivedAnchor="RFC8279">
          <front>
            <title>Multicast Using Bit Index Explicit Replication (BIER)</title>
            <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="A. Dolganow" initials="A." surname="Dolganow"/>
            <author fullname="T. Przygienda" initials="T." surname="Przygienda"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <date month="November" year="2017"/>
            <abstract>
              <t indent="0">This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8279"/>
          <seriesInfo name="DOI" value="10.17487/RFC8279"/>
        </reference>
        <reference anchor="RFC9260" target="https://www.rfc-editor.org/info/rfc9260" quoteTitle="true" derivedAnchor="RFC9260">
          <front>
            <title>Stream Control Transmission Protocol</title>
            <author fullname="R. Stewart" initials="R." surname="Stewart"/>
            <author fullname="M. Tüxen" initials="M." surname="Tüxen"/>
            <author fullname="K. Nielsen" initials="K." surname="Nielsen"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.</t>
              <t indent="0">SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC.</t>
              <t indent="0">SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users:</t>
              <t indent="0">The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9260"/>
          <seriesInfo name="DOI" value="10.17487/RFC9260"/>
        </reference>
      </references>
      <references pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-bier-pim-signaling" target="https://datatracker.ietf.org/doc/html/draft-ietf-bier-pim-signaling-13" quoteTitle="true" derivedAnchor="BIER-PIM">
          <front>
            <title>PIM Signaling Through BIER Core</title>
            <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli" role="editor">
              <organization showOnFrontPage="true">Nokia</organization>
            </author>
            <author fullname="Fengman Xu" initials="F." surname="Xu">
              <organization showOnFrontPage="true">Verizon</organization>
            </author>
            <author fullname="Jayant Kotalwar" initials="J." surname="Kotalwar">
              <organization showOnFrontPage="true">Nokia</organization>
            </author>
            <author fullname="IJsbrand Wijnands" initials="I." surname="Wijnands">
              <organization showOnFrontPage="true">Cisco System</organization>
            </author>
            <author fullname="Mankamana Prasad Mishra" initials="M." surname="Mishra">
              <organization showOnFrontPage="true">Cisco System</organization>
            </author>
            <author fullname="Zhaohui (Jeffrey) Zhang" initials="Z." surname="Zhang">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <date day="3" month="March" year="2025"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-bier-pim-signaling-13"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC3973" target="https://www.rfc-editor.org/info/rfc3973" quoteTitle="true" derivedAnchor="RFC3973">
          <front>
            <title>Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)</title>
            <author fullname="A. Adams" initials="A." surname="Adams"/>
            <author fullname="J. Nicholas" initials="J." surname="Nicholas"/>
            <author fullname="W. Siadak" initials="W." surname="Siadak"/>
            <date month="January" year="2005"/>
            <abstract>
              <t indent="0">This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3973"/>
          <seriesInfo name="DOI" value="10.17487/RFC3973"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Zheng (Sandy) Zhang"/>
      and <contact fullname="Tanmoy Kundu"/> for their suggestions and
      contributions to this document.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Hooman Bidgoli" initials="H" role="editor" surname="Bidgoli">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <postal>
            <street>March Road</street>
            <city>Ottawa</city>
            <region>Ontario</region>
            <code>K2K 2T6</code>
            <country>Canada</country>
          </postal>
          <email>hooman.bidgoli@nokia.com</email>
        </address>
      </author>
      <author fullname="Stig Venaas" initials="S." surname="Venaas">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street>Tasman Drive</street>
            <city>San Jose</city>
            <region>CA</region>
            <code>95134</code>
            <country>United States of America</country>
          </postal>
          <phone/>
          <email>stig@cisco.com</email>
        </address>
      </author>
      <author fullname="Mankamana Mishra" initials="M." surname="Mishra">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street>Tasman Drive</street>
            <city>San Jose</city>
            <region>CA</region>
            <code>95134</code>
            <country>United States of America</country>
          </postal>
          <email>mankamis@cisco.com</email>
        </address>
      </author>
      <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
        <organization showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <postal>
            <city>Boston</city>
            <region>MA</region>
            <country>United States of America</country>
          </postal>
          <email>zzhang@juniper.net</email>
        </address>
      </author>
      <author fullname="Mike McBride" initials="M." surname="McBride">
        <organization showOnFrontPage="true">Futurewei Technologies Inc.</organization>
        <address>
          <postal>
            <city>Santa Clara</city>
            <region>CA</region>
            <country>United States of America</country>
          </postal>
          <email>michael.mcbride@futurewei.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
