idnits 2.17.1 draft-ietf-bier-architecture-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2017) is 2418 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 371 -- Looks like a reference, but probably isn't: '255' on line 371 -- Looks like a reference, but probably isn't: '1' on line 293 -- Looks like a reference, but probably isn't: '65535' on line 277 -- Looks like a reference, but probably isn't: '256' on line 291 -- Looks like a reference, but probably isn't: '512' on line 293 -- Looks like a reference, but probably isn't: '15' on line 370 == Outdated reference: A later version (-11) exists of draft-ietf-bier-mvpn-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IJ. Wijnands, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Experimental E. Rosen, Ed. 5 Expires: March 17, 2018 Juniper Networks, Inc. 6 A. Dolganow 7 Nokia 8 T. Przygienda 9 Juniper Networks, Inc. 10 S. Aldrin 11 Google, Inc. 12 September 13, 2017 14 Multicast using Bit Index Explicit Replication 15 draft-ietf-bier-architecture-08 17 Abstract 19 This document specifies a new architecture for the forwarding of 20 multicast data packets. It provides optimal forwarding of multicast 21 packets through a "multicast domain". However, it does not require a 22 protocol for explicitly building multicast distribution trees, nor 23 does it require intermediate nodes to maintain any per-flow state. 24 This architecture is known as "Bit Index Explicit Replication" 25 (BIER). When a multicast data packet enters the domain, the ingress 26 router determines the set of egress routers to which the packet needs 27 to be sent. The ingress router then encapsulates the packet in a 28 BIER header. The BIER header contains a bitstring in which each bit 29 represents exactly one egress router in the domain; to forward the 30 packet to a given set of egress routers, the bits corresponding to 31 those routers are set in the BIER header. The procedures for 32 forwarding a packet based on its BIER header are specified in this 33 document. Elimination of the per-flow state and the explicit tree- 34 building protocols results in a considerable simplification. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 17, 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. The BFR Identifier and BFR-Prefix . . . . . . . . . . . . . . 6 72 3. Encoding BFR Identifiers in BitStrings . . . . . . . . . . . 7 73 4. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1. The Routing Underlay . . . . . . . . . . . . . . . . . . 10 75 4.2. The BIER Layer . . . . . . . . . . . . . . . . . . . . . 11 76 4.3. The Multicast Flow Overlay . . . . . . . . . . . . . . . 12 77 5. Advertising BFR-ids and BFR-Prefixes . . . . . . . . . . . . 12 78 6. BIER Intra-Domain Forwarding Procedures . . . . . . . . . . . 14 79 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.2. BFR Neighbors . . . . . . . . . . . . . . . . . . . . . . 16 81 6.3. The Bit Index Routing Table . . . . . . . . . . . . . . . 16 82 6.4. The Bit Index Forwarding Table . . . . . . . . . . . . . 17 83 6.5. The BIER Forwarding Procedure . . . . . . . . . . . . . . 18 84 6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 20 85 6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 21 86 6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22 87 6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 24 88 6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 24 89 6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 25 90 6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 27 91 6.9. When Some Nodes do not Support BIER . . . . . . . . . . . 28 92 6.10. Use of Different BitStringLengths within a Domain . . . . 30 93 6.10.1. BitStringLength Compatibility Check . . . . . . . . 32 94 6.10.2. Handling BitStringLength Mismatches . . . . . . . . 33 95 6.10.3. Transitioning from One BitStringLength to Another . 34 97 7. Operational Considerations . . . . . . . . . . . . . . . . . 34 98 7.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 35 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 101 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 102 11. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 36 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 104 12.1. Normative References . . . . . . . . . . . . . . . . . . 38 105 12.2. Informative References . . . . . . . . . . . . . . . . . 38 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 108 1. Introduction 110 This document specifies a new architecture for the forwarding of 111 multicast data packets. The architecture provides optimal forwarding 112 of multicast data packets through a "multicast domain". However, it 113 does not require the use of a protocol for explicitly building 114 multicast distribution trees, and it does not require intermediate 115 nodes to maintain any per-flow state. This architecture is known as 116 "Bit Index Explicit Replication" (BIER). 118 A router that supports BIER is known as a "Bit-Forwarding Router" 119 (BFR). The BIER control plane protocols (see Section 4.2) run within 120 a "BIER domain", allowing the BFRs within that domain to exchange the 121 information needed for them to forward packets to each other using 122 BIER. 124 A multicast data packet enters a BIER domain at a "Bit-Forwarding 125 Ingress Router" (BFIR), and leaves the BIER domain at one or more 126 "Bit-Forwarding Egress Routers" (BFERs). A BFR that receives a 127 multicast data packet from another BFR in the same BIER domain, and 128 forwards the packet to another BFR in the same BIER domain, will be 129 known as a "transit BFR" for that packet. A single BFR may be a BFIR 130 for some multicast traffic while also being a BFER for some multicast 131 traffic and a transit BFR for some multicast traffic. In fact, for a 132 given packet, a BFR may be a BFIR and/or a transit BFR and/or (one 133 of) the BFER(s) for that packet. 135 A BIER domain may contain one or more sub-domains. Each BIER domain 136 MUST contain at least one sub-domain, the "default sub-domain" (also 137 denoted "sub-domain zero"). If a BIER domain contains more than one 138 sub-domain, each BFR in the domain MUST be provisioned to know the 139 set of sub-domains to which it belongs. Each sub-domain is 140 identified by a sub-domain-id in the range [0,255]. 142 For each sub-domain to which a given BFR belongs, if the BFR is 143 capable of acting as a BFIR or a BFER, it MUST be provisioned with a 144 "BFR-id" that is unique within the sub-domain. A BFR-id is a small 145 unstructured positive integer. For instance, if a particular BIER 146 sub-domain contains 1,374 BFRs, each one could be given a BFR-id in 147 the range 1-1374. 149 If a given BFR belongs to more than one sub-domain, it may (though it 150 need not) have a different BFR-id for each sub-domain. 152 When a multicast packet arrives from outside the domain at a BFIR, 153 the BFIR determines the set of BFERs to which the packet will be 154 sent. The BFIR also determines the sub-domain in which the packet 155 will be sent. Determining the sub-domain in which a given packet 156 will be sent is known as "assigning the packet to a sub-domain". 157 Procedures for choosing the sub-domain to which a particular packet 158 is assigned are outside the scope of this document. However, once a 159 particular packet has been assigned to a particular sub-domain, it 160 remains assigned to that sub-domain until it leaves the BIER domain. 161 That is, the sub-domain to which a packet is assigned MUST NOT be 162 changed while the packet is in flight through the BIER domain. 164 Once the BFIR determines sub-domain and the set of BFERs for a given 165 packet, the BFIR encapsulates the packet in a "BIER header". The 166 BIER header contains a bit string in which each bit represents a 167 single BFR-id. To indicate that a particular BFER is to receive a 168 given packet, the BFIR sets the bit corresponding to that BFER's 169 BFR-id in the sub-domain to which the packet has been assigned. We 170 will use term "BitString" to refer to the bit string field in the 171 BIER header. We will use the term "payload" to refer to the packet 172 that has been encapsulated. Thus a "BIER-encapsulated" packet 173 consists of a "BIER header" followed by a "payload". 175 The number of BFERs to which a given packet can be forwarded is 176 limited only by the length of the BitString in the BIER header. 177 Different deployments can use different BitString lengths. We will 178 use the term "BitStringLength" to refer to the number of bits in the 179 BitString. It is possible that some deployment will have more BFERs 180 in a given sub-domain than there are bits in the BitString. To 181 accommodate this case, the BIER encapsulation includes both the 182 BitString and a "Set Identifier" (SI). It is the BitString and the 183 SI together that determine the set of BFERs to which a given packet 184 will be delivered: 186 o by convention, the least significant (rightmost) bit in the 187 BitString is "bit 1", and the most significant (leftmost) bit is 188 "bit BitStringLength". 190 o if a BIER-encapsulated packet has an SI of n, and a BitString with 191 bit k set, then the packet must be delivered to the BFER whose 192 BFR-id (in the sub-domain to which the packet has been assigned) 193 is n*BitStringLength+k. 195 For example, suppose the BIER encapsulation uses a BitStringLength of 196 256 bits. By convention, the least significant (rightmost) bit is 197 "bit 1", and the most significant (leftmost) bit is "bit 256". 198 Suppose that a given packet has been assigned to sub-domain 0, and 199 needs to be delivered to three BFERs, where those BFERs have BFR-ids 200 in sub-domain 0 of 13, 126, and 235 respectively. The BFIR would 201 create a BIER encapsulation with the SI set to zero, and with bits 202 13, 126, and 235 of the BitString set. (All other bits of the 203 BitString would be clear.) If the packet also needs to be sent to a 204 BFER whose BFR-id is 257, the BFIR would have to create a second copy 205 of the packet, and the BIER encapsulation would specify an SI of 1, 206 and a BitString with bit 1 set and all the other bits clear. 208 It is generally advantageous to assign the BFR-ids of a given 209 sub-domain so that as many BFERs as possible can be represented in a 210 single bit string. 212 Suppose a BFR, call it BFR-A, receives a packet whose BIER 213 encapsulation specifies an SI of 0, and a BitString with bits 13, 26, 214 and 235 set. Suppose BFR-A has two BFR neighbors, BFR-B and BFR-C, 215 such that the best path to BFERs 13 and 26 is via BFR-B, but the best 216 path to BFER 235 is via BFR-C. Then BFR-A will replicate the packet, 217 sending one copy to BFR-B and one copy to BFR-C. However, BFR-A will 218 clear bit 235 in the BitString of the packet copy it sends to BFR-B, 219 and will clear bits 13 and 26 in the BitString of the packet copy it 220 sends to BFR-C. As a result, BFR-B will forward the packet only 221 towards BFERs 13 and 26, and BFR-C will forward the packet only 222 towards BFER 235. This ensures that each BFER receives only one copy 223 of the packet. 225 Detailed procedures for forwarding a BIER-encapsulated packet through 226 a BIER domain can be found in Section 6. 228 With this forwarding procedure, a multicast data packet can follow an 229 optimal path from its BFIR to each of its BFERs. Further, since the 230 set of BFERs for a given packet is explicitly encoded into the BIER 231 header, the packet is not sent to any BFER that does not need to 232 receive it. This allows for optimal forwarding of multicast traffic. 233 This optimal forwarding is achieved without any need for transit BFRs 234 to maintain per-flow state, or to run a multicast tree-building 235 protocol. 237 The idea of encoding the set of egress nodes into the header of a 238 multicast packet is not new. For example, [Boivie_Feldman] proposes 239 to encode the set of egress nodes as a set of IP addresses, and 240 proposes mechanisms and procedures that are in some ways similar to 241 those described in the current document. However, since BIER encodes 242 each BFR-id as a single bit in a bit string, it can represent up to 243 128 BFERs in the same number of bits that it would take to carry the 244 IPv6 address of a single BFER. Thus BIER scales to a much larger 245 number of egress nodes per packet. 247 BIER does not require that each transit BFR look up the best path to 248 each BFER that is identified in the BIER header; the number of 249 lookups required in the forwarding path for a single packet can be 250 limited to the number of neighboring BFRs; this can be much smaller 251 than the number of BFERs. See Section 6 (especially Section 6.4) for 252 details. 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 256 document are to be interpreted as described in RFC 2119 [RFC2119]. 258 2. The BFR Identifier and BFR-Prefix 260 Each BFR MUST be assigned a single "BFR-Prefix" for each sub-domain 261 to which it belongs. A BFR's BFR-Prefix MUST be an IP address 262 (either IPv4 or IPv6) of the BFR. It is RECOMMENDED that the 263 BFR-prefix be a loopback address of the BFR. 265 If a BFR belongs to more than one sub-domain, it may (though it need 266 not) have a different BFR-prefix in each sub-domain. 268 All BFR-Prefixes used within a given sub-domain MUST belong to the 269 same address family (either IPv4 or IPv6). 271 The BFR-prefix of a given BFR in a given sub-domain MUST be routable 272 in that sub-domain. Whether a particular BFR-Prefix is routable in a 273 given sub-domain depends on the "routing underlay" associated with 274 that sub-domain. The notion of "routing underlay" is described in 275 Section 4.1. 277 A "BFR Identifier" (BFR-id) is a number in the range [1,65535]. 278 Within a given sub-domain, every BFR that may need to function as a 279 BFIR or BFER MUST have a single BFR-id, which identifies it uniquely 280 within that sub-domain. A BFR that does not need to function as a 281 BFIR or BFER in a given sub-domain does not need to have a BFR-id in 282 that sub-domain. 284 The value 0 is not a legal BFR-id. 286 The procedure for assigning a particular BFR-id to a particular BFR 287 is outside the scope of this document. However, it is RECOMMENDED 288 that the BFR-ids for each sub-domain be assigned "densely" from the 289 numbering space, as this will result in a more efficient encoding 290 (see Section 3). That is, if there are 256 or fewer BFERs, it is 291 RECOMMENDED to assign all the BFR-ids from the range [1,256]. If 292 there are more than 256 BFERs, but less than 512, it is RECOMMENDED 293 to assign all the BFR-ids from the range [1,512], with as few "holes" 294 as possible in the earlier range. However, in some deployments, it 295 may be advantageous to depart from this recommendation; this is 296 discussed further in Section 3. 298 In some deployments, it may not be possible to support (in a given 299 sub-domain) the full range of 65535 BFR-ids. For example, if the 300 BFRs in a given sub-domain only support 16 SIs and if they only 301 support BitStringLengths of 256 or less, then only 16*256=4096 302 BFR-ids can be supported in that sub-domain. 304 3. Encoding BFR Identifiers in BitStrings 306 To encode a BFR-id in a BIER data packet, one must convert the BFR-id 307 to an SI and a BitString. This conversion depends upon the parameter 308 we are calling "BitStringLength". The conversion is done as follows. 309 If the BFR-id is N, then 311 o SI is the integer part of the quotient (N-1)/BitStringLength 313 o The BitString has one bit position set. If the low-order bit is 314 bit 1, and the high-order bit is bit BitStringLength, the bit 315 position that represents BFR-id N is 316 ((N-1) modulo BitStringLength)+1. 318 If several different BFR-ids all resolve to the same SI, then all 319 those BFR-ids can be represented in a single BitString. The 320 BitStrings for all of those BFR-ids are combined using a bitwise 321 logical OR operation. 323 Within a given BIER domain (or even within a given BIER sub-domain), 324 different values of BitStringLength may be used. Each BFR MUST be 325 provisioned to know the following: 327 o the BitStringLength ("Imposition BitStringLength") and sub-domain 328 ("Imposition sub-domain") to use when it imposes (as a BFIR) a 329 BIER encapsulation on a particular set of packets, and 331 o the BitStringLengths ("Disposition BitStringLengths") that it will 332 process when (as a BFR or BFER) it receives packets from a 333 particular sub-domain. 335 It is not required that a BFIR use the same Imposition 336 BitStringLength or the same Imposition sub-domain for all packets on 337 which it imposes the BIER encapsulation. However, if a particular 338 BFIR is provisioned to use a particular Imposition BitStringLength 339 and a particular Imposition sub-domain when imposing the 340 encapsulation on a given set of packets, all other BFRs with BFR-ids 341 in that sub-domain SHOULD be provisioned to process received BIER 342 packets with that BitStringLength (i.e., all other BFRs with BFR-ids 343 in that sub-domain SHOULD be provisioned with that BitStringLength as 344 a Disposition BitStringLength for that sub-domain. Exceptions to 345 this rule MAY be made under certain conditions; this is discussed in 346 Section 6.10. 348 When a BIER encapsulation is specified, the specification MUST define 349 a default BitStringLength for the encapsulation. Every BFIR 350 supporting that encapsulation MUST be capable of being provisioned 351 with that default BitStringLength as its Imposition BitStringLength. 352 Every BFR and BFER supporting that encapsulation MUST be capable of 353 being provisioned with that default BitStringLength as a Disposition 354 BitStringLength. 356 The specification of a BIER encapsulation MAY also allow the use of 357 other BitStringLengths. 359 If a BFR is capable of being provisioned with a given value of 360 BitStringLength as an Imposition BitStringLength, it MUST also be 361 capable of being provisioned with that same value as one of its 362 Disposition BitStringLengths. It SHOULD be capable of being 363 provisioned with all legal smaller values of BitStringLength as both 364 Imposition and Disposition BitStringLength. 366 In order to support transition from one BitStringLength to another, 367 every BFR MUST be capable of being provisioned to simultaneously use 368 two different Disposition BitStringLengths. 370 A BFR MUST support SI values in the range [0,15], and MAY support SI 371 values in the range [0,255]. ("Supporting the values in a given 372 range" means, in this context, that any value in the given range is 373 legal, and will be properly interpreted.) Note that for a given 374 BitStringLength, the total number of BFR-ids that can be represented 375 is the product of the BitStringLength and the number of supported 376 SIs. For example, if a deployment uses (in a given sub-domain) a 377 BitStringLength of 64 and supports 256 SIs, that deployment can only 378 support 16384 BFR-ids in that sub-domain. Even a deployment that 379 supports 256 SIs will not be able to support 65535 BFR-ids unless it 380 uses a BitStringLength of at least 256. 382 When a BFIR determines that a multicast data packet, assigned to a 383 given sub-domain, needs to be forwarded to a particular set of 384 destination BFERs, the BFIR partitions that set of BFERs into 385 subsets, where each subset contains the target BFERs whose BFR-ids in 386 the given sub-domain all resolve to the same SI. Call these the 387 "SI-subsets" for the packet. Each SI-subset can be represented by a 388 single BitString. The BFIR creates a copy of the packet for each 389 SI-subset. The BIER encapsulation is then applied to each packet. 390 The encapsulation specifies a single SI for each packet, and contains 391 the BitString that represents all the BFR-ids in the corresponding 392 SI-subset. Of course, in order to properly interpret the BitString, 393 it must be possible to infer the sub-domain-id from the encapsulation 394 as well. 396 Suppose, for example, that a BFIR determines that a given packet 397 needs to be forwarded to three BFERs, whose BFR-ids (in the 398 appropriate sub-domain) are 27, 235, and 497. The BFIR will have to 399 forward two copies of the packet. One copy, associated with SI=0, 400 will have a BitString with bits 27 and 235 set. The other copy, 401 associated with SI=1, will have a BitString with bit 241 set. 403 In order to minimize the number of copies that must be made of a 404 given multicast packet, it is RECOMMENDED that the BFR-ids used in a 405 given sub-domain be assigned "densely" (see Section 2) from the 406 numbering space. This will minimize the number of SIs that have to 407 be used in that sub-domain. However, depending upon the details of a 408 particular deployment, other assignment methods may be more 409 advantageous. Suppose, for example, that in a certain deployment, 410 every multicast flow is either intended for the "east coast" or for 411 the "west coast". In such a deployment, it would be advantageous to 412 assign BFR-ids so that all the "west coast" BFR-ids fall into the 413 same SI-subset, and so that all the "east coast" BFR-ids fall into 414 the same SI-subset. 416 When a BFR receives a BIER data packet, it will infer the SI from the 417 encapsulation. The set of BFERs to which the packet needs to be 418 forwarded can then be inferred from the SI and the BitString. 420 In some of the examples given later in this document, we will use a 421 BitStringLength of 4, and will represent a BFR-id in the form 422 "SI:xyzw", where SI is the Set Identifier of the BFR-id (assuming a 423 BitStringLength of 4), and xyzw is a string of 4 bits. A 424 BitStringLength of 4 is used only in the examples; we would not 425 expect actual deployments to have such a small BitStringLength. 427 It is possible that several different forms of BIER encapsulation 428 will be developed. If so, the particular encapsulation that is used 429 in a given deployment will depend on the type of network 430 infrastructure that is used to realize the BIER domain. Details of 431 the BIER encapsulation(s) will be given in companion documents. An 432 encapsulation for use in MPLS networks is described in 433 [MPLS_BIER_ENCAPS]; that document also describes a very similar 434 encapsulation that can be used in non-MPLS networks. 436 4. Layering 438 It is helpful to think of the BIER architecture as consisting of 439 three layers: the "routing underlay", the "BIER layer", and the 440 "multicast flow overlay". 442 4.1. The Routing Underlay 444 The "routing underlay" establishes "adjacencies" between pairs of 445 BFRs, and determines one or more "best paths" from a given BFR to a 446 given set of BFRs. Each such path is a sequence of BFRs such that BFR(k+j) is "adjacent" to 448 BFR(k+j+1) (for 0<=j and BitStringLength can be done using the 575 advertisement capabilities of the IGP. For example, if a BIER domain 576 is also an OSPF domain, these advertisements can be done using the 577 OSPF "Opaque Link State Advertisement" (Opaque LSA) mechanism. 578 Details of the necessary extensions to OSPF and IS-IS will be 579 provided in companion documents. (See [OSPF_BIER_EXTENSIONS] and 580 [ISIS_BIER_EXTENSIONS].) 582 If, in a particular deployment, the BIER domain is not an OSPF or 583 ISIS domain, procedures suitable to the deployment must be used to 584 advertise this information. Details of the necessary procedures will 585 be provided in companion documents. For example, if BGP is the only 586 routing algorithm used in the BIER domain, the procedures of 587 [BGP_BIER_EXTENSIONS] may be used. 589 These advertisements enable each BFR to associate a given 590 with a given BFR-prefix. As will be seen in 591 subsequent sections of this document, knowledge of this association 592 is an important part of the forwarding process. 594 Since each BFR needs to have a unique (in each sub-domain) BFR-id, 595 two different BFRs will not advertise ownership of the same 596 unless there has been a provisioning error. 598 o If BFR-A determines that BFR-B and BFR-C have both advertised the 599 same BFR-id for the same sub-domain, BFR-A MUST log an error. 600 Suppose that the duplicate BFR-id is "N". When BFR-A is 601 functioning as a BFIR, it MUST NOT encode the BFR-id value N in 602 the BIER encapsulation of any packet that has been assigned to the 603 given sub-domain, even if it has determined that the packet needs 604 to be received by BFR-B and/or BFR-C. 606 This will mean that BFR-B and BFR-C cannot receive multicast 607 traffic at all in the given sub-domain until the provisioning 608 error is fixed. However, that is preferable to having them 609 receive each other's traffic. 611 o If BFR-A has been provisioned with BFR-id N for a particular 612 sub-domain, has not yet advertised its ownership of BFR-id N for 613 that sub-domain, but has received an advertisement from a 614 different BFR (say BFR-B) that is advertising ownership of BFR-id 615 N for the same sub-domain, then BFR-A SHOULD log an error, and 616 MUST NOT advertise its own ownership of BFR-id N for that 617 sub-domain as long as the advertisement from BFR-B is extant. 619 This procedure may prevent the accidental misconfiguration of a 620 new BFR from impacting an existing BFR. 622 If a BFR advertises that it has a BFR-id of 0 in a particular 623 sub-domain, other BFRs receiving the advertisement MUST interpret 624 that advertisement as meaning that the advertising BFR does not have 625 a BFR-id in that sub-domain. 627 6. BIER Intra-Domain Forwarding Procedures 629 This section specifies the rules for forwarding a BIER-encapsulated 630 data packet within a BIER domain. These rules are not intended to 631 specify an implementation strategy; to conform to this specification, 632 an implementation need only produce the same results that these rules 633 produce. 635 6.1. Overview 637 This section provides a brief overview of the BIER forwarding 638 procedures. Subsequent sub-sections specify the procedures in more 639 detail. 641 To forward a BIER-encapsulated packet: 643 1. Determine the packet's sub-domain. 645 2. Determine the packet's BitStringLength and BitString. 647 3. Determine the packet's SI. 649 4. From the sub-domain, the SI and the BitString, determine the set 650 of destination BFERs for the packet. 652 5. Using information provided by the routing underlay associated 653 with the packet's sub-domain, determine the next hop adjacency 654 for each of the destination BFERs. 656 6. It is possible that the packet's BitString will have one or more 657 bits that correspond to BFR-ids that are not in use. It is also 658 possible that the packet's BitString will have one or more bits 659 that correspond to BFERs that are unreachable, i.e., that have no 660 next hop adjacency. In the following, we will consider the "next 661 hop adjacency" for all such bit positions to be the "null" next 662 hop. 664 7. Partition the set of destination BFERs such that all the BFERs in 665 a single partition have the same next hop. We will say that each 666 partition is associated with a next hop. 668 8. For each partition: 670 a. Make a copy of the packet. 672 b. Clear any bit in the packet's BitString that identifies a 673 BFER that is not in the partition. 675 c. Transmit the packet to the associated next hop. (If the next 676 hop is the null next hop, the packet is discarded.) 678 If a BFR receives a BIER-encapsulated packet whose triple identifies that BFR itself, then the BFR is also a 680 BFER for that packet. As a BFER, it must pass the payload to the 681 multicast flow overlay. If the BitString has bits set for other 682 BFRs, the packet also needs to be forwarded further within the BIER 683 domain. If the BF(E)R also forwards one or more copies of the packet 684 within the BIER domain, the bit representing the BFR's own BFR-id 685 MUST be clear in all the copies. 687 When BIER on a BFER is to pass a packet to the multicast flow 688 overlay, it of course decapsulates the packet by removing the BIER 689 header. However, it may be necessary to provide the multicast flow 690 overlay with contextual information obtained from the BIER 691 encapsulation. The information that needs to pass between the BIER 692 layer and the multicast flow overlay is specific to the multicast 693 flow overlay. Specification of the interaction between the BIER 694 layer and the multicast flow overlay is outside the scope of this 695 specification. 697 If the BIER encapsulation contains a "Time to Live" (TTL) value, this 698 value is not, by default, inherited by the payload. If a particular 699 multicast flow overlay needs to know the TTL value, this needs to be 700 specified in whatever specification defines the interaction between 701 BIER and that multicast flow overlay. 703 If the BIER encapsulation contains a Traffic Class field, a Type of 704 Service field, a Differentiated Services field, or any field of that 705 sort, the value of that field is not, by default, passed to the 706 multicast flow overlay. If a particular multicast flow overlay needs 707 to know the values of such fields, this fact needs to be specified in 708 whatever specification defines the interaction between BIER and that 709 multicast flow overlay. 711 When BIER on a BFER passes a packet to the multicast flow overlay, 712 the overlay will determine how to further dispatch the packet. If 713 the packet needs to be forwarded into another BIER domain, then the 714 BFR will act as a BFER in one BIER domain and as a BFIR in another. 715 A BIER-encapsulated packet cannot pass directly from one BIER domain 716 to another; at the boundary between BIER domains, the packet must be 717 decapsulated and passed to the multicast flow overlay. 719 Note that when a BFR transmits multiple copies of a packet within a 720 BIER domain, only one copy will be destined to any given BFER. 721 Therefore it is not possible for any BIER-encapsulated packet to be 722 delivered more than once to any BFER. 724 6.2. BFR Neighbors 726 The "BFR Neighbors" (BFR-NBRs) of a given BFR, say BFR-A, are those 727 BFRs that, according to the routing underlay, are adjacencies of 728 BFR-A. Each BFR-NBR will have a BFR-prefix. 730 Suppose a BIER-encapsulated packet arrives at BFR-A. From the 731 packet's encapsulation, BFR-A learns the sub-domain of the packet, 732 and the BFR-ids (in that sub-domain) of the BFERs to which the packet 733 is destined. Then using the information advertised per Section 5, 734 BFR-A can find the BFR-prefix of each destination BFER. Given the 735 BFR-prefix of a particular destination BFER, say BFER-D, BFR-A learns 736 from the routing underlay (associated with the packet's sub-domain) 737 an IP address of the BFR that is the next hop on the path from BFR-A 738 to BFER-D. Let's call this next hop BFR-B. BFR-A must then 739 determine the BFR-prefix of BFR-B. (This determination can be made 740 from the information advertised per Section 5.) This BFR-prefix is 741 the BFR-NBR of BFR-A on the path from BFR-A to BFER-D. 743 Note that if the routing underlay provides multiple equal cost paths 744 from BFR-A to BFER-D, BFR-A may have multiple BFR-NBRs for BFER-D. 746 Under certain circumstances, a BFR may have adjacencies (in a 747 particular routing underlay) that are not BFRs. Please see 748 Section 6.9 for a discussion of how to handle those circumstances. 750 6.3. The Bit Index Routing Table 752 The Bit Index Routing Table (BIRT) is a table that maps from the 753 BFR-id (in a particular sub-domain) of a BFER to the BFR-prefix of 754 that BFER, and to the BFR-NBR on the path to that BFER. 756 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 757 4 (0:1000) \ \ 1 (0:0001) 758 \ \ 759 ( E ) ( F ) 760 3 (0:0100) 2 (0:0010) 762 Figure 1: BIER Topology 1 764 As an example, consider the topology shown in Figure 1. In this 765 diagram, we represent the BFR-id of each BFR in the SI:xyzw form 766 discussed in Section 3. This topology will result in the BIRT of 767 Figure 2 at BFR-B. The first column shows the BFR-id as a number and 768 also (in parentheses) in the SI:BitString format that corresponds to 769 a BitStringLength of 4. (The actual minimum BitStringLength is 64, 770 but we use 4 in the examples.) 772 Note that a BIRT is specific to a particular BIER sub-domain. 774 -------------------------------------------- 775 | BFR-id | BFR-Prefix | BFR-NBR | 776 | (SI:BitString) | of Dest BFER | | 777 ============================================ 778 | 4 (0:1000) | A | A | 779 -------------------------------------------- 780 | 1 (0:0001) | D | C | 781 -------------------------------------------- 782 | 3 (0:0100) | E | E | 783 -------------------------------------------- 784 | 2 (0:0010) | F | C | 785 -------------------------------------------- 787 Figure 2: Bit Index Routing Table at BFR-B 789 6.4. The Bit Index Forwarding Table 791 The "Bit Index Forwarding Table" (BIFT) is derived from the BIRT as 792 follows. (Note that a BIFT is specific to a particular sub-domain.) 794 Suppose that several rows in the BIRT have the same SI and the same 795 BFR-NBR. By taking the logical OR of the BitStrings of those rows, 796 we obtain a bit mask that corresponds to that combination of SI and 797 BFR-NBR. We will refer to this bit mask as the "Forwarding Bit Mask" 798 (F-BM) for that combination. 800 For example, in Figure 2, we see that two of the rows have the same 801 SI (0) and same BFR-NBR (C). The Bit Mask that corresponds to is 0011 ("0001" OR'd with "0010"). 804 The BIFT is used to map from the BFR-id of a BFER to the 805 corresponding F-BM and BFR-NBR. For example, Figure 3 shows the BIFT 806 that is derived from the BIRT of Figure 2. Note that BFR-ids 1 and 2 807 have the same SI and the same BFR-NBR, hence they have the same F-BM. 809 ------------------------------------- 810 | BFR-id | F-BM | BFR-NBR | 811 | (SI:Bitstring) | | | 812 ===================================== 813 | 1 (0:0001) | 0011 | C | 814 ------------------------------------- 815 | 2 (0:0010) | 0011 | C | 816 ------------------------------------- 817 | 3 (0:0100) | 0100 | E | 818 ------------------------------------- 819 | 4 (0:1000) | 1000 | A | 820 ------------------------------------- 822 Figure 3: Bit Index Forwarding Table 824 This Bit Index Forwarding Table (BIFT) is programmed into the data- 825 plane and used to forward packets, applying the rules specified below 826 in Section 6.5. 828 6.5. The BIER Forwarding Procedure 830 Below is the procedure that a BFR uses for forwarding a BIER- 831 encapsulated packet. 833 1. Determine the packet's SI, BitStringLength, and sub-domain. 835 2. If the BitString consists entirely of zeroes, discard the packet; 836 the forwarding process has been completed. Otherwise proceed to 837 step 3. 839 3. Find the position, call it "k", of the least significant (i.e., 840 of the rightmost) bit that is set in the packet's BitString. 841 (Remember, bits are numbered from 1, starting with the least 842 significant bit.) 844 4. If bit k identifies the BFR itself, copy the packet, and send the 845 copy to the multicast flow overlay. Then clear bit k in the 846 original packet, and go to step 2. Otherwise, proceed to step 5. 848 5. Use the value k, together with the SI, sub-domain, and 849 BitStringLength, as the 'index' into the BIFT. 851 6. Extract from the BIFT the F-BM and the BFR-NBR. 853 7. Copy the packet. Update the copy's BitString by AND'ing it with 854 the F-BM (i.e., PacketCopy->BitString &= F-BM). Then forward the 855 copy to the BFR-NBR. (If the BFR-NBR is null, the copy is just 856 discarded.) Note that when a packet is forwarded to a particular 857 BFR-NBR, its BitString identifies only those BFERs that are to be 858 reached via that BFR-NBR. 860 8. Now update the original packet's BitString by AND'ing it with the 861 INVERSE of the F-BM (i.e., Packet->Bitstring &= ~F-BM). (This 862 clears the bits that identify the BFERs to which a copy of the 863 packet has just been forwarded.) Go to step 2. 865 This procedure causes the packet to be forwarded to a particular 866 BFR-NBR only once. The number of lookups in the BIFT is the same as 867 the number of BFR-NBRs to which the packet must be forwarded; it is 868 not necessary to do a separate lookup for each destination BFER. 870 When a packet is sent to a particular BFR-NBR, the BitString is not 871 the only part of the BIER header that needs to be modified. If there 872 is a TTL field in the BIER header, it will need to be decremented. 873 In addition, when either of the encapsulations of [MPLS_BIER_ENCAPS] 874 is used, the BIFT-id field is likely to require modification, based 875 on signaling from the BFR-NBR to which the packet is being sent. The 876 BIFT-id field of an incoming BIER packet implicitly identifies a Set 877 Identifier, a Sub-Domain and a BitStringLength. If the packet is 878 sent to a particular BFR-NBR, the BIFT-id field must be changed to 879 whatever value that BFR-NBR has advertised for the same Set 880 Identifier, Sub-Domain, and BitStringLength. (If the encapsulation 881 of Section 2.1 of [MPLS_BIER_ENCAPS] is used, this is essentially an 882 MPLS label swap operation.) 884 Suppose it has been decided (by the above rules) to send a packet to 885 a particular BFR-NBR. If that BFR-NBR is connected via multiple 886 parallel interfaces, it may be desirable to apply some form of load 887 balancing. Load balancing algorithms are outside the scope of this 888 document. However, if the packet's encapsulation contains an 889 "entropy" field, the entropy field SHOULD be respected; two packets 890 with the same value of the entropy field SHOULD be sent on the same 891 interface (if possible). 893 In some cases, the routing underlay may provide multiple equal cost 894 paths (through different BFR-NBRs) to a given BFER. This is known as 895 "Equal Cost Multiple Paths" (ECMP). The procedures described in this 896 section must be augmented in order to support load balancing over 897 ECMP. The necessary augmentations can be found in Section 6.7. 899 In the event that unicast traffic to the BFR-NBR is being sent via a 900 "bypass tunnel" of some sort, the BIER-encapsulated multicast traffic 901 send to the BFR-NBR SHOULD also be sent via that tunnel. This allows 902 any existing "Fast Reroute" schemes to be applied to multicast 903 traffic as well as to unicast traffic. 905 Some examples of these forwarding procedures can be found in 906 Section 6.6. 908 The rules given in this section can be represented by the following 909 pseudocode: 911 void ForwardBitMaskPacket (Packet) 912 { 913 SI=GetPacketSI(Packet); 914 Offset=SI*BitStringLength; 915 for (Index = GetFirstBitPosition(Packet->BitString); Index ; 916 Index = GetNextBitPosition(Packet->BitString, Index)) { 917 F-BM = BIFT[Index+Offset]->F-BM; 918 if (!F-BM) continue; 919 BFR-NBR = BIFT[Index+Offset]->BFR-NBR; 920 PacketCopy = Copy(Packet); 921 PacketCopy->BitString &= F-BM; 922 PacketSend(PacketCopy, BFR-NBR); 923 Packet->BitString &= ~F-BM; 924 } 925 } 927 Figure 4: Pseudocode 929 This pseudocode assumes that at a given BFER, the BFR-NBR entry 930 corresponding to the BFER's own BFR-id will be the BFER's own 931 BFR-prefix. It also assumes that the corresponding F-BM has only one 932 bit set, the bit representing the BFER itself. In this case, the 933 "PacketSend" function sends the packet to the multicast flow overlay. 935 This pseudocode also assumes that the F-BM for the null next hop 936 contains a 1 in a given bit position if and only if that bit position 937 corresponds either to an unused BFR-id or to an unreachable BFER. 938 When the BFR-NBR is null, the "PacketSend" function discards the 939 packet. 941 6.6. Examples of BIER Forwarding 943 In this section, we give two examples of BIER forwarding, based on 944 the topology in Figure 1. In these examples, all packets have been 945 assigned to the default sub-domain, all packets have SI=0, and the 946 BitStringLength is 4. Figure 5 shows the BIFT entries for SI=0 only. 947 For compactness, we show the first column of the BIFT, the BFR-id, 948 only as an integer. 950 BFR-A BIFT BFR-B BIFT BFR-C BIFT 951 ------------------- ------------------- ------------------- 952 | Id | F-BM | NBR | | Id | F-BM | NBR | | Id | F-BM | NBR | 953 =================== =================== =================== 954 | 1 | 0111 | B | | 1 | 0011 | C | | 1 | 0001 | D | 955 ------------------- ------------------- ------------------- 956 | 2 | 0111 | B | | 2 | 0011 | C | | 2 | 0010 | F | 957 ------------------- ------------------- ------------------- 958 | 3 | 0111 | B | | 3 | 0100 | E | | 3 | 1100 | B | 959 ------------------- ------------------- ------------------- 960 | 4 | 1000 | A | | 4 | 1000 | A | | 4 | 1100 | B | 961 ------------------- ------------------- ------------------- 963 Figure 5: BIFTs for Forwarding Examples 965 6.6.1. Example 1 967 BFR-D, BFR-E and BFR-F are BFER's. BFR-A is the BFIR. Suppose that 968 BFIR-A has learned from the multicast flow overlay that BFER-D is 969 interested in a given multicast flow. If BFIR-A receives a packet of 970 that flow from outside the BIER domain, BFIR-A applies the BIER 971 encapsulation to the packet. The encapsulation must be such that the 972 SI is zero. The encapsulation also includes a BitString, with just 973 bit 1 set and with all other bits clear (i.e., 0001). This indicates 974 that BFER-D is the only BFER that needs to receive the packet. Then 975 BFIR-A follows the procedures of Section 6.5: 977 o Since the packet's BitString is 0001, BFIR-A finds that the first 978 bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-A 979 determines that the bit mask F-BM is 0111 and the BFR-NBR is 980 BFR-B. 982 o BFR-A then makes a copy of the packet, and applies F-BM to the 983 copy: Copy->BitString &= 0111. The copy's Bitstring is now 0001 984 (0001 & 0111). 986 o The copy is now sent to BFR-B. 988 o BFR-A then updates the packet's BitString by applying the inverse 989 of the F-BM: Packet->Bitstring &= ~F-BM. As a result, the 990 packet's BitString is now 0000 (0001 & 1000). 992 o As the packet's BitString is now zero, the forwarding procedure is 993 complete. 995 When BFR-B receives the multicast packet from BFR-A, it follows the 996 same procedure. The result is that a copy of the packet, with a 997 BitString of 0001, is sent to BFR-C. BFR-C applies the same 998 procedures, and as a result sends a copy of the packet, with a 999 BitString of 0001, to BFR-D. 1001 At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an 1002 F-BM of 0001 and a BFR-NBR of BFR-D itself. This will cause a copy 1003 of the packet to be delivered to the multicast flow overlay at BFR-D. 1004 The packet's BitString will be set to 0000, and the packet will not 1005 be forwarded any further. 1007 6.6.2. Example 2 1009 This example is similar to Example 1, except that BFIR-A has learned 1010 from the multicast flow overlay that both BFER-D and BFER-E are 1011 interested in a given multicast flow. If BFIR-A receives a packet of 1012 that flow from outside the BIER domain, BFIR-A applies the BIER 1013 encapsulation to the packet. The encapsulation must be such that the 1014 SI is zero. The encapsulation also includes a BitString with two 1015 bits set: bit 1 is set (as in example 1) to indicate that BFR-D is a 1016 BFER for this packet, and bit 3 is set to indicate that BFR-E is a 1017 BFER for this packet. I.e., the BitString (assuming again a 1018 BitStringLength of 4) is 0101. To forward the packet, BFIR-A follows 1019 the procedures of Section 6.5: 1021 o Since the packet's BitString is 0101, BFIR-A finds that the first 1022 bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-A 1023 determines that the bit mask F-BM is 0111 and the BFR-NBR is 1024 BFR-B. 1026 o BFR-A then makes a copy of the packet, and applies the F-BM to the 1027 copy: Copy->BitString &= 0111. The copy's Bitstring is now 0101 1028 (0101 & 0111). 1030 o The copy is now sent to BFR-B. 1032 o BFR-A then updates the packet's BitString by applying the inverse 1033 of the F-BM: Packet->Bitstring &= ~F-BM. As a result, the 1034 packet's BitString is now 0000 (0101 & 1000). 1036 o As the packet's BitString is now zero, the forwarding procedure is 1037 complete. 1039 When BFR-B receives the multicast packet from BFR-A, it follows the 1040 procedure of Section 6.5, as follows: 1042 o Since the packet's BitString is 0101, BFR-B finds that the first 1043 bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-B 1044 determines that the bit mask F-BM is 0011 and the BFR-NBR is 1045 BFR-C. 1047 o BFR-B then makes a copy of the packet, and applies the F-BM to the 1048 copy: Copy->BitString &= 0011. The copy's Bitstring is now 0001 1049 (0101 & 0011). 1051 o The copy is now sent to BFR-C. 1053 o BFR-B then updates the packet's BitString by applying the inverse 1054 of the F-BM: Packet->Bitstring &= F-BM. As a result, the 1055 packet's BitString is now 0100 (0101 & 1100). 1057 o Now BFR-B finds the next bit in the packet's (modified) BitString. 1058 This is bit 3. Looking at entry 3 in its BIFT, BFR-B determines 1059 that the F-BM is 0100 and the BFR-NBR is BFR-E. 1061 o BFR-B then makes a copy of the packet, and applies the F-BM to the 1062 copy: Copy->BitString &= 0100. The copy's Bitstring is now 0100 1063 (0100 & 0100). 1065 o The copy is now sent to BFR-E. 1067 o BFR-B then updates the packet's BitString by applying the inverse 1068 of the F-BM: Packet->Bitstring &= ~F-BM. As a result, the 1069 packet's BitString is now 0000 (0100 & 1011). 1071 o As the packet's BitString is now zero, the forwarding procedure is 1072 complete. 1074 Thus BFR-B forwards two copies of the packet. One copy of the 1075 packet, with BitString 0001, has now been sent from BFR-B to BFR-C. 1076 Following the same procedures, BFR-C will forward the packet to 1077 BFER-D. 1079 At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an 1080 F-BM of 0001 and a BFR-NBR of BFR-D itself. This will cause a copy 1081 of the packet to be delivered to the multicast flow overlay at BFR-D. 1082 The packet's BitString will be set to 0000, and the packet will not 1083 be forwarded any further. 1085 The other copy of the packet has been sent from BFR-B to BFER-E, with 1086 BitString 0100. 1088 At BFER-E, the BIFT entry (not pictured) for BFR-id 3 will specify an 1089 F-BM of 0100 and a BFR-NBR of BFR-E itself. This will cause a copy 1090 of the packet to be delivered to the multicast flow overlay at BFR-E. 1091 The packet's BitString will be set to 0000, and the packet will not 1092 be forwarded any further. 1094 6.7. Equal Cost Multi-path Forwarding 1096 In many networks, the routing underlay will provide multiple equal 1097 cost paths from a given BFR to a given BFER. When forwarding 1098 multicast packets through the network, it can be beneficial to take 1099 advantage of this by load balancing among those paths. This feature 1100 is known as "equal cost multiple path forwarding", or "ECMP". 1102 BIER supports ECMP, but the procedures of Section 6.5 must be 1103 modified slightly. Two ECMP procedures are defined. In the first 1104 (described in Section 6.7.1), the choice among equal-cost paths taken 1105 by a given packet from a given BFR to a given BFER depends on (a) the 1106 packet's entropy, and (b) the other BFERs to which that packet is 1107 destined. In the second (described in Section 6.7.2), the choice 1108 depends only upon the packet's entropy. 1110 There are tradeoffs between the two forwarding procedures described 1111 here. In the procedure of Section 6.7.1, the number of packet 1112 replications is minimized. The procedure in Section 6.7.1 also uses 1113 less memory in the BFR. In the procedure of Section 6.7.2, the path 1114 traveled by a given packet from a given BFR to a given BFER is 1115 independent of the other BFERs to which the packet is destined. 1116 While the procedures of Section 6.7.2 may cause more replications, 1117 they provide a more predictable behavior. 1119 The two procedures described here operate on identical packet formats 1120 and will interoperate correctly. However, if deterministic behavior 1121 is desired, then all BFRs would need to use the procedure from 1122 Section 6.7.2. 1124 6.7.1. Non-deterministic ECMP 1126 Figure 6 shows the operation of non-deterministic ECMP in BIER. 1128 BFR-A BIFT BFR-B BIFT BFR-C BIFT 1129 ------------------- ------------------- ------------------- 1130 | Id | F-BM | NBR | | Id | F-BM | NBR | | Id | F-BM | NBR | 1131 =================== =================== =================== 1132 | 1 | 0111 | B | | 1 | 0011 | C | | 1 | 0001 | D | 1133 ------------------- ------------------- ------------------- 1134 | 2 | 0111 | B | | 2 | 0011 | C | | 2 | 0010 | F | 1135 ------------------- | | 0110 | E | ------------------- 1136 | 3 | 0111 | B | ------------------- | 3 | 1100 | B | 1137 ------------------- | 3 | 0110 | E | ------------------- 1138 | 4 | 1000 | A | ------------------| | 4 | 1100 | B | 1139 ------------------- | 4 | 1000 | A | ------------------- 1140 ------------------- 1142 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 1143 4 (0:1000) \ \ 1 (0:0001) 1144 \ \ 1145 ( E ) ------------ ( F ) 1146 3 (0:0100) 2 (0:0010) 1148 Figure 6: Example of ECMP 1150 In this example, BFR-B has two equal cost paths to reach BFER-F, one 1151 via BFR-C and one via BFR-E. Since the BFR-id of BFER-F is 2, this 1152 is reflected in entry 2 of BFR-B's BIFT. Entry 2 shows that BFR-B 1153 has a choice of two BFR-NBRs for BFER-B, and that a different F-BM is 1154 associated with each choice. When BFR-B looks up entry 2 in the 1155 BIFT, it can choose either BFR-NBR. However, when following the 1156 procedures of Section 6.5, it MUST use the F-BM corresponding to the 1157 BFR-NBR that it chooses. 1159 How the choice is made is an implementation matter. However, the 1160 usual rules for ECMP apply: packets of a given flow SHOULD NOT be 1161 split among two paths, and any "entropy" field in the packet's 1162 encapsulation SHOULD be respected. 1164 Note however that by the rules of Section 6.5, any packet destined 1165 for both BFER-D and BFER-F will be sent via BFR-C. 1167 6.7.2. Deterministic ECMP 1169 With the procedures of Section 6.7.1, where ECMP paths exist, the 1170 path a packet takes to reach any particular BFER depends not only on 1171 routing and on the packet's entropy, but also on the set of other 1172 BFERs to which the packet is destined. 1174 For example consider the following scenario in the network of 1175 Figure 6. 1177 o There is a sequence of packets being transmitted by BFR-A, some of 1178 which are destined for both D and F, and some of which are 1179 destined only for F. 1181 o All the packets in this sequence have the same entropy value, call 1182 it "Q". 1184 o At BFR-B, when a packet with entropy value Q is forwarded via 1185 entry 2 in the BIFT, the packet is sent to E. 1187 Using the forwarding procedure of Section 6.7.1, packets of this 1188 sequence that are destined for both D and F are forwarded according 1189 to entry 1 in the BIFT, and thus will reach F via the path A-B-C-F. 1190 However, packets of this sequence that are destined only for F are 1191 forwarded according to entry 2 in the BIFT, and thus will reach F via 1192 the path A-B-E-F. 1194 That procedure minimizes the number of packets transmitted by BFR B. 1195 However, consider the following scenario: 1197 o Beginning at time t0, the multicast flow in question needs to be 1198 received ONLY by BFER-F; 1200 o Beginning at a later time, t1, the flow needs to be received by 1201 both BFER-D and BFER-F. 1203 o Beginning at a later time, t2, the no longer needs to be received 1204 by D, but still needs to be received by F. 1206 Then from t0 until t1, the flow will travel to F via the path 1207 A-B-E-F. From t1 until t2, the flow will travel to F via the path 1208 A-B-C-F. And from t2, the flow will again travel to F via the path 1209 A-B-E-F. 1211 The problem is that if D repeatedly joins and leaves the flow, the 1212 flow's path from B to F will keep switching. This could cause F to 1213 receive packets out of order. It also makes troubleshooting 1214 difficult. For example, if there is some problem on the E-F link, 1215 receivers at F will get good service when the flow is also going to D 1216 (avoiding the E-F link), but bad service when the flow is not going 1217 to D. Since it is hard to know which path is being used at any given 1218 time, this may be hard to troubleshoot. Also, it is very difficult 1219 to perform a traceroute that is known to follow the path taken by the 1220 flow at any given time. 1222 The source of this difficulty is that, in the procedures of 1223 Section 6.7.1, the path taken by a particular flow to a particular 1224 BFER depends upon whether there are lower numbered BFERs that are 1225 also receiving the flow. Thus the choice among the ECMP paths is 1226 fundamentally non-deterministic. 1228 Deterministic forwarding can be achieved by using multiple BIFTs, 1229 such that each row in a BIFT has only one path to each destination, 1230 but the multiple ECMP paths to any particular destination are spread 1231 across the multiple tables. When a BIER-encapsulated packet arrives 1232 to be forwarded, the BFR uses a hash of the BIER Entropy field to 1233 determine which BIFT to use, and then the normal BIER forwarding 1234 algorithm (as described in Sections 6.5 and 6.6) is used with the 1235 selected BIFT. 1237 As an example, suppose there are two paths to destination X (call 1238 them X1 and X2), and four paths to destination Y (call them Y1, Y2, 1239 Y3, and Y4). If there are, say, four BIFTs, one BIFT would have 1240 paths X1 and Y1, one would have X1 and Y2, one would have X2 and Y3, 1241 and one would have X2 and Y4. If traffic to X is split evenly among 1242 these four BIFTs, the traffic will be split evenly between the two 1243 paths to X; if traffic to Y is split evenly among these four BIFTs, 1244 the traffic will be split evenly between the four paths to Y. 1246 Note that if there are three paths to one destination and four paths 1247 to another, 12 BIFTs would be required in order to get even splitting 1248 of the load to each of those two destinations. Of course, each BIFT 1249 uses some memory, and one might be willing to have less optimal 1250 splitting in order to have fewer BIFTs. How that tradeoff is made is 1251 an implementation or deployment decision. 1253 6.8. Prevention of Loops and Duplicates 1255 The BitString in a BIER-encapsulated packet specifies the set of 1256 BFERs to which that packet is to be forwarded. When a 1257 BIER-encapsulated packet is replicated, no two copies of the packet 1258 will ever have a BFER in common. If one of the packet's BFERs 1259 forwards the packet further, that will first clear the bit that 1260 identifies itself. As a result, duplicate delivery of packets is not 1261 possible with BIER. 1263 As long as the routing underlay provides a loop free path between 1264 each pair of BFRs, BIER-encapsulated packets will not loop. Since 1265 the BIER layer does not create any paths of its own, there is no need 1266 for any BIER-specific loop prevention techniques beyond the 1267 forwarding procedures specified in Section 6.5. 1269 If, at some time, the routing underlay is not providing a loop free 1270 path between BFIR-A and BFER-B, then BIER encapsulated packets may 1271 loop while traveling from BFIR-A to BFER-B. However, such loops will 1272 never result in delivery of duplicate packets to BFER-B. 1274 These properties of BIER eliminate the need for the "reverse path 1275 forwarding" (RPF) check that is used in conventional IP multicast 1276 forwarding. 1278 6.9. When Some Nodes do not Support BIER 1280 The procedures of section Section 6.2 presuppose that, within a given 1281 BIER domain, all the nodes adjacent to a given BFR in a given routing 1282 underlay are also BFRs. However, it is possible to use BIER even 1283 when this is not the case, as long as the ingress and egress nodes 1284 are BFRs. In this section, we describe procedures that can be used 1285 if the routing underlay is an SPF-based IGP that computes a shortest 1286 path tree from each node to all other nodes in the domain. 1288 At a given BFR, say BFR B, start with a copy of the IGP-computed 1289 shortest path tree from BFR B to each router in the domain. (This 1290 tree is computed by the SPF algorithm of the IGP.) Let's call this 1291 copy the "BIER-SPF tree rooted at BFR B." BFR B then modifies this 1292 BIER-SPF tree as follows. 1294 1. BFR B looks in turn at each of B's child nodes on the BIER-SPF 1295 tree. 1297 2. If one of the child nodes does not support BIER, BFR B removes 1298 that node from the tree. The child nodes of the node that has 1299 just been removed are then re-parented on the tree, so that BFR B 1300 now becomes their parent. 1302 3. BFR B then continues to look at each of its child nodes, 1303 including any nodes that have been re-parented to B as a result 1304 of the previous step. 1306 When all of the child nodes (the original child nodes plus any new 1307 ones) have been examined, B's children on the BIER-SPF tree will all 1308 be BFRs. 1310 When the BIFT is constructed, B's child nodes on the BIER-SPF tree 1311 are considered to be the BFR-NBRs. The F-BMs must be computed 1312 appropriately, based on the BFR-NBRs. 1314 B may now have BFR-NBRs that are not "directly connected" to B via 1315 layer 2. To send a packet to one of these BFR-NBRs, B will have to 1316 send the packet through a unicast tunnel. In an MPLS network, this 1317 may be as simple as finding the IGP unicast next hop to the child 1318 node, and pushing on (above the BIER encapsulation header) an MPLS 1319 label that the IGP next hop has bound to an address of the child 1320 node. (This assumes that the packet is using an MPLS-based BIER 1321 encapsulation, such as the one specified in Section 2.1 of 1323 [MPLS_BIER_ENCAPS].) Of course, the BIFT-id in the BIER 1324 encapsulation header must be the BIFT-id advertised by the child node 1325 for the packet's Set Index, Sub-Domain, and BitStringLength. 1327 If for some reason the unicast tunnel cannot be an MPLS tunnel, any 1328 other kind of tunnel can be used, as long as the encapsulation for 1329 that tunnel type has a way of indicating that the payload is a 1330 BIER-encapsulated packet. 1332 Note that if a BIER-encapsulated packet is not using an MPLS-based 1333 BIER encapsulation, it will not be possible to send it through an 1334 MPLS tunnel unless it is known that the tunnel only carries BIER 1335 packets. The reason is that MPLS has no "next protocol type" field. 1336 This is not a problem if an MPLS-based BIER encapsulation is used, 1337 because in that case the BIER encapsulation begins with an MPLS label 1338 that identifies the packet as a BIER-encapsulated packet. 1340 Of course, the above is not meant as an implementation technique, 1341 just as a functional description. 1343 While the above description assumes that the routing underlay 1344 provides an SPF tree, it may also be applicable to other types of 1345 routing underlay. 1347 The technique above can also be used to provide "node protection" 1348 (i.e., to provide fast reroute around nodes that are believed to have 1349 failed). If BFR B has a failed BFR-NBR, B can remove the failed 1350 BFR-NBR from the BIER-SPF tree, and can then re-parent the child 1351 BFR-NBRs of the failed BFR-NBR so that they appear to be B's own 1352 child nodes on the tree (i.e., so that they appear to be B's 1353 BFR-NBRs). Then the usual BIER forwarding procedures apply. 1354 However, getting the packet from B to the child nodes of the failed 1355 BFR-NBR is a bit more complicated, as it may require using a unicast 1356 bypass tunnel to get around the failed node. 1358 A simpler variant of step 2 above would be the following: 1360 If one of the child nodes does not support BIER, BFR B removes 1361 that node from the tree. All BFERs that are reached through that 1362 child node are then re-parented on the tree, so that BFR B now 1363 becomes their parent. 1365 This variant is simpler because the set of BFERs that are reached 1366 through a particular child node of B can be determined from the F-BM 1367 in the BIFT. However, if this variant is used, the results are less 1368 optimal, because packets will be unicast directly from B to the BFERs 1369 that are reachable through the non-BIER child node. 1371 When using a unicast MPLS tunnel to get a packet to a BFR-NBR: 1373 o the TTL of the MPLS label entry representing the tunnel SHOULD be 1374 set to a large value, rather than being copied from the TTL value 1375 from the BIER encapsulation header, and 1377 o when the tunnel labels are popped off, the TTL from the tunnel 1378 labels SHOULD NOT be copied to the BIER encapsulation header. 1380 In other words, the TTL processing for the tunnel SHOULD be as 1381 specified in [RFC3443] for "Pipe Model" and "Short Pipe Model" LSPs. 1382 The same principle applies if the tunnels are not MPLS tunnels; the 1383 BIER packet SHOULD NOT inherit the TTL from the tunnel encapsulation. 1384 That way, the TTL of the BIER encapsulation header constrains only 1385 the number of BFRs that the packet may traverse, not the total number 1386 of hops. 1388 If two BIER packets have the same value in the entropy field of their 1389 respective BIER headers, and if both are transmitted through a given 1390 tunnel, it is desirable for the tunnel encapsulation to preserve the 1391 fact that the two packets have the same entropy. 1393 The material in this section presupposes that a given node is either 1394 a BFR or not, and that a BFR supports BIER on all its interfaces. It 1395 is however possible that a router will have some line cards that 1396 support BIER and some that do not. In such a case, one can think of 1397 the router as a "partial-BFR", that supports BIER only on some of its 1398 interfaces. If it is desired to deploy such partial-BFRs, one can 1399 use the multi-topology features of the IGP to set up a BIER-specific 1400 topology. This topology would exclude all the non-BIER-capable 1401 interfaces that attach to BFRs. BIER would then have to be run in a 1402 sub-domain that is bound to this topology. If unicast tunnels are 1403 used to bypass non-BFRs, either the tunnels have to be restricted to 1404 this topology, or the tunnel endpoints have to be BFRs that do not 1405 have any non-BIER-capable interfaces. 1407 6.10. Use of Different BitStringLengths within a Domain 1409 The procedures of this section apply only when the same encapsulation 1410 is used throughout the BIER domain. Consideration of the scenario 1411 where both multiple encapsulations and multiple BitStringLengths are 1412 used in a given BIER domain is outside the scope of this document. 1414 It is possible for different BFRs within a BIER domain to be using 1415 different Imposition and/or Disposition BitStringLengths. As stated 1416 in Section 3: 1418 "if a particular BFIR is provisioned to use a particular 1419 Imposition BitStringLength and a particular Imposition sub-domain 1420 when imposing the encapsulation on a given set of packets, all 1421 other BFRs with BFR-ids in that sub-domain SHOULD be provisioned 1422 to process received BIER packets with that BitStringLength (i.e., 1423 all other BFRs with BFR-ids in that sub-domain SHOULD be 1424 provisioned with that BitStringLength as a Disposition 1425 BitStringLength for that sub-domain)." 1427 Note that mis-provisioning can result in "black holes". If a BFIR 1428 creates a BIER packet with a particular BitStringLength, and if that 1429 packet needs to travel through a BFR that cannot process received 1430 BIER packets with that BitStringLength, then it may be impossible to 1431 forward the packet to all of the BFERs identified in its BIER header. 1432 Section 6.10.1 defines a procedure, the "BitStringLength 1433 Compatibility Check", that can be used to detect the possibility of 1434 such black holes. 1436 However, failure of the BitStringLength Compatibility Check does not 1437 necessarily result in the creation of black holes; Section 6.10.2 1438 specifies OPTIONAL procedures that allow BIER forwarding to proceed 1439 without black holes, even if the BitStringLength Compatibility Check 1440 fails. 1442 If the procedures of Section 6.10.2 are not deployed, but the 1443 BitStringLength Compatibility Check fails at some BFIR, the BFIR has 1444 two choices: 1446 o Create BIER packets with the provisioned Imposition 1447 BitStringLength, even though the packets may not be able to reach 1448 all the BFERs identified in their BitStrings 1450 o Use an Imposition BitStringLength that passes the Compatibility 1451 Check (assuming that there is one), even if this is not the 1452 provisioned Imposition BitStringLength. 1454 Section 6.10.1 discusses the implications of making one or the other 1455 of these choices. 1457 There will be times when an operator wishes to change the 1458 BitStringLengths used in a particular BIER domain. Section 6.10.3 1459 specifies a simple procedure that can be used to transition a BIER 1460 domain from one BitStringLength to another. 1462 6.10.1. BitStringLength Compatibility Check 1464 When a BFIR needs to encapsulate a packet, the BFIR first assigns the 1465 packet to a sub-domain. Then the BFIR chooses an Imposition 1466 BitStringLength L for the packet. The choice of Imposition 1467 BitStringLength is by provisioning. However, the BFIR should also 1468 perform the BitStringLength Compatibility Check defined below. 1470 The combination of Sub-Domain S and Imposition BitStringLength L 1471 passes the BitStringLength Compatibility Check if and only if the 1472 following condition holds: 1474 Every BFR that has advertised its membership in sub-domain S has 1475 also advertised that it is using Disposition BitStringLength L 1476 (and possibly other BitStringLengths as well) in that Sub-Domain. 1477 (If the MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is 1478 being used, this means that every BFR that is advertising a label 1479 for Sub-Domain S is advertising a label for the combination of 1480 Sub-Domain S and Disposition BitStringLength L.) 1482 If a BFIR has been provisioned to use a particular Imposition 1483 BitStringLength and a particular sub-domain for some set of packets, 1484 and if that combination of Imposition BitStringLength and sub-domain 1485 does not pass the BitStringLength Compatibility Check, the BFIR 1486 SHOULD log this fact as an error. It then has the following choice 1487 about what to do with the packets: 1489 1. The BFIR MAY use the provisioned Imposition BitStringLength 1490 anyway. If the procedure Paragraph 2 or Paragraph 3 of 1491 Section 6.10.2 are deployed, this will not cause black holes, and 1492 may actually be the optimal result. It should be understood 1493 though that the BFIR cannot determine by signaling whether those 1494 procedures have been deployed. 1496 2. If the BFIR is capable of using an Imposition BitStringlength 1497 that does pass the BitStringLength Compatibility Check for the 1498 particular sub-domain, the BFIR MAY use that Imposition 1499 BitStringLength instead. 1501 Which of these two choices to make is itself determined by 1502 provisioning. 1504 Note that discarding the packets is not one of the allowable choices. 1505 Suppose, for example, that all the BFIRs are provisioned to use 1506 Imposition BitStringLength L for a particular sub-domain S, but one 1507 BFR has not been provisioned to use Disposition BitStringLength L for 1508 sub-domain S. This will cause the BitStringLength Compatibility 1509 Check to fail. If the BFIR sends packets with BitStringLength L and 1510 sub-domain S, the mis-provisioned BFR will not be able to forward 1511 those packets, and thus the packets may only be able to reach a 1512 subset of the BFERs to which they are destined. However, this is 1513 still better than having the BFIRs drop the packets; if the BFIRs 1514 discard the packets, the packets won't reach any of the BFERs to 1515 which they are destined at all. 1517 If the procedures of Section 6.10.2 have not been deployed, choice 2 1518 might seem like a better option. However, there might not be any 1519 Imposition BitStringLength that a given BFIR can use that also passes 1520 the BitStringLength Compatibility Check. If it is desired to use 1521 choice 2 in a particular deployment, then there should be a "Fallback 1522 Disposition BitStringLength", call it F, such that: 1524 o Every BFR advertises that it uses BitStringLength F as a 1525 Disposition BitStringLength for every sub-domain, and 1527 o If a BFIR is provisioned to use Imposition BitStringLength X and 1528 Imposition sub-domain S for a certain class of packets, but the 1529 BitStringLength Compatibility check fails for the combination of 1530 BitStringLength X and sub-domain S, then the BFIR will fall back 1531 to using BitStringLength F as the Imposition BitStringLength 1532 whenever the Imposition sub-domain is S. 1534 It is RECOMMENDED that the value of F be the default BitStringLength 1535 for the encapsulation being used. 1537 6.10.2. Handling BitStringLength Mismatches 1539 Suppose a packet has been BIER-encapsulated with a BitStringLength 1540 value of X, and that the packet has arrived at BFR-A. Now suppose 1541 that according to the routing underlay, the next hop is BFR-B, but 1542 BFR-B is not using X as one of its Disposition BitStringLengths. 1543 What should BFR-A do with the packet? BFR-A has three options. It 1544 MUST do one of the three, but the choice of which procedure to follow 1545 is a local matter. The three options are: 1547 1. BFR-A MAY discard the packet. 1549 2. BFR-A MAY re-encapsulate the packet, using a BIER header whose 1550 BitStringLength value is supported by BFR-B. 1552 Note that if BFR-B only uses Disposition BitStringLength values 1553 that are smaller than the BitStringLength value of the packet, 1554 this may require creating additional copies of the packet. 1555 Whether additional copies actually have to be created depends 1556 upon the bits that are actually set in the original packet's 1557 BitString. 1559 3. BFR-A MAY treat BFR-B as if BFR-B did not support BIER at all, 1560 and apply the rules of Section 6.9. 1562 Note that there is no signaling that enables a BFR to advertise which 1563 of the three options it will use. 1565 Option 2 can be useful if there is a region of the BIER domain where 1566 the BFRs are capable of using a long BitStringLength, and a region 1567 where the BFRs are only capable of using a shorter BitStringLength. 1569 6.10.3. Transitioning from One BitStringLength to Another 1571 Suppose one wants to migrate the BitStringLength used in a particular 1572 BIER domain from one value (X) to another value (Y). The following 1573 migration procedure can be used. This procedure allows the BFRs to 1574 be reprovisioned one at a time, and does not require a "flag day". 1576 First, upgrade all the BFRs in the domain so that they use both value 1577 X and value Y as their Disposition BitStringLengths. Once this is 1578 done, reprovision the BFIRs so that they use BitStringLength value Y 1579 as the Imposition BitStringLength. Once that is done, one may 1580 optionally reprovision all the BFRs so that they no longer use 1581 Disposition BitStringLength X. 1583 7. Operational Considerations 1585 BIER offers a radical simplification over current IPMulticast 1586 operations; no tree-building control plane, no per-flow forwarding 1587 state, no Reverse Path Forwarding (RPF), no Rendezvous Point (RP) 1588 etc. BIER packet forwarding/replication is along the unicast paths 1589 to each bit position set in the packet, ensuring the encapsulated 1590 multicast packets follow the same path as unicast to each set bit in 1591 the header. The BIER FIB can be derived from the unicast SPF 1592 calculated unicast FIB, or any other forwarding path calculation in 1593 or out of band. Each bit will follow this unicast path from the 1594 entry point of the BIER domain to edge device with that assigned bit. 1596 Due to these differences, operational expectation from traditional 1597 multicast solutions do not apply to a BIER domain. There is no 1598 granular per-flow state at each node defining a tree. Monitoring 1599 flows at the forwarding plane level, (S,G) entries, is not provided 1600 in a BIER node. BIER FIB packet counters may be maintained for BFR- 1601 IDs or next-hop neighbors. Any flow based metrics will require 1602 deeper packet inspection which is outside of the scope of this 1603 document. In this way, BIER is again more like unicast. 1605 It is this reduction in state that allows for one of the key 1606 operational benefits of BIER, deterministic convergence. The BIER 1607 FIB can converge immediately after the unicast FIB regardless of how 1608 many multicast flows are transiting the links. Careful monitoring of 1609 (S,G) utilization is not required within a BIER domain. 1611 7.1. Configuration 1613 A BIER domain requires that each edge node (BFER) be given a unique 1614 bit position in the BIER mask (BFR-id). The BFR-id must be 1615 configured on each BFER and associated with a unique IP address of 1616 that BFER. Any existing manual or automated configuration tools must 1617 provide access to BIER specific configuration. The association of 1618 the BFR-id with a unique address of the BFER to which it is assigned 1619 must also be advertised into the IGP of the BIER domain. This may be 1620 implied from the BIER configuration or require IGP specific 1621 configuration. This document does not dictate any specific 1622 configuration methodology. 1624 8. IANA Considerations 1626 This document contains no actions for IANA. 1628 9. Security Considerations 1630 When BIER is paired with a particular multicast flow overlay, it 1631 inherits the security considerations of that layer. Similarly, when 1632 BIER is paired with a particular routing underlay, it inherits the 1633 security considerations of that layer. 1635 If the BIER encapsulation of a particular packet specifies an SI or a 1636 BitString other than the one intended by the BFIR, the packet is 1637 likely to be misdelivered. If the BIER encapsulation of a packet is 1638 modified (through error or malfeasance) in a way other than that 1639 specified in this document, the packet may be misdelivered. Some 1640 modifications of the BIER encapsulation, e.g., setting every bit in 1641 the BitString, may result in (intentional or unintentional) Denial of 1642 Service (DoS) attacks. 1644 If a BFIR is compromised, it may impose a BIER encapsulation with all 1645 the bits in the BitString set, which would also result in a DoS 1646 attack. 1648 Every BFR MUST be provisioned to know which of its interfaces lead to 1649 a BIER domain and which do not. BIER-encapsulated packets MUST NOT 1650 be accepted from outside the BIER domain. (Reception of 1651 BIER-encapsulated packets from outside the BIER domain would create 1652 an attack vector for DoS attacks, as an attacker might set all the 1653 bits in the BitString.) 1654 If two interfaces lead to different BIER domains, the BFR MUST be 1655 provisioned to know that those two interfaces lead to different BIER 1656 domains. If the provisioning is not correct, BIER-encapsulated 1657 packets from one BIER domain may "leak" into another; this is likely 1658 to result in misdelivery of packets. 1660 DoS attacks may also result from incorrect provisioning (through 1661 error or malfeasance) of the BFRs. 1663 If the procedures used for advertising BFR-ids and BFR-prefixes are 1664 not secure, an attack on those procedures may result in incorrect 1665 delivery of BIER-encapsulated packets. 1667 10. Acknowledgements 1669 The authors wish to thank Rajiv Asati, Alia Atlas, John Bettink, Ross 1670 Callon (who contributed much of the text on deterministic ECMP), 1671 Nagendra Kumar, Christian Martin, Neale Ranns, Greg Shepherd, Albert 1672 Tian, Ramji Vaithianathan, Xiaohu Xu and Jeffrey Zhang for their 1673 ideas and contributions to this work. 1675 The authors also wish to thank Sue Hares, Victor Kuarsingh, and Dan 1676 Romascanu for their reviews of this document. 1678 11. Contributor Addresses 1680 Below is a list of other contributing authors in alphabetical order: 1682 Gregory Cauchie 1683 Bouygues Telecom 1685 Email: gcauchie@bouyguestelecom.fr 1687 Mach (Guoyi) Chen 1688 Huawei 1690 Email: mach.chen@huawei.com 1692 Arkadiy Gulko 1693 Thomson Reuters 1694 195 Broadway 1695 New York NY 10007 1696 United States 1698 Email: arkadiy.gulko@thomsonreuters.com 1699 Wim Henderickx 1700 Nokia 1701 Copernicuslaan 50 1702 Antwerp 2018 1703 Belgium 1705 Email: wim.henderickx@nokia.com 1707 Martin Horneffer 1708 Deutsche Telekom 1709 Hammer Str. 216-226 1710 Muenster 48153 1711 Germany 1713 Email: Martin.Horneffer@telekom.de 1715 Uwe Joorde 1716 Deutsche Telekom 1717 Hammer Str. 216-226 1718 Muenster D-48153 1719 Germany 1721 Email: Uwe.Joorde@telekom.de 1723 Luay Jalil 1724 Verizon 1725 1201 E Arapaho Rd. 1726 Richardson, TX 75081 1727 United States 1729 Email: luay.jalil@verizon.com 1731 Greg Shepherd 1732 Cisco Systems 1733 170 West Tasman Drive 1734 San Jose, CA 95134 1735 United States 1737 Email: shep@cisco.com 1739 Jeff Tantsura 1741 Email: jefftant.ietf@gmail.com 1743 12. References 1745 12.1. Normative References 1747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1748 Requirement Levels", BCP 14, RFC 2119, 1749 DOI 10.17487/RFC2119, March 1997, 1750 . 1752 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 1753 in Multi-Protocol Label Switching (MPLS) Networks", 1754 RFC 3443, DOI 10.17487/RFC3443, January 2003, 1755 . 1757 12.2. Informative References 1759 [BGP_BIER_EXTENSIONS] 1760 Xu, X., Chen, M., Patel, K., Wijnands, IJ., and T. 1761 Przygienda, "BGP Extensions BIER", internet-draft draft- 1762 ietf-bier-idr-extensions-02.txt, January 2017. 1764 [BIER-MVPN] 1765 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 1766 Przygienda, "Multicast VPN Using BIER", internet-draft 1767 draft-ietf-bier-mvpn-07.txt, July 2017. 1769 [Boivie_Feldman] 1770 Boivie, R. and N. Feldman, "Small Group Multicast", 1771 (expired) draft-boivie-sgm-02.txt, February 2001. 1773 [ISIS_BIER_EXTENSIONS] 1774 Ginsberg, L., Przygienda, T., Aldrin, S., and J. Zhang, 1775 "BIER Support via ISIS", internet-draft draft-ietf-bier- 1776 isis-extensions-04.txt, March 2017. 1778 [MPLS_BIER_ENCAPS] 1779 Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., 1780 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 1781 Explicit Replication in MPLS and non-MPLS Networks 1782 Networks", internet-draft draft-ietf-bier-mpls- 1783 encapsulation-07.txt, June 2017. 1785 [OSPF_BIER_EXTENSIONS] 1786 Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 1787 Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions 1788 for Bit Index Explicit Replication", internet-draft draft- 1789 ietf-bier-ospf-bier-extensions-06.txt, June 2017. 1791 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1792 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1793 2012, . 1795 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1796 Encodings and Procedures for Multicast in MPLS/BGP IP 1797 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1798 . 1800 Authors' Addresses 1802 IJsbrand Wijnands (editor) 1803 Cisco Systems, Inc. 1804 De Kleetlaan 6a 1805 Diegem 1831 1806 Belgium 1808 Email: ice@cisco.com 1810 Eric C. Rosen (editor) 1811 Juniper Networks, Inc. 1812 10 Technology Park Drive 1813 Westford, Massachusetts 01886 1814 United States 1816 Email: erosen@juniper.net 1818 Andrew Dolganow 1819 Nokia 1820 600 March Rd. 1821 Ottawa, Ontario K2K 2E6 1822 Canada 1824 Email: andrew.dolganow@nokia.com 1826 Tony Przygienda 1827 Juniper Networks, Inc. 1828 1194 N. Mathilda Ave. 1829 Sunnyvale, California 94089 1830 United States 1832 Email: prz@juniper.net 1833 Sam K Aldrin 1834 Google, Inc. 1835 1600 Amphitheatre Parkway 1836 Mountain View, California 1837 United States 1839 Email: aldrin.ietf@gmail.com