idnits 2.17.1 draft-ietf-bier-te-arch-13.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 2022) is 741 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: '3' on line 1056 -- Looks like a reference, but probably isn't: '2' on line 1065 -- Looks like a reference, but probably isn't: '1' on line 1072 == Missing Reference: 'SI' is mentioned on line 2270, but not defined == Missing Reference: 'I' is mentioned on line 1125, but not defined == Missing Reference: 'VRF' is mentioned on line 2611, but not defined == Unused Reference: 'RFC6241' is defined on line 2837, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 2858, but no explicit reference was found in the text == Unused Reference: 'RFC8040' is defined on line 2867, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-bier-te-yang-04 == Outdated reference: A later version (-27) exists of draft-ietf-teas-rfc3272bis-16 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T.T.E. Eckert, Ed. 3 Internet-Draft Futurewei 4 Intended status: Standards Track M.M. Menth 5 Expires: 27 October 2022 University of Tuebingen 6 G.C. Cauchie 7 KOEVOO 8 April 2022 10 Tree Engineering for Bit Index Explicit Replication (BIER-TE) 11 draft-ietf-bier-te-arch-13 13 Abstract 15 This memo describes per-packet stateless strict and loose path 16 steered replication and forwarding for "Bit Index Explicit 17 Replication" (BIER, RFC8279) packets. It is called BIER Tree 18 Engineering (BIER-TE) and is intended to be used as the path steering 19 mechanism for Traffic Engineering with BIER. 21 BIER-TE introduces a new semantic for "bit positions" (BP). They 22 indicate adjacencies of the network topology, as opposed to (non-TE) 23 BIER in which BPs indicate "Bit-Forwarding Egress Routers" (BFER). A 24 BIER-TE packets BitString therefore indicates the edges of the (loop- 25 free) tree that the packet is forwarded across by BIER-TE. BIER-TE 26 can leverage BIER forwarding engines with little changes. Co- 27 existence of BIER and BIER-TE forwarding in the same domain is 28 possible, for example by using separate BIER "sub-domains" (SDs). 29 Except for the optional routed adjacencies, BIER-TE does not require 30 a BIER routing underlay, and can therefore operate without depending 31 on an "Interior Gateway Routing protocol" (IGP). 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 3 October 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . 5 70 2.2. BIER-TE Topology and adjacencies . . . . . . . . . . . . 8 71 2.3. Relationship to BIER . . . . . . . . . . . . . . . . . . 9 72 2.4. Accelerated/Hardware forwarding comparison . . . . . . . 11 73 3. Components . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.1. The Multicast Flow Overlay . . . . . . . . . . . . . . . 12 75 3.2. The BIER-TE Control Plane . . . . . . . . . . . . . . . . 12 76 3.2.1. The BIER-TE Controller . . . . . . . . . . . . . . . 14 77 3.2.1.1. BIER-TE Topology discovery and creation . . . . . 14 78 3.2.1.2. Engineered Trees via BitStrings . . . . . . . . . 15 79 3.2.1.3. Changes in the network topology . . . . . . . . . 16 80 3.2.1.4. Link/Node Failures and Recovery . . . . . . . . . 16 81 3.3. The BIER-TE Forwarding Plane . . . . . . . . . . . . . . 16 82 3.4. The Routing Underlay . . . . . . . . . . . . . . . . . . 17 83 3.5. Traffic Engineering Considerations . . . . . . . . . . . 17 84 4. BIER-TE Forwarding . . . . . . . . . . . . . . . . . . . . . 18 85 4.1. The BIER-TE Bit Index Forwarding Table (BIFT) . . . . . . 18 86 4.2. Adjacency Types . . . . . . . . . . . . . . . . . . . . . 20 87 4.2.1. Forward Connected . . . . . . . . . . . . . . . . . . 21 88 4.2.2. Forward Routed . . . . . . . . . . . . . . . . . . . 21 89 4.2.3. ECMP . . . . . . . . . . . . . . . . . . . . . . . . 21 90 4.2.4. Local Decap(sulation) . . . . . . . . . . . . . . . . 22 91 4.3. Encapsulation / Co-existence with BIER . . . . . . . . . 22 92 4.4. BIER-TE Forwarding Pseudocode . . . . . . . . . . . . . . 23 93 4.5. BFR Requirements for BIER-TE forwarding . . . . . . . . . 26 94 5. BIER-TE Controller Operational Considerations . . . . . . . . 27 95 5.1. Bit Position Assignments . . . . . . . . . . . . . . . . 27 96 5.1.1. P2P Links . . . . . . . . . . . . . . . . . . . . . . 27 97 5.1.2. BFER . . . . . . . . . . . . . . . . . . . . . . . . 27 98 5.1.3. Leaf BFERs . . . . . . . . . . . . . . . . . . . . . 27 99 5.1.4. LANs . . . . . . . . . . . . . . . . . . . . . . . . 29 100 5.1.5. Hub and Spoke . . . . . . . . . . . . . . . . . . . . 30 101 5.1.6. Rings . . . . . . . . . . . . . . . . . . . . . . . . 30 102 5.1.7. Equal Cost MultiPath (ECMP) . . . . . . . . . . . . . 31 103 5.1.8. Forward Routed adjacencies . . . . . . . . . . . . . 34 104 5.1.8.1. Reducing bit positions . . . . . . . . . . . . . 34 105 5.1.8.2. Supporting nodes without BIER-TE . . . . . . . . 35 106 5.1.9. Reuse of bit positions (without DNC) . . . . . . . . 35 107 5.1.10. Summary of BP optimizations . . . . . . . . . . . . . 36 108 5.2. Avoiding duplicates and loops . . . . . . . . . . . . . . 37 109 5.2.1. Loops . . . . . . . . . . . . . . . . . . . . . . . . 38 110 5.2.2. Duplicates . . . . . . . . . . . . . . . . . . . . . 38 111 5.3. Managing SI, sub-domains and BFR-ids . . . . . . . . . . 39 112 5.3.1. Why SI and sub-domains . . . . . . . . . . . . . . . 39 113 5.3.2. Assigning bits for the BIER-TE topology . . . . . . . 40 114 5.3.3. Assigning BFR-id with BIER-TE . . . . . . . . . . . . 41 115 5.3.4. Mapping from BFR to BitStrings with BIER-TE . . . . . 42 116 5.3.5. Assigning BFR-ids for BIER-TE . . . . . . . . . . . . 43 117 5.3.6. Example bit allocations . . . . . . . . . . . . . . . 43 118 5.3.6.1. With BIER . . . . . . . . . . . . . . . . . . . . 43 119 5.3.6.2. With BIER-TE . . . . . . . . . . . . . . . . . . 44 120 5.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 45 121 6. Security Considerations . . . . . . . . . . . . . . . . . . . 46 122 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 123 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 124 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 48 125 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 126 10.1. Normative References . . . . . . . . . . . . . . . . . . 61 127 10.2. Informative References . . . . . . . . . . . . . . . . . 61 128 Appendix A. BIER-TE and Segment Routing (SR) . . . . . . . . . . 64 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 131 1. Overview 133 BIER-TE is based on the (non-TE) BIER architecture, terminology and 134 packet formats as described in [RFC8279] and [RFC8296]. This 135 document describes BIER-TE in the expectation that the reader is 136 familiar with these two documents. 138 BIER-TE introduces a new semantic for "bit positions" (BP). They 139 indicate adjacencies of the network topology, as opposed to (non-TE) 140 BIER in which BPs indicate "Bit-Forwarding Egress Routers" (BFER). A 141 BIER-TE packets BitString therefore indicates the edges of the (loop- 142 free) tree that the packet is forwarded across by BIER-TE. With 143 BIER-TE, the "Bit Index Forwarding Table" (BIFT) of each "Bit 144 Forwarding Router" (BFR) is only populated with BP that are adjacent 145 to the BFR in the BIER-TE Topology. Other BPs are empty in the BIFT. 147 The BFR replicate and forwards BIER packets to adjacent BPs that are 148 set in the packet. BPs are normally also cleared upon forwarding to 149 avoid duplicates and loops. 151 BIER-TE can leverage BIER forwarding engines with little or no 152 changes. It can also co-exist with BIER forwarding in the same 153 domain, for example by using separate BIER sub-domains. Except for 154 the optional routed adjacencies, BIER-TE does not require a BIER 155 routing underlay, and can therefore operate without depending on an 156 "Interior Gateway Routing protocol" (IGP). 158 This document is structured as follows: 160 * Section 2 introduces BIER-TE with two forwarding examples, 161 followed by an introduction of the new concepts of the BIER-TE 162 (overlay) topology and finally a summary of the relationship 163 between BIER and BIER-TE and a discussion of accelerated hardware 164 forwarding. 166 * Section 3 describes the components of the BIER-TE architecture, 167 Flow overlay, BIER-TE layer with the BIER-TE control plane 168 (including the BIER-TE controller) and BIER-TE forwarding plane, 169 and the routing underlay. 171 * Section 4 specifies the behavior of the BIER-TE forwarding plane 172 with the different type of adjacencies and possible variations of 173 BIER-TE forwarding pseudocode, and finally the mandatory and 174 optional requirements. 176 * Section 5 describes operational considerations for the BIER-TE 177 controller, foremost how the BIER-TE controller can optimize the 178 use of BP by using specific type of BIER-TE adjacencies for 179 different type of topological situations, but also how to assign 180 bits to avoid loops and duplicates (which in BIER-TE does not come 181 for free), and finally how "Set Identifier" (SI), "sub-domain" 182 (SD) and BFR-ids can be managed by a BIER-TE controller, examples 183 and summary. 185 * Appendix A concludes the technology specific sections of the 186 document by further relating BIER-TE to Segment Routing (SR). 188 Note that related work, [I-D.ietf-roll-ccast] uses Bloom filters 189 [Bloom70] to represent leaves or edges of the intended delivery tree. 190 Bloom filters in general can support larger trees/topologies with 191 fewer addressing bits than explicit BitStrings, but they introduce 192 the heuristic risk of false positives and cannot clear bits in the 193 BitString during forwarding to avoid loops. For these reasons, BIER- 194 TE uses explicit BitStrings like BIER. The explicit BitStrings of 195 BIER-TE can also be seen as a special type of Bloom filter, and this 196 is how related work [ICC] describes it. 198 1.1. Requirements Language 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL" in this document are to be interpreted as described in BCP 203 14 [RFC2119] [RFC8174] when, and only when, they appear in all 204 capitals, as shown here. 206 2. Introduction 208 2.1. Basic Examples 210 BIER-TE forwarding is best introduced with simple examples. These 211 examples use formal terms defined later in the document (Figure 4), 212 including forward_connected(), forward_routed() and local_decap(). 214 BIER-TE Topology: 216 Diagram: 218 p5 p6 219 --- BFR3 --- 220 p3/ p13 \p7 p15 221 BFR1 ---- BFR2 BFR5 ----- BFR6 222 p1 p2 p4\ p14 /p10 p11 p12 223 --- BFR4 --- 224 p8 p9 226 (simplified) BIER-TE Bit Index Forwarding Tables (BIFT): 228 BFR1: p1 -> local_decap() 229 p2 -> forward_connected() to BFR2 231 BFR2: p1 -> forward_connected() to BFR1 232 p5 -> forward_connected() to BFR3 233 p8 -> forward_connected() to BFR4 235 BFR3: p3 -> forward_connected() to BFR2 236 p7 -> forward_connected() to BFR5 237 p13 -> local_decap() 239 BFR4: p4 -> forward_connected() to BFR2 240 p10 -> forward_connected() to BFR5 241 p14 -> local_decap() 243 BFR5: p6 -> forward_connected() to BFR3 244 p9 -> forward_connected() to BFR4 245 p12 -> forward_connected() to BFR6 247 BFR6: p11 -> forward_connected() to BFR5 248 p15 -> local_decap() 250 Figure 1: BIER-TE basic example 252 Consider the simple network in the above BIER-TE overview example 253 picture with 6 BFRs. p1...p15 are the bit positions used. All BFRs 254 can act as an ingress BFR (BFIR), BFR1, BFR3, BFR4 and BFR6 can also 255 be BFERs. Forward_connected() is the name for adjacencies that are 256 representing subnet adjacencies of the network. Local_decap() is the 257 name of the adjacency to decapsulate BIER-TE packets and pass their 258 payload to higher layer processing. 260 Assume a packet from BFR1 should be sent via BFR4 to BFR6. This 261 requires a BitString (p2,p8,p10,p12,p15). When this packet is 262 examined by BIER-TE on BFR1, the only bit position from the BitString 263 that is also set in the BIFT is p2. This will cause BFR1 to send the 264 only copy of the packet to BFR2. Similarly, BFR2 will forward to 265 BFR4 because of p8, BFR4 to BFR5 because of p10 and BFR5 to BFR6 266 because of p12. p15 finally makes BFR6 receive and decapsulate the 267 packet. 269 To send a copy to BFR6 via BFR4 and also a copy to BFR3, the 270 BitString needs to be (p2,p5,p8,p10,p12,p13,p15). When this packet 271 is examined by BFR2, p5 causes one copy to be sent to BFR3 and p8 one 272 copy to BFR4. When BFR3 receives the packet, p13 will cause it to 273 receive and decapsulate the packet. 275 If instead the BitString was (p2,p6,p8,p10,p12,p13,p15), the packet 276 would be copied by BFR5 towards BFR3 because of p6 instead of being 277 copied by BFR2 to BFR3 because of p5 in the prior case. This is 278 showing the ability of the shown BIER-TE Topology to make the traffic 279 pass across any possible path and be replicated where desired. 281 BIER-TE has various options to minimize BP assignments, many of which 282 are based on out-of-band knowledge about the required multicast 283 traffic paths and bandwidth consumption in the network, such as from 284 pre-deployment planning. 286 Figure 2 shows a modified example, in which Rtr2 and Rtr5 are assumed 287 not to support BIER-TE, so traffic has to be unicast encapsulated 288 across them. To emphasize non-L2, but routed/tunneled forwarding of 289 BIER-TE packets, these adjacencies are called "forward_routed". 290 Otherwise, there is no difference in their processing over the 291 aforementioned forward_connected() adjacencies. 293 In addition, bits are saved in the following example by assuming that 294 BFR1 only needs to be BFIR but not BFER or transit BFR. 296 BIER-TE Topology: 298 Diagram: 300 p1 p3 p7 301 ....> BFR3 <.... p5 302 ........ ........> 303 BFR1 (Rtr2) (Rtr5) BFR6 304 ........ ........> p9 305 ....> BFR4 <.... p6 306 p2 p4 p8 308 (simplified) BIER-TE Bit Index Forwarding Tables (BIFT): 310 BFR1: p1 -> forward_routed() to BFR3 311 p2 -> forward_routed() to BFR4 313 BFR3: p3 -> local_decap() 314 p5 -> forward_routed() to BFR6 316 BFR4: p4 -> local_decap() 317 p6 -> forward_routed() to BFR6 319 BFR6: p7 -> forward_routed() to BFR3 320 p8 -> forward_routed() to BFR4 321 p9 -> local_decap() 323 Figure 2: BIER-TE basic overlay example 325 To send a BIER-TE packet from BFR1 via BFR3 to be received by BFR6, 326 the BitString is (p1,p5,p9). From BFR1 via BFR4 to be received by 327 BFR6, the BitString is (p2,p6,p9). A packet from BFR1 to be received 328 by BFR3,BFR4 and from BFR3 to be received by BFR6 uses 329 (p1,p2,p3,p4,p5,p9). A packet from BFR1 to be received by BFR3,BFR4 330 and from BFR4 to be received by BFR6 uses (p1,p2,p3,p4,p6,p9). A 331 packet from BFR1 to be received by BFR4, and from BFR4 to be received 332 by BFR6 and from there to be received by BFR3 uses 333 (p2,p3,p4,p6,p7,p9). A packet from BFR1 to be received by BFR3, and 334 from BFR3 to be received by BFR6 there to be received by BFR4 uses 335 (p1,p3,p4,p5,p8,p9). 337 2.2. BIER-TE Topology and adjacencies 339 The key new component in BIER-TE compared to (non-TE) BIER is the 340 BIER-TE topology as introduced through the two examples in 341 Section 2.1. It is used to control where replication can or should 342 happen and how to minimize the required number of BP for adjacencies. 344 The BIER-TE Topology consists of the BIFTs of all the BFR and can 345 also be expressed as a directed graph where the edges are the 346 adjacencies between the BFRs labelled with the BP used for the 347 adjacency. Adjacencies are naturally unidirectional. BP can be 348 reused across multiple adjacencies as long as this does not lead to 349 undesired duplicates or loops as explained in Section 5.2. 351 If the BIER-TE topology represents (a subset of) the underlying 352 (layer 2) topology of the network as shown in the first example, this 353 may be called a "native" BIER-TE topology. A topology consisting 354 only of "forward_routed" adjacencies as shown in the second example 355 may be called an "overlay" BIER-TE topology. A BIER-TE topology with 356 both forward_connected() and forward_routed() adjacencies may be 357 called a "hybrid" BIER-TE topology. 359 2.3. Relationship to BIER 361 BIER-TE is designed so that its forwarding plane is a simple 362 extension to the (non-TE) BIER forwarding plane, hence allowing for 363 it to be added to BIER deployments where it can be beneficial. 365 BIER-TE is also intended as an option to expand the BIER architecture 366 into deployments where (non-TE) BIER may not be the best fit, such as 367 statically provisioned networks with needs for path steering but 368 without desire for distributed routing protocols. 370 1. BIER-TE inherits the following aspects from BIER unchanged: 372 1. The fundamental purpose of per-packet signaled replication 373 and delivery via a BitString. 375 2. The overall architecture consisting of three layers, flow 376 overlay, BIER(-TE) layer and routing underlay. 378 3. The supported encapsulations [RFC8296]. 380 4. The semantic of all [RFC8296] header elements used by the 381 BIER-TE forwarding plane other than the semantic of the BP in 382 the BitString. 384 5. The BIER forwarding plane, except for how bits have to be 385 cleared during replication. 387 2. BIER-TE has the following key changes with respect to BIER: 389 1. In BIER, bits in the BitString of a BIER packet header 390 indicate a BFER and bits in the BIFT indicate the BIER 391 control plane calculated next-hop toward that BFER. In BIER- 392 TE, a bit in the BitString of a BIER packet header indicates 393 an adjacency in the BIER-TE topology, and only the BFR that 394 is the upstream of that adjacency has its BP populated with 395 the adjacency in its BIFT. 397 2. In BIER, the implied reference options for the core part of 398 the BIER layer control plane are the BIER extensions for 399 distributed routing protocols. This includes ISIS/OSPF 400 extensions for BIER, [RFC8401] and [RFC8444]. 402 3. The reference option for the core part of the BIER-TE control 403 plane is the BIER-TE controller. Nevertheless, both the BIER 404 and BIER-TE BIFTs forwarding plane state could equally be 405 populated by any mechanism. 407 4. Assuming the reference options for the control plane, BIER-TE 408 replaces in-network autonomous path calculation by explicit 409 paths calculated by the BIER-TE controller. 411 3. The following elements/functions described in the BIER 412 architecture are not required by the BIER-TE architecture: 414 1. "Bit Index Routing Tables" (BIRTs) are not required on BFRs 415 for BIER-TE when using a BIER-TE controller because the 416 controller can directly populate the BIFTs. In BIER, BIRTs 417 are populated by the distributed routing protocol support for 418 BIER, allowing BFRs to populate their BIFTs locally from 419 their BIRTs. Other BIER-TE control plane or management plane 420 options may introduce requirements for BIRTs for BIER-TE 421 BFRs. 423 2. The BIER-TE layer forwarding plane does not require BFRs to 424 have a unique BP and therefore also no unique BFR-id. See 425 Section 5.1.3. 427 3. Identification of BFRs by the BIER-TE control plane is 428 outside the scope of this specification. Whereas the BIER 429 control plane uses BFR-ids in its BFR to BFR signaling, a 430 BIER-TE controller may choose any form of identification 431 deemed appropriate. 433 4. BIER-TE forwarding does not require the BFIR-id field of the 434 BIER packet header. 436 4. Co-existence of BIER and BIER-TE in the same network requires the 437 following: 439 1. The BIER/BIER-TE packet header needs to allow addressing both 440 BIER and BIER-TE BIFTs. Depending on the encapsulation 441 option, the same SD may or may not be reusable across BIER 442 and BIER-TE. See Section 4.3. In either case, a packet is 443 always only forwarded end-to-end via BIER or via BIER-TE 444 (ships in the nights forwarding). 446 2. BIER-TE deployments will have to assign BFR-ids to BFRs and 447 insert them into the BFIR-id field of BIER packet headers as 448 BIER does, whenever the deployment uses (unchanged) 449 components developed for BIER that use BFR-id, such as 450 multicast flow overlays or BIER layer control plane elements. 451 See also Section 5.3.3. 453 2.4. Accelerated/Hardware forwarding comparison 455 BIER-TE forwarding rules, especially the BitString parsing are 456 designed to be as close as possible to those of BIER in the 457 expectation that this eases the programming of BIER-TE forwarding 458 code and/or BIER-TE forwarding hardware on platforms supporting BIER. 459 The pseudocode in Section 4.4 shows how existing (non-TE) BIER/BIFT 460 forwarding can be modified to support the required BIER-TE forwarding 461 functionality (Section 4.5), by using BIER BIFT's "Forwarding Bit 462 Mask" (F-BM): Only the clearing of bits to avoid duplicate packets to 463 a BFR's neighbor is skipped in BIER-TE forwarding because it is not 464 necessary and could not be done when using BIER F-BM. 466 Whether to use BIER or BIER-TE forwarding is simply a choice of the 467 mode of the BIFT indicated by the packet (BIER or BIER-TE BIFT). 468 This is determined by the BFR configuration for the encapsulation, 469 see Section 4.3. 471 3. Components 473 BIER-TE can be thought of being constituted from the same three 474 layers as BIER: The "multicast flow overlay", the "BIER layer" and 475 the "routing underlay". The following picture also shows how the 476 "BIER layer" is constituted from the "BIER-TE forwarding plane" and 477 the "BIER-TE control plane" represent by the "BIER-TE Controller". 479 <------BGP/PIM-----> 480 |<-IGMP/PIM-> multicast flow <-PIM/IGMP->| 481 overlay 483 BIER-TE [BIER-TE Controller] <=> [BIER-TE Topology] 484 control ^ ^ ^ 485 plane / | \ BIER-TE control protocol 486 | | | e.g. YANG/NETCONF/RESTCONF 487 | | | PCEP/... 488 v v v 489 Src -> Rtr1 -> BFIR-----BFR-----BFER -> Rtr2 -> Rcvr 491 |<----------------->| 492 BIER-TE forwarding plane 494 |<- BIER-TE domain->| 496 |<--------------------->| 497 Routing underlay 499 Figure 3: BIER-TE architecture 501 3.1. The Multicast Flow Overlay 503 The Multicast Flow Overlay has the same role as described for BIER in 504 [RFC8279], Section 4.3. See also Section 3.2.1.2. 506 When a BIER-TE controller is used, then the signaling for the 507 Multicast Flow Overlay may also be preferred to operate through a 508 central point of control. For BGP based overlay flow services such 509 as "Multicast VPN Using BIER" ([RFC8556]) this can be achieved by 510 making the BIER-TE controller operate as a BGP Route Reflector 511 ([RFC4456]) and combining it with signaling through BGP or a 512 different protocol for the BIER-TE controller calculated BitStrings. 513 See Section 3.2.1.2 and Section 5.3.4. 515 3.2. The BIER-TE Control Plane 517 In the (non-TE) BIER architecture [RFC8279], the BIER control plane 518 is not explicitly separated from the BIER forwarding plane, but 519 instead their functions are summarized together in Section 4.2. 520 Example standardized options for the BIER control plane include ISIS/ 521 OSPF extensions for BIER, [RFC8401] and [RFC8444]. 523 For BIER-TE, the control plane includes at minimum the following 524 functionality. 526 1. BIER-TE topology control: During initial provisioning of the 527 network and/or during modifications of its topology and/or 528 services, the protocols and/or procedures to establish BIER-TE 529 BIFTs: 531 1. Determine the desired BIER-TE topology for a BIER-TE sub- 532 domains: the native and/or overlay adjacencies that are 533 assigned to BPs. Topology discovery is discussed in 534 Section 3.2.1.1 and the various aspects of the BIER-TE 535 controllers determinations about the topology are discussed 536 throughout Section 5 538 2. Determine the per-BFR BIFT from the BIER-TE topology. This is 539 achieved by simply extracting the adjacencies of the BFR from 540 the BIER-TE topology and populating the BFRs BIFT with them. 542 3. Optionally assign BFR-ids to BFIRs for later insertion into 543 BIER headers on BFIRs as BFIR-id. Alternatively, BFIR-id in 544 BIER packet headers may be managed solely by the flow overlay 545 layer and/or be unused. This is discussed in Section 5.3.3. 547 4. Install/update the BIFTs into the BFRs and optionally BFR-ids 548 into BFIRs. This is discussed in Section 3.2.1.1. 550 2. BIER-TE tree control: During operations of the network, 551 protocols and/or procedures to support creation/change/removal of 552 overlay flows on BFIRs: 554 1. Process the BIER-TE requirements for the multicast overlay 555 flow: BFIR and BFERs of the flow as well as policies for the 556 path selection of the flow. This is discussed in Section 3.5. 558 2. Determine the BitStrings and optionally Entropy. This is 559 discussed in Section 3.2.1.2, Section 3.5 and Section 5.3.4. 561 3. Install state on the BFIR to impose the desired BIER packet 562 header(s) for packets of the overlay flow. Different aspects 563 of this and the next point are discussed throughout 564 Section 3.2.1 and in Section 4.3, but the main responsibility 565 of these two points is with the Multicast Flow Overlay 566 (Section 3.1), which is architecturally inherited from BIER. 568 4. Install the necessary state on the BFERs to decapsulate the 569 BIER packet header and properly dispatch its payload. 571 3.2.1. The BIER-TE Controller 573 [RFC-Editor: the following text has three references to anchors 574 topology-control, topology-control-1 and tree-control. 575 Unfortunately, XMLv2 does not offer any tagging that reasonable 576 references are generated (i had this problem already in RFCs last 577 year. Please make sure there are useful-to-read cross-references in 578 the RFC in these three places after you convert to XMLv3.] 580 This architecture describes the BIER-TE control plane as shown in 581 Figure 3 to consist of: 583 * A BIER-TE controller. 585 * BFR data-models and protocols to communicate between controller 586 and BFRs in support of BIER-TE topology control (Section 3.2), 587 such as YANG/NETCONF/RESTCONF ([RFC7950]/[RFC6241]/[RFC8040]). 589 * BFR data-models and protocols to communicate between controller 590 and BFIR in support of BIER-TE tree control (Section 3.2), such as 591 BIER-TE extensions for [RFC5440]. 593 The single, centralized BIER-TE controller is used in this document 594 as reference option for the BIER-TE control plane but other options 595 are equally feasible. The BIER-TE control plane could equally be 596 implemented without automated configuration/protocols, by an operator 597 via CLI on the BFRs. In that case, operator configured local policy 598 on the BFIR would have to determine how to set the appropriate BIER 599 header fields. The BIER-TE control plane could also be decentralized 600 and/or distributed, but this document does not consider any 601 additional protocols and/or procedures which would then be necessary 602 to coordinate its (distributed/decentralized) entities to achieve the 603 above described functionality. 605 3.2.1.1. BIER-TE Topology discovery and creation 607 The first item of BIER-TE topology control (Section 3.2, Paragraph 3, 608 Item 2.2.1) includes network topology discovery and BIER-TE topology 609 creation. The latter describes the process by which a Controller 610 determines which routers are to be configured as BFRs and the 611 adjacencies between them. 613 In statically managed networks, such as in industrial environments, 614 both discovery and creation can be a manual/offline process. 616 In other networks, topology discovery may rely on protocols including 617 extending a "Link-State-Protocol" based IGP into the BIER-TE 618 controller itself, [RFC7752] (BGP-LS) or [RFC8345] (YANG topology) as 619 well as BIER-TE specific methods, for example via 620 [I-D.ietf-bier-te-yang]. These options are non-exhaustive. 622 Dynamic creation of the BIER-TE topology can be as easy as mapping 623 the network topology 1:1 to the BIER-TE topology by assigning a BP 624 for every network subnet adjacency. In larger networks, it likely 625 involves more complex policy and optimization decisions including how 626 to minimize the number of BPs required and how to assign BPs across 627 different BitStrings to minimize the number of duplicate packets 628 across links when delivering an overlay flow to BFER using different 629 SIs/BitStrings. These topics are discussed in Section 5. 631 When the BIER-TE topology is determined, the BIER-TE Controller then 632 pushes the BitPositions/adjacencies to the BIFT of the BFRs. On each 633 BFR only those SI:BitPositions are populated that are adjacencies to 634 other BFRs in the BIER-TE topology. 636 Communications between the BIER-TE Controller and BFRs for both BIER- 637 TE topology control and BIER-TE tree control is ideally via 638 standardized protocols and data-models such as NETCONF/RESTCONF/YANG/ 639 PCEP. Vendor-specific CLI on the BFRs is also an option (as in many 640 other SDN solutions lacking definition of standardized data models). 642 3.2.1.2. Engineered Trees via BitStrings 644 In BIER, the same set of BFER in a single sub-domain is always 645 encoded as the same BitString. In BIER-TE, the BitString used to 646 reach the same set of BFER in the same sub-domain can be different 647 for different overlay flows because the BitString encodes the paths 648 towards the BFER, so the BitStrings from different BFIR to the same 649 set of BFER will often be different. Likewise, the BitString from 650 the same BFIR to the same set of BFER can be different for different 651 overlay flows for policy reasons such as shortest path trees, Steiner 652 trees (minimum cost trees), diverse path trees for redundancy and so 653 on. 655 See also [I-D.ietf-bier-multicast-http-response] for an application 656 leveraging BIER-TE engineered trees. 658 3.2.1.3. Changes in the network topology 660 If the network topology changes (not failure based) so that 661 adjacencies that are assigned to bit positions are no longer needed, 662 the BIER-TE Controller can re-use those bit positions for new 663 adjacencies. First, these bit positions need to be removed from any 664 BFIR flow state and BFR BIFT state, then they can be repopulated, 665 first into BIFT and then into the BFIR. 667 3.2.1.4. Link/Node Failures and Recovery 669 When link or nodes fail or recover in the topology, BIER-TE could 670 quickly respond with FRR procedures such as [I-D.eckert-bier-te-frr], 671 the details of which are out of scope for this document. It can also 672 more slowly react by recalculating the BitStrings of affected 673 multicast flows. This reaction is slower than the FRR procedure 674 because the BIER-TE Controller needs to receive link/node up/down 675 indications, recalculate the desired BitStrings and push them down 676 into the BFIRs. With FRR, this is all performed locally on a BFR 677 receiving the adjacency up/down notification. 679 3.3. The BIER-TE Forwarding Plane 681 [RFC-editor Q: "is constituted from" / "consists of" / "composed 682 from..." ???] 684 The BIER-TE Forwarding Plane is constituted from the following 685 components: 687 1. On a BFIR, imposition of the BIER header for packets from overlay 688 flows. This is driven by a combination of state established by 689 the BIER-TE control plane and/or the multicast flow overlay as 690 explained in Section 3.1. 692 2. On BFRs (including BFIR and BFER), forwarding/replication of BIER 693 packets according to their SD, SI, "BitStringLength" (BSL), 694 BitString and optionally Entropy fields as explained in 695 Section 4. Processing of other BIER header fields such as DSCP 696 is outside the scope of this document. 698 3. On BFERs, removal of the BIER header and dispatching of the 699 payload according to state created by the BIER-TE control plane 700 and/or overlay layer. 702 When the BIER-TE Forwarding Plane receives a packet, it simply looks 703 up the bit positions that are set in the BitString of the packet in 704 the BIFT that was populated by the BIER-TE Controller. For every BP 705 that is set in the BitString, and that has one or more adjacencies in 706 the BIFT, a copy is made according to the type of adjacencies for 707 that BP in the BIFT. Before sending any copy, the BFR clears all BPs 708 in the BitString of the packet for which the BFR has one or more 709 adjacencies in the BIFT. Clearing these bits inhibits packets from 710 looping when the BitStrings erroneously includes a forwarding loop. 711 When a forward_connected() adjacency has the "DoNotClear" (DNC) flag 712 set, then this BP is re-set for the packet copied to that adjacency. 713 See Section 4.2.1. 715 3.4. The Routing Underlay 717 For forward_connected() adjacencies, BIER-TE is sending BIER packets 718 to directly connected BIER-TE neighbors as L2 (unicasted) BIER 719 packets without requiring a routing underlay. For forward_routed() 720 adjacencies, BIER-TE forwarding encapsulates a copy of the BIER 721 packet so that it can be delivered by the forwarding plane of the 722 routing underlay to the routable destination address indicated in the 723 adjacency. See Section 4.2.2 for the adjacency definition. 725 BIER relies on the routing underlay to calculate paths towards BFERs 726 and derive next-hop BFR adjacencies for those paths. This commonly 727 relies on BIER specific extensions to the routing protocols of the 728 routing underlay but may also be established by a controller. In 729 BIER-TE, the next-hops of a packet are determined by the BitString 730 through the BIER-TE Controller established adjacencies on the BFR for 731 the BPs of the BitString. There is thus no need for BFR specific 732 routing underlay extensions to forward BIER packets with BIER-TE 733 semantics. 735 Encapsulation parameters can be provisioned by the BIER-TE controller 736 into the forward_connected() or forward_routed() adjacencies directly 737 without relying on a routing underlay. 739 If the BFR intends to support FRR for BIER-TE, then the BIER-TE 740 forwarding plane needs to receive fast adjacency up/down 741 notifications: Link up/down or neighbor up/down, e.g. from BFD. 742 Providing these notifications is considered to be part of the routing 743 underlay in this document. 745 3.5. Traffic Engineering Considerations 747 Traffic Engineering ([I-D.ietf-teas-rfc3272bis]) provides performance 748 optimization of operational IP networks while utilizing network 749 resources economically and reliably. The key elements needed to 750 effect TE are policy, path steering and resource management. These 751 elements require support at the control/controller level and within 752 the forwarding plane. 754 Policy decisions are made within the BIER-TE control plane, i.e., 755 within BIER-TE Controllers. Controllers use policy when composing 756 BitStrings and BFR BIFT state. The mapping of user/IP traffic to 757 specific BitStrings/BIER-TE flows is made based on policy. The 758 specific details of BIER-TE policies and how a controller uses them 759 are out of scope of this document. 761 Path steering is supported via the definition of a BitString. 762 BitStrings used in BIER-TE are composed based on policy and resource 763 management considerations. For example, when composing BIER-TE 764 BitStrings, a Controller must take into account the resources 765 available at each BFR and for each BP when it is providing 766 congestion-loss-free services such as Rate Controlled Service 767 Disciplines [RCSD94]. Resource availability could be provided for 768 example via routing protocol information, but may also be obtained 769 via a BIER-TE control protocol such as NETCONF or any other protocol 770 commonly used by a Controller to understand the resources of the 771 network it operates on. The resource usage of the BIER-TE traffic 772 admitted by the BIER-TE controller can be solely tracked on the BIER- 773 TE Controller based on local accounting as long as no 774 forward_routed() adjacencies are used (see Section 4.2.1 for the 775 definition of forward_routed() adjacencies). When forward_routed() 776 adjacencies are used, the paths selected by the underlying routing 777 protocol need to be tracked as well. 779 Resource management has implications on the forwarding plane beyond 780 the BIER-TE defined steering of packets. This includes allocation of 781 buffers to guarantee the worst case requirements of admitted RCSD 782 traffic and potentially policing and/or rate-shaping mechanisms, 783 typically done via various forms of queuing. This level of resource 784 control, while optional, is important in networks that wish to 785 support congestion management policies to control or regulate the 786 offered traffic to deliver different levels of service and alleviate 787 congestion problems, or those networks that wish to control latencies 788 experienced by specific traffic flows. 790 4. BIER-TE Forwarding 792 4.1. The BIER-TE Bit Index Forwarding Table (BIFT) 794 The BIER-TE BIFT is the equivalent to the BIER BIFT for (non-TE) 795 BIER. It exists on every BFR running BIER-TE. For every BIER sub- 796 domain (SD) in use for BIER-TE, it is a table as shown shown in 797 Figure 4. That example BIFT assumes a BSL of 8 bit positions (BPs) 798 in the packets BitString. As in [RFC8279] this BSL is purely used 799 for the example and not a BIER/BIER-TE supported BSL (minimum BSL is 800 64). 802 A BIER-TE BIFT compares to a BIER BIFT as shown in [RFC8279] as 803 follows. 805 In both BIER and BIER-TE, BIFT rows/entries are indexed in their 806 respective BIER pseudocode ([RFC8279] Section 6.5) and BIER-TE 807 pseudocode (Section 4.4) by the BIFT-index derived from the packets 808 SI, BSL and the one bit position of the packets BitString (BP) 809 addressing the BIFT row: BIFT-index = SI * BSL + BP - 1. BP within a 810 BitString are numbered from 1 to BSL, hence the - 1 offset when 811 converting to a BIFT-index. This document also uses the notion SI:BP 812 to indicate BIFT rows, [RFC8279] uses the equivalent notion 813 SI:BitString, where the BitString is filled with only the BP for the 814 BIFT row. 816 In BIER, each BIFT-index addresses one BFER by its BFR-id = BIFT- 817 index + 1 and is populated on each BFR with the next-hop "BFR 818 Neighbor" (BFR-NBR) towards that BFER. 820 In BIER-TE, each BIFT-index and therefore SI:BP indicates one or more 821 adjacencies between BFRs in the topology and is only populated with 822 those adjacencies forwarding entries on the BFR that is the upstream 823 for these adjacencies. The BIFT entry are empty on all other BFRs. 825 In BIER, each BIFT row also requires a "Forwarding Bit Mask" (F-BM) 826 entry for BIER forwarding rules. In BIER-TE forwarding, F-BM is not 827 required, but can be used when implementing BIER-TE on forwarding 828 hardware derived from BIER forwarding, that must use F-BM. This is 829 discussed in the first BIER-TE forwarding pseudocode in Section 4.4. 831 ------------------------------------------------------------------ 832 | BIFT-index | | Adjacencies: | 833 | (SI:BP) |(FBM)| or one or more per entry | 834 ================================================================== 835 | BIFT indices for Packets with SI=0 | 836 ------------------------------------------------------------------ 837 | 0 (0:1) | ... | forward_connected(interface,neighbor{,DNC}) | 838 ------------------------------------------------------------------ 839 | 1 (0:2) | ... | forward_connected(interface,neighbor{,DNC}) | 840 | | ... | forward_connected(interface,neighbor{,DNC}) | 841 ------------------------------------------------------------------ 842 | ... | ... | ... | 843 ------------------------------------------------------------------ 844 | 4 (0:5) | ... | local_decap({VRF}) | 845 ------------------------------------------------------------------ 846 | 5 (0:6) | ... | forward_routed({VRF,}l3-neighbor) | 847 ------------------------------------------------------------------ 848 | 6 (0:7) | ... | | 849 ------------------------------------------------------------------ 850 | 7 (0:8) | ... | ECMP((adjacency1,...adjacencyN){,seed}) | 851 ----------------------------------------------------------------- 852 | BIFT indices for BitString/Packet with SI=1 | 853 ------------------------------------------------------------------ 854 | 9 (1:1) | | ... | 855 | ... |... | ... | 856 ------------------------------------------------------------------ 857 BIER-TE Bit Index Forwarding Table (BIFT) 859 Figure 4: BIER-TE BIFT with different adjacencies 861 The BIFT is configured for the BIER-TE data plane of a BFR by the 862 BIER-TE Controller through an appropriate protocol and data-model. 863 The BIFT is then used to forward packets, according to the rules 864 specified in the BIER-TE Forwarding Procedures. 866 Note that a BIFT index (SI:BP) may be populated in the BIFT of more 867 than one BFR to save BPs. See Section 5.1.6 for an example of how a 868 BIER-TE controller could assign BPs to (logical) adjacencies shared 869 across multiple BFRs, Section 5.1.3 for an example of assigning the 870 same BP to different adjacencies, and Section 5.1.9 for general 871 guidelines regarding re-use of BPs across different adjacencies. 873 {VRF} indicates the Virtual Routing and Forwarding context into which 874 the BIER payload is to be delivered. This is optional and depends on 875 the multicast flow overlay. 877 4.2. Adjacency Types 878 4.2.1. Forward Connected 880 A "forward_connected()" adjacency is towards a directly connected BFR 881 neighbor using an interface address of that BFR on the connecting 882 interface. A forward_connected() adjacency does not route packets 883 but only L2 forwards them to the neighbor. 885 Packets sent to an adjacency with "DoNotClear" (DNC) set in the BIFT 886 MUST NOT have the bit position for that adjacency cleared when the 887 BFR creates a copy for it. The bit position will still be cleared 888 for copies of the packet made towards other adjacencies. This can be 889 used for example in ring topologies as explained in Section 5.1.6. 891 For protection against loops from misconfiguration (see 892 Section 5.2.1), DNC is only permissible for forward_connected() 893 adjacencies. No need or benefit of DNC for other type of adjacencies 894 was identified and their risk was not analyzed. 896 4.2.2. Forward Routed 898 A "forward_routed()" adjacency is an adjacency towards a BFR that 899 uses a (tunneling) encapsulation which will cause the packet to be 900 forwarded by the routing underlay toward the adjacent BFR. This can 901 leverage any feasible encapsulation, such as MPLS or tunneling over 902 IP/IPv6, as long as the BIER-TE packet can be identified as a 903 payload. This identification can either rely on the BIER/BIER-TE co- 904 existence mechanisms described in Section 4.3, or by explicit support 905 for a BIER-TE payload type in the tunneling encapsulation. 907 forward_routed() adjacencies are necessary to pass BIER-TE traffic 908 across non BIER-TE capable routers or to minimize the number of 909 required BP by tunneling over (BIER-TE capable) routers on which 910 neither replication nor path-steering is desired, or simply to 911 leverage path redundancy and FRR of the routing underlay towards the 912 next BFR. They may also be useful to a multi-subnet adjacent BFR to 913 leverage the routing underlay ECMP independent of BIER-TE ECMP 914 (Section 4.2.3). 916 4.2.3. ECMP 918 (non-TE) BIER ECMP is tied to the BIER BIFT processing semantic and 919 is therefore not directly usable with BIER-TE. 921 A BIER-TE "Equal Cost Multipath" (ECMP()) adjacency as shown in 922 Figure 4 for BIFT-index 7 has a list of two or more non-ECMP 923 adjacencies as parameters and an optional seed parameter. When a 924 BIER-TE packet is copied onto such an ECMP() adjacency, an 925 implementation specific so-called hash function will select one out 926 of the list's adjacencies to which the packet is forwarded. If the 927 packet's encapsulation contains an entropy field, the entropy field 928 SHOULD be respected; two packets with the same value of the entropy 929 field SHOULD be sent on the same adjacency. The seed parameter 930 allows to design hash functions that are easy to implement at high 931 speed without running into polarization issues across multiple 932 consecutive ECMP hops. See Section 5.1.7 for more explanations. 934 4.2.4. Local Decap(sulation) 936 A "local_decap()" adjacency passes a copy of the payload of the BIER- 937 TE packet to the protocol ("NextProto") within the BFR (IPv4/IPv6, 938 Ethernet,...) responsible for that payload according to the packet 939 header fields. A local_decap() adjacency turns the BFR into a BFER 940 for matching packets. Local_decap() adjacencies require the BFER to 941 support routing or switching for NextProto to determine how to 942 further process the packet. 944 4.3. Encapsulation / Co-existence with BIER 946 Specifications for BIER-TE encapsulation are outside the scope of 947 this document. This section gives explanations and guidelines. 949 Like [RFC8279], handling of "Maximum Transmission Unit" (MTU) 950 limitations is outside the scope of this document and instead part of 951 the BIER-TE packet encapsulation and/or flow overlay. See for 952 example [RFC8296], Section 3. It applies equally to BIER-TE as it 953 does to BIER. 955 Because a BFR needs to interpret the BitString of a BIER-TE packet 956 differently from a (non-TE) BIER packet, it is necessary to 957 distinguish BIER from BIER-TE packets. In the BIER encapsulation 958 [RFC8296], the BIFT-id field of the packet indicates the BIFT of the 959 packet. BIER and BIER-TE can therefore be run simultaneously, when 960 the BIFT-id address space is shared across BIER BIFT and BIER-TE 961 BIFT. Partitioning the BIFT-id address space is subject to BIER-TE/ 962 BIER control plane procedures. 964 When [RFC8296] is used for BIER with MPLS, BIFT-id address ranges can 965 be dynamically allocated from MPLS label space only for the set of 966 actually used SD:BSL BIFT. This allows to also allocate non- 967 overlapping label ranges for BIFT-id that are to be used with BIER-TE 968 BIFTs. 970 With MPLS, it is also possible to reuse the same SD space for both 971 BIER-TE and BIER, so that the same SD has both a BIER BIFT with a 972 corresponding range of BIFT-ids and disjoint BIER-TE BIFTs with a 973 non-overlapping range of BIFT-ids. 975 When a fixed mapping from BSL, SD and SI to BIFT-id is used which 976 does not explicitly partition the BIFT-id space between BIER and 977 BIER-TE, such as proposed for non-MPLS forwarding with [RFC8296] 978 encapsulation in [I-D.ietf-bier-non-mpls-bift-encoding] revision 04, 979 section 5, then it is necessary to allocate disjoint SDs to BIER and 980 BIER-TE BIFTs so that both can be addressed by the BIFT-ids. The 981 encoding proposed in section 6. of the same document does not 982 statically encode BSL or SD into the BIFT-id, but allows for a 983 mapping, and hence could provide for the same freedom as when MPLS is 984 being used (same or different SD for BIER/BIER-TE). 986 forward_routed() requires an encapsulation that permits to direct 987 unicast encapsulated BIER-TE packets to a specific interface address 988 on a target BFR. With MPLS encapsulation, this can simply be done 989 via a label stack with that addresses label as the top label - 990 followed by the label assigned to the (BSL,SD,SI) BitString. With 991 non-MPLS encapsulation, some form of IP encapsulation would be 992 required (for example IP/GRE). 994 The encapsulation used for forward_routed() adjacencies can equally 995 support existing advanced adjacency information such as "loose source 996 routes" via e.g. MPLS label stacks or appropriate header extensions 997 (e.g. for IPv6). 999 4.4. BIER-TE Forwarding Pseudocode 1001 The following pseudocode, Figure 5, for BIER-TE forwarding is based 1002 on the (non-TE) BIER forwarding pseudocode of [RFC8279], section 6.5 1003 with one modification. 1005 void ForwardBitMaskPacket_withTE (Packet) 1006 { 1007 SI=GetPacketSI(Packet); 1008 Offset=SI*BitStringLength; 1009 for (Index = GetFirstBitPosition(Packet->BitString); Index ; 1010 Index = GetNextBitPosition(Packet->BitString, Index)) { 1011 F-BM = BIFT[Index+Offset]->F-BM; 1012 if (!F-BM) continue; [3] 1013 BFR-NBR = BIFT[Index+Offset]->BFR-NBR; 1014 PacketCopy = Copy(Packet); 1015 PacketCopy->BitString &= F-BM; [2] 1016 PacketSend(PacketCopy, BFR-NBR); 1017 // The following must not be done for BIER-TE: 1018 // Packet->BitString &= ~F-BM; [1] 1019 } 1020 } 1021 Figure 5: BIER-TE Forwarding Pseudocode for required functions, 1022 based on BIER Pseudocode 1024 In step [2], the F-BM is used to clear bit(s) in PacketCopy. This 1025 step exists in both BIER and BIER-TE, but the F-BMs need to be 1026 populated differently for BIER-TE than for BIER for the desired 1027 clearing. 1029 In BIER, multiple bits of a BitString can have the same BFR-NBR. 1030 When a received packets BitString has more than one of those bits 1031 set, the BIER replication logic has to avoid that more than one 1032 PacketCopy is sent to that BFR-NBR ([1]). Likewise, the PacketCopy 1033 sent to a BFR-NBR must clear all bits in its BitString that are not 1034 routed across BFR-NBR. This protects against BIER replication on any 1035 possible further BFR to create duplicates ([2]). 1037 To solve both [1] and [2] for BIER, the F-BM of each bit index needs 1038 to have all bits set that this BFR wants to route across BFR-NBR. [2] 1039 clears all other bits in PacketCopy->BitString, and [1] clears those 1040 bits from Packet->BitString after the first PacketCopy. 1042 In BIER-TE, a BFR-NBR in this pseudocode is an adjacency, 1043 forward_connected(), forward_routed() or local_decap(). There is no 1044 need for [2] to suppress duplicates in the way BIER does because in 1045 general, different BP would never have the same adjacency. If a 1046 BIER-TE controller actually finds some optimization in which this 1047 would be desirable, then the controller is also responsible to ensure 1048 that only one of those bits is set in any Packet->BitString, unless 1049 the controller explicitly wants for duplicates to be created. 1051 The following points describe how the forwarding bit mask (F-BM) for 1052 each BP is configured in the BIFT and how this impacts the BitString 1053 of the packet being processed with that BIFT: 1055 1. The F-BMs of all BIFT BPs without an adjacency have all their 1056 bits clear. This will cause [3] to skip further processing of 1057 such a BP. 1059 2. All BIFT BPs with an adjacency (with DNC flag clear) have an F-BM 1060 that has only those BPs set for which this BFR does not have an 1061 adjacency. This causes [2] to clear all bits from 1062 PacketCopy->BitString for which this BFR does have an adjacency. 1064 3. [1] is not performed for BIER-TE. All bit clearing required by 1065 BIER-TE is performed by [2]. 1067 This Forwarding Pseudocode can support the required BIER-TE 1068 forwarding functions (see Section 4.5), forward_connected(), 1069 forward_routed() and local_decap(), but not the recommended functions 1070 DNC flag and multiple adjacencies per bit nor the optional function, 1071 ECMP() adjacencies. The DNC flag cannot be supported when using only 1072 [1] to mask bits. 1074 The modified and expanded Forwarding Pseudocode in Figure 6 specifies 1075 how to support all BIER-TE forwarding functions (required, 1076 recommended and optional): 1078 * This pseudocode eliminates per-bit F-BM, therefore reducing the 1079 size of BIFT state by BSL^2*SI and eliminating the need for per- 1080 packet-copy BitString masking operations except for adjacencies 1081 with the DNC flag set: 1083 - AdjacentBits[SI] are bit positions with a non-empty list of 1084 adjacencies in this BFR BIFT. This can be computed whenever 1085 the BIER-TE Controller updates (add/removes) adjacencies in the 1086 BIFT. 1088 - The BFR needs to create packet copies for these adjacent bits 1089 when they are set in the packets BitString. This set of bits 1090 is calculated in PktAdjacentBits. 1092 - All bit positions to which the BFR creates copies have to be 1093 cleared in packet copies to avoid loops. This is done by 1094 masking the BitString of the packet with ~AdjacentBits[SI]. 1095 When an adjacency has DNC set, this bit position is set again 1096 only for the packet copy towards that bit position. 1098 * BIFT entries may contain more than one adjacency in support of 1099 specific configurations such as Section 5.1.5. The code therefore 1100 includes a loop over these adjacencies. 1102 * The ECMP() adjacency is shown. Its parameters are a seed and a 1103 ListOfAdjacencies from which one is picked. 1105 * The forward_connected(), forward_routed(), local_decap() 1106 adjacencies are shown with their parameters. 1108 void ForwardBitMaskPacket_withTE (Packet) 1109 { 1110 SI = GetPacketSI(Packet); 1111 Offset = SI * BitStringLength; 1112 // Determine adjacent bits in the Packets BitString 1113 PktAdjacentBits = Packet->BitString & AdjacentBits[SI]; 1115 // Clear adjacent bits in Packet header to avoid loops 1116 Packet->BitString &= ~AdjacentBits[SI]; 1118 // Loop over PktAdjacentBits to create packet copies 1119 for (Index = GetFirstBitPosition(PktAdjacentBits); Index ; 1120 Index = GetNextBitPosition(PktAdjacentBits, Index)) { 1121 for adjacency in BIFT[Index+Offset]->Adjacencies { 1122 if(adjacency.type == ECMP(ListOfAdjacencies,seed) ) { 1123 I = ECMP_hash(sizeof(ListOfAdjacencies), 1124 Packet->Entropy,seed); 1125 adjacency = ListOfAdjacencies[I]; 1126 } 1127 PacketCopy = Copy(Packet); 1128 switch(adjacency.type) { 1129 case forward_connected(interface,neighbor,DNC): 1130 if(DNC) 1131 PacketCopy->BitString |= 1<<(Index-1); 1132 SendToL2Unicast(PacketCopy,interface,neighbor); 1134 case forward_routed({VRF,}l3-neighbor): 1135 SendToL3(PacketCopy,{VRF,}l3-neighbor); 1137 case local_decap({VRF},neighbor): 1138 DecapBierHeader(PacketCopy); 1139 PassTo(PacketCopy,{VRF,}Packet->NextProto); 1140 } 1141 } 1142 } 1143 } 1145 Figure 6: Complete BIER-TE Forwarding Pseudocode for required, 1146 recommended and optional functions 1148 4.5. BFR Requirements for BIER-TE forwarding 1150 BFR that support BIER-TE and BIER MUST support configuration that 1151 enables BIER-TE instead of (non-TE) BIER forwarding rules for all 1152 BIFT of one or more BIER sub-domains. Every BP in a BIER-TE BIFT 1153 MUST support to have zero or one adjacency. BIER-TE forwarding MUST 1154 support the adjacency types forward_connected() with the DNC flag not 1155 set, forward_routed() and local_decap(). As explained in 1156 Section 4.4, these required BIER-TE forwarding functions can be 1157 implemented via the same Forwarding Pseudocode as BIER forwarding 1158 except for one modification (skipping one masking with F-BM). 1160 BIER-TE forwarding SHOULD support forward_connected() adjacencies 1161 with a set DNC flag, as this is highly useful to save bits in rings 1162 (see Section 5.1.6). 1164 BIER-TE forwarding SHOULD support more than one adjacency on a bit. 1165 This allows to save bits in hub and spoke scenarios (see 1166 Section 5.1.5). 1168 BIER-TE forwarding MAY support ECMP() adjacencies to save bits in 1169 ECMP scenarios, see Section 5.1.7 for an example. This is an 1170 optional requirement, because for ECMP deployments using BIER-TE one 1171 can also leverage ECMP of the routing underlay via forwarded_routed 1172 adjacencies and/or might prefer to have more explicit control of the 1173 path chosen via explicit BP/adjacencies for each ECMP path 1174 alternative. 1176 5. BIER-TE Controller Operational Considerations 1178 5.1. Bit Position Assignments 1180 This section describes how the BIER-TE Controller can use the 1181 different BIER-TE adjacency types to define the bit positions of a 1182 BIER-TE domain. 1184 Because the size of the BitString limits the size of the BIER-TE 1185 domain, many of the options described exist to support larger 1186 topologies with fewer bit positions. 1188 5.1.1. P2P Links 1190 On a P2P link that connects two BFRs, the same bit position can be 1191 used on both BFRs for the adjacency to the neighboring BFR. A P2P 1192 link requires therefore only one bit position. 1194 5.1.2. BFER 1196 Every non-Leaf BFER is given a unique bit position with a 1197 local_decap() adjacency. 1199 5.1.3. Leaf BFERs 1200 BFR1(P) BFR2(P) BFR1(P) BFR2(P) 1201 | \ / | | | 1202 | X | | | 1203 | / \ | | | 1204 BFER1(PE) BFER2(PE) BFER1(PE)----BFER2(PE) 1206 ^ U-turn link 1208 Leaf BFER / Non-Leaf BFER / 1209 PE-router PE-router 1211 Figure 7: Leaf vs. non-Leaf BFER Example 1213 A leaf BFER is one where incoming BIER-TE packets never need to be 1214 forwarded to another BFR but are only sent to the BFER to exit the 1215 BIER-TE domain. For example, in networks where Provider Edge (PE) 1216 router are spokes connected to Provider (P) routers, those PEs are 1217 Leaf BFERs unless there is a U-turn between two PEs. 1219 Consider how redundant disjoint traffic can reach BFER1/BFER2 in 1220 Figure 7: When BFER1/BFER2 are Non-Leaf BFER as shown on the right- 1221 hand side, one traffic copy would be forwarded to BFER1 from BFR1, 1222 but the other one could only reach BFER1 via BFER2, which makes BFER2 1223 a non-Leaf BFER. Likewise, BFER1 is a non-Leaf BFER when forwarding 1224 traffic to BFER2. Note that the BFERs in the left-hand picture are 1225 only guaranteed to be leaf-BFER by fitting routing configuration that 1226 prohibits transit traffic to pass through the BFERs, which is 1227 commonly applied in these topologies. 1229 In most situations, leaf-BFER that are to be addressed via the same 1230 BitString can share a single bit position for their local_decap() 1231 adjacency in that BitString and therefore save bit positions. On a 1232 non-leaf BFER, a received BIER-TE packet may only need to transit the 1233 BFER or it may need to also be decapsulated. Whether or not to 1234 decapsulate the packet therefore needs to be indicated by a unique 1235 bit position populated only on the BIFT of this BFER with a 1236 local_decap() adjacency. On a leaf-BFER, packets never need to pass 1237 through; any packet received is therefore usually intended to be 1238 decapsulated. This can be expressed by a single, shared bit position 1239 that is populated with a local_decap() adjacency on all leaf-BFER 1240 addressed by the BitString. 1242 The possible exception from this leaf-BFER bit position optimization 1243 can be cases where the bit position on the prior BIER-TE BFR (which 1244 created the packet copy for the leaf-BFER in question) is populated 1245 with multiple adjacencies as an optimization, such as in 1246 Section 5.1.4 or Section 5.1.5. With either of these two 1247 optimizations, the sender of the packet could only control explicitly 1248 whether the packet was to be decapsulated on the leaf-BFER in 1249 question, if the leaf-BFER has a unique bit position for its 1250 local_decap() adjacency. 1252 However, if the bit position is shared across leaf-BFER, and packets 1253 are therefore decapsulated potentially unnecessarily, this may still 1254 be appropriate if the decapsulated payload of the BIER-TE packet 1255 indicates whether or not the packet needs to be further processed/ 1256 received. This is typically true for example if the payload is IP 1257 multicast because IP multicast on a BFER would know the membership 1258 state of the IP multicast payload and be able to discard it if the 1259 packet was delivered unnecessarily by the BIER-TE layer. If the 1260 payload has no such membership indication, and the BFIR wants to have 1261 explicit control about which BFER are to receive and decapsulate a 1262 packet, then these two optimizations can not be used together with 1263 shared bit positions optimization for leaf-BFER. 1265 5.1.4. LANs 1267 In a LAN, the adjacency to each neighboring BFR is given a unique bit 1268 position. The adjacency of this bit position is a 1269 forward_connected() adjacency towards the BFR and this bit position 1270 is populated into the BIFT of all the other BFRs on that LAN. 1272 BFR1 1273 |p1 1274 LAN1-+-+---+-----+ 1275 p3| p4| p2| 1276 BFR3 BFR4 BFR7 1278 Figure 8: LAN Example 1280 If Bandwidth on the LAN is not an issue and most BIER-TE traffic 1281 should be copied to all neighbors on a LAN, then bit positions can be 1282 saved by assigning just a single bit position to the LAN and 1283 populating the bit position of the BIFTs of each BFRs on the LAN with 1284 a list of forward_connected() adjacencies to all other neighbors on 1285 the LAN. 1287 This optimization does not work in the case of BFRs redundantly 1288 connected to more than one LAN with this optimization because these 1289 BFRs would receive duplicates and forward those duplicates into the 1290 opposite LANs. Adjacencies of such BFRs into their LAN still need a 1291 separate bit position. 1293 5.1.5. Hub and Spoke 1295 In a setup with a hub and multiple spokes connected via separate p2p 1296 links to the hub, all p2p adjacencies from the hub to the spokes 1297 links can share the same bit position. The bit position on the hub's 1298 BIFT is set up with a list of forward_connected() adjacencies, one 1299 for each Spoke. 1301 This option is similar to the bit position optimization in LANs: 1302 Redundantly connected spokes need their own bit positions, unless 1303 they are themselves Leaf-BFER. 1305 This type of optimized BP could be used for example when all traffic 1306 is "broadcast" traffic (very dense receiver set) such as live-TV or 1307 many-to-many telemetry including situation-awareness (SA). This BP 1308 optimization can then be used to explicitly steer different traffic 1309 flows across different ECMP paths in Data-Center or broadband- 1310 aggregation networks with minimal use of BPs. 1312 5.1.6. Rings 1314 In L3 rings, instead of assigning a single bit position for every p2p 1315 link in the ring, it is possible to save bit positions by setting the 1316 "DoNotClear" (DNC) flag on forward_connected() adjacencies. 1318 For the rings shown in Figure 9, a single bit position will suffice 1319 to forward traffic entering the ring at BFRa or BFRb all the way up 1320 to BFR1: 1322 On BFRa, BFRb, BFR30,... BFR3, the bit position is populated with a 1323 forward_connected() adjacency pointing to the clockwise neighbor on 1324 the ring and with DNC set. On BFR2, the adjacency also points to the 1325 clockwise neighbor BFR1, but without DNC set. 1327 Handling DNC this way ensures that copies forwarded from any BFR in 1328 the ring to a BFR outside the ring will not have the ring bit 1329 position set, therefore minimizing the chance to create loops. 1331 v v 1332 | | 1333 L1 | L2 | L3 1334 /-------- BFRa ---- BFRb --------------------\ 1335 | | 1336 \- BFR1 - BFR2 - BFR3 - ... - BFR29 - BFR30 -/ 1337 | | L4 | | 1338 p33| p15| 1339 BFRd BFRc 1340 Figure 9: Ring Example 1342 Note that this example only permits for packets intended to make it 1343 all the way around the ring to enter it at BFRa and BFRb, and that 1344 packets will always travel clockwise. If packets should be allowed 1345 to enter the ring at any ring BFR, then one would have to use two 1346 ring bit positions. One for each direction: clockwise and 1347 counterclockwise. 1349 Both would be set up to stop rotating on the same link, e.g. L1. 1350 When the ingress ring BFR creates the clockwise copy, it will clear 1351 the counterclockwise bit position because the DNC bit only applies to 1352 the bit for which the replication is done. Likewise for the 1353 clockwise bit position for the counterclockwise copy. As a result, 1354 the ring ingress BFR will send a copy in both directions, serving 1355 BFRs on either side of the ring up to L1. 1357 5.1.7. Equal Cost MultiPath (ECMP) 1359 [RFC-Editor: A reviewer (Lars Eggert) noted that the infinite "to 1360 use" in the following sentence is not correct. The same was also 1361 noted for several other similar instances. The following URL seems 1362 to indicate though that this is a per-case decision, which seems 1363 undefined: https://writingcenter.gmu.edu/guides/choosing-between- 1364 infinitive-and-gerund-to-do-or-doing. What exactly should be done 1365 about this ?]. 1367 An ECMP() adjacency allows to use just one BP to deliver packets to 1368 one of N adjacencies instead of one BP for each adjacency. In the 1369 common example case Figure 10, a link-bundle of three links L1,L2,L3 1370 connects BFR1 and BFR2, and only one BP is used instead of three BP 1371 to deliver packets from BFR1 to BFR2. 1373 --L1----- 1374 BFR1 --L2----- BFR2 1375 --L3----- 1377 BIFT entry in BFR1: 1378 ------------------------------------------------------------------ 1379 | Index | Adjacencies | 1380 ================================================================== 1381 | 0:6 | ECMP({forward_connected(L1, BFR2), | 1382 | | forward_connected(L2, BFR2), | 1383 | | forward_connected(L3, BFR2)}, seed) | 1384 ------------------------------------------------------------------ 1386 BIFT entry in BFR2: 1387 ------------------------------------------------------------------ 1388 | Index | Adjacencies | 1389 ================================================================== 1390 | 0:6 | ECMP({forward_connected(L1, BFR1), | 1391 | | forward_connected(L2, BFR1), | 1392 | | forward_connected(L3, BFR1)}, seed) | 1393 ------------------------------------------------------------------ 1395 Figure 10: ECMP Example 1397 This document does not standardize any ECMP algorithm because it is 1398 sufficient for implementations to document their freely chosen ECMP 1399 algorithm. Figure 11 shows an example ECMP algorithm, and would 1400 double as its documentation: A BIER-TE controller could determine 1401 which adjacency is chosen based on the seed and adjacencies 1402 parameters and the packet entropy. 1404 forward(packet, ECMP(adj(0), adj(1),... adj(N-1), seed)): 1405 i = (packet(bier-header-entropy) XOR seed) % N 1406 forward packet to adj(i) 1408 Figure 11: ECMP algorithm Example 1410 In the following example, all traffic from BFR1 towards BFR10 is 1411 intended to be ECMP load split equally across the topology. This 1412 example is not meant as a likely setup, but to illustrate that ECMP 1413 can be used to share BPs not only across link bundles, but also 1414 across alternative paths across different transit BFR, and it 1415 explains the use of the seed parameter. 1417 BFR1 (BFIR) 1418 /L11 \L12 1419 / \ 1420 BFR2 BFR3 1421 /L21 \L22 /L31 \L32 1422 / \ / \ 1423 BFR4 BFR5 BFR6 BFR7 1424 \ / \ / 1425 \ / \ / 1426 BFR8 BFR9 1427 \ / 1428 \ / 1429 BFR10 (BFER) 1431 BIFT entry in BFR1: 1432 ------------------------------------------------------------------ 1433 | 0:6 | ECMP({forward_connected(L11, BFR2), | 1434 | | forward_connected(L12, BFR3)}, seed1) | 1435 ------------------------------------------------------------------ 1437 BIFT entry in BFR2: 1438 ------------------------------------------------------------------ 1439 | 0:7 | ECMP({forward_connected(L21, BFR4), | 1440 | | forward_connected(L22, BFR5)}, seed1) | 1441 ------------------------------------------------------------------ 1443 BIFT entry in BFR3: 1444 ------------------------------------------------------------------ 1445 | 0:7 | ECMP({forward_connected(L31, BFR6), | 1446 | | forward_connected(L32, BFR7)}, seed1) | 1447 ------------------------------------------------------------------ 1449 BIFT entry in BFR4, BFR5: 1450 ------------------------------------------------------------------ 1451 | 0:8 | forward_connected(Lxx, BFR8) |xx differs on BFR4/BFR5| 1452 ------------------------------------------------------------------ 1454 BIFT entry in BFR6, BFR7: 1455 ------------------------------------------------------------------ 1456 | 0:8 | forward_connected(Lxx, BFR9) |xx differs on BFR6/BFR7| 1457 ------------------------------------------------------------------ 1459 BIFT entry in BFR8, BFR9: 1460 ------------------------------------------------------------------ 1461 | 0:9 | forward_connected(Lxx, BFR10) |xx differs on BFR8/BFR9| 1462 ------------------------------------------------------------------ 1464 Figure 12: Polarization Example 1466 Note that for the following discussion of ECMP, only the BIFT ECMP 1467 adjacencies on BFR1, BFR2, BFR3 are relevant. The re-use of BP 1468 across BFR in this example is further explained in Section 5.1.9 1469 below. 1471 With the setup of ECMP in the topology above, traffic would not be 1472 equally load-split. Instead, links L22 and L31 would see no traffic 1473 at all: BFR2 will only see traffic from BFR1 for which the ECMP hash 1474 in BFR1 selected the first adjacency in the list of 2 adjacencies 1475 given as parameters to the ECMP. It is link L11-to-BFR2. BFR2 1476 performs again ECMP with two adjacencies on that subset of traffic 1477 using the same seed1, and will therefore again select the first of 1478 its two adjacencies: L21-to-BFR4. And therefore L22 and BFR5 sees no 1479 traffic. Likewise for L31 and BFR6. 1481 This issue in BFR2/BFR3 is called polarization. It results from the 1482 re-use of the same hash function across multiple consecutive hops in 1483 topologies like these. To resolve this issue, the ECMP() adjacency 1484 on BFR1 can be set up with a different seed2 than the ECMP() 1485 adjacencies on BFR2/BFR3. BFR2/BFR3 can use the same hash because 1486 packets will not sequentially pass across both of them. Therefore, 1487 they can also use the same BP 0:7. 1489 Note that ECMP solutions outside of BIER often hide the seed by auto- 1490 selecting it from local entropy such as unique local or next-hop 1491 identifiers. Allowing the BIER-TE Controller to explicitly set the 1492 seed gives the ability for it to control same/different path 1493 selection across multiple consecutive ECMP hops. 1495 5.1.8. Forward Routed adjacencies 1497 5.1.8.1. Reducing bit positions 1499 Forward_routed() adjacencies can reduce the number of bit positions 1500 required when the path steering requirement is not hop-by-hop 1501 explicit path selection, but loose-hop selection. Forward_routed() 1502 adjacencies can also allow to operate BIER-TE across intermediate hop 1503 routers that do not support BIER-TE. 1505 ............... 1506 ...BFR1--... ...--L1-- BFR2... 1507 ... .Routers. ...--L2--/ 1508 ...BFR4--... ...--L3-- BFR3... 1509 ... ...--L4--/ | 1510 ............... | 1511 LO 1512 Network Area 1 1514 Figure 13: Forward Routed Adjacencies Example 1516 Assume the requirement in Figure 13 is to explicitly steer traffic 1517 flows that have arrived at BFR1 or BFR4 via a path in the routing 1518 underlay "Network Area 1" to one of the following three next 1519 segments: (1) BFR2 via link L1, (2) BFR2 via link L2, or (3) via BFR3 1520 and then nor caring whether the packet is forwarded via L3 or L4. 1522 To enable this, both BFR1 and BFR4 are set up with a forward_routed 1523 adjacency bit position towards an address of BFR2 on link L1, another 1524 forward_routed() bit position towards an address of BFR2 on link L2 1525 and a third forward_routed() bit position towards a node address LO 1526 of BFR3. 1528 5.1.8.2. Supporting nodes without BIER-TE 1530 Forward_routed() adjacencies also enable incremental deployment of 1531 BIER-TE. Only the nodes through which BIER-TE traffic needs to be 1532 steered - with or without replication - need to support BIER-TE. 1533 Where they are not directly connected to each other, forward_routed 1534 adjacencies are used to pass over non BIER-TE enabled nodes. 1536 5.1.9. Reuse of bit positions (without DNC) 1538 Bit positions can be re-used across multiple BFRs to minimize the 1539 number of BP needed. This happens when adjacencies on multiple BFRs 1540 use the DNC flag as described above, but it can also be done for non- 1541 DNC adjacencies. This section only discusses this non-DNC case. 1543 Because BP are cleared when passing a BFR with an adjacency for that 1544 BP, reuse of BP across multiple BFRs does not introduce any problems 1545 with duplicates or loops that do not also exist when every adjacency 1546 has a unique BP. Instead, the challenge when reusing BP is whether 1547 it allows to still achieve the desired Tree Engineering goals. 1549 BP cannot be reused across two BFRs that would need to be passed 1550 sequentially for some path: The first BFR will clear the BP, so those 1551 paths cannot be built. BP can be set across BFR that would (A) only 1552 occur across different paths or (B) across different branches of the 1553 same tree. 1555 An example of (A) was given in Figure 12, where BP 0:7, BP 0:8 and BP 1556 0:9 are each reused across multiple BFRs because a single packet/path 1557 would never be able to reach more than one BFR sharing the same BP. 1559 Assume the example was changed: BFR1 has no ECMP() adjacency for BP 1560 0:6, but instead BP 0:5 with forward_connected() to BFR2 and BP 0:6 1561 with forward_connected() to BFR3. Packets with both BP 0:5 and BP 1562 0:6 would now be able to reach both BFR2 and BFR3 and the still 1563 existing re-use of BP 0:7 between BFR2 and BFR3 is a case of (B) 1564 where reuse of BP is perfect because it does not limit the set of 1565 useful path choices: 1567 If instead of reusing BP 0:7, BFR3 used a separate BP 0:10 for its 1568 ECMP() adjacency, no useful additional path steering options would be 1569 enabled. If duplicates at BFR10 where undesirable, this would be 1570 done by not setting BP 0:5 and BP 0:6 for the same packet. If the 1571 duplicates where desirable (e.g.: resilient transmission), the 1572 additional BP 0:10 would also not render additional value. 1574 area1 1575 BFR1a BFR1b 1576 / \ 1577 .................................... 1578 . Core . 1579 .................................... 1580 | / \ / \ | 1581 BFR2a BFR2b BFR3a BFR3b BFR6a BFR6b 1582 /-------\ /---------\ /--------\ 1583 | area2 | | area3 | ... | area6 | 1584 | ring | | ring | | ring | 1585 \-------/ \---------/ \--------/ 1586 more BFR more BFR more BFR 1588 Figure 14: Reuse of BP 1590 Reuse may also save BPs in larger topologies. Consider the topology 1591 shown in Figure 14. A BFIR/sender (e.g.: video headend) is attached 1592 to area 1, and area 2...6 contain receivers/BFER. Assume each area 1593 had a distribution ring, each with two BPs to indicate the direction 1594 (as explained before). These two BPs could be reused across the 5 1595 areas. Packets would be replicated through other BPs for the Core to 1596 the desired subset of areas, and once a packet copy reaches the ring 1597 of the area, the two ring BPs come into play. This reuse is a case 1598 of (B), but it limits the topology choices: Packets can only flow 1599 around the same direction in the rings of all areas. This may or may 1600 not be acceptable based on the desired path steering options: If 1601 resilient transmission is the path engineering goal, then it is 1602 likely a good optimization, if the bandwidth of each ring was to be 1603 optimized separately, it would not be a good limitation. 1605 5.1.10. Summary of BP optimizations 1607 This section reviewed a range of techniques by which a BIER-TE 1608 Controller can create a BIER-TE topology in a way that minimizes the 1609 number of necessary BPs. 1611 Without any optimization, a BIER-TE Controller would attempt to map 1612 the network subnet topology 1:1 into the BIER-TE topology and every 1613 subnet adjacent neighbor requires a forward_connected() BP and every 1614 BFER requires a local_decap() BP. 1616 The optimizations described are then as follows: 1618 * P2P links require only one BP (Section 5.1.1). 1620 * All leaf-BFER can share a single local_decap() BP (Section 5.1.3). 1622 * A LAN with N BFR needs at most N BP (one for each BFR). It only 1623 needs one BP for all those BFR that are not redundantly connected 1624 to multiple LANs (Section 5.1.4). 1626 * A hub with p2p connections to multiple non-leaf-BFER spokes can 1627 share one BP to all spokes if traffic can be flooded to all 1628 spokes, e.g.: because of no bandwidth concerns or dense receiver 1629 sets (Section 5.1.5). 1631 * Rings of BFR can be built with just two BP (one for each 1632 direction) except for BFR with multiple ring connections - similar 1633 to LANs (Section 5.1.6). 1635 * ECMP() adjacencies to N neighbors can replace N BP with 1 BP. 1636 Multihop ECMP can avoid polarization through different seeds of 1637 the ECMP algorithm (Section 5.1.7). 1639 * Forward_routed() adjacencies allow to "tunnel" across non-BIER-TE 1640 capable routers and across BIER-TE capable routers where no 1641 traffic-steering or replications are required (Section 5.1.8). 1643 * BP can generally be reused across a set of nodes where it can be 1644 guaranteed that no path will ever need to traverse more than one 1645 node of the set. Depending on scenario, this may limit the 1646 feasible path steering options (Section 5.1.9). 1648 Note that the described list of optimizations is not exhaustive. 1649 Especially when the set of required path steering choices is limited 1650 and the set of possible subsets of BFERs that should be able to 1651 receive traffic is limited, further optimizations of BP are possible. 1652 The hub and spoke optimization is a simple example of such traffic 1653 pattern dependent optimizations. 1655 5.2. Avoiding duplicates and loops 1656 5.2.1. Loops 1658 Whenever BIER-TE creates a copy of a packet, the BitString of that 1659 copy will have all bit positions cleared that are associated with 1660 adjacencies on the BFR. This inhibits looping of packets. The only 1661 exception are adjacencies with DNC set. 1663 v v 1664 | | 1665 L1 | L2 | L3 1666 /-------- BFRa ---- BFRb ---------------------\ 1667 | . | 1668 | ...... Wrong link wiring | 1669 | . | 1670 \- BFR1 - BFR2 BFR3 - ... - BFR29 - BFR30 -/ 1671 | | L4 | | 1672 p33| p15| 1673 BFRd BFRc 1675 Figure 15: Miswired Ring Example 1677 With DNC set, looping can happen. Consider in Figure 15 that link L4 1678 from BFR3 is (inadvertently) plugged into the L1 interface of BFRa 1679 (instead of BFR2). This creates a loop where the rings clockwise bit 1680 position is never cleared for copies of the packets traveling 1681 clockwise around the ring. 1683 To inhibit looping in the face of such physical misconfiguration, 1684 only forward_connected() adjacencies are permitted to have DNC set, 1685 and the link layer port unique unicast destination address of the 1686 adjacency (e.g. MAC address) protects against closing the loop. 1687 Link layers without port unique link layer addresses should not be 1688 used with the DNC flag set. 1690 5.2.2. Duplicates 1692 BFIR1 1693 / \ 1694 / p2 \ p3 1695 BFR2 BFR3 1696 \ p4 / p5 1697 \ / 1698 BFER4 1700 Figure 16: Duplicates Example 1702 Duplicates happen when the graph expressed by a BitString is not a 1703 tree but redundantly connecting BFRs with each other. In Figure 16, 1704 a BitString of p2,p3,p4,p5 would result in duplicate packets to 1705 arrive on BFER4. The BIER-TE Controller must therefore ensure to 1706 only create BitStrings that are trees. 1708 When links are incorrectly physically re-connected before the BIER-TE 1709 Controller updates BitStrings in BFIRs, duplicates can happen. Like 1710 loops, these can be inhibited by link layer addressing in 1711 forward_connected() adjacencies. 1713 If interface or loopback addresses used in forward_routed() 1714 adjacencies are moved from one BFR to another, duplicates can equally 1715 happen. Such re-addressing operations must be coordinated with the 1716 BIER-TE Controller. 1718 5.3. Managing SI, sub-domains and BFR-ids 1720 When the number of bits required to represent the necessary hops in 1721 the topology and BFER exceeds the supported BitStringLength (BSL), 1722 multiple SIs and/or sub-domains must be used. This section discusses 1723 how. 1725 BIER-TE forwarding does not require the concept of BFR-id, but 1726 routing underlay, flow overlay and BIER headers may. This section 1727 also discusses how BFR-ids can be assigned to BFIR/BFER for BIER-TE. 1729 5.3.1. Why SI and sub-domains 1731 For (non-TE) BIER and BIER-TE forwarding, the most important result 1732 of using multiple SI and/or sub-domains is the same: Packets that 1733 need to be sent to BFERs in different SIs or sub-domains require 1734 different BIER packets: each one with a BitString for a different 1735 (SI,sub-domain) combination. Each such BitString uses one BSL sized 1736 SI block in the BIFT of the sub-domain. We call this a BIFT:SI 1737 (block). 1739 For BIER and BIER-TE forwarding themselves there is also no 1740 difference whether different SIs and/or sub-domains are chosen, but 1741 SI and sub-domain have different purposes in the BIER architecture 1742 shared by BIER-TE. This impacts how operators are managing them and 1743 how especially flow overlays will likely use them. 1745 By default, every possible BFIR/BFER in a BIER network would likely 1746 be given a BFR-id in sub-domain 0 (unless there are > 64k BFIR/BFER). 1748 If there are different flow services (or service instances) requiring 1749 replication to different subsets of BFERs, then it will likely not be 1750 possible to achieve the best replication efficiency for all of these 1751 service instances via sub-domain 0. Ideal replication efficiency for 1752 N BFER exists in a sub-domain if they are split over not more than 1753 ceiling(N/BitStringLength) SI. 1755 If service instances justify additional BIER:SI state in the network, 1756 additional sub-domains will be used: BFIR/BFER are assigned BFR-id in 1757 those sub-domains and each service instance is configured to use the 1758 most appropriate sub-domain. This results in improved replication 1759 efficiency for different services. 1761 Even if creation of sub-domains and assignment of BFR-id to BFIR/BFER 1762 in those sub-domains is automated, it is not expected that individual 1763 service instances can deal with BFER in different sub-domains. A 1764 service instance may only support configuration of a single sub- 1765 domain it should rely on. 1767 To be able to easily reuse (and modify as little as possible) 1768 existing BIER procedures including flow-overlay and routing underlay, 1769 when BIER-TE forwarding is added, we therefore reuse SI and sub- 1770 domain logically in the same way as they are used in BIER: All 1771 necessary BFIR/BFER for a service use a single BIER-TE BIFT and are 1772 split across as many SIs as necessary (see Section 5.3.2). Different 1773 services may use different sub-domains that primarily exist to 1774 provide more efficient replication (and for BIER-TE desirable path 1775 steering) for different subsets of BFIR/BFER. 1777 5.3.2. Assigning bits for the BIER-TE topology 1779 In BIER, BitStrings only need to carry bits for BFERs, which leads to 1780 the model that BFR-ids map 1:1 to each bit in a BitString. 1782 In BIER-TE, BitStrings need to carry bits to indicate not only the 1783 receiving BFER but also the intermediate hops/links across which the 1784 packet must be sent. The maximum number of BFER that can be 1785 supported in a single BitString or BIFT:SI depends on the number of 1786 bits necessary to represent the desired topology between them. 1788 "Desired" topology because it depends on the physical topology, and 1789 on the desire of the operator to allow for explicit path steering 1790 across every single hop (which requires more bits), or reducing the 1791 number of required bits by exploiting optimizations such as unicast 1792 (forward_routed()), ECMP() or flood (DNC) over "uninteresting" sub- 1793 parts of the topology - e.g. parts where different trees do not need 1794 to take different paths due to path steering reasons. 1796 The total number of bits to describe the topology vs. the number of 1797 BFERs in a BIFT:SI can range widely based on the size of the topology 1798 and the amount of alternative paths in it. In a BIER-TE topology 1799 crafted by a BIER-TE expert, the higher the percentage of non-BFER 1800 bits, the higher the likelihood, that those topology bits are not 1801 just BIER-TE overhead without additional benefit, but instead that 1802 they will allow to express desirable path steering alternatives. 1804 5.3.3. Assigning BFR-id with BIER-TE 1806 BIER-TE forwarding does not use the BFR-id, nor does it require for 1807 the BFIR-id field of the BIER header to be set to a particular value. 1808 However, other parts of a BIER-TE deployment may need a BFR-id, 1809 specifically multicast flow overlay signaling and multicast flow 1810 overlay packet disposition, and in that case BFRs need to also have 1811 BFR-ids for BIER-TE SDs. 1813 For example, for BIER overlay signaling, BFIRs need to have a BFR-id, 1814 because this BFIR BFR-id is carried in the BFIR-id field of the BIER 1815 header to indicate to the overlay signaling on the receiving BFER 1816 which BFIR originated the packet. 1818 In BIER, BFR-id = SI * BSL + BP, such that the SI and BP of a BFER 1819 can be calculated from the BFR-id and vice versa. This also means 1820 that every BFR with a BFR-id has a reserved BP in an SI, even if that 1821 is not necessary for BIER forwarding, because the BFR may never be a 1822 BFER but only a BFIR. 1824 In BIER-TE, for a non-leaf BFER, there is usually a single BP for 1825 that BFER with a local_decap() adjacency on the BFER. The BFR-id for 1826 such a BFER can therefore be determined using the same procedure as 1827 in (non-TE) BIER: BFR-id = SI * BSL + BP. 1829 As explained in Section 5.1.3, leaf BFERs do not need such a unique 1830 local_decap() adjacency. Likewise, BFIRs that are not also BFERs may 1831 not have a unique local_decap() adjacency either. For all those 1832 BFIRs and (leaf) BFERs, the controller needs to determine unique BFR- 1833 ids that do not collide with the BFR-ids derived from the non-leaf 1834 BFER local_decap() BPs. 1836 While this document defines no requirements on how to allocate such 1837 BFR-id, a simple option is to derive it from the (SI,BP) of an 1838 adjacency that is unique to the BFR in question. For a BFIR this can 1839 be the first adjacency only populated on this BFIR, for a leaf-BFER, 1840 this could be the first BP with an adjacency towards that BFER. 1842 5.3.4. Mapping from BFR to BitStrings with BIER-TE 1844 In BIER, applications of the flow overlay on a BFIR can calculate the 1845 (SI,BP) of a BFER from the BFR-id of the BFER and can therefore 1846 easily determine the BitStrings for a BIER packet to a set of BFERs 1847 with known BFR-ids. 1849 In BIER-TE this mapping needs to be equally supported for flow 1850 overlays. This section outlines two core options, based on what type 1851 of Tree Engineering the BIER-TE controller needs to performs for a 1852 particular application. 1854 "Independent branches": For a given flow overlay instance, the 1855 branches from a BFIR to every BFER are calculated by the BIER-TE 1856 controller to be independent of the branches to any other BFER. 1857 Shortest path trees are the most common examples of trees with 1858 independent branches. 1860 "Interdependent branches": When a BFER is added or deleted from a 1861 particular distribution tree, the BIER-TE controller has to 1862 recalculate the branches to other BFER, because they may need to 1863 change. Steiner trees are examples of interdependent branch trees. 1865 If "independent branches" are used, the BIER-TE Controller can signal 1866 to the BFIR flow overlay for every BFER an SI:BitString that 1867 represents the branch to that BFER. The flow overlay on the BIFR can 1868 then independently of the controller calculate the SI:BitString for 1869 all desired BFERs by OR'ing their BitStrings. This allows for flow 1870 overlay applications to operate independently of the controller 1871 whenever it needs to determine which subset of BFERs need to receive 1872 a particular packet. 1874 If "interdependent branches" are required, the application would need 1875 to inquire the SI:BitString for a given set of BFER whenever the set 1876 changes. 1878 Note that in either case (unlike in BIER), the bits may need to 1879 change upon link/node failure/recovery, network expansion and network 1880 resource consumption by other traffic as part of traffic engineering 1881 goals (e.g.: re-optimization of lower priority traffic flows). 1882 Interactions between such BFIR applications and the BIER-TE 1883 Controller do therefore need to support dynamic updates to the 1884 SI:BitStrings. 1886 Communications between the BFIR flow overlay and the BIER-TE 1887 controller requires some way to identify the BFER. If BFR-ids are 1888 used in the deployment, as outlined in Section 5.3.3, then those are 1889 the natural BFR identifier. If BFR-ids are not used, then any other 1890 unique identifier, such as the BFR-prefix of the BFR ([RFC8279]) 1891 could be used. 1893 5.3.5. Assigning BFR-ids for BIER-TE 1895 It is not currently determined if a single sub-domain could or should 1896 be allowed to forward both (non-TE) BIER and BIER-TE packets. If 1897 this should be supported, there are two options: 1899 A. BIER and BIER-TE have different BFR-id in the same sub-domain. 1900 This allows higher replication efficiency for BIER because their BFR- 1901 id can be assigned sequentially, while the BitStrings for BIER-TE 1902 will have also the additional bits for the topology. There is no 1903 relationship between a BFR BIER BFR-id and its BIER-TE BFR-id. 1905 B. BIER and BIER-TE share the same BFR-id. The BFR-ids are assigned 1906 as explained above for BIER-TE and simply reused for BIER. The 1907 replication efficiency for BIER will be as low as that for BIER-TE in 1908 this approach. 1910 5.3.6. Example bit allocations 1912 5.3.6.1. With BIER 1914 Consider a network setup with a BSL of 256 for a network topology as 1915 shown in Figure 17. The network has 6 areas, each with 170 BFERs, 1916 connecting via a core with 4 (core) BFRs. To address all BFERs with 1917 BIER, 4 SIs are required. To send a BIER packet to all BFER in the 1918 network, 4 copies need to be sent by the BFIR. On the BFIR it does 1919 not make a difference how the BFR-ids are allocated to BFER in the 1920 network, but for efficiency further down in the network it does make 1921 a difference. 1923 area1 area2 area3 1924 BFR1a BFR1b BFR2a BFR2b BFR3a BFR3b 1925 | \ / \ / | 1926 ................................ 1927 . Core . 1928 ................................ 1929 | / \ / \ | 1930 BFR4a BFR4b BFR5a BFR5b BFR6a BFR6b 1931 area4 area5 area6 1933 Figure 17: Scaling BIER-TE bits by reuse 1935 With random allocation of BFR-id to BFER, each receiving area would 1936 (most likely) have to receive all 4 copies of the BIER packet because 1937 there would be BFR-id for each of the 4 SIs in each of the areas. 1938 Only further towards each BFER would this duplication subside - when 1939 each of the 4 trees runs out of branches. 1941 If BFR-ids are allocated intelligently, then all the BFER in an area 1942 would be given BFR-id with as few as possible different SIs. Each 1943 area would only have to forward one or two packets instead of 4. 1945 Given how networks can grow over time, replication efficiency in an 1946 area will then also go down over time when BFR-ids are only allocated 1947 sequentially, network wide. An area that initially only has BFR-id 1948 in one SI might end up with many SIs over a longer period of growth. 1949 Allocating SIs to areas with initially sufficiently many spare bits 1950 for growths can help to alleviate this issue. Or renumber BFERs 1951 after network expansion. In this example one may consider to use 6 1952 SIs and assign one to each area. 1954 This example shows that intelligent BFR-id allocation within at least 1955 sub-domain 0 can even be helpful or even necessary in BIER. 1957 5.3.6.2. With BIER-TE 1959 In BIER-TE one needs to determine a subset of the physical topology 1960 and attached BFERs so that the "desired" representation of this 1961 topology and the BFER fit into a single BitString. This process 1962 needs to be repeated until the whole topology is covered. 1964 Once bits/SIs are assigned to topology and BFERs, BFR-id is just a 1965 derived set of identifiers from the operator/BIER-TE Controller as 1966 explained above. 1968 Every time that different sub-topologies have overlap, bits need to 1969 be repeated across the BitStrings, increasing the overall amount of 1970 bits required across all BitString/SIs. In the worst case, one 1971 assigns random subsets of BFERs to different SIs. This will result 1972 in an outcome much worse than in (non-TE) BIER: It maximizes the 1973 amount of unnecessary topology overlap across SI and therefore 1974 reduces the number of BFER that can be reached across each individual 1975 SI. Intelligent BFER to SI assignment and selecting specific 1976 "desired" subtopologies can minimize this problem. 1978 To set up BIER-TE efficiently for the topology of Figure 17, the 1979 following bit allocation method can be used. This method can easily 1980 be expanded to other, similarly structured larger topologies. 1982 Each area is allocated one or more SIs depending on the number of 1983 future expected BFERs and number of bits required for the topology in 1984 the area. In this example, 6 SIs, one per area. 1986 In addition, we use 4 bits in each SI: bia, bib, bea, beb: (b)it 1987 (i)ngress (a), (b)it (i)ngress (b), (b)it (e)gress (a), (b)it 1988 (e)gress (b). These bits will be used to pass BIER packets from any 1989 BFIR via any combination of ingress area a/b BFR and egress area a/b 1990 BFR into a specific target area. These bits are then set up with the 1991 right forward_routed() adjacencies on the BFIR and area edge BFR: 1993 On all BFIRs in an area j|j=1...6, bia in each BIFT:SI is populated 1994 with the same forward_routed(BFRja), and bib with 1995 forward_routed(BFRjb). On all area edge BFR, bea in 1996 BIFT:SI=k|k=1...6 is populated with forward_routed(BFRka) and beb in 1997 BIFT:SI=k with forward_routed(BFRkb). 1999 For BIER-TE forwarding of a packet to a subset of BFERs across all 2000 areas, a BFIR would create at most 6 copies, with SI=1...SI=6, In 2001 each packet, the bits indicate bits for topology and BFER in that 2002 topology plus the four bits to indicate whether to pass this packet 2003 via the ingress area a or b border BFR and the egress area a or b 2004 border BFR, therefore allowing path steering for those two "unicast" 2005 legs: 1) BFIR to ingress area edge and 2) core to egress area edge. 2006 Replication only happens inside the egress areas. For BFER in the 2007 same area as in the BFIR, these four bits are not used. 2009 5.3.7. Summary 2011 BIER-TE can, like BIER, support multiple SIs within a sub-domain. 2012 This allows to apply the mapping BFR-id = SI * BSL + BP. This allows 2013 to re-use the BIER architecture concept of BFR-id and therefore 2014 minimize BIER-TE specific functions in possible BIER layer control 2015 plane mechanisms with BIER-TE, including flow overlay methods and 2016 BIER header fields. 2018 The number of BFIR/BFER possible in a sub-domain is smaller than in 2019 BIER because BIER-TE uses additional bits for topology. 2021 Sub-domains (SDs) in BIER-TE can be used like in BIER to create more 2022 efficient replication to known subsets of BFERs. 2024 Assigning bits for BFERs intelligently into the right SI is more 2025 important in BIER-TE than in BIER because of replication efficiency 2026 and overall amount of bits required. 2028 6. Security Considerations 2030 If [RFC8296] is used, BIER-TE shares its security considerations. 2032 BIER-TE shares the security considerations of BIER, [RFC8279], with 2033 the following overriding or additional considerations. 2035 BIER-TE forwarding explicitly supports unicast "tunneling" of BIER 2036 packets via forward_routed() adjacencies. The BIER domain security 2037 model is based on a subset of interfaces on a BFR that connect to 2038 other BFRs of the same BIER domain. For BIER-TE, this security model 2039 equally applies to such unicast "tunneled" BIER packets. This does 2040 not only include the need to filter received unicast "tunneled" BIER 2041 packets to prohibit injection of such "tunneled" BIER packets from 2042 outside the BIER domain, but also prohibiting forward_routed() 2043 adjacencies to leak BIER packets from the BIER domain. It SHOULD be 2044 possible to configure interfaces to be part of a BIER domain solely 2045 for sending and receiving of unicast "tunneled" BIER packets even if 2046 the interface can not send/receive BIER encapsulated packets. 2048 In BIER, the standardized methods for the routing underlays are IGPs 2049 with extensions to distribute BFR-ids and BFR-prefixes. [RFC8401] 2050 specifies the extensions for IS-IS and [RFC8444] specifies the 2051 extensions for OSPF. Attacking the protocols for the BIER routing 2052 underlay or (non-TE) BIER layer control plane, or impairment of any 2053 BFR in a domain may lead to successful attacks against the results of 2054 the routing protocol, enabling DoS attacks against paths or the 2055 addressing (BFR-id, BFR-prefixes) used by BIER. 2057 The reference model for the BIER-TE layer control plane is a BIER-TE 2058 controller. When such a controller is used, impairment of an 2059 individual BFR in a domain causes no impairment of the BIER-TE 2060 control plane on other BFRs. If a routing protocol is used to 2061 support forward_routed() adjacencies, then this is still an attack 2062 vector as in BIER, but only for BIER-TE forward_routed() adjacencies, 2063 and not other adjacencies. 2065 Whereas IGP routing protocols are most often not well secured through 2066 cryptographic authentication and confidentiality, communications 2067 between controllers and routers such as those to be considered for 2068 the BIER-TE controller/control-plane can be and are much more 2069 commonly secured with those security properties, for example by using 2070 Secure SHell (SSH), [RFC4253] for NETCONF ([RFC6242]), or via 2071 Transport Layer Security (TLS), such as [RFC8253] for PCEP, 2072 [RFC5440], or [RFC7589] for NETCONF. BIER-TE controllers SHOULD use 2073 security equal to or better than these mechanisms. 2075 When any of these security mechanisms/protocols are used for 2076 communications between a BIER-TE controller and BFRs, their security 2077 considerations apply to BIER-TE. In addition, the security 2078 considerations of PCE, [RFC4655] apply. 2080 The most important attack vector in BIER-TE is misconfiguration, 2081 either on the BFR themselves or via the BIER-TE controller. 2082 Forwarding entries with DNC could be set up to create persistent 2083 loops, in which packets only expire because of TTL. To minimize the 2084 impact of such attacks (or more likely unintentional misconfiguration 2085 by operators and/or bad BIER-TE controller software), the BIER-TE 2086 forwarding rules are defined to be as strict in clearing bits as 2087 possible. The clearing of all bits with an adjacency on a BFR 2088 prohibits that a looping packet creates additional packet 2089 amplification through the misconfigured loop on the packet's second 2090 or further times around the loop, because all relevant adjacency bits 2091 would have been cleared on the first round through the loop. In 2092 result, BIER-TE has the same degree of looping packets as possible 2093 with unintentional or malicious loops in the routing underlay with 2094 BIER or even with unicast traffic. 2096 Deployments where BIER-TE would likely be beneficial may include 2097 operational models where actual configuration changes from the 2098 controller are only required during non-production phases of the 2099 network's life-cycle, such as in embedded networks or in 2100 manufacturing networks during e.g. plant reworking/repairs. In these 2101 type of deployments, configuration changes could be locked out when 2102 the network is in production state and could only be (re-)enabled 2103 through reverting the network/installation into non-production state. 2104 Such security designs would not only allow to provide additional 2105 layers of protection against configuration attacks, but would 2106 foremost protect the active production process from such 2107 configuration attacks. 2109 7. IANA Considerations 2111 This document requests no action by IANA. 2113 8. Acknowledgements 2115 The authors would like to thank Greg Shepherd, Ijsbrand Wijnands, 2116 Neale Ranns, Dirk Trossen, Sandy Zheng, Lou Berger, Jeffrey Zhang, 2117 Carsten Borman and Wolfgang Braun for their reviews and suggestions. 2119 Special thanks to Xuesong Geng for shepherding the document and for 2120 IESG review/suggestions by Alvaro Retana (responsible AD/RTG), 2121 Benjamin Kaduk (SEC), Tommy Pauly (TSV), Zaheduzzaman Sarker (TSV), 2122 Eric Vyncke (INT), Martin Vigoureux (RTG), Robert Wilton (OPS), Eric 2123 Kline (INT), Lars Eggert (GEN), Roman Danyliv (SEC), Ines Robles 2124 (RTGDIR), Robert Sparks (Gen-ART), Yingzhen Qu (RTGdir), Martin Duke 2125 (TSV). 2127 9. Change log [RFC Editor: Please remove] 2129 draft-ietf-bier-te-arch: 2131 13: 2133 Changed Gregs author association/email. 2135 Fixed Nits in -12 from Ben Kaduk. 2137 Fixed Alvaro's concerns: (1) Removed references to SR in Abstract/ 2138 Overview (2) removed section 4.5. 2140 12: 2142 AD review Alvaro Retana. 2144 Various textual/editorial nits including adding () to all 2145 instances of forwarding adjacency name instances. 2147 3.1 Added new paragraph outlining possible use of BGP as RR in 2148 BIER-TE controller as core of multicast flow overlay component of 2149 BIER-TE. 2151 3.2 added xref's to relevant sections to the listed control plane 2152 points. 2154 4.1 rewrote paragraphs of 4.1 leading up to Figure 4. to eliminate 2155 any confusion in how the BIFT work and how it compares to the 2156 notions in rfc8279, as well as better linking it to the 2157 Pseudocode. 2159 Moved SR section into appendix. 2161 TSV review Martin Duke. 2163 Text/editorial nits. 2165 4.4 improved text describing handling of F-BM. 2167 RTGdir review Yingzhen Qu. 2169 Various text/editorial nits. 2171 Added notion that BitStrings represent loop free tree for packet 2172 to abstract and intro. 2174 Various text nit and editorial improvements. 2176 Fixed some BFR-id field -> BFIR-id field mistakes. 2178 Capitalized NETCONF/RESTCONF/YANG, added RFC references. 2180 Improved Figure 16 with explicitly two links into BFR3 and 2181 explanatory text. 2183 Gen-ART review Robert Sparks. 2185 Various textual nits, editorial improvements. 2187 3.2 Introduced terms "BIER-TE topology control" and "BIER-TE tree 2188 control" for the two functional components of the control plane. 2190 3.2.1 - 3.2 change introduces the open RFC-editor issue of 2191 appropriate xrfs (to be resolved by RFC-editor). 2193 3.3 Rewrote last paragraph to better describe loop prevention 2194 through clearing of bits in BitString. 2196 4.1 Fixed up text/formula describing mapping between bfr-id, SI:BP 2197 and SI,BSL and BP. Fix offset bug. 2199 5.3.6.2 Improved description paragraph explaining overlap of 2200 topology for different SI. 2202 5.3.7 Improved first summary paragraph. 2204 7. Rephrased applicability statement of control plane protocol 2205 security considerations to BIER-TE security. 2207 RTGDIR review Ines Robles. 2209 Fixed up adjacencies in Example 2 and explanation text to be 2210 explicit about which BFR not only passes, but also receives the 2211 packet. 2213 7. (security considerations). Added paragraph about 2214 forward_routed() and prohibiting BIER packet leaking in/out of 2215 domain. 2217 IESG review Roman Danyliv (SEC). 2219 Several textual/sentence nits/editorials. 2221 IESG review Lars Eggert (GEN). 2223 Various good editorial word fixed. 2225 Pointer to non-false-positive bloom filter work that looks like it 2226 happened after our IETF discussions documented in this doc, so 2227 will not add it to doc, but here is URL for folks interested: 2228 https://ieeexplore.ieee.org/document/8486415. 2230 Did not change "native" to a different word for inclusivity 2231 because of my worry there is no estavblished single replacement 2232 word, making reading/searching/understanding more difficult. 2234 IESG review Martin Vigeureux (RTG). 2236 Added back reference to RFC8402. Textual fixes. 2238 IESG review Eric Kline (INT). 2240 2.1 Fixed typo in BFR* explanations. 2242 4.3 Added explanatio about MTU handling. 2244 IESG review Eric Vyncke (INT). 2246 Fixed up initial text to introduce various abbreviations. 2248 2.4 refined wording to "with the _intent_ to easily build common 2249 forwarding planes...". 2251 4.2.3 refined text about entropy in ECMP - now taken text from 2252 rfc8279. 2254 IESG review Zaheduzzaman Sarker (TSV). 2256 5.1.7 Refined text explaining documentation of ECMP algorithm. 2258 5.3.6.2. fixed range of areas/SI over which to build the example 2259 large network BPs - removed explanation of the large network shown 2260 to be only used for sources in area 1 (IPTV), because it was a 2261 stale explanation. 2263 IESG review Ben Kaduk (round 2): 2265 4.4 Advanced pseudocode still had one wrong "~". Root cause seems 2266 to have been day 0 problem in pseudocode written for -01, "~" was 2267 inserted in the wrong one of two code lines. Also enhanced 2268 textual description and comments in pseudocode, changed variable 2269 name AdjacentBits to PktAdjacentBits to avoid confusion with 2270 AdjacentBits[SI]. 2272 5.1.3 Rewrote last two paragraphs explaining the sharing of bit 2273 positions for lead-BFER hopefully better. Also detailled how it 2274 interacts with other optimizations and the type of payload BIER-TE 2275 packets may carry. 2277 4.4 (from Carsten Borman) changed spacing in pseudocode to be 2278 consistent. Fixed {VRF}, clarified pseudocode object syntax, 2279 typos. 2281 11: IESG review Ben Kaduk, summary: 2283 One discuss for bug in pseudocode. turned out to be one cahrcter 2284 typo. 2286 Added (non-TE) prefix in places where BIER by itsels had to be 2287 better disambiguated. 2289 enhanced text for hub-and-spoke to indicate we're only talking 2290 about hub to spoke traffic. 2292 long list ot language fixes/improvement (nits). Thanks a lot!. 2294 add suggestion to SHOULD use known confidentiality protocols 2295 between controller and BFR. 2297 10: AD review Alvaro Retana, summary: 2299 Note: rfcdiff shows more changes than actually exist because text 2300 moved around. 2302 Summary: 2304 1. restructuring: merged all controller sections under common 2305 controller ops main section, moved unfitting stuff out to 2306 other parts of doc. Split Intro section into Overview and 2307 Intro. Shortened Abstract, moved text into Overview, added 2308 sections overview. 2310 2. enhanced/rewrote: 2.3 Comparison with -> Relationship to BIER- 2311 TE 2313 3. enhanced/rewrote: 3.2 BIER-TE controller -> BIER-TE control 2314 plane, 3.2.1 BIER-TE controller, for consistency with rfc8279 2316 4. additional subsections for Alvaros asks 2318 5. added to: 3.3 BIER-TE forwarding plane (consistency with 2319 rfc8279) 2321 6. Enhanced description of 4.3/encap considerations to better 2322 explain how BIER/BIER-TE can run together. 2324 Notation: Markers (a),(b),... at end of points are references from 2325 the review discussion with Alvaro to the changes made. 2327 Details:. 2329 Throughout text: changed term spelling to rfc8279 - bit positions, 2330 sub-domain, ... (i). 2332 Reset changed to clear, also DNR changed to DNC (Do Not Clear) 2333 (q). 2335 Abstract: Shortened. Removed name explanation note (Tree 2336 Engineering), (a). 2338 1. Introduction -> Overview: Moved important explanation 2339 paragraph from abstract to Introduction. Fixed text, (a). 2341 Added bullet point list explanation of structure of document (e). 2343 Renamed to Overview because that is now more factually correct. 2345 1.1. Fixed bug in example adding bit p15.(l). 2347 2. (New - Introduction): Moved section 1.1 - 1.3 (examples, 2348 comparison with BIER-TE) from Introduction into new "Overview" 2349 section. Primarily so that "requirements language" section (at 2350 end of Introduction) is not in middle of document after all the 2351 Introduction. 2353 2.1 Removed discussion of encap, moved to 4.2.2 (m). 2355 2.2 enhanced paragraph suggesting native/overlay topology types, 2356 also sugest type hybrid (n). 2358 2.3 Overhauled comparison text BIER/BIER-TE, structured into 2359 common, different, not-required-by-te, integration-bier-bier-te. 2360 Changed title to "Relationship" to allow including last point. 2361 (f). 2363 2.4 moved Hardware forwarding comparison section into section 2 to 2364 allow coalescing of sections into section 5 about the controller 2365 operations (hardware forwarding was in the middle of it, wrong 2366 place). Shortened/improved third paragraph by pointing to BIFT as 2367 deciding element for selection between BIER/BIER-TE. Removed 2368 notion of experimentation (this now targets standard) (g). 2370 3. (Components): Aligned component name and descriptions better 2371 with RFC8279. Now describe exactly same three layers. BIER layer 2372 constituted from BIER-TE control plane and BIER-TE forwarding 2373 plane. BIER-TE controller is now simply component of BIER-TE 2374 control plane. (b). 2376 3.1. shortened/improved paragraph explaining use of SI:BP instead 2377 of also bfr-id as index into BIFT, rewrote paragraph talking about 2378 reuse of BPs(o). 2380 3.2. rewrote explanation of BIER-TE control plane in the style of 2381 RFC8729 Section 4.2 (BIER layer) with numbered points. Note that 2382 RFC8729 mixes control and forwarding plane bullet points (this doc 2383 does not). Merged text from old sections 2.2.1 and 2.2.3 into 2384 list. (b). 2386 3.2.1. Expanded/improved explanation of BIER-TE Controller (b). 2388 3.2.1.1. Added subsection for topology discovery and creation 2389 (d). 2391 3.2.1.2. Added subsection for engineered BitStrings as key novel 2392 aspect not found in BIER. (X). 2394 3.3. Added numbered list for components of BIER-TE forwarding 2395 plane (completing the comparable text from RFC8729 Section 4.2). 2397 3.4 Alvaro does not mind additional example, fixed bugs. 2399 3.5 Removed notion about using IGP BIER extensions for BIER-TE, 2400 such as BIFT address ranges. After -10 making use of BIFT 2401 clearer, it now looks to authors as if use of IGP extensions would 2402 not be beneficial, as long as we do need to use the BIER-TE 2403 controller, e.g. unlike in BIER, a BFR could not learn from the 2404 IGP information what traffic to send towards a particular BIFT-ID, 2405 but instead that is the core of what the controller needs to 2406 provide. 2408 4.2.2 Improved text to explain requirement to identify BIER-TE in 2409 the tunnel encap and compress description of use-cases (m). 2411 4.2.3 enhanced ECMP text (p). 2413 4.3. rewrote most of Encapsulation Considerations to better 2414 explain to Alvaros question re sharing or not sharing SD via BIER/ 2415 BIER-TE. Added reference to I-D.ietf-bier-non-mpls-bift-encoding 2416 as a very helpful example. (f). 2418 4.3 Renamed title to "...Co-Existence with BIER" as this is what 2419 it is about and to help finding it from abstract/intro ("co- 2420 exist") (j). 2422 4.4. Moved BIER-TE Forwarding Pseudocode here to coalesce text 2423 logically. Changed text to better compare with BIER pseudo 2424 forwarding code. Numerical list of how F-BM works for BIER-TE. 2425 Removed efficiency comparison with BIER (too difficult to provide 2426 sufficient justification, derails from focus of section) (j). 2428 4.6. (Requirements) Restructured: Removed notion of "basic" BIER- 2429 TE forwarding, simply referring to it now as "mandatory" BIER-TE 2430 forwarding. Cleaned up text to have requirements for different 2431 adjacencies in different paragraphs. (c). 2433 5. Created new main section "BIER-TE Controller operational 2434 considerations", coalesced old sections 4., 5., 7. into this new 2435 main section. No text changes. (k). 2437 5.1.9 Added new separate picture instead of referring to a picture 2438 later in text, adjusted text (r). 2440 5.3.2 Changed title to not include word "comparison" to avoid this 2441 being accounted against Alvaros concern about scattering 2442 comparison (IMHO text already has little comparison, so title was 2443 misleading) (h). 2445 co-authors internal review: 2447 4.4 Added xref to Figure 5. 2449 5.2.1 Duplicated ring picture, added visuals for described 2450 miswiring (s). 2452 5.2.2 replace "topology" with graph (wrong word). 2454 5.3.3 rewrote explanation of how to map BFR-id to SI:BP and assign 2455 them, clarified BFR-id is option. Retitled to better explain 2456 scope of section. 2458 5.3.4 Removed considerations in 5.3.4 for sharing BFR-id across 2459 BIER/BIER-TE (t), changed title to explain how BFIR/BIER-TE 2460 controller interactions need some form of identifying BFR but this 2461 does not have to be BFR-id. 2463 7. Added new security considerations (u). 2465 09: Incorporated fixes for feedback from Shepherd (Xuesong Geng). 2467 Added references for Bloom Filters and Rate Controlled Service 2468 Disciplines. 2470 1.1 Fixed numbering of example 1 topology explanation. Improved 2471 language on second example (less abbreviating to avoid confusion 2472 about meaning). 2474 1.2 Improved explanation of BIER-TE topology, fixed terminology of 2475 graphs (BIER-TE topology is a directed graph where the edges are 2476 the adjacencies). 2478 2.4 Fixed and amended routing underlay explanations: detailed why 2479 no need for BFER routing underlay routing protocol extensions, but 2480 potential to re-use BIER routing underlay routing protocol 2481 extensions for non-BFER related extensions. 2483 3.1 Added explanation for VRF and its use in adjacencies. 2485 08: Incorporated (with hopefully acceptable fixes) for Lou 2486 suggested section 2.5, TE considerations. 2488 Fixes are primarily to the point to a) emphasize that BIER-TE does 2489 not depend on the routing underlay unless forward_routed() 2490 adjacencies are used, and b) that the allocation and tracking of 2491 resources does not explicitly have to be tied to BPs, because they 2492 are just steering labels. Instead, it would ideally come from 2493 per-hop resource management that can be maintained only via local 2494 accounting in the controller. 2496 07: Further reworking text for Lou. 2498 Renamed BIER-PE to BIER-TE standing for "Tree Engineering" after 2499 votes from BIER WG. 2501 Removed section 1.1 (introduced by version 06) because not 2502 considered necessary in this doc by Lou (for framework doc). 2504 Added [RFC editor pls. remove] Section to explain name change to 2505 future reviewers. 2507 06: Concern by Lou Berger re. BIER-TE as full traffic engineering 2508 solution. 2510 Changed title "Traffic Engineering" to "Path Engineering" 2512 Added intro section of relationship BIER-PE to traffic 2513 engineering. 2515 Changed "traffic engineering" term in text" to "path engineering", 2516 where appropriate 2518 Other: 2520 Shortened "BIER-TE Controller Host" to "BIER-TE Controller". 2521 Fixed up all instances of controller to do this. 2523 05: Review Jeffrey Zhang. 2525 Part 2: 2527 4.3 added note about leaf-BFER being also a propery of routing 2528 setup. 2530 4.7 Added missing details from example to avoid confusion with 2531 routed adjacencies, also compressed explanatory text and better 2532 justification why seed is explicitly configured by controller. 2534 4.9 added section discussing generic reuse of BP methods. 2536 4.10 added section summarizing BP optimizations of section 4. 2538 6. Rewrote/compressed explanation of comparison BIER/BIER-TE 2539 forwarding difference. Explained benefit of BIER-TE per-BP 2540 forwarding being independent of forwarding for other BPs. 2542 Part 1: 2544 Explicitly ue forwarded_connected adjcency in ECMP adjcency 2545 examples to avoid confusion. 2547 4.3 Add picture as example for leav vs. non-leaf BFR in topology. 2548 Improved description. 2550 4.5 Exampe for traffic that can be broadcast -> for single BP in 2551 hub&spoke. 2553 4.8.1 Simplified example picture for routed adjacency, explanatory 2554 text. 2556 Review from Dirk Trossen: 2558 Fixed up explanation of ICC paper vs. bloom filter. 2560 04: spell check run. 2562 Addded remaining fixes for Sandys (Zhang Zheng) review: 2564 4.7 Enhance ECMP explanations: 2566 example ECMP algorithm, highlight that doc does not standardize 2567 ECMP algorithm. 2569 Review from Dirk Trossen: 2571 1. Added mentioning of prior work for traffic engineered paths 2572 with bloom filters. 2574 2. Changed title from layers to components and added "BIER-TE 2575 control plane" to "BIER-TE Controller" to make it clearer, what it 2576 does. 2578 2.2.3. Added reference to I-D.ietf-bier-multicast-http-response 2579 as an example solution. 2581 2.3. clarified sentence about resetting BPs before sending copies 2582 (also forgot to mention DNR here). 2584 3.4. Added text saying this section will be removed unless IESG 2585 review finds enough redeeming value in this example given how -03 2586 introduced section 1.1 with basic examples. 2588 7.2. Removed explicit numbers 20%/80% for number of topology bits 2589 in BIER-TE, replaced with more vague (high/low) description, 2590 because we do not have good reference material Added text saying 2591 this section will be removed unless IESG review finds enough 2592 redeeming value in this example given how -03 introduced section 2593 1.1 with basic examples. 2595 many typos fixed. Thanks a lot. 2597 03: Last call textual changes by authors to improve readability: 2599 removed Wolfgang Braun as co-authors (as requested). 2601 Improved abstract to be more explanatory. Removed mentioning of 2602 FRR (not concluded on so far). 2604 Added new text into Introduction section because the text was too 2605 difficult to jump into (too many forward pointers). This 2606 primarily consists of examples and the early introduction of the 2607 BIER-TE Topology concept enabled by these examples. 2609 Amended comparison to SR. 2611 Changed syntax from [VRF] to {VRF} to indicate its optional and to 2612 make idnits happy. 2614 Split references into normative / informative, added references. 2616 02: Refresh after IETF104 discussion: changed intended status back 2617 to standard. Reasoning: 2619 Tighter review of standards document == ensures arch will be 2620 better prepared for possible adoption by other WGs (e.g. DetNet) 2621 or std. bodies. 2623 Requirement against the degree of existing implementations is self 2624 defined by the WG. BIER WG seems to think it is not necessary to 2625 apply multiple interoperating implementations against an 2626 architecture level document at this time to make it qualify to go 2627 to standards track. Also, the levels of support introduced in -01 2628 rev. should allow all BIER forwarding engines to also be able to 2629 support the base level BIER-TE forwarding. 2631 01: Added note comparing BIER and SR to also hopefully clarify 2632 BIER-TE vs. BIER comparison re. SR. 2634 - added requirements section mandating only most basic BIER-TE 2635 forwarding features as MUST. 2637 - reworked comparison with BIER forwarding section to only 2638 summarize and point to pseudocode section. 2640 - reworked pseudocode section to have one pseudocode that mirrors 2641 the BIER forwarding pseudocode to make comparison easier and a 2642 second pseudocode that shows the complete set of BIER-TE 2643 forwarding options and simplification/optimization possible vs. 2644 BIER forwarding. Removed MyBitsOfInterest (was pure 2645 optimization). 2647 - Added captions to pictures. 2649 - Part of review feedback from Sandy (Zhang Zheng) integrated. 2651 00: Changed target state to experimental (WG conclusion), updated 2652 references, mod auth association. 2654 - Source now on https://www.github.com/toerless/bier-te-arch 2656 - Please open issues on the github for change/improvement requests 2657 to the document - in addition to posting them on the list 2658 (bier@ietf.). Thanks!. 2660 draft-eckert-bier-te-arch: 2662 06: Added overview of forwarding differences between BIER, BIER- 2663 TE. 2665 05: Author affiliation change only. 2667 04: Added comparison to Live-Live and BFIR to FRR section 2668 (Eckert). 2670 04: Removed FRR content into the new FRR draft [I-D.eckert-bier- 2671 te-frr] (Braun). 2673 - Linked FRR information to new draft in Overview/Introduction 2675 - Removed BTAFT/FRR from "Changes in the network topology" 2677 - Linked new draft in "Link/Node Failures and Recovery" 2678 - Removed FRR from "The BIER-TE Forwarding Layer" 2680 - Moved FRR section to new draft 2682 - Moved FRR parts of Pseudocode into new draft 2684 - Left only non FRR parts 2686 - removed FrrUpDown(..) and //FRR operations in 2687 ForwardBierTePacket(..) 2689 - New draft contains FrrUpDown(..) and ForwardBierTePacket(Packet) 2690 from bier-arch-03 2692 - Moved "BIER-TE and existing FRR to new draft 2694 - Moved "BIER-TE and Segment Routing" section one level up 2696 - Thus, removed "Further considerations" that only contained this 2697 section 2699 - Added Changes for version 04 2701 03: Updated the FRR section. Added examples for FRR key concepts. 2702 Added BIER-in-BIER tunneling as option for tunnels in backup 2703 paths. BIFT structure is expanded and contains an additional 2704 match field to support full node protection with BIER-TE FRR. 2706 03: Updated FRR section. Explanation how BIER-in-BIER 2707 encapsulation provides P2MP protection for node failures even 2708 though the routing underlay does not provide P2MP. 2710 02: Changed the definition of BIFT to be more inline with BIER. 2711 In revs. up to -01, the idea was that a BIFT has only entries for 2712 a single BitString, and every SI and sub-domain would be a 2713 separate BIFT. In BIER, each BIFT covers all SI. This is now 2714 also how we define it in BIER-TE. 2716 02: Added Section 5.3 to explain the use of SI, sub-domains and 2717 BFR-id in BIER-TE and to give an example how to efficiently assign 2718 bits for a large topology requiring multiple SI. 2720 02: Added further detailed for rings - how to support input from 2721 all ring nodes. 2723 01: Fixed BFIR -> BFER for section 4.3. 2725 01: Added explanation of SI, difference to BIER ECMP, 2726 consideration for Segment Routing, unicast FRR, considerations for 2727 encapsulation, explanations of BIER-TE Controller and CLI. 2729 00: Initial version. 2731 10. References 2733 10.1. Normative References 2735 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2736 Requirement Levels", BCP 14, RFC 2119, 2737 DOI 10.17487/RFC2119, March 1997, 2738 . 2740 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2741 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2742 May 2017, . 2744 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 2745 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 2746 Explicit Replication (BIER)", RFC 8279, 2747 DOI 10.17487/RFC8279, November 2017, 2748 . 2750 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 2751 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 2752 for Bit Index Explicit Replication (BIER) in MPLS and Non- 2753 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2754 2018, . 2756 10.2. Informative References 2758 [Bloom70] Bloom, B. H., "Space/time trade-offs in hash coding with 2759 allowable errors", Comm. ACM 13(7):422-6, July 1970, 2760 . 2762 [I-D.eckert-bier-te-frr] 2763 Eckert, T., Cauchie, G., Braun, W., and M. Menth, 2764 "Protection Methods for BIER-TE", Work in Progress, 2765 Internet-Draft, draft-eckert-bier-te-frr-03, 5 March 2018, 2766 . 2769 [I-D.ietf-bier-multicast-http-response] 2770 Trossen, D., Rahman, A., Wang, C., and T. Eckert, 2771 "Applicability of BIER Multicast Overlay for Adaptive 2772 Streaming Services", Work in Progress, Internet-Draft, 2773 draft-ietf-bier-multicast-http-response-06, 10 July 2021, 2774 . 2777 [I-D.ietf-bier-non-mpls-bift-encoding] 2778 Wijnands, I., Mishra, M., Xu, X., and H. Bidgoli, "An 2779 Optional Encoding of the BIFT-id Field in the non-MPLS 2780 BIER Encapsulation", Work in Progress, Internet-Draft, 2781 draft-ietf-bier-non-mpls-bift-encoding-04, 30 May 2021, 2782 . 2785 [I-D.ietf-bier-te-yang] 2786 Zhang, Z., Wang, C., Chen, R., Hu, F., Sivakumar, M., and 2787 H. Chen, "A YANG data model for Tree Engineering for Bit 2788 Index Explicit Replication (BIER-TE)", Work in Progress, 2789 Internet-Draft, draft-ietf-bier-te-yang-04, 7 November 2790 2021, . 2793 [I-D.ietf-roll-ccast] 2794 Bergmann, O., Bormann, C., Gerdes, S., and H. Chen, 2795 "Constrained-Cast: Source-Routed Multicast for RPL", Work 2796 in Progress, Internet-Draft, draft-ietf-roll-ccast-01, 30 2797 October 2017, . 2800 [I-D.ietf-teas-rfc3272bis] 2801 Farrel, A., "Overview and Principles of Internet Traffic 2802 Engineering", Work in Progress, Internet-Draft, draft- 2803 ietf-teas-rfc3272bis-16, 24 March 2022, 2804 . 2807 [ICC] Reed, M. J., Al-Naday, M., Thomos, N., Trossen, D., 2808 Petropoulos, G., and S. Spirou, "Stateless multicast 2809 switching in software defined networks", IEEE 2810 International Conference on Communications (ICC), Kuala 2811 Lumpur, Malaysia, 2016, May 2016, 2812 . 2814 [RCSD94] Zhang, H. and D. Domenico, "Rate-Controlled Service 2815 Disciplines", Journal of High-Speed Networks, 1994, May 2816 1994, . 2818 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2819 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 2820 January 2006, . 2822 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 2823 Reflection: An Alternative to Full Mesh Internal BGP 2824 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 2825 . 2827 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 2828 Computation Element (PCE)-Based Architecture", RFC 4655, 2829 DOI 10.17487/RFC4655, August 2006, 2830 . 2832 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 2833 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 2834 DOI 10.17487/RFC5440, March 2009, 2835 . 2837 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2838 and A. Bierman, Ed., "Network Configuration Protocol 2839 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2840 . 2842 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2843 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2844 . 2846 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 2847 NETCONF Protocol over Transport Layer Security (TLS) with 2848 Mutual X.509 Authentication", RFC 7589, 2849 DOI 10.17487/RFC7589, June 2015, 2850 . 2852 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 2853 S. Ray, "North-Bound Distribution of Link-State and 2854 Traffic Engineering (TE) Information Using BGP", RFC 7752, 2855 DOI 10.17487/RFC7752, March 2016, 2856 . 2858 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2859 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2860 . 2862 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 2863 Replication Tunnels in Multicast VPN", RFC 7988, 2864 DOI 10.17487/RFC7988, October 2016, 2865 . 2867 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2868 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2869 . 2871 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 2872 "PCEPS: Usage of TLS to Provide a Secure Transport for the 2873 Path Computation Element Communication Protocol (PCEP)", 2874 RFC 8253, DOI 10.17487/RFC8253, October 2017, 2875 . 2877 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2878 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2879 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2880 2018, . 2882 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 2883 Zhang, "Bit Index Explicit Replication (BIER) Support via 2884 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 2885 . 2887 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 2888 Decraene, B., Litkowski, S., and R. Shakir, "Segment 2889 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 2890 July 2018, . 2892 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 2893 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 2894 Extensions for Bit Index Explicit Replication (BIER)", 2895 RFC 8444, DOI 10.17487/RFC8444, November 2018, 2896 . 2898 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 2899 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 2900 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 2901 2019, . 2903 Appendix A. BIER-TE and Segment Routing (SR) 2905 SR ([RFC8402]) aims to enable lightweight path steering via loose 2906 source routing. Compared to its more heavy-weight predecessor RSVP- 2907 TE, SR does for example not require per-path signaling to each of 2908 these hops. 2910 BIER-TE supports the same design philosophy for multicast. Like in 2911 SR, it relies on source-routing - via the definition of a BitString. 2912 Like SR, it only requires to consider the "hops" on which either 2913 replication has to happen, or across which the traffic should be 2914 steered (even without replication). Any other hops can be skipped 2915 via the use of routed adjacencies. 2917 BIER-TE bit position (BP) can be understood as the BIER-TE equivalent 2918 of "forwarding segments" in SR, but they have a different scope than 2919 SR forwarding segments. Whereas forwarding segments in SR are global 2920 or local, BPs in BIER-TE have a scope that is the group of BFR(s) 2921 that have adjacencies for this BP in their BIFT. This can be called 2922 "adjacency" scoped forwarding segments. 2924 Adjacency scope could be global, but then every BFR would need an 2925 adjacency for this BP, for example a forward_routed() adjacency with 2926 encapsulation to the global SR SID of the destination. Such a BP 2927 would always result in ingress replication though (as in [RFC7988]). 2928 The first BFR encountering this BP would directly replicate to it. 2929 Only by using non-global adjacency scope for BPs can traffic be 2930 steered and replicated on non-ingress BFR. 2932 SR can naturally be combined with BIER-TE and help to optimize it. 2933 For example, instead of defining bit positions for non-replicating 2934 hops, it is equally possible to use segment routing encapsulations 2935 (e.g. SR-MPLS label stacks) for the encapsulation of 2936 "forward_routed" adjacencies. 2938 Note that (non-TE) BIER itself can also be seen to be similar to SR. 2939 BIER BPs act as global destination Node-SIDs and the BIER BitString 2940 is simply a highly optimized mechanism to indicate multiple such SIDs 2941 and let the network take care of effectively replicating the packet 2942 hop-by-hop to each destination Node-SID. What BIER does not allow is 2943 to indicate intermediate hops, or in terms of SR the ability to 2944 indicate a sequence of SID to reach the destination. This is what 2945 BIER-TE and its adjacency scoped BP enables. 2947 Authors' Addresses 2949 Toerless Eckert (editor) 2950 Futurewei Technologies Inc. 2951 2330 Central Expy 2952 Santa Clara, 95050 2953 United States of America 2954 Email: tte+ietf@cs.fau.de 2956 Michael Menth 2957 University of Tuebingen 2958 Email: menth@uni-tuebingen.de 2960 Gregory Cauchie 2961 KOEVOO 2962 Email: gregory@koevoo.tech