<?xmlversion="1.1" encoding="US-ASCII"?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">zwsp "​"> <!ENTITYRFC8279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml">nbhy "‑"> <!ENTITYRFC8401 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8401.xml"> <!ENTITY RFC8444 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8444.xml"> <!ENTITY RFC8665 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8665.xml">wj "⁠"> ]><?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc strict="no"?> <?rfc rfcedstyle="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><rfccategory="std" updates="8401,8444"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bier-bar-ipa-13"ipr="trust200902">number="9272" submissionType="IETF" category="std" consensus="true" ipr="trust200902" updates="8401, 8444" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.12.10 --> <front> <titleabbrev="bier-bar-ipa">BIER Underlayabbrev="BAR and IPA Interaction">Underlay Path Calculation Algorithm andConstraints</title>Constraints for Bit Index Explicit Replication (BIER)</title> <seriesInfo name="RFC" value="9272"/> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <organization>Juniper Networks</organization> <address> <email>zzhang@juniper.net</email> </address> </author> <author fullname="Antoni Przygienda" initials="A." surname="Przygienda"> <organization>Juniper Networks</organization> <address> <email>prz@juniper.net</email> </address> </author> <author fullname="Andrew Dolganow" initials="A." surname="Dolganow"> <organization>Individual</organization> <address> <email>adolgano@gmail.com</email> </address> </author> <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli"> <organization>Nokia</organization> <address> <email>hooman.bidgoli@nokia.com</email> </address> </author> <author fullname="IJsbrand Wijnands"initials="I."initials="IJ." surname="Wijnands"> <organization>Individual</organization> <address> <email>ice@braindump.be</email> </address> </author> <author fullname="Arkadiy Gulko" initials="A." surname="Gulko"> <organization>Edward Jones Wealth Management</organization> <address> <email>arkadiy.gulko@edwardjones.com</email> </address> </author> <dateyear="2022"/> <workgroup>BIER</workgroup>year="2022" month="September" /> <area>rtg</area> <workgroup>bier</workgroup> <abstract> <t> This document specifies general rules for the interaction between the BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay pathcalculation.calculation within the Bit Index Explicit Replication (BIER) architecture. The semantics defined in this document updateRFC8401RFC 8401 andRFC8444.RFC 8444. This document also updates theBIER Algorithm"BIER Algorithm" registry established inRFC8401.RFC 8401. </t> </abstract><note title="Requirements Language"> <t> 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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </note></front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>In the Bit Index Explicit Replication (BIER) architecture[RFC8279],<xref target="RFC8279" format="default"/>, 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 aBIER specificBIER-specific algorithm or could be a generic IGP one, e.g., Shortest Path First (SPF). </t> <t> In[RFC8401]<xref target="RFC8401" format="default"/> and[RFC8444],<xref target="RFC8444" format="default"/>, an 8-bit BAR (BIER Algorithm) field and 8-bit IPA (IGP Algorithm) field are defined to signal theBIER specificBIER-specific algorithm and generic IGPAlgorithm respectivelyAlgorithm, respectively, and only value 0 is allowed for both fields in those two documents.<!-- This document specifies the general rules for the two fields and their interaction when either or both fields are not 0, and updates their semantics defined in [RFC8444] and [RFC8401]. --></t> <t> 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[RFC8401], [RFC8444].<xref target="RFC8401" format="default"/> and <xref target="RFC8444" format="default"/>. This document also updates theBIER Algorithm"BIER Algorithm" registry defined in[RFC8401]<xref target="RFC8401" format="default"/> by renaming the "Experimental Use" range to "Private or Experimental Use". </t> <section> <name>Requirements Language</name> <t> 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"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <sectiontitle = "Updated Definitionnumbered="true" toc="default"> <name>Updated Definitions forBAR andIPAFields">and BAR Fields</name> <t>Thedefinitiondefinitions for theBAR andIPA and BAR fields inSection 6.1 of [RFC8401]<xref target="RFC8401" section="6.1" sectionFormat="of" format="default"/> andSection 2.1 of [RFC8444]<xref target="RFC8444" section="2.1" sectionFormat="of" format="default"/> are updated as follows. </t><t> IPA: IGP<dl newline="false"> <dt>IPA:</dt> <dd>IGP Algorithm. Specifies a generic Routing Algorithm(RA)and related Routing Constraints(RC)to calculate underlay paths to reach other Bit-Forwarding Routers (BFRs). Values are from the "IGP Algorithm Types" registry. OneOctet. </t> <t> BAR: BIERoctet. </dd> <dt>BAR:</dt> <dd><t>BIER Algorithm. Specifies a BIER-specific Algorithm(BA)and BIER-specific Constraints(BC)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. OneOctet.octet. </t> <t> When a BAR value is defined, the correspondingBABIER-specific Algorithm (BA) andBCBIER-specific Constraint (BC) semanticsSHOULD<bcp14>SHOULD</bcp14> be specified. For an IGP Algorithm to be used as a BIER IPA, itsRARouting Algorithm (RA) andRCRouting Constraint (RC) semanticsSHOULD<bcp14>SHOULD</bcp14> be specified. If any of these semantics is not specified, itMUST<bcp14>MUST</bcp14> be interpreted as the "NULL" algorithm or constraint. For example, the IGP Algorithm 0 defined in[RFC8665]<xref target="RFC8665" format="default"/> is treated as having a NULL RC, i.e., no constraints (seeSection 3).<xref target="general_rules"/>). </t> <t>If a specification is not available for a specific BAR value, its valueMUST<bcp14>MUST</bcp14> be from the Private or Experimental Use range of the registry. </t> </dd> </dl> </section> <sectiontitle = "Generalnumbered="true" toc="default" anchor="general_rules"> <name>General Rules for the BAR and IPAInteraction">Interaction</name> <t>For a particular sub-domain, all BFRsMUST<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, itMUST<bcp14>MUST</bcp14> treat the advertising router as incapable of supporting BIER for thatsub-domain (onesub-domain. (One way of handling incapable routers is documented inSection 6.9 of [RFC8279]<xref target="RFC8279" section="6.9" sectionFormat="of" format="default"/>, and additional methods may be defined in thefuture).future.) </t> <t>For a particular topology X that a sub-domain is associated with, a routerMUST<bcp14>MUST</bcp14> calculate the underlay paths according to its BAR and IPA values in the following way:<list style="numbers"> <t>Apply</t> <ol spacing="normal" type="1"> <li>Apply the BIER constraints, resulting in BC(X). If BC is NULL, then BC(X) is X itself.</t> <t>Apply</li> <li>Apply the routing constraints, resulting in RC(BC(X)). If RC is NULL, then RC(BC(X)) is BC(X).</t></li> <li> <t>Select the algorithm AG asfollowing: <list style="letters"> <t>Iffollows: </t> <ol spacing="normal" type="a"> <li>If BA is NULL, AG is set toRA. </t> <t>IfRA.</li> <li>If BA is not NULL, AG is set toBA. </t> </list> </t> <t>RunBA.</li> </ol> </li> <li>Run AG on RC(BC(X)).</t> </list> </t></li> </ol> <t>It's possible that the resulting AG is not applicable toBIER,BIER. In that case, no BIER paths will becalculatedcalculated, anditthis is a network design issue that an operator needs to avoid when choosingBAR/IPA.the BAR or IPA. </t> <sectiontitle = "Whennumbered="true" toc="default"> <name>When BAR Is NotUsed">Used</name> <t>BAR value 0 is defined as "No BIER-specific algorithm is used"[RFC8401].<xref target="RFC8401" format="default"/>. 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> <sectiontitle = "Exceptions/Extensionsnumbered="true" toc="default"> <name>Exceptions or Extensions to the GeneralRules">Rules</name> <t>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 title = "Compatibility"> <t>Currently only value 0 is used for both BAR and IPA in [RFC8401], [RFC8444] and <xref target="I-D.ietf-bier-ospfv3-extensions"/>, which means no constraints, so there are no compatibility issues. </t--></section> <sectiontitle = "Examples">numbered="true" toc="default"> <name>Examples</name> <t>As an example, one may define a new BAR with aBIER specificBIER-specific constraint of "excludingBIER incapableBIER-incapable routers". NoBIER specificBIER-specific algorithm is specified, and theBIER specificBIER-specific constraint can go with anyIPA - whateverIPA, i.e., any RC defined by the IPA is augmented with "excludingBIER incapable routers", i.e., routersBIER-incapable routers". (Routers that do not support BIER are not considered when applying the IGPAlgorithm.Algorithm.) </t> <t>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-incapablerouters"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.ThatThis is a network design issue that an operator needs to avoid when choosingBAR/IPA.the BAR or IPA. </t> <t>In another example, a BAR value can be specified to use the SteinerTreetree algorithm and used together with IPA 0 (which uses an SPF algorithm). According to the general rules, theBIER specificBIER-specific algorithm takes precedence so SPF is not used. </t> </section> <sectiontitle="IANA Considerations"> <t>This document requests the following changes to thenumbered="true" toc="default"> <name>IANA Considerations</name> <t>The "BIER Algorithm"registry: <list style="numbers"> <t>Rename theregistry has been updated as follows: </t> <ol spacing="normal" type="1"> <li>The "Experimental Use" rangetohas been renamed "Private or ExperimentalUse"</t> <t>Add thisUse".</li> <li>This document has been added as areference</t> </list> </t>reference both for the registry itself and for values 240-254 in the registry.</li> </ol> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>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[RFC8279], [RFC8401], [RFC8444].<xref target="RFC8279" format="default"/>, <xref target="RFC8401" format="default"/>, and <xref target="RFC8444" format="default"/>. </t> </section> </middle> <back> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8401.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8444.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8665.xml"/> </references> <section anchor="Acknowledgements"title="Acknowledgements">numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors thankAlia Atlas, Eric Rosen, Senthil Dhanaraj<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></middle> <back> <references title="Normative References"> &RFC2119; &RFC8174; &RFC8401; &RFC8444; &RFC8279; &RFC8665; </references></back> </rfc>