idnits 2.17.1 draft-chen-bier-te-egress-protect-01.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 date (25 August 2021) is 972 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 127 -- Looks like a reference, but probably isn't: '65535' on line 127 == Unused Reference: 'RFC5226' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC5286' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'RFC7684' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC7770' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC8556' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'I-D.eckert-bier-te-frr' 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 704, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-protection-sr-te-paths' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'RFC8296' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'RFC8401' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'RFC8444' is defined on line 736, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-10 ** 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-07 == Outdated reference: A later version (-06) exists of draft-ietf-spring-segment-protection-sr-te-paths-01 Summary: 2 errors (**), 0 flaws (~~), 19 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 February 2022 A. Wang 6 China Telecom 7 G. Mishra 8 Verizon Inc. 9 Y. Liu 10 China Mobile 11 Y. Fan 12 Casa Systems 13 L. Liu 14 Fujitsu 15 X. Liu 16 Volta Networks 17 25 August 2021 19 BIER-TE Egress Protection 20 draft-chen-bier-te-egress-protect-01 22 Abstract 24 This document describes a mechanism for fast protection against the 25 failure of an egress node of an explicit point to multipoint (P2MP) 26 multicast path/tree in a "Bit Index Explicit Replication" (BIER) 27 Traffic Engineering (TE) domain. It does not have any per-flow state 28 in the core of the domain. For a multicast packet to the egress 29 node, when the egress node fails, its upstream hop as a PLR sends the 30 packet to the egress' backup node once the PLR detects the failure. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in [RFC2119] [RFC8174] 37 when, and only when, they appear in all capitals, as shown here. 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 26 February 2022. 56 Copyright Notice 58 Copyright (c) 2021 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 (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Overview of BIER-TE Egress Protection . . . . . . . . . . . . 4 75 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 5 77 3.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 6 78 4. BIER-TE Extensions . . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Extensions to BIER-TE BIFT for Egress Protection . . . . 7 80 4.2. Updated Forwarding Procedure . . . . . . . . . . . . . . 7 81 5. Example Application of BIER-TE Egress Protection . . . . . . 9 82 5.1. Example BIER-TE Topology . . . . . . . . . . . . . . . . 9 83 5.2. BIER-TE BIFT on a BFR . . . . . . . . . . . . . . . . . . 11 84 5.3. Extended BIER-TE BIFT on a BFR . . . . . . . . . . . . . 12 85 5.4. Forwarding using Extended BIER-TE BIFT . . . . . . . . . 14 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 91 9.2. Informative References . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 [I-D.ietf-bier-te-arch] introduces Bit Index Explicit Replication 97 (BIER) Traffic/Tree Engineering (BIER-TE). It is an architecture for 98 per-packet stateless explicit point to multipoint (P2MP) multicast 99 path/tree and based on the BIER architecture defined in [RFC8279]. A 100 multicast packet is replicated and forwarded along the P2MP path/tree 101 encoded in the packet. It does not require intermediate nodes to 102 maintain any per-path/tree state. 104 This document describes a mechanism for fast protection against the 105 failure of an egress node of an explicit P2MP multicast path/tree in 106 a BIER-TE domain. It is called BIER-TE Egress Protection. For a 107 multicast packet to the egress node, when the egress node fails, its 108 upstream hop as a PLR sends the packet to the egress' backup node 109 (called backup egress node) once the PLR detects the failure. 111 This BIER-TE Egress Protection does not require intermediate nodes to 112 maintain any per-path state for fast protection against the failure 113 of an egress node of the path. 115 1.1. Terminology 117 BIER: Bit Index Explicit Replication. 119 BIER-TE: BIER Traffic/Tree Engineering. 121 BFR: Bit-Forwarding Router. 123 BFIR: Bit-Forwarding Ingress Router. 125 BFER: Bit-Forwarding Egress Router. 127 BFR-id: BFR Identifier. It is a number in the range [1,65535]. 129 BFR-NBR: BFR Neighbor. 131 F-BM: Forwarding Bit Mask. 133 BFR-prefix: An IP address (either IPv4 or IPv6) of a BFR. 135 BIRT: Bit Index Routing Table. It is a table that maps from the 136 BFR-id (in a particular sub-domain) of a BFER to the BFR-prefix 137 of that BFER, and to the BFR-NBR on the path to that BFER. 139 BIFT: Bit Index Forwarding Table. 141 FRR: Fast Re-Route. 143 PLR: Point of Local Repair. 145 IGP: Interior Gateway Protocol. 147 LSDB: Link State DataBase. 149 SPF: Shortest Path First. 151 SPT: Shortest Path Tree. 153 OSPF: Open Shortest Path First. 155 IS-IS: Intermediate System to Intermediate System. 157 LSA: Link State Advertisement in OSPF. 159 LSP: Link State Protocol Data Unit (PDU) in IS-IS. 161 2. Overview of BIER-TE Egress Protection 163 For fast protecting an egress node of a BIER-TE domain, a backup 164 egress node is configured on the egress node. After the 165 configuration, the egress node distributes the information about the 166 backup egress to its direct neighbors. 168 For clearly distinguishing between an egress node and a backup egress 169 node, an egress node is called a primary egress node sometimes. 171 For a multicast packet to a primary egress node of the domain, when 172 the primary egress node fails, its upstream hop as a point of local 173 repair (PLR) sends the packet to the backup egress node configured to 174 protect the primary egress node once the PLR detects the failure. 175 The upstream hop of the primary egress node is its direct neighbor. 177 A Bit-Forwarding Router (BFR) in a BIER-TE sub-domain has a BIER-TE 178 Bit Index Forwarding Tables (BIFT) [I-D.ietf-bier-te-arch]. A BIER- 179 TE BIFT on a BFR comprises a forwarding entry for a BitPosition (BP) 180 assigned to each of the adjacencies of the BFR. If the BP represents 181 a forward connected adjacency, the forwarding entry for the BP 182 forwards the multicast packet with the BP to the directly connected 183 BFR neighbor of the adjacency. If the BP represents a BFER (i.e., 184 egress node) or say a local decap adjacency, the forwarding entry for 185 the BP decapsulates the multicast packet with the BP and passes a 186 copy of the payload of the packet to the packet's NextProto within 187 the BFR. 189 The BIER-TE BIFT on a BFR is extended to support protection against 190 the failure of an egress node. For each forwarding entry of the 191 BIER-TE BIFT on the BFR, if it is for the BP representing a forward 192 connected adjacency and its BFR-NBR is a BFER (i.e., primary egress 193 node), the forwarding entry is extended to include a new forwarding 194 entry, which is called backup forwarding entry or backup entry for 195 short. This backup entry forwards the multicast packet with the BP 196 to the backup egress node, which is configured to protect the primary 197 egress node. 199 Once the BFR as a PLR detects the failure of its BFR-NBR X that is a 200 primary egress node of the domain, for a multicast packet with the BP 201 for the primary egress node, the PLR uses the backup forwarding entry 202 in the extended BIER-TE BIFT to send the packet to the backup egress 203 node configured to protect the primary egress node. 205 3. Protocol Extensions 207 This section defines extensions to OSPF and IS-IS for advertising the 208 backup information (including the information about the backup egress 209 node for protecting a primary egress node). 211 3.1. Extensions to OSPF 213 When a node P (as a primary egress node) has a backup egress node 214 configured to protect against its failure, node P advertises the 215 information about the backup egress node to its neighbors in its 216 router information opaque LSA of LS type 9 or 10. The information is 217 included in a backup egress BP TLV. The format of the TLV is shown 218 in Figure 1. 220 0 1 2 3 221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type (TBD1) | Length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Reserved | BP of backup egress node | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Sub-TLVs (Optional) | 228 : : 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 1: OSPF Backup Egress BP TLV 233 Type: 2 octets, its value (TBD1) is to be assigned by IANA. 235 Length: 2 octets, its value is 4 plus the length of the Sub-TLVs 236 included. If no Sub-TLV is included, its value is 4. 238 Reserved: 2 octets, it MUST be set to zero when sending and be 239 ignored while receiving. 241 BP of backup egress node: 2 octets, its value is the local decap 242 BitPosition of the backup egress node, which is configured to protect 243 against the failure of the primary egress node. 245 Sub-TLVs (Optional): No Sub-TLV is defined now. 247 After each of the neighbors receives the backup egress BP TLV from 248 node P, it knows that node P as a primary egress node will be 249 protected by the backup egress node in the TLV. Once detecting the 250 failure of node P, it sends the packet with the BP for node P towards 251 the backup egress node. 253 3.2. Extensions to IS-IS 255 For supporting fast protection against the failure of a primary 256 egress node in a BIER-TE domain, a new IS-IS TLV, called IS-IS backup 257 egress BP TLV, is defined. It contains the local decap BitPosition 258 of the backup egress node configured to protect the primary egress 259 node. 261 When a node P (as a primary egress node) has a backup egress node 262 configured to protect against its failure, node P advertises the 263 information about the backup egress node to its neighbors using a IS- 264 IS backup egress BP TLV. 266 This TLV may be advertised in IS-IS Hello (IIH) PDUs, LSPs, or in 267 Circuit Scoped Link State PDUs (CS-LSP) [RFC7356]. The format of the 268 TLV is shown in Figure 2. 270 0 1 2 3 271 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type (TBD2) | Length | BP of backup egress node | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 ~ Sub-TLVs (Optional) ~ 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 2: IS-IS Backup Egress BP TLV 280 Type: 1 octet, its value (TBD2) is to be assigned by IANA. 282 Length: 1 octet, its value is 2 plus the length of the Sub-TLVs 283 included. If no Sub-TLV is included, its value is 2. 285 BP of backup egress node: 2 octets, its value is the local decap 286 BitPosition of the backup egress node configured to protect against 287 the failure of the primary egress node. 289 Sub-TLVs (Optional): No Sub-TLV is defined now. 291 4. BIER-TE Extensions 293 This section describes extensions to a BIER-TE BIFT of a BFR for 294 supporting fast protection against the failure of a primary egress 295 node and enhancements on a forwarding procedure to use the extended 296 BIER-TE BIFT for egress protection. 298 4.1. Extensions to BIER-TE BIFT for Egress Protection 300 If a BFR is a neighbor of an egress node in a BIER-TE sub-domain, it 301 has an extended BIER-TE BIFT to support protection against the 302 failure of its neighbor egress node. The forwarding entry with the 303 egress node (say X) as its BFR-NBR in the BIFT comprises a backup 304 entry. The backup entry contains a flag EPA (which is short for 305 Egress Protection is Active) and a backup path to a backup egress 306 node (say Y) which is configured to protect the egress node. 308 In normal operations, the flag EPA in the backup entry for neighbor 309 egress node X is set to 0 (zero). The flag EPA is set to 1 (one) 310 when egress node X fails. EPA == 1 means that the egress protection 311 for primary egress node X is active and the backup entry will be used 312 to forward the packet with BP for egress node X to backup egress node 313 Y along the backup path. 315 The backup path from the BFR to backup egress node Y is a path that 316 satisfies a set of constraints and does not traverse primary egress 317 node X or any link connected to X. In one implementation, the backup 318 path is represented by the BitPositions for the adjacencies along the 319 backup path. 321 4.2. Updated Forwarding Procedure 323 The forwarding procedure defined in [I-D.ietf-bier-te-arch] is 324 updated/enhanced for using an extended BIER-TE BIFT to consider the 325 egress protection (i.e., the new backup entry containing EPA and 326 backup path in the BIFT). 328 For a multicast packet with the BP in the BitString indicating a BFR- 329 NBR as a primary egress node, the updated forwarding procedure on a 330 BFR sends the packet towards the backup egress node of the primary 331 egress node if the primary egress node fails. 333 It checks whether EPA equals to 1 (one) in the forwarding entry with 334 the BFR-NBR that is the primary egress node. If EPA is 1 (i.e., the 335 primary egress node fails and the egress protection for primary 336 egress is active), then the procedure clears two BPs in the packet's 337 BitString and checks whether the backup egress node is not one of the 338 packet's destinations. 340 One BP is the BP for the primary egress node and the other is the BP 341 for the forward connected adjacency from the BFR to the primary 342 egress node. After these two BPs are cleared in the packet's 343 BitString, the packet will not be sent to the failed primary egress 344 node. 346 When the BP for the backup egress node in the packet's BitString is 347 0, the backup egress node is not one of the packet's destinations. 348 In this case, the procedure adds the backup path to the backup egress 349 node into the packet through adding the BPs for the backup path in 350 the packet's BitString. Thus the packet will be sent to the backup 351 egress node along the backup path. 353 The updated procedure is described in Figure 3. It can also be used 354 by the BFR to forward multicast packets in normal operations. 356 Packet = the packet received by BFR; 357 FOR each BP k (from the rightmost in Packet's BitString) { 358 IF BP k is local decap adjacency (or say BP of the BFR) { 359 copies Packet, sends copy's payload to the multicast 360 flow overlay and clears bit k in Packet's BitString 361 } ELSE IF BP k is forward connect adjacency of the BFR { 362 finds the forwarding entry in the BIER-TE BIFT for the domain 363 using BP k; 364 Clears BP k; 365 IF EPA == 1 {//Egress Protection for BFR-NBR/egress is Active 366 Clears BP for BFR-NBR in Packet's BitString; 367 IF BP for backup egress is 0 in Packet's BitString { 368 Adds BPs for backup path into Packet's BitString 369 } 370 } //egress removed, backup path to backup egress added 371 ELSE { 372 Copies Packet, updates the copy's BitString by 373 clearing all the BPs for the adjacencies of the BFR, 374 and sends the updated copy to BFR-NBR 375 } 376 } 377 } 379 Figure 3: Updated Forwarding Procedure 381 5. Example Application of BIER-TE Egress Protection 383 This section illustrates an example application of BIER-TE Egress 384 Protection on a BFR in a BIER-TE topology in Figure 4. 386 5.1. Example BIER-TE Topology 388 An example BIER topology for a BIER-TE sub-domain is shown in 389 Figure 4. It has 8 nodes/BFRs A, B, C, D, E, F, G and H. 391 6' 13' 14' 4 (0:01000) 392 /-----------( G )----------( H )Backup Egress for D 393 / 15'\_______ 10'/ \ 394 / _______)____/ \ 395 / / (_____ (CE) Receiver 396 / / \ / 397 8' 7' /5' 3' 4' /9' 17' 16'\ / 398 ( A )--------( B )------------( C )------------( D )Primary Egress 399 5(0:10000) \1' \11' 18' 1 (0:00001) 400 \ \ 401 \2' 19' 20' \12' 402 ( E )------------( F ) 403 3(0:00100) 2 (0:00010) 405 Figure 4: Example BIER-TE Topology 407 Nodes/BFRs D, F, E, H and A are BFERs and have local decap adjacency 408 BitPositions 1, 2, 3, 4, and 5 respectively. For simplicity, these 409 BPs are represented by (SI:BitString), where SI = 0 and BitString is 410 of 5 bits. BPs 1, 2, 3, 4, and 5 are represented by 1 (0:00001), 2 411 (0:00010), 3 (0:00100), 4 (0:01000) and 5 (0:10000) respectively. 413 The BitPositions for the forward connected adjacencies are 414 represented by i', where i is from 1 to 20. In one option, they are 415 encoded as (n+i), where n is a power of 2 such as 32768. For 416 simplicity, these BitPositions are represented by (SI:BitString), 417 where SI = (6 + (i-1)/5) and BitString is of 5 bits. BitPositions i' 418 (i from 1 to 20) are represented by 1'(6:00001), 2'(6:00010), 419 3'(6:00100), 4'(6:01000), 5'(6:10000), 6'(7:00001), 7'(7:00010), 420 8'(7:00100), . . . , 20'(9:10000). 422 For a link between two nodes X and Y, there are two BitPositions for 423 two forward connected adjacencies. These two forward connected 424 adjacency BitPositions are assigned on nodes X and Y respectively. 425 The BitPosition assigned on X is the forward connected adjacency of 426 Y. The BitPosition assigned on Y is the forward connected adjacency 427 of X. 429 For example, for the link between nodes B and C in the figure, two 430 forward connected adjacency BitPositions 3' and 4' are assigned to 431 two ends of the link. BitPosition 3' is assigned on node B to B's 432 end of the link. It is the forward connected adjacency of node C. 433 BitPosition 4' is assigned on node C to C's end of the link. It is 434 the forward connected adjacency of node B. 436 BFER H is configured to protect BFER D on BFR D. Suppose that this 437 information is distributed to BFR D's neighbors BFR C and BFR G by 438 IGP. BFR C and BFR G know that H is the backup egress to protect the 439 primary egress D. 441 Similarly, BFER D is configured to protect BFER H on BFR H; BFER F is 442 configured to protect BFER E on BFR E; and BFER E is configured to 443 protect BFER F on BFR F. These are not shown in the figure. 445 CE is a multicast traffic Receiver, which is dual homed to primary 446 egress node D and backup egress node H for protecting primary egress 447 D. During normal operations, there is no multicast traffic to CE 448 from backup egress node H and CE receives the multicast traffic only 449 from primary egress node D. There is no duplicated traffic to 450 receiver CE. This is different from MoFRR in [RFC7431], where 451 duplicated traffic is sent to both the primary egress D and backup 452 egress H, to which the receiver CE is dual homed. When primary 453 egress node D fails, the multicast traffic is sent to CE from backup 454 egress node H. 456 5.2. BIER-TE BIFT on a BFR 458 Every BFR in a BIER-TE sub-domain/topology has a BIER-TE BIFT. For 459 the BIER-TE topology in Figure 4, each of 8 nodes/BFRs A, B, C, D, E, 460 F, G and H has its BIER-TE BIFT for the topology. 462 The BIER-TE BIFT on BFR C (i.e. node C) is shown in Figure 5. 464 The 1st forwarding entry in the BIFT will forward a multicast packet 465 with BitPosition 18' to D. 467 The 2nd forwarding entry in the BIFT will forward a multicast packet 468 with BitPosition 12' to F. 470 The 3rd forwarding entry in the BIFT will forward a multicast packet 471 with BitPosition 10' to H. 473 The 4-th forwarding entry in the BIFT will forward a multicast packet 474 with BitPosition 3' to B. 476 +----------------+--------------+------------+ 477 | Adjacency BP | Action | BFR-NBR | 478 | (SI:BitString) | | (Next Hop) | 479 +================+==============+============+ 480 | 18' (9:00100) | fw-connected | D | 481 +----------------+--------------+------------+ 482 | 12' (8:00010) | fw-connected | F | 483 +----------------+--------------+------------+ 484 | 10' (7:10000) | fw-connected | H | 485 +----------------+--------------+------------+ 486 | 3' (6:00100) | fw-connected | B | 487 +----------------+--------------+------------+ 489 Figure 5: BIER-TE BIFT on BFR C 491 The BIER-TE BIFT on BFR D (i.e. node D) is shown in Figure 6. 493 The 1st forwarding entry in the BIFT will forward a multicast packet 494 with BitPosition 17' to C. 496 The 2nd forwarding entry in the BIFT will forward a multicast packet 497 with BitPosition 15' to G. 499 The 3rd forwarding entry in the BIFT will locally decapsulate a 500 multicast packet with BitPosition 1 and pass a copy of the payload of 501 the packet to the packet's NextProto. 503 +----------------+--------------+------------+ 504 | Adjacency BP | Action | BFR-NBR | 505 | (SI:BitString) | | (Next Hop) | 506 +================+==============+============+ 507 | 17' (9:00010) | fw-connected | C | 508 +----------------+--------------+------------+ 509 | 15' (8:10000) | fw-connected | G | 510 +----------------+--------------+------------+ 511 | 1 (0:00001) | local-decap | | 512 +----------------+--------------+------------+ 514 Figure 6: BIER-TE BIFT on BFR D 516 5.3. Extended BIER-TE BIFT on a BFR 518 Each of the BFRs that are neighbors of egress nodes (i.e., BFERs) in 519 a BIER-TE sub-domain/topology has an extended BIER-TE BIFT to support 520 protection against the failure of every its neighbor egress node. 522 For example, the extended BIER-TE BIFT on BFR C is illustrated in 523 Figure 7. It comprises a backup entry for each of its neighbor 524 egress nodes D, F and H. Each of these backup entries contains a 525 flag EPA and a backup path to a backup egress node. EPA is set to 526 zero in normal operations. EPA in the backup entry for neighbor 527 egress node X is set to one when egress node X fails. 529 The backup entry of the 1st forwarding entry in the BIFT contains EPA 530 = 0 and backup path {10', 4}. When egress node D fails, the EPA is 531 set to one and the backup entry is used to forward a multicast packet 532 with BitPosition 1 for D to D's backup egress node H with BitPosition 533 4 along the backup path. 535 The backup entry of the 2nd forwarding entry in the BIFT contains EPA 536 = 0 and backup path {3', 2', 3}. When egress node F fails, EPA is 537 set to one and the backup entry is used to forward a multicast packet 538 with BitPosition 2 for F to F's backup egress node E with BitPosition 539 3 along the backup path. 541 +----------------+--------------+----------+-----------------+ 542 | Adjacency BP | Action | BFR-NBR | Backup Entry | 543 | (SI:BitString) | |(Next Hop)|(EP, BackupPath) | 544 +================+==============+==========+=================+ 545 | 18' (9:00100) | fw-connected | D |EPA=0, {10', 4} | 546 +----------------+--------------+----------+-----------------+ 547 | 12' (8:00010) | fw-connected | F |EPA=0, {3', 2',3}| 548 +----------------+--------------+----------+-----------------+ 549 | 10' (7:10000) | fw-connected | H |EPA=0, {18', 1} | 550 +----------------+--------------+----------+-----------------+ 551 | 3' (6:00100) | fw-connected | B |EPA=0, { } | 552 +----------------+--------------+----------+-----------------+ 554 Figure 7: Extended BIER-TE BIFT on BFR C 556 The backup entry of the 3rd forwarding entry in the BIFT contains EPA 557 = 0 and backup path {18', 1}. When egress node H fails, EPA is set 558 to one and the backup entry is used to forward a multicast packet 559 with BitPosition 4 for H to H's backup egress node D with BitPosition 560 1 along the backup path. 562 5.4. Forwarding using Extended BIER-TE BIFT 564 Suppose that there is a multicast packet with explicit path {7', 4', 565 18', 12', 2, 1} on BFR A. The path is encoded in the BitPositions of 566 the packet. BFR A forwards the packet to BFR B according to the 567 forwarding entry for 7' in its extended BIER-TE BIFT. BFR B forwards 568 the packet to BFR C according to the forwarding entry for 4' in B's 569 extended BIER-TE BIFT. 571 In normal operations, after receiving the packet from BFR B, BFR C 572 copies and sends the packet to BFR D and BFR F using the forwarding 573 entries for 18' and 12' in the extended BIER-TE BIFT on BFR C 574 respectively. 576 Once BFR C detects the failure of egress node D, it sets EPA of the 577 backup entry in the 1st forwarding entry to one. After receiving the 578 packet from BFR B, BFR C copies and sends the packet to D's backup 579 egress node H using the backup entry in the forwarding entry for 18' 580 with BFR-NBR D in C's extended BIER-TE BIFT. It copies and sends the 581 packet to F using the forwarding entry for 12' in C's extended BIER- 582 TE BIFT. 584 The packet received by BFR C from BFR B contains (SI:BitString) = 585 (0:00011)(8:00010)(9:00100), which represents {18', 12', 2, 1}. 586 Since EPA in the backup entry in the forwarding entry with BFR-NBR == 587 D is 1, BFR C copies and sends the packet to D's backup egress node H 588 in the following steps. 590 At first, it obtains the backup entry from the forwarding entry for 591 18' with BFR-NBR D. EPA == 1 in the backup entry indicates that 592 egress protection for egress node D is active. BFR C clears 593 BitPositions 18' and 1 in Packet's BitString and adds the backup path 594 {10', 4} into Packet's BitString. The updated BitString in Packet is 595 (0:01010)(7:10000)(8:00010), which represents {12', 10', 4, 2}. This 596 lets BFR C copy and send Packet to F and H using the forwarding 597 entries for 12' and 10' in C's extended BIER-TE BIFT respectively. 599 When node H receives the packet with BitPosition 4 for H, it 600 decapsulates the packet and passes a copy of the payload of the 601 packet to the packet's NextProto, which sends the payload to the same 602 CE as egress node D sends. 604 When node F receives the packet with BitPosition 2 for F, it 605 decapsulates the packet and passes a copy of the payload of the 606 packet to the packet's NextProto, which sends the payload to another 607 CE (not shown in the figure). 609 6. Security Considerations 611 TBD. 613 7. IANA Considerations 615 No requirements for IANA. 617 8. Acknowledgements 619 The authors would like to thank people for their comments to this 620 work. 622 9. References 624 9.1. Normative References 626 [I-D.ietf-bier-te-arch] 627 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 628 for Bit Index Explicit Replication (BIER-TE)", Work in 629 Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9 630 July 2021, . 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, 635 DOI 10.17487/RFC2119, March 1997, 636 . 638 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 639 IANA Considerations Section in RFCs", RFC 5226, 640 DOI 10.17487/RFC5226, May 2008, 641 . 643 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 644 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 645 July 2008, . 647 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 648 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 649 DOI 10.17487/RFC5286, September 2008, 650 . 652 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 653 RFC 5714, DOI 10.17487/RFC5714, January 2010, 654 . 656 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 657 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 658 . 660 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 661 Scope Link State PDUs (LSPs)", RFC 7356, 662 DOI 10.17487/RFC7356, September 2014, 663 . 665 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 666 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 667 RFC 7490, DOI 10.17487/RFC7490, April 2015, 668 . 670 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 671 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 672 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 673 2015, . 675 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 676 S. Shaffer, "Extensions to OSPF for Advertising Optional 677 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 678 February 2016, . 680 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 681 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 682 May 2017, . 684 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 685 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 686 Explicit Replication (BIER)", RFC 8279, 687 DOI 10.17487/RFC8279, November 2017, 688 . 690 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 691 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 692 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 693 2019, . 695 9.2. Informative References 697 [I-D.eckert-bier-te-frr] 698 Eckert, T., Cauchie, G., Braun, W., and M. Menth, 699 "Protection Methods for BIER-TE", Work in Progress, 700 Internet-Draft, draft-eckert-bier-te-frr-03, 5 March 2018, 701 . 704 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 705 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 706 Decraene, B., and D. Voyer, "Topology Independent Fast 707 Reroute using Segment Routing", Work in Progress, 708 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 709 07, 29 June 2021, . 712 [I-D.ietf-spring-segment-protection-sr-te-paths] 713 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 714 "Segment Protection for SR-TE Paths", Work in Progress, 715 Internet-Draft, draft-ietf-spring-segment-protection-sr- 716 te-paths-01, 11 July 2021, 717 . 720 [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. 721 Decraene, "Multicast-Only Fast Reroute", RFC 7431, 722 DOI 10.17487/RFC7431, August 2015, 723 . 725 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 726 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 727 for Bit Index Explicit Replication (BIER) in MPLS and Non- 728 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 729 2018, . 731 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 732 Zhang, "Bit Index Explicit Replication (BIER) Support via 733 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 734 . 736 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 737 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 738 Extensions for Bit Index Explicit Replication (BIER)", 739 RFC 8444, DOI 10.17487/RFC8444, November 2018, 740 . 742 Authors' Addresses 744 Huaimo Chen 745 Futurewei 746 Boston, MA, 747 United States of America 749 Email: Huaimo.chen@futurewei.com 750 Mike McBride 751 Futurewei 753 Email: michael.mcbride@futurewei.com 755 Aijun Wang 756 China Telecom 757 Beiqijia Town, Changping District 758 Beijing 759 102209 760 China 762 Email: wangaj3@chinatelecom.cn 764 Gyan S. Mishra 765 Verizon Inc. 766 13101 Columbia Pike 767 Silver Spring, MD 20904 768 United States of America 770 Phone: 301 502-1347 771 Email: gyan.s.mishra@verizon.com 773 Yisong Liu 774 China Mobile 776 Email: liuyisong@chinamobile.com 778 Yanhe Fan 779 Casa Systems 780 United States of America 782 Email: yfan@casa-systems.com 784 Lei Liu 785 Fujitsu 786 United States of America 788 Email: liulei.kddi@gmail.com 789 Xufeng Liu 790 Volta Networks 791 McLean, VA 792 United States of America 794 Email: xufeng.liu.ietf@gmail.com