BIER-TE Egress Protection
draft-chen-bier-te-egress-protect-07
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Huaimo Chen , Mike McBride , Aijun Wang , Gyan Mishra , Yisong Liu , Yanhe Fan , Lei Liu , Xufeng Liu | ||
| Last updated | 2024-03-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-bier-te-egress-protect-07
Network Working Group H. Chen
Internet-Draft M. McBride
Intended status: Standards Track Futurewei
Expires: 29 September 2024 A. Wang
China Telecom
G. Mishra
Verizon Inc.
Y. Liu
China Mobile
Y. Fan
Casa Systems
L. Liu
Fujitsu
X. Liu
Alef Edge
28 March 2024
BIER-TE Egress Protection
draft-chen-bier-te-egress-protect-07
Abstract
This document describes a mechanism for fast protection against the
failure of an egress node of an explicit point to multipoint (P2MP)
multicast path/tree in a "Bit Index Explicit Replication" (BIER)
Traffic Engineering (TE) domain. It does not have any per-flow state
in the core of the domain. For a multicast packet to the egress
node, when the egress node fails, its upstream hop as a PLR sends the
packet to the egress' backup node once the PLR detects the failure.
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 29 September 2024 [Page 1]
Internet-Draft BIER-TE Egress Protect March 2024
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 29 September 2024.
Copyright Notice
Copyright (c) 2024 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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of BIER-TE Egress Protection . . . . . . . . . . . . 4
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5
3.1. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 5
3.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 6
4. BIER-TE Extensions . . . . . . . . . . . . . . . . . . . . . 7
4.1. Extensions to BIER-TE BIFT for Egress Protection . . . . 7
4.2. Updated Forwarding Procedure . . . . . . . . . . . . . . 7
5. Example Application of BIER-TE Egress Protection . . . . . . 9
5.1. Example BIER-TE Topology . . . . . . . . . . . . . . . . 9
5.2. BIER-TE BIFT on a BFR . . . . . . . . . . . . . . . . . . 10
5.3. Extended BIER-TE BIFT on a BFR . . . . . . . . . . . . . 11
5.4. Forwarding using Extended BIER-TE BIFT . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Chen, et al. Expires 29 September 2024 [Page 2]
Internet-Draft BIER-TE Egress Protect March 2024
1. Introduction
[RFC9262] introduces Bit Index Explicit Replication (BIER) Traffic/
Tree Engineering (BIER-TE). It is an architecture for per-packet
stateless explicit point to multipoint (P2MP) multicast path/tree and
based on the BIER architecture defined in [RFC8279]. A multicast
packet is replicated and forwarded along the P2MP path/tree encoded
in the packet. It does not require intermediate nodes to maintain
any per-path/tree state.
This document describes a mechanism for fast protection against the
failure of an egress node of an explicit P2MP multicast path/tree in
a BIER-TE domain. It is called BIER-TE Egress Protection. For a
multicast packet to the egress node, when the egress node fails, its
upstream hop as a PLR sends the packet to the egress' backup node
(called backup egress node) once the PLR detects the failure.
This BIER-TE Egress Protection does not require intermediate nodes to
maintain any per-path state for fast protection against the failure
of an egress node of the path.
1.1. Terminology
BIER: Bit Index Explicit Replication.
BIER-TE: BIER Traffic/Tree Engineering.
BFR: Bit-Forwarding Router.
BFIR: Bit-Forwarding Ingress Router.
BFER: Bit-Forwarding Egress Router.
BFR-id: BFR Identifier. It is a number in the range [1,65535].
BFR-NBR: BFR Neighbor.
F-BM: Forwarding Bit Mask.
BFR-prefix: An IP address (either IPv4 or IPv6) of a BFR.
BIRT: Bit Index Routing Table. It is a table that maps from the
BFR-id (in a particular sub-domain) of a BFER to the BFR-prefix
of that BFER, and to the BFR-NBR on the path to that BFER.
BIFT: Bit Index Forwarding Table.
FRR: Fast Re-Route.
Chen, et al. Expires 29 September 2024 [Page 3]
Internet-Draft BIER-TE Egress Protect March 2024
PLR: Point of Local Repair.
IGP: Interior Gateway Protocol.
LSDB: Link State DataBase.
SPF: Shortest Path First.
SPT: Shortest Path Tree.
OSPF: Open Shortest Path First.
IS-IS: Intermediate System to Intermediate System.
LSA: Link State Advertisement in OSPF.
LSP: Link State Protocol Data Unit (PDU) in IS-IS.
2. Overview of BIER-TE Egress Protection
For fast protecting an egress node of a BIER-TE domain, a backup
egress node is configured on the egress node. After the
configuration, the egress node distributes the information about the
backup egress to its direct neighbors.
For clearly distinguishing between an egress node and a backup egress
node, an egress node is called a primary egress node sometimes.
For a multicast packet to a primary egress node of the domain, when
the primary egress node fails, its upstream hop as a point of local
repair (PLR) sends the packet to the backup egress node configured to
protect the primary egress node once the PLR detects the failure.
The upstream hop of the primary egress node is its direct neighbor.
A Bit-Forwarding Router (BFR) in a BIER-TE sub-domain has a BIER-TE
Bit Index Forwarding Tables (BIFT) [RFC9262]. A BIER-TE BIFT on a
BFR comprises a forwarding entry for a BitPosition (BP) assigned to
each of the adjacencies of the BFR. If the BP represents a forward
connected adjacency, the forwarding entry for the BP forwards the
multicast packet with the BP to the directly connected BFR neighbor
of the adjacency. If the BP represents a BFER (i.e., egress node) or
say a local decap adjacency, the forwarding entry for the BP
decapsulates the multicast packet with the BP and passes a copy of
the payload of the packet to the packet's NextProto within the BFR.
The BIER-TE BIFT on a BFR is extended to support protection against
the failure of an egress node. For each forwarding entry of the
BIER-TE BIFT on the BFR, if it is for the BP representing a forward
Chen, et al. Expires 29 September 2024 [Page 4]
Internet-Draft BIER-TE Egress Protect March 2024
connected adjacency and its BFR-NBR is a BFER (i.e., primary egress
node), the forwarding entry is extended to include a new forwarding
entry, which is called backup forwarding entry or backup entry for
short. This backup entry forwards the multicast packet with the BP
to the backup egress node, which is configured to protect the primary
egress node.
Once the BFR as a PLR detects the failure of its BFR-NBR X that is a
primary egress node of the domain, for a multicast packet with the BP
for the primary egress node, the PLR uses the backup forwarding entry
in the extended BIER-TE BIFT to send the packet to the backup egress
node configured to protect the primary egress node.
3. Protocol Extensions
This section defines extensions to OSPF and IS-IS for advertising the
backup information (including the information about the backup egress
node for protecting a primary egress node).
3.1. Extensions to OSPF
When a node P (as a primary egress node) has a backup egress node
configured to protect against its failure, node P advertises the
information about the backup egress node to its neighbors in its
router information opaque LSA of LS type 9 or 10. The information is
included in a backup egress BP TLV. The format of the TLV is shown
in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | BP of backup egress node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (Optional) |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: OSPF Backup Egress BP TLV
Type: 2 octets, its value (TBD1) is to be assigned by IANA.
Length: 2 octets, its value is 4 plus the length of the Sub-TLVs
included. If no Sub-TLV is included, its value is 4.
Chen, et al. Expires 29 September 2024 [Page 5]
Internet-Draft BIER-TE Egress Protect March 2024
Reserved: 2 octets, it MUST be set to zero when sending and be
ignored while receiving.
BP of backup egress node: 2 octets, its value is the local decap
BitPosition of the backup egress node, which is configured to protect
against the failure of the primary egress node.
Sub-TLVs (Optional): No Sub-TLV is defined now.
After each of the neighbors receives the backup egress BP TLV from
node P, it knows that node P as a primary egress node will be
protected by the backup egress node in the TLV. Once detecting the
failure of node P, it sends the packet with the BP for node P towards
the backup egress node.
3.2. Extensions to IS-IS
For supporting fast protection against the failure of a primary
egress node in a BIER-TE domain, a new IS-IS TLV, called IS-IS backup
egress BP TLV, is defined. It contains the local decap BitPosition
of the backup egress node configured to protect the primary egress
node.
When a node P (as a primary egress node) has a backup egress node
configured to protect against its failure, node P advertises the
information about the backup egress node to its neighbors using a IS-
IS backup egress BP TLV.
This TLV may be advertised in IS-IS Hello (IIH) PDUs, LSPs, or in
Circuit Scoped Link State PDUs (CS-LSP) [RFC7356]. The format of the
TLV is shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD2) | Length | BP of backup egress node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (Optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IS-IS Backup Egress BP TLV
Type: 1 octet, its value (TBD2) is to be assigned by IANA.
Length: 1 octet, its value is 2 plus the length of the Sub-TLVs
included. If no Sub-TLV is included, its value is 2.
Chen, et al. Expires 29 September 2024 [Page 6]
Internet-Draft BIER-TE Egress Protect March 2024
BP of backup egress node: 2 octets, its value is the local decap
BitPosition of the backup egress node configured to protect against
the failure of the primary egress node.
Sub-TLVs (Optional): No Sub-TLV is defined now.
4. BIER-TE Extensions
This section describes extensions to a BIER-TE BIFT of a BFR for
supporting fast protection against the failure of a primary egress
node and enhancements on a forwarding procedure to use the extended
BIER-TE BIFT for egress protection.
4.1. Extensions to BIER-TE BIFT for Egress Protection
If a BFR is a neighbor of an egress node in a BIER-TE sub-domain, it
has an extended BIER-TE BIFT to support protection against the
failure of its neighbor egress node. The forwarding entry with the
egress node (say X) as its BFR-NBR in the BIFT comprises a backup
entry. The backup entry contains a flag EPA (which is short for
Egress Protection is Active) and a backup path to a backup egress
node (say Y) which is configured to protect the egress node.
In normal operations, the flag EPA in the backup entry for neighbor
egress node X is set to 0 (zero). The flag EPA is set to 1 (one)
when egress node X fails. EPA == 1 means that the egress protection
for primary egress node X is active and the backup entry will be used
to forward the packet with BP for egress node X to backup egress node
Y along the backup path.
The backup path from the BFR to backup egress node Y is a path that
satisfies a set of constraints and does not traverse primary egress
node X or any link connected to X. In one implementation, the backup
path is represented by the BitPositions for the adjacencies along the
backup path.
4.2. Updated Forwarding Procedure
The forwarding procedure defined in [RFC9262] is updated/enhanced for
using an extended BIER-TE BIFT to consider the egress protection
(i.e., the new backup entry containing EPA and backup path in the
BIFT).
For a multicast packet with the BP in the BitString indicating a BFR-
NBR as a primary egress node, the updated forwarding procedure on a
BFR sends the packet towards the backup egress node of the primary
egress node if the primary egress node fails.
Chen, et al. Expires 29 September 2024 [Page 7]
Internet-Draft BIER-TE Egress Protect March 2024
It checks whether EPA equals to 1 (one) in the forwarding entry with
the BFR-NBR that is the primary egress node. If EPA is 1 (i.e., the
primary egress node fails and the egress protection for primary
egress is active), then the procedure clears two BPs in the packet's
BitString and checks whether the backup egress node is not one of the
packet's destinations.
One BP is the BP for the primary egress node and the other is the BP
for the forward connected adjacency from the BFR to the primary
egress node. After these two BPs are cleared in the packet's
BitString, the packet will not be sent to the failed primary egress
node.
When the BP for the backup egress node in the packet's BitString is
0, the backup egress node is not one of the packet's destinations.
In this case, the procedure adds the backup path to the backup egress
node into the packet through adding the BPs for the backup path in
the packet's BitString. Thus the packet will be sent to the backup
egress node along the backup path.
The updated procedure is described in Figure 3. It can also be used
by the BFR to forward multicast packets in normal operations.
Packet = the packet received by BFR;
FOR each BP k (from the rightmost in Packet's BitString) {
IF BP k is local decap adjacency (or say BP of the BFR) {
copies Packet, sends copy's payload to the multicast
flow overlay and clears bit k in Packet's BitString
} ELSE IF BP k is forward connect adjacency of the BFR {
finds FIB entry for BFR-NBR in BIER-TE BIFT using BP k;
Clears BP k;
IF EPA == 1 {//Egress Protection for BFR-NBR/egress is Active
Clears BP for BFR-NBR in Packet's BitString;
IF BP for backup egress is 0 in Packet's BitString {
Adds BPs for backup path into Packet's BitString
}
} //egress removed, backup path to backup egress added
ELSE {
Copies Packet and sends the updated copy to BFR-NBR
}
}
}
Figure 3: Updated Forwarding Procedure
Chen, et al. Expires 29 September 2024 [Page 8]
Internet-Draft BIER-TE Egress Protect March 2024
5. Example Application of BIER-TE Egress Protection
This section illustrates an example application of BIER-TE Egress
Protection on a BFR in a BIER-TE topology in Figure 4.
5.1. Example BIER-TE Topology
An example BIER topology for a BIER-TE sub-domain is shown in
Figure 4. It has 8 nodes/BFRs A, B, C, D, E, F, G and H.
6' 13' 14' 4 (0:01000)
/-----------( G )----------( H )Backup Egress for D
/ 15'\_______ 10'/ \
/ _______)____/ \
/ / (_____ (CE) Receiver
/ / \ /
8' 7' /5' 3' 4' /9' 17' 16'\ /
( A )--------( B )------------( C )------------( D )Primary Egress
5(0:10000) \1' \11' 18' 1 (0:00001)
\ \
\2' 19' 20' \12'
( E )------------( F )
3(0:00100) 2 (0:00010)
Figure 4: Example BIER-TE Topology
Nodes/BFRs D, F, E, H and A are BFERs and have local decap adjacency
BitPositions 1, 2, 3, 4, and 5 respectively. For simplicity, these
BPs are represented by (SI:BitString), where SI = 0 and BitString is
of 5 bits. BPs 1, 2, 3, 4, and 5 are represented by 1 (0:00001), 2
(0:00010), 3 (0:00100), 4 (0:01000) and 5 (0:10000) respectively.
The BitPositions for the forward connected adjacencies are
represented by i', where i is from 1 to 20. In one option, they are
encoded as (n+i), where n is a power of 2 such as 32768. For
simplicity, these BitPositions are represented by (SI:BitString),
where SI = (6 + (i-1)/5) and BitString is of 5 bits. BitPositions i'
(i from 1 to 20) are represented by 1'(6:00001), 2'(6:00010),
3'(6:00100), 4'(6:01000), 5'(6:10000), 6'(7:00001), 7'(7:00010),
8'(7:00100), . . . , 20'(9:10000).
For a link between two nodes X and Y, there are two BitPositions for
two forward connected adjacencies. These two forward connected
adjacency BitPositions are assigned on nodes X and Y respectively.
The BitPosition assigned on X is the forward connected adjacency of
Y. The BitPosition assigned on Y is the forward connected adjacency
of X.
Chen, et al. Expires 29 September 2024 [Page 9]
Internet-Draft BIER-TE Egress Protect March 2024
For example, for the link between nodes B and C in the figure, two
forward connected adjacency BitPositions 3' and 4' are assigned to
two ends of the link. BitPosition 3' is assigned on node B to B's
end of the link. It is the forward connected adjacency of node C.
BitPosition 4' is assigned on node C to C's end of the link. It is
the forward connected adjacency of node B.
BFER H is configured to protect BFER D on BFR D. Suppose that this
information is distributed to BFR D's neighbors BFR C and BFR G by
IGP. BFR C and BFR G know that H is the backup egress to protect the
primary egress D.
Similarly, BFER D is configured to protect BFER H on BFR H; BFER F is
configured to protect BFER E on BFR E; and BFER E is configured to
protect BFER F on BFR F. These are not shown in the figure.
CE is a multicast traffic Receiver, which is dual homed to primary
egress node D and backup egress node H for protecting primary egress
D. During normal operations, there is no multicast traffic to CE
from backup egress node H and CE receives the multicast traffic only
from primary egress node D. There is no duplicated traffic to
receiver CE. This is different from MoFRR in [RFC7431], where
duplicated traffic is sent to both the primary egress D and backup
egress H, to which the receiver CE is dual homed. When primary
egress node D fails, the multicast traffic is sent to CE from backup
egress node H.
5.2. BIER-TE BIFT on a BFR
Every BFR in a BIER-TE sub-domain/topology has a BIER-TE BIFT. For
the BIER-TE topology in Figure 4, each of 8 nodes/BFRs A, B, C, D, E,
F, G and H has its BIER-TE BIFT for the topology.
The BIER-TE BIFT on BFR C (i.e. node C) is shown in Figure 5.
The 1st forwarding entry in the BIFT will forward a multicast packet
with BitPosition 18' to D.
The 2nd forwarding entry in the BIFT will forward a multicast packet
with BitPosition 12' to F.
The 3rd forwarding entry in the BIFT will forward a multicast packet
with BitPosition 10' to H.
The 4-th forwarding entry in the BIFT will forward a multicast packet
with BitPosition 3' to B.
Chen, et al. Expires 29 September 2024 [Page 10]
Internet-Draft BIER-TE Egress Protect March 2024
+----------------+--------------+------------+
| Adjacency BP | Action | BFR-NBR |
| (SI:BitString) | | (Next Hop) |
+================+==============+============+
| 18' (9:00100) | fw-connected | D |
+----------------+--------------+------------+
| 12' (8:00010) | fw-connected | F |
+----------------+--------------+------------+
| 10' (7:10000) | fw-connected | H |
+----------------+--------------+------------+
| 3' (6:00100) | fw-connected | B |
+----------------+--------------+------------+
Figure 5: BIER-TE BIFT on BFR C
The BIER-TE BIFT on BFR D (i.e. node D) is shown in Figure 6.
The 1st forwarding entry in the BIFT will forward a multicast packet
with BitPosition 17' to C.
The 2nd forwarding entry in the BIFT will forward a multicast packet
with BitPosition 15' to G.
The 3rd forwarding entry in the BIFT will locally decapsulate a
multicast packet with BitPosition 1 and pass a copy of the payload of
the packet to the packet's NextProto.
+----------------+--------------+------------+
| Adjacency BP | Action | BFR-NBR |
| (SI:BitString) | | (Next Hop) |
+================+==============+============+
| 17' (9:00010) | fw-connected | C |
+----------------+--------------+------------+
| 15' (8:10000) | fw-connected | G |
+----------------+--------------+------------+
| 1 (0:00001) | local-decap | |
+----------------+--------------+------------+
Figure 6: BIER-TE BIFT on BFR D
5.3. Extended BIER-TE BIFT on a BFR
Each of the BFRs that are neighbors of egress nodes (i.e., BFERs) in
a BIER-TE sub-domain/topology has an extended BIER-TE BIFT to support
protection against the failure of every its neighbor egress node.
Chen, et al. Expires 29 September 2024 [Page 11]
Internet-Draft BIER-TE Egress Protect March 2024
For example, the extended BIER-TE BIFT on BFR C is illustrated in
Figure 7. It comprises a backup entry for each of its neighbor
egress nodes D, F and H. Each of these backup entries contains a
flag EPA and a backup path to a backup egress node. EPA is set to
zero in normal operations. EPA in the backup entry for neighbor
egress node X is set to one when egress node X fails.
The backup entry of the 1st forwarding entry in the BIFT contains EPA
= 0 and backup path {10', 4}. When egress node D fails, the EPA is
set to one and the backup entry is used to forward a multicast packet
with BitPosition 1 for D to D's backup egress node H with BitPosition
4 along the backup path.
The backup entry of the 2nd forwarding entry in the BIFT contains EPA
= 0 and backup path {3', 2', 3}. When egress node F fails, EPA is
set to one and the backup entry is used to forward a multicast packet
with BitPosition 2 for F to F's backup egress node E with BitPosition
3 along the backup path.
+----------------+--------------+----------+-----------------+
| Adjacency BP | Action | BFR-NBR | Backup Entry |
| (SI:BitString) | |(Next Hop)|(EP, BackupPath) |
+================+==============+==========+=================+
| 18' (9:00100) | fw-connected | D |EPA=0, {10', 4} |
+----------------+--------------+----------+-----------------+
| 12' (8:00010) | fw-connected | F |EPA=0, {3', 2',3}|
+----------------+--------------+----------+-----------------+
| 10' (7:10000) | fw-connected | H |EPA=0, {18', 1} |
+----------------+--------------+----------+-----------------+
| 3' (6:00100) | fw-connected | B |EPA=0, { } |
+----------------+--------------+----------+-----------------+
Figure 7: Extended BIER-TE BIFT on BFR C
The backup entry of the 3rd forwarding entry in the BIFT contains EPA
= 0 and backup path {18', 1}. When egress node H fails, EPA is set
to one and the backup entry is used to forward a multicast packet
with BitPosition 4 for H to H's backup egress node D with BitPosition
1 along the backup path.
Chen, et al. Expires 29 September 2024 [Page 12]
Internet-Draft BIER-TE Egress Protect March 2024
5.4. Forwarding using Extended BIER-TE BIFT
Suppose that there is a multicast packet with explicit path {7', 4',
18', 12', 2, 1} on BFR A. The path is encoded in the BitPositions of
the packet. BFR A forwards the packet to BFR B according to the
forwarding entry for 7' in its extended BIER-TE BIFT. BFR B forwards
the packet to BFR C according to the forwarding entry for 4' in B's
extended BIER-TE BIFT.
In normal operations, after receiving the packet from BFR B, BFR C
copies and sends the packet to BFR D and BFR F using the forwarding
entries for 18' and 12' in the extended BIER-TE BIFT on BFR C
respectively.
Once BFR C detects the failure of egress node D, it sets EPA of the
backup entry in the 1st forwarding entry to one. After receiving the
packet from BFR B, BFR C copies and sends the packet to D's backup
egress node H using the backup entry in the forwarding entry for 18'
with BFR-NBR D in C's extended BIER-TE BIFT. It copies and sends the
packet to F using the forwarding entry for 12' in C's extended BIER-
TE BIFT.
The packet received by BFR C from BFR B contains (SI:BitString) =
(0:00011)(8:00010)(9:00100), which represents {18', 12', 2, 1}.
Since EPA in the backup entry in the forwarding entry with BFR-NBR ==
D is 1, BFR C copies and sends the packet to D's backup egress node H
in the following steps.
At first, it obtains the backup entry from the forwarding entry for
18' with BFR-NBR D. EPA == 1 in the backup entry indicates that
egress protection for egress node D is active. BFR C clears
BitPositions 18' and 1 in Packet's BitString and adds the backup path
{10', 4} into Packet's BitString. The updated BitString in Packet is
(0:01010)(7:10000)(8:00010), which represents {12', 10', 4, 2}. This
lets BFR C copy and send Packet to F and H using the forwarding
entries for 12' and 10' in C's extended BIER-TE BIFT respectively.
When node H receives the packet with BitPosition 4 for H, it
decapsulates the packet and passes a copy of the payload of the
packet to the packet's NextProto, which sends the payload to the same
CE as egress node D sends.
When node F receives the packet with BitPosition 2 for F, it
decapsulates the packet and passes a copy of the payload of the
packet to the packet's NextProto, which sends the payload to another
CE (not shown in the figure).
Chen, et al. Expires 29 September 2024 [Page 13]
Internet-Draft BIER-TE Egress Protect March 2024
6. Security Considerations
TBD.
7. IANA Considerations
No requirements for IANA.
8. Acknowledgements
The authors would like to thank people for their comments to this
work.
9. References
9.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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <https://www.rfc-editor.org/info/rfc5250>.
[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>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014,
<https://www.rfc-editor.org/info/rfc7356>.
Chen, et al. Expires 29 September 2024 [Page 14]
Internet-Draft BIER-TE Egress Protect March 2024
[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>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[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>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>.
[RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree
Engineering for Bit Index Explicit Replication (BIER-TE)",
RFC 9262, DOI 10.17487/RFC9262, October 2022,
<https://www.rfc-editor.org/info/rfc9262>.
9.2. Informative References
[I-D.eckert-bier-te-frr]
Eckert, T. T., Cauchie, G., Braun, W., and M. Menth,
"Protection Methods for BIER-TE", Work in Progress,
Internet-Draft, draft-eckert-bier-te-frr-03, 5 March 2018,
<https://datatracker.ietf.org/doc/html/draft-eckert-bier-
te-frr-03>.
[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,
Chen, et al. Expires 29 September 2024 [Page 15]
Internet-Draft BIER-TE Egress Protect March 2024
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
13, 16 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
segment-routing-ti-lfa-13>.
[I-D.ietf-spring-segment-protection-sr-te-paths]
Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu,
"Segment Protection for SR-TE Paths", Work in Progress,
Internet-Draft, draft-ietf-spring-segment-protection-sr-
te-paths-06, 9 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
segment-protection-sr-te-paths-06>.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015,
<https://www.rfc-editor.org/info/rfc7431>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z.
Zhang, "Bit Index Explicit Replication (BIER) Support via
IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018,
<https://www.rfc-editor.org/info/rfc8401>.
[RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A.,
Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2
Extensions for Bit Index Explicit Replication (BIER)",
RFC 8444, DOI 10.17487/RFC8444, November 2018,
<https://www.rfc-editor.org/info/rfc8444>.
Authors' Addresses
Huaimo Chen
Futurewei
Boston, MA,
United States of America
Email: hchen.ietf@gmail.com
Mike McBride
Futurewei
Email: michael.mcbride@futurewei.com
Chen, et al. Expires 29 September 2024 [Page 16]
Internet-Draft BIER-TE Egress Protect March 2024
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
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
Chen, et al. Expires 29 September 2024 [Page 17]