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,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
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,
<https://www.rfc-editor.org/info/rfc5286>.
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]