BIER Egress Protection

1.1. Terminology

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.¶

PLR:

Point of Local Repair.¶

LFA:

Loop-Free Alternate.¶

Basic LFA:

It is the LFA defined in [RFC5286].¶

RLFA:

Remote LFA. It is the LFA defined in [RFC7490].¶

TI-LFA:

Topology Independent LFA. It is the LFA defined in [I-D.ietf-rtgwg-segment-routing-ti-lfa].¶

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.¶

FIB:

Forwarding Information Base or Forwarding Table.¶

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. Using the LSA of LS type 9, node P will advertise the information only to its neighbors (which will not advertise the information further). Using the LSA of LS type 10, node P will advertise the information to the whole BIER network domain (i.e., P's neighbors will advertise the information further until the information reaches every node in the domain). The information is included in a backup egress node TLV. The format of the TLV is shown in Figure 2.¶

After each of the neighbors receives the backup egress node TLV, 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 BIER packet with the bit for destination P towards node P's backup egress node.¶

  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            |S| BFR-id of backup egress node  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Sub-TLVs (Optional)                     |
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.¶

Reserved:

15 bits, they MUST be set to zero when sending and be ignored while receiving.¶

S flag:

1 bit. It is set to one to indicate that the primary egress and backup egress send their BIER packets' payloads to the same CE receiver ; it is set to zero to indicate that the primary egress and backup egress send their BIER packets' payloads to different CE receivers .¶

BFR-id of backup egress node:

2 octets, its value is the BFR-id 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.¶

3.2. Extensions to IS-IS

For supporting fast protection against the failure of a primary egress node in a BIER domain, a new IS-IS TLV, called IS-IS backup egress node TLV, is defined. It contains the BFR-id of a backup 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 using a IS-IS backup egress node TLV.¶

This TLV may be advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link State PDUs (CS-LSP) [RFC7356]. Using CS-LSP or IIH PDUs, node P will advertise the information only to its neighbors. Using LSPs, node P will advertise the information to the whole BIER network domain. The format of the TLV is shown in Figure 3.¶

  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    |          Reserved           |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | BFR-id of backup egress node  |    Sub-TLVs (Optional)        ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

1 octet, its value (TBD2) is to be assigned by IANA.¶

Length:

1 octet, its value is 4 plus the length of the Sub-TLVs included. If no Sub-TLV is included, its value is 4.¶

The other fields are the same as those in Figure 2.¶

4.1. Integrated one BIFT

A BFR has an integrated BIFT for both normal operations and protections against the failure of each of its neighbor BFERs. That is that the normal BIFT on the BFR is extended to have a backup entry (or say sub-entry) for each of its neighbor BFERs.¶

+--------------+-------+-------+---+---+----------+-------+---------+
|    BFR-id    | F-BM  |BFR-NBR|BEA|SC | BE-BFER  | BF-BM |BBFR-NBR |
|(SI:BitString)|       |       |   |   |          |       |         |
+==============+=======+=======+===+===+==========+=======+=========+
|  1 (0:00001) | 00001 |   D   | 0 | 1 | H(01000) | 01001 |    H    |
+--------------+-------+-------+---+---+----------+-------+---------+
|  2 (0:00010) | 00110 |   F   | 0 | 0 | E(00100) | 00010 |E(TI-LFA)|
+--------------+-------+-------+---+---+----------+-------+---------+
|  3 (0:00100) | 00110 |   F   | 0 | 0 | F(00010) | 00110 |    F    |
+--------------+-------+-------+---+---+----------+-------+---------+
|  4 (0:01000) | 01000 |   H   | 0 | 1 | D(00001) | 01001 |    D    |
+--------------+-------+-------+---+---+----------+-------+---------+
|  5 (0:10000) | 10000 |   B   | 0 |   |    0     | NULL  |   NULL  |
+--------------+-------+-------+---+---+----------+-------+---------+

+--------------+-------+-------+
|    BFR-id    | F-BM  |BFR-NBR|
|(SI:BitString)|       |       |
+==============+=======+=======+
|  1 (0:00001) | 10111 |   C   |
+--------------+-------+-------+
|  2 (0:00010) | 10111 |   C   |
+--------------+-------+-------+
|  3 (0:00100) | 10111 |   C   |
+--------------+-------+-------+
|  4 (0:01000) | 01000 |   H   |
+--------------+-------+-------+
|  5 (0:10000) | 10111 |   C   |
+--------------+-------+-------+

+--------------+-------+-------+---+---+----------+-------+---------+
|    BFR-id    | F-BM  |BFR-NBR|BEA|SC | BE-BFER  | BF-BM |BBFR-NBR |
|(SI:BitString)|       |       |   |   |          |       |/P-FIB   |
+==============+=======+=======+===+===+==========+=======+=========+
|  1 (0:00001) | 10111 |   C   | 0 | 0 | H(01000) | 00001 |P-FIB-4D |
+--------------+-------+-------+---+---+----------+-------+---------+
|  2 (0:00010) | 10111 |   C   | 0 | 0 |          |       |  NULL   |
+--------------+-------+-------+---+---+----------+-------+---------+
|  3 (0:00100) | 10111 |   C   | 0 | 0 |          |       |  NULL   |
+--------------+-------+-------+---+---+----------+-------+---------+
|  4 (0:01000) | 01000 |   H   | 0 | 0 |          |       |  NULL   |
+--------------+-------+-------+---+---+----------+-------+---------+
|  5 (0:10000) | 10111 |   C   | 0 |   |          |       |  NULL   |
+--------------+-------+-------+---+---+----------+-------+---------+

 Packet = the packet received by BFR;
 FOR each BFER k (from the rightmost in Packet's BitString) {
    IF BFER k is the BFR itself {
       copies Packet, sends the copy to the multicast
       flow overlay and clears bit k in Packet's BitString
    } ELSE {
       finds the row in the EP-BIFT for the sub-domain using
       Packet's SI and BitString as the key/index
       IF BEA == 1 { // Primary Egress fails
         IF (BBFR-NBR/P-FIB is Pointer to FIB) {// on Backup Egress
            Sends payload to CE using the FIB for primary egress;
         } ELSE {
            IF (SC == 1) {// on PLR and SC == 1
               clears bit k in Packet's BitString;//BFER k is PE-BFER
               sets bit j in Packet's BitString;  //BFER j is BE-BFER
            } // SC == 0, no updates to packet
            Copies Packet, updates the copy's BitString by ANDing it
            with BF-BM in the entry, sends updated copy to BBFR-NBR;
          }
          updates Packet's BitString by ANDing it with
          the INVERSE of BF-BM;
       } ELSE {
          Copies Packet, updates the copy's BitString by ANDing
          it with F-BM in the entry, sends updated copy to BFR-NBR;
          updates Packet's BitString by ANDing it with the INVERSE
          of the F-BM in the entry
       }
    }
 }

4.2. Multiple Backup BIFTs

A BFR has a normal BIFT and multiple backup BIFTs for egress protection. For each of the BFR's neighbor BFERs, the BFR has a backup BIFT for the BFER, which considers the failure of the BFER. In normal operations, the BFR uses its normal BIFT to forward all the BIER packets. When the BFR detects the failure of the BFER, the BFR uses the backup BIFT for the BFER to forward all the BIER packets.¶

+--------------+-------+-------+---+----------+
|    BFR-id    | F-BM  |BFR-NBR|SC | BE-BFER  |
|(SI:BitString)|       |       |   |          |
+==============+=======+=======+===+==========+
|  1 (0:00001) | 01001 |   H   | 1 | H(01000) |
+--------------+-------+-------+---+----------+
|  2 (0:00010) | 00110 |   F   |   |          |
+--------------+-------+-------+---+----------+
|  3 (0:00100) | 00110 |   F   |   |          |
+--------------+-------+-------+---+----------+
|  4 (0:01000) | 01001 |   H   |   |          |
+--------------+-------+-------+---+----------+
|  5 (0:10000) | 10000 |   B   |   |          |
+--------------+-------+-------+---+----------+

+--------------+-------+---------+---+----------+
|    BFR-id    | F-BM  | BFR-NBR |SC | BE-BFER  |
|(SI:BitString)|       | /P-FIB  |   |          |
+==============+=======+=========+===+==========+
|  1 (0:00001) | 00001 |P-FIB-4D | 0 | H(01000) |
+--------------+-------+---------+---+----------+
|  2 (0:00010) | 00110 |    C    |   |          |
+--------------+-------+---------+---+----------+
|  3 (0:00100) | 00110 |    C    |   |          |
+--------------+-------+---------+---+----------+
|  4 (0:01000) | 01001 |    H    |   |          |
+--------------+-------+---------+---+----------+
|  5 (0:10000) | 10000 |    C    |   |          |
+--------------+-------+---------+---+----------+

 Packet = the packet received by BFR;
 FOR each BFER k (from the rightmost in Packet's BitString) {
    IF BFER k is the BFR itself {
       copies Packet, sends the copy to the multicast
       flow overlay and clears bit k in Packet's BitString
    } ELSE {
       finds the row in the EP-BIFT for the sub-domain using
       Packet's SI and BitString as the key/index
       IF (BFR-NBR/P-FIB is Pointer to FIB) {// on Backup Egress
          Sends payload using the FIB for the primary egress;
       } ELSE {
          IF (SC == 1) {// on PLR and SC == 1
             clears bit k in Packet's BitString;//BFER k is PE-BFER
             sets bit j in Packet's BitString;  //BFER j is BE-BFER
          } // SC == 0, no updates to packet
          Copies Packet, updates the copy's BitString by ANDing
          it with F-BM in the entry, sends updated copy to BFR-NBR;
       }
       updates Packet's BitString by ANDing it with the INVERSE
       of the F-BM in the entry
    }
 }

5.1. BIRT and BIFT on a BFR

Every BFR in a BIER sub-domain/topology builds and maintains a Bit Index Routing Table (BIRT). For the BIER topology in Figure 1, each of 8 nodes/BFRs A, B, C, D, E, F, G and H builds and maintains a BIRT using the LSDB for the topology.¶

The BIRT built on BFR C (i.e., node C) is shown in Figure 11.¶

           +----------------+--------------+------------+
           |     BFR-id     |  BFR-Prefix  |  BFR-NBR   |
           | (SI:BitString) | of Dest BFER | (Next Hop) |
           +================+==============+============+
           |  1 (0:00001)   |     D        |     D      |
           +----------------+--------------+------------+
           |  2 (0:00010)   |     F        |     F      |
           +----------------+--------------+------------+
           |  3 (0:00100)   |     E        |     F      |
           +----------------+--------------+------------+
           |  4 (0:01000)   |     H        |     H      |
           +----------------+--------------+------------+
           |  5 (0:10000)   |     A        |     B      |
           +----------------+--------------+------------+

The 1st row in the BIRT indicates that the next hop BFR-NBR on the shortest path to BFER D with BFR-id 1 is BFR D.¶

The 2nd row in the BIRT indicates that the next hop BFR-NBR on the shortest path to BFER F with BFR-id 2 is BFR F.¶

The 3rd row in the BIRT indicates that the next hop BFR-NBR on the shortest path to BFER E with BFR-id 3 is BFR F.¶

The 4-th row in the BIRT indicates that the next hop BFR-NBR on the shortest path to BFER H with BFR-id 4 is BFR H.¶

The 5-th row in the BIRT indicates that the next hop BFR-NBR on the shortest path to BFER A with BFR-id 5 is BFR B.¶

From this BIRT on BFR C, a Bit Index Forwarding Table (BIFT) is derived. This BIFT is shown in Figure 12.¶

The 2nd and 3-th rows in the BIRT have the same SI = 0 and next hop BFR-NBR = F. The F-BM for each of these two rows in the BIFT is the logical OR of the BitStrings of these rows, which is 00110 (00010 OR 00100 = 00110).¶

The F-BM for 1st row in the BIFT is 00001.¶

The F-BM for 4-th row in the BIFT is 01000.¶

The F-BM for 5-th row in the BIFT is 10000.¶

              +----------------+---------+------------+
              |     BFR-id     |  F-BM   |  BFR-NBR   |
              | (SI:BitString) |         | (Next Hop) |
              +================+=========+============+
              |  1 (0:00001)   |  00001  |     D      |
              +----------------+---------+------------+
              |  2 (0:00010)   |  00110  |     F      |
              +----------------+---------+------------+
              |  3 (0:00100)   |  00110  |     F      |
              +----------------+---------+------------+
              |  4 (0:01000)   |  01000  |     H      |
              +----------------+---------+------------+
              |  5 (0:10000)   |  10000  |     B      |
              +----------------+---------+------------+

5.2. Backup BIRTs and Backup BIFTs on a BFR

Each of the BFRs that are neighbors of egress nodes (i.e., BFERs) in a BIER sub-domain/topology builds and maintains a number of Egress Protection Bit Index Routing Tables (EP-BIRTs) or say backup BIRTs.¶

For the BIER topology in Figure 1,¶

           BFR B is the neighbor of BFERs A and E;
           BFR C is the neighbor of BFERs D, F and H;
           BFR E is the neighbor of BFER F;
           BFR F is the neighbor of BFER E;
           BFR G is the neighbor of BFERs D and H.

Each of 5 nodes/BFRs B, C, E, F and G builds and maintains a number of backup BIRTs using the LSDB for the topology for its every BFR-NBR as an egress node.¶

For example, BFR C (i.e., node C) in the BIER topology builds and maintains three backup BIRTs for its three BFR-NBRs (BFERs D, F and H) that are egress nodes respectively.¶

The backup BIRT for BEFR D built by BFR C based on the BIRT on BFR C (refer to Figure 11) is shown in Figure 13.¶

The BIRT is copied to the backup BIRT for BFER D (i.e., the first three columns of the backup BIRT). The new backup information (i.e., the 4-th column) for every row in the backup BIRT is initialized with BE-BFER = 0/NULL.¶

     +--------------+--------------+----------+-----------+
     |    BFR-id    |  BFR-Prefix  |  BFR-NBR |  BE-BFER  |
     |(SI:BitString)| of Dest BFER |(Next Hop)|           |
     +==============+==============+==========+===========+
     |  1 (0:00001) |      D       |    H     |     H     |
     +--------------+--------------+----------+-----------+
     |  2 (0:00010) |      F       |    F     |     0     |
     +--------------+--------------+----------+-----------+
     |  3 (0:00100) |      E       |    F     |     0     |
     +--------------+--------------+----------+-----------+
     |  4 (0:01000) |      H       |    H     |     0     |
     +--------------+--------------+----------+-----------+
     |  5 (0:10000) |      A       |    B     |     0     |
     +--------------+--------------+----------+-----------+

In the backup BIRT for BFER D, the row that has Destination BFER == D is the 1st row. This row has the new backup information BE-BFER = H, which indicates that BFER D (i.e., primary egress node D) is protected by BFER H (i.e., backup egress node H). Each of the other rows has the new backup information BE-BFER = 0/NULL.¶

The 1st row in the EP-BIRT indicates that the packet with destination D will be sent to D's backup egress node H when D fails.¶

The 2nd row in the backup BIRT indicates that the next hop BFR-NBR on the path to BFER F with BFR-id 2 is BFR F.¶

The 3rd row in the backup BIRT indicates that the next hop BFR-NBR on the path to BFER E with BFR-id 3 is BFR F.¶

The 4-th row in the backup BIRT indicates that the next hop BFR-NBR on the path to BFER H with BFR-id 4 is BFR H.¶

The 5-th row in the backup BIRT indicates that the next hop BFR-NBR on the path to BFER A with BFR-id 5 is BFR B.¶

From this backup BIRT for BFER D on BFR C, an Egress Protection Bit Index Forwarding Table (EP-BIFT) or say backup BIFT for BFER D is derived. This backup BIFT for BFER D is shown in Figure 14.¶

The first and 4-th rows in the backup BIRT have the same next hop BFR-NBR = H. The F-BM for each of these two rows in the backup BIFT is the logical OR of the BitStrings of these rows, which is 01001 (00001 OR 01000 = 01001).¶

The 2nd and 3rd rows in the backup BIRT have the same next hop BFR-NBR = E. The F-BM for each of these two rows in the backup BIFT is the logical OR of the BitStrings of these rows, which is 00110 (00010 OR 00100 = 00110).¶

      +----------------+---------+------------+----+----------+
      |     BFR-id     |  F-BM   |  BFR-NBR   | SC | BE-BFER  |
      | (SI:BitString) |         | (Next Hop) |    |          |
      +================+=========+============+====+==========+
      |  1 (0:00001)   |  01001  |     H      | 1  |    H     |
      +----------------+---------+------------+----+----------+
      |  2 (0:00010)   |  00110  |     F      | 0  |    0     |
      +----------------+---------+------------+----+----------+
      |  3 (0:00100)   |  00110  |     F      | 0  |    0     |
      +----------------+---------+------------+----+----------+
      |  4 (0:01000)   |  01001  |     H      | 0  |    0     |
      +----------------+---------+------------+----+----------+
      |  5 (0:10000)   |  10000  |     B      | 0  |    0     |
      +----------------+---------+------------+----+----------+

The F-BM for 5-th row in the backup BIFT is 10000.

5.3. Forwarding using Backup BIFT

Suppose that there is a multicast traffic from BFR A as ingress/BFIR to egresses/BFERs D, F and E. For every packet of the traffic, after receiving it, BFR A adds a BIER header into the packet and sends the packet with the BIER header to BFR B, which sends the packet BFR C. The BIER header contains (SI:BitString) = (0:00111) for egresses/BFERs D, F and E.¶

In normal operations, after receiving the packet from BFR B, BFR C copies, updates and sends the packet to BFR D and BFR F using the normal BIFT on BFR C according to the forwarding procedure defined in [RFC8279].¶

Once BFR C detects the failure of its BFR-NBR D, which is a BFER, after receiving the packet from BFR B, BFR C copies, updates and sends the packet using the backup BIFT for BFER D on BFR C according to the updated forwarding procedure.¶

For the packet targeting to BFER D (i.e., primary egress node), BFR C sends it towards BFER H (i.e., backup egress node), which is configured to protect BFER D.¶

For example, once BFR C detects the failure of its BFR-NBR D, after receiving the packet from BFR B, BFR C copies, updates and sends the packet to BFR H and BFR F using the backup BIFT for BFER D on BFR C.¶

The packet received by BFR C from BFR B contains (SI:BitString) = (0:00111). The rightmost one bit in BitString is bit 1. For BFER 1 (0:00001) (i.e., BFR D as BFER), BFR C gets the 1st row (i.e., forwarding entry) in the backup BIFT for BFER D. BE-BFER = H in the row indicates that BFER D is protected against the failure of D by backup BFER H. BFR C clears bit 1 in Packet's BitString and sets bit 4 (i.e., the bit for BE-BFER = H) in Packet's BitString to one since SC = 1. The BitString in Packet is 01110 now. BFR C copies, updates the BitString by ANDing it with F-BM (which is 01001) and sends the packet copy with BitString = 01000 to BFR-NBR H in the entry.¶

After sending the packet to H, BFR C updates the original packet by ANDing its BitString with the INVERSE of the F-BM in the first row. The updated BitString = 00110, which is 01110 & ~F-BM in the row = 01110 & 10110 = 00110.¶

For the packet containing BitString = 00110, the rightmost one bit in BitString is bit 2. For BFER 2 (0:00010) (i.e., BFR F as BFER), BFR C gets the 2nd row (i.e., forwarding entry) in the backup BIFT for BFER D. The next hop BFR-NBR is F in the row. BFR C copies, updates and sends the packet to F.¶

The packet sent to F contains the updated BitString = 00110, which is 00110 & F-BM in the 2nd row = 00110 & 00110 = 00110.¶

After sending the packet to F, BFR C updates the original packet by ANDing its BitString with the INVERSE of the F-BM in the 2nd row. The updated BitString = 00000, which is 00110 & ~F-BM in the row = 00110 & 11001 = 00000.¶

The updated packet has BitString without any one bit. BFR C finishes forwarding the packet to F and H (backup for D). BFR F will sends the packet to E.¶

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>.

[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>.

9.2. Informative References

[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-10, 27 April 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-10>.

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

[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>.