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.¶
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.¶
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/.¶
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 22 August 2025.¶
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.¶
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.¶
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 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].¶
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.¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
To minimize the occurrence of redundant packets, it is essential that backup
entries are prioritized for use within the single extended BIFT, as described in Section 3.2).
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).¶
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.¶
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
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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, 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.¶
In the network depicted in Figure 2, the primary path
from BFR B1 to BFER B5 is B1-B6-B5. Node protection for BFER B5 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.¶
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.¶
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.¶
With link protection, the backup BFR-NBRs equal the primary
BFR-NBRs. If a primary BFR-NBR is directly connected to the BFR
as a PLR, the corresponding backup forwarding action is Tunnel.
As a result, the BIER packets affected by a failure are
tunneled over the routing underlay to their BFR-NBR
instead of being sent directly as plain BIER packets
to the BFR-NBR.
If a 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 the same as the primary F-BMs,
which is in line with the computation of the backup F-BMs
in Section 3.4.¶
Figure 7 shows
B1's backup BIFT for tunnel-based BIER-FRR
with link protection for the BIER network example of
Figure 2.
The backup BFR-NBRs and backup F-BMs
in this backup BIFT are
the same as the primary
BFR-NBRs and primary F-BMs in the primary BIFT in
Figure 4,
but the backup actions in this backup BIFT are Tunnel
while the primary actions in the primary BIFT are Plain
(which are not shown, but implied).¶
When B1 as a PLR detects failure of its link to B6,
a BIER packet with bitstring 0100000 for B6
is tunneled by B1 towards B6 via the routing underlay.
The exact path of the backup tunnel depends on the routing
underlay.
It may be B1-B2-B7-B6 or B1-B2-B3-B4-B5-B6.¶
If a BIER packet is destined to {B2, B5, B7}, first
an encapsulated packet copy is
forwarded via link B1-B2 to backup BFR-NBR B6 with backup action
Tunnel to deliver packet copies to BFER B5 and B7. Then, a
non-encapsulated
packet copy is forwarded via link B1-B2 to BFR-NBR B2 with primary
action Plain to deliver a packet copy to BFER B2. Thus, with
tunnel-based BIER-FRR, a single redundant packet copy can occur
in case of a failure because an encapsulated packet copy and
a non-encapsulated packet copy are forwarded over the same link.
This happens although BIER packets affected by failures are forwarded
before BIER packets not affected by failures.¶
A BIER packet with bitstring 1000000 for B7 is forwarded
on the backup
path B1-B2-B7-B6-B7 as it is first delivered to the backup
BFR-NBR B6.
Thus, the backup path can be unnecessarily long.
This phenomenon is known from facility backup method in
[RFC4090] which takes similar paths as
tunnel-based BIER-FRR.¶
To determine the backup forwarding entries with node protection, a
case analysis for the BFER to protect is needed. If the BFER is the
same as its primary BFR-NBR, node protection is not possible for that
BFER. Therefore, link protection is applied,
i.e., the backup
BFR-NBR is set to the primary BFR-NBR.
If that level of protection is not sufficient,
egress protection in [I-D.chen-bier-egress-protect]
may be applied.
Otherwise (i.e., 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, i.e., the backup
BFR-NBR is a next next hop BFR. In all cases, the backup action is
Tunnel. In the first case, the backup F-BM is set to all zeroes plus
the bit enabled for the BFER to protect. In the second case, the
backup F-BM is computed in the way
described in Section 3.4.¶
Figure 8 shows
B1's backup BIFT for tunnel-based BIER-FRR
with node protection for the BIER network example 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 them are
those nodes themselves. According to the description above,
only the bit for B2 is set in the
backup F-BM of B2. The same holds 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 as a PLR detects the failure of its BFR-NBR B6,
a BIER packet with bitstring 1010010 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 on link B1-B2. Thus,
with node protection, more redundant packets copies may be sent than
with link protection.¶
Caveat: If the routing underlay does not provide node protection,
tunnel-based BIER-FRR cannot provide node protection, either.
This is shown
by the following example. The underlay in the networking example of
Figure 2 offers only link protection.
B6 fails and B1 must forward a
packet to B5. According to the backup BIFT in
Figure 8 the packet
is tunneled towards B5 and the tunnel path B1-B2-B7-B6-B5 may be taken
for
this purpose by the underlay due to FRR with link protection.
However, B6 is also unreachable at B7 so that the packet is returned
to B2 and the packet loops between B2 and B7.¶
LFA-based BIER-FRR leverages alternate BFRs
to deliver BIER packets to BFERs for which the primary
BFR-NBR is unreachable.
It does not rely on any fast restoration/protection
mechanisms in the underlay.
First, some
prerequisites for LFA-based BIER-FRR are clarified, BIER-LFAs are
defined, and then link and node protection for
LFA-based BIER-FRR are discussed using a single backup BIFT.¶
A loop-free alternate (LFA) for a specific destination is an
alternate node to which a packet is sent if the primary next hop
for this destination is not reachable.
This alternate node should be able to forward 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].
Such LFAs are denoted as IP-LFAs.
BIER-LFAs are very similar to IP-LFAs, but a BIER-LFA node must
be a BFR.
If only a subset of the nodes in the routing underlay 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 needed.
This is a difference to tunnel-based BIER-FRR where knowledge
about the primary BIFTs of a PLR and its BFR-NBRs is sufficient.¶
LFA-based BIER-FRR may reuse IP-LFAs in the following sense as
BIER-LFAs.
If an IP-LFA node for the destination of a specific BFER is a
BFR, it may be reused as backup BFR-NBR for that BFER together with the
backup action that is applied for that IP-LFA on the IP layer.
A normal IP-LFA corresponds to backup action plain,
a remote IP-LFA to Tunnel, and a TI-IP-LFA to Explicit.¶
As for IP-LFAs, there are several, different types of BIER-LFAs:¶
A BFR is a normal BIER-LFA for a specific BFER if it is
directly connected to the PLR and¶
the BFER can be reached from it through the BIER domain¶
both the path from the PLR to it and the path from it
to the BFER are disjoint with the primary path from the
PLR to the primary BFR-NBR. These paths¶
may contain the primary BFR-NBR for link protection, and¶
must not contain the primary BFR-NBR for node protection.¶
A BFR is a remote BIER-LFA for a specific BFER if it is not
directly connected to the PLR,
if it can be reached via a tunnel from the PLR, and if it
also satisfies the aforementioned conditions 1 and 2.¶
A BFR is a TI-BIER-LFA for a specific BFER if it is not
directly connected to the PLR,
if it cannot be reached via a tunnel from the PLR,
if it is reachable
from the PLR via an explicit path (i.e., with the help of
a SR header), and if it also satisfies the aforementioned
conditions 1 and 2.¶
For some BFERs, one or more normal BIER-LFAs are available at a specific PLR.
For other BFERs, only remote and TI-LFAs are available.
And there may be some BFERs, for which only TI-LFAs are available.¶
The backup actions to reroute BIER packets depending
on the BIER-LFA types are:¶
The protection coverage is the set of BFERs that can be protected with
a desired protection level by a certain BIER-LFA type.
The BIER-LFA types have the following properties:¶
Normal BIER-LFAs are simplest, as they require neither tunneling
nor explicit paths.
Remote BIER-LFAs are more powerful, but entail more header overhead
and require more functionality from the PLR.
TI-BIER-LFAs are most complex as they require the use of explicit paths.
When LFA-based BIER-FRR is utilized, the set of supported BIER-LFAs
must be indicated.
The following options are available:¶
With link protection, normal BIER-LFAs are preferred over remote LFAs
and remote BIER-LFAs are preferred over TI-BIER-LFAs. Depending on
the set of supported BIER-LFAs, a BFER may not be protectable.¶
Figure 5
illustrates B1's backup BIFT for LFA-based
BIER-FRR with link protection in the networking example of
Figure 2.¶
If the link B1-B6 fails, B1 cannot reach the BFERs B4, B5, B6, and B7
over their primary BFR-NBR. Therefore, B1 sends their traffic via
the backup BFR-NBR B2 together with the traffic for B2 and B3 as B2
is their primary BFR-NBR. As a consequence, the backup F-BM is
1111110 in that case. Likewise, if the link B1-B2 fails, B1 sends
all traffic to B6, and the backup F-BM is 1111110 also in that case.¶
B1 requires only normal BIER-LFAs to protect all BFERs. This can be
substantially different for other BFRs.
Figure 9 and
Figure 10 show
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.
And BFR B5 requires even 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, a BFER cannot be protected by BIER-FRR.¶
Assume B7 has a BIER packet with destinations {B1, B4, B5,
B6}. When link B7-B6 fails,
the packet copy for B1 is sent to B2 using forwarding action Plain,
the packet copy to B4 is tunneled via B2 to B3,
and the packet copies towards
B5 and B6 are sent via explicit paths towards B4 and B1 respectively.
As these
packet copies have different headers, they all need to be sent.
Hence, there are three redundant copies.¶
To determine the backup forwarding entries with node protection, a
case analysis for the BFER to protect is needed again. If the BFER
is the same as its primary BFR-NBR, node protection is not possible
for that BFER. In this case, link protection is applied.
Otherwise,
the BFER must be protected by a node-protecting BIER-LFA. Thereby,
normal BIER-LFAs are preferred over remote BIER-LFAs and remote BIER-
LFAs are preferred over TI-BIER-LFAs. Depending on the set of
allowed BIER-LFAs, a BFER may not be protectable.¶
Figure 11
illustrates B1's backup BIFT for the LFA-based BIER-FRR
with node protection in the networking example of
Figure 2.¶
As the primary BFR-NBR of B1 for BFER B6 is B6 itself, only link
protection can be applied. Therefore, B2 is used as normal, link-
protection BIER-LFA to protect B6. Likewise, the primary BFR-NBR of
B1 for BFER B2 is B2, and therefore, B2 is protected with B6 as
normal, link-protecting BIER-LFA. BFER B7 is protected against the
failure of node B6 with B2 as normal, node-protecting BIER-LFA as B2
has a shortest path towards B7 that does not traverse B6. The backup
F-BMs for BFER 6 and BFER 7 are {B2, B6, B7} because if B6 is
unreachable, the traffic for these BFERs is sent via link B1-B2 with
forwarding action Plain.¶
BFER B4 is not reachable through a normal LFA when BFR B6 fails.
However, B3 is a remote, node-protecting BIER-LFA for BFER B4 because
B3 has a shortest path towards B4, and B3 is reachable through a
shortest path from B1, and the resulting backup path from B1 to B4
does not traverse B6. Likewise, B4 is 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 is a node-protecting
TI-LFA for BFER B5 because B4 has a shortest path towards B5 that
does not traverse B6. Moreover, B4 is reachable through the explicit
path B1-B2-B3-B4.¶
Redundant packets occur with LFA-based BIER-FRR
if BIER packets are sent over a specific link in different forms.
These forms are¶
plain BIER packets (plain primary transmission or
reroute to normal BIER-LFA)¶
BIER packets encapsulated to a specific BFR-NBR
(tunneled primary transmission or reroute to remote BIER-LFA)¶
BIER packets with an encoded explicit path (reroute to TI-LFA)¶
When different remote LFAs are addressed, even multiple
redundant packets can be caused through remote LFAs.
The same can happen with TI-LFAs.
Some redundant packets can be avoided if remote LFAs
or TI-LFAs are chosen such that they can protect several
BFERs and thereby avoid the need for another remote LFA or TI-LFA.
However, this may lead to longer backup paths.
This is a new, potential optimization objective for
the choice of remote or TI-BIER-LFAs which does not exist for IP-FRR.
Its relevance may depend on the use case.¶
This optimization potential can be illustrated by LFA-based BIER-FRR with link protection for B7.
Its backup BIFT is given in
Figure 9.
As observed in Section 6.2.5,
B7 needs to send 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, then only two
redundant copies need to be sent.¶
This section first discusses the difference of IP-LFAs
for IP-FRR and BIER-LFAs for BIER-FRR.
Then it discusses advantages and disadvantages of tunnel-based
and LFA-based BIER-FRR.¶
LFAs have been first proposed for IP networks. They are
simple in the sense that they do not require any tunneling overhead.
However, some destinations cannot be protected against some link
failures and even more destinations cannot be protected against some
node failures. Therefore, remote LFAs (R-LFAs) have been defined
to improve that coverage by tunneling the affected traffic to another
node from where the traffic can reach the destination via normal
forwarding. Nevertheless, there may be still some destinations that
cannot be protected against link or node failures. Therefore,
topology-independent LFAs (TI-LFAs) have been defined where affected
traffic is tunneled via an explicit path (preferably using segment
routing headers) to another node from where the traffic can reach its
destination via normal IP forwarding. With TI-LFAs, all destinations
can be protected against any failures as long as connectivity exists.¶
LFA-based BIER-FRR adopts the idea of LFAs. It differs from
IP-FRR as the LFA target node, i.e., the node to which the traffic
is deviated, 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 BIER-LFA. Thus,
if only some nodes of the underlay are BFRs, the BIER-LFAs will be
substantially different from IP-LFAs. Moreover, this makes it more
difficult to find normal LFAs for which tunneling is not needed.
That means, LFA-based BIER-FRR is likely to require more remote LFAs
and TI-LFAs than IP-FRR under such conditions.¶
Computation of backup forwarding entries is very simple.
Only primary BIFTs of a PLR and its BFR-NBRs are needed
to compute the backup forwarding entries.
Routing information from the routing underlay is not needed.¶
The forwarding action Explicit is not needed. However,
depending on the underlay, explicit forwarding may be used
to achieve FRR in the underlay.¶
It is limited to the protection level of the underlay.
E.g., if the underlay supports only link protection, tunnel-based
BIER-FRR cannot provide node protection.¶
Redundant packet copies may occur in
tunnel-based BIER-FRR.¶
In case of node protection, backup paths may be extended
more than needed.¶
Requires a tunneling header for any rerouting, which creates
header overhead.¶
Does not rely on any fast protection of the underlay.¶
Can provide better protection on the BIER layer than on
the IP layer; this is possible if LFA-based BIER-FRR utilizes BIER-LFAs
with better protection level than LFA-based IP-FRR. E.g., the underlay
may provide only FRR with link protection while BIER-FRR may provide
node protection for BIER traffic.¶
Computation of backup forwarding entries requires routing
information from the underlay.¶
Computation of backup forwarding entries more complex
if some nodes of the underlay are not BFRs.¶
Need for forwarding action Tunnel to protect some BFERs,
which adds header overhead.¶
Need for forwarding action Explicit to achieve full protection
coverage for some topologies; otherwise only partial protection
coverage. This requires support for explicit paths, e.g., segment routing.¶
More remote and TI-LFAs needed than for IP-FRR if some nodes
in the routing underlay are not BFRs.¶
Redundant packet copies may occur in LFA-based BIER-FRR
(but it's less than with tunnel-based BIER-FRR).¶
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8279>.
Braun, W., Albert, M., Eckert, T., and M. Menth, "Performance Comparison of Resilience Mechanisms for Stateless Multicast Using BIER", .
[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, , <https://datatracker.ietf.org/doc/html/draft-chen-bier-egress-protect-07>.
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, , <https://www.rfc-editor.org/info/rfc4090>.
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.¶
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.¶
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 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.¶
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 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.¶
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