Internet DRAFT - draft-chen-bier-te-egress-protect

draft-chen-bier-te-egress-protect







Network Working Group                                            H. Chen
Internet-Draft                                                M. McBride
Intended status: Standards Track                               Futurewei
Expires: 28 June 2024                                            A. Wang
                                                           China Telecom
                                                               G. Mishra
                                                            Verizon Inc.
                                                                  Y. Liu
                                                            China Mobile
                                                                  Y. Fan
                                                            Casa Systems
                                                                  L. Liu
                                                                 Fujitsu
                                                                  X. Liu
                                                               Alef Edge
                                                        26 December 2023


                       BIER-TE Egress Protection
                  draft-chen-bier-te-egress-protect-06

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 28 June 2024                  [Page 1]

Internet-Draft           BIER-TE Egress Protect            December 2023


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 28 June 2024.

Copyright Notice

   Copyright (c) 2023 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 28 June 2024                  [Page 2]

Internet-Draft           BIER-TE Egress Protect            December 2023


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 28 June 2024                  [Page 3]

Internet-Draft           BIER-TE Egress Protect            December 2023


   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 28 June 2024                  [Page 4]

Internet-Draft           BIER-TE Egress Protect            December 2023


   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 28 June 2024                  [Page 5]

Internet-Draft           BIER-TE Egress Protect            December 2023


   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 28 June 2024                  [Page 6]

Internet-Draft           BIER-TE Egress Protect            December 2023


   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 28 June 2024                  [Page 7]

Internet-Draft           BIER-TE Egress Protect            December 2023


   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 28 June 2024                  [Page 8]

Internet-Draft           BIER-TE Egress Protect            December 2023


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 28 June 2024                  [Page 9]

Internet-Draft           BIER-TE Egress Protect            December 2023


   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 28 June 2024                 [Page 10]

Internet-Draft           BIER-TE Egress Protect            December 2023


              +----------------+--------------+------------+
              |  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 28 June 2024                 [Page 11]

Internet-Draft           BIER-TE Egress Protect            December 2023


   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 28 June 2024                 [Page 12]

Internet-Draft           BIER-TE Egress Protect            December 2023


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 28 June 2024                 [Page 13]

Internet-Draft           BIER-TE Egress Protect            December 2023


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 28 June 2024                 [Page 14]

Internet-Draft           BIER-TE Egress Protect            December 2023


   [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]
              Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
              Decraene, B., and D. Voyer, "Topology Independent Fast
              Reroute using Segment Routing", Work in Progress,



Chen, et al.              Expires 28 June 2024                 [Page 15]

Internet-Draft           BIER-TE Egress Protect            December 2023


              Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
              12, 17 November 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
              segment-routing-ti-lfa-12>.

   [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-05, 27 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              segment-protection-sr-te-paths-05>.

   [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: Huaimo.chen@futurewei.com


   Mike McBride
   Futurewei
   Email: michael.mcbride@futurewei.com




Chen, et al.              Expires 28 June 2024                 [Page 16]

Internet-Draft           BIER-TE Egress Protect            December 2023


   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 28 June 2024                 [Page 17]