idnits 2.17.00 (12 Aug 2021) /tmp/idnits33193/draft-eckert-bier-te-frr-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC8279], [I-D.ietf-bier-te-arch], [RFC7431]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 591: '... 1. Tunneling SHOULD be used. The ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 1531 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'BitStringLength' is mentioned on line 513, but not defined == Missing Reference: 'Index' is mentioned on line 563, but not defined == Missing Reference: 'BP' is mentioned on line 558, but not defined == Missing Reference: 'I' is mentioned on line 568, but not defined == Missing Reference: 'VRF' is mentioned on line 581, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Eckert 3 Internet-Draft Huawei 4 Intended status: Experimental G. Cauchie 5 Expires: September 6, 2018 Bouygues Telecom 6 W. Braun 7 M. Menth 8 University of Tuebingen 9 March 5, 2018 11 Protection Methods for BIER-TE 12 draft-eckert-bier-te-frr-03 14 Abstract 16 This document proposes protection methods for the BIER-TE 17 architecture [I-D.ietf-bier-te-arch]. These include 1+1 (live-live) 18 path/tree [RFC7431] redundancy, 1:1 path/tree protection, as well as 19 fast reroute (FRR) methods. The latter may protect against link and/ 20 or node failures and leverage infrastructure tunnels, BIER-in-BIER 21 encapsulation, or header modification for implementation. 23 In particular, this memo describes FRR for BIER-TE in detail. FRR 24 for BIER-TE requires support from the BIER-TE controller and the BFRs 25 that are attached to a link/adjacency for which FRR protection is 26 desired. FRR relies on the BIER header described in [RFC8279] which 27 is also used by BIER-TE. It does not require extensions or 28 modifications to existing BIER-TE tables. However, the presented FRR 29 procedures need some additional forwarding plane logic on the BFR. 30 An additional table is needed that carries information about pre- 31 computed backup paths. When a failure is detected, the information 32 from this table is used to modify the bitstring in the BIER header 33 before forwarding a packet over a backup path. To prevent undesired 34 packet duplication, packets should be tunneled on the backup paths. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 6, 2018. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Overview of FRR Mechanisms for BIER-TE . . . . . . . . . . . 3 72 2.1. Path/Tree Diversity . . . . . . . . . . . . . . . . . . . 3 73 2.1.1. 1+1 Path/Tree Redundancy . . . . . . . . . . . . . . 3 74 2.1.2. 1:1 Path/Tree Protection . . . . . . . . . . . . . . 5 75 2.2. 1:1 Link/Node Protection . . . . . . . . . . . . . . . . 5 76 2.2.1. Link Protection using Existing Mechanisms . . . . . . 6 77 2.2.2. Node Protection using Existing Mechanisms . . . . . . 6 78 2.2.3. Native 1:1 Protection using BIER-in-BIER 79 Encapsulation . . . . . . . . . . . . . . . . . . . . 7 80 2.2.4. Native BIER-TE Node and Link Protection . . . . . . . 7 81 3. FRR Extension for Native 1:1 Protection with BIER-TE . . . . 7 82 3.1. FRR Key Concepts . . . . . . . . . . . . . . . . . . . . 8 83 3.2. The BIER-TE Adjacency FRR Table (BTAFT) . . . . . . . . . 9 84 3.3. FRR in BIER-TE Forwarding . . . . . . . . . . . . . . . . 10 85 3.4. FRR in the BIER-TE Controller . . . . . . . . . . . . . . 10 86 3.5. BIER-TE FRR Benefits . . . . . . . . . . . . . . . . . . 11 87 3.6. Adjustment to the BIER-TE Forwarding Pseudocode . . . . . 11 88 3.7. Recommendations for Tunneling . . . . . . . . . . . . . . 14 89 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 91 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 94 7.2. Informational References . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 The BIER-TE architecture is defined in [I-D.ietf-bier-te-arch] and 100 does not provide any protection mechanisms. However, there are 101 several approaches to protect multicast traffic against network 102 failures. This draft gives an overview of 1+1 (live-live) path/tree 103 redundancy, 1:1 path/tree protection, as well as fast reroute (FRR) 104 methods including link and node protection. They may leverage either 105 existing mechanisms with some extensions for BIER-TE, BIER-TE point- 106 to-multipoint tunnels, or renounce on tunneling at all with the 107 downside of reduced coverage. 109 This document describes additions to the BIER-TE architecture that 110 facilitate FRR for link and node protection using BIER-TE 111 encapsulation. Similar extensions are needed for node-protection FRR 112 with existing mechanisms and must be supported by and must be 113 supported by the BIER-TE controller and BFRs attached to a link/ 114 adjacency for which FRR support is required. The FRR operation 115 modifies the BIER header to facilitate local bypass of failed 116 elements. It is possible to add and remove multicast links to the 117 header, use unicast tunnels, e.g., MPLS tunnels, to implement the 118 bypass, or to leverage BIER-in-BIER encapsulation. 120 The BIER-TE FRR method only requires a small set of additional 121 forwarding entries that are stored in a separate table called the 122 BTAFT. The entries depend only on the topology and not on the 123 multicast flows. 125 2. Overview of FRR Mechanisms for BIER-TE 127 In the following we give an overview of various protection methods 128 that may be applied to protect BIER-TE-based multicast trees. 130 BIER-TE can be combined with a range of mechanisms to provide 131 resilience in the face of failures such as link or nodes. In this 132 section, we give an overview of the key options. 134 2.1. Path/Tree Diversity 136 2.1.1. 1+1 Path/Tree Redundancy 138 In 1+1 redundancy, often also called live-live, traffic is sent twice 139 across the network, path-engineered in a way that no single point of 140 failure (link or node) is in the path for both copies towards every 141 single receiver. For point-to-multipoint transmission, this 142 basically requires disjoint ent-to-end paths. For point-to- 143 multipoint transmission, distribution structures are needed that 144 fulfill the earlier mentioned criterion. They usually resemble 145 "orthogonal" tree structures. See [BIERFRRANALYSIS] for 146 illustration. For multicast transmission, 1+1 redundancy can be very 147 attractive because the cost of dual transmission can often be 148 negligible vs. the overall bandwidth saving of doing replication in 149 the network. 151 Path-engineering for 1+1 redundancy can become quite advanced 152 depending on the topology - but it does not require any new 153 functionalities from BIER-TE. It just requires appropriate 154 engineering and potentially additional application or BIER edge 155 functions such as traffic duplication at the sender and traffic 156 deduplication at the receiver. 158 Consider the following topology example: each sender or receiver has 159 connections to two BFRs to overcome the failure of either BFR. The 160 application on the source creates two copies for every packet. It 161 sends one "a-packet" copy onto its a-link and the other "b-packet" 162 copy onto its b-link. Snd,Rcvr could be BFIR,BFER or they could send 163 native multicast and the BFR they connect to are BFIR, BFER. 165 BIER-TE bitstrings need to be set up for a-packets and b-packets to 166 pass through the topology counter-circular to each other so that any 167 individual link or node failure never interrupt both a-packets and 168 b-packets 170 Snd1,Rcv1 171 a-link/ \ 172 / \ 173 ------ BFR1a ---- BFR1b ------- 174 / \ 175 - BFR2a (RING1) BFR4b - 176 / \ / \ 177 Snd2,Rcv2 \ / Snd4,Rcv4 178 -- BFR2b ---- BFR3a -- BFR3b --- BFR4a ---- 179 / \ / \ 180 / Snd3,Rcv3 \ 181 - BFR5a BFR6b - 182 / \ (RING2) / \ 183 Snd5,Rcv5 \ / Rcv5 184 -- BFR5b --- BFR6a --- BFR6b --- BFR6a ----- 185 \ / 186 Rcv6 188 The application side in Snd,Rcv needs to be able to eliminate the 189 duplication resulting from receiving both a-packet and b-packet 190 copies (unless there is a failure). This is easily done if there is 191 any encapsulation (such as transport layer) where sequence numbers 192 are used. Otherwise such a layer has to be added. 194 If sender and/or receivers can not support the duplication on the 195 sending side and/or deduplication on the receiving side, it is easy 196 to derive variations of these designs in which network ingress/egress 197 devices take over these rules. The functionality that is least 198 common in network devices is per-packet deduplication based on 199 sequence numbers in the packets. Only few network transport service 200 encapsulations do currently provide sequence numbers, e.g., L2TPv3. 202 Because the described ingress/egress functionalities are not specific 203 to BIER-TE but would equally apply to the solution if built with 204 native IP multicast or RSVP-TE/P2MP, this document does not propose 205 any further functionality required for this type of solutions. 207 Compared to RSVP-TE/P2MP, one specific benefit of BIER-TE is that 208 trees can be optimized without re-signaling solely by the BIER-TE 209 sender adding/deleting bits representing leaf trees to receivers that 210 join/leave the content. 212 2.1.2. 1:1 Path/Tree Protection 214 If duplicate transmission is not desirable, variations of the above 215 scheme can be devised where only one copy is sent to each receiver. 216 Such solutions require receiver feedback to the sender and are 217 therefore most feasible for a limited receiver set deployment, e.g., 218 regional multi-system operator (MSO) distribution networks to hybrid 219 fiber-coaxial (HFC) headends. For example, by default only the 220 a-tree could be transmitted, and upon reception failure at any subset 221 of receivers, the sender would transmit to the subset of the b-tree 222 covering those receivers. Upon recovery of the a-tree, signaling 223 from the receiver could equally stop transmission of the b-tree 224 toward this receiver. 226 For a more common path utilization across the network in the no- 227 failure scenario, senders could instead start with 50% receiver 228 populated a-tree and b-tree as well. 230 These options heavily depend on the ability to change the set of 231 receivers in a tree without signaling. The enabling/disabling of 232 sending to a particular branch of the network can be done within a 233 single round-trip starting with the signaling of the reception 234 failure by a receiver. 236 2.2. 1:1 Link/Node Protection 238 In this section we discuss the link and node protection for BIER-TE 239 using existing mechanisms and the native BIER-Te FRR approach. 241 2.2.1. Link Protection using Existing Mechanisms 243 BIER-TE can be used in conjunction with reactive 1:1 link protection 244 as it is also possible in RSVP-TE/P2MP. When a node sees a failure 245 on a link, it assumes that the link has failed and uses a pre- 246 established backup path to get packets to the node on the other side 247 of the link. In example below, BFR2 would use a pre-established path 248 via l7,l2,l3,l4 to send packets to BFR3 when it sees a failure of 249 link1. 251 l3 252 ------ BFR4 ------- BFR5 ------ 253 / / \ 254 / l2 l4 / \ l5 255 / / | 256 BFR1 ---- BFR2 --X-- BFR3 ---- BFR6 -- 257 l7 l1 \ | 258 \ | l6 259 \ | 260 -- BFR7 -- 262 In BIER-TE, this link protection can be done either by using some 263 pre-existing traffic engineered tunneling mechanisms such as RSVP-TE/ 264 P2P or Segment Routing paths to get packets to BFR3 in the link 265 failure case. These options do not require enhancements to BIER-TE. 267 2.2.2. Node Protection using Existing Mechanisms 269 BFR2 can not distinguish whether link1 or BFR3 fails. It simply 270 needs to assume one or the other and perform link or node protection. 271 If it assumes node failure and wants to perform node protection, the 272 solution becomes more complex. Effectively, BFR2 needs to get the 273 packets over to BFR5,BFR6 and BFR7 or the subset of those next-next- 274 hops that is required. Using pre-established p2p backup tunnels 275 (RSVP-TE/P2P or SR) allows to send just to the required subset of 276 next-next-hops at the expense of sending the traffic up to three 277 times across the path consisting of the links l7,l2,l3. The required 278 subset of next-next-hops consists of the downstream next-next-hops. 279 Downstream means that the next-next-hops are the direct multicast 280 children of the next-hop. This is similar to the FRR concept 281 discussed in Section 3.1. Using a backup RSVP-TE/P2MP tree 282 eliminates this higher load but would deliver to all next-next-hops 283 or it would be necessary to set up backup RSVP-TE/P2MP trees for all 284 possible subsets of next-next-hops (which may not scale well). 286 2.2.3. Native 1:1 Protection using BIER-in-BIER Encapsulation 288 A simpler solution for node protection leverages BIER-in-BIER 289 encapsulation. In this approach, BFR2 would encapsulate the BIER-TE 290 packet into another BIER-TE packet whose bitset was pre-built to 291 carry the packet via l7,l2,l3,l5,l6 to BFR5,BFR6,BFR7 optionally 292 reducing the bitset based on the bitset of the encapsulated BIER-TE 293 packet. This document describes this option in Section 3. 295 If there are no available infrastructure tunnels deployed, then BIER- 296 in-BIER encapsulation could equally be used for the simple case of 297 link protection. 299 2.2.4. Native BIER-TE Node and Link Protection 301 An even simpler solution is to not encapsulate the BIER-TE packet 302 into another BIER-TE packet but instead to rewrite the bitstring of 303 the BIER-TE packet to make the packets get delivered via l2,l3 to 304 BFR5, via l5 to BFR6 if that is part of the original bitstring and 305 via l6 to BFR7, if that is part of the original bitstring. 307 This document specifies the necessary rules for the BIER-TE 308 forwarding machinery for such bitstring bitstring rewrites to enable 309 the most lightweight and efficient form of node protection with BIER- 310 TE. 312 This solution will not work in all topologies though because the set 313 of bits necessary to pass the traffic across a backup path/tree may 314 cause undesired traffic forwarding (duplicates/loops). 316 3. FRR Extension for Native 1:1 Protection with BIER-TE 318 In this section, we explain the FRR extension to support native 1:1 319 protection with BIER-TE. These extensions do not require changes to 320 the BIER header or to forwarding mechanism. The protection procedure 321 runs directly before the BIER-TE forwarding procedure. 323 Note that the FRR extensions require the use of a new table which is 324 described in Section 3.2. The table is only filled with entries that 325 depend on the network topology and do not depend on the multicast 326 flows. 328 An implementation of BIER-TE FRR based on BIER-in-BIER encapsulation 329 in the networking programming language P4 is given in [BIER-FRR-P4]. 330 The source code is thoroughly documented and contains examples how 331 the BIER-TE BIFT and BIER-TE BTAFT tables can be filled. 333 3.1. FRR Key Concepts 335 In this section we use the following example to explain the key 336 concepts of BIER-TE FRR. The example shows a multicast tree from 337 BFR1 to BFR2, BFR6, BFR9. The path to BFR2 is represented by the 338 bits p1, p3 and p4. The bits p1, p6, p7 and the bits p2, p8 339 represent the path towards BFR6 and BFR 9, respectively. Local_decap 340 bits for all BFR2,BFR6, and BFR9 are also used. 342 BFR1-------+ 343 | | 344 | | 345 p4 p3 v p1 v p2 346 BFR2<---BFR3<-----BFR4------BFR5 347 | | p5 | 348 | | | 349 p8 | v p6 v p8 350 BFR6<-----BFR7-----BFR9 351 p7 p9 p10 353 First, we consider that the link from P towards F fails. The failure 354 can be protected by the backup paths over BFR3->BFR6->BFR7: p3, p8, 355 p9 (BP1) and BFR5->BFR9->BFR7: p5, p8, p10 (BP2). The use of backup 356 path BP1 does not cause duplicates. Backup path BP2 would cause 357 duplicates because the local_decap bit for D2 is still set in 358 bitstring at P. Two options exist to avoid duplicates. 360 1. We reset the local_decap bit for D2: This solution prevents the 361 duplicate packet. However, this method can lead to lost packets 362 in other examples. 364 2. We use a tunnel from P to F over D2 to prevent BIER packet 365 processing at the nodes at the backup path. 367 Tunnels may be implemented in these two different ways: 369 1. A remote adjacency represented by a single bit which is a tunnel 370 in the routing underlay. For an MPLS routing underlay, this can 371 be implemented using an MPLS label stack. In the example we 372 would introduce an additional bit,e.g., p11, representing the 373 tunnel. 375 2. BIER-in-BIER encapsulation using an additional BIER header with 376 NextProto = BIER. This methods does not require additional bits 377 for remote adjacencies compared to remote adjacencies but it 378 increases the size of the packet header. In this example the new 379 bitstring contains the bits of BP2 and an additional local_decap 380 bit for BFR7. 382 Now, we consider that BFR7 fails. The backup path must send the 383 packets to all downstream next next-hops (DS-NNHs), i.e. the next- 384 hops of the sub-tree rooted of BFR7. BFR4 can identify the DS-NNHs 385 by checking the bits of interest of the failed node BFR7. BFR6 is 386 such a node because bit p7 is set. BFR9 is not downstream because 387 there is no bit of interest from BFR7 to BFR9. Sending packets to 388 BFR9 would causes duplicates because BFR9 is served using the branch 389 BFR1->BFR5->BFR9. 391 Protection against link failures only requires knowledge of the 392 failed adjacency. Protection against node failures requires 393 additional knowledge of the downstream nodes of the tree. The 394 computation of appropriate backup paths, AddBitmasks, ResetBitmasks, 395 and BitPositions is outside of the scope of this document. 397 3.2. The BIER-TE Adjacency FRR Table (BTAFT) 399 The BIER-TE IF FRR Table exists in every BFR that is supporting BIER- 400 TE FRR. It is indexed by FRR Adjacency Index that is compromised of 401 the SI and the adjacency. Associated with each FRR Adjacency Index 402 are the failed BitPosition (F-BP), Downstream BitPosition (DS-BP), 403 ResetBitmask, and AddBitmask. The table can be configured to enable 404 different actions for the AddBitMask. Either the table is configured 405 to apply BIER-in-BIER encapsulation with a new BIER header containing 406 the AddBitmask as new bitstring or to simply add the bits on the 407 current bitstring. 409 --------------------------------------------------------------------- 410 | FRR Adjacency | Failed | Downstream | ResetBitmask | AddBitmask | 411 | Index | BP | BP | | | 412 ===================================================================== 413 | 0:1 | 5 | 5 | ..0010000 | ..11000000 | 414 --------------------------------------------------------------------- 415 ... 417 An FRR Adjacency is an adjacency that is used in the BIFT of the BFR. 418 The BFR has to be able to determine whether the adjacency is up or 419 down in less than 50msec. An FRR adjacency can be a 420 forward_connected adjacency with fast L2 link state Up/Down state 421 notifications or a forward_connected or forward_routed adjacency with 422 a fast aliveness mechanism such as BFD. Details of those mechanism 423 are outside the scope of this architecture. 425 The FRR Adjacency Index is the index that would be indicated on the 426 fast Up/Down notifications to the BIER-TE forwarding plane and 427 enables the selection of appropriate ResetBitmasks and AddBitmasks. 429 The failed BitPosition is the BP in the BIFT in which the FRR 430 Adjacency is used. The downstream BitPosition is required to protect 431 against node failures to identify the downstream adjacency as 432 described in Section 3.1. The backup path/tree is constructed of the 433 individual ResetBitmasks and AddBitmasks of the downstream nodes. To 434 protect against link failures, the DS-BP field is set equally to the 435 F-BP field. 437 3.3. FRR in BIER-TE Forwarding 439 The BIER-TE forwarding plane receives fast Up/Down notifications of 440 BIER adjacencies which are used for different SIs. From the failed 441 BitPosition in the BTAFT entry, it records which BPs are currently 442 affected (have a down adjacency). 444 When a packet is received, BIER-TE forwarding checks if it has failed 445 BPs and matching downstream BitPositions to which it would forward. 446 If it does, it will remove the ResetBitmask bits from the packets 447 BitString. Depending on the table configuration it will either add 448 the AddBitmask bits to the packets BitString or construct a new BIER 449 header for rerouted packets. Note that the original packet must be 450 still available for non-affected bitpositions. 452 Afterwards, normal BIER-TE forwarding occurs, taking the modified 453 bitstring or the additional BIER header into account. Note that the 454 information is pre-computed by the controller so that the BFR can 455 reroute around a failure immediately after its detection. 457 3.4. FRR in the BIER-TE Controller 459 The basic rules how the BIER-TE controller would calculate the 460 ResetBitmask and the AddBitmask are as follows: 462 1. The BIER-TE controller decides which tunnel mode a BFR uses for 463 the BTAFT: remote adjacencies or BIER-in-BIER tunneling. 465 2. The BIER-TE controller determines whether a failure of the 466 adjacency should be taken to indicate link or node failure. This 467 is a policy decision. 469 3. The ResetBitmask has the BitPosition of the failed adjacency. 471 4. In the case of link protection, the AddBitmask are the segments 472 forming a path from the BFR over to the BFR on the other end of 473 the failed link. The path can be formed using remote adjacencies 474 for tunneling purposes. 476 5. In the case of node protection, the AddBitmask are the segments 477 forming a tree from the BFR over to all necessary downstream BFRs 478 of the (assumed to be failed) BFR across the failed adjacency. 480 6. The ResetBitmask is extended with those segments that could lead 481 to duplicate packets if the AddBitmask is added to possible 482 bitstrings of packets using the failing BitPosition. 484 3.5. BIER-TE FRR Benefits 486 Compared to other FRR solutions, such as RSVP-TE/P2MP FRR, BIER-TE 487 FRR has two key distinctions 489 o It maintains the goal of BIER-TE not to establish in-network per 490 multicast traffic flow state. For that reason, the backup path/ 491 trees are only tied to the topology, but not to individual 492 distribution trees. 494 o For the case of a node failure, it allows to build a path 495 engineered backup tree as opposed to a set of partly overlapping 496 p2p backup tunnels. 498 o BIER-in-BIER encapsulation enables backup tunnels in networks that 499 do not provide a routing layer with tunneling capabilities. It 500 may simplify network management because additional tunnels (such 501 as GRE) do not to be setup in the routing layer. 503 3.6. Adjustment to the BIER-TE Forwarding Pseudocode 505 We augment the forwarding procedure presented in the BIER-TE draft to 506 support FRR. 508 The following procedure computes the ResetBitmasks and AddBitmasks 509 when an adjacency up/down notification is triggered. The masks can 510 later be directly applied to the header to facilitate the backup. 512 global ResetBitMaskByBT[BitStringLength] 513 global AddBitMaskByBT[BitStringLength] 514 global FRRaffectedBP 516 void FrrUpDown(FrrAdjacencyIndex, UpDown) 517 { 518 global FRRAdjacenciesDown 519 local Idx = FrrAdjacencyIndex 521 if (UpDown == Up) 522 FRRAdjacenciesDown &= ~ 2<<(FrrAdjacencyIndex-1) 523 else 524 FRRAdjacenciesDown |= 2<<(FrrAdjacencyIndex-1) 526 for (Index = GetFirstBitPosition(FRRAdjacenciesDown); Index ; 527 Index = GetNextBitPosition(FRRAdjacenciesDown, Index)) 529 local BP = BTAFT[Index].BitPosition 530 FRRaffectedBP |= 2<<(Index) 531 ResetBitMaskByBT[BP] |= BTAFT[Index].ResetBitMask 532 AddBitMaskByBT[BP] |= BTAFT[Index].AddBitMask 533 } 535 The ForwardBierTePacket procedure must be modified by applying the 536 FRR operations when necessary. 538 void ForwardBierTePacket (Packet) 539 { 540 // We calculate in BitMask the subset of BPs of the BitString 541 // for which we have adjacencies. This is purely an 542 // optimization to avoid to replicate for every BP 543 // set in BitString only to discover that for most of them, 544 // the BIFT has no adjacency. 546 local BitMask = Packet->BitString 547 Packet->BitString &= ~MyBitsOfInterest 548 BitMask &= MyBitsOfInterest 550 // FRR Operations 551 // Note: this algorithm is not optimal yet for ECMP cases 552 // it performs FRR replacement for all candidate ECMP paths 554 local MyFRRBP = BitMask & FRRaffectedBP 555 for (BP = GetFirstBitPosition(MyFRRNP); BP ; 556 BP = GetNextBitPosition(MyFRRNP, BP)) 557 BitMask &= ~ResetBitMaskByBT[BP] 558 BitMask |= ResetBitMaskByBT[BP] 560 // Replication 561 for (Index = GetFirstBitPosition(BitMask); Index ; 562 Index = GetNextBitPosition(BitMask, Index)) 563 foreach adjacency BIFT[Index] 565 if(adjacency == ECMP(ListOfAdjacencies, seed) ) 566 I = ECMP_hash(sizeof(ListOfAdjacencies), 567 Packet->Entropy, seed) 568 adjacency = ListOfAdjacencies[I] 570 PacketCopy = Copy(Packet) 572 switch(adjacency) 573 case forward_connected(interface,neighbor,DNR): 574 if(DNR) 575 PacketCopy->BitString |= 2<<(Index-1) 576 SendToL2Unicast(PacketCopy,interface,neighbor) 578 case forward_routed([VRF],neighbor): 579 SendToL3(PacketCopy,[VRF,]l3-neighbor) 581 case local_decap([VRF],neighbor): 582 DecapBierHeader(PacketCopy) 583 PassTo(PacketCopy,[VRF,]Packet->NextProto) 584 } 586 3.7. Recommendations for Tunneling 588 Recommendations for usage of tunnels for BIER-TE FRR based on the 589 study in [BIERFRRANALYSIS]: 591 1. Tunneling SHOULD be used. The study shows that header 592 modification does not improve coverage in many topologies and may 593 cause more harm than protection when node failures occur. 595 2. Using unicast tunnels may cause unnecessary extra load on 596 overlapping links when protecting against node failures. 597 Moreover, they require additional bits in the BIER header. 599 3. BIER-in-BIER encapsulation is the recommended mechanism. It 600 causes increased header overhead through the encapsulating BIER 601 header. This may become an issue when the BIER header supports 602 long bitstrings 604 4. IANA Considerations 606 This document requests no action by IANA. 608 5. Acknowledgements 610 The authors would like to thank Greg Shepherd, Ijsbrand Wijnands and 611 Neale Ranns for their extensive review and suggestions. 613 6. Change log [RFC Editor: Please remove] 615 03: Updated references, no other conent changes from -02. Refresh 616 to continue using this document for reference of new work. 617 Unchanged. Currently unclear if the novel method proposed in this 618 document is worth pursuing. If not, then we would change the 619 document to solely document the applicability of pre-existing 620 methods (and remove new options). 622 02: Overview of FRR mechanisms feasible for BIER-TE (Eckert) 624 02: Removed Section "BIER-TE and existing FRR, because it is now 625 part of "Overview" chapter (Braun) 627 02: Added recommendation on native BIER-TE FRR with regard to 628 tunneling options based on a study (Braun) 630 02: Added P4 implementation of BIER-TE FRR using BIER-in-BIER as 631 reference.(Braun) 633 01: Update of author addresses 634 00: Initial version based on draft-eckert-bier-arch-03. 636 7. References 638 7.1. Normative References 640 [I-D.ietf-bier-te-arch] 641 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 642 Engineering for Bit Index Explicit Replication (BIER-TE)", 643 draft-ietf-bier-te-arch-00 (work in progress), January 644 2018. 646 [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. 647 Decraene, "Multicast-Only Fast Reroute", RFC 7431, 648 DOI 10.17487/RFC7431, August 2015, 649 . 651 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 652 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 653 Explicit Replication (BIER)", RFC 8279, 654 DOI 10.17487/RFC8279, November 2017, 655 . 657 7.2. Informational References 659 [BIER-FRR-P4] 660 Braun, W., Hartmann, J., and M. Menth, "Demo: Scalable and 661 Reliable Software-Defined Multicast with BIER and P4", 662 IFIP/IEEE International Symposium on Integrated Network 663 Management (IM), May 2017, . 666 [BIERFRRANALYSIS] 667 Braun, W., Eckert, T., and M. Menth, "Performance 668 Comparison of Resilience Mechanisms for Stateless 669 Multicast Using BIER", IFIP/IEEE International Symposium 670 on Integrated Network Management (IM), May 2017, 671 . 674 Authors' Addresses 675 Toerless Eckert 676 Huawei USA - Futurewei Technologies Inc. 677 2330 Central Expy 678 Santa Clara 95050 679 USA 681 Email: tte+ietf@cs.fau.de 683 Gregory Cauchie 684 Bouygues Telecom 686 Email: GCAUCHIE@bouyguestelecom.fr 688 Wolfgang Braun 689 University of Tuebingen 691 Email: wolfgang.braun@uni-tuebingen.de 693 Michael Menth 694 University of Tuebingen 696 Email: menth@uni-tuebingen.de