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 tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?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>
<title abbrev="BGP Extensions for BIER">BGP Extensions for BIER</title>
<author fullname="Xiaohu Xu" initials="X.X." surname="Xu"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<organization>China Mobile</organization> tf-bier-idr-extensions-19" number="9793" ipr="trust200902" consensus="true" obso
letes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDep
th="3" symRefs="true" sortRefs="true" version="3">
<front>
<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="June" year="2025"/>
<abstract> <area>RTG</area>
<workgroup>bier</workgroup>
<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
the BIER-specific information and the methods for calculating BIER information and methods for calculating BIER states based on the
forwarding states with this information. More advertisements. 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 Bit-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
where BGP instead of IGP is used as an underlay <xref target="RFC7938"/>.
These
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-->
</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>Bit-Forwarding Router</dd>
<t>BSL: BitStringLength</t> <dt>BFR-ID:</dt><dd>BFR 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>Bit Index Forwarding Table</dd>
<t>BFER: BIER Forwarding Egress Router</t> <dt>BIFT-id:</dt><dd>Bit Index Forwarding Table Identifier</dd>
<t>BFR-prefix: Each BFR is assigned a single "BFR-prefix" for each <dt>BFER:</dt><dd>Bit-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>
</dl>
<section>
<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>
<section anchor="attr" numbered="true" toc="default">
<section title="BIER Path Attribute" anchor="attr"> <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>
<dt>Length:</dt><dd>2 octets encoding the length in octets of the
<t>Length: Two octets encoding the length in octets of the Value Value part.</dd>
part.</t> <dt>Sub-domain:</dt><dd>A
1-octet field encoding the sub-domain ID corresponding to the
<t>Sub-domain <xref target="RFC8279"/>: a one-octet field encoding the BFR-ID (see <xref target="RFC8279" format="default"/>).</dd>
sub-domain ID <dt>BFR-ID:</dt><dd>A
corresponding to the BFR-ID.</t> 2-octet field encoding the BFR-ID (see <xref target="RFC8279" format="de
fault"/>).</dd>
<t>BFR-ID <xref target="RFC8279"/>: a two-octet field encoding the BFR <dt>Reserved:</dt><dd><bcp14>SHOULD</bcp14> be set to 0 on
-ID.</t> transmission and <bcp14>MUST</bcp14> be ignored on reception.</dd>
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ign <dt>Sub-TLVs:</dt><dd>Contains one or more sub-TLVs.</dd>
ored on </dl>
reception.</t> <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
<t>Sub-TLVs: contains one or more sub-TLV.</t>
</list>
<t>The BIER TLV MAY appear multiple times in the BIER Path
Attribute, one for each sub-domain. There MUST 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">
The BIER MPLS Encapsulation Sub-TLV has the following format: <name>BIER MPLS Encapsulation Sub-TLV</name>
<artwork align="center"><![CDATA[ <t>The BIER MPLS Encapsulation sub-TLV has the following format.
It <bcp14>MAY</bcp14> appear multiple times in the BIER TLV.
0 1 2 3 </t>
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 <t>
The BIER MPLS Encapsulation sub-TLV has the following format:
</t>
<artwork align="center" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (see <xref section="1" sectionFormat="of" target="RFC8279"
format="default"/>) used in the encapsulation for this BIER
Length: Two octets encoding the length in octets of the Value sub-domain for this BitString length.</dd>
part. The value is 4 or other (depending on sub-TLVs) <dt>BS Len:</dt><dd>BitString Length. A 4-bit field encoding the
</t> supported BitString length associated with this BFR-prefix. The
<t> values allowed in this field are specified in <xref section="2" section
Format="of"
Max SI: A 1-octet field encoding the maximum Set Identifier (SI) target="RFC8296" format="default"/>.</dd>
(see Section 1 of <xref target="RFC8279"/>) used in the encapsulation for <dt>Label:</dt><dd>A 20-bit value representing the first label in the l
this abel range.</dd>
BIER sub-domain for this BitString length. </dl>
</t> <t> The "label range" is the set of labels beginning with the Label
<t> and ending with (Label + (Max SI)). A unique label range is allocated
for each BitString length and sub-domain-id. These labels are used
BS Len (BitString Length): A 4-bit field encoding the supported for BIER forwarding, as described in <xref target="RFC8279"
BitString length associated with this BFR-prefix. The values format="default"/> and <xref target="RFC8296" format="default"/>.
allowed in this field are specified in Section 2 of <xref target="RFC8296" </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"/
<t> >) that are used
in the network. Each SI maps to a single label in the label range:
Label: A 20-bit value representing the first label in the label range. the first label is for SI=0, the second label is for SI=1, etc.
</t> </t>
</list></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
20-bit range, the BIER MPLS Encapsulation Sub-TLV containing the
error MUST be ignored.
</t>
<t>
If the same BitString length is repeated in multiple BIER MPLS If the label associated with the Maximum SI exceeds the
Encapsulation Sub-TLVs inside the same BIER TLV, all BIER MPLS 20-bit range, the BIER MPLS Encapsulation sub-TLV containing the
Encapsulation Sub-TLVs in the BIER TLV MUST be ignored. error <bcp14>MUST</bcp14> be ignored.
</t> </t>
<t> <t>
Label ranges within all BIER MPLS Encapsulation Sub-TLVs advertised If the same BitString length is repeated in multiple BIER MPLS Encapsulation
by the same BFR MUST NOT overlap. If an overlap is detected, all sub-TLVs inside the same BIER TLV, all BIER MPLS Encapsulation sub-TLVs in the B
BIER MPLS Encapsulation Sub-TLVs advertised by the BFR MUST be ignored. IER TLV <bcp14>MUST</bcp14> be ignored.
</t> </t>
</section> <t>
<section title="BIER Non-MPLS Encapsulation sub-TLV"> Label ranges within all BIER MPLS Encapsulation sub-TLVs advertised
<t>The BIER non-MPLS Encapsulation sub-TLV is used for non-MPLS encapsulat by the same BFR <bcp14>MUST NOT</bcp14> overlap. If an overlap is detected,
ion and has the following format. It MAY appear multiple times within a all
BIER MPLS Encapsulation sub-TLVs advertised by the BFR <bcp14>MUST</bcp14> be
ignored.
</t>
</section>
<section numbered="true" toc="default">
<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 SI
<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 SI 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 Encapsulat
encapsulation sub-TLV may overlap with the Label value in the ion 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 Bit-Forwarding Egress Router (BFER) <bcp14>MUST</bcp14> attach a BIER
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 next hop when calculating BIF
. T.
</t> </t>
<!--t>A BFR/BFER MAY attach a BIER proxy range sub-TLV <t>When a BFR receives an update with the BIER path attribute, the
<xref target="I-D.ietf-bier-prefix-redistribute"/> in the BIER TLV. attribute is parsed with the following validations:</t>
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 <ul spacing="normal">
BFR/BFER's address, and a host BIER prefix NLRI MUST be originate <li><t>Syntactic checking based on the Length field of TLVs and sub-TLVs
d :</t>
for the BFR/BFER. <ul spacing="normal">
Other than this case, <li>The total length of BIER TLVs (including the Type and Length
<t>A BFR that is not a BFER (i.e., its BFR-ID is 0) fields) <bcp14>MUST</bcp14> be equal to the BIER path attribute
SHOULD NOT attach a BIER attribute to its own BIER prefix NLRIs length.</li>
(if a BIER attribute is attached it will not get used anyway). <li>The total length of sub-TLVs (including the Type and Length
</t> fields) of a TLV <bcp14>MUST</bcp14> be equal to the length of the
a BFR receiving a non-host BIER prefix without the BIER proxy ran TLV.</li>
ge </ul>
sub-TLV SHOULD perform an "attribute discard" action </li>
<xref target="RFC7606"/> about the BIER attribute. <li>Semantic checking as per <xref target="attr" format="default"/>.</li
</t--> >
<t>When a BFR receives an update with the BIER path attribute, </ul>
the attribute is parsed with the following validations: <t>
<list style="symbols">
<t>Syntactic checking based on the length field of TLVs and sub
-TLVs:
<list>
<t>The total length of BIER TLVs (including the type and
length
fields) MUST equal to the BIER path attribute length.</t>
<t>The total length of sub-TLVs (including the type and l
ength
fields) of a TLV MUST equal to the length of the TLV.</t>
</list>
</t>
<t>Semantic checking as per <xref target="attr"/>.</t>
</list>
</t>
<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,
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 BIER Nexthop sub-TLV. If there is no BIER Nexthop sub-TLV at all,
The entry's BFR Neighbor is the BIER prefix itself. The BIER label the entry's BFR-NBR 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 next hop.
</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. next hop. 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
BGP peers".</t> exactly as if it were an unrecognized non-transitive attribute.
That is, it <bcp14>MUST</bcp14> be quietly ignored and not passed along
to other
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">
<t>This document introduces no new security considerations beyond those
already discussed in <xref target="RFC4271"/> and <xref target="RFC8279"/>
and the
operational considerations (<xref target="op"/>) of this document.</t>
</section>
<section title="Contributors">
<t>This document has the following contributors:
<artwork>
Zheng Zhang
ZTE
zhang.zheng@zte.com.cn
</artwork>
</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements"> <section anchor="Security" numbered="true" toc="default">
<t>Thanks a lot for Eric Rosen and Peter Psenak for their <name>Security Considerations</name>
valuable comments on this document.</t> <t>This document introduces no new security considerations beyond those
already discussed in <xref target="RFC4271" format="default"/>, <xref
<!----> target="RFC8279" format="default"/>, and the operational considerations
(<xref target="op" format="default"/>) of this document.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-bier-prefix-redistribute" to="BIER-Prefix
&RFC2119; -Redistribute"/>
&RFC8174; <references>
&RFC4271; <name>References</name>
&RFC8279; <references>
&RFC8296; <name>Normative References</name>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.I-D.ietf-bier-prefix-redistribute.xml'?> 174.xml"/>
&RFC8126; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
&RFC4760; 271.xml"/>
&RFC7606; <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>
<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> </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 numbered="false" toc="default">
<name>Contributors</name>
<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>
</back> </back>
</rfc> </rfc>
 End of changes. 95 change blocks. 
517 lines changed or deleted 504 lines changed or added

This html diff was produced by rfcdiff 1.48.