<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-bier-bar-ipa-13" indexInclude="true" ipr="trust200902" number="9272" prepTime="2022-09-09T16:36:49" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" updates="8401, 8444" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bier-bar-ipa-13" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9272" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="BAR and IPA Interaction">Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER)</title>
    <seriesInfo name="RFC" value="9272" stream="IETF"/>
    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization showOnFrontPage="true">Juniper Networks</organization>
      <address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>
    <author fullname="Antoni Przygienda" initials="A." surname="Przygienda">
      <organization showOnFrontPage="true">Juniper Networks</organization>
      <address>
        <email>prz@juniper.net</email>
      </address>
    </author>
    <author fullname="Andrew Dolganow" initials="A." surname="Dolganow">
      <organization showOnFrontPage="true">Individual</organization>
      <address>
        <email>adolgano@gmail.com</email>
      </address>
    </author>
    <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <email>hooman.bidgoli@nokia.com</email>
      </address>
    </author>
    <author fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands">
      <organization showOnFrontPage="true">Individual</organization>
      <address>
        <email>ice@braindump.be</email>
      </address>
    </author>
    <author fullname="Arkadiy Gulko" initials="A." surname="Gulko">
      <organization showOnFrontPage="true">Edward Jones Wealth Management</organization>
      <address>
        <email>arkadiy.gulko@edwardjones.com</email>
      </address>
    </author>
    <date month="09" year="2022"/>
    <area>rtg</area>
    <workgroup>bier</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
  This document specifies general rules for the interaction between the
  BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay
  path calculation within the Bit Index Explicit Replication (BIER)
  architecture.  The semantics defined in this document update RFC 8401
  and RFC 8444.  This document also updates the "BIER Algorithm"
  registry established in RFC 8401.
      </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/rfc9272" 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) 2022 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>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </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-updated-definitions-for-ipa">Updated Definitions for IPA and BAR Fields</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-general-rules-for-the-bar-a">General Rules for the BAR and IPA Interaction</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" 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-when-bar-is-not-used">When BAR Is Not Used</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-exceptions-or-extensions-to">Exceptions or Extensions to the General Rules</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-examples">Examples</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-iana-considerations">IANA 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-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</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.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.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">In the Bit Index Explicit Replication (BIER) architecture <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>, packets with a BIER encapsulation
      header are forwarded to the neighbors on the underlay paths towards
      Bit-Forwarding Egress Routers (BFERs) that are represented by bits set
      in the BIER header's BitString.  The paths are calculated in the
      underlay topology for each sub-domain following a calculation algorithm
      specific to the sub-domain. The topology or algorithm may or may not be
      congruent with unicast. The algorithm could be a BIER-specific algorithm
      or could be a generic IGP one, e.g., Shortest Path First (SPF).
      </t>
      <t indent="0" pn="section-1-2">
	  In <xref target="RFC8401" format="default" sectionFormat="of" derivedContent="RFC8401"/> and <xref target="RFC8444" format="default" sectionFormat="of" derivedContent="RFC8444"/>, an 8-bit BAR
       (BIER Algorithm) field and 8-bit IPA (IGP Algorithm) field are defined
       to signal the BIER-specific algorithm
       and generic IGP Algorithm, respectively, and only value 0 is allowed for
       both fields in those two documents.
      </t>
      <t indent="0" pn="section-1-3">
   This document specifies general rules for the interaction between the BIER
   Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay path
   calculation when other BAR and/or IPA values are used.  The semantics
   defined in this document update <xref target="RFC8401" format="default" sectionFormat="of" derivedContent="RFC8401"/>
   and <xref target="RFC8444" format="default" sectionFormat="of" derivedContent="RFC8444"/>.  This document also updates the "BIER Algorithm" registry defined
   in <xref target="RFC8401" format="default" sectionFormat="of" derivedContent="RFC8401"/> by renaming the "Experimental
   Use" range to "Private or Experimental Use".
      </t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.1-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>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-updated-definitions-for-ipa">Updated Definitions for IPA and BAR Fields</name>
      <t indent="0" pn="section-2-1">The definitions for the IPA and BAR fields in <xref target="RFC8401" section="6.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8401#section-6.1" derivedContent="RFC8401"/> and <xref target="RFC8444" section="2.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8444#section-2.1" derivedContent="RFC8444"/> are updated as follows.
      </t>
      <dl newline="false" indent="3" spacing="normal" pn="section-2-2">
        <dt pn="section-2-2.1">IPA:</dt>
        <dd pn="section-2-2.2">IGP Algorithm.  Specifies a generic Routing Algorithm and
      related Routing Constraints to calculate underlay paths to
      reach other Bit-Forwarding Routers (BFRs).
      Values are from the "IGP Algorithm Types" registry. One octet.
	</dd>
        <dt pn="section-2-2.3">BAR:</dt>
        <dd pn="section-2-2.4">
          <t indent="0" pn="section-2-2.4.1">BIER Algorithm.  Specifies a BIER-specific Algorithm and
	BIER-specific Constraints used to either modify, enhance, or
	replace the calculation of underlay paths to reach other BFRs
	as defined by the IPA value. Values are allocated from the "BIER
	Algorithm" registry. One octet.
          </t>
          <t indent="0" pn="section-2-2.4.2">
	When a BAR value is defined, the corresponding BIER-specific Algorithm (BA) and BIER-specific Constraint (BC) semantics <bcp14>SHOULD</bcp14> be specified.  For an IGP Algorithm to be
	used as a BIER IPA, its Routing Algorithm (RA) and Routing Constraint (RC) semantics <bcp14>SHOULD</bcp14> be specified.  If any of these semantics is not specified, it
	<bcp14>MUST</bcp14> be interpreted as the "NULL" algorithm or constraint. For
	example, the IGP Algorithm 0 defined in <xref target="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/> is treated as having a NULL RC, i.e., no
	constraints (see <xref target="general_rules" format="default" sectionFormat="of" derivedContent="Section 3"/>).
          </t>
          <t indent="0" pn="section-2-2.4.3">If a specification is not available for a specific BAR value, its 
      value <bcp14>MUST</bcp14> be from the Private or Experimental Use range of 
      the registry. 
          </t>
        </dd>
      </dl>
    </section>
    <section numbered="true" toc="include" anchor="general_rules" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-general-rules-for-the-bar-a">General Rules for the BAR and IPA Interaction</name>
      <t indent="0" pn="section-3-1">For a particular sub-domain, all BFRs <bcp14>MUST</bcp14> be provisioned with and
      signal the same BAR and IPA values. If a BFR discovers another BFR
      advertising a different BAR or IPA value for a sub-domain, it <bcp14>MUST</bcp14> treat
      the advertising router as incapable of supporting BIER for that
      sub-domain. (One way of handling incapable routers is documented in
      <xref target="RFC8279" section="6.9" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8279#section-6.9" derivedContent="RFC8279"/>, and additional
      methods may be defined in the future.)
      </t>
      <t indent="0" pn="section-3-2">For a particular topology X that a sub-domain is associated with,
	a router <bcp14>MUST</bcp14> calculate the underlay paths according to its BAR and
	IPA values in the following way:
      </t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3-3">
	<li pn="section-3-3.1" derivedCounter="1.">Apply the BIER constraints, resulting in BC(X). If BC is NULL, then BC(X) is X itself.
    </li>
        <li pn="section-3-3.2" derivedCounter="2.">Apply the routing constraints, resulting in RC(BC(X)). If RC is NULL, then RC(BC(X)) is BC(X).
    </li>
        <li pn="section-3-3.3" derivedCounter="3.">
          <t indent="0" pn="section-3-3.3.1">Select the algorithm AG as follows:
          </t>
          <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-3-3.3.2">
	    <li pn="section-3-3.3.2.1" derivedCounter="a.">If BA is NULL, AG is set to RA.</li>
            <li pn="section-3-3.3.2.2" derivedCounter="b.">If BA is not NULL, AG is set to BA.</li>
          </ol>
        </li>
        <li pn="section-3-3.4" derivedCounter="4.">Run AG on RC(BC(X)).
    </li>
      </ol>
      <t indent="0" pn="section-3-4">It's possible that the resulting AG is not applicable to BIER.
	In that case, no BIER paths will be calculated, and this is a network
	design issue that an operator needs to avoid when choosing the BAR or IPA.
      </t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-when-bar-is-not-used">When BAR Is Not Used</name>
        <t indent="0" pn="section-3.1-1">BAR value 0 is defined as "No BIER-specific algorithm is used"
        <xref target="RFC8401" format="default" sectionFormat="of" derivedContent="RFC8401"/>.  This value indicates NULL
        BA and BC.  Following the rules defined above, the IPA value alone
        identifies the calculation algorithm and constraints to be used for a
        particular sub-domain.
        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-exceptions-or-extensions-to">Exceptions or Extensions to the General Rules</name>
        <t indent="0" pn="section-3.2-1">Exceptions or extensions to the above general rules may be specified
       in the future for specific BAR and/or IPA values. When that happens,
       compatibility with defined BAR and/or IPA values and semantics need
       to be specified.
        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-examples">Examples</name>
      <t indent="0" pn="section-4-1">As an example, one may define a new BAR with a BIER-specific
       constraint of "excluding BIER-incapable routers". 
  No BIER-specific
  algorithm is specified, and the BIER-specific constraint can go with
  any IPA, i.e., any RC defined by the IPA is augmented with "excluding
  BIER-incapable routers". (Routers that do not support BIER are
  not considered when applying the IGP Algorithm.)
      </t>
      <t indent="0" pn="section-4-2">If the BC and RC happen to conflict and lead to an empty
       topology, then no BIER forwarding path will be found. For example,
       the BC could be "exclude BIER-incapable routers", and the RC could
       be "include green links only". If all the green links are associated
       with BIER-incapable routers, it results in an empty topology. This is a
       network design issue that an operator needs to avoid when choosing
       the BAR or IPA.
      </t>
      <t indent="0" pn="section-4-3">In another example, a BAR value can be specified to use the Steiner tree
	algorithm and used together with IPA 0 (which uses an SPF algorithm).
	According to the general rules, the BIER-specific algorithm takes
	precedence so SPF is not used.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">The "BIER Algorithm" registry has been updated as follows:
      </t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5-2">
	<li pn="section-5-2.1" derivedCounter="1.">The "Experimental Use" range has been renamed "Private or Experimental Use".</li>
        <li pn="section-5-2.2" derivedCounter="2.">This document has been added as a reference both for the registry itself and for values 240-254 in the registry.</li>
      </ol>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">This document specifies general rules for the interaction between the
      BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay path
      calculation. It does not change the security aspects as discussed in
      <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>, <xref target="RFC8401" format="default" sectionFormat="of" derivedContent="RFC8401"/>, and <xref target="RFC8444" format="default" sectionFormat="of" derivedContent="RFC8444"/>.
      </t>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-normative-references">Normative References</name>
      <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="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="RFC8401" target="https://www.rfc-editor.org/info/rfc8401" quoteTitle="true" derivedAnchor="RFC8401">
        <front>
          <title>Bit Index Explicit Replication (BIER) Support via IS-IS</title>
          <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
          <author fullname="T. Przygienda" initials="T." surname="Przygienda"/>
          <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
          <author fullname="Z. Zhang" initials="Z." surname="Zhang"/>
          <date month="June" year="2018"/>
          <abstract>
            <t indent="0">This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8401"/>
        <seriesInfo name="DOI" value="10.17487/RFC8401"/>
      </reference>
      <reference anchor="RFC8444" target="https://www.rfc-editor.org/info/rfc8444" quoteTitle="true" derivedAnchor="RFC8444">
        <front>
          <title>OSPFv2 Extensions for Bit Index Explicit Replication (BIER)</title>
          <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
          <author fullname="N. Kumar" initials="N." surname="Kumar"/>
          <author fullname="IJ. Wijnands" initials="IJ." surname="Wijnands"/>
          <author fullname="A. Dolganow" initials="A." surname="Dolganow"/>
          <author fullname="T. Przygienda" initials="T." surname="Przygienda"/>
          <author fullname="J. Zhang" initials="J." surname="Zhang"/>
          <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
          <date month="November" year="2018"/>
          <abstract>
            <t indent="0">Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). The BFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in the BIER packet header.</t>
            <t indent="0">This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8444"/>
        <seriesInfo name="DOI" value="10.17487/RFC8444"/>
      </reference>
      <reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8665" quoteTitle="true" derivedAnchor="RFC8665">
        <front>
          <title>OSPF Extensions for Segment Routing</title>
          <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
          <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
          <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
          <author fullname="H. Gredler" initials="H." surname="Gredler"/>
          <author fullname="R. Shakir" initials="R." surname="Shakir"/>
          <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
          <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
          <date month="December" year="2019"/>
          <abstract>
            <t indent="0">Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</t>
            <t indent="0">This document describes the OSPFv2 extensions required for Segment Routing.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8665"/>
        <seriesInfo name="DOI" value="10.17487/RFC8665"/>
      </reference>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors thank <contact fullname="Alia Atlas"/>, <contact fullname="Eric Rosen"/>, 
         <contact fullname="Senthil Dhanaraj"/> and many others for their suggestions and comments.
         In particular, the BC/BA/RC/RA representation for the interaction rules
         is based on Alia's write-up.
      </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="Zhaohui Zhang" initials="Z." surname="Zhang">
        <organization showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <email>zzhang@juniper.net</email>
        </address>
      </author>
      <author fullname="Antoni Przygienda" initials="A." surname="Przygienda">
        <organization showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <email>prz@juniper.net</email>
        </address>
      </author>
      <author fullname="Andrew Dolganow" initials="A." surname="Dolganow">
        <organization showOnFrontPage="true">Individual</organization>
        <address>
          <email>adolgano@gmail.com</email>
        </address>
      </author>
      <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <email>hooman.bidgoli@nokia.com</email>
        </address>
      </author>
      <author fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands">
        <organization showOnFrontPage="true">Individual</organization>
        <address>
          <email>ice@braindump.be</email>
        </address>
      </author>
      <author fullname="Arkadiy Gulko" initials="A." surname="Gulko">
        <organization showOnFrontPage="true">Edward Jones Wealth Management</organization>
        <address>
          <email>arkadiy.gulko@edwardjones.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
