rfc9793xml2.original.xml   rfc9793.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc [
.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.8174.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC4271 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.4271.xml">
<!ENTITY RFC8279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8279.xml">
<!ENTITY RFC8126 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8126.xml">
<!ENTITY RFC7606 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7606.xml">
<!ENTITY RFC4760 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4760.xml">
<!ENTITY RFC8296 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8296.xml">
]> ]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc tocdepth="3"?> tf-bier-idr-extensions-19" number="9793" ipr="trust200902" consensus="true" obso
<?rfc tocindent="yes"?> letes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDep
<?rfc symrefs="yes"?> th="3" symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-bier-idr-extensions-19"
ipr="trust200902">
<front> <front>
<title abbrev="BGP Extensions for BIER">BGP Extensions for BIER</title>
<author fullname="Xiaohu Xu" initials="X.X." surname="Xu"> <!--[rfced] Please note that the title of the document has been updated as follo
<organization>China Mobile</organization> ws.
Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide")
.
Please review.
Original:
BGP Extensions for BIER
Current:
BGP Extensions for Bit Index Explicit Replication (BIER)
-->
<title abbrev="BGP Extensions for BIER">BGP Extensions for Bit Index Explici
t Replication (BIER)</title>
<seriesInfo name="RFC" value="9793"/>
<author fullname="Xiaohu Xu" initials="X." surname="Xu">
<organization>China Mobile</organization>
<address> <address>
<email>xuxiaohu@cmss.chinamobile.com</email> <email>xuxiaohu@cmss.chinamobile.com</email>
</address> </address>
</author> </author>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<author fullname="Mach Chen" initials="M.C." surname="Chen">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<email>mach.chen@huawei.com</email> <email>mach.chen@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Keyur Patel" initials="K." surname="Patel">
<author fullname="Keyur Patel" initials="K.P." surname="Patel">
<organization>Arrcus, Inc.</organization> <organization>Arrcus, Inc.</organization>
<address> <address>
<email>keyur@arrcus.com</email> <email>keyur@arrcus.com</email>
</address> </address>
</author> </author>
<author fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands">
<author fullname="IJsbrand Wijnands" initials="I.W." 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="Tony Przygienda" initials="T." surname="Przygienda">
<author fullname="Antoni Przygienda" initials="A.P." surname="Przygienda">
<organization>Juniper</organization> <organization>Juniper</organization>
<address> <address>
<email>prz@juniper.net</email> <email>prz@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Zhaohui Zhang" initials="Z." role="editor" surname="Zhang" > <author fullname="Zhaohui Zhang" initials="Z." role="editor" surname="Zhang" >
<organization>Juniper</organization> <organization>Juniper</organization>
<address> <address>
<email>zzhang@juniper.net</email> <email>zzhang@juniper.net</email>
</address> </address>
</author> </author>
<date month="May" year="2025"/>
<area>RTG</area>
<workgroup>bier</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<!--[rfced] We see these two similar sentences in the Abstract and
Introduction. May we update the sentence from the Introduction to
match the one from the Abstract?
Abstract:
This document describes BGP extensions for advertising the BIER
information and methods for calculating BIER states based on the
advertisements.
Introduction:
This document describes BGP extensions for advertising the BIER-specific
information and the methods for calculating BIER forwarding states
with this information.
-->
<abstract> <abstract>
<t>Bit Index Explicit Replication (BIER) is a multicast forwarding <t>Bit Index Explicit Replication (BIER) is a multicast forwarding
architecture that doesn't require an explicit tree-building protocol architecture that doesn't require an explicit tree-building protocol
and doesn't require intermediate routers to maintain per-tree multicast and doesn't require intermediate routers to maintain per-tree multicast
states. Some BIER-specific information and state, which are only in states. Some BIER-specific information and states, which are only in
proportion to the number of BIER routers but not per-tree, do need to be a dvertised, proportion to the number of BIER routers but not per-tree, do need to be a dvertised,
calculated, and maintained. This document describes BGP extensions for calculated, and maintained. This document describes BGP extensions for
advertising the BIER information and methods for calculating BIER states advertising the BIER information and methods for calculating BIER states
based on the advertisements.</t> based on the advertisements.</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>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> is a mul <name>Introduction</name>
ticast <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279" format="de
forwarding architecture which doesn't require an explicit tree-building fault"/> is a multicast
forwarding architecture that doesn't require an explicit tree-building
protocol and doesn't require intermediate routers to maintain per-tree protocol and doesn't require intermediate routers to maintain per-tree
multicast states. It supports both direct and tunneled BIER forwarding. multicast states. It supports both direct and tunneled BIER forwarding.
This document describes BGP extensions for advertising This document describes BGP extensions for advertising
the BIER-specific information and the methods for calculating BIER the BIER-specific information and the methods for calculating BIER
forwarding states with this information. More forwarding states with this information. More
specifically, in this document, we define a new optional specifically, in this document, we define a new optional
transitive BGP attribute, referred to as the BIER attribute, to convey transitive BGP attribute, referred to as the "BIER attribute", to convey
the BIER-specific information such as BIER Forwarding Router identifier the BIER-specific information such as BIER Forwarding Router identifier
(BFR-id), BitString Length (BSL), and so on. The signaling is to be (BFR-id), BitStringLength (BSL), and so on. The signaling is to be
used in a single Administrative Domain, and <xref target="op"/> specifi used in a single Administrative Domain (AD), and <xref target="op" form
es at="default"/> specifies
procedures to prevent the BIER attribute from "leaking out" of the doma in.</t> procedures to prevent the BIER attribute from "leaking out" of the doma in.</t>
<!--t>These extensions are applicable in those multi-tenant data centers <!--t>These extensions are applicable in those multi-tenant data centers
where BGP instead of IGP is used as an underlay <xref target="RFC7938"/>. These where BGP instead of IGP is used as an underlay <xref target="RFC7938"/>. These
extensions may also be applicable to other BGP based network extensions may also be applicable to other BGP based network
scenarios, e.g., as described in <xref target="I-D.ietf-bier-multicast-as- a-service"/>.</t--> scenarios, e.g., as described in <xref target="I-D.ietf-bier-multicast-as- a-service"/>.</t-->
</section> </section>
<section anchor="Abbreviations_Terminology" numbered="true" toc="default">
<section anchor="Abbreviations_Terminology" title="Terminology"> <name>Terminology</name>
<t>This document makes use of the terms defined in <xref target="RFC4271"/ <t>This document makes use of the terminology defined in <xref
> and <xref target="RFC8279"/>. Some terminologies are listed below for convenie target="RFC4271" format="default"/> and <xref target="RFC8279"
nce. format="default"/>. Some terms are listed below for
</t> convenience.</t>
<t>BIER: Bit Indexed Explicit Replication</t> <dl spacing="normal" newline="false">
<t>BFR: BIER Forwarding Router</t> <dt>BIER:</dt><dd>Bit Indexed Explicit Replication</dd>
<t>BFR-ID: BIER Forwarding Router Identifier</t> <dt>BFR:</dt><dd>BIER Forwarding Router</dd>
<t>BSL: BitStringLength</t> <dt>BFR-ID:</dt><dd>BIER Forwarding Router Identifier</dd>
<t>BIFT: BIER Forwarding Table</t> <dt>BSL:</dt><dd>BitStringLength</dd>
<t>BIFT-id: BIER Forwarding Table Identifier</t> <dt>BIFT:</dt><dd>BIER Forwarding Table</dd>
<t>BFER: BIER Forwarding Egress Router</t> <dt>BIFT-id:</dt><dd>BIER Forwarding Table Identifier</dd>
<t>BFR-prefix: Each BFR is assigned a single "BFR-prefix" for each <dt>BFER:</dt><dd>BIER Forwarding Egress Router</dd>
<dt>BFR-prefix:</dt><dd>Each BFR is assigned a single "BFR-prefix" for ea
ch
sub-domain to which it belongs. It is recommended that the BFR-prefix sub-domain to which it belongs. It is recommended that the BFR-prefix
be a loopback address of the BFR. be a loopback address of the BFR.</dd>
</t> <dt>NLRI:</dt><dd>Network Layer Reachability Information <xref target="RF
<t>NLRI: Network Layer Reachability Information <xref target="RFC4271"/>< C4271" format="default"/></dd>
/t> <dt>AFI:</dt><dd>Address Family Identifier <xref target="RFC4760" format=
<t>AFI: Address Family Identifier <xref target="RFC4760"/></t> "default"/></dd>
<t>SAFI: Subsequent Address Family Identifier <xref target="RFC4760"/></t <dt>SAFI:</dt><dd>Subsequent Address Family Identifier <xref target="RFC4
> 760" format="default"/></dd>
</section> </dl>
<section>
<section title="BIER Path Attribute" anchor="attr"> <!--[rfced] FYI - We moved the Requirements Language paragraph to the
Terminology section per the RFC Style Guide; see Section 4 of
RFC 7322.
-->
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section anchor="attr" numbered="true" toc="default">
<name>BIER Path Attribute</name>
<t>This specification defines an optional, transitive BGP path attribute, <t>This specification defines an optional, transitive BGP path attribute,
referred to as the BIER attribute. This attribute can be attached to a referred to as the "BIER attribute". This attribute can be attached to a
BGP UPDATE message by the originator for NLRIs of AFI 1 or 2 and BGP UPDATE message by the originator for NLRIs of AFI 1 or 2 and
SAFI 1,2, or 4 to indicate the BIER-specific information of a SAFI 1, 2, or 4 to indicate the BIER-specific information of a
particular BFR identified by the /32 (for IPv4) or /128 (for IPv6) particular BFR identified by the /32 (for IPv4) or /128 (for IPv6)
host address prefix contained in the NLRI. The attachment of the BIER host address prefix contained in the NLRI. The attachment of the BIER
attribute to non-host address prefixes is not defined by this document. attribute to non-host address prefixes is not defined by this document.
It may be specified in the future, for example by It may be specified in the future, for example, by
<xref target="I-D.ietf-bier-prefix-redistribute"/>. <xref target="I-D.ietf-bier-prefix-redistribute" format="default"/>.
</t> </t>
<t> <t>
If the BIER path attribute is present, the NLRI is referred to as a If the BIER path attribute is present, the NLRI is referred to as a
"BFR-prefix". Use of the attribute with other AFIs/SAFIs is outside the "BFR-prefix". Use of the attribute with other AFIs/SAFIs is outside the
scope of this document. scope of this document.
</t> </t>
<t> <t>
The BIER path attribute is an optional, transitive BGP path attribute The BIER path attribute is an optional, transitive BGP path attribute
with type code TBD and of variable length. The attribute value portion with type code 41 and of variable length. The attribute value portion
carries BIER TLVs, which are encoded as follows: carries BIER TLVs, which are encoded as follows:
<artwork align="center"><![CDATA[ </t>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (variable) ~ ~ Value (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<t>
The Length field defines the length of the value portion in octets (thus, a TLV The Length field defines the length of the value portion in octets (thus, a TLV
with no value portion would have a length of zero). The TLV is not padded to 4-o with no value portion would have a length of zero). The TLV is not padded to 4-o
ctet alignment. Unknown and unsupported types MUST be preserved and propagated w ctet alignment. Unknown and unsupported types <bcp14>MUST</bcp14> be preserved a
ithin the BIER Attribute. The presence of unknown or unexpected TLVs MUST NOT re nd propagated within the BIER Attribute. The presence of unknown or unexpected T
sult in the NLRI or the BIER Attribute being considered malformed. LVs <bcp14>MUST NOT</bcp14> result in the NLRI or the BIER Attribute being consi
dered malformed.
</t> </t>
<t> <t>
When creating a BIER attribute, a BFR MUST include one When creating a BIER attribute, a BFR <bcp14>MUST</bcp14> include one
BIER TLV for every Sub-domain that the prefix belongs to. The BIER TLV for every Sub-domain that the prefix belongs to. The
attribute type code for the BIER Attribute is TBD. The value field of attribute type code for the BIER Attribute is 41. The value field of
the BIER Attribute contains one or more BIER TLV shown as follows:</t> the BIER Attribute contains one or more BIER TLVs as shown below:</t>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length | | Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain | BFR-ID | Reserved | | Sub-domain | BFR-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| Sub-TLVs | | Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
]]></artwork> ]]></artwork>
<list> <dl newline="false" spacing="normal">
<t>Type: 1.</t> <dt>Type:</dt><dd>1</dd>
<t>Length: Two octets encoding the length in octets of the Value
part.</t>
<t>Sub-domain <xref target="RFC8279"/>: a one-octet field encoding the
sub-domain ID
corresponding to the BFR-ID.</t>
<t>BFR-ID <xref target="RFC8279"/>: a two-octet field encoding the BFR
-ID.</t>
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ign
ored on
reception.</t>
<t>Sub-TLVs: contains one or more sub-TLV.</t>
</list>
<t>The BIER TLV MAY appear multiple times in the BIER Path <!--[rfced] FYI - We note a mix of "one-octet" vs. "1-octet" and "two
Attribute, one for each sub-domain. There MUST be no more than octets" vs. "2 octets". We updated the document to use the
numeral form for consistency.
-->
<dt>Length:</dt><dd>2 octets encoding the length in octets of the
Value part.</dd>
<dt>Sub-domain:</dt><dd>A
1-octet field encoding the sub-domain ID corresponding to the
BFR-ID (see <xref target="RFC8279" format="default"/>).</dd>
<dt>BFR-ID:</dt><dd>A
2-octet field encoding the BFR-ID (see <xref target="RFC8279" format="de
fault"/>).</dd>
<dt>Reserved:</dt><dd><bcp14>SHOULD</bcp14> be set to 0 on
transmission and <bcp14>MUST</bcp14> be ignored on reception.</dd>
<dt>Sub-TLVs:</dt><dd>Contains one or more sub-TLVs.</dd>
</dl>
<t>The BIER TLV <bcp14>MAY</bcp14> appear multiple times in the BIER Path
Attribute, one for each sub-domain. There <bcp14>MUST</bcp14> be no more
than
one BIER TLV with the same Sub-domain value; if there is, the one BIER TLV with the same Sub-domain value; if there is, the
entire BIER Path Attribute MUST be ignored. entire BIER Path Attribute <bcp14>MUST</bcp14> be ignored.
</t> </t>
<t>A BIER TLV may have sub-TLVs, which may have their own sub-TLVs. <t>A BIER TLV may have sub-TLVs, which may have their own sub-TLVs.
All those are referred to as sub-TLVs and share the same Type space, All those are referred to as sub-TLVs and share the same Type space,
regardless of the level. regardless of the level.
</t>
<section title="BIER MPLS Encapsulation sub-TLV">
<t>The BIER MPLS Encapsulation sub-TLV has the following format.
It MAY appear multiple times in the BIER TLV.
</t> </t>
<t> <section numbered="true" toc="default">
<name>BIER MPLS Encapsulation Sub-TLV</name>
<t>The BIER MPLS Encapsulation sub-TLV has the following format.
It <bcp14>MAY</bcp14> appear multiple times in the BIER TLV.
</t>
<t>
The BIER MPLS Encapsulation Sub-TLV has the following format: The BIER MPLS Encapsulation Sub-TLV has the following format:
<artwork align="center"><![CDATA[ </t>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length | | Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max SI |BS Len | Label | | Max SI |BS Len | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs | ~ sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></t> ]]></artwork>
<dl newline="false" spacing="normal">
<t><list> <dt>Type:</dt><dd>2</dd>
<t> <dt>Length:</dt><dd>2 octets encoding the length in octets of the Value
Type: 2 part. The value is 4 or other (depending on sub-TLVs).</dd>
</t> <dt>Max SI:</dt><dd>A 1-octet field encoding the maximum Set
<t> Identifier (SI) (see <xref section="1" sectionFormat="of" target="RFC82
79"
Length: Two octets encoding the length in octets of the Value format="default"/>) used in the encapsulation for this BIER
part. The value is 4 or other (depending on sub-TLVs) sub-domain for this BitString length.</dd>
</t> <dt>BS Len:</dt><dd>BitString Length. A 4-bit field encoding the
<t> supported BitString length associated with this BFR-prefix. The
values allowed in this field are specified in <xref section="2" section
Max SI: A 1-octet field encoding the maximum Set Identifier (SI) Format="of"
(see Section 1 of <xref target="RFC8279"/>) used in the encapsulation for target="RFC8296" format="default"/>.</dd>
this <dt>Label:</dt><dd>A 20-bit value representing the first label in the l
BIER sub-domain for this BitString length. abel range.</dd>
</t> </dl>
<t> <t> The "label range" is the set of labels beginning with the Label
and ending with (Label + (Max SI)). A unique label range is allocated
BS Len (BitString Length): A 4-bit field encoding the supported for each BitString length and sub-domain-id. These labels are used
BitString length associated with this BFR-prefix. The values for BIER forwarding, as described in <xref target="RFC8279"
allowed in this field are specified in Section 2 of <xref target="RFC8296" format="default"/> and <xref target="RFC8296" format="default"/>.
/>. </t>
</t> <t> The size of the label range is determined by the number of SIs
<t> (<xref section="1" sectionFormat="of" target="RFC8279" format="default"/
>) that are used
Label: A 20-bit value representing the first label in the label range. in the network. Each SI maps to a single label in the label range:
</t> the first label is for SI=0, the second label is for SI=1, etc.
</list></t> </t>
<t> <t>
The "label range" is the set of labels beginning with the Label and
ending with (Label + (Max SI)). A unique label range is allocated
for each BitString length and sub-domain-id. These labels are used
for BIER forwarding as described in <xref target="RFC8279"/> and <xref target
="RFC8296"/>.
</t>
<t>
The size of the label range is determined by the number of SIs
(Section 1 of <xref target="RFC8279"/>) that are used in the network. Each S
I maps
to a single label in the label range: the first label is for SI=0,
the second label is for SI=1, etc.
</t>
<t>
If the label associated with the Maximum Set Identifier exceeds the If the label associated with the Maximum Set Identifier exceeds the
20-bit range, the BIER MPLS Encapsulation Sub-TLV containing the 20-bit range, the BIER MPLS Encapsulation Sub-TLV containing the
error MUST be ignored. error <bcp14>MUST</bcp14> be ignored.
</t> </t>
<t> <t>
If the same BitString length is repeated in multiple BIER MPLS If the same BitString length is repeated in multiple BIER MPLS
Encapsulation Sub-TLVs inside the same BIER TLV, all BIER MPLS Encapsulation Sub-TLVs inside the same BIER TLV, all BIER MPLS
Encapsulation Sub-TLVs in the BIER TLV MUST be ignored. Encapsulation Sub-TLVs in the BIER TLV <bcp14>MUST</bcp14> be ignored.
</t> </t>
<t> <t>
Label ranges within all BIER MPLS Encapsulation Sub-TLVs advertised Label ranges within all BIER MPLS Encapsulation Sub-TLVs advertised
by the same BFR MUST NOT overlap. If an overlap is detected, all by the same BFR <bcp14>MUST NOT</bcp14> overlap. If an overlap is detected,
BIER MPLS Encapsulation Sub-TLVs advertised by the BFR MUST be ignored. all
</t> BIER MPLS Encapsulation Sub-TLVs advertised by the BFR <bcp14>MUST</bcp14> be
</section> ignored.
</t>
<section title="BIER Non-MPLS Encapsulation sub-TLV"> </section>
<t>The BIER non-MPLS Encapsulation sub-TLV is used for non-MPLS encapsulat <section numbered="true" toc="default">
ion and has the following format. It MAY appear multiple times within a <name>BIER Non-MPLS Encapsulation Sub-TLV</name>
<t>The BIER non-MPLS Encapsulation sub-TLV is used for non-MPLS encapsul
ation and has the following format. It <bcp14>MAY</bcp14> appear multiple times
within a
single BIER TLV. If the same BitString length is repeated in single BIER TLV. If the same BitString length is repeated in
multiple BIER non-MPLS encapsulation Sub-TLVs inside the same BIER multiple BIER non-MPLS encapsulation Sub-TLVs inside the same BIER
TLV, the BIER TLV MUST be ignored. TLV, the BIER TLV <bcp14>MUST</bcp14> be ignored.
</t> </t>
<artwork align="center" name="" type="" alt=""><![CDATA[
<t><artwork align="center"><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length | | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max SI |BS LEN | BIFT-id | | Max SI |BS Len | BIFT-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs | ~ sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></t> ]]></artwork>
<dl newline="false" spacing="normal">
<t><list> <dt>Type:</dt><dd>3</dd>
<t> <dt>Length:</dt><dd>2 octets encoding the length in octets of the Value
Type: 3. part. The value is 4 or other (depending on sub-TLVs).</dd>
</t> <dt>Max SI:</dt><dd>A 1-octet field encoding the Maximum Set
<t> Identifier (<xref section="1" sectionFormat="of" target="RFC8279" forma
t="default"/>)
Length: Two octets encoding the length in octets of the Value used in the encapsulation for this BIER sub-domain for this BitString
part. The value is 4 or other (depending on sub-TLVs). length. The first BIFT-id is for SI=0, the second BIFT-id is for
</t> SI=1, etc. If the BIFT-id associated with the Maximum Set Identifier
<t> exceeds the 20-bit range, the sub-TLV <bcp14>MUST</bcp14> be
ignored.</dd>
Max SI: A 1-octet field encoding the Maximum Set Identifier <dt>BS Len:</dt><dd>BitString Length. A 4-bit field encoding the
(Section 1 of <xref target="RFC8279"/>) used in the encapsulation for this BitString length (as per <xref target="RFC8296" format="default"/>)
BIER supported for the encapsulation.</dd>
subdomain for this BitString length. The first BIFT-id is for SI=0, <dt>BIFT-id:</dt><dd>A 20-bit field representing the first BIFT-id
the second BIFT-id is for SI=1, etc. If the BIFT-id associated with in the BIFT-id range.</dd>
the Maximum Set Identifier exceeds the 20-bit range, the sub-TLV </dl>
MUST be ignored. <t>
</t>
<t>
BIFT-id: A 20-bit field representing the first BIFT-id in the
BIFT-id range.
</t>
<t>
BitString Length (BS Len): A 4-bit field encoding the bitstring
length (as per <xref target="RFC8296"/>) supported for the encapsulation.
</t>
</list></t>
<t>
The "BIFT-id range" is the set of 20-bit values beginning with the The "BIFT-id range" is the set of 20-bit values beginning with the
BIFT-id and ending with (BIFT-id + (Max SI)). These BIFT-id's are BIFT-id and ending with (BIFT-id + (Max SI)). These BIFT-ids are
used for BIER forwarding as described in <xref target="RFC8279"/> and <xref t used for BIER forwarding, as described in <xref target="RFC8279" format="defa
arget="RFC8296"/>. ult"/> and <xref target="RFC8296" format="default"/>.
</t> </t>
<t> <t>
The size of the BIFT-id range is determined by the number of SI's The size of the BIFT-id range is determined by the number of SIs
(Section 1 of <xref target="RFC8279"/>) that are used in the network. Each S (<xref section="1" sectionFormat="of" target="RFC8279" format="default"/>) th
I maps at are used in the network. Each SI maps
to a single BIFT-id in the BIFT-id range: the first BIFT-id is for to a single BIFT-id in the BIFT-id range: the first BIFT-id is for
SI=0, the second BIFT-id is for SI=1, etc. SI=0, the second BIFT-id is for SI=1, etc.
</t> </t>
<t> <t>
If the BIFT-id associated with the Maximum Set Identifier exceeds If the BIFT-id associated with the Maximum Set Identifier exceeds
the 20-bit range, the BIER non-MPLS Encapsulation sub-TLV the 20-bit range, the BIER non-MPLS Encapsulation sub-TLV
containing the error MUST be ignored. containing the error <bcp14>MUST</bcp14> be ignored.
</t> </t>
<t> <t>
BIFT-id ranges within all the BIER non-MPLS Encapsulation sub-TLVs BIFT-id ranges within all the BIER non-MPLS Encapsulation sub-TLVs
advertised by the same BFR MUST NOT overlap. If an overlap is advertised by the same BFR <bcp14>MUST NOT</bcp14> overlap. If an over
detected, all the BIER non-MPLS Encapsulation sub-TLV advertised lap is
by the BFR MUST be ignored. However, the detected, all the BIER non-MPLS Encapsulation sub-TLVs advertised
by the BFR <bcp14>MUST</bcp14> be ignored. However, the
BIFT-id ranges may overlap across different encapsulation types and BIFT-id ranges may overlap across different encapsulation types and
that is allowed. As an example, the BIFT-id value in the non-MPLS that is allowed. As an example, the BIFT-id value in the non-MPLS
encapsulation sub-TLV may overlap with the Label value in the encapsulation sub-TLV may overlap with the Label value in the
Label range in BIER MPLS encapsulation sub-TLV. Label range in the BIER MPLS encapsulation sub-TLV.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>BIER Nexthop Sub-TLV</name>
<section title="BIER Nexthop sub-TLV"> <t>The BIER Nexthop sub-TLV <bcp14>MAY</bcp14> be included, and it <bcp1
<t>The BIER Nexthop sub-TLV MAY be included, and MUST NOT be included 4>MUST NOT</bcp14> be included
more than once in each of the MPLS or non-MPLS more than once in each of the MPLS or non-MPLS
Encapsulation sub-TLV as well as the top-level BIER TLV. It is used Encapsulation sub-TLVs or in the top-level BIER TLV. It is used
when calculating BIFT entries, as described in <xref target="bift when calculating BIFT entries, as described in <xref target="bift
"/> " format="default"/>
and illustrated in <xref target="biernh"/>. and illustrated in <xref target="biernh" format="default"/>.
</t> </t>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length | | Type = 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nexthop | | Nexthop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<list> <dl newline="false" spacing="normal">
<t>Type: 4</t> <dt>Type:</dt><dd>4</dd>
<dt>Length:</dt><dd>2 octets. The value is 4 if the Nexthop is an
<t>Length: 2 octets. The value is 4 if the Nexthop is an IPv4 address IPv4 address and 16 if the Nexthop is an IPv6 address.</dd>
and 16 if the Nexthop is an IPv6 address</t> <dt>Nexthop:</dt><dd>4 or 16 octets of an IPv4/IPv6 address.</dd>
</dl>
<t>Nexthop: 4 or 16 octets of IPv4/IPv6 address</t> </section>
</list>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Originating/Propagating/Updating BIER Attribute"> <name>Originating/Propagating/Updating the BIER Attribute</name>
<t>A BIER Forwarding Egress Router (BFER) MUST attach a BIER attribute <t>A BIER Forwarding Egress Router (BFER) <bcp14>MUST</bcp14> attach a BIE
R attribute
to its own /32 (for IPv4) or /128 (for IPv6) to its own /32 (for IPv4) or /128 (for IPv6)
host BFR-prefix NLRI. The BIER attribute MUST include one host BFR-prefix NLRI. The BIER attribute <bcp14>MUST</bcp14> incl ude one
BIER TLV for each BIER sub-domain that it supports. Each BIER TLV BIER TLV for each BIER sub-domain that it supports. Each BIER TLV
MUST include an MPLS and/or non-MPLS Encapsulation sub-TLV, and MAY <bcp14>MUST</bcp14> include an MPLS and/or non-MPLS Encapsulation sub-TL V and <bcp14>MAY</bcp14>
include a BIER Nexthop sub-TLV with the Nexthop set to the include a BIER Nexthop sub-TLV with the Nexthop set to the
BIER prefix. If the BIER Nexthop sub-TLV is not included, the BIER prefi x BIER prefix. If the BIER Nexthop sub-TLV is not included, the BIER prefi x
will be used by receiving BFRs as the BIER nexthop when calculating BIFT . will be used by receiving BFRs as the BIER nexthop when calculating BIFT .
</t> </t>
<!--t>A BFR/BFER MAY attach a BIER proxy range sub-TLV <!--t>A BFR/BFER MAY attach a BIER proxy range sub-TLV
<xref target="I-D.ietf-bier-prefix-redistribute"/> in the BIER TLV. <xref target="I-D.ietf-bier-prefix-redistribute"/> in the BIER TLV.
If the NRLI is a non-host prefix with the proxy range sub-TLV, If the NRLI is a non-host prefix with the proxy range sub-TLV,
a BIER Nexthop sub-TLV MUST be inlucded to encode the originating a BIER Nexthop sub-TLV MUST be inlucded to encode the originating
BFR/BFER's address, and a host BIER prefix NLRI MUST be originate d BFR/BFER's address, and a host BIER prefix NLRI MUST be originate d
for the BFR/BFER. for the BFR/BFER.
Other than this case, Other than this case,
<t>A BFR that is not a BFER (i.e., its BFR-ID is 0) <t>A BFR that is not a BFER (i.e., its BFR-ID is 0)
SHOULD NOT attach a BIER attribute to its own BIER prefix NLRIs <bcp14>SHOULD NOT</bcp14> attach a BIER attribute to its own BIER prefix NLRIs
(if a BIER attribute is attached it will not get used anyway). (if a BIER attribute is attached it will not get used anyway).
</t> </t>
a BFR receiving a non-host BIER prefix without the BIER proxy ran ge a BFR receiving a non-host BIER prefix without the BIER proxy ran ge
sub-TLV SHOULD perform an "attribute discard" action sub-TLV <bcp14>SHOULD</bcp14> perform an "attribute discard" acti on
<xref target="RFC7606"/> about the BIER attribute. <xref target="RFC7606"/> about the BIER attribute.
</t--> </t-->
<t>When a BFR receives an update with the BIER path attribute, <t>When a BFR receives an update with the BIER path attribute, the
the attribute is parsed with the following validations: attribute is parsed with the following validations:</t>
<list style="symbols">
<t>Syntactic checking based on the length field of TLVs and sub <ul spacing="normal">
-TLVs: <li><t>Syntactic checking based on the Length field of TLVs and sub-TLVs
<list> :</t>
<t>The total length of BIER TLVs (including the type and <ul spacing="normal">
length <li>The total length of BIER TLVs (including the Type and Length
fields) MUST equal to the BIER path attribute length.</t> fields) <bcp14>MUST</bcp14> be equal to the BIER path attribute
<t>The total length of sub-TLVs (including the type and l length.</li>
ength <li>The total length of sub-TLVs (including the Type and Length
fields) of a TLV MUST equal to the length of the TLV.</t> fields) of a TLV <bcp14>MUST</bcp14> be equal to the length of the
</list> TLV.</li>
</t> </ul>
<t>Semantic checking as per <xref target="attr"/>.</t> </li>
</list> <li>Semantic checking as per <xref target="attr" format="default"/>.</li
</t> >
<t> </ul>
<t>
If the syntactic checking fails, the attribute is considered If the syntactic checking fails, the attribute is considered
malformed and the "attribute discard" action <xref target="RFC7606"/> malformed and the "attribute discard" action <xref target="RFC7606" format="d
about the BIER attribute MUST be taken. If the semantic checking passes, efault"/>
BIFT entries are calculated as described in Section 5. Otherwise for the BIER attribute <bcp14>MUST</bcp14> be taken. If the semantic checking
(semantic checking fails), some or all BIER TLVs are ignored, per the rules passes,
given in <xref target="attr"/>, and if the remaining data permits, BIFT entries are calculated as described in <xref target="bift" forma
BIFT entries are calculated per <xref target="bift"/>. t="default"/>. Otherwise
</t> (i.e., if semantic checking fails), some or all BIER TLVs are ignored, per th
<t>When a BFR re-advertises a BGP NLRI with a BIER attribute, for the e rules
sub-domains that this BFR supports, in the corresponding BIER TLV given in <xref target="attr" format="default"/>, and if the remaining data pe
it rmits,
SHOULD set/update the BIER Nexthop sub-TLV to use its own BIER prefix, BIFT entries are calculated per <xref target="bift" format="default"/>.
in which case it MUST replace the MPLS or non-MPLS Encapsulation sub-TLV </t>
<t>When a BFR re-advertises a BGP NLRI with a BIER attribute, for the
sub-domains that this BFR supports, in the corresponding BIER TLV
, it
<bcp14>SHOULD</bcp14> set/update the BIER Nexthop sub-TLV to use its own
BIER prefix;
in which case, it <bcp14>MUST</bcp14> replace the MPLS or non-MPLS Encap
sulation sub-TLV
with its own, i.e., as if the BFR is attaching the with its own, i.e., as if the BFR is attaching the
encapsulation sub-TLV for its own BIER prefix. If it does not encapsulation sub-TLV for its own BIER prefix. If it does not
update the BIER Nexthop sub-TLVs, it MUST NOT update MPLS or update the BIER Nexthop sub-TLVs, it <bcp14>MUST NOT</bcp14> update the MPLS or
non-MPLS Encapsulation sub-TLV. If it does not support a sub-domain, non-MPLS Encapsulation sub-TLV. If it does not support a sub-domain,
it MUST NOT update the corresponding BIER TLV. it <bcp14>MUST NOT</bcp14> update the corresponding BIER TLV.
</t> </t>
<t>It's possible that the BFR supports some but not all <t>It's possible that the BFR supports some but not all
BitStringLengths (BSLs) BitStringLengths (BSLs)
in the received MPLS or non-MPLS Encapsulation sub-TLVs. in the received MPLS or non-MPLS Encapsulation sub-TLVs.
After setting/updating the BIER Nexthop sub-TLV in the top BIER TLV After setting/updating the BIER Nexthop sub-TLV in the top BIER TLV
to itself, for the BSLs that it does support, the BFR MUST remove to itself, for the BSLs that it does support, the BFR <bcp14>MUST</bcp14 > remove
the BIER Nexthop sub-TLV (if present) in the corresponding Encapsulation the BIER Nexthop sub-TLV (if present) in the corresponding Encapsulation
sub-TLVs. For the BSLs that it does not support: sub-TLVs. For the BSLs that it does not support:
<list style="symbols"> </t>
<t>If a BIER Nexthop sub-TLV is included in the Encapsulation s <ul spacing="normal">
ub-TLV, <li>
it MUST NOT be updated.</t> <t>If a BIER Nexthop sub-TLV is included in the Encapsulation sub-TLV,
<t>Otherwise, if a BIER Nexthop sub-TLV was included in the rec it <bcp14>MUST NOT</bcp14> be updated.</t>
eived </li>
<li>
<t>Otherwise, if a BIER Nexthop sub-TLV is included in the received
BIER TLV, its original value (before changed for supported BSLs by BIER TLV, its original value (before changed for supported BSLs by
this BFR) MUST be copied into the Encapsulation sub-TLV.</t> this BFR) <bcp14>MUST</bcp14> be copied into the Encapsulation
<t>Otherwise, a BIER Nexthop sub-TLV MUST be added to the sub-TLV.</t>
</li>
<li>
<t>Otherwise, a BIER Nexthop sub-TLV <bcp14>MUST</bcp14> be added to t
he
Encapsulation sub-TLV with its value set to the BFR-prefix.</t> Encapsulation sub-TLV with its value set to the BFR-prefix.</t>
</list> </li>
</t> </ul>
<t> <t>
All impacted length fields (e.g., All impacted Length fields (e.g.,
the Encapsulation sub-TLV Length, the top-level BIER TLV Length) MUST the Encapsulation sub-TLV Length and the top-level BIER TLV Length) <bcp
14>MUST</bcp14>
be updated accordingly. be updated accordingly.
</t> </t>
<t>Since the BIER attribute is an optional, transitive BGP path <t>Since the BIER attribute is an optional, transitive BGP path
attribute, a non-BFR BGP speaker could still re-advertise the received attribute, a non-BFR BGP speaker could still re-advertise the received
route with a BIER attribute. route with a BIER attribute.
</t> </t>
<t>Two different BFR-prefixes MUST NOT have the same non-zero BFR-ID <t>Two different BFR-prefixes <bcp14>MUST NOT</bcp14> have the same non-ze ro BFR-ID
in the same sub-domain. If a duplication is detected, the receiving in the same sub-domain. If a duplication is detected, the receiving
BFR MUST NOT use the BFR-prefixes with the same BFR-ID for BIFT BFR <bcp14>MUST NOT</bcp14> use the BFR-prefixes with the same BFR-ID f
calculation for the sub-domain and an error SHOULD be logged. or BIFT
calculation for the sub-domain and an error <bcp14>SHOULD</bcp14> be lo
gged.
</t> </t>
</section> </section>
<section anchor="bift" numbered="true" toc="default">
<section title="BIFT Calculation with BGP Signaling" anchor="bift"> <name>BIFT Calculation with BGP Signaling</name>
<t>As pointed out in <xref target="RFC8279"/>, BIFTs are derived from <t>As pointed out in <xref target="RFC8279" format="default"/>, BIFTs are
derived from
the unicast FIB by adding BIER-specific information. the unicast FIB by adding BIER-specific information.
</t> </t>
<t>For each sub-domain, a BFR calculates the corresponding BIFTs <t>For each sub-domain, a BFR calculates the corresponding BIFTs
by going through the BIER prefixes whose BIER attribute includes by going through the BIER prefixes whose BIER attribute includes
a BIER TLV for the sub-domain. a BIER TLV for the sub-domain.
For a non-zero BFR-id in the BIER TLV, <!--or for each BFR-id For a non-zero BFR-id in the BIER TLV, <!--or for each BFR-id
in the BIER Proxy Range sub-TLV in the BIER TLV of a BIER prefix,--> in the BIER Proxy Range sub-TLV in the BIER TLV of a BIER prefix,-->
a BIFT entry is created or updated. The entry's BFR Neighbor a BIFT entry is created or updated. The entry's BFR Neighbor
(BFR-NBR) <xref target="RFC8279"/> is the Nexthop in the BIER (BFR-NBR) <xref target="RFC8279" format="default"/> is the Nexthop in the
Nexthop sub-TLV in the corresponding Encapsulation sub-TLV, or BIER
Nexthop sub-TLV in the corresponding Encapsulation sub-TLV or
in the top-level BIER TLV if the Encapsulation sub-TLV does not in the top-level BIER TLV if the Encapsulation sub-TLV does not
have a Nexthop sub-TLV. If there is no Nexthop sub-TLV at all, have a Nexthop sub-TLV. If there is no Nexthop sub-TLV at all,
The entry's BFR Neighbor is the BIER prefix itself. The BIER label the entry's BFR Neighbor is the BIER prefix itself. The BIER label
or BIFT-id for the entry is derived from the Label Range in the or BIFT-id for the entry is derived from the label range in the
MPLS Encapsulation sub-TLV or from the BIFT-id Range in the MPLS Encapsulation sub-TLV or from the BIFT-id range in the
non-MPLS Encapsulation sub-TLV. non-MPLS Encapsulation sub-TLV.
</t> </t>
<t>BIER traffic is sent to the BFR-NBR either directly (BIER header <t>BIER traffic is sent to the BFR-NBR either directly (BIER header
directly follows a layer 2 header) if the BFR-NBR is directly directly follows a Layer 2 header) if the BFR-NBR is directly
connected, or via a tunnel otherwise. Notice that, if a non-BFR connected or via a tunnel. Notice that, if a non-BFR
BGP speaker re-advertises a BIER prefix (in this case it can not update BGP speaker re-advertises a BIER prefix (in this case, it cannot update
the BIER attribute since it is not capable), or if a BFR BGP speaker the BIER attribute since it is not capable), or if a BFR BGP speaker
re-advertises a BIER prefix without updating the BIER Nexthop re-advertises a BIER prefix without updating the BIER Nexthop
sub-TLV, the BFR receiving the prefix will tunnel BIER traffic - sub-TLV, the BFR receiving the prefix will tunnel BIER traffic --
the BGP speaker re-advertising the BIER prefix will not see the the BGP speaker re-advertising the BIER prefix will not see the
BIER traffic for the BIER prefix. BIER traffic for the BIER prefix.
</t> </t>
<t>How the tunnel is set up and chosen is outside the scope of this <t>How the tunnel is set up and chosen is outside the scope of this
document. It can be any kind of tunnel, e.g., MPLS Label Switched Path document. It can be any kind of tunnel, e.g., MPLS Label Switched Path
or IP/GRE, as long as the tunnel header can indicate that the payload or IP/GRE, as long as the tunnel header can indicate that the payload
is BIER. is BIER.
</t> </t>
</section> </section>
<section title="Example of BIER Nexthop Usage and Handling" anchor="biernh"> <section anchor="biernh" numbered="true" toc="default">
<t>Consider a simple topology as follows: <name>Example of BIER Nexthop Usage and Handling</name>
<artwork><![CDATA[ <t>Consider a simple topology as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
----- BFER1 ----- BFER1
/ /
BFR1 --- non-BFR --- BFR2 ------ BFER2 BFR1 --- non-BFR --- BFR2 ------ BFER2
\ \
----- BFER3 ----- BFER3
]]></artwork>
]]></artwork> <t>The BFER1/2/3 each advertises a route for its loopback address with a
</t> BIER path attribute, listing one BIER TLV for each sub-domain that it is
<t>The BFER1/2/3 each advertises a route for its loopback address in, with a non-zero BFR-ID and an MPLS Encapsulation sub-TLV. A BIER
with a BIER path attribute, listing one BIER TLV for each subdomain Nexthop sub-TLV is not included in the one from BFER1 but is included in
that it is in, with a non-zero BFR-ID and an MPLS Encapsulation sub-TLV the ones from BFER2/3. The BIER Nexthop sub-TLV encodes the BFR-prefix
. of BFER2 and BFER3, respectively.
A BIER Nexthop sub-TLV is not included in the one from BFER1 but is </t>
included in the ones from BFER2/3. The BIER Nexthop sub-TLV encodes <t>When BFR2 receives the route, it calculates its BIFT entries.
the BFR-prefix of BFER2 and BFER3 respectively.
</t>
<t>When BFR2 receives the route, it calculates its BIFT entries.
Because the route from BFER1 does not include a BIER Nexthop, BFR2 Because the route from BFER1 does not include a BIER Nexthop, BFR2
uses BFRer1's BFR-prefix as the nexthop. uses BFR1's BFR-prefix as the nexthop.
</t> </t>
<t>When BFR2 re-advertises the routes to the non-BFR, it adds <t>When BFR2 re-advertises the routes to the non-BFR, it adds
a BIER Nexthop sub-TLV to the BFER1 route, and updates the BIER Nexthop a BIER Nexthop sub-TLV to the BFER1 route and updates the BIER Nexthop
sub-TLV in the BFER2/3 routes, all encoding BFR2's own address. sub-TLV in the BFER2/3 routes, all encoding BFR2's own address.
It also updates the MPLS Encapsulation sub-TLV to encode its own labels . It also updates the MPLS Encapsulation sub-TLV to encode its own labels .
</t> </t>
<t>When the non-BFR receives the routes, since it does not support BIER <t>When the non-BFR receives the routes, since it does not support BIER,
,
no BIER-specific action is taken and the routes are re-advertised to no BIER-specific action is taken and the routes are re-advertised to
BFR1 with the BIER path attribute unchanged. BFR1 with the BIER path attribute unchanged.
</t> </t>
<t>When BFR1 receives the routes, it calculates the BIFT entries, <t>When BFR1 receives the routes, it calculates the BIFT entries,
using BFR2's address encoded in the BIER Nexthop sub-TLV as the using BFR2's address encoded in the BIER Nexthop sub-TLV as the
nexthop. Because BFR2 is not directly connected, a tunnel must be used. nexthop. Because BFR2 is not directly connected, a tunnel must be used.
</t> </t>
</section> </section>
<section anchor="op" numbered="true" toc="default">
<section title="Operational Considerations" anchor="op"> <name>Operational Considerations</name>
<t>It's assumed by this document that the BIER domain <t>In this document, it is assumed that the BIER domain
<xref target="RFC8279"/> is aligned with <xref target="RFC8279" format="default"/> is aligned with
an Administrative Domain (AD) which may be composed of multiple an Administrative Domain (AD), which may be composed of multiple
Autonomous Systems. Use of the BIER attribute in other Autonomous Systems. Use of the BIER attribute in other
scenarios is outside the scope of this document.</t> scenarios is outside the scope of this document.</t>
<t>BFR-prefixes are typically loopback addresses on the BFRs. They <t>BFR-prefixes are typically loopback addresses on the BFRs. They
are distributed throughout the AD but they do not need to be are distributed throughout the AD, but they do not need to be
distributed outside the AD for the BIER purposes. This is analogous distributed outside the AD for the BIER's purposes. This is analogous
to that Provider Edge router's loopback addresses are distributed to the Provider Edge router's loopback addresses that are distributed
inside the AD but they do not need to be distributed outside the AD. inside the AD, but they do not need to be distributed outside the AD.
</t> </t>
<t>If prefixes are distributed outside of the AD with the BIER <t>If prefixes are distributed outside of the AD with the BIER
attribute attached and the neighboring AD also deploys BIER, attribute attached and the neighboring AD also deploying BIER,
then the two BIER domains, which should be independent of each other, then the two BIER domains, which should be independent of each other,
may be incorrectly joined together and most likely have conflicting may be incorrectly joined together and most likely have conflicting
configurations, causing security risks and operational troubles. configurations, causing security risks and operational troubles.
</t> </t>
<t>To prevent that, a boundary router of the AD that supports the BIER <t>To prevent that, a boundary router of the AD that supports the BIER
attribute MUST attribute <bcp14>MUST</bcp14>
support a per-EBGP-session/group policy, that indicates whether the support a policy based on an External BGP (EBGP) session/group that indica
attribute is allowed and by default it is NOT allowed. tes whether the
attribute is allowed; by default, it is NOT allowed.
If it is not allowed, the BIER If it is not allowed, the BIER
attribute MUST NOT be sent to any EBGP peer of the session/group. attribute <bcp14>MUST NOT</bcp14> be sent to any EBGP peer of the session/
If a BIER attribute is received from the peer, it MUST be treated group.
exactly as if it were an unrecognized non-transitive attribute. If a BIER attribute is received from the peer, it <bcp14>MUST</bcp14> be t
That is, "it MUST be quietly ignored and not passed along to other reated
exactly as if it were an unrecognized non-transitive attribute.
<!--[rfced] Should a citation be added for the quoted text below? Or may
we remove the quotation marks?
Original:
If a BIER attribute is
received from the peer, it MUST be treated exactly as if it were an
unrecognized non-transitive attribute. That is, "it MUST be quietly
ignored and not passed along to other BGP peers".
-->
That is, "it <bcp14>MUST</bcp14> be quietly ignored and not passed alon
g to other
BGP peers".</t> BGP peers".</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has assigned codepoint 41 to the BIER attribute in the "BGP Path
Attributes" registry
<eref brackets="angle" target="https://www.iana.org/assignments/bgp-parame
ters"/> as follows:</t>
<table>
<thead>
<tr>
<th>Value</th>
<th>Code</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>41</td>
<td>BIER</td>
<td>RFC 9793</td>
</tr>
</tbody>
</table>
<t>IANA has created the "BGP BIER TLV and Sub-TLV Types" registry within t
he "Border Gateway Protocol (BGP) Parameters" registry group. The type field fo
r the
registry consists of 2 octets, with possible values from 0 to 65535
(the value 0 is reserved). The allocation policy for this field is
First Come First Served <xref target="RFC8126" format="default"/>.</t>
<t>The five initial values have been allocated as follows:</t>
<section anchor="IANA" title="IANA Considerations"> <table>
<t>IANA is requested to assign a codepoint TBD in the "BGP Path <thead>
Attributes" registry (https://www.iana.org/assignments/bgp-parameters/bgp- <tr>
parameters.xhtml#bgp-parameters-2) to the BIER attribute.</t> <th>Value</th>
<artwork align="center"><![CDATA[ <th>Name</th>
Value Name Reference <th>Reference</th>
===== ==== ========= </tr>
TBD BIER This document </thead>
]]></artwork> <tbody>
<t>IANA is requested to create a registry in the BGP Parameters registry <tr>
group for "BGP BIER TLV and SUB-TLV Types". <td>0</td> <td>Reserved</td> <td>RFC 9793</td>
The type field for the registry consists of two octets, with </tr>
possible values from 0 to 655355 (the value 0 is reserved). The <tr>
allocation policy for this field is to be "First Come First Serve" <td>1</td> <td>BIER TLV</td> <td>RFC 9793</td>
<xref target="RFC8126"/>. </tr>
</t> <tr>
<t> <td>2</td> <td>MPLS Encapsulation sub-TLV</td> <td>RFC 9793</td>
Five initial values are to be allocated from the "BGP BIER TLV and Sub-TLV </tr>
Types" registry as follows: <tr>
<artwork align="center"><![CDATA[ <td>3</td> <td>non-MPLS Encapsulation sub-TLV</td> <td>RFC 9793</td>
Value Name Reference </tr>
===== ==== ========= <tr>
0 Reserved This document <td>4</td> <td>BIER Nexthop sub-TLV</td> <td>RFC 9793</td>
1 BIER TLV This document </tr>
2 MPLS Encapsulation sub-TLV This document <tr>
3 non-MPLS Encapsulation sub-TLV This document <td>5-65535</td> <td colspan="2">Unassigned</td>
4 BIER Nexthop sub-TLV This document </tr>
5-65535 Unassigned </tbody>
]]></artwork> </table>
</t>
</section>
<section anchor="Security" title="Security Considerations"> </section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>This document introduces no new security considerations beyond those <t>This document introduces no new security considerations beyond those
already discussed in <xref target="RFC4271"/> and <xref target="RFC8279"/> already discussed in <xref target="RFC4271" format="default"/>, <xref
and the target="RFC8279" format="default"/>, and the operational considerations
operational considerations (<xref target="op"/>) of this document.</t> (<xref target="op" format="default"/>) of this document.</t>
</section> </section>
<section title="Contributors"> </middle>
<t>This document has the following contributors: <back>
<artwork> <displayreference target="I-D.ietf-bier-prefix-redistribute" to="BIER-Prefix
Zheng Zhang -Redistribute"/>
ZTE <references>
zhang.zheng@zte.com.cn <name>References</name>
</artwork> <references>
</t> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
279.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
296.xml"/>
</references>
<references>
<name>Informative References</name>
<!-- [I-D.ietf-bier-prefix-redistribute] IESG State: I-D Exists as of 1/9/25. --
>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-bier-prefix-redistribute.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
760.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
606.xml"/>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Eric Rosen"/> and <contact
fullname="Peter Psenak"/> for their valuable comments on this
document.</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements"> <section numbered="false" toc="default">
<t>Thanks a lot for Eric Rosen and Peter Psenak for their <name>Contributors</name>
valuable comments on this document.</t> <t>This document has the following contributor:</t>
<contact fullname="Zheng (Sandy) Zhang">
<!----> <organization>ZTE</organization>
<address>
<email>zhang.zheng@zte.com.cn</email>
</address>
</contact>
</section> </section>
</back>
</middle> <!-- [rfced] Some author comments are present in the XML. Please confirm
that no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->
<back> <!--[rfced] Acronyms
<references title="Normative References">
&RFC2119; a) Both the expansion and the acronym for the following terms are used
&RFC8174; throughout the document. After the first expansions, would you like
&RFC4271; to use only the acronyms for consistency and per the guidance from
&RFC8279; the "Web Portion of the Style Guide"
&RFC8296; <https://www.rfc-editor.org/styleguide/part2/#ref_repo>?
</references>
BFR Neighbor (BFR-NBR)
Set Identifier (SI)
b) Per RFC 8279, may we update the following acronym expansions to the
latter form listed for consistency?
BFER = BIER Forwarding Egress Router > Bit-Forwarding Egress Router
BFR = BIER Forwarding Router > Bit-Forwarding Router
BIFT = BIER Forwarding Table > Bit Index Forwarding Table
BFR-id = BIER Forwarding Router Identifier, BIER Forwarding Router
identifier > BFR Identifier
c) FYI - We have added an expansion for the following abbreviation per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion
in the document carefully to ensure correctness.
External BGP (EBGP)
-->
<!-- [rfced] Terminology
a) Throughout the text, the following terminology appears to be used
inconsistently. May we update to the latter form listed for consistency?
BIER Attribute > BIER attribute
BIER Path Attribute > BIER path attribute
MPLS encapsulation sub-TLV, MPLS encapsulation Sub-TLV, MPLS Encapsulation
Sub-TLV, Encapsulation sub-TLV > MPLS Encapsulation sub-TLV (per IANA)
non-MPLS encapsulation sub-TLV, non-MPLS encapsulation Sub-TLV >
non-MPLS Encapsulation sub-TLV (per IANA)
Nexthop sub-TLV > BIER Nexthop sub-TLV (per IANA)
b) The following terminology appears to be used inconsistently throughout
the text. Please review and let us know if/how they may be made consistent.
Nexthop vs. nexthop
[Note that RFCs 4271, 7606, 8279, and 8296 use "next hop" (for general use).]
Sub-domain vs. sub-domain
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
<references title="Informative References">
<?rfc include='reference.I-D.ietf-bier-prefix-redistribute.xml'?>
&RFC8126;
&RFC4760;
&RFC7606;
</references>
</back>
</rfc> </rfc>
 End of changes. 102 change blocks. 
470 lines changed or deleted 609 lines changed or added

This html diff was produced by rfcdiff 1.48.