idnits 2.17.1 draft-chen-bier-te-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 21, 2021) is 1159 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) -- Looks like a reference, but probably isn't: '1' on line 144 -- Looks like a reference, but probably isn't: '65535' on line 144 == Unused Reference: 'RFC5226' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC5286' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC7684' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC7770' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC8556' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-segment-routing-ti-lfa' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-protection-sr-te-paths' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'RFC8296' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'RFC8401' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'RFC8444' is defined on line 734, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-09 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5714 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-05 == Outdated reference: A later version (-06) exists of draft-ietf-spring-segment-protection-sr-te-paths-00 Summary: 2 errors (**), 0 flaws (~~), 20 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft M. McBride 4 Intended status: Standards Track Futurewei 5 Expires: August 25, 2021 Y. Liu 6 China Mobile 7 A. Wang 8 China Telecom 9 G. Mishra 10 Verizon Inc. 11 Y. Fan 12 Casa Systems 13 L. Liu 14 Fujitsu 15 X. Liu 16 Volta Networks 17 February 21, 2021 19 BIER-TE Fast ReRoute 20 draft-chen-bier-te-frr-00 22 Abstract 24 This document describes a mechanism for fast re-route (FRR) 25 protection against the failure of a transit node or link on an 26 explicit point to multipoint (P2MP) multicast path/tree in a "Bit 27 Index Explicit Replication" (BIER) Traffic Engineering (TE) domain. 28 It does not have any per-path state in the core. For a multicast 29 packet to traverse a transit node along an explicit P2MP path, when 30 the node fails, its upstream hop node as a PLR reroutes the packet 31 around the failed node along the P2MP path once it detects the 32 failure. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in [RFC2119] [RFC8174] 39 when, and only when, they appear in all capitals, as shown here. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on August 25, 2021. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Overview of BIER-TE FRR . . . . . . . . . . . . . . . . . . . 4 78 3. BIER-TE Extensions for BIER-TE FRR . . . . . . . . . . . . . 5 79 3.1. Extensions to BIER-TE BIFT . . . . . . . . . . . . . . . 5 80 3.2. Updated Forwarding Procedure . . . . . . . . . . . . . . 6 81 4. Example Application of BIER-TE FRR . . . . . . . . . . . . . 7 82 4.1. Example BIER-TE Topology . . . . . . . . . . . . . . . . 7 83 4.2. BIER-TE BIFT on a BFR . . . . . . . . . . . . . . . . . . 8 84 4.3. Extended BIER-TE BIFT on a BFR . . . . . . . . . . . . . 10 85 4.4. Forwarding using Extended BIER-TE BIFT . . . . . . . . . 13 86 4.4.1. Forwarding in Normal Operations . . . . . . . . . . . 13 87 4.4.2. Forwarding in Failure . . . . . . . . . . . . . . . . 13 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 8.2. Informative References . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 96 1. Introduction 98 [I-D.ietf-bier-te-arch] introduces Bit Index Explicit Replication 99 (BIER) Traffic/Tree Engineering (BIER-TE). It is an architecture for 100 per-packet stateless explicit point to multipoint (P2MP) multicast 101 path/tree and based on Bit Index Explicit Replication (BIER) 102 architecture defined in [RFC8279]. It does not require intermediate 103 nodes to maintain any per-path/tree state. 105 [I-D.eckert-bier-te-frr] describes three BIER-TE FRR methods for 106 providing fast protections against the failure of an intermediate 107 node or link on an explicit P2MP BIET-TE path. The first method is 108 Point-to-Point Tunneling (PPT), where a BIER-TE packet is rerouted by 109 the PLR around the failure to its NHs and NNHs through unicast 110 tunnels. This method depends on the tunnels, whose configurations 111 may increase the Opex. The second is BIER-in-BIER Encapsulation 112 (BBE), where a BIER-TE packet is rerouted by the PLR to its NHs and 113 NNHs through encapsulating the packet in another BIER-TE header. 114 This additional header reroutes the packet around the failure towards 115 its NHs and NNHs and may increase the overhead. The third is Header 116 Modification (HM), where the backup path is added into the existing 117 BIER-TE header through using an AddBitmask and a ResetBitmask. The 118 issue of this method is that it may cause duplicated packets for some 119 destinations. 121 This document describes a BIER-TE FRR mechanism without the above 122 issues. For a multicast packet with a BIER-TE header to traverse a 123 transit node along an explicit P2MP path, when the node fails, its 124 upstream hop node as a point of local repair (PLR) reroutes the 125 packet around the failed node to the next hop nodes of the failed 126 node on the P2MP path once it detects the failure. 128 This BIER-TE FRR does not require intermediate nodes to maintain any 129 per-path state for FRR protection against the failure of a transit 130 node or link on any explicit P2MP multicast path. 132 1.1. Terminology 134 BIER: Bit Index Explicit Replication. 136 BIER-TE: BIER Traffic/Tree Engineering. 138 BFR: Bit-Forwarding Router. 140 BFIR: Bit-Forwarding Ingress Router. 142 BFER: Bit-Forwarding Egress Router. 144 BFR-id: BFR Identifier. It is a number in the range [1,65535]. 146 BFR-NBR: BFR Neighbor. 148 F-BM: Forwarding Bit Mask. 150 BFR-prefix: An IP address (either IPv4 or IPv6) of a BFR. 152 BIRT: Bit Index Routing Table. It is a table that maps from the BFR- 153 id (in a particular sub-domain) of a BFER to the BFR-prefix of 154 that BFER, and to the BFR-NBR on the path to that BFER. 156 BIFT: Bit Index Forwarding Table. 158 FRR: Fast Re-Route. 160 PLR: Point of Local Repair. 162 IGP: Interior Gateway Protocol. 164 LSDB: Link State DataBase. 166 SPF: Shortest Path First. 168 SPT: Shortest Path Tree. 170 2. Overview of BIER-TE FRR 172 A Bit-Forwarding Router (BFR) in a BIER-TE domain has a BIER-TE Bit 173 Index Forwarding Tables (BIFT) [I-D.ietf-bier-te-arch]. A BIER-TE 174 BIFT on a BFR comprises a forwarding entry for a BitPosition (BP) 175 assigned to each of the adjacencies of the BFR. If the BP represents 176 a forward connected adjacency, the forwarding entry for the BP 177 forwards the multicast packet with the BP to the directly connected 178 BFR neighbor of the adjacency. If the BP represents a BFER (i.e., 179 egress node) or say a local decap adjacency, the forwarding entry for 180 the BP decapsulates the multicast packet with the BP and passes a 181 copy of the payload of the packet to the packet's NextProto within 182 the BFR. 184 To support BIER-TE FRR (i.e., fast re-route (FRR) protection against 185 the failure of a transit node or link on an explicit P2MP multicast 186 path in a BIER-TE domain), the BIER-TE BIFT on a BFR is extended. 187 For each forwarding entry of the BIER-TE BIFT on the BFR, if it is 188 for the BP representing a forward connected adjacency, the forwarding 189 entry is extended to include a new forwarding entry, which is called 190 FRR forwarding entry or FRR entry for short. 192 Suppose that the BFR-NBR in the forwarding entry for the BP is N. 193 The FRR entry forwards the multicast packet with the BP to the N's 194 next hops that are on the P2MP path encoded in the multicast packet. 196 Once the BFR as a PLR detects the failure of its BFR-NBR N that is a 197 transit node, for a multicast packet with the BP attached to N, the 198 PLR uses the FRR forwarding entry in the extended BIER-TE BIFT to 199 send the packet to the N's next hop nodes that are on the P2MP path 200 encoded in the multicast packet. These next hop nodes forward the 201 packet along the P2MP path towards the egress nodes of the path. 203 Before sending the packet to the N's next hops, for any local decap 204 BP for a destination/BFER in the header, the PLR removes/clears it if 205 it is on the backup path and it is not reachable through the forward 206 connected adjacency BPs in the header (i.e., it is not on any branch 207 from the PLR). 209 3. BIER-TE Extensions for BIER-TE FRR 211 This section describes extensions to a BIER-TE BIFT of a BFR for 212 supporting BIER-TE FRR and enhancements on a forwarding procedure to 213 use the extended BIER-TE BIFT for BIER-TE FRR. 215 3.1. Extensions to BIER-TE BIFT 217 Every BFR has an extended BIER-TE BIFT to support BIER-TE FRR 218 protection against the failure of its neighbor transit node. The 219 forwarding entry with transit node (say N) as its BFR-NBR in the BIFT 220 comprises a FRR forwarding entry (or FRR entry for short). The FRR 221 entry contains a flag FPA (which is short for FRR Protection is 222 Active) and a backup path from the BFR to each of N's next hop nodes. 224 In normal operations, the flag FPA in the FRR entry for neighbor 225 transit node N is set to 0 (zero). The flag FPA is set to 1 (one) 226 when transit node N fails. FPA == 1 means that the FRR protection 227 for transit node N is active and the FRR entry will be used to 228 forward the packet with the BP for the adjacency from the BFR to node 229 N towards N's next hop nodes on the P2MP path encoded in the packet's 230 BitString along the backup paths. 232 The backup path from the BFR to a N's next hop node X is a path that 233 satisfies a set of constraints and does not traverse transit node N 234 or any link connected to N. In one implementation, the backup path 235 is represented by the BitPositions for the adjacencies along the 236 backup path. 238 3.2. Updated Forwarding Procedure 240 The forwarding procedure defined in [I-D.ietf-bier-te-arch] is 241 updated/enhanced for using an extended BIER-TE BIFT to support BIER- 242 TE FRR. 244 For a multicast packet with the BP in the BitString indicating a BFR- 245 NBR as a transit node of the P2MP path encoded in the packet, the 246 updated forwarding procedure on a BFR sends the packet towards the 247 transit node's next hop nodes on the P2MP path if the transit node 248 fails. 250 It checks whether FPA equals to 1 (one) in the forwarding entry with 251 the BFR-NBR that is a transit node of the P2MP path. If FPA is 1 252 (i.e., the transit node fails and the FRR protection for the transit 253 node is active), the procedure clears the BP for the adjacency to the 254 transit node in the packet's BitString first. Secondly, for any 255 local decap BP for a destination/BFER in the BitString, it removes/ 256 clears the BP if the BP is on the backup path and is not reachable by 257 the forward connected adjacency BPs in the BitString (i.e., is not on 258 any branch from the BFR as PLR). And then, for each next hop node of 259 the failed transit node that is on the P2MP path encoded in the 260 packet's BitString, it copies and sends the packet to the next hop 261 node along the backup path from the BFR to the next hop node. 263 For each next hop node of transit node BFR-NBR (which is named as N 264 for simplicity), when N's next hop node is on the P2MP path, the 265 forwarding procedure clears the BP for the adjacency from N to the 266 N's next hop node in the packet's BitString and adds the BPs for the 267 backup path from the BFR to the N's next hop node. This lets the 268 packet be copied and sent to the N's next hop nodes along the backup 269 paths when transit node N fails and then towards the destinations 270 along the P2MP path. 272 The updated procedure is described in Figure 1. It can also be used 273 by the BFR to forward multicast packets in normal operations. 275 Packet = the packet received by BFR; 276 FOR each BP k (from the rightmost in Packet's BitString) { 277 IF (BP k is local decap adjacency) { 278 copies Packet, sends the copy to the multicast 279 flow overlay and clears bit k in Packet's BitString 280 } ELSE IF (BP k is forward connect adjacency of the BFR) { 281 finds the forwarding entry in the BIER-TE BIFT for the domain 282 using BP k; 283 Clears BP k in Packet's BitString; 284 IF (FPA == 1) {//FRR for BFR-NBR/transit N is Active 285 FOR each BP j for a BFER in Packet's BitString { 286 IF (BP j is on a backup path and 287 is not reachable by BPs in BitString) { 288 Clears BP j in Packet's BitString 289 } 290 } 291 FOR each N's next hop on P2MP path in Packet's BitString { 292 Clears the BP for the adjacency from N to the next hop; 293 Adds the BPs for the backup path to N's next hop 294 into Packet's BitString 295 } 296 } //Adjacency to N removed, backup path to N's next hop added 297 ELSE { 298 Copies Packet, updates the copy's BitString by 299 clearing all the BPs for the adjacencies of the BFR, 300 and sends the updated copy to BFR-NBR 301 } 302 } 303 } 305 Figure 1: Updated Forwarding Procedure 307 4. Example Application of BIER-TE FRR 309 This section illustrates an example application of BIER-TE FRR on a 310 BFR in a BIER-TE topology in Figure 2. 312 4.1. Example BIER-TE Topology 314 An example BIER-TE topology for a BIER-TE domain is shown in 315 Figure 2. It has 9 nodes/BFRs A, B, C, D, E, F, G, H and I. Nodes/ 316 BFRs D, F, E, H and A are BFERs and have local decap adjacency 317 BitPositions 1, 2, 3, 4, and 5 respectively. For simplicity, these 318 BPs are represented by (SI:BitString), where SI = 0 and BitString is 319 of 8 bits. BPs 1, 2, 3, 4, and 5 are represented by 1 (0:00000001), 320 2 (0:00000010), 3 (0:00000100), 4 (0:00001000) and 5 (0:00010000) 321 respectively. 323 26' 19' 20' 4 324 /--------------------( G )---------------( H ) 325 / / 18'\ 16'/|28' 326 / 6'/ \17' / | 327 / ________/ ( I )____________/ | 328 25'/ / 14'/ 15' | 329 / 5'/ / | 330 / 8' 7' / 3' 4' /13' 12' |27' 331 ( A )--------( B )------------( C )-----------------( D ) 1 332 5 \1' \9' 11' /24' 333 \ \ / 334 \2' 21' 22' \10' / 335 ( E )------------( F )____________/ 336 3 2 23' 338 Figure 2: Example BIER-TE Topology 340 The BitPositions for the forward connected adjacencies are 341 represented by i', where i is from 1 to 28. In one option, they are 342 encoded as (n+i), where n is a power of 2 such as 32768. For 343 simplicity, these BitPositions are represented by (SI:BitString), 344 where SI = (6 + (i-1)/8) and BitString is of 8 bits. BitPositions i' 345 (i from 1 to 28) are represented by 1'(6:00000001), 2'(6:00000010), 346 3'(6:00000100), 4'(6:00001000), 5'(6:00010000), 6'(6:00100000), 347 7'(6:01000000), 8'(6:10000000), 9'(7:00000001), 10'(7:00000010), . . 348 . , 24'(8:10000000) 25'(9:00000001), 26'(9:00000010), ..., 349 28'(9:00001000). 351 For a link between two nodes X and Y, there are two BitPositions for 352 two forward connected adjacencies. These two forward connected 353 adjacency BitPositions are assigned on nodes X and Y respectively. 354 The BitPosition assigned on X is the forward connected adjacency of 355 Y. The BitPosition assigned on Y is the forward connected adjacency 356 of X. 358 For example, for the link between nodes B and C in the figure, two 359 forward connected adjacency BitPositions 3' and 4' are assigned to 360 two ends of the link. BitPosition 3' is assigned on node B to B's 361 end of the link. It is the forward connected adjacency of node C. 362 BitPosition 4' is assigned on node C to C's end of the link. It is 363 the forward connected adjacency of node B. 365 4.2. BIER-TE BIFT on a BFR 367 Every BFR in a BIER-TE domain/topology has a BIER-TE BIFT. For the 368 BIER-TE topology in Figure 2, each of 9 nodes/BFRs A, B, C, D, E, F, 369 G, H and I has its BIER-TE BIFT for the topology. 371 The BIER-TE BIFT on BFR B (i.e. node B) is shown in Figure 3. 373 The 1st forwarding entry in the BIFT is for BitPosition 2', which is 374 the forward connected adjacency from B to E. For a multicast packet 375 with BitPosition 2', which indicates that the P2MP path in the packet 376 traverses the adjacency from B to E, the forwarding entry forwards 377 the packet to E along the link from B to E. 379 The 2nd forwarding entry in the BIFT is for BitPosition 4', which is 380 the forward connected adjacency from B to C. For a multicast packet 381 with BitPosition 4', which indicates that the P2MP path in the packet 382 traverses the adjacency from B to C, the forwarding entry forwards 383 the packet to C along the link from B to C. 385 The 3rd forwarding entry in the BIFT is for BitPosition 6', which is 386 the forward connected adjacency from B to G. For a multicast packet 387 with BitPosition 6', which indicates that the P2MP path in the packet 388 traverses the adjacency from B to G, the forwarding entry forwards 389 the packet to G along the link from B to G. 391 The 4-th forwarding entry in the BIFT is for BitPosition 8', which is 392 the forward connected adjacency from B to A. For a multicast packet 393 with BitPosition 8', which indicates that the P2MP path in the packet 394 traverses the adjacency from B to A, the forwarding entry forwards 395 the packet to A along the link from B to A. 397 +----------------+--------------+------------+ 398 | Adjacency BP | Action | BFR-NBR | 399 | (SI:BitString) | | (Next Hop) | 400 +================+==============+============+ 401 | 2'(6:00000010) | fw-connected | E | 402 +----------------+--------------+------------+ 403 | 4'(6:00001000) | fw-connected | C | 404 +----------------+--------------+------------+ 405 | 6'(6:00100000) | fw-connected | G | 406 +----------------+--------------+------------+ 407 | 8'(6:10000000) | fw-connected | A | 408 +----------------+--------------+------------+ 410 Figure 3: BIER-TE BIFT on BFR B 412 The BIER-TE BIFT on BFR E (i.e. node E) is shown in Figure 4. 414 The 1st forwarding entry in the BIFT forwards a multicast packet with 415 BitPosition 1' to B. It is for BitPosition 1', which is the forward 416 connected adjacency from E to B. For a multicast packet with 417 BitPosition 1', which indicates that the P2MP path in the packet 418 traverses the adjacency from E to B, the forwarding entry forwards 419 the packet to B along the link from E to B. 421 The 2nd forwarding entry in the BIFT forwards a multicast packet with 422 BitPosition 22' to F. It is for BitPosition 22', which is the 423 forward connected adjacency from E to F. For a multicast packet with 424 BitPosition 22', which indicates that the P2MP path in the packet 425 traverses the adjacency from E to F, the forwarding entry forwards 426 the packet to F along the link from E to F. 428 The 3rd forwarding entry in the BIFT locally decapsulates a multicast 429 packet with BitPosition 3 and passes a copy of the payload of the 430 packet to the packet's NextProto. It is for BitPosition 3, which is 431 the local decap adjacency for BFER (i.e., egress) E. For a multicast 432 packet with BitPosition 3, which indicates that the P2MP path in the 433 packet has node E as one of its destinations (i.e., egress nodes), 434 the forwarding entry decapsulates the packet and passes a copy of the 435 payload of the packet to the packet's NextProto within node E. 437 +----------------+--------------+------------+ 438 | Adjacency BP | Action | BFR-NBR | 439 | (SI:BitString) | | (Next Hop) | 440 +================+==============+============+ 441 | 1'(6:00000001)| fw-connected | B | 442 +----------------+--------------+------------+ 443 | 22'(8:00001000)| fw-connected | F | 444 +----------------+--------------+------------+ 445 | 3 (0:00000100)| local-decap | | 446 +----------------+--------------+------------+ 448 Figure 4: BIER-TE BIFT on BFR D 450 4.3. Extended BIER-TE BIFT on a BFR 452 Every BFR has an extended BIER-TE BIFT to support BIER-TE FRR 453 protection against the failure of its neighbor transit node. 455 For example, the extended BIER-TE BIFT on BFR B is illustrated in 456 Figure 5. Each forwarding entry with transit node (such as E, C and 457 G) as its BFR-NBR in the BIFT comprises a FRR entry. Each of these 458 FRR entries contains a flag FPA and a number of backup paths. For a 459 forwarding entry with transit node X, its FRR entry has a backup path 460 to each of node X's next hop nodes except for BFR B itself. FPA is 461 set to zero in normal operations. FPA in the FRR entry for neighbor 462 transit node X is set to one when node X fails. 464 On BFR B, the 1st forwarding entry in the BIFT has BFR-NBR E as 465 transit node. Nodes F and B are the next hop nodes of node E in 466 Figure 2. The backup path from B to F without E or links attached to 467 E goes through the link from B to C and then the link from C to F. 468 This backup path from B to F is represented by B-->F: {4', 10'} in 469 the FRR entry of the forwarding entry. 471 FPA in the FRR entry is set to 0 (zero) in normal operations. When 472 transit node E fails, the FPA is set to 1 (one) and the FRR entry is 473 used to forward a multicast packet with BitPosition 2' for adjacency 474 from B to E towards E's next hop node F along the backup path from B 475 to F if the P2MP path in the packet traverses node F. 477 +----------------+--------------+----------+-----------------+ 478 | Adjacency BP | Action | BFR-NBR | FRR Entry | 479 | (SI:BitString) | |(Next Hop)|(FPA,BackupPaths)| 480 +================+==============+==========+=================+ 481 | 2'(6:00000010) | fw-connected | E | FPA=0, | 482 +----------------+--------------+----------+ | 483 | B-->F: {4',10'} | 484 +----------------+--------------+----------+-----------------+ 485 | 4'(6:00000010) | fw-connected | C | FPA=0, | 486 +----------------+--------------+----------+ | 487 | B-->F: {2',22'}, B-->D: {6',20',27'}, B-->I: {6',17'} | 488 +----------------+--------------+----------+-----------------+ 489 | 6'(6:00100000) | fw-connected | G | FPA=0, | 490 +----------------+--------------+----------+ | 491 | B-->I: {4',14'}, B-->H: {4',14',16'}, B-->A: {8'} | 492 +----------------+--------------+----------+-----------------+ 493 | 8'(6:10000000) | fw-connected | A | FPA=0, | 494 +----------------+--------------+----------+ | 495 | B-->G: {6'} | 496 +----------------+--------------+----------+-----------------+ 498 Figure 5: Extended BIER-TE BIFT on BFR B 500 On BFR B, the 2nd forwarding entry in the BIFT has BFR-NBR C as 501 transit node. Nodes F, D, I and B are the next hop nodes of node C 502 in Figure 2. The backup path from B to F without C or links attached 503 to C goes through the link from B to E and then the link from E to F. 504 This backup path from B to F is represented by B-->F: {2', 22'} in 505 the FRR entry of the forwarding entry. 507 The backup path from B to D without C or links attached to C goes 508 through the link from B to G, the link from G to H and then the link 509 from H to D. This backup path from B to D is represented by B-->D: 510 {6', 20', 27'} in the FRR entry of the forwarding entry. 512 The backup path from B to I without C or links attached to C goes 513 through the link from B to G and then the link from G to I. This 514 backup path from B to I is represented by B-->I: {6', 17'} in the FRR 515 entry of the forwarding entry. 517 FPA in the FRR entry is set to 0 (zero) in normal operations. When 518 transit node C fails, the FPA is set to 1 (one) and the FRR entry is 519 used to forward a multicast packet with BitPosition 4' for adjacency 520 from B to C towards C's next hop nodes F, D or I along the backup 521 paths from B to F, D or I respectively if the P2MP path in the packet 522 traverses nodes F, D or I. 524 On BFR B, the 3rd forwarding entry in the BIFT has BFR-NBR G as 525 transit node. Nodes I, H, A and B are the next hop nodes of node G 526 in Figure 2. The backup path from B to I without G or links attached 527 to G goes through the link from B to C and then the link from C to I. 528 This backup path from B to I is represented by B-->I: {4', 14'} in 529 the FRR entry of the forwarding entry. 531 The backup path from B to H without G or links attached to G goes 532 through the link from B to C, the link from C to I and then the link 533 from I to H. This backup path from B to H is represented by B-->H: 534 {4', 14', 16'} in the FRR entry of the forwarding entry. 536 The backup path from B to A without G or links attached to G goes 537 through the link from B to A. This backup path from B to A is 538 represented by B-->A: {8'} in the FRR entry of the forwarding entry. 540 FPA in the FRR entry is set to 0 (zero) in normal operations. When 541 transit node G fails, the FPA is set to 1 (one) and the FRR entry is 542 used to forward a multicast packet with BitPosition 6' for adjacency 543 from B to G towards G's next hop nodes I, H or A along the backup 544 paths from B to I, H or A respectively if the P2MP path in the packet 545 traverses nodes I, H or A. 547 On BFR B, the 4-th forwarding entry in the BIFT has BFR-NBR A as 548 transit node. Nodes G and B are the next hop nodes of node A. The 549 backup path from B to G without A or links attached to A goes through 550 the link from B to G. This backup path from B to G is represented by 551 B-->G: {6'} in the FRR entry of the forwarding entry. 553 FPA in the FRR entry is set to 0 (zero) in normal operations. When 554 node A fails, the FPA is set to 1 (one) and the FRR entry is used to 555 forward a multicast packet with BitPosition 8' for adjacency from B 556 to A towards A's next hop node G along the backup path from B to G if 557 the P2MP path in the packet traverses node A as a transit node. 559 4.4. Forwarding using Extended BIER-TE BIFT 561 Suppose that there is an explicit multicast P2MP path from ingress A 562 to egresses H and D, traversing from A to G to H and from A to B to C 563 to D. This path is represented by BPs as {26', 20', 7', 4', 12', 4, 564 1}. The forwarding behaviors in normal operations and in case of BFR 565 C failure are described below. 567 4.4.1. Forwarding in Normal Operations 569 For a multicast packet with the path on BFR A, A sends the packet to 570 G and B according to the forwarding entries for 26' and 7' in A's 571 extended BIER-TE BIFT respectively. The packet received by G and B 572 contains path {20', 4', 12', 4, 1}. 574 After receving the packet from A, G forwards the packet to H 575 according to forwarding entry for 20' in its extended BIER-TE BIFT. 576 The packet received by H contains path {4', 12', 4, 1}. After 577 receving the packet from A, B forwards the packet to C according to 578 forwarding entry for 4' in its extended BIER-TE BIFT. The packet 579 received by C contains path {20', 12', 4, 1}. 581 After receving the packet from G, H decapsulates the packet and 582 passes a copy of the payload of the packet to the packet's NextProto 583 according to forwarding entry for 4 in its extended BIER-TE BIFT. 584 After receving the packet from B, C forwards the packet to D 585 according to forwarding entry for 12' in its extended BIER-TE BIFT. 586 The packet received by D contains path {20', 4, 1}. 588 After receving the packet from C, D decapsulates the packet and 589 passes a copy of the payload of the packet to the packet's NextProto 590 according to forwarding entry for 1 in its extended BIER-TE BIFT. 592 4.4.2. Forwarding in Failure 594 Once BFR B detects the failure of node C, it sets FPA of the FRR 595 entry in the 2nd forwarding entry with BFR-NBR C to one. After 596 receiving the packet from BFR A, which contains path {20', 4', 12', 597 4, 1}, BFR B clears BP 4'; BFR B clears the BP 4 for BFER H since H 598 is on the backup path from B to G to H to D, but not on any branch of 599 the path from B. 601 For C's next hop node D on the P2MP path, BFR B clears adjacency BP 602 12' from C to D and adds the BPs for backup path {6', 20', 27'} from 603 B to G to H to D. The packet has path {6', 20', 27', 1}. BFR B 604 sends the packet to G according to forwarding entry for 6' in its 605 extended BIER-TE BIFT. The packet received by G contains path {20', 606 27', 1}. 608 After receving the packet from B, G forwards the packet to H 609 according to forwarding entry for 20' in its extended BIER-TE BIFT. 610 The packet received by H contains path {27', 1}. 612 After receving the packet from G, H forwards the packet to D 613 according to forwarding entry for 27' in its extended BIER-TE BIFT. 614 The packet received by D contains path {1}. 616 After receving the packet from H, D decapsulates the packet and 617 passes a copy of the payload of the packet to the packet's NextProto 618 according to forwarding entry for 1 in its extended BIER-TE BIFT. 620 5. Security Considerations 622 TBD. 624 6. IANA Considerations 626 No requirements for IANA. 628 7. Acknowledgements 630 The authors would like to thank Daniel Merling for his comments to 631 this work. 633 8. References 635 8.1. Normative References 637 [I-D.ietf-bier-te-arch] 638 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 639 for Bit Index Explicit Replication (BIER-TE)", draft-ietf- 640 bier-te-arch-09 (work in progress), October 2020. 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, 644 DOI 10.17487/RFC2119, March 1997, 645 . 647 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 648 IANA Considerations Section in RFCs", RFC 5226, 649 DOI 10.17487/RFC5226, May 2008, 650 . 652 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 653 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 654 July 2008, . 656 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 657 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 658 DOI 10.17487/RFC5286, September 2008, 659 . 661 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 662 RFC 5714, DOI 10.17487/RFC5714, January 2010, 663 . 665 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 666 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 667 . 669 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 670 Scope Link State PDUs (LSPs)", RFC 7356, 671 DOI 10.17487/RFC7356, September 2014, 672 . 674 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 675 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 676 RFC 7490, DOI 10.17487/RFC7490, April 2015, 677 . 679 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 680 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 681 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 682 2015, . 684 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 685 S. Shaffer, "Extensions to OSPF for Advertising Optional 686 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 687 February 2016, . 689 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 690 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 691 May 2017, . 693 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 694 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 695 Explicit Replication (BIER)", RFC 8279, 696 DOI 10.17487/RFC8279, November 2017, 697 . 699 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 700 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 701 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 702 2019, . 704 8.2. Informative References 706 [I-D.eckert-bier-te-frr] 707 Eckert, T., Cauchie, G., Braun, W., and M. Menth, 708 "Protection Methods for BIER-TE", draft-eckert-bier-te- 709 frr-03 (work in progress), March 2018. 711 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 712 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 713 and D. Voyer, "Topology Independent Fast Reroute using 714 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 715 lfa-05 (work in progress), November 2020. 717 [I-D.ietf-spring-segment-protection-sr-te-paths] 718 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 719 "Segment Protection for SR-TE Paths", draft-ietf-spring- 720 segment-protection-sr-te-paths-00 (work in progress), 721 September 2020. 723 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 724 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 725 for Bit Index Explicit Replication (BIER) in MPLS and Non- 726 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 727 2018, . 729 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 730 Zhang, "Bit Index Explicit Replication (BIER) Support via 731 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 732 . 734 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 735 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 736 Extensions for Bit Index Explicit Replication (BIER)", 737 RFC 8444, DOI 10.17487/RFC8444, November 2018, 738 . 740 Authors' Addresses 742 Huaimo Chen 743 Futurewei 744 Boston, MA 745 USA 747 Email: Huaimo.chen@futurewei.com 748 Mike McBride 749 Futurewei 751 Email: michael.mcbride@futurewei.com 753 Yisong Liu 754 China Mobile 756 Email: liuyisong@chinamobile.com 758 Aijun Wang 759 China Telecom 760 Beiqijia Town, Changping District 761 Beijing, 102209 762 China 764 Email: wangaj3@chinatelecom.cn 766 Gyan S. Mishra 767 Verizon Inc. 768 13101 Columbia Pike 769 Silver Spring MD 20904 770 USA 772 Phone: 301 502-1347 773 Email: gyan.s.mishra@verizon.com 775 Yanhe Fan 776 Casa Systems 777 USA 779 Email: yfan@casa-systems.com 781 Lei Liu 782 Fujitsu 784 USA 786 Email: liulei.kddi@gmail.com 787 Xufeng Liu 788 Volta Networks 790 McLean, VA 791 USA 793 Email: xufeng.liu.ietf@gmail.com