idnits 2.17.1 draft-chen-bier-te-frr-02.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 (22 February 2022) is 786 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 143 -- Looks like a reference, but probably isn't: '65535' on line 143 == Unused Reference: 'RFC5226' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC5286' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'RFC7684' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC7770' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC8556' is defined on line 697, 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 719, but no explicit reference was found in the text == Unused Reference: 'RFC8296' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'RFC8401' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'RFC8444' is defined on line 738, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-12 ** 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-08 == Outdated reference: A later version (-06) exists of draft-ietf-spring-segment-protection-sr-te-paths-02 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: 26 August 2022 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 22 February 2022 19 BIER-TE Fast ReRoute 20 draft-chen-bier-te-frr-02 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 26 August 2022. 58 Copyright Notice 60 Copyright (c) 2022 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 (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Overview of BIER-TE FRR . . . . . . . . . . . . . . . . . . . 4 77 3. BIER-TE Extensions for BIER-TE FRR . . . . . . . . . . . . . 5 78 3.1. Extensions to BIER-TE BIFT . . . . . . . . . . . . . . . 5 79 3.2. Updated Forwarding Procedure . . . . . . . . . . . . . . 6 80 4. Example Application of BIER-TE FRR . . . . . . . . . . . . . 7 81 4.1. Example BIER-TE Topology . . . . . . . . . . . . . . . . 7 82 4.2. BIER-TE BIFT on a BFR . . . . . . . . . . . . . . . . . . 8 83 4.3. Extended BIER-TE BIFT on a BFR . . . . . . . . . . . . . 10 84 4.4. Forwarding using Extended BIER-TE BIFT . . . . . . . . . 13 85 4.4.1. Forwarding in Normal Operations . . . . . . . . . . . 13 86 4.4.2. Forwarding in Failure . . . . . . . . . . . . . . . . 14 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 8.2. Informative References . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 95 1. Introduction 97 [I-D.ietf-bier-te-arch] introduces Bit Index Explicit Replication 98 (BIER) Traffic/Tree Engineering (BIER-TE). It is an architecture for 99 per-packet stateless explicit point to multipoint (P2MP) multicast 100 path/tree and based on Bit Index Explicit Replication (BIER) 101 architecture defined in [RFC8279]. It does not require intermediate 102 nodes to maintain any per-path/tree state. 104 [I-D.eckert-bier-te-frr] describes three BIER-TE FRR methods for 105 providing fast protections against the failure of an intermediate 106 node or link on an explicit P2MP BIET-TE path. The first method is 107 Point-to-Point Tunneling (PPT), where a BIER-TE packet is rerouted by 108 the PLR around the failure to its NHs and NNHs through unicast 109 tunnels. This method depends on the tunnels, whose configurations 110 may increase the Opex. The second is BIER-in-BIER Encapsulation 111 (BBE), where a BIER-TE packet is rerouted by the PLR to its NHs and 112 NNHs through encapsulating the packet in another BIER-TE header. 113 This additional header reroutes the packet around the failure towards 114 its NHs and NNHs and may increase the overhead. The third is Header 115 Modification (HM), where the backup path is added into the existing 116 BIER-TE header through using an AddBitmask and a ResetBitmask. The 117 issue of this method is that it may cause duplicated packets for some 118 destinations. 120 This document describes a BIER-TE FRR mechanism without the above 121 issues. For a multicast packet with a BIER-TE header to traverse a 122 transit node along an explicit P2MP path, when the node fails, its 123 upstream hop node as a point of local repair (PLR) reroutes the 124 packet around the failed node to the next hop nodes of the failed 125 node on the P2MP path once it detects the failure. 127 This BIER-TE FRR does not require intermediate nodes to maintain any 128 per-path state for FRR protection against the failure of a transit 129 node or link on any explicit P2MP multicast path. 131 1.1. Terminology 133 BIER: Bit Index Explicit Replication. 135 BIER-TE: BIER Traffic/Tree Engineering. 137 BFR: Bit-Forwarding Router. 139 BFIR: Bit-Forwarding Ingress Router. 141 BFER: Bit-Forwarding Egress Router. 143 BFR-id: BFR Identifier. It is a number in the range [1,65535]. 145 BFR-NBR: BFR Neighbor. 147 F-BM: Forwarding Bit Mask. 149 BFR-prefix: An IP address (either IPv4 or IPv6) of a BFR. 151 BIRT: Bit Index Routing Table. It is a table that maps from the 152 BFR-id (in a particular sub-domain) of a BFER to the BFR-prefix 153 of that BFER, and to the BFR-NBR on the path to that BFER. 155 BIFT: Bit Index Forwarding Table. 157 FRR: Fast Re-Route. 159 PLR: Point of Local Repair. 161 IGP: Interior Gateway Protocol. 163 LSDB: Link State DataBase. 165 SPF: Shortest Path First. 167 SPT: Shortest Path Tree. 169 2. Overview of BIER-TE FRR 171 A Bit-Forwarding Router (BFR) in a BIER-TE domain has a BIER-TE Bit 172 Index Forwarding Tables (BIFT) [I-D.ietf-bier-te-arch]. A BIER-TE 173 BIFT on a BFR comprises a forwarding entry for a BitPosition (BP) 174 assigned to each of the adjacencies of the BFR. If the BP represents 175 a forward connected adjacency, the forwarding entry for the BP 176 forwards the multicast packet with the BP to the directly connected 177 BFR neighbor of the adjacency. If the BP represents a BFER (i.e., 178 egress node) or say a local decap adjacency, the forwarding entry for 179 the BP decapsulates the multicast packet with the BP and passes a 180 copy of the payload of the packet to the packet's NextProto within 181 the BFR. 183 To support BIER-TE FRR (i.e., fast re-route (FRR) protection against 184 the failure of a transit node or link on an explicit P2MP multicast 185 path in a BIER-TE domain), the BIER-TE BIFT on a BFR is extended. 186 For each forwarding entry of the BIER-TE BIFT on the BFR, if it is 187 for the BP representing a forward connected adjacency, the forwarding 188 entry is extended to include a new forwarding entry, which is called 189 FRR forwarding entry or FRR entry for short. 191 Suppose that the BFR-NBR in the forwarding entry for the BP is N. 192 The FRR entry forwards the multicast packet with the BP to the N's 193 next hops that are on the P2MP path encoded in the multicast packet. 195 Once the BFR as a PLR detects the failure of its BFR-NBR N that is a 196 transit node, for a multicast packet with the BP attached to N, the 197 PLR uses the FRR forwarding entry in the extended BIER-TE BIFT to 198 send the packet to the N's next hop nodes that are on the P2MP path 199 encoded in the multicast packet. These next hop nodes forward the 200 packet along the P2MP path towards the egress nodes of the path. 202 Before sending the packet to the N's next hops, for any local decap 203 BP for a destination/BFER in the header, the PLR removes/clears it if 204 it is on the backup path and it is not reachable through the forward 205 connected adjacency BPs in the header (i.e., it is not on any branch 206 from the PLR). 208 3. BIER-TE Extensions for BIER-TE FRR 210 This section describes extensions to a BIER-TE BIFT of a BFR for 211 supporting BIER-TE FRR and enhancements on a forwarding procedure to 212 use the extended BIER-TE BIFT for BIER-TE FRR. 214 3.1. Extensions to BIER-TE BIFT 216 Every BFR has an extended BIER-TE BIFT to support BIER-TE FRR 217 protection against the failure of its neighbor transit node. The 218 forwarding entry with transit node (say N) as its BFR-NBR in the BIFT 219 comprises a FRR forwarding entry (or FRR entry for short). The FRR 220 entry contains a flag FPA (which is short for FRR Protection is 221 Active) and a backup path from the BFR to each of N's next hop nodes. 223 In normal operations, the flag FPA in the FRR entry for neighbor 224 transit node N is set to 0 (zero). The flag FPA is set to 1 (one) 225 when transit node N fails. FPA == 1 means that the FRR protection 226 for transit node N is active and the FRR entry will be used to 227 forward the packet with the BP for the adjacency from the BFR to node 228 N towards N's next hop nodes on the P2MP path encoded in the packet's 229 BitString along the backup paths. 231 The backup path from the BFR to a N's next hop node X is a path that 232 satisfies a set of constraints and does not traverse transit node N 233 or any link connected to N. In one implementation, the backup path 234 is represented by the BitPositions for the adjacencies along the 235 backup path. 237 3.2. Updated Forwarding Procedure 239 The forwarding procedure defined in [I-D.ietf-bier-te-arch] is 240 updated/enhanced for using an extended BIER-TE BIFT to support BIER- 241 TE FRR. 243 For a multicast packet with the BP in the BitString indicating a BFR- 244 NBR as a transit node of the P2MP path encoded in the packet, the 245 updated forwarding procedure on a BFR sends the packet towards the 246 transit node's next hop nodes on the P2MP path if the transit node 247 fails. 249 It checks whether FPA equals to 1 (one) in the forwarding entry with 250 the BFR-NBR that is a transit node of the P2MP path. If FPA is 1 251 (i.e., the transit node fails and the FRR protection for the transit 252 node is active), the procedure clears the BP for the adjacency to the 253 transit node in the packet's BitString first. Secondly, for any 254 local decap BP for a destination/BFER in the BitString, it removes/ 255 clears the BP if the BP is on the backup path and is not reachable by 256 the forward connected adjacency BPs in the BitString (i.e., is not on 257 any branch from the BFR as PLR). And then, for each next hop node of 258 the failed transit node that is on the P2MP path encoded in the 259 packet's BitString, it copies and sends the packet to the next hop 260 node along the backup path from the BFR to the next hop node. 262 For each next hop node of transit node BFR-NBR (which is named as N 263 for simplicity), when N's next hop node is on the P2MP path, the 264 forwarding procedure clears the BP for the adjacency from N to the 265 N's next hop node in the packet's BitString and adds the BPs for the 266 backup path from the BFR to the N's next hop node. This lets the 267 packet be copied and sent to the N's next hop nodes along the backup 268 paths when transit node N fails and then towards the destinations 269 along the P2MP path. 271 The updated procedure is described in Figure 1. It can also be used 272 by the BFR to forward multicast packets in normal operations. 274 Packet = the packet received by BFR; 275 FOR each BP k (from the rightmost in Packet's BitString) { 276 IF (BP k is local decap adjacency) { 277 copies Packet, sends the copy to the multicast 278 flow overlay and clears bit k in Packet's BitString 279 } ELSE IF (BP k is forward connect adjacency of the BFR) { 280 finds the forwarding entry in the BIER-TE BIFT for the domain 281 using BP k; 282 Clears BP k in Packet's BitString; 283 IF (FPA == 1) {//FRR for BFR-NBR/transit N is Active 284 FOR each BP j for a BFER in Packet's BitString { 285 IF (BP j is on a backup path and 286 is not reachable by BPs in BitString) { 287 Clears BP j in Packet's BitString 288 } 289 } 290 FOR each N's next hop on P2MP path in Packet's BitString { 291 Clears the BP for the adjacency from N to the next hop; 292 Adds the BPs for the backup path to N's next hop 293 into Packet's BitString 294 } 295 } //Adjacency to N removed, backup path to N's next hop added 296 ELSE { 297 Copies Packet, updates the copy's BitString by 298 clearing all the BPs for the adjacencies of the BFR, 299 and sends the updated copy to BFR-NBR 300 } 301 } 302 } 304 Figure 1: Updated Forwarding Procedure 306 4. Example Application of BIER-TE FRR 308 This section illustrates an example application of BIER-TE FRR on a 309 BFR in a BIER-TE topology in Figure 2. 311 4.1. Example BIER-TE Topology 313 An example BIER-TE topology for a BIER-TE domain is shown in 314 Figure 2. It has 9 nodes/BFRs A, B, C, D, E, F, G, H and I. Nodes/ 315 BFRs D, F, E, H and A are BFERs and have local decap adjacency 316 BitPositions 1, 2, 3, 4, and 5 respectively. For simplicity, these 317 BPs are represented by (SI:BitString), where SI = 0 and BitString is 318 of 8 bits. BPs 1, 2, 3, 4, and 5 are represented by 1 (0:00000001), 319 2 (0:00000010), 3 (0:00000100), 4 (0:00001000) and 5 (0:00010000) 320 respectively. 322 26' 19' 20' 4 323 /--------------------( G )---------------( H ) 324 / / 18'\ 16'/|28' 325 / 6'/ \17' / | 326 / ________/ ( I )____________/ | 327 25'/ / 14'/ 15' | 328 / 5'/ / | 329 / 8' 7' / 3' 4' /13' 12' |27' 330 ( A )--------( B )------------( C )-----------------( D ) 1 331 5 \1' \9' 11' /24' 332 \ \ / 333 \2' 21' 22' \10' / 334 ( E )------------( F )____________/ 335 3 2 23' 337 Figure 2: Example BIER-TE Topology 339 The BitPositions for the forward connected adjacencies are 340 represented by i', where i is from 1 to 28. In one option, they are 341 encoded as (n+i), where n is a power of 2 such as 32768. For 342 simplicity, these BitPositions are represented by (SI:BitString), 343 where SI = (6 + (i-1)/8) and BitString is of 8 bits. BitPositions i' 344 (i from 1 to 28) are represented by 1'(6:00000001), 2'(6:00000010), 345 3'(6:00000100), 4'(6:00001000), 5'(6:00010000), 6'(6:00100000), 346 7'(6:01000000), 8'(6:10000000), 9'(7:00000001), 10'(7:00000010), . . 347 . , 24'(8:10000000) 25'(9:00000001), 26'(9:00000010), ..., 348 28'(9:00001000). 350 For a link between two nodes X and Y, there are two BitPositions for 351 two forward connected adjacencies. These two forward connected 352 adjacency BitPositions are assigned on nodes X and Y respectively. 353 The BitPosition assigned on X is the forward connected adjacency of 354 Y. The BitPosition assigned on Y is the forward connected adjacency 355 of X. 357 For example, for the link between nodes B and C in the figure, two 358 forward connected adjacency BitPositions 3' and 4' are assigned to 359 two ends of the link. BitPosition 3' is assigned on node B to B's 360 end of the link. It is the forward connected adjacency of node C. 361 BitPosition 4' is assigned on node C to C's end of the link. It is 362 the forward connected adjacency of node B. 364 4.2. BIER-TE BIFT on a BFR 366 Every BFR in a BIER-TE domain/topology has a BIER-TE BIFT. For the 367 BIER-TE topology in Figure 2, each of 9 nodes/BFRs A, B, C, D, E, F, 368 G, H and I has its BIER-TE BIFT for the topology. 370 The BIER-TE BIFT on BFR B (i.e. node B) is shown in Figure 3. 372 The 1st forwarding entry in the BIFT is for BitPosition 2', which is 373 the forward connected adjacency from B to E. For a multicast packet 374 with BitPosition 2', which indicates that the P2MP path in the packet 375 traverses the adjacency from B to E, the forwarding entry forwards 376 the packet to E along the link from B to E. 378 The 2nd forwarding entry in the BIFT is for BitPosition 4', which is 379 the forward connected adjacency from B to C. For a multicast packet 380 with BitPosition 4', which indicates that the P2MP path in the packet 381 traverses the adjacency from B to C, the forwarding entry forwards 382 the packet to C along the link from B to C. 384 The 3rd forwarding entry in the BIFT is for BitPosition 6', which is 385 the forward connected adjacency from B to G. For a multicast packet 386 with BitPosition 6', which indicates that the P2MP path in the packet 387 traverses the adjacency from B to G, the forwarding entry forwards 388 the packet to G along the link from B to G. 390 The 4-th forwarding entry in the BIFT is for BitPosition 8', which is 391 the forward connected adjacency from B to A. For a multicast packet 392 with BitPosition 8', which indicates that the P2MP path in the packet 393 traverses the adjacency from B to A, the forwarding entry forwards 394 the packet to A along the link from B to A. 396 +----------------+--------------+------------+ 397 | Adjacency BP | Action | BFR-NBR | 398 | (SI:BitString) | | (Next Hop) | 399 +================+==============+============+ 400 | 2'(6:00000010) | fw-connected | E | 401 +----------------+--------------+------------+ 402 | 4'(6:00001000) | fw-connected | C | 403 +----------------+--------------+------------+ 404 | 6'(6:00100000) | fw-connected | G | 405 +----------------+--------------+------------+ 406 | 8'(6:10000000) | fw-connected | A | 407 +----------------+--------------+------------+ 409 Figure 3: BIER-TE BIFT on BFR B 411 The BIER-TE BIFT on BFR E (i.e. node E) is shown in Figure 4. 413 The 1st forwarding entry in the BIFT forwards a multicast packet with 414 BitPosition 1' to B. It is for BitPosition 1', which is the forward 415 connected adjacency from E to B. For a multicast packet with 416 BitPosition 1', which indicates that the P2MP path in the packet 417 traverses the adjacency from E to B, the forwarding entry forwards 418 the packet to B along the link from E to B. 420 The 2nd forwarding entry in the BIFT forwards a multicast packet with 421 BitPosition 22' to F. It is for BitPosition 22', which is the 422 forward connected adjacency from E to F. For a multicast packet with 423 BitPosition 22', which indicates that the P2MP path in the packet 424 traverses the adjacency from E to F, the forwarding entry forwards 425 the packet to F along the link from E to F. 427 The 3rd forwarding entry in the BIFT locally decapsulates a multicast 428 packet with BitPosition 3 and passes a copy of the payload of the 429 packet to the packet's NextProto. It is for BitPosition 3, which is 430 the local decap adjacency for BFER (i.e., egress) E. For a multicast 431 packet with BitPosition 3, which indicates that the P2MP path in the 432 packet has node E as one of its destinations (i.e., egress nodes), 433 the forwarding entry decapsulates the packet and passes a copy of the 434 payload of the packet to the packet's NextProto within node E. 436 +----------------+--------------+------------+ 437 | Adjacency BP | Action | BFR-NBR | 438 | (SI:BitString) | | (Next Hop) | 439 +================+==============+============+ 440 | 1'(6:00000001)| fw-connected | B | 441 +----------------+--------------+------------+ 442 | 22'(8:00001000)| fw-connected | F | 443 +----------------+--------------+------------+ 444 | 3 (0:00000100)| local-decap | | 445 +----------------+--------------+------------+ 447 Figure 4: BIER-TE BIFT on BFR D 449 4.3. Extended BIER-TE BIFT on a BFR 451 Every BFR has an extended BIER-TE BIFT to support BIER-TE FRR 452 protection against the failure of its neighbor transit node. 454 For example, the extended BIER-TE BIFT on BFR B is illustrated in 455 Figure 5. Each forwarding entry with transit node (such as E, C and 456 G) as its BFR-NBR in the BIFT comprises a FRR entry. Each of these 457 FRR entries contains a flag FPA and a number of backup paths. For a 458 forwarding entry with transit node X, its FRR entry has a backup path 459 to each of node X's next hop nodes except for BFR B itself. FPA is 460 set to zero in normal operations. FPA in the FRR entry for neighbor 461 transit node X is set to one when node X fails. 463 On BFR B, the 1st forwarding entry in the BIFT has BFR-NBR E as 464 transit node. Nodes F and B are the next hop nodes of node E in 465 Figure 2. The backup path from B to F without E or links attached to 466 E goes through the link from B to C and then the link from C to F. 467 This backup path from B to F is represented by B-->F: {4', 10'} in 468 the FRR entry of the forwarding entry. 470 FPA in the FRR entry is set to 0 (zero) in normal operations. When 471 transit node E fails, the FPA is set to 1 (one) and the FRR entry is 472 used to forward a multicast packet with BitPosition 2' for adjacency 473 from B to E towards E's next hop node F along the backup path from B 474 to F if the P2MP path in the packet traverses node F. 476 +--------------+------------+----------+------------------------+ 477 | Adjacency BP | Action | BFR-NBR | FRR Entry | 478 |(SI:BitString)| |(Next Hop)|---+--------------------+ 479 | | | |FPA| Backup Paths | 480 +==============+============+==========+===+====================+ 481 |2'(6:00000010)|fw-connected| E | 0 |B-->F: {4',10'} | 482 +--------------+------------+----------+---+--------------------+ 483 |4'(6:00000010)|fw-connected| C | 0 |B-->F: {2',22'} | 484 | | | | |B-->D: {6',20',27'} | 485 | | | | |B-->I: {6',17'} | 486 +--------------+------------+----------+---+--------------------+ 487 |6'(6:00100000)|fw-connected| G | 0 |B-->I: {4',14'} | 488 | | | | |B-->H: {4',14',16'} | 489 | | | | |B-->A: {8'} | 490 +--------------+------------+----------+---+--------------------+ 491 |8'(6:10000000)|fw-connected| A | 0 |B-->G: {6'} | 492 +--------------+------------+----------+---+--------------------+ 494 Figure 5: Extended BIER-TE BIFT on BFR B 496 On BFR B, the 2nd forwarding entry in the BIFT has BFR-NBR C as 497 transit node. Nodes F, D, I and B are the next hop nodes of node C 498 in Figure 2. The backup path from B to F without C or links attached 499 to C goes through the link from B to E and then the link from E to F. 500 This backup path from B to F is represented by B-->F: {2', 22'} in 501 the FRR entry of the forwarding entry. 503 The backup path from B to D without C or links attached to C goes 504 through the link from B to G, the link from G to H and then the link 505 from H to D. This backup path from B to D is represented by B-->D: 506 {6', 20', 27'} in the FRR entry of the forwarding entry. 508 The backup path from B to I without C or links attached to C goes 509 through the link from B to G and then the link from G to I. This 510 backup path from B to I is represented by B-->I: {6', 17'} in the FRR 511 entry of the forwarding entry. 513 FPA in the FRR entry is set to 0 (zero) in normal operations. When 514 transit node C fails, the FPA is set to 1 (one) and the FRR entry is 515 used to forward a multicast packet with BitPosition 4' for adjacency 516 from B to C towards C's next hop nodes F, D or I along the backup 517 paths from B to F, D or I respectively if the P2MP path in the packet 518 traverses nodes F, D or I. 520 On BFR B, the 3rd forwarding entry in the BIFT has BFR-NBR G as 521 transit node. Nodes I, H, A and B are the next hop nodes of node G 522 in Figure 2. The backup path from B to I without G or links attached 523 to G goes through the link from B to C and then the link from C to I. 524 This backup path from B to I is represented by B-->I: {4', 14'} in 525 the FRR entry of the forwarding entry. 527 The backup path from B to H without G or links attached to G goes 528 through the link from B to C, the link from C to I and then the link 529 from I to H. This backup path from B to H is represented by B-->H: 530 {4', 14', 16'} in the FRR entry of the forwarding entry. 532 The backup path from B to A without G or links attached to G goes 533 through the link from B to A. This backup path from B to A is 534 represented by B-->A: {8'} in the FRR entry of the forwarding entry. 536 FPA in the FRR entry is set to 0 (zero) in normal operations. When 537 transit node G fails, the FPA is set to 1 (one) and the FRR entry is 538 used to forward a multicast packet with BitPosition 6' for adjacency 539 from B to G towards G's next hop nodes I, H or A along the backup 540 paths from B to I, H or A respectively if the P2MP path in the packet 541 traverses nodes I, H or A. 543 On BFR B, the 4-th forwarding entry in the BIFT has BFR-NBR A as 544 transit node. Nodes G and B are the next hop nodes of node A. The 545 backup path from B to G without A or links attached to A goes through 546 the link from B to G. This backup path from B to G is represented by 547 B-->G: {6'} in the FRR entry of the forwarding entry. 549 FPA in the FRR entry is set to 0 (zero) in normal operations. When 550 node A fails, the FPA is set to 1 (one) and the FRR entry is used to 551 forward a multicast packet with BitPosition 8' for adjacency from B 552 to A towards A's next hop node G along the backup path from B to G if 553 the P2MP path in the packet traverses node A as a transit node. 555 4.4. Forwarding using Extended BIER-TE BIFT 557 Suppose that there is an explicit multicast P2MP path from ingress A 558 to egresses H and D, traversing from A to G to H and from A to B to C 559 to D. This path is represented by BPs as {26', 20', 7', 4', 12', 4, 560 1}. The forwarding behaviors in normal operations and in case of BFR 561 C failure are described below. 563 4.4.1. Forwarding in Normal Operations 565 For a multicast packet with the path on BFR A, A sends the packet to 566 G and B according to the forwarding entries for 26' and 7' in A's 567 extended BIER-TE BIFT respectively. The packet received by G and B 568 contains path {20', 4', 12', 4, 1}. 570 After receving the packet from A, G forwards the packet to H 571 according to forwarding entry for 20' in its extended BIER-TE BIFT. 572 The packet received by H contains path {4', 12', 4, 1}. After 573 receving the packet from A, B forwards the packet to C according to 574 forwarding entry for 4' in its extended BIER-TE BIFT. The packet 575 received by C contains path {20', 12', 4, 1}. 577 After receving the packet from G, H decapsulates the packet and 578 passes a copy of the payload of the packet to the packet's NextProto 579 according to forwarding entry for 4 in its extended BIER-TE BIFT. 580 After receving the packet from B, C forwards the packet to D 581 according to forwarding entry for 12' in its extended BIER-TE BIFT. 582 The packet received by D contains path {20', 4, 1}. 584 After receving the packet from C, D decapsulates the packet and 585 passes a copy of the payload of the packet to the packet's NextProto 586 according to forwarding entry for 1 in its extended BIER-TE BIFT. 588 4.4.2. Forwarding in Failure 590 Once BFR B detects the failure of node C, it sets FPA of the FRR 591 entry in the 2nd forwarding entry with BFR-NBR C to one. After 592 receiving the packet from BFR A, which contains path {20', 4', 12', 593 4, 1}, BFR B clears BP 4'; BFR B clears the BP 4 for BFER H since H 594 is on the backup path from B to G to H to D, but not on any branch of 595 the path from B. 597 For C's next hop node D on the P2MP path, BFR B clears adjacency BP 598 12' from C to D and adds the BPs for backup path {6', 20', 27'} from 599 B to G to H to D. The packet has path {6', 20', 27', 1}. BFR B 600 sends the packet to G according to forwarding entry for 6' in its 601 extended BIER-TE BIFT. The packet received by G contains path {20', 602 27', 1}. 604 After receving the packet from B, G forwards the packet to H 605 according to forwarding entry for 20' in its extended BIER-TE BIFT. 606 The packet received by H contains path {27', 1}. 608 After receving the packet from G, H forwards the packet to D 609 according to forwarding entry for 27' in its extended BIER-TE BIFT. 610 The packet received by D contains path {1}. 612 After receving the packet from H, D decapsulates the packet and 613 passes a copy of the payload of the packet to the packet's NextProto 614 according to forwarding entry for 1 in its extended BIER-TE BIFT. 616 5. Security Considerations 618 TBD. 620 6. IANA Considerations 622 No requirements for IANA. 624 7. Acknowledgements 626 The authors would like to thank Daniel Merling for his comments to 627 this work. 629 8. References 631 8.1. Normative References 633 [I-D.ietf-bier-te-arch] 634 Eckert, T., Menth, M., and G. Cauchie, "Tree Engineering 635 for Bit Index Explicit Replication (BIER-TE)", Work in 636 Progress, Internet-Draft, draft-ietf-bier-te-arch-12, 28 637 January 2022, . 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, 642 DOI 10.17487/RFC2119, March 1997, 643 . 645 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 646 IANA Considerations Section in RFCs", RFC 5226, 647 DOI 10.17487/RFC5226, May 2008, 648 . 650 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 651 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 652 July 2008, . 654 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 655 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 656 DOI 10.17487/RFC5286, September 2008, 657 . 659 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 660 RFC 5714, DOI 10.17487/RFC5714, January 2010, 661 . 663 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 664 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 665 . 667 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 668 Scope Link State PDUs (LSPs)", RFC 7356, 669 DOI 10.17487/RFC7356, September 2014, 670 . 672 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 673 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 674 RFC 7490, DOI 10.17487/RFC7490, April 2015, 675 . 677 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 678 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 679 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 680 2015, . 682 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 683 S. Shaffer, "Extensions to OSPF for Advertising Optional 684 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 685 February 2016, . 687 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 688 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 689 May 2017, . 691 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 692 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 693 Explicit Replication (BIER)", RFC 8279, 694 DOI 10.17487/RFC8279, November 2017, 695 . 697 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 698 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 699 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 700 2019, . 702 8.2. Informative References 704 [I-D.eckert-bier-te-frr] 705 Eckert, T., Cauchie, G., Braun, W., and M. Menth, 706 "Protection Methods for BIER-TE", Work in Progress, 707 Internet-Draft, draft-eckert-bier-te-frr-03, 5 March 2018, 708 . 711 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 712 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 713 Decraene, B., and D. Voyer, "Topology Independent Fast 714 Reroute using Segment Routing", Work in Progress, 715 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 716 08, 21 January 2022, . 719 [I-D.ietf-spring-segment-protection-sr-te-paths] 720 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 721 "Segment Protection for SR-TE Paths", Work in Progress, 722 Internet-Draft, draft-ietf-spring-segment-protection-sr- 723 te-paths-02, 21 January 2022, 724 . 727 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 728 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 729 for Bit Index Explicit Replication (BIER) in MPLS and Non- 730 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 731 2018, . 733 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 734 Zhang, "Bit Index Explicit Replication (BIER) Support via 735 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 736 . 738 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 739 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 740 Extensions for Bit Index Explicit Replication (BIER)", 741 RFC 8444, DOI 10.17487/RFC8444, November 2018, 742 . 744 Authors' Addresses 746 Huaimo Chen 747 Futurewei 748 Boston, MA, 749 United States of America 750 Email: Huaimo.chen@futurewei.com 752 Mike McBride 753 Futurewei 754 Email: michael.mcbride@futurewei.com 756 Yisong Liu 757 China Mobile 758 Email: liuyisong@chinamobile.com 760 Aijun Wang 761 China Telecom 762 Beiqijia Town, Changping District 763 Beijing 764 102209 765 China 766 Email: wangaj3@chinatelecom.cn 767 Gyan S. Mishra 768 Verizon Inc. 769 13101 Columbia Pike 770 Silver Spring, MD 20904 771 United States of America 772 Phone: 301 502-1347 773 Email: gyan.s.mishra@verizon.com 775 Yanhe Fan 776 Casa Systems 777 United States of America 778 Email: yfan@casa-systems.com 780 Lei Liu 781 Fujitsu 782 United States of America 783 Email: liulei.kddi@gmail.com 785 Xufeng Liu 786 Volta Networks 787 McLean, VA 788 United States of America 789 Email: xufeng.liu.ietf@gmail.com