Network Working Group H. Chen Internet-Draft M. McBride Intended status: Standards Track Futurewei Expires: 16 February 2023 A. Wang China Telecom G. Mishra Verizon Inc. Y. Liu China Mobile Y. Fan Casa Systems L. Liu Fujitsu X. Liu IBM Corporation 15 August 2022 BIER-TE Egress Protection draft-chen-bier-te-egress-protect-03 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 16 February 2023 [Page 1] Internet-Draft BIER-TE Egress Protect August 2022 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 16 February 2023. Copyright Notice Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . 11 5.3. Extended BIER-TE BIFT on a BFR . . . . . . . . . . . . . 12 5.4. Forwarding using Extended BIER-TE BIFT . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Chen, et al. Expires 16 February 2023 [Page 2] Internet-Draft BIER-TE Egress Protect August 2022 1. Introduction [I-D.ietf-bier-te-arch] 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 16 February 2023 [Page 3] Internet-Draft BIER-TE Egress Protect August 2022 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) [I-D.ietf-bier-te-arch]. 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. Chen, et al. Expires 16 February 2023 [Page 4] Internet-Draft BIER-TE Egress Protect August 2022 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 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. Chen, et al. Expires 16 February 2023 [Page 5] Internet-Draft BIER-TE Egress Protect August 2022 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. 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. Chen, et al. Expires 16 February 2023 [Page 6] Internet-Draft BIER-TE Egress Protect August 2022 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. 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 [I-D.ietf-bier-te-arch] 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). Chen, et al. Expires 16 February 2023 [Page 7] Internet-Draft BIER-TE Egress Protect August 2022 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. 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. Chen, et al. Expires 16 February 2023 [Page 8] Internet-Draft BIER-TE Egress Protect August 2022 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 the forwarding entry in the BIER-TE BIFT for the domain 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, updates the copy's BitString by clearing all the BPs for the adjacencies of the BFR, and sends the updated copy to BFR-NBR } } } Figure 3: Updated Forwarding Procedure 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. Chen, et al. Expires 16 February 2023 [Page 9] Internet-Draft BIER-TE Egress Protect August 2022 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. 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. Chen, et al. Expires 16 February 2023 [Page 10] Internet-Draft BIER-TE Egress Protect August 2022 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 16 February 2023 [Page 11] Internet-Draft BIER-TE Egress Protect August 2022 +----------------+--------------+------------+ | 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 16 February 2023 [Page 12] Internet-Draft BIER-TE Egress Protect August 2022 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 16 February 2023 [Page 13] Internet-Draft BIER-TE Egress Protect August 2022 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 16 February 2023 [Page 14] Internet-Draft BIER-TE Egress Protect August 2022 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 [I-D.ietf-bier-te-arch] Eckert, T., Menth, M., and G. Cauchie, "Tree Engineering for Bit Index Explicit Replication (BIER-TE)", Work in Progress, Internet-Draft, draft-ietf-bier-te-arch-13, 25 April 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, . [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, . [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, . Chen, et al. Expires 16 February 2023 [Page 15] Internet-Draft BIER-TE Egress Protect August 2022 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, . [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, . [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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . 9.2. Informative References [I-D.eckert-bier-te-frr] Eckert, 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, . Chen, et al. Expires 16 February 2023 [Page 16] Internet-Draft BIER-TE Egress Protect August 2022 [I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A., 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- 08, 21 January 2022, . [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-03, 7 March 2022, . [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. Decraene, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, . [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, . [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, . [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, . Authors' Addresses Huaimo Chen Futurewei Boston, MA, United States of America Email: Huaimo.chen@futurewei.com Chen, et al. Expires 16 February 2023 [Page 17] Internet-Draft BIER-TE Egress Protect August 2022 Mike McBride Futurewei Email: michael.mcbride@futurewei.com 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 IBM Corporation United States of America Email: xufeng.liu.ietf@gmail.com Chen, et al. Expires 16 February 2023 [Page 18]