Internet-Draft BIER-TE Egress Protect March 2024
Chen, et al. Expires 29 September 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-chen-bier-te-egress-protect-07
Published:
Intended Status:
Standards Track
Expires:
Authors:
H. Chen
Futurewei
M. McBride
Futurewei
A. Wang
China Telecom
G. Mishra
Verizon Inc.
Y. Liu
China Mobile
Y. Fan
Casa Systems
L. Liu
Fujitsu
X. Liu
Alef Edge

BIER-TE Egress Protection

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

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

This Internet-Draft will expire on 29 September 2024.

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

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.

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.

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

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.

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.

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

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.

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

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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc5286>.
[RFC5714]
Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, , <https://www.rfc-editor.org/info/rfc5714>.
[RFC5880]
Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8279]
Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, , <https://www.rfc-editor.org/info/rfc8279>.
[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, , <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, , <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, , <https://datatracker.ietf.org/doc/html/draft-eckert-bier-te-frr-03>.
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-13, , <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-13>.
[I-D.ietf-spring-segment-protection-sr-te-paths]
Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, "Segment Protection for SR-TE Paths", Work in Progress, Internet-Draft, draft-ietf-spring-segment-protection-sr-te-paths-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-protection-sr-te-paths-06>.
[RFC7431]
Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. Decraene, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8444>.

Authors' Addresses

Huaimo Chen
Futurewei
Boston, MA,
United States of America
Mike McBride
Futurewei
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Gyan S. Mishra
Verizon Inc.
13101 Columbia Pike
Silver Spring, MD 20904
United States of America
Phone: 301 502-1347
Yisong Liu
China Mobile
Yanhe Fan
Casa Systems
United States of America
Lei Liu
Fujitsu
United States of America
Xufeng Liu
Alef Edge
United States of America