BIER Working Group D. Merling Internet-Draft M. Menth Intended status: Standards Track University of Tuebingen Expires: September 6, 2019 March 05, 2019 BIER Fast Reroute draft-merling-bier-frr-00 Abstract BIER is a scalable multicast overlay [RFC8279] that utilizes some routing underlay, e.g., IP, to build up its Bit Index Forwarding Tables (BIFTs). This document proposes a Fast Reroute Extension for BIER (BIER-FRR). In case of a link or node failure, the routing underlay may first utilize FRR techniques to restore connectivity and then its forwarding tables converge. After that, BIER can update its BIFTs, which requires time. BIER packets may not be delivered until the last procedure has finished. With BIER-FRR, a BIER Forwarding Router (BFR) can deliver BIER packets again after a link or node failures as soon as the connectivity within the routing underlay is restored and the BFR is informed about a next-hop (NH) that is unreachable on a lower layer. BIER-FRR provides a mode for link protection and node protection. For link protection, it tunnels traffic to the next-hop using the underlying routing. For node protection, it forwards BIER packets to their specific next-hop and next-next-hops using tunnels in the underlying routing after applying a suitable backup bitmask to the bitstring in the BIER header of each packet. This procedure prevents duplicates. If topology allows, BIER-FRR achieves full protection against any single component failure. For link protection, BIER-FRR requires only a minor change to the forwarding logic. For node protection, BIER-FRR also requires backup entries in the BIFT. This document describes the concept and operating principles of BIER- FRR. It defines the necessary modifications to the BIER forwarding Procedure and the BIFT, and explains how backup entries are computed. 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/. Merling & Menth Expires September 6, 2019 [Page 1] Internet-Draft BIER-FRR March 2019 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 September 6, 2019. Copyright Notice Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Link Failures . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. BIER Encapsulation within a Lower-Layer Technology with Protection . . . . . . . . . . . . . . . . . . . 6 3.1.2. BIER Encapsulation within the Routing Underlay . . . 6 3.1.3. BIER Encapsulation within a Lower-Layer Technology without Protection . . . . . . . . . . . . . . . . . 7 3.2. Node Failures . . . . . . . . . . . . . . . . . . . . . . 7 4. Fast Reroute Extension for BIER (BIER-FRR) . . . . . . . . . 7 4.1. BIER-FRR Link Protection . . . . . . . . . . . . . . . . 7 4.1.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. Example . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. BIER-FRR Node Protection . . . . . . . . . . . . . . . . 8 4.2.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Example . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Computation of Backup BIFT Entries . . . . . . . . . 11 4.2.3.1. Computation . . . . . . . . . . . . . . . . . . . 11 4.2.3.2. Example . . . . . . . . . . . . . . . . . . . . . 12 4.3. Protection Level . . . . . . . . . . . . . . . . . . . . 12 5. Necessary Changes to the BIER Architecture . . . . . . . . . 13 5.1. Unicast Tunneling . . . . . . . . . . . . . . . . . . . . 13 Merling & Menth Expires September 6, 2019 [Page 2] Internet-Draft BIER-FRR March 2019 5.2. Detecting Unreachable N(N)Hs . . . . . . . . . . . . . . 13 5.3. BIFT with backup entries . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction With BIER [RFC8279], Bit-Forwarding Routers (BFRs) forward packets based on a bitstring in the BIER header using the information in their Bit Index Forwarding Tables (BIFTs). In case of a persistent link or node failure, BIER traffic may not be delivered until the BIFT has been updated based on the re-converged routing underlay. The routing underlay restores connectivity more quickly than BIER, in particular if the routing underlay leverages fast reroute (FRR) mechanisms because then the forwarding ability is retained before forwarding tables of the routing underlay have converged. In this document we propose Fast Reroute Extension for BIER (BIER-FRR). It enables a BFR to quickly reroute BIER packets as soon as the underlying routing works again and it is informed about a next-hop (NH) that is unreachable on a lower layer. We first explain the problem and distinguish link and node failures for that purpose. In case of a persistent link failure, a BFR cannot deliver BIER traffic until the NH in the BIFT is updated with an appropriate node. In case of a node failure, the entire multicast subtree behind the failed not is not reachable until the BIFT is updated. Thus, in either case, BIER's connectivity is restored only after the underlying routing has converged and the BIFTs have been updated. This may require substantial time during which BIER traffic is dropped. An exception are unreachable NHs to which BIER traffic is sent through tunnels in the routing underlay. They are reachable again as soon as the routing underlay works again. BIER-FRR tackles this problems with two different modes that have different implementation complexity: link protection and node protection. In any case, a BFR with an unreachable NH needs to be informed about the failure and acts as a point of local repair (PLR). E.g., BFD mechanisms may be used [I-D.hu-bier-bfd] to detect failed NHs. With BIER-FRR link protection, a BFR tunnels affected BIER packets towards the NH using a tunnel in the underlying routing. Then, this traffic can be delivered as soon as the underlying routing works again. With BIER-FRR node protection, a BFR tunnels affected BIER packets to the NH and all relevant next-next-hops (NNHs) in the underlying routing after applying suitables backup bitmasks to the Merling & Menth Expires September 6, 2019 [Page 3] Internet-Draft BIER-FRR March 2019 bitstring in the BIER header. This procedure ensures that both the NH and all potential multicast subtrees receive the traffic if possible, and it prevents potential duplicates and loops on the BIER layer. Thus, BIER-FRR basically implements 1:1 protection. The latter is discussed in [I-D.xiong-bier-resilience] without proposing a specific mechanism. This document describes the concept of BIER-FRR, protection properties, the computation of backup bitmasks, and gives a detailed BIER-FRR forwarding example. 2. Terminology The following sections require the understanding of certain abbreviations and definitions that were defined within other documents, especially [RFC8279]. To facilitate the reading of this document, they are shortly explained in this section. o BFR: Bit-Forwarding Router, Section 1 of [RFC8279] A device that acts as a BIER forwarding device in the BIER domain. o BFIR: Bit-Forwarding Ingress Router, Section 1 of [RFC8279] Entry point to the BIER domain. A BFIR adds a BIER header to a multicast packet. o BFER: Bit-Forwarding Egress Router, Section 1 of [RFC8279] Exit point of the BIER domain. A BFER removes the BIER header of a multicast packet. o NH: Next-hop The next downstream BFR to which a packet is forwarded. o BIFT: Bit Index Forwarding Table, Section 6.4 of [RFC8279] A BFR uses its BIFT to determine the NH(s) of a BIER packet. The BIFT maps a F-BM to each NH of a BFR. o F-BM: Forwarding bitmask Section 6.4 of [RFC8279] A F-BM is a bitmask that indicates which destinations are reached via the subtree of the corresponding NH. A F-BM is applied to the BIER header by bitwise AND'ing the F-BM with the bitstring in the BIER header. This prevents duplicates at BFERs. Merling & Menth Expires September 6, 2019 [Page 4] Internet-Draft BIER-FRR March 2019 o Routing underlay: Section 4.1 of [RFC8279] The routing underlay connects pairs of BFR. If a typical Interior Gateway Protocol (IGP) like OSPF is used, the multicast packets will be forwarded on shortest paths. Other routing underlays with different path layouts are possible. The routing underlay is used to determine the NH entries of the BIFT. o BIER Layer: Section 4.2 of [RFC8279] Conceptually the BIER layer is placed above the routing underlay. The BIER layer can be understood as a transport layer for multicast packets. It consists of all necessary protocols and mechanisms to forward a BIER packet from a BFIR, over potentially multiple BFRs, to a set of BFERs. o Multicast Overlay: Section 4.3 of [RFC8279] Conceptually the multicast overlay is placed above the BIER layer. It is used to maintain information about egress points of multicast groups. The multicast overlay passes those information to the BIER layer which then determines the corresponding BIER headers. o PLR: Point of Local Repair A node that cannot forward a packet due to an unreachable NH. o BIER-FRR: Fast Reroute Extension for BIER (BIER-FRR) A mechanism to restore connectivity on the BIER layer as soon as BFRs are informed about non-reachable NHs and the underlying routing works again. o BIER-FRR link protection A mode of BIER-FRR that can handle only link failures. o BIER-FRR node protection A mode of BIER-FRR that can handle both link and node failures. It is more complex than BIER-FRR link protection. o NNH: Next-next-hop Next downstream BFR after the NH. Merling & Menth Expires September 6, 2019 [Page 5] Internet-Draft BIER-FRR March 2019 2.1. 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]. 3. Problem Statement We first consider the impact of link failures and then the one of node failures on the behavior of a BIER network without BIER-FRR. 3.1. Link Failures The effect of a link failure depends on the technology used for encapsulation of BIER packets. We distinguish three cases. (1) BIER packets are carried over some lower-layer technology with protection. (2) BIER packets are tunneled through the routing underlay. (3) BIER packets are carried over some lower-layer technology without protection. 3.1.1. BIER Encapsulation within a Lower-Layer Technology with Protection MPLS is an example for a lower-layer technology with protection capabilities. In case of a link failure, first packets are lost, then the protection mechanism of the lower-layer technology quickly restores the link. From then on, packets are no longer lost. 3.1.2. BIER Encapsulation within the Routing Underlay IP is an example for a routing underlay. The routing underlay is expected to deal with failures of lower- layer technologies. In case of a link failure, packets are lost. If the failure persists due to a lower-layer technology without protection, the routing underlay is informed about the failure. The routing underlay may leverage FRR techniques, e.g., Loop-Free Alternates (LFAs) [RFC5286], to quickly restore reachability so that packets are delivered again which are sent encapsulated the within routing underlay. From then on, also BIER packets encapsulated within the routing underlay are delivered again. At the same time, routing reconvergence is triggered. When the routing has converged after some time, forwarding tables of the routing underlay are updated. Based on them, new NHs for BIFTs are computed and installed so that the PLR delivers BIER packets to a different NH than the one that is still unreachable via the lower- layer technology. Merling & Menth Expires September 6, 2019 [Page 6] Internet-Draft BIER-FRR March 2019 3.1.3. BIER Encapsulation within a Lower-Layer Technology without Protection Ethernet is an example for a lower-layer technology without protection. In case of a link failure, the failure persists from the perspective of BIER and the routing underlay unless the failure is repaired. As a consequence, packets are lost. Then, the routing underlay acts as described above to restore rechability and finally updates its forwarding tables. By that time, BIER packets encapsulated within the lower-layer technology are still dropped. Then, new NHs for BIFTs are computed based on the new forwarding tables of the routing underlay and are installed. From then on, BIER can deliver packets again over a different NH. When BIER-FRR is used, BIER packets can be delivered again as soon as the BFR is informed about the unreachable NH and routing underlay works again. 3.2. Node Failures The effect of node failures is more severe. First, the packets cannot be delivered to the failed node. This, however, cannot be repaired. Second, multicast distribution trees downstream of a failed NH cannot receive traffic as the failed NH replicate traffic towards relevant NNHs. This problem is solved neither by lower-layer technologies with link protection nor by BIER encapsulation within the routing underlay. Therefore, BIER packets sent to the failed NH are dropped until BIFTs are updated based on reconverged forwarding tables of the routing underlay. This may require quite some time. When BIER-FRR node protection is used, BIER packets can be delivered along the affected multicast tree as soon as the BFR is informed about the unreachable NH and the routing underlay works again. 4. Fast Reroute Extension for BIER (BIER-FRR) This section describes the concept of BIER-FRR. In case of a link or node failure, it reroutes BIER packets until the BIFTs are updated or the failure is repaired. BIER-FRR offers two modes: link protection and node protection. Their protection level is summarized. 4.1. BIER-FRR Link Protection We introduce the mechanism and illustrate it by an example. Merling & Menth Expires September 6, 2019 [Page 7] Internet-Draft BIER-FRR March 2019 4.1.1. Mechanism When a BFR is informed about an unreachable NH, it tunnels all BIER packets towards that NH through the routing underlay. As soon as the routing underlay works again, the BIER packets are delivered to the NH if the NH still works. Then, the NH forwards the BIER packets further along the multicast distribution tree. 4.1.2. Example Figure 1 shows an example toplogy for the routing underlay and Figure 2 the multicast distribution tree for BFR 1 on the BIER Layer which is computed based on shortest paths. 1------2------3 | | 4------| Figure 1: Example topology for the routing underlay. 1 / \ 2 4 / 3 Figure 2: Multicast distribution tree for BFR 1 on the BIER Layer. When BFR 1 sends a packet to BFR 3, the NH is BFR 2. If link 1<->2 fails, packets encapsulated within a lower-layer technology can no longer be delivered from BFR 1 to BFR 2. As soon as BFR 1 is informed that BFR 2 is no longer reachable, it encapsulates the BIER packets to BFR 3 within the routing underlay towards BFR 2. When the routing underlay has restored connectivity, the BIER packets are tunneled from BFR 1 via BFR 4 to BFR 2 which decapsulates them. Then BFR further forwards the BIER packets to BFR 3. 4.2. BIER-FRR Node Protection We introduce the mechanism, illustrate it by an example, and explain how needed backup BIFT entries are computed. 4.2.1. Mechanism When a BFR is informed about an unreachable NH, it tunnels all affected BIER packets to that NH if the NH receives a copy of the BIER packet, and to all NNHs over which copies of the BIER packet are Merling & Menth Expires September 6, 2019 [Page 8] Internet-Draft BIER-FRR March 2019 to be delivered. The latter are the relevant NNHs. Before tunneling the packets, their bitstrings are modified using backup F-BMs to avoid forwarding loops and duplicates. The BIFT and its operation are explained in detail in Section 6.4 of [RFC8279]. We briefly revise them to facilitate further reading before introducing backup BIFT entries to support the solution presented above. Figure 3 illustrates the structure of the BIFT. The BIFT contains for each BFR-id a F-BM and the next hop (BFR-NBR). The BFR-id is mapped to a position in the bitstring of the BIER header; for this purpose, the bits within a bitstring are counted from right to left starting with 1. The F-BM is also a bitstring and indicates all BFRs that are reachable through the multicast distribution subtree via BFR-NBR. As a result, the F-BMs in a BIFT are either identical (same BFR-NBR) or disjoint with regard to activated bits. For transmission of BIER packets, the BIFT is used together with a copy of the bitstring of the BIER header. Processing is performed by the following loop. An entry from the BIFT is selected that holds a BFR-id which is set in the copy of the bitstring. Then, the F-BM of that entry is applied to the bitstring of the BIER packet and then the BIER packet is sent to the indicated BFR-NBR. The bits of the F-BM are cleared in the bitstring copy and the loop restarts. It ends when all bits in the bitstring copy are zero. -------------------------------------------------------------- | BFR-id | F-BM | BFR-NBR | -------------------------------------------------------------- | 1 | | | Figure 3: Structure of the BIFT according to [RFC8279]. -------------------------------------------------------------- | BFR-id | F-BM | BFR-NBR | -------------------------------------------------------------- | 1 | primary F-BM | primary NH | | | backup F-BM | backup NH | -------------------------------------------------------------- | ... | ... | ... | Figure 4: Structure of a BIFT with primary and backup entries. To support BIER-FRR node protection, backup BIFT entries for protected BFR-NBRs are added to the BIFT. That structure is illustrated in Figure 4. We call the normal BIFT entries primary entries. Backup BIFT entries have the same structure as primary BIFT entries and are used for forwarding in the same way. The set of Merling & Menth Expires September 6, 2019 [Page 9] Internet-Draft BIER-FRR March 2019 active bits in a primary BIFT entry must equal the set of active bits in its corresponding backup entries to guarantee that all destinations in the multicast distribution subtree via BFR-NBR are protected. If the BFR-NBR of a primary BIFT entry is reachable, the corresponding backup BIFT entries are ignored in the forwarding process. If the BFR-NBR of a primary BIFT entry is unreachable, the BIER packet is processed using the corresponding backup BIFT entries instead of the primary BIFT entry. BIER packets sent by a backup BIFT entry MUST be tunneled through the routing underlay to the backup BFR-NBR after application of the backup F-BM. There are other options to organize the backup entries just as there are options for more scalable BIFT organization. 4.2.2. Example Figure 5 shows an example toplogy for the routing underlay and Figure 6 the multicast distribution trees for BFR 1 and BFR 2 on the BIER Layer which are computed based on shortest paths. 1------2------5 | | | 3------4------6 Figure 5: Example topology for the routing underlay. 1 2 / \ /|\ 2 3 4 5 1 / \ / \ 4 5 3 6 / 6 Figure 6: Multicast distribution trees for BFR 1 and BFR 2 on the BIER Layer. Figure 7 gives the BIFT for BFR 1 with backup entries. Merling & Menth Expires September 6, 2019 [Page 10] Internet-Draft BIER-FRR March 2019 --------------------------------- | FRR-BIFT BFR 1 | --------------------------------- | BFR-id | F-BM | BFR-NBR | --------------------------------- | 1 | 000001 | - | | | - | - | --------------------------------- | 2 | 111010 | 2 | | | 000010 | 2 | --------------------------------- | 3 | 000100 | 3 | | | 000100 | 3 | --------------------------------- | 4 | 111010 | 2 | | | 101000 | 4 | --------------------------------- | 5 | 111010 | 2 | | | 010000 | 5 | --------------------------------- | 6 | 111010 | 2 | | | 101000 | 4 | --------------------------------- Figure 7: BIFT of BFR 1 with backup entries. When BFR 1 sends a BIER packet to BFR 6, the NH is BFR 2. If link 1<->2 fails, BIER packets encapsulated within a lower-layer technology can no longer be delivered from BFR 1 to BFR 2. As soon as BFR 1 is informed that BFR 2 is no longer reachable, it applies backup BIFT entries to forward affected BIER packets. That means, it modifies the bitstring of BIER packets towards BFR 6 with the appropriate backup F-BM and sends them to backup NH BFR 4 after encapsulation within the routing underlay. Therefore, the packets are tunneled from BFR 1 via BFR 3 to BFR 4. BFR 4 decapsulates the packet and a copy of the BIER packet is delivered to BFR 6. 4.2.3. Computation of Backup BIFT Entries We explain the computation and give an example. 4.2.3.1. Computation BIER-FRR node protection ensures that a PLR can send BIER packets in case of an unreachable NH to all BFRs in the downstream multicast subtree of the unreachable NH. For this purpose, backup entries for these BFRs need to be provided in the BIFT of the PLR. We compute them differently for the NHs of PLRs and for all other BFRs which Merling & Menth Expires September 6, 2019 [Page 11] Internet-Draft BIER-FRR March 2019 belong to multicast subtrees starting with a NNH. This leads to two computation rules: 1. BIER packets for NHs are sent to the NHs (backup-NH = NH) via a tunnel and the backup F-BM must ensure that these BIER packets are not forwarded any further. That means, the backup F-BM contains only the BFR-id of the NH. 2. BIER packets for other BFRs are sent via a tunnel to the NNH in the multicast subtree they belong to. Also all other BFRs in the same multicast subtree should be reached with the same BIER packet. Therefore, the backup F-BM for a BFR contains the BFR- ids for all BFRs in its multicast subtree starting with the respective NNH. Thus, the corresponding backup F-BM can be computed by ANDing the PLR's F-BM for the NH and the NH's F-BM for the specific NNH. 4.2.3.2. Example We consider the BIFT of BFR 1 in Figure 7. Example for rule (1): The backup BIFT entry for BFR 2 has a F-BM that just contains BFR 2 (000010). Example for rule (2): The backup BIFT entry for BFR 4 has a F-BM that contains BFR 4 and BFR 6 (101000). It is computed ANDing the F-BM of BFR 1 for BFR 2 (111010) and the F-BM of BFR 2 for BFR 4 (101100). The latter has been derived from the multicast distribution tree of BFR 2 in Figure 6. 4.3. Protection Level BIER-FRR is a protection scheme that reacts when a NH is no longer reachable. It is a local mechanism that does not require signaling or cooperation with other nodes, possibly except for the detection of locally unreachable NHs. The protection ensures that BIER multicast traffic is forwarded to all destinations that are reachable over the routing underlay and that no duplicates occur. The protection is fast as it works as soon as the BFR is informed about a unreachable NH and the underlying routing works again after the failure occurred. BIER-FRR link protection is able to protect single link failures within a network provided that the underlying routing can restore full connectivity. Multiple link failures within a network are not necessarily protected. Merling & Menth Expires September 6, 2019 [Page 12] Internet-Draft BIER-FRR March 2019 BIER-FRR node protection protects both single link and single node failures within a network provided that the underlying routing can restore full connectivity. Multiple link and node failures within a network are not necessarily protected. The design of BIER-FRR guarantees loop-freeness on the BIER layer. Since the BIER packet is tunneled, the BIER is header is only used for forwarding if the tunneled packet arrives at the designated BFR. Loop-freeness on the routing underlay is out of the scope of this document. 5. Necessary Changes to the BIER Architecture This section serves as an overview to list the necessary conceptual features or changes that are required for BIER-FRR. 5.1. Unicast Tunneling Unicast tunnels to connect two not directly adjacent BFRs are already available. This feature is described in Section 6.9 of [RFC8279]. 5.2. Detecting Unreachable N(N)Hs A liveness component (e.g. BFD) has to be added to enable the detection of unreachable NHs. This feature has been proposed in [I-D.hu-bier-bfd]. 5.3. BIFT with backup entries The BIFT has to be extended with backup entries as described in Section XXX. When the regular BIER forwarding procedure yields an unreachable NH, the backup entry contains a backup F-BM for header modification and a NNH to which the BIER packet should be tunneled to. 6. Security Considerations This memo does not extend the security considerations for BIER. 7. IANA Considerations This document requests no action by IANA. 8. References Merling & Menth Expires September 6, 2019 [Page 13] Internet-Draft BIER-FRR March 2019 8.1. Normative References [I-D.hu-bier-bfd] hu, f., Mirsky, G., Xiong, Q., and C. Liu, "BIER BFD", draft-hu-bier-bfd-02 (work in progress), October 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . 8.2. Informative References [I-D.xiong-bier-resilience] Xiong, Q., hu, f., and G. Mirsky, "The Resilience for BIER", draft-xiong-bier-resilience-01 (work in progress), October 2018. [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, . Authors' Addresses Daniel Merling University of Tuebingen Sand 13 Tuebingen 72076 Germany Phone: +49 7071 29-70507 Email: daniel.merling@uni-tuebingen.de Merling & Menth Expires September 6, 2019 [Page 14] Internet-Draft BIER-FRR March 2019 Michael Menth University of Tuebingen Sand 13 Tuebingen 72076 Germany Phone: +49 7071 29-70505 Email: menth@uni-tuebingen.de Merling & Menth Expires September 6, 2019 [Page 15]