idnits 2.17.1 draft-merling-bier-frr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8279]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 05, 2019) is 1877 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-hu-bier-bfd-02 == Outdated reference: A later version (-02) exists of draft-xiong-bier-resilience-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Working Group D. Merling 3 Internet-Draft M. Menth 4 Intended status: Standards Track University of Tuebingen 5 Expires: September 6, 2019 March 05, 2019 7 BIER Fast Reroute 8 draft-merling-bier-frr-00 10 Abstract 12 BIER is a scalable multicast overlay [RFC8279] that utilizes some 13 routing underlay, e.g., IP, to build up its Bit Index Forwarding 14 Tables (BIFTs). This document proposes a Fast Reroute Extension for 15 BIER (BIER-FRR). In case of a link or node failure, the routing 16 underlay may first utilize FRR techniques to restore connectivity and 17 then its forwarding tables converge. After that, BIER can update its 18 BIFTs, which requires time. BIER packets may not be delivered until 19 the last procedure has finished. With BIER-FRR, a BIER Forwarding 20 Router (BFR) can deliver BIER packets again after a link or node 21 failures as soon as the connectivity within the routing underlay is 22 restored and the BFR is informed about a next-hop (NH) that is 23 unreachable on a lower layer. BIER-FRR provides a mode for link 24 protection and node protection. For link protection, it tunnels 25 traffic to the next-hop using the underlying routing. For node 26 protection, it forwards BIER packets to their specific next-hop and 27 next-next-hops using tunnels in the underlying routing after applying 28 a suitable backup bitmask to the bitstring in the BIER header of each 29 packet. This procedure prevents duplicates. If topology allows, 30 BIER-FRR achieves full protection against any single component 31 failure. For link protection, BIER-FRR requires only a minor change 32 to the forwarding logic. For node protection, BIER-FRR also requires 33 backup entries in the BIFT. 35 This document describes the concept and operating principles of BIER- 36 FRR. It defines the necessary modifications to the BIER forwarding 37 Procedure and the BIFT, and explains how backup entries are computed. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 6, 2019. 56 Copyright Notice 58 Copyright (c) 2019 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 76 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 77 3.1. Link Failures . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1.1. BIER Encapsulation within a Lower-Layer Technology 79 with Protection . . . . . . . . . . . . . . . . . . . 6 80 3.1.2. BIER Encapsulation within the Routing Underlay . . . 6 81 3.1.3. BIER Encapsulation within a Lower-Layer Technology 82 without Protection . . . . . . . . . . . . . . . . . 7 83 3.2. Node Failures . . . . . . . . . . . . . . . . . . . . . . 7 84 4. Fast Reroute Extension for BIER (BIER-FRR) . . . . . . . . . 7 85 4.1. BIER-FRR Link Protection . . . . . . . . . . . . . . . . 7 86 4.1.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . 8 87 4.1.2. Example . . . . . . . . . . . . . . . . . . . . . . . 8 88 4.2. BIER-FRR Node Protection . . . . . . . . . . . . . . . . 8 89 4.2.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . 8 90 4.2.2. Example . . . . . . . . . . . . . . . . . . . . . . . 10 91 4.2.3. Computation of Backup BIFT Entries . . . . . . . . . 11 92 4.2.3.1. Computation . . . . . . . . . . . . . . . . . . . 11 93 4.2.3.2. Example . . . . . . . . . . . . . . . . . . . . . 12 94 4.3. Protection Level . . . . . . . . . . . . . . . . . . . . 12 95 5. Necessary Changes to the BIER Architecture . . . . . . . . . 13 96 5.1. Unicast Tunneling . . . . . . . . . . . . . . . . . . . . 13 97 5.2. Detecting Unreachable N(N)Hs . . . . . . . . . . . . . . 13 98 5.3. BIFT with backup entries . . . . . . . . . . . . . . . . 13 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 103 8.2. Informative References . . . . . . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 106 1. Introduction 108 With BIER [RFC8279], Bit-Forwarding Routers (BFRs) forward packets 109 based on a bitstring in the BIER header using the information in 110 their Bit Index Forwarding Tables (BIFTs). In case of a persistent 111 link or node failure, BIER traffic may not be delivered until the 112 BIFT has been updated based on the re-converged routing underlay. 113 The routing underlay restores connectivity more quickly than BIER, in 114 particular if the routing underlay leverages fast reroute (FRR) 115 mechanisms because then the forwarding ability is retained before 116 forwarding tables of the routing underlay have converged. In this 117 document we propose Fast Reroute Extension for BIER (BIER-FRR). It 118 enables a BFR to quickly reroute BIER packets as soon as the 119 underlying routing works again and it is informed about a next-hop 120 (NH) that is unreachable on a lower layer. 122 We first explain the problem and distinguish link and node failures 123 for that purpose. In case of a persistent link failure, a BFR cannot 124 deliver BIER traffic until the NH in the BIFT is updated with an 125 appropriate node. In case of a node failure, the entire multicast 126 subtree behind the failed not is not reachable until the BIFT is 127 updated. Thus, in either case, BIER's connectivity is restored only 128 after the underlying routing has converged and the BIFTs have been 129 updated. This may require substantial time during which BIER traffic 130 is dropped. An exception are unreachable NHs to which BIER traffic 131 is sent through tunnels in the routing underlay. They are reachable 132 again as soon as the routing underlay works again. 134 BIER-FRR tackles this problems with two different modes that have 135 different implementation complexity: link protection and node 136 protection. In any case, a BFR with an unreachable NH needs to be 137 informed about the failure and acts as a point of local repair (PLR). 138 E.g., BFD mechanisms may be used [I-D.hu-bier-bfd] to detect failed 139 NHs. With BIER-FRR link protection, a BFR tunnels affected BIER 140 packets towards the NH using a tunnel in the underlying routing. 141 Then, this traffic can be delivered as soon as the underlying routing 142 works again. With BIER-FRR node protection, a BFR tunnels affected 143 BIER packets to the NH and all relevant next-next-hops (NNHs) in the 144 underlying routing after applying suitables backup bitmasks to the 145 bitstring in the BIER header. This procedure ensures that both the 146 NH and all potential multicast subtrees receive the traffic if 147 possible, and it prevents potential duplicates and loops on the BIER 148 layer. Thus, BIER-FRR basically implements 1:1 protection. The 149 latter is discussed in [I-D.xiong-bier-resilience] without proposing 150 a specific mechanism. 152 This document describes the concept of BIER-FRR, protection 153 properties, the computation of backup bitmasks, and gives a detailed 154 BIER-FRR forwarding example. 156 2. Terminology 158 The following sections require the understanding of certain 159 abbreviations and definitions that were defined within other 160 documents, especially [RFC8279]. To facilitate the reading of this 161 document, they are shortly explained in this section. 163 o BFR: Bit-Forwarding Router, Section 1 of [RFC8279] 165 A device that acts as a BIER forwarding device in the BIER domain. 167 o BFIR: Bit-Forwarding Ingress Router, Section 1 of [RFC8279] 169 Entry point to the BIER domain. A BFIR adds a BIER header to a 170 multicast packet. 172 o BFER: Bit-Forwarding Egress Router, Section 1 of [RFC8279] 174 Exit point of the BIER domain. A BFER removes the BIER header of 175 a multicast packet. 177 o NH: Next-hop 179 The next downstream BFR to which a packet is forwarded. 181 o BIFT: Bit Index Forwarding Table, Section 6.4 of [RFC8279] 183 A BFR uses its BIFT to determine the NH(s) of a BIER packet. The 184 BIFT maps a F-BM to each NH of a BFR. 186 o F-BM: Forwarding bitmask Section 6.4 of [RFC8279] 188 A F-BM is a bitmask that indicates which destinations are reached 189 via the subtree of the corresponding NH. A F-BM is applied to the 190 BIER header by bitwise AND'ing the F-BM with the bitstring in the 191 BIER header. This prevents duplicates at BFERs. 193 o Routing underlay: Section 4.1 of [RFC8279] 195 The routing underlay connects pairs of BFR. If a typical Interior 196 Gateway Protocol (IGP) like OSPF is used, the multicast packets 197 will be forwarded on shortest paths. Other routing underlays with 198 different path layouts are possible. The routing underlay is used 199 to determine the NH entries of the BIFT. 201 o BIER Layer: Section 4.2 of [RFC8279] 203 Conceptually the BIER layer is placed above the routing underlay. 204 The BIER layer can be understood as a transport layer for 205 multicast packets. It consists of all necessary protocols and 206 mechanisms to forward a BIER packet from a BFIR, over potentially 207 multiple BFRs, to a set of BFERs. 209 o Multicast Overlay: Section 4.3 of [RFC8279] 211 Conceptually the multicast overlay is placed above the BIER layer. 212 It is used to maintain information about egress points of 213 multicast groups. The multicast overlay passes those information 214 to the BIER layer which then determines the corresponding BIER 215 headers. 217 o PLR: Point of Local Repair 219 A node that cannot forward a packet due to an unreachable NH. 221 o BIER-FRR: Fast Reroute Extension for BIER (BIER-FRR) 223 A mechanism to restore connectivity on the BIER layer as soon as 224 BFRs are informed about non-reachable NHs and the underlying 225 routing works again. 227 o BIER-FRR link protection 229 A mode of BIER-FRR that can handle only link failures. 231 o BIER-FRR node protection 233 A mode of BIER-FRR that can handle both link and node failures. 234 It is more complex than BIER-FRR link protection. 236 o NNH: Next-next-hop 238 Next downstream BFR after the NH. 240 2.1. Requirements Language 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 244 document are to be interpreted as described in [RFC2119]. 246 3. Problem Statement 248 We first consider the impact of link failures and then the one of 249 node failures on the behavior of a BIER network without BIER-FRR. 251 3.1. Link Failures 253 The effect of a link failure depends on the technology used for 254 encapsulation of BIER packets. We distinguish three cases. (1) BIER 255 packets are carried over some lower-layer technology with protection. 256 (2) BIER packets are tunneled through the routing underlay. (3) BIER 257 packets are carried over some lower-layer technology without 258 protection. 260 3.1.1. BIER Encapsulation within a Lower-Layer Technology with 261 Protection 263 MPLS is an example for a lower-layer technology with protection 264 capabilities. In case of a link failure, first packets are lost, 265 then the protection mechanism of the lower-layer technology quickly 266 restores the link. From then on, packets are no longer lost. 268 3.1.2. BIER Encapsulation within the Routing Underlay 270 IP is an example for a routing underlay. The routing underlay is 271 expected to deal with failures of lower- layer technologies. In case 272 of a link failure, packets are lost. If the failure persists due to 273 a lower-layer technology without protection, the routing underlay is 274 informed about the failure. The routing underlay may leverage FRR 275 techniques, e.g., Loop-Free Alternates (LFAs) [RFC5286], to quickly 276 restore reachability so that packets are delivered again which are 277 sent encapsulated the within routing underlay. From then on, also 278 BIER packets encapsulated within the routing underlay are delivered 279 again. 281 At the same time, routing reconvergence is triggered. When the 282 routing has converged after some time, forwarding tables of the 283 routing underlay are updated. Based on them, new NHs for BIFTs are 284 computed and installed so that the PLR delivers BIER packets to a 285 different NH than the one that is still unreachable via the lower- 286 layer technology. 288 3.1.3. BIER Encapsulation within a Lower-Layer Technology without 289 Protection 291 Ethernet is an example for a lower-layer technology without 292 protection. In case of a link failure, the failure persists from the 293 perspective of BIER and the routing underlay unless the failure is 294 repaired. As a consequence, packets are lost. Then, the routing 295 underlay acts as described above to restore rechability and finally 296 updates its forwarding tables. By that time, BIER packets 297 encapsulated within the lower-layer technology are still dropped. 298 Then, new NHs for BIFTs are computed based on the new forwarding 299 tables of the routing underlay and are installed. From then on, BIER 300 can deliver packets again over a different NH. 302 When BIER-FRR is used, BIER packets can be delivered again as soon as 303 the BFR is informed about the unreachable NH and routing underlay 304 works again. 306 3.2. Node Failures 308 The effect of node failures is more severe. First, the packets 309 cannot be delivered to the failed node. This, however, cannot be 310 repaired. Second, multicast distribution trees downstream of a 311 failed NH cannot receive traffic as the failed NH replicate traffic 312 towards relevant NNHs. This problem is solved neither by lower-layer 313 technologies with link protection nor by BIER encapsulation within 314 the routing underlay. Therefore, BIER packets sent to the failed NH 315 are dropped until BIFTs are updated based on reconverged forwarding 316 tables of the routing underlay. This may require quite some time. 318 When BIER-FRR node protection is used, BIER packets can be delivered 319 along the affected multicast tree as soon as the BFR is informed 320 about the unreachable NH and the routing underlay works again. 322 4. Fast Reroute Extension for BIER (BIER-FRR) 324 This section describes the concept of BIER-FRR. In case of a link or 325 node failure, it reroutes BIER packets until the BIFTs are updated or 326 the failure is repaired. BIER-FRR offers two modes: link protection 327 and node protection. Their protection level is summarized. 329 4.1. BIER-FRR Link Protection 331 We introduce the mechanism and illustrate it by an example. 333 4.1.1. Mechanism 335 When a BFR is informed about an unreachable NH, it tunnels all BIER 336 packets towards that NH through the routing underlay. As soon as the 337 routing underlay works again, the BIER packets are delivered to the 338 NH if the NH still works. Then, the NH forwards the BIER packets 339 further along the multicast distribution tree. 341 4.1.2. Example 343 Figure 1 shows an example toplogy for the routing underlay and 344 Figure 2 the multicast distribution tree for BFR 1 on the BIER Layer 345 which is computed based on shortest paths. 347 1------2------3 348 | | 349 4------| 351 Figure 1: Example topology for the routing underlay. 353 1 354 / \ 355 2 4 356 / 357 3 359 Figure 2: Multicast distribution tree for BFR 1 on the BIER Layer. 361 When BFR 1 sends a packet to BFR 3, the NH is BFR 2. If link 1<->2 362 fails, packets encapsulated within a lower-layer technology can no 363 longer be delivered from BFR 1 to BFR 2. As soon as BFR 1 is 364 informed that BFR 2 is no longer reachable, it encapsulates the BIER 365 packets to BFR 3 within the routing underlay towards BFR 2. When the 366 routing underlay has restored connectivity, the BIER packets are 367 tunneled from BFR 1 via BFR 4 to BFR 2 which decapsulates them. Then 368 BFR further forwards the BIER packets to BFR 3. 370 4.2. BIER-FRR Node Protection 372 We introduce the mechanism, illustrate it by an example, and explain 373 how needed backup BIFT entries are computed. 375 4.2.1. Mechanism 377 When a BFR is informed about an unreachable NH, it tunnels all 378 affected BIER packets to that NH if the NH receives a copy of the 379 BIER packet, and to all NNHs over which copies of the BIER packet are 380 to be delivered. The latter are the relevant NNHs. Before tunneling 381 the packets, their bitstrings are modified using backup F-BMs to 382 avoid forwarding loops and duplicates. 384 The BIFT and its operation are explained in detail in Section 6.4 of 385 [RFC8279]. We briefly revise them to facilitate further reading 386 before introducing backup BIFT entries to support the solution 387 presented above. Figure 3 illustrates the structure of the BIFT. 388 The BIFT contains for each BFR-id a F-BM and the next hop (BFR-NBR). 389 The BFR-id is mapped to a position in the bitstring of the BIER 390 header; for this purpose, the bits within a bitstring are counted 391 from right to left starting with 1. The F-BM is also a bitstring and 392 indicates all BFRs that are reachable through the multicast 393 distribution subtree via BFR-NBR. As a result, the F-BMs in a BIFT 394 are either identical (same BFR-NBR) or disjoint with regard to 395 activated bits. For transmission of BIER packets, the BIFT is used 396 together with a copy of the bitstring of the BIER header. Processing 397 is performed by the following loop. An entry from the BIFT is 398 selected that holds a BFR-id which is set in the copy of the 399 bitstring. Then, the F-BM of that entry is applied to the bitstring 400 of the BIER packet and then the BIER packet is sent to the indicated 401 BFR-NBR. The bits of the F-BM are cleared in the bitstring copy and 402 the loop restarts. It ends when all bits in the bitstring copy are 403 zero. 405 -------------------------------------------------------------- 406 | BFR-id | F-BM | BFR-NBR | 407 -------------------------------------------------------------- 408 | 1 | | | 410 Figure 3: Structure of the BIFT according to [RFC8279]. 412 -------------------------------------------------------------- 413 | BFR-id | F-BM | BFR-NBR | 414 -------------------------------------------------------------- 415 | 1 | primary F-BM | primary NH | 416 | | backup F-BM | backup NH | 417 -------------------------------------------------------------- 418 | ... | ... | ... | 420 Figure 4: Structure of a BIFT with primary and backup entries. 422 To support BIER-FRR node protection, backup BIFT entries for 423 protected BFR-NBRs are added to the BIFT. That structure is 424 illustrated in Figure 4. We call the normal BIFT entries primary 425 entries. Backup BIFT entries have the same structure as primary BIFT 426 entries and are used for forwarding in the same way. The set of 427 active bits in a primary BIFT entry must equal the set of active bits 428 in its corresponding backup entries to guarantee that all 429 destinations in the multicast distribution subtree via BFR-NBR are 430 protected. 432 If the BFR-NBR of a primary BIFT entry is reachable, the 433 corresponding backup BIFT entries are ignored in the forwarding 434 process. If the BFR-NBR of a primary BIFT entry is unreachable, the 435 BIER packet is processed using the corresponding backup BIFT entries 436 instead of the primary BIFT entry. BIER packets sent by a backup 437 BIFT entry MUST be tunneled through the routing underlay to the 438 backup BFR-NBR after application of the backup F-BM. 440 There are other options to organize the backup entries just as there 441 are options for more scalable BIFT organization. 443 4.2.2. Example 445 Figure 5 shows an example toplogy for the routing underlay and 446 Figure 6 the multicast distribution trees for BFR 1 and BFR 2 on the 447 BIER Layer which are computed based on shortest paths. 449 1------2------5 450 | | | 451 3------4------6 453 Figure 5: Example topology for the routing underlay. 455 1 2 456 / \ /|\ 457 2 3 4 5 1 458 / \ / \ 459 4 5 3 6 460 / 461 6 463 Figure 6: Multicast distribution trees for BFR 1 and BFR 2 on the 464 BIER Layer. 466 Figure 7 gives the BIFT for BFR 1 with backup entries. 468 --------------------------------- 469 | FRR-BIFT BFR 1 | 470 --------------------------------- 471 | BFR-id | F-BM | BFR-NBR | 472 --------------------------------- 473 | 1 | 000001 | - | 474 | | - | - | 475 --------------------------------- 476 | 2 | 111010 | 2 | 477 | | 000010 | 2 | 478 --------------------------------- 479 | 3 | 000100 | 3 | 480 | | 000100 | 3 | 481 --------------------------------- 482 | 4 | 111010 | 2 | 483 | | 101000 | 4 | 484 --------------------------------- 485 | 5 | 111010 | 2 | 486 | | 010000 | 5 | 487 --------------------------------- 488 | 6 | 111010 | 2 | 489 | | 101000 | 4 | 490 --------------------------------- 492 Figure 7: BIFT of BFR 1 with backup entries. 494 When BFR 1 sends a BIER packet to BFR 6, the NH is BFR 2. If link 495 1<->2 fails, BIER packets encapsulated within a lower-layer 496 technology can no longer be delivered from BFR 1 to BFR 2. As soon 497 as BFR 1 is informed that BFR 2 is no longer reachable, it applies 498 backup BIFT entries to forward affected BIER packets. That means, it 499 modifies the bitstring of BIER packets towards BFR 6 with the 500 appropriate backup F-BM and sends them to backup NH BFR 4 after 501 encapsulation within the routing underlay. Therefore, the packets 502 are tunneled from BFR 1 via BFR 3 to BFR 4. BFR 4 decapsulates the 503 packet and a copy of the BIER packet is delivered to BFR 6. 505 4.2.3. Computation of Backup BIFT Entries 507 We explain the computation and give an example. 509 4.2.3.1. Computation 511 BIER-FRR node protection ensures that a PLR can send BIER packets in 512 case of an unreachable NH to all BFRs in the downstream multicast 513 subtree of the unreachable NH. For this purpose, backup entries for 514 these BFRs need to be provided in the BIFT of the PLR. We compute 515 them differently for the NHs of PLRs and for all other BFRs which 516 belong to multicast subtrees starting with a NNH. This leads to two 517 computation rules: 519 1. BIER packets for NHs are sent to the NHs (backup-NH = NH) via a 520 tunnel and the backup F-BM must ensure that these BIER packets 521 are not forwarded any further. That means, the backup F-BM 522 contains only the BFR-id of the NH. 524 2. BIER packets for other BFRs are sent via a tunnel to the NNH in 525 the multicast subtree they belong to. Also all other BFRs in the 526 same multicast subtree should be reached with the same BIER 527 packet. Therefore, the backup F-BM for a BFR contains the BFR- 528 ids for all BFRs in its multicast subtree starting with the 529 respective NNH. Thus, the corresponding backup F-BM can be 530 computed by ANDing the PLR's F-BM for the NH and the NH's F-BM 531 for the specific NNH. 533 4.2.3.2. Example 535 We consider the BIFT of BFR 1 in Figure 7. 537 Example for rule (1): The backup BIFT entry for BFR 2 has a F-BM that 538 just contains BFR 2 (000010). 540 Example for rule (2): The backup BIFT entry for BFR 4 has a F-BM that 541 contains BFR 4 and BFR 6 (101000). It is computed ANDing the F-BM of 542 BFR 1 for BFR 2 (111010) and the F-BM of BFR 2 for BFR 4 (101100). 543 The latter has been derived from the multicast distribution tree of 544 BFR 2 in Figure 6. 546 4.3. Protection Level 548 BIER-FRR is a protection scheme that reacts when a NH is no longer 549 reachable. It is a local mechanism that does not require signaling 550 or cooperation with other nodes, possibly except for the detection of 551 locally unreachable NHs. 553 The protection ensures that BIER multicast traffic is forwarded to 554 all destinations that are reachable over the routing underlay and 555 that no duplicates occur. The protection is fast as it works as soon 556 as the BFR is informed about a unreachable NH and the underlying 557 routing works again after the failure occurred. 559 BIER-FRR link protection is able to protect single link failures 560 within a network provided that the underlying routing can restore 561 full connectivity. Multiple link failures within a network are not 562 necessarily protected. 564 BIER-FRR node protection protects both single link and single node 565 failures within a network provided that the underlying routing can 566 restore full connectivity. Multiple link and node failures within a 567 network are not necessarily protected. 569 The design of BIER-FRR guarantees loop-freeness on the BIER layer. 570 Since the BIER packet is tunneled, the BIER is header is only used 571 for forwarding if the tunneled packet arrives at the designated BFR. 572 Loop-freeness on the routing underlay is out of the scope of this 573 document. 575 5. Necessary Changes to the BIER Architecture 577 This section serves as an overview to list the necessary conceptual 578 features or changes that are required for BIER-FRR. 580 5.1. Unicast Tunneling 582 Unicast tunnels to connect two not directly adjacent BFRs are already 583 available. This feature is described in Section 6.9 of [RFC8279]. 585 5.2. Detecting Unreachable N(N)Hs 587 A liveness component (e.g. BFD) has to be added to enable the 588 detection of unreachable NHs. This feature has been proposed in 589 [I-D.hu-bier-bfd]. 591 5.3. BIFT with backup entries 593 The BIFT has to be extended with backup entries as described in 594 Section XXX. When the regular BIER forwarding procedure yields an 595 unreachable NH, the backup entry contains a backup F-BM for header 596 modification and a NNH to which the BIER packet should be tunneled 597 to. 599 6. Security Considerations 601 This memo does not extend the security considerations for BIER. 603 7. IANA Considerations 605 This document requests no action by IANA. 607 8. References 608 8.1. Normative References 610 [I-D.hu-bier-bfd] 611 hu, f., Mirsky, G., Xiong, Q., and C. Liu, "BIER BFD", 612 draft-hu-bier-bfd-02 (work in progress), October 2018. 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, 616 DOI 10.17487/RFC2119, March 1997, 617 . 619 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 620 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 621 Explicit Replication (BIER)", RFC 8279, 622 DOI 10.17487/RFC8279, November 2017, 623 . 625 8.2. Informative References 627 [I-D.xiong-bier-resilience] 628 Xiong, Q., hu, f., and G. Mirsky, "The Resilience for 629 BIER", draft-xiong-bier-resilience-01 (work in progress), 630 October 2018. 632 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 633 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 634 DOI 10.17487/RFC5286, September 2008, 635 . 637 Authors' Addresses 639 Daniel Merling 640 University of Tuebingen 641 Sand 13 642 Tuebingen 72076 643 Germany 645 Phone: +49 7071 29-70507 646 Email: daniel.merling@uni-tuebingen.de 647 Michael Menth 648 University of Tuebingen 649 Sand 13 650 Tuebingen 72076 651 Germany 653 Phone: +49 7071 29-70505 654 Email: menth@uni-tuebingen.de