Network Working Group H. Chen, Ed.
Internet-Draft M. McBride
Intended status: Informational Futurewei
Expires: 28 August 2025 S. Lindner
M. Menth
University of Tuebingen
A. Wang
China Telecom
G. Mishra
Verizon Inc.
24 February 2025
BIER Fast ReRoute
draft-ietf-bier-frr-07
Abstract
This document describes a mechanism for Fast Reroute (FRR) in Bit
Index Explicit Replication (BIER) networks. The proposed solution
enhances the resiliency of BIER by providing a method to quickly
reroute traffic in the event of a link or node failure, thereby
minimizing packet loss and service disruption. The document details
the procedures for detecting failures and selecting backup paths
within the BIER domain, ensuring that multicast traffic continues to
reach its intended destinations without requiring per-flow state or
additional signaling. This FRR mechanism is designed to integrate
seamlessly with existing BIER operations, offering a robust solution
for improving network reliability.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Chen, et al. Expires 28 August 2025 [Page 1]
Internet-Draft BIER FRR February 2025
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 August 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definition of BIER-FRR . . . . . . . . . . . . . . . . . . . 6
3.1. Definition of Forwarding Actions . . . . . . . . . . . . 6
3.2. Definition of Backup Forwarding Entries . . . . . . . . . 6
3.3. Activating and Deactivating Backup Forwarding Entries . . 7
3.4. Computation of the Backup F-BM . . . . . . . . . . . . . 8
4. Representations for BIER-FRR Forwarding Data . . . . . . . . 8
4.1. Potential Emergence of Redundant Packets . . . . . . . . 8
4.2. Primary BIFT and Single Backup BIFT . . . . . . . . . . . 10
4.3. Primary BIFT and Failure-Specific Backup BIFTs . . . . . 12
5. Protection Levels . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 13
5.2. Node Protection . . . . . . . . . . . . . . . . . . . . . 13
5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Backup Strategies . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Tunnel-Based BIER-FRR . . . . . . . . . . . . . . . . . . 14
6.1.1. Tunnel-Based BIER-FRR with Link Protection . . . . . 14
6.1.2. Tunnel-Based BIER-FRR with Node Protection . . . . . 16
6.2. LFA-based BIER-FRR . . . . . . . . . . . . . . . . . . . 17
6.2.1. Relation of BIER-LFAs to IP-LFAs and Prerequisites . 17
6.2.2. Definition of BIER-LFAs . . . . . . . . . . . . . . . 18
6.2.3. Protection Coverage of BIER-LFA Types . . . . . . . . 19
6.2.4. Sets of Supported BIER-LFAs . . . . . . . . . . . . . 20
6.2.5. Link Protection . . . . . . . . . . . . . . . . . . . 20
Chen, et al. Expires 28 August 2025 [Page 2]
Internet-Draft BIER FRR February 2025
6.2.6. Node Protection . . . . . . . . . . . . . . . . . . . 22
6.2.7. Optimization Potential to Reduce Redundant BIER Packets
in Failure Cases . . . . . . . . . . . . . . . . . . 23
7. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Comparison of LFA-Based Protection for IP-FRR and
BIER-FRR . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Advantages and Disadvantages of Tunnel-Based BIER-FRR . . 24
7.2.1. Advantages . . . . . . . . . . . . . . . . . . . . . 24
7.2.2. Disadvantages . . . . . . . . . . . . . . . . . . . . 25
7.3. Advantages and Disadvantages of LFA-Based BIER-FRR . . . 25
7.3.1. Advantages . . . . . . . . . . . . . . . . . . . . . 25
7.3.2. Disadvantages . . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Specific Backup Strategy Examples . . . . . . . . . 27
A.1. LFA-based BIER-FRR using Single BIFT . . . . . . . . . . 27
A.2. LFA-based BIER-FRR using Multiple Backup BIFTs . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
With BIER [RFC8279], a Bit-Forwarding Router (BFR) forwards BIER
packets based on a bitstring in the BIER header using the information
in the Bit Index Forwarding Table (BIFT). Its entries are locally
derived from a routing underlay or set by a controller. In case of a
persistent link or node failure, BIER traffic may not be delivered
until the BIFT has been updated based on the reconverged routing
underlay or by the controller.
Chen, et al. Expires 28 August 2025 [Page 3]
Internet-Draft BIER FRR February 2025
Typically, BIER packets are forwarded without an outer IP header.
Consequently, if a link or node failure occurs, the corresponding BFR
Neighbor (BFR-NBR) becomes unreachable. Fast Reroute (FRR)
mechanisms in the routing underlay, such as IP-FRR, apply exclusively
to IP packets, leading to potential loss of BIER traffic. BIER
traffic can only be restored after the routing underlay has
reconverged and the BIFT has been recalculated. Tunneling BIER
packets can serve as a solution to reach the BFR-NBR in the case of a
link failure by leveraging the FRR capabilities of the routing
underlay, provided such mechanisms are available. However, this
approach does not address node failures, as all destinations that
rely on the failed node as their BFR-NBR become unreachable. Given
that BIER often carries multicast traffic with real-time
requirements, there is a particular need to protect BIER traffic
against prolonged outages following failures.
This document introduces a nomenclature for Fast Reroute in BIER
(BIER-FRR). Upon detecting that a BFR-NBR is unreachable, BIER-FRR
enables a BFR to quickly reroute affected BIER packets using backup
forwarding entries. To avoid the generation of redundant packets,
backup forwarding entries should be processed before normal
forwarding entries. To achieve this, two potential representations
for backup forwarding entries are proposed.
The protection level offered by BIER-FRR can be either link
protection or node protection. Link protection is limited to
safeguarding against link failures and is simpler to implement but
may not be effective if a BFR itself fails. Node protection, while
more complex, also guards against the failure of BFRs. The choice of
backup strategy determines the selection of backup forwarding
entries.
Examples of backup strategies include tunnel-based BIER-FRR and Loop-
Free Alternate (LFA)-based BIER-FRR:
* Tunnel-based BIER-FRR: This approach leverages the mechanisms of
the routing underlay for FRR purposes. The routing underlay
typically restores connectivity faster than BIER, as the
reconvergence of the routing underlay is a prerequisite for the
recalculation of the BIFT. When the routing underlay utilizes FRR
mechanisms, its forwarding capabilities are restored well before
reconvergence is completed. To benefit from the rapid restoration
of the routing underlay, BIER traffic affected by a failure is
tunneled over the routing underlay.
* LFA-based BIER-FRR: This approach reroutes BIER traffic to
alternative neighbors in the event of a failure. It applies the
principles of IP-FRR, requiring that LFAs are also BFRs. Normal
Chen, et al. Expires 28 August 2025 [Page 4]
Internet-Draft BIER FRR February 2025
BIER-LFAs can be reached without tunneling, remote BIER-LFAs
employ a tunnel, and topology-independent BIER-LFAs use explicit
paths to reach the backup BFR-NBR. Unlike tunnel-based FRR, LFA-
based BIER-FRR does not depend on fast reroute mechanisms in the
routing underlay.
The BIER-FRR mechanism described in this document adheres to a
primary/backup path model, also known as 1:1 protection, which
contrasts with the 1+1 protection model, where traffic is duplicated
across both primary and backup paths, as explored for BIER in
[BrAl17].
2. Terminology
This document uses the following definitions:
BIER: Bit Indexed Explicit Routing
BIER FRR: Bit Indexed Explicit Routing Fast ReRoute
BFR: Bit-Forwarding Router
BFR-NBR: Bit-Forwarding Neighbor
BFIR: Bit-Forwarding Ingress Router
BFER: Bit-Forwarding Egress Router
BIFT: Bit Index Forwarding Table
F-BM: Forwarding Bit Mask
PLR: Point of Local Repair
LFA: Loop Free Alternate
BF-BM: Backup F-BM
BBFR-NBR: Backup BFR-NBR
BFA: Backup Forwarding Action
BEA: Backup Entry Active
Chen, et al. Expires 28 August 2025 [Page 5]
Internet-Draft BIER FRR February 2025
3. Definition of BIER-FRR
In this section, forwarding actions and backup forwarding entries are
defined. Then, the BIER forwarding process with BIER-FRR and the
computation of the backup F-BM are explained.
3.1. Definition of Forwarding Actions
A BFR-NBR is considered directly connected if it is a next hop at the
network layer, meaning it can be reached via link layer technology.
Conversely, if the BFR-NBR cannot be reached directly through the
link layer, it is regarded as indirectly connected.
The following forwarding actions are defined:
* Plain: The BIER packet is sent directly to a BFR-NBR via a direct
link without encapsulation in a tunnel header. This indicates
that the packet is not routed through the underlying network.
* Tunnel: The BIER packet is encapsulated with a tunnel header and
forwarded to a BFR-NBR over the routing underlay.
* Explicit: The packet is forwarded along an explicit path to a BFR-
NBR. The specific path information must be provided. If segment
routing is employed for this purpose, the segment IDs (SIDs) must
be specified. Two forwarding actions of type Explicit are
considered equivalent only if they utilize the same explicit path.
In the BIFT as outlined in [RFC8279], the forwarding actions are
implicitly determined by the connectivity status of the BFR-NBR. If
the BFR-NBR is directly connected, the forwarding action is Plain.
If the BFR-NBR is not directly connected, the forwarding action is
Tunnel.
3.2. Definition of Backup Forwarding Entries
The BIFT as proposed in [RFC8279] includes a Forwarding Bit Mask
(F-BM) and a BFR-NBR for a specific BFER. These elements constitute
a primary forwarding entry. The BIER-FRR (Fast Reroute) mechanism
extends the conventional BIFT by introducing additional columns that
contain backup forwarding entries. A backup forwarding entry
comprises the following components:
* Backup Forwarding Bit Mask (BF-BM)
* Backup BFR Neighbor (BBFR-NBR)
* Backup Forwarding Action (BFA)
Chen, et al. Expires 28 August 2025 [Page 6]
Internet-Draft BIER FRR February 2025
* Backup Entry Active (BEA) Flag
The BF-BM and BBFR-NBR share the same structure as their primary
counterparts. The BFA is defined as a forwarding action according to
Section 3.1. The BEA flag indicates whether the backup forwarding
entry is currently active. When active, the BF-BM, BBFR-NBR, and BFA
are utilized for forwarding BIER packets in place of the primary
forwarding entry. The structure of the extended BIFT is illustrated
in Figure 1.
+--------+------+---------+--------+----------+--------+----+
| BFR-id | F-BM | BFR-NBR | BF-BM | BBFR-NBR | BFA | BEA|
+========+======+=========+========+==========+========+====+
| ... | ... | ... | ... | ... | ... | |
+--------+------+---------+--------+----------+--------+----+
Figure 1: Structure of an extended BIFT with backup forwarding
entries.
The primary action is not explicitly stated in the BIFT, as it is
derived from the BFR-NBR. In contrast, the backup forwarding action
is explicitly defined in the extended BIFT. Additionally, in the
case of an Explicit forwarding action, the explicit path must be
indicated. However, since explicit paths are implementation-
specific, this information is not detailed in the table. The values
for the backup BFR-NBR and the backup action depend on the desired
level of protection and the chosen backup strategy. Examples of
these are provided in Section 6.1 and Section 6.2. The Backup
Forwarding Bit Mask (BF-BM) is determined based on the backup BFR-
NBR, and its computation is described in Section 3.4.
3.3. Activating and Deactivating Backup Forwarding Entries
When a primary BFR-NBR is not reachable over the implicit primary
action, a failure is observed. Then, the BEA flag of the
corresponding backup forwarding entry is set.
If the primary BFR-NBR is directly connected, the information about
the failed interface is sufficient to detect its unreachability. If
the primary BFR-NBR is indirectly connected, a BFD session between
the BFR as PLR and the BFR-NBR may be used to monitor its
reachability.
If the primary BFR-NBR is reachable again, the BEA flag is
deactivated. This may be caused by the disappearance of the failure
or by a change of the primary BFR-NBR due to a reconfiguration of the
BIFT.
Chen, et al. Expires 28 August 2025 [Page 7]
Internet-Draft BIER FRR February 2025
3.4. Computation of the Backup F-BM
The primary F-BM of a specific BFER identifies all BFERs that share
the same primary Bit-Forwarding Router Neighbor (BFR-NBR). The
backup F-BM for a specific BFER is computed to indicate:
* All BFERs that share both the primary and backup BFR-NBRs of the
specific BFER, and
* All BFERs for which the backup BFR-NBR of the specific BFER serves
as the primary BFR-NBR.
4. Representations for BIER-FRR Forwarding Data
To minimize the occurrence of redundant packets, it is essential that
backup entries are prioritized for use within the single extended
BIFT. However, implementing this priority may be challenging or
infeasible on certain hardware platforms. Consequently, two
alternative representations of forwarding entries are proposed. The
first representation involves a primary BIFT and a Single Backup BIFT
(SBB). The second representation comprises a primary BIFT along with
multiple Failure-Specific Backup BIFTs (FBB).
4.1. Potential Emergence of Redundant Packets
The BIER forwarding procedure in failure-free scenarios is designed
to avoid the generation of redundant packets, ensuring that at most a
single copy is transmitted per link for each BIER packet. However,
this property may be compromised when BIER-FRR, as described in
Section 3 is employed to provide protection against a failure.
Figure 2 presents an example of a BIER network. In this example,
BFRs are identified by the prefix "B" followed by their BFR-ids. For
simplicity, each BFR also serves as a BFER, and its bit position in
the bitstring corresponds to its BFR-id. The number assigned to each
link represents its cost, which the routing underlay uses to compute
the shortest paths.
Chen, et al. Expires 28 August 2025 [Page 8]
Internet-Draft BIER FRR February 2025
1 1
B1 --------- B6 ------------ B5 BFR Bi is BFER
| | | (i = 1,2,3,4,5,6,7;
| | | i is BFR-id of Bi)
2 | | 1 |
| 1 | | 1 cost of link B1-B2 is 2
B2 --------- B7 | cost of link B3-B4 is 4
| | cost of other links is 1
1 | |
| 4 |
B3 ------------------------- B4
Figure 2: BIER network example.
The extended BIFT with backup forwarding entries for LFA-based BIER-
FRR with link protection, as constructed by BFR B1, is illustrated in
Figure 3.
+------+----------+-------+----------+--------+----------+---+
|BFR-id| F-BM |BFR-NBR| BF-BM |BBFR-NBR| BFA |BEA|
+======+==========+=======+==========+========+==========+===+
| 2 | 0000110 | B2 | 1111110 | B6 | Plain | |
+------+----------+-------+----------+--------+----------+---+
| 3 | 0000110 | B2 | 1111110 | B6 | Plain | |
+------+----------+-------+----------+--------+----------+---+
| 4 | 1111000 | B6 | 1111110 | B2 | Plain | |
+------+----------+-------+----------+--------+----------+---+
| 5 | 1111000 | B6 | 1111110 | B2 | Plain | |
+------+----------+-------+----------+--------+----------+---+
| 6 | 1111000 | B6 | 1111110 | B2 | Plain | |
+------+----------+-------+----------+--------+----------+---+
| 7 | 1111000 | B6 | 1111110 | B2 | Plain | |
+------+----------+-------+----------+--------+----------+---+
Figure 3: B1's extended BIFT for LFA-based FRR with link protection.
The emergence of redundant packets during a failure scenario is
demonstrated as follows. Consider the extended BIFT for BFR B1
depicted in Figure 3. This BIFT includes backup forwarding entries
for LFA-based FRR with link protection. In a failure-free scenario,
when forwarding a BIER packet destined for B2 and B6 (bitstring
0100010), BFR B1 sends a single copy of the packet on the link B1-B2
and another on the link B1-B6.
Chen, et al. Expires 28 August 2025 [Page 9]
Internet-Draft BIER FRR February 2025
In the event of a failure on link B1-B6, BFR B1, acting as the PLR,
detects the failure. Consequently, B1 sets the BEA flag for all
destinations that have B6 as their BFR-NBR. If B1 is to send a BIER
packet to B2 and B6 under these conditions, it first sends a copy
with bitstring 0000010 to B2 using the corresponding primary
forwarding entry in the extended BIFT shown in Figure 3.
Subsequently, B1 sends another copy of the packet with bitstring
0100000 to B2 for B6, using the backup forwarding entry, since the
BEA flag is activated.
This results in a second (redundant) copy being sent over the same
link B1-B2. This redundancy can be avoided if the backup forwarding
entry is prioritized. By using the backup forwarding entry first, B1
would send only a single copy of the packet with bitstring 0100010 to
B2, and no additional copy would be sent to B2, as the bitstring in
the packet would be cleared by the BF-BM 1111110. Therefore,
prioritizing the processing of BFERs with unreachable BFR-NBRs helps
to reduce the generation of redundant packet copies.
4.2. Primary BIFT and Single Backup BIFT
The extended BIFT can be divided into two distinct BIFTs: one serving
as the primary BIFT, and the other as a single backup BIFT. The
primary BIFT functions in the same manner as the regular BIFT. The
backup BIFT, however, contains the backup forwarding entries,
including the BBF-BM, BBFR-NBR, BFA, and BEA flag from the extended
BIFT. When a BFR, acting as the PLR, detects that a BFR-NBR has
become unreachable, it activates the BEA flag for all BFERs in the
backup BIFT that have the affected BFR-NBR as their primary BFR-NBR.
When forwarding a BIER packet, the BFR processes the packet using the
backup BIFT first, followed by the primary BIFT. This prioritization
helps to reduce the number of redundant packet copies.
B1's extended BIFT from Figure 3 is divided into the primary BIFT
shown in Figure 4 and the single backup BIFT shown in Figure 5.
Chen, et al. Expires 28 August 2025 [Page 10]
Internet-Draft BIER FRR February 2025
+--------+---------+---------+
| BFR-id | F-BM | BFR-NBR |
+========+=========+=========+
| 2 | 0000110 | B2 |
+--------+---------+---------+
| 3 | 0000110 | B2 |
+--------+---------+---------+
| 4 | 1111000 | B6 |
+--------+---------+---------+
| 5 | 1111000 | B6 |
+--------+---------+---------+
| 6 | 1111000 | B6 |
+--------+---------+---------+
| 7 | 1111000 | B6 |
+--------+---------+---------+
Figure 4: B1's primary BIFT for the BIER network example.
+------+----------+--------+-----------+---+-----------------+
|BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
| | | | | | failure of |
+======+==========+========+===========+===+=================+
| 2 | 1111110 | B6 | Plain | | Link B1->B2 |
+------+----------+--------+-----------+---+-----------------+
| 3 | 1111110 | B6 | Plain | | Link B1->B2 |
+------+----------+--------+-----------+---+-----------------+
| 4 | 1111110 | B2 | Plain | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
| 5 | 1111110 | B2 | Plain | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
| 6 | 1111110 | B2 | Plain | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
| 7 | 1111110 | B2 | Plain | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
Figure 5: B1's backup BIFT for the BIER network example.
Each forwarding entry in the backup BIFT includes the BF-BM, BBFR-
NBR, BFA, and BEA. When a BFR-NBR fails, the BEA flag is activated
for all BFERs in the backup BIFT that have the affected BFR-NBR as
their primary BFR-NBR. For instance, BFERs B4, B5, B6, and B7 have
BFR-NBR B6 as their primary BFR-NBR. If BFR-NBR B6 fails, the BEA
flag for BFERs B4, B5, B6, and B7 is activated, setting the BEA in
the last four entries in the backup BIFT to one.
Chen, et al. Expires 28 August 2025 [Page 11]
Internet-Draft BIER FRR February 2025
4.3. Primary BIFT and Failure-Specific Backup BIFTs
As an alternative to the single extended BIFT, the information can be
represented using a primary BIFT along with several failure-specific
backup BIFTs. A failure-specific backup BIFT is associated with the
unreachability of a particular BFR-NBR. A backup BIFT for the
failure of BFR-NBR N is simply referred to as a backup BIFT for N.
This backup BIFT mirrors the structure of the regular BIFT but
includes entries for backup forwarding actions. Therefore, a BFR
maintains a primary BIFT, identical to the regular BIFT, and a
separate backup BIFT for each of its BFR-NBRs.
Under normal, failure-free conditions, the BFR utilizes the primary
BIFT to forward BIER packets. Upon detecting that BFR-NBR N has
become unreachable, the BFR, acting as the PLR, switches to the
backup BIFT for N to forward all BIER packets. Once the routing
underlay has re-converged to reflect the updated network topology,
the primary BIFT is re-computed. The newly computed primary BIFT is
then reinstated for forwarding all BIER packets.
This concept can be illustrated using the example of the extended
BIFT in Figure 3. Figure 4 depicts B1's primary BIFT in this
context. BFR B1 in Figure 2 has two neighbors: B6 and B2.
Consequently, B1 maintains two backup BIFTs with link protection: one
for B6 and another for B2. Additionally, B1 also maintains two
backup BIFTs with node protection. Figure 6 represents B1's backup
BIFT for B6, which is utilized in response to the unreachability of
B6, functioning similarly to the extended BIFT shown in Figure 3.
+--------+---------+---------+-----------------+-----------------+
| BFR-id | F-BM | BFR-NBR |Forwarding Action|Comment: protects|
| | | | | failure of |
+========+=========+=========+=================+=================+
| 2 | 1111110 | B2 | Plain | |
+--------+---------+---------+-----------------+-----------------+
| 3 | 1111110 | B2 | Plain | |
+--------+---------+---------+-----------------+-----------------+
| 4 | 1111110 | B2 | Plain | Link B1->B6 |
+--------+---------+---------+-----------------+-----------------+
| 5 | 1111110 | B2 | Plain | Link B1->B6 |
+--------+---------+---------+-----------------+-----------------+
| 6 | 1111110 | B2 | Plain | Link B1->B6 |
+--------+---------+---------+-----------------+-----------------+
| 7 | 1111110 | B2 | Plain | Link B1->B6 |
+--------+---------+---------+-----------------+-----------------+
Figure 6: B1's backup BIFT for B6 for LFA-based BIER FRR with
link protection.
Chen, et al. Expires 28 August 2025 [Page 12]
Internet-Draft BIER FRR February 2025
Once B1, as the PLR, detects that B6 has become unreachable via the
link to B6, it switches to the backup BIFT for B6 to forward all BIER
packets. Since this representation aligns with the concept of a
single primary and single backup BIFT, the occurrence of redundant
packets for the same forwarding action is avoided.
5. Protection Levels
Both link protection and node protection may be supported. Link
protection is designed to safeguard against the failure of an
adjacent link, whereas node protection addresses the failure of a
neighboring node and the associated path leading to that node. The
relevance of link or node protection depends on the specific service
being supported. Additionally, both protection levels can be
combined with any of the backup strategies outlined in Section 6.
5.1. Link Protection
In link protection, the backup path is designed to circumvent the
failed link (i.e., the failed primary path from the PLR to the
primary BFR-NBR), while still potentially including the primary BFR-
NBR itself. Consequently, the backup path remains operational even
if the primary path fails. The primary limitation of link protection
is its inability to provide protection if the primary BFR-NBR itself
becomes inoperative. However, link protection also offers certain
advantages. It typically results in shorter backup paths compared to
node protection. In the case of tunnel-based BIER-FRR, link
protection generates at most one redundant packet, whereas node
protection may result in multiple redundant packets. Additionally,
for LFA-based BIER-FRR, link protection is more effective in
safeguarding a greater number of BFERs using normal BIER-LFAs than
node protection.
5.2. Node Protection
In node protection, the backup path is designed to avoid both the
failed node and the link to that node (i.e., the failed primary path
from the PLR to the primary BFR-NBR, including the primary BFR-NBR).
Consequently, the backup path must exclude both the primary path and
the primary BFR-NBR to remain operational in the event of their
failure. If a BFER and its primary BFR-NBR are the same, only link
protection is feasible for that BFER. The primary advantage of node
protection is its enhanced protection quality compared to link
protection. However, node protection also has certain drawbacks. It
typically results in longer backup paths than link protection. In
the context of tunnel-based BIER-FRR, node protection may lead to the
transmission of a greater number of redundant packets over a link
than with link protection. Furthermore, for LFA-based BIER-FRR,
Chen, et al. Expires 28 August 2025 [Page 13]
Internet-Draft BIER FRR February 2025
fewer BFERs may be protected using normal BIER-LFAs, necessitating
the use of more remote or topology-independent BIER-LFAs, which are
inherently more complex.
5.3. Example
In the network depicted in Figure 2, the primary path from BFR B1 to
BFER B5 is B1-B6-B5. Protecting BFER B5 from a BFR-NBR B6 node
failure can only be provided through the backup path B1-B2-B3-B4-B5.
Link protection for BFER B5 is achieved via the backup path
B1-B2-B7-B6, and additionally through the backup path
B1-B2-B3-B4-B5-B6. The specific backup entries are determined by the
selected protection level and backup strategy. Example BIFTs
illustrating link and node protection are provided in Section 6.
6. Backup Strategies
Backup strategies determine the selection of backup forwarding
entries, influencing both the choice of the backup BFR-NBR and the
backup action, and consequently, the backup path. The following
sections present tunnel-based BIER-FRR and LFA-based BIER-FRR as
potential strategies.
6.1. Tunnel-Based BIER-FRR
The routing underlay may possess the capability to forward packets to
their destinations even in the presence of a failure, potentially due
to FRR mechanisms within the routing underlay. In such scenarios,
while the primary BFR-NBR may no longer be reachable via the primary
action (Plain), it could still be accessible through a backup action
(Tunnel).
Tunnel-based BIER-FRR encapsulates BIER packets impacted by a failure
within the routing underlay, thereby leveraging the routing
underlay's fast restoration capabilities. As soon as connectivity in
the routing underlay is reestablished, the affected BIER packets can
be forwarded to their intended destinations. The appropriate backup
forwarding entries in a BIFT for BIER-FRR are determined by the
desired protection level.
6.1.1. Tunnel-Based BIER-FRR with Link Protection
In the context of link protection, the backup BFR-NBRs are identical
to the primary BFR-NBRs. If a primary BFR-NBR is directly connected
to the BFR acting as the Point of Local Repair (PLR), the
corresponding backup forwarding action is Tunnel. Consequently, BIER
packets affected by a failure are tunneled through the routing
underlay to their BFR-NBR, rather than being directly sent as plain
Chen, et al. Expires 28 August 2025 [Page 14]
Internet-Draft BIER FRR February 2025
BIER packets. If the primary BFR-NBR is not directly connected to
the BFR as a PLR (i.e., the implicit primary action is Tunnel), the
corresponding backup action is also Tunnel. The backup F-BMs are
identical to the primary F-BMs, consistent with the computation of
backup F-BMs described in Section 3.4.
+------+----------+--------+-----------+---+-----------------+
|BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
| | | | | | failure of |
+======+==========+========+===========+===+=================+
| 2 | 0000110 | B2 | Tunnel | | Link B1->B2 |
+------+----------+--------+-----------+---+-----------------+
| 3 | 0000110 | B2 | Tunnel | | Link B1->B2 |
+------+----------+--------+-----------+---+-----------------+
| 4 | 1111000 | B6 | Tunnel | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
| 5 | 1111000 | B6 | Tunnel | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
| 6 | 1111000 | B6 | Tunnel | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
| 7 | 1111000 | B6 | Tunnel | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
Figure 7: B1's backup BIFT for tunnel-based BIER-FRR with link
protection.
Figure 7 illustrates B1's backup BIFT for tunnel-based BIER-FRR with
link protection in the BIER network example depicted in Figure 2.
The backup BFR-NBRs and backup F-BMs in this backup BIFT correspond
to the primary BFR-NBRs and primary F-BMs in the primary BIFT shown
in Figure 4. However, the backup actions in this backup BIFT are
Tunnel, while the primary actions in the primary BIFT are Plain
(which are not explicitly shown but implied).
When B1, acting as the PLR, detects a failure of its link to B6, a
BIER packet with the bitstring 0100000 destined for B6 is tunneled by
B1 through the routing underlay towards B6. The specific path of the
backup tunnel depends on the routing underlay and could be
B1-B2-B7-B6 or B1-B2-B3-B4-B5-B6.
If a BIER packet is destined for {B2, B5, B7}, an encapsulated packet
copy is first forwarded via link B1-B2 to backup BFR-NBR B6 using the
backup action Tunnel to deliver packet copies to BFERs B5 and B7.
Subsequently, a non-encapsulated packet copy is forwarded via link
B1-B2 to BFR-NBR B2 using the primary action Plain to deliver a
packet copy to BFER B2. Therefore, with tunnel-based BIER-FRR, a
single redundant packet copy may occur in the event of a failure
because an encapsulated and a non-encapsulated packet copy are
Chen, et al. Expires 28 August 2025 [Page 15]
Internet-Draft BIER FRR February 2025
forwarded over the same link. This redundancy occurs even though
BIER packets affected by failures are forwarded before those
unaffected by failures.
A BIER packet with the bitstring 1000000 destined for B7 is forwarded
along the backup path B1-B2-B7-B6-B7, as it is first delivered to the
backup BFR-NBR B6. Consequently, the backup path may be
unnecessarily long. This phenomenon is similar to the facility
backup method described in [RFC4090] which employs paths analogous to
those in tunnel-based BIER-FRR..
6.1.2. Tunnel-Based BIER-FRR with Node Protection
To determine the backup forwarding entries for node protection, a
case-by-case analysis of the BFER to be protected is required. If
the BFER is the same as its primary BFR-NBR, node protection is not
feasible for that BFER. In such cases, link protection is applied,
meaning the backup BFR-NBR is set to the primary BFR-NBR. If this
level of protection is deemed insufficient, egress protection as
described in [I-D.chen-bier-egress-protect] may be applied.If the
BFER is different from its primary BFR-NBR, the backup BFR-NBR is set
to the primary BFR-NBR's primary BFR-NBR for that BFER, making the
backup BFR-NBR a next-next-hop BFR. In all scenarios, the backup
action is Tunnel. In the first case, the backup F-BM is set to all
zeros with the bit for the BFER to be protected enabled. In the
second case, the backup F-BM is computed as described in Section 3.4.
+------+----------+--------+----------+---+-----------------+
|BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
| | | | | | failure of |
+======+==========+========+==========+===+=================+
| 2 | 0000010 | B2 | Tunnel | | Link B1->B2 |
+------+----------+--------+----------+---+-----------------+
| 3 | 0000100 | B3 | Tunnel | | BFR-NBR B2 |
+------+----------+--------+----------+---+-----------------+
| 4 | 0011000 | B5 | Tunnel | | BFR-NBR B6 |
+------+----------+--------+----------+---+-----------------+
| 5 | 0011000 | B5 | Tunnel | | BFR-NBR B6 |
+------+----------+--------+----------+---+-----------------+
| 6 | 0100000 | B6 | Tunnel | | Link B1->B6 |
+------+----------+--------+----------+---+-----------------+
| 7 | 1000000 | B7 | Tunnel | | BFR-NBR B6 |
+------+----------+--------+----------+---+-----------------+
Figure 8: B1's backup BIFT for tunnel-based BIER-FRR with node
protection.
Chen, et al. Expires 28 August 2025 [Page 16]
Internet-Draft BIER FRR February 2025
Figure 8 illustrates B1's backup BIFT for tunnel-based BIER-FRR with
node protection in the BIER network example provided in Figure 2.
BFERs B2 and B6 are direct neighbors of B1. To protect them, only
link protection is applied, as B1's primary BFR-NBR for these nodes
is the nodes themselves. As described above, only the bit for B2 is
set in the backup F-BM of B2, and similarly for B6. For BFER B5, the
backup BFR-NBR is B5, as it is B1's next-next-hop BFR towards B5.
Similarly, for BFER B7, the backup BFR-NBR is B7. When B1, acting as
the PLR, detects the failure of its BFR-NBR B6, a BIER packet with
bitstring 1010010 destined for {B2, B5, B7} is processed as follows:
an encapsulated copy of the packet is sent via tunnel B1-B2-B3-B4-B5,
another encapsulated copy is sent via tunnel B1-B2-B7, and a non-
encapsulated copy is sent via link B1-B2. In this example, two
redundant packets are sent over link B1-B2. Therefore, node
protection may result in more redundant packet copies than link
protection..
Caveat: If the routing underlay does not support node protection,
tunnel-based BIER-FRR will similarly be unable to provide node
protection. This limitation is illustrated in the following example.
In the network depicted in Figure 2, the underlay offers only link
protection. If BFR-NBR B6 fails and B1 must forward a packet to B5,
according to the backup BIFT in Figure 8 the packet is tunneled
towards B5. The underlay may route the packet along the path
B1-B2-B7-B6-B5 due to FRR with link protection. However, since B6 is
also unreachable from B7, the packet is returned to B2, resulting in
a loop between B2 and B7.
6.2. LFA-based BIER-FRR
LFA-based BIER-FRR leverages alternate BFRs to deliver BIER packets
to BFERs for which the primary BFR-NBR is unreachable. This approach
does not rely on any fast restoration or protection mechanisms in the
underlying routing infrastructure. First, the prerequisites for LFA-
based BIER-FRR are clarified, followed by the definition of BIER-
LFAs. Subsequently, link and node protection for LFA-based BIER-FRR
are discussed using a single backup BIFT.
6.2.1. Relation of BIER-LFAs to IP-LFAs and Prerequisites
A LFA for a specific destination is an alternate node to which a
packet is sent if the primary next hop for that destination is
unreachable. This alternate node should be capable of forwarding the
packet without creating a forwarding loop. LFAs have been defined
for IP networks in [RFC5286], [RFC7490] and
[I-D.ietf-rtgwg-segment-routing-ti-lfa], and such LFAs are referred
to as IP-LFAs. BIER-LFAs are similar to IP-LFAs, but a BIER-LFA node
must be a BFR. If only a subset of the nodes in the routing underlay
Chen, et al. Expires 28 August 2025 [Page 17]
Internet-Draft BIER FRR February 2025
are BFRs, some IP-LFAs in the routing underlay may not be usable as
BIER-LFAs. To compute BIER-LFAs, network topology and link cost
information from the routing underlay are required. This differs
from tunnel-based BIER-FRR, where knowledge of the primary BIFTs of a
PLR and its BFR-NBRs is sufficient.
LFA-based BIER-FRR may reuse IP-LFAs as BIER-LFAs under the following
conditions: if an IP-LFA node for the destination of a specific BFER
is a BFR, it may be reused as the backup BFR-NBR for that BFER, along
with the backup action applied for that IP-LFA at the IP layer. A
normal IP-LFA corresponds to the backup action Plain, a remote IP-LFA
to Tunnel, and a TI-IP-LFA to Explicit.
6.2.2. Definition of BIER-LFAs
As with IP-LFAs, there are several types of BIER-LFAs:
* A BFR is considered a normal BIER-LFA for a specific BFER if it is
directly connected to the PLR and:
1. the BFER can be reached from it through the BIER domain.
2. both the path from the PLR to the BFR and the path from the
BFR to the BFER are disjoint from the primary path from the
PLR to the primary BFR-NBR. These paths:
- may include the primary BFR-NBR for link protection.
- must not include the primary BFR-NBR for node protection.
* A BFR is considered a remote BIER-LFA for a specific BFER if it is
not directly connected to the PLR, can be reached via a tunnel
from the PLR, and satisfies the aforementioned conditions 1 and 2.
* A BFR is considered a TI-BIER-LFA for a specific BFER if it is not
directly connected to the PLR, cannot be reached via a tunnel from
the PLR, but is reachable from the PLR via an explicit path (e.g.,
with the assistance of a Segment Routing (SR) header), and
satisfies the aforementioned conditions 1 and 2.
For some BFERs, one or more normal BIER-LFAs may be available at a
specific PLR. For other BFERs, only remote or TI-BIER-LFAs may be
available. There may also be BFERs for which only TI-BIER-LFAs are
available.
The backup actions for rerouting BIER packets depending on the type
of BIER-LFA are:
Chen, et al. Expires 28 August 2025 [Page 18]
Internet-Draft BIER FRR February 2025
* For normal BIER-LFA: Plain
* For remote BIER-LFA: Tunnel
* For TI-BIER-LFA: Explicit
6.2.3. Protection Coverage of BIER-LFA Types
Protection coverage refers to the set of BFERs that can be protected
with a desired level of protection by a particular type of BIER-LFA.
The BIER-LFA types exhibit the following characteristics:
* Normal BIER-LFAs
- The protection coverage is the least, as some or many BFERs may
not be protected at the desired level or at all.
- Redundant packet copies are avoided.
- There is no encapsulation overhead.
* Remote BIER-LFAs
- They enhance the protection coverage of normal BIER-LFAs.
- Redundant packet copies may occur on a link, similar to tunnel-
based BIER-FRR.
- The encapsulation overhead is similar to that of tunnel-based
BIER-FRR.
* TI-BIER-LFAs
- They complement the protection coverage of normal and remote
BIER-LFAs to achieve 100% coverage.
- Redundant packets may occur on a link, similar to tunnel-based
BIER-FRR.
- The encapsulation overhead is similar or equivalent to that of
tunnel-based BIER-FRR, depending on the FRR mechanism employed
in the routing underlay.
Chen, et al. Expires 28 August 2025 [Page 19]
Internet-Draft BIER FRR February 2025
6.2.4. Sets of Supported BIER-LFAs
Normal BIER-LFAs are the simplest option, as they do not require
tunneling or explicit paths. Remote BIER-LFAs offer greater
capabilities but introduce additional header overhead and require
more functionality from the PLR. TI-BIER-LFAs are the most complex,
necessitating the use of explicit paths. When implementing LFA-based
BIER-FRR, it is essential to specify the set of supported BIER-LFAs.
The available options are as follows:
* Option 1: Only normal BIER-LFAs are supported.
* Option 2: Both normal and remote BIER-LFAs are supported.
* Option 3: All types of BIER-LFAs are supported.
6.2.5. Link Protection
In link protection, normal BIER-LFAs are prioritized over remote
LFAs, and remote BIER-LFAs are preferred over TI-BIER-LFAs.
Depending on the set of supported BIER-LFAs, it may not be possible
to protect all BFERs.
Figure 5 illustrates B1's backup BIFT for LFA-based BIER-FRR with
link protection, using the network example provided in Figure 2.
If the link between B1 and B6 fails, B1 cannot reach the BFERs B4,
B5, B6, and B7 via their primary BFR-NBR. Consequently, B1 forwards
their traffic via the backup BFR-NBR B2, along with the traffic for
B2 and B3, as B2 is their primary BFR-NBR. In this scenario, the
backup F-BM is set to 1111110. Similarly, if the link between B1 and
B2 fails, B1 routes all traffic to B6, with the backup F-BM also set
to 1111110.
B1 requires only normal BIER-LFAs to protect all BFERs. However,
this situation can vary significantly for other BFRs. Figure 9 and
Figure 10 present the backup BIFTs for B7 and B5, respectively. BFR
B7 requires one normal BIER-LFA, three remote BIER-LFAs, and two TI-
BIER-LFAs to protect all BFERs. BFR B5 requires one normal BIER-LFA,
one remote BIER-LFA, and four TI-BIER-LFAs as backup BFR-NBRs. Thus,
depending on the set of supported BIER-LFAs, it may not be possible
to protect all BFERs using BIER-FRR.
Chen, et al. Expires 28 August 2025 [Page 20]
Internet-Draft BIER FRR February 2025
Consider a scenario where B7 holds a BIER packet with destinations
{B1, B4, B5, B6}. If the link between B7 and B6 fails, the packet
copy for B1 is sent to B2 using the forwarding action Plain, the
packet copy for B4 is tunneled via B2 to B3, and the packet copies
for B5 and B6 are sent via explicit paths to B4 and B1, respectively.
Since these packet copies have different headers, all of them must be
transmitted, resulting in three redundant copies.
+------+----------+--------+-----------+---+-----------------+
|BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
| | | | | | failure of |
+======+==========+========+===========+===+=================+
| 1 | 0000111 | B2 | Plain | | Link B7->B6 |
+------+----------+--------+-----------+---+-----------------+
| 2 | 0000110 | B1 | Tunnel | | Link B1->B2 |
+------+----------+--------+-----------+---+-----------------+
| 3 | 0000110 | B1 | Tunnel | | Link B1->B2 |
+------+----------+--------+-----------+---+-----------------+
| 4 | 0001000 | B3 | Tunnel | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
| 5 | 0010000 | B4 | Explicit | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
| 6 | 0100000 | B1 | Explicit | | Link B1->B6 |
+------+----------+--------+-----------+---+-----------------+
Figure 9: B7's backup BIFT with link protection.
+------+----------+--------+-----------+---+-----------------+
|BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
| | | | | | failure of |
+======+==========+========+===========+===+=================+
| 1 | 1100011 | B3 | Explicit | | Link B5->B6 |
+------+----------+--------+-----------+---+-----------------+
| 2 | 1100011 | B3 | Explicit | | Link B5->B6 |
+------+----------+--------+-----------+---+-----------------+
| 3 | 0000100 | B4 | Plain | | Link B5->B6 |
+------+----------+--------+-----------+---+-----------------+
| 4 | 0001000 | B3 | Tunnel | | Link B5->B4 |
+------+----------+--------+-----------+---+-----------------+
| 6 | 1100011 | B3 | Explicit | | Link B5->B6 |
+------+----------+--------+-----------+---+-----------------+
| 7 | 1100011 | B3 | Explicit | | Link B5->B6 |
+------+----------+--------+-----------+---+-----------------+
Figure 10: B5's backup BIFT with link protection.
Chen, et al. Expires 28 August 2025 [Page 21]
Internet-Draft BIER FRR February 2025
6.2.6. Node Protection
To determine the backup forwarding entries for node protection, it is
necessary to conduct a case-by-case analysis of the BFER to be
protected. If the BFER is the same as its primary BFR-NBR, node
protection is not feasible for that BFER, and link protection must be
applied instead. In all other cases, the BFER should be protected by
a node-protecting BIER-LFA. In this context, normal BIER-LFAs are
prioritized over remote BIER-LFAs, and remote BIER-LFAs are preferred
over TI-BIER-LFAs. Depending on the set of supported BIER-LFAs, it
may not be possible to protect certain BFERs.
Figure 11 illustrates B1's backup BIFT for LFA-based BIER-FRR with
node protection, using the network example provided in Figure 2.
+------+----------+--------+-----------+---+-----------------+
|BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
| | | | | | failure of |
+======+==========+========+===========+===+=================+
| 2 | 1111010 | B6 | Plain | | BFR-NBR B2 |
+------+----------+--------+-----------+---+-----------------+
| 3 | 0000100 | B4 | Tunnel | | BFR-NBR B2 |
+------+----------+--------+-----------+---+-----------------+
| 4 | 0001000 | B3 | Tunnel | | BFR-NBR B6 |
+------+----------+--------+-----------+---+-----------------+
| 5 | 0010000 | B4 | Explicit | | BFR-NBR B6 |
+------+----------+--------+-----------+---+-----------------+
| 6 | 1100100 | B2 | Plain | | BFR-NBR B6 |
+------+----------+--------+-----------+---+-----------------+
| 7 | 1100100 | B2 | Plain | | BFR-NBR B6 |
+------+----------+--------+-----------+---+-----------------+
Figure 11: B1's backup BIFT with node protection.
As B6 serves as the primary BFR-NBR for BFER B6, only link protection
can be applied. Consequently, B2 is utilized as a normal, link-
protecting BIER-LFA to safeguard B6. Similarly, as B2 is the primary
BFR-NBR for BFER B2, B2 is protected with B6 as its normal, link-
protecting BIER-LFA. BFER B7 is protected against the failure of
node B6 by using B2 as its normal, node-protecting BIER-LFA, as B2
has a shortest path to B7 that does not traverse B6. The backup
F-BMs for BFERs B6 and B7 are set to {B2, B6, B7}, as traffic for
these BFERs is routed via link B1-B2 with the forwarding action Plain
when B6 is unreachable.
BFER B4 cannot be reached via a normal LFA when BFR B6 fails.
However, B3 serves as a remote, node-protecting BIER-LFA for BFER B4,
as B3 has a shortest path to B4, is reachable from B1 via a shortest
Chen, et al. Expires 28 August 2025 [Page 22]
Internet-Draft BIER FRR February 2025
path, and the resulting backup path from B1 to B4 does not traverse
B6. Similarly, B4 serves as a remote LFA for BFER B3 if BFR B2
fails.
BFER B5 is neither reachable through a normal BIER-LFA nor through a
remote BIER-LFA when BFR B6 fails. However, B4 acts as a node-
protecting TI-LFA for BFER B5, as B4 has a shortest path to B5 that
does not traverse B6. Additionally, B4 is reachable through the
explicit path B1-B2-B3-B4.
6.2.7. Optimization Potential to Reduce Redundant BIER Packets in
Failure Cases
Redundant packets can occur with LFA-based BIER-FRR when BIER packets
are transmitted over a specific link in different forms, including:
* Plain BIER packets (either primary transmission or reroute to a
normal BIER-LFA).
* BIER packets encapsulated for transmission to a specific BFR-NBR
(either tunneled primary transmission or reroute to a remote BIER-
LFA).
* BIER packets routed with an encoded explicit path (reroute to a
TI-LFA).
When different remote LFAs are utilized, multiple redundant packets
may be generated through remote LFAs. A similar situation can arise
with TI-LFAs. However, some redundant packets can be mitigated if
remote LFAs or TI-LFAs are selected such that they can protect
multiple BFERs, thereby reducing the need for additional remote LFAs
or TI-LFAs. This approach, while potentially leading to longer
backup paths, introduces a new optimization objective for the
selection of remote or TI-BIER-LFAs, which does not exist in IP-FRR.
The relevance of this optimization may vary depending on the specific
use case.
To illustrate this optimization potential, consider LFA-based BIER-
FRR with link protection for B7, as described in its backup BIFT in
Figure 9. As noted in Section 6.2.5, B7 needs to transmit four
copies to forward a packet to {B1, B4, B5, B6}. If the more complex
TI-BIER-LFA B4 is chosen to protect BFER B4 instead of the remote
BIER-LFA B3, only two redundant copies need to be transmitted.
Chen, et al. Expires 28 August 2025 [Page 23]
Internet-Draft BIER FRR February 2025
7. Comparison
This section first addresses the differences between IP-LFAs for IP-
FRR and BIER-LFAs for BIER-FRR. It then examines the advantages and
disadvantages of tunnel-based and LFA-based BIER-FRR.
7.1. Comparison of LFA-Based Protection for IP-FRR and BIER-FRR
LFAs were initially proposed for IP networks. They are
straightforward in that they do not require any tunneling overhead.
However, certain destinations cannot be protected against specific
link failures, and even more destinations may be unprotected against
certain node failures. To improve coverage, remote LFAs (R-LFAs)
were introduced, which tunnel affected traffic to another node from
which the traffic can reach the destination through normal
forwarding. Despite this, there may still be destinations that
remain unprotected against link or node failures. To address this,
topology-independent LFAs (TI-LFAs) were developed, wherein affected
traffic is tunneled via an explicit path (preferably using segment
routing headers) to another node from which the traffic can reach its
destination through standard IP forwarding. With TI-LFAs, all
destinations can be protected against any failures as long as
connectivity exists.
LFA-based BIER-FRR adopts the principles of LFAs but differs from IP-
FRR in that the LFA target node, i.e., the node to which traffic is
diverted, must be a BFR. If an IP-LFA target is a BFR, it can be
utilized as a BIER-LFA; otherwise, it cannot serve as a BIER-LFA.
Consequently, if only a subset of nodes in the underlay are BFRs, the
BIER-LFAs will differ substantially from IP-LFAs. Furthermore, this
makes it more challenging to identify normal LFAs that do not require
tunneling. As a result, LFA-based BIER-FRR is likely to require more
remote LFAs and TI-LFAs than IP-FRR under such conditions.
7.2. Advantages and Disadvantages of Tunnel-Based BIER-FRR
7.2.1. Advantages
* The computation of backup forwarding entries is straightforward,
requiring only the primary BIFTs of a PLR and its BFR-NBRs. No
routing information from the routing underlay is necessary.
* The forwarding action "Explicit" is not required. However,
depending on the underlay, explicit forwarding may still be
utilized to achieve FRR in the underlay.
Chen, et al. Expires 28 August 2025 [Page 24]
Internet-Draft BIER FRR February 2025
7.2.2. Disadvantages
* It relies on the presence of a FRR mechanism in the underlay.
* It is constrained by the protection level provided by the
underlay. For instance, if the underlay supports only link
protection, tunnel-based BIER-FRR cannot offer node protection.
* Redundant packet copies may occur in tunnel-based BIER-FRR.
* In the case of node protection, backup paths may be unnecessarily
extended.
* A tunneling header is required for any rerouting, resulting in
additional header overhead.
7.3. Advantages and Disadvantages of LFA-Based BIER-FRR
7.3.1. Advantages
* It does not depend on any fast protection mechanisms in the
underlay.
* It can provide superior protection at the BIER layer compared to
the IP layer, particularly if LFA-based BIER-FRR utilizes BIER-
LFAs with a higher protection level than those used in LFA-based
IP-FRR. For example, the underlay may only offer FRR with link
protection, while BIER-FRR can provide node protection for BIER
traffic.
* It avoids header overhead for normal BIER-LFAs.
7.3.2. Disadvantages
* The computation of backup forwarding entries requires routing
information from the underlay.
* The computation of backup forwarding entries is more complex when
some nodes in the underlay are not BFRs.
* The "Tunnel" forwarding action is required to protect certain
BFERs, which adds header overhead.
* The "Explicit" forwarding action is necessary to achieve full
protection coverage in some topologies; without it, only partial
protection coverage is possible. This requires support for
explicit paths, such as segment routing.
Chen, et al. Expires 28 August 2025 [Page 25]
Internet-Draft BIER FRR February 2025
* More remote and TI-LFAs are needed compared to IP-FRR if some
nodes in the routing underlay are not BFRs.
* Redundant packet copies may occur in LFA-based BIER-FRR, though
this is less frequent than with tunnel-based BIER-FRR.
8. Security Considerations
This specification does not introduce additional security concerns
beyond those already discussed in the BIER architecture [RFC8279]
along with the IP FRR [RFC5286] and LFA [RFC7490] specifications.
9. IANA Considerations
No requirements for IANA.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
10.2. Informative References
Chen, et al. Expires 28 August 2025 [Page 26]
Internet-Draft BIER FRR February 2025
[BrAl17] Braun, W., Albert, M., Eckert, T., and M. Menth,
"Performance Comparison of Resilience Mechanisms for
Stateless Multicast Using BIER", May 2017.
[I-D.chen-bier-egress-protect]
Chen, H., McBride, M., Wang, A., Mishra, G. S., Liu, Y.,
Menth, M., Khasanov, B., Geng, X., Fan, Y., Liu, L., and
X. Liu, "BIER Egress Protection", Work in Progress,
Internet-Draft, draft-chen-bier-egress-protect-07, 28
March 2024, <https://datatracker.ietf.org/doc/html/draft-
chen-bier-egress-protect-07>.
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
21, 12 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
segment-routing-ti-lfa-21>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
Appendix A. Specific Backup Strategy Examples
This appendix demonstrates the computations of some specific backup
strategy options in details.
A.1. LFA-based BIER-FRR using Single BIFT
In the LFA-based BIER-FRR using single BIFT, every BFR has a single
BIFT for a level of protection. Its structure is the same as the one
in Figure 1.
The following presents the details in BFR B1 in Figure 2 for building
the BIFT for BIER-FRR link protection.
At first, BFR B1 obtains a BIER-LFA as BBFR-NBR for each BFER. B6 is
normal BIER-LFA as BBFR-NBR for BFER B2 and B3. B2 is normal BIER-
LFA as BBFR-NBR for BFER B4, B5, B6 and B7. Figure 12 illustrates
B1's intermediate BIFT for link protection filled with values for
BBFR-NBRs and BFAs.
Chen, et al. Expires 28 August 2025 [Page 27]
Internet-Draft BIER FRR February 2025
+------+---------+-------+----------+--------+----------+---+
|BFR-id| F-BM |BFR-NBR| BF-BM |BBFR-NBR| BFA |BEA|
+======+=========+=======+==========+========+==========+===+
| 2 | 0000110 | B2 | | B6 | Plain | |
+------+---------+-------+----------+--------+----------+---+
| 3 | 0000110 | B2 | | B6 | Plain | |
+------+---------+-------+----------+--------+----------+---+
| 4 | 1111000 | B6 | | B2 | Plain | |
+------+---------+-------+----------+--------+----------+---+
| 5 | 1111000 | B6 | | B2 | Plain | |
+------+---------+-------+----------+--------+----------+---+
| 6 | 1111000 | B6 | | B2 | Plain | |
+------+---------+-------+----------+--------+----------+---+
| 7 | 1111000 | B6 | | B2 | Plain | |
+------+---------+-------+----------+--------+----------+---+
Figure 12: B1's intermediate BIFT for link protection.
From the intermediate BIFT, BFERs B2 and B3 have the same BFR-NBR B2
and BBFR-NBR B6, BFERs B4 to B7 have the same BFR-NBR B6 as the BBFR-
NBR B6 for BFER B2. According to Section 3.4, the BF-BM for BFER B2
has the bits for B2 and B3 as well as the bits for B4 to B7, which is
1111110. The BF-BM for BFER B3 is also 1111110. Similarly, the BF-
BM for each of BFERs B3 to B7 is computed, which is 1111110.
With the BF-BMs, BFR B1 has the BIFT for link protection, which is
illustrated in Figure 13.
+------+---------+-------+----------+--------+----------+---+
|BFR-id| F-BM |BFR-NBR| BF-BM |BBFR-NBR| BFA |BEA|
+======+=========+=======+==========+========+==========+===+
| 2 | 0000110 | B2 | 1111110 | B6 | Plain | |
+------+---------+-------+----------+--------+----------+---+
| 3 | 0000110 | B2 | 1111110 | B6 | Plain | |
+------+---------+-------+----------+--------+----------+---+
| 4 | 1111000 | B6 | 1111110 | B2 | Plain | |
+------+---------+-------+----------+--------+----------+---+
| 5 | 1111000 | B6 | 1111110 | B2 | Plain | |
+------+---------+-------+----------+--------+----------+---+
| 6 | 1111000 | B6 | 1111110 | B2 | Plain | |
+------+---------+-------+----------+--------+----------+---+
| 7 | 1111000 | B6 | 1111110 | B2 | Plain | |
+------+---------+-------+----------+--------+----------+---+
Figure 13: B1's BIFT for BIER-FRR link protection.
Chen, et al. Expires 28 August 2025 [Page 28]
Internet-Draft BIER FRR February 2025
A.2. LFA-based BIER-FRR using Multiple Backup BIFTs
For the LFA-based BIER-FRR using multiple backup BIFTs, in addition
to a primary BIFT, a BFR has a backup BIFT for each of its BFR-NBRs
with a level of protection. The backup BIFT for BFR-NBR N with link
protection (or simply called the backup BIFT for link to N) assumes
that the link to N failed. The BFR uses it to protect against the
failure of its link to N. The backup BIFT for N with node protection
(or simply called the backup BIFT for N) assumes that node N failed.
The BFR uses it to protect against the failure of N. Once the BFR as
a PLR detects the failure of its link to N, it uses the backup BIFT
for link to N to forward all BIER packets. When the BFR as a PLR
detects the failure of its BFR-NBR N, it uses the backup BIFT for N
to forward all BIER packets.
Even though a BFR has multiple backup BIFTs, the LFA-based BIER-FRR
using multiple backup BIFTs is scalable. Both the size of a backup
BIFT and the number of backup BIFTs on the BFR are small. Assume a
BIER network has 1000 BFRs and 100 BFERs, and each BFR has 10 BFR-
NBRs on average. The size of a backup BIFT is 100 forwarding
entries. The number of backup BIFTs on the BFR is 20 on average.
The total size of all backup BIFTs is 100*20 = 2000 forwarding
entries.
The following presents the details in BFR B1 in Figure 2 for building
the backup BIFT for link to B2 to support BIER-FRR link protection.
To support link protection, BFR B1 in Figure 2 has two backup BIFTs:
one for link to B2 and the other for link to B6. The backup BIFT for
link to B2 is illustrated in Figure 14.
+--------+---------+---------+-----------------+-----------------+
| BFR-id | F-BM | BFR-NBR |Forwarding Action|Comment: protects|
| | | | | failure of |
+========+=========+=========+=================+=================+
| 2 | 1111110 | B6 | Plain | Link B1->B2 |
+--------+---------+---------+-----------------+-----------------+
| 3 | 1111110 | B6 | Plain | Link B1->B2 |
+--------+---------+---------+-----------------+-----------------+
| 4 | 1111110 | B6 | Plain | |
+--------+---------+---------+-----------------+-----------------+
| 5 | 1111110 | B6 | Plain | |
+--------+---------+---------+-----------------+-----------------+
| 6 | 1111110 | B6 | Plain | |
+--------+---------+---------+-----------------+-----------------+
| 7 | 1111110 | B6 | Plain | |
+--------+---------+---------+-----------------+-----------------+
Chen, et al. Expires 28 August 2025 [Page 29]
Internet-Draft BIER FRR February 2025
Figure 14: B1's backup BIFT for link to B2.
BFR B1 builds the backup BIFT for link to B2 in two steps. In the
first step, it builds the backup BIRT for link to B2 through copying
its regular BIRT to the backup BIRT and then changing BFR-NBR B2 in
the backup BIRT to a backup BFR-NBR to protect against the failure of
the link to B2. The backup BIRT for link to B2 built by B1 is
illustrated in Figure 15.
+------+-------------+---------+-----------------+-----------------+
|BFR-id|BFER's Prefix| BFR-NBR |Forwarding Action|Comment: protects|
| | | | | failure of |
+======+=============+=========+=================+=================+
| 2 | B2 | B6 | Plain | Link B1->B2 |
+------+-------------+---------+-----------------+-----------------+
| 3 | B3 | B6 | Plain | Link B1->B2 |
+------+-------------+---------+-----------------+-----------------+
| 4 | B4 | B6 | Plain | |
+------+-------------+---------+-----------------+-----------------+
| 5 | B5 | B6 | Plain | |
+------+-------------+---------+-----------------+-----------------+
| 6 | B6 | B6 | Plain | |
+------+-------------+---------+-----------------+-----------------+
| 7 | B7 | B6 | Plain | |
+------+-------------+---------+-----------------+-----------------+
Figure 15: B1's backup BIRT for link to B2.
The BFR-NBR in each of the first two routing entries with BFR-NBR B2
originally from the BIRT is changed to its corresponding backup BFR-
NBR. The BFR-NBR B2 in the first entry is changed to backup BFR-NBR
BIER-LFA B6. The BFR-NBR B2 in the second entry is changed to backup
BFR-NBR BIER-LFA B6.
In the second step, BFR B1 derives the backup BIFT for link to B2
from the backup BIRT for link to B2 in the same way as it derives its
regular BIFT from its BIRT defined in [RFC8279]. The result of the
backup BIFT for link to B2 is the one shown in Figure 14.
When BFR B1 as a PLR detects the failure of its link to B2, it
forwards all the BIER packets using the FRR-BIFT for link to B2.
There is no redundant packet. For example, for a BIER packet with
destinations B2 and B6 (i.e., bitstring 0100010), BFR B1 sends a
single packet copy on the link to B6 using the backup BIFT for link
to B2 after detecting the failure of its link to B2. It will not
send any copy of the packet to B6 again since the bitstring in the
packet will be all cleaned by the F-BM 1111110 after sending the
Chen, et al. Expires 28 August 2025 [Page 30]
Internet-Draft BIER FRR February 2025
packet to B6 via its link to B6. Similarly, for a BIER packet with
destinations B2, B5 and B7 (i.e., bitstring 1010010), BFR B1 sends a
single packet copy on its link to B6 using the backup BIFT for link
to B2 after detecting the failure of its link to B2.
Acknowledgments
The authors would like to thank Daniel Merling, Jeffrey Zhang, Tony
Przygienda and Shaofu Peng for their comments to this work. A
special thank you to Gunter van de Velde for his extensive editing to
help bring this document to publication.
Contributors
Yisong Liu
China Mobile
Email: liuyisong@chinamobile.com
Yanhe Fan
Casa Systems
United States of America
Email: yfan@casa-systems.com
Lei Liu
Fujitsu
United States of America
Email: liulei.kddi@gmail.com
Xufeng Liu
Alef Edge
United States of America
Email: xufeng.liu.ietf@gmail.com
Xuesong Geng
China
Email: gengxuesong@huawei.com
Authors' Addresses
Huaimo Chen (editor)
Futurewei
Boston, MA,
United States of America
Email: hchen.ietf@gmail.com
Mike McBride
Futurewei
Chen, et al. Expires 28 August 2025 [Page 31]
Internet-Draft BIER FRR February 2025
Email: michael.mcbride@futurewei.com
Steffen Lindner
University of Tuebingen
Email: steffen.lindner@uni-tuebingen.de
Michael Menth
University of Tuebingen
Email: menth@uni-tuebingen.de
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: wangaj3@chinatelecom.cn
Gyan S. Mishra
Verizon Inc.
13101 Columbia Pike
Silver Spring, MD 20904
United States of America
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com
Chen, et al. Expires 28 August 2025 [Page 32]