rfc9272xml2.original.xml   rfc9272.xml 
<?xml version="1.1" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!ENTITY nbsp "&#160;">
.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!ENTITY nbhy "&#8209;">
.8174.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC8279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8279.xml">
<!ENTITY RFC8401 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">
]> ]>
<?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"?>
<rfc category="std" updates="8401,8444" docName="draft-ietf-bier-bar-ipa-13" ipr
="trust200902">
<front>
<title abbrev="bier-bar-ipa">BIER Underlay Path Calculation Algorithm and Co
nstraints</title>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bier-bar-ipa
-13" number="9272" submissionType="IETF" category="std" consensus="true" ipr="tr
ust200902"
updates="8401, 8444" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="3"
symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.12.10 -->
<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"/>
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>zzhang@juniper.net</email> <email>zzhang@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Antoni Przygienda" initials="A." surname="Przygienda"> <author fullname="Antoni Przygienda" initials="A." surname="Przygienda">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>prz@juniper.net</email> <email>prz@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Andrew Dolganow" initials="A." surname="Dolganow"> <author fullname="Andrew Dolganow" initials="A." surname="Dolganow">
<organization>Individual</organization> <organization>Individual</organization>
<address> <address>
<email>adolgano@gmail.com</email> <email>adolgano@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli"> <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>hooman.bidgoli@nokia.com</email> <email>hooman.bidgoli@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands">
<author fullname="IJsbrand Wijnands" initials="I." surname="Wijnands">
<organization>Individual</organization> <organization>Individual</organization>
<address> <address>
<email>ice@braindump.be</email> <email>ice@braindump.be</email>
</address> </address>
</author> </author>
<author fullname="Arkadiy Gulko" initials="A." surname="Gulko"> <author fullname="Arkadiy Gulko" initials="A." surname="Gulko">
<organization>Edward Jones Wealth Management</organization> <organization>Edward Jones Wealth Management</organization>
<address> <address>
<email>arkadiy.gulko@edwardjones.com</email> <email>arkadiy.gulko@edwardjones.com</email>
</address> </address>
</author> </author>
<date year="2022"/>
<workgroup>BIER</workgroup> <date year="2022" month="September" />
<area>rtg</area>
<workgroup>bier</workgroup>
<abstract> <abstract>
<t> <t>
This document specifies general rules for the interaction between This document specifies general rules for the interaction between the
the BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay
path calculation. The semantics defined in this document update path calculation within the Bit Index Explicit Replication (BIER)
RFC8401 and RFC8444. This document also updates the BIER Algorithm architecture. The semantics defined in this document update RFC 8401
registry established in RFC8401. and RFC 8444. This document also updates the "BIER Algorithm"
registry established in RFC 8401.
</t> </t>
</abstract> </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> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>In the Bit Index Explicit Replication (BIER) architecture [RFC8279], <name>Introduction</name>
packets with a BIER encapsulation header are forwarded to the neighbors <t>In the Bit Index Explicit Replication (BIER) architecture <xref
on the underlay paths towards Bit-Forwarding Egress Routers (BFERs) target="RFC8279" format="default"/>, packets with a BIER encapsulation
that are represented by bits set in the BIER header's BitString. header are forwarded to the neighbors on the underlay paths towards
The paths are calculated in the underlay topology Bit-Forwarding Egress Routers (BFERs) that are represented by bits set
for each sub-domain following a calculation algorithm specific to the in the BIER header's BitString. The paths are calculated in the
sub-domain. The topology or algorithm may or may not be congruent underlay topology for each sub-domain following a calculation algorithm
with unicast. The algorithm could be a BIER specific algorithm or specific to the sub-domain. The topology or algorithm may or may not be
could be a generic IGP one, e.g., Shortest Path First (SPF). congruent with unicast. The algorithm could be a BIER-specific algorithm
</t> or could be a generic IGP one, e.g., Shortest Path First (SPF).
<t> </t>
In [RFC8401] and [RFC8444], an 8-bit BAR <t>
In <xref target="RFC8401" format="default"/> and <xref target="RFC8444"
format="default"/>, an 8-bit BAR
(BIER Algorithm) field and 8-bit IPA (IGP Algorithm) field are defined (BIER Algorithm) field and 8-bit IPA (IGP Algorithm) field are defined
to signal the BIER specific algorithm to signal the BIER-specific algorithm
and generic IGP Algorithm respectively and only value 0 is allowed for and generic IGP Algorithm, respectively, and only value 0 is allowed for
both fields in those two documents. both fields in those two documents.
<!-- </t>
This document specifies the general rules for the two fields and their <t>
interaction when either or both fields are not 0, and updates This document specifies general rules for the interaction between the BIER
their semantics defined in [RFC8444] and [RFC8401]. Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay path
</t> calculation when other BAR and/or IPA values are used. The semantics
<t> defined in this document update <xref target="RFC8401" format="default"/>
This document specifies general rules for the interaction between and <xref target="RFC8444" format="default"/>. This document also updates th
the BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay e "BIER Algorithm" registry defined
path calculation when other BAR and/or IPA values are used. in <xref target="RFC8401" format="default"/> by renaming the "Experimental
The semantics defined in this document update [RFC8401], [RFC8444]. Use" range to "Private or Experimental Use".
This document also updates the BIER Algorithm registry defined in [RFC8401] </t>
by renaming the "Experimental Use" range to "Private or Experimental Use". <section>
</t> <name>Requirements Language</name>
</section> <t>
<section title = "Updated Definition for BAR and IPA Fields"> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The definition for the BAR and IPA fields in Section 6.1 of [RFC8401 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
] and Section 2.1 of [RFC8444] ",
are updated as follows. "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
IPA: IGP Algorithm. Specifies a generic Routing Algorithm (RA) and be
related Routing Constraints (RC) to calculate underlay paths to interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
reach other Bit-Forwarding Routers (BFRs). target="RFC8174"/> when, and only when, they appear in all capitals, as
Values are from the "IGP Algorithm Types" registry. One Octet. shown here.
</t> </t>
<t>
BAR: 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. One Octet.
</t>
<t>
When a BAR value is defined,
the corresponding BA and BC semantics SHOULD be specified.
For an IGP Algorithm to be used as a
BIER IPA, its RA and RC semantics SHOULD be specified.
If any of these semantics is not specified, it MUST be
interpreted as "NULL" algorithm or constraint. For example,
the IGP Algorithm 0 defined in [RFC8665] is treated
as having a NULL RC, i.e., no constraints (see Section 3).
</t>
<t>If a specification is not available for a specific BAR value, its
value MUST be from the Private or Experimental Use range of
the registry.
</t>
</section>
<section title = "General Rules for the BAR and IPA Interaction">
<t>For a particular sub-domain, all BFRs MUST be
provisioned with and signal the same BAR and IPA values. If a BFR
discovers another BFR advertising different BAR or IPA value for a
sub-domain, it MUST treat the advertising router as incapable of
supporting BIER for that sub-domain
(one way of handling incapable routers is documented in Section 6.9
of [RFC8279] and additional methods may be defined in the future).
</t>
<t>For a particular topology X that a sub-domain is associated with,
a router MUST calculate the underlay paths according to its BAR and
IPA values in the following way:
<list style="numbers">
<t>Apply the BIER constraints, resulting in BC(X). If BC is NULL, then BC(X)
is X itself.
</t>
<t>Apply the routing constraints, resulting in RC(BC(X)). If RC is NULL, the
n RC(BC(X)) is BC(X).
</t>
<t>Select the algorithm AG as following:
<list style="letters">
<t>If BA is NULL, AG is set to RA.
</t>
<t>If BA is not NULL, AG is set to BA.
</t>
</list>
</t>
<t>Run AG on RC(BC(X)).
</t>
</list>
</t>
<t>It's possible that the resulting AG is not applicable to BIER,
In that case, no BIER paths will be calculated and it is a network
design issue that an operator needs to avoid when choosing BAR/IPA.
</t>
<section title = "When BAR Is Not Used">
<t>BAR value 0 is defined as "No BIER-specific algorithm is used" [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>
<section title = "Exceptions/Extensions to the General Rules">
<t>Exceptions or extensions to the above general rules may be specified </section>
<section numbered="true" toc="default">
<name>Updated Definitions for IPA and BAR Fields</name>
<t>The definitions for the IPA and BAR fields in <xref target="RFC8401" se
ction="6.1" sectionFormat="of" format="default"/> and <xref target="RFC8444" sec
tion="2.1" sectionFormat="of" format="default"/> are updated as follows.
</t>
<dl newline="false">
<dt>IPA:</dt>
<dd>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>BAR:</dt>
<dd><t>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>
When a BAR value is defined, the corresponding BIER-specific Algorithm (B
A) and BIER-specific Constraint (BC) semantics <bcp14>SHOULD</bcp14> be specifie
d. 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 no
t 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"/> is treated as having a NULL RC, i.e., no
constraints (see <xref target="general_rules"/>).
</t>
<t>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="default" anchor="general_rules">
<name>General Rules for the BAR and IPA Interaction</name>
<t>For a particular sub-domain, all BFRs <bcp14>MUST</bcp14> be provisione
d 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"/>
, and additional
methods may be defined in the future.)
</t>
<t>For a particular topology X that a sub-domain is associated with,
a router <bcp14>MUST</bcp14> calculate the underlay paths according to it
s BAR and
IPA values in the following way:
</t>
<ol spacing="normal" type="1">
<li>Apply the BIER constraints, resulting in BC(X). If BC is NULL, then B
C(X) is X itself.
</li>
<li>Apply the routing constraints, resulting in RC(BC(X)). If RC is NULL
, then RC(BC(X)) is BC(X).
</li>
<li>
<t>Select the algorithm AG as follows:
</t>
<ol spacing="normal" type="a">
<li>If BA is NULL, AG is set to RA.</li>
<li>If BA is not NULL, AG is set to BA.</li>
</ol>
</li>
<li>Run AG on RC(BC(X)).
</li>
</ol>
<t>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="default">
<name>When BAR Is Not Used</name>
<t>BAR value 0 is defined as "No BIER-specific algorithm is used"
<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>
<section numbered="true" toc="default">
<name>Exceptions or Extensions to the General 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, in the future for specific BAR and/or IPA values. When that happens,
compatibility with defined BAR and/or IPA values and semantics need compatibility with defined BAR and/or IPA values and semantics need
to be specified. to be specified.
</t> </t>
</section> </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> </section>
<section title = "Examples"> <section numbered="true" toc="default">
<t>As an example, one may define a new BAR with a BIER specific <name>Examples</name>
constraint of "excluding BIER <t>As an example, one may define a new BAR with a BIER-specific
incapable routers". No BIER specific algorithm is specified, and the constraint of "excluding BIER-incapable routers".
BIER specific constraint can go with any IPA - No BIER-specific
whatever RC defined by the IPA is augmented with "excluding BIER algorithm is specified, and the BIER-specific constraint can go with
incapable routers", i.e., routers that do not support BIER are not any IPA, i.e., any RC defined by the IPA is augmented with "excluding
considered when applying the IGP Algorithm. BIER-incapable routers". (Routers that do not support BIER are
</t> not considered when applying the IGP Algorithm.)
<t>If the BC and RC happen to conflict and lead to an empty </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, topology, then no BIER forwarding path will be found. For example,
the BC could be "exclude BIER-incapable routers" and the RC could the BC could be "exclude BIER-incapable routers", and the RC could
be "include green links only". If all the green links are associated be "include green links only". If all the green links are associated
with BIER-incapable routers, it results in an empty topology. That is a with BIER-incapable routers, it results in an empty topology. This is a
network design issue that an operator needs to avoid when choosing network design issue that an operator needs to avoid when choosing
BAR/IPA. the BAR or IPA.
</t> </t>
<t>In another example, a BAR value can be specified to use Steiner Tree <t>In another example, a BAR value can be specified to use the Steiner tre
algorithm and used together with IPA 0 (which uses SPF algorithm). e
According to the general rules, the BIER specific algorithm takes 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. precedence so SPF is not used.
</t> </t>
</section> </section>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<t>This document requests the following changes to the "BIER Algorithm" re <name>IANA Considerations</name>
gistry: <t>The "BIER Algorithm" registry has been updated as follows:
<list style="numbers"> </t>
<t>Rename the "Experimental Use" range to "Private or Experimental Use"</t> <ol spacing="normal" type="1">
<t>Add this document as a reference</t> <li>The "Experimental Use" range has been renamed "Private or Experimenta
</list> l Use".</li>
</t> <li>This document has been added as a reference both for the registry it
self and for values 240-254 in the registry.</li>
</ol>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<t>This document specifies general rules for the interaction between <name>Security Considerations</name>
the BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay <t>This document specifies general rules for the interaction between the
path calculation. It does not change the security aspects as discussed in BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay path
[RFC8279], [RFC8401], [RFC8444]. calculation. It does not change the security aspects as discussed in
</t> <xref target="RFC8279" format="default"/>, <xref target="RFC8401"
format="default"/>, and <xref target="RFC8444" format="default"/>.
</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements"> </middle>
<t>The authors thank Alia Atlas, Eric Rosen, <back>
Senthil Dhanaraj and many others for their suggestions and comments. <references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.840
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.844
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.827
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.866
5.xml"/>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors thank <contact fullname="Alia Atlas"/>, <contact fullname="
Eric Rosen"/>,
<contact fullname="Senthil Dhanaraj"/> and many others for their sugges
tions and comments.
In particular, the BC/BA/RC/RA representation for the interaction rules In particular, the BC/BA/RC/RA representation for the interaction rules
is based on Alia's write-up. is based on Alia's write-up.
</t> </t>
</section> </section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC8174;
&RFC8401;
&RFC8444;
&RFC8279;
&RFC8665;
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 27 change blocks. 
215 lines changed or deleted 229 lines changed or added

This html diff was produced by rfcdiff 1.48.