idnits 2.17.1 draft-chen-bier-te-egress-protect-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 date (February 21, 2021) is 1152 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 128 -- Looks like a reference, but probably isn't: '65535' on line 128 == Unused Reference: 'RFC5226' is defined on line 637, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC5286' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'RFC7684' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC7770' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC8556' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'I-D.eckert-bier-te-frr' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-segment-routing-ti-lfa' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-protection-sr-te-paths' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC8296' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'RFC8401' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'RFC8444' is defined on line 729, 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 (~~), 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: August 25, 2021 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 February 21, 2021 19 BIER-TE Egress Protection 20 draft-chen-bier-te-egress-protect-00 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 August 25, 2021. 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 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Overview of BIER-TE Egress Protection . . . . . . . . . . . . 4 76 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 77 3.1. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 5 78 3.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 6 79 4. BIER-TE Extensions . . . . . . . . . . . . . . . . . . . . . 7 80 4.1. Extensions to BIER-TE BIFT for Egress Protection . . . . 7 81 4.2. Updated Forwarding Procedure . . . . . . . . . . . . . . 7 82 5. Example Application of BIER-TE Egress Protection . . . . . . 9 83 5.1. Example BIER-TE Topology . . . . . . . . . . . . . . . . 9 84 5.2. BIER-TE BIFT on a BFR . . . . . . . . . . . . . . . . . . 10 85 5.3. Extended BIER-TE BIFT on a BFR . . . . . . . . . . . . . 11 86 5.4. Forwarding using Extended BIER-TE BIFT . . . . . . . . . 12 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 9.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 the BIER architecture defined in [RFC8279]. A 101 multicast packet is replicated and forwarded along the P2MP path/tree 102 encoded in the packet. It does not require intermediate nodes to 103 maintain any per-path/tree state. 105 This document describes a mechanism for fast protection against the 106 failure of an egress node of an explicit P2MP multicast path/tree in 107 a BIER-TE domain. It is called BIER-TE Egress Protection. For a 108 multicast packet to the egress node, when the egress node fails, its 109 upstream hop as a PLR sends the packet to the egress' backup node 110 (called backup egress node) once the PLR detects the failure. 112 This BIER-TE Egress Protection does not require intermediate nodes to 113 maintain any per-path state for fast protection against the failure 114 of an egress node of the path. 116 1.1. Terminology 118 BIER: Bit Index Explicit Replication. 120 BIER-TE: BIER Traffic/Tree Engineering. 122 BFR: Bit-Forwarding Router. 124 BFIR: Bit-Forwarding Ingress Router. 126 BFER: Bit-Forwarding Egress Router. 128 BFR-id: BFR Identifier. It is a number in the range [1,65535]. 130 BFR-NBR: BFR Neighbor. 132 F-BM: Forwarding Bit Mask. 134 BFR-prefix: An IP address (either IPv4 or IPv6) of a BFR. 136 BIRT: Bit Index Routing Table. It is a table that maps from the BFR- 137 id (in a particular sub-domain) of a BFER to the BFR-prefix of 138 that BFER, and to the BFR-NBR on the path to that BFER. 140 BIFT: Bit Index Forwarding Table. 142 FRR: Fast Re-Route. 144 PLR: Point of Local Repair. 146 IGP: Interior Gateway Protocol. 148 LSDB: Link State DataBase. 150 SPF: Shortest Path First. 152 SPT: Shortest Path Tree. 154 OSPF: Open Shortest Path First. 156 IS-IS: Intermediate System to Intermediate System. 158 LSA: Link State Advertisement in OSPF. 160 LSP: Link State Protocol Data Unit (PDU) in IS-IS. 162 2. Overview of BIER-TE Egress Protection 164 For fast protecting an egress node of a BIER-TE domain, a backup 165 egress node is configured on the egress node. After the 166 configuration, the egress node distributes the information about the 167 backup egress to its direct neighbors. 169 For clearly distinguishing between an egress node and a backup egress 170 node, an egress node is called a primary egress node sometimes. 172 For a multicast packet to a primary egress node of the domain, when 173 the primary egress node fails, its upstream hop as a point of local 174 repair (PLR) sends the packet to the backup egress node configured to 175 protect the primary egress node once the PLR detects the failure. 176 The upstream hop of the primary egress node is its direct neighbor. 178 A Bit-Forwarding Router (BFR) in a BIER-TE sub-domain has a BIER-TE 179 Bit Index Forwarding Tables (BIFT) [I-D.ietf-bier-te-arch]. A BIER- 180 TE BIFT on a BFR comprises a forwarding entry for a BitPosition (BP) 181 assigned to each of the adjacencies of the BFR. If the BP represents 182 a forward connected adjacency, the forwarding entry for the BP 183 forwards the multicast packet with the BP to the directly connected 184 BFR neighbor of the adjacency. If the BP represents a BFER (i.e., 185 egress node) or say a local decap adjacency, the forwarding entry for 186 the BP decapsulates the multicast packet with the BP and passes a 187 copy of the payload of the packet to the packet's NextProto within 188 the BFR. 190 The BIER-TE BIFT on a BFR is extended to support protection against 191 the failure of an egress node. For each forwarding entry of the 192 BIER-TE BIFT on the BFR, if it is for the BP representing a forward 193 connected adjacency and its BFR-NBR is a BFER (i.e., primary egress 194 node), the forwarding entry is extended to include a new forwarding 195 entry, which is called backup forwarding entry or backup entry for 196 short. This backup entry forwards the multicast packet with the BP 197 to the backup egress node, which is configured to protect the primary 198 egress node. 200 Once the BFR as a PLR detects the failure of its BFR-NBR X that is a 201 primary egress node of the domain, for a multicast packet with the BP 202 for the primary egress node, the PLR uses the backup forwarding entry 203 in the extended BIER-TE BIFT to send the packet to the backup egress 204 node configured to protect the primary egress node. 206 3. Protocol Extensions 208 This section defines extensions to OSPF and IS-IS for advertising the 209 backup information (including the information about the backup egress 210 node for protecting a primary egress node). 212 3.1. Extensions to OSPF 214 When a node P (as a primary egress node) has a backup egress node 215 configured to protect against its failure, node P advertises the 216 information about the backup egress node to its neighbors in its 217 router information opaque LSA of LS type 9 or 10. The information is 218 included in a backup egress BP TLV. The format of the TLV is shown 219 in Figure 1. 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type (TBD1) | Length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Reserved | BP of backup egress node | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Sub-TLVs (Optional) | 229 : : 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1: OSPF Backup Egress BP TLV 234 Type: 2 octets, its value (TBD1) is to be assigned by IANA. 236 Length: 2 octets, its value is 4 plus the length of the Sub-TLVs 237 included. If no Sub-TLV is included, its value is 4. 239 Reserved: 2 octets, it MUST be set to zero when sending and be 240 ignored while receiving. 242 BP of backup egress node: 2 octets, its value is the local decap 243 BitPosition of the backup egress node, which is configured to protect 244 against the failure of the primary egress node. 246 Sub-TLVs (Optional): No Sub-TLV is defined now. 248 After each of the neighbors receives the backup egress BP TLV from 249 node P, it knows that node P as a primary egress node will be 250 protected by the backup egress node in the TLV. Once detecting the 251 failure of node P, it sends the packet with the BP for node P towards 252 the backup egress node. 254 3.2. Extensions to IS-IS 256 For supporting fast protection against the failure of a primary 257 egress node in a BIER-TE domain, a new IS-IS TLV, called IS-IS backup 258 egress BP TLV, is defined. It contains the local decap BitPosition 259 of the backup egress node configured to protect the primary egress 260 node. 262 When a node P (as a primary egress node) has a backup egress node 263 configured to protect against its failure, node P advertises the 264 information about the backup egress node to its neighbors using a IS- 265 IS backup egress BP TLV. 267 This TLV may be advertised in IS-IS Hello (IIH) PDUs, LSPs, or in 268 Circuit Scoped Link State PDUs (CS-LSP) [RFC7356]. The format of the 269 TLV is shown in Figure 2. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type (TBD2) | Length | BP of backup egress node | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 ~ Sub-TLVs (Optional) ~ 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 2: IS-IS Backup Egress BP TLV 281 Type: 1 octet, its value (TBD2) is to be assigned by IANA. 283 Length: 1 octet, its value is 2 plus the length of the Sub-TLVs 284 included. If no Sub-TLV is included, its value is 2. 286 BP of backup egress node: 2 octets, its value is the local decap 287 BitPosition of the backup egress node configured to protect against 288 the failure of the primary egress node. 290 Sub-TLVs (Optional): No Sub-TLV is defined now. 292 4. BIER-TE Extensions 294 This section describes extensions to a BIER-TE BIFT of a BFR for 295 supporting fast protection against the failure of a primary egress 296 node and enhancements on a forwarding procedure to use the extended 297 BIER-TE BIFT for egress protection. 299 4.1. Extensions to BIER-TE BIFT for Egress Protection 301 If a BFR is a neighbor of an egress node in a BIER-TE sub-domain, it 302 has an extended BIER-TE BIFT to support protection against the 303 failure of its neighbor egress node. The forwarding entry with the 304 egress node (say X) as its BFR-NBR in the BIFT comprises a backup 305 entry. The backup entry contains a flag EPA (which is short for 306 Egress Protection is Active) and a backup path to a backup egress 307 node (say Y) which is configured to protect the egress node. 309 In normal operations, the flag EPA in the backup entry for neighbor 310 egress node X is set to 0 (zero). The flag EPA is set to 1 (one) 311 when egress node X fails. EPA == 1 means that the egress protection 312 for primary egress node X is active and the backup entry will be used 313 to forward the packet with BP for egress node X to backup egress node 314 Y along the backup path. 316 The backup path from the BFR to backup egress node Y is a path that 317 satisfies a set of constraints and does not traverse primary egress 318 node X or any link connected to X. In one implementation, the backup 319 path is represented by the BitPositions for the adjacencies along the 320 backup path. 322 4.2. Updated Forwarding Procedure 324 The forwarding procedure defined in [I-D.ietf-bier-te-arch] is 325 updated/enhanced for using an extended BIER-TE BIFT to consider the 326 egress protection (i.e., the new backup entry containing EPA and 327 backup path in the BIFT). 329 For a multicast packet with the BP in the BitString indicating a BFR- 330 NBR as a primary egress node, the updated forwarding procedure on a 331 BFR sends the packet towards the backup egress node of the primary 332 egress node if the primary egress node fails. 334 It checks whether EPA equals to 1 (one) in the forwarding entry with 335 the BFR-NBR that is the primary egress node. If EPA is 1 (i.e., the 336 primary egress node fails and the egress protection for primary 337 egress is active), then the procedure clears two BPs in the packet's 338 BitString and checks whether the backup egress node is not one of the 339 packet's destinations. 341 One BP is the BP for the primary egress node and the other is the BP 342 for the forward connected adjacency from the BFR to the primary 343 egress node. After these two BPs are cleared in the packet's 344 BitString, the packet will not be sent to the failed primary egress 345 node. 347 When the BP for the backup egress node in the packet's BitString is 348 0, the backup egress node is not one of the packet's destinations. 349 In this case, the procedure adds the backup path to the backup egress 350 node into the packet through adding the BPs for the backup path in 351 the packet's BitString. Thus the packet will be sent to the backup 352 egress node along the backup path. 354 The updated procedure is described in Figure 3. It can also be used 355 by the BFR to forward multicast packets in normal operations. 357 Packet = the packet received by BFR; 358 FOR each BP k (from the rightmost in Packet's BitString) { 359 IF BP k is local decap adjacency (or say BP of the BFR) { 360 copies Packet, sends copy's payload to the multicast 361 flow overlay and clears bit k in Packet's BitString 362 } ELSE IF BP k is forward connect adjacency of the BFR { 363 finds the forwarding entry in the BIER-TE BIFT for the domain 364 using BP k; 365 Clears BP k; 366 IF EPA == 1 {//Egress Protection for BFR-NBR/egress is Active 367 Clears BP for BFR-NBR in Packet's BitString; 368 IF BP for backup egress is 0 in Packet's BitString { 369 Adds BPs for backup path into Packet's BitString 370 } 371 } //egress removed, backup path to backup egress added 372 ELSE { 373 Copies Packet, updates the copy's BitString by 374 clearing all the BPs for the adjacencies of the BFR, 375 and sends the updated copy to BFR-NBR 376 } 377 } 378 } 380 Figure 3: Updated Forwarding Procedure 382 5. Example Application of BIER-TE Egress Protection 384 This section illustrates an example application of BIER-TE Egress 385 Protection on a BFR in a BIER-TE topology in Figure 4. 387 5.1. Example BIER-TE Topology 389 An example BIER topology for a BIER-TE sub-domain is shown in 390 Figure 4. It has 8 nodes/BFRs A, B, C, D, E, F, G and H. 392 6' 13' 14' 4 (0:01000) 393 /-----------( G )----------( H )Backup Egress for D 394 / 15'\_______ 10'/ \ 395 / _______)____/ \ 396 / / (_____ (CE) Receiver 397 / / \ / 398 8' 7' /5' 3' 4' /9' 17' 16'\ / 399 ( A )--------( B )------------( C )------------( D )Primary Egress 400 5(0:10000) \1' \11' 18' 1 (0:00001) 401 \ \ 402 \2' 19' 20' \12' 403 ( E )------------( F ) 404 3(0:00100) 2 (0:00010) 406 Figure 4: Example BIER-TE Topology 408 Nodes/BFRs D, F, E, H and A are BFERs and have local decap adjacency 409 BitPositions 1, 2, 3, 4, and 5 respectively. For simplicity, these 410 BPs are represented by (SI:BitString), where SI = 0 and BitString is 411 of 5 bits. BPs 1, 2, 3, 4, and 5 are represented by 1 (0:00001), 2 412 (0:00010), 3 (0:00100), 4 (0:01000) and 5 (0:10000) respectively. 414 The BitPositions for the forward connected adjacencies are 415 represented by i', where i is from 1 to 20. In one option, they are 416 encoded as (n+i), where n is a power of 2 such as 32768. For 417 simplicity, these BitPositions are represented by (SI:BitString), 418 where SI = (6 + (i-1)/5) and BitString is of 5 bits. BitPositions i' 419 (i from 1 to 20) are represented by 1'(6:00001), 2'(6:00010), 420 3'(6:00100), 4'(6:01000), 5'(6:10000), 6'(7:00001), 7'(7:00010), 421 8'(7:00100), . . . , 20'(9:10000). 423 For a link between two nodes X and Y, there are two BitPositions for 424 two forward connected adjacencies. These two forward connected 425 adjacency BitPositions are assigned on nodes X and Y respectively. 426 The BitPosition assigned on X is the forward connected adjacency of 427 Y. The BitPosition assigned on Y is the forward connected adjacency 428 of X. 430 For example, for the link between nodes B and C in the figure, two 431 forward connected adjacency BitPositions 3' and 4' are assigned to 432 two ends of the link. BitPosition 3' is assigned on node B to B's 433 end of the link. It is the forward connected adjacency of node C. 434 BitPosition 4' is assigned on node C to C's end of the link. It is 435 the forward connected adjacency of node B. 437 BFER H is configured to protect BFER D on BFR D. Suppose that this 438 information is distributed to BFR D's neighbors BFR C and BFR G by 439 IGP. BFR C and BFR G know that H is the backup egress to protect the 440 primary egress D. 442 Similarly, BFER D is configured to protect BFER H on BFR H; BFER F is 443 configured to protect BFER E on BFR E; and BFER E is configured to 444 protect BFER F on BFR F. These are not shown in the figure. 446 CE is a multicast traffic Receiver, which is dual homed to primary 447 egress node D and backup egress node H for protecting primary egress 448 D. During normal operations, there is no multicast traffic to CE 449 from backup egress node H and CE receives the multicast traffic only 450 from primary egress node D. There is no duplicated traffic to 451 receiver CE. This is different from MoFRR in [RFC7431], where 452 duplicated traffic is sent to both the primary egress D and backup 453 egress H, to which the receiver CE is dual homed. When primary 454 egress node D fails, the multicast traffic is sent to CE from backup 455 egress node H. 457 5.2. BIER-TE BIFT on a BFR 459 Every BFR in a BIER-TE sub-domain/topology has a BIER-TE BIFT. For 460 the BIER-TE topology in Figure 4, each of 8 nodes/BFRs A, B, C, D, E, 461 F, G and H has its BIER-TE BIFT for the topology. 463 The BIER-TE BIFT on BFR C (i.e. node C) is shown in Figure 5. 465 The 1st forwarding entry in the BIFT will forward a multicast packet 466 with BitPosition 18' to D. 468 The 2nd forwarding entry in the BIFT will forward a multicast packet 469 with BitPosition 12' to F. 471 The 3rd forwarding entry in the BIFT will forward a multicast packet 472 with BitPosition 10' to H. 474 The 4-th forwarding entry in the BIFT will forward a multicast packet 475 with BitPosition 3' to B. 477 +----------------+--------------+------------+ 478 | Adjacency BP | Action | BFR-NBR | 479 | (SI:BitString) | | (Next Hop) | 480 +================+==============+============+ 481 | 18' (9:00100) | fw-connected | D | 482 +----------------+--------------+------------+ 483 | 12' (8:00010) | fw-connected | F | 484 +----------------+--------------+------------+ 485 | 10' (7:10000) | fw-connected | H | 486 +----------------+--------------+------------+ 487 | 3' (6:00100) | fw-connected | B | 488 +----------------+--------------+------------+ 490 Figure 5: BIER-TE BIFT on BFR C 492 The BIER-TE BIFT on BFR D (i.e. node D) is shown in Figure 6. 494 The 1st forwarding entry in the BIFT will forward a multicast packet 495 with BitPosition 17' to C. 497 The 2nd forwarding entry in the BIFT will forward a multicast packet 498 with BitPosition 15' to G. 500 The 3rd forwarding entry in the BIFT will locally decapsulate a 501 multicast packet with BitPosition 1 and pass a copy of the payload of 502 the packet to the packet's NextProto. 504 +----------------+--------------+------------+ 505 | Adjacency BP | Action | BFR-NBR | 506 | (SI:BitString) | | (Next Hop) | 507 +================+==============+============+ 508 | 17' (9:00010) | fw-connected | C | 509 +----------------+--------------+------------+ 510 | 15' (8:10000) | fw-connected | G | 511 +----------------+--------------+------------+ 512 | 1 (0:00001) | local-decap | | 513 +----------------+--------------+------------+ 515 Figure 6: BIER-TE BIFT on BFR D 517 5.3. Extended BIER-TE BIFT on a BFR 519 Each of the BFRs that are neighbors of egress nodes (i.e., BFERs) in 520 a BIER-TE sub-domain/topology has an extended BIER-TE BIFT to support 521 protection against the failure of every its neighbor egress node. 523 For example, the extended BIER-TE BIFT on BFR C is illustrated in 524 Figure 7. It comprises a backup entry for each of its neighbor 525 egress nodes D, F and H. Each of these backup entries contains a 526 flag EPA and a backup path to a backup egress node. EPA is set to 527 zero in normal operations. EPA in the backup entry for neighbor 528 egress node X is set to one when egress node X fails. 530 The backup entry of the 1st forwarding entry in the BIFT contains EPA 531 = 0 and backup path {10', 4}. When egress node D fails, the EPA is 532 set to one and the backup entry is used to forward a multicast packet 533 with BitPosition 1 for D to D's backup egress node H with BitPosition 534 4 along the backup path. 536 The backup entry of the 2nd forwarding entry in the BIFT contains EPA 537 = 0 and backup path {3', 2', 3}. When egress node F fails, EPA is 538 set to one and the backup entry is used to forward a multicast packet 539 with BitPosition 2 for F to F's backup egress node E with BitPosition 540 3 along the backup path. 542 +----------------+--------------+----------+-----------------+ 543 | Adjacency BP | Action | BFR-NBR | Backup Entry | 544 | (SI:BitString) | |(Next Hop)|(EP, BackupPath) | 545 +================+==============+==========+=================+ 546 | 18' (9:00100) | fw-connected | D |EPA=0, {10', 4} | 547 +----------------+--------------+----------+-----------------+ 548 | 12' (8:00010) | fw-connected | F |EPA=0, {3', 2',3}| 549 +----------------+--------------+----------+-----------------+ 550 | 10' (7:10000) | fw-connected | H |EPA=0, {18', 1} | 551 +----------------+--------------+----------+-----------------+ 552 | 3' (6:00100) | fw-connected | B |EPA=0, { } | 553 +----------------+--------------+----------+-----------------+ 555 Figure 7: Extended BIER-TE BIFT on BFR C 557 The backup entry of the 3rd forwarding entry in the BIFT contains EPA 558 = 0 and backup path {18', 1}. When egress node H fails, EPA is set 559 to one and the backup entry is used to forward a multicast packet 560 with BitPosition 4 for H to H's backup egress node D with BitPosition 561 1 along the backup path. 563 5.4. Forwarding using Extended BIER-TE BIFT 565 Suppose that there is a multicast packet with explicit path {7', 4', 566 18', 12', 2, 1} on BFR A. The path is encoded in the BitPositions of 567 the packet. BFR A forwards the packet to BFR B according to the 568 forwarding entry for 7' in its extended BIER-TE BIFT. BFR B forwards 569 the packet to BFR C according to the forwarding entry for 4' in B's 570 extended BIER-TE BIFT. 572 In normal operations, after receiving the packet from BFR B, BFR C 573 copies and sends the packet to BFR D and BFR F using the forwarding 574 entries for 18' and 12' in the extended BIER-TE BIFT on BFR C 575 respectively. 577 Once BFR C detects the failure of egress node D, it sets EPA of the 578 backup entry in the 1st forwarding entry to one. After receiving the 579 packet from BFR B, BFR C copies and sends the packet to D's backup 580 egress node H using the backup entry in the forwarding entry for 18' 581 with BFR-NBR D in C's extended BIER-TE BIFT. It copies and sends the 582 packet to F using the forwarding entry for 12' in C's extended BIER- 583 TE BIFT. 585 The packet received by BFR C from BFR B contains (SI:BitString) = 586 (0:00011)(8:00010)(9:00100), which represents {18', 12', 2, 1}. 587 Since EPA in the backup entry in the forwarding entry with BFR-NBR == 588 D is 1, BFR C copies and sends the packet to D's backup egress node H 589 in the following steps. 591 At first, it obtains the backup entry from the forwarding entry for 592 18' with BFR-NBR D. EPA == 1 in the backup entry indicates that 593 egress protection for egress node D is active. BFR C clears 594 BitPositions 18' and 1 in Packet's BitString and adds the backup path 595 {10', 4} into Packet's BitString. The updated BitString in Packet is 596 (0:01010)(7:10000)(8:00010), which represents {12', 10', 4, 2}. This 597 lets BFR C copy and send Packet to F and H using the forwarding 598 entries for 12' and 10' in C's extended BIER-TE BIFT respectively. 600 When node H receives the packet with BitPosition 4 for H, it 601 decapsulates the packet and passes a copy of the payload of the 602 packet to the packet's NextProto, which sends the payload to the same 603 CE as egress node D sends. 605 When node F receives the packet with BitPosition 2 for F, it 606 decapsulates the packet and passes a copy of the payload of the 607 packet to the packet's NextProto, which sends the payload to another 608 CE (not shown in the figure). 610 6. Security Considerations 612 TBD. 614 7. IANA Considerations 616 No requirements for IANA. 618 8. Acknowledgements 620 The authors would like to thank people for their comments to this 621 work. 623 9. References 625 9.1. Normative References 627 [I-D.ietf-bier-te-arch] 628 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 629 for Bit Index Explicit Replication (BIER-TE)", draft-ietf- 630 bier-te-arch-09 (work in progress), October 2020. 632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 633 Requirement Levels", BCP 14, RFC 2119, 634 DOI 10.17487/RFC2119, March 1997, 635 . 637 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 638 IANA Considerations Section in RFCs", RFC 5226, 639 DOI 10.17487/RFC5226, May 2008, 640 . 642 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 643 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 644 July 2008, . 646 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 647 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 648 DOI 10.17487/RFC5286, September 2008, 649 . 651 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 652 RFC 5714, DOI 10.17487/RFC5714, January 2010, 653 . 655 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 656 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 657 . 659 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 660 Scope Link State PDUs (LSPs)", RFC 7356, 661 DOI 10.17487/RFC7356, September 2014, 662 . 664 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 665 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 666 RFC 7490, DOI 10.17487/RFC7490, April 2015, 667 . 669 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 670 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 671 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 672 2015, . 674 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 675 S. Shaffer, "Extensions to OSPF for Advertising Optional 676 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 677 February 2016, . 679 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 680 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 681 May 2017, . 683 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 684 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 685 Explicit Replication (BIER)", RFC 8279, 686 DOI 10.17487/RFC8279, November 2017, 687 . 689 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 690 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 691 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 692 2019, . 694 9.2. Informative References 696 [I-D.eckert-bier-te-frr] 697 Eckert, T., Cauchie, G., Braun, W., and M. Menth, 698 "Protection Methods for BIER-TE", draft-eckert-bier-te- 699 frr-03 (work in progress), March 2018. 701 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 702 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 703 and D. Voyer, "Topology Independent Fast Reroute using 704 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 705 lfa-05 (work in progress), November 2020. 707 [I-D.ietf-spring-segment-protection-sr-te-paths] 708 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 709 "Segment Protection for SR-TE Paths", draft-ietf-spring- 710 segment-protection-sr-te-paths-00 (work in progress), 711 September 2020. 713 [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. 714 Decraene, "Multicast-Only Fast Reroute", RFC 7431, 715 DOI 10.17487/RFC7431, August 2015, 716 . 718 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 719 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 720 for Bit Index Explicit Replication (BIER) in MPLS and Non- 721 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 722 2018, . 724 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 725 Zhang, "Bit Index Explicit Replication (BIER) Support via 726 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 727 . 729 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 730 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 731 Extensions for Bit Index Explicit Replication (BIER)", 732 RFC 8444, DOI 10.17487/RFC8444, November 2018, 733 . 735 Authors' Addresses 737 Huaimo Chen 738 Futurewei 739 Boston, MA 740 USA 742 Email: Huaimo.chen@futurewei.com 744 Mike McBride 745 Futurewei 747 Email: michael.mcbride@futurewei.com 749 Aijun Wang 750 China Telecom 751 Beiqijia Town, Changping District 752 Beijing, 102209 753 China 755 Email: wangaj3@chinatelecom.cn 756 Gyan S. Mishra 757 Verizon Inc. 758 13101 Columbia Pike 759 Silver Spring MD 20904 760 USA 762 Phone: 301 502-1347 763 Email: gyan.s.mishra@verizon.com 765 Yisong Liu 766 China Mobile 768 Email: liuyisong@chinamobile.com 770 Yanhe Fan 771 Casa Systems 772 USA 774 Email: yfan@casa-systems.com 776 Lei Liu 777 Fujitsu 779 USA 781 Email: liulei.kddi@gmail.com 783 Xufeng Liu 784 Volta Networks 786 McLean, VA 787 USA 789 Email: xufeng.liu.ietf@gmail.com