idnits 2.17.1 draft-ietf-bier-architecture-07.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 (June 21, 2017) is 2494 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 363 -- Looks like a reference, but probably isn't: '255' on line 363 -- Looks like a reference, but probably isn't: '1' on line 285 -- Looks like a reference, but probably isn't: '65535' on line 269 -- Looks like a reference, but probably isn't: '256' on line 283 -- Looks like a reference, but probably isn't: '512' on line 285 -- Looks like a reference, but probably isn't: '15' on line 362 == Outdated reference: A later version (-11) exists of draft-ietf-bier-mvpn-05 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: December 23, 2017 Juniper Networks, Inc. 6 A. Dolganow 7 Nokia 8 T. Przygienda 9 Juniper Networks, Inc. 10 S. Aldrin 11 Google, Inc. 12 June 21, 2017 14 Multicast using Bit Index Explicit Replication 15 draft-ietf-bier-architecture-07 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. Elimination of the per- 32 flow state and the explicit tree-building protocols results in a 33 considerable simplification. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 23, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. The BFR Identifier and BFR-Prefix . . . . . . . . . . . . . . 6 70 3. Encoding BFR Identifiers in BitStrings . . . . . . . . . . . 7 71 4. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.1. The Routing Underlay . . . . . . . . . . . . . . . . . . 10 73 4.2. The BIER Layer . . . . . . . . . . . . . . . . . . . . . 11 74 4.3. The Multicast Flow Overlay . . . . . . . . . . . . . . . 11 75 5. Advertising BFR-ids and BFR-Prefixes . . . . . . . . . . . . 12 76 6. BIER Intra-Domain Forwarding Procedures . . . . . . . . . . . 13 77 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.2. BFR Neighbors . . . . . . . . . . . . . . . . . . . . . . 15 79 6.3. The Bit Index Routing Table . . . . . . . . . . . . . . . 16 80 6.4. The Bit Index Forwarding Table . . . . . . . . . . . . . 17 81 6.5. The BIER Forwarding Procedure . . . . . . . . . . . . . . 18 82 6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 20 83 6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 21 84 6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22 85 6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 24 86 6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 24 87 6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 25 88 6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 27 89 6.9. When Some Nodes do not Support BIER . . . . . . . . . . . 28 90 6.10. Use of Different BitStringLengths within a Domain . . . . 31 91 6.10.1. BitStringLength Compatibility Check . . . . . . . . 32 92 6.10.2. Handling BitStringLength Mismatches . . . . . . . . 33 93 6.10.3. Transitioning from One BitStringLength to Another . 34 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 97 10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 35 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 100 11.2. Informative References . . . . . . . . . . . . . . . . . 36 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 103 1. Introduction 105 This document specifies a new architecture for the forwarding of 106 multicast data packets. It provides optimal forwarding of multicast 107 data packets through a "multicast domain". However, it does not 108 require the use of a protocol for explicitly building multicast 109 distribution trees, and it does not require intermediate nodes to 110 maintain any per-flow state. This architecture is known as "Bit 111 Index Explicit Replication" (BIER). 113 A router that supports BIER is known as a "Bit-Forwarding Router" 114 (BFR). The BIER control plane protocols (see Section 4.2) run within 115 a "BIER domain", allowing the BFRs within that domain to exchange the 116 information needed for them to forward packets to each other using 117 BIER. 119 A multicast data packet enters a BIER domain at a "Bit-Forwarding 120 Ingress Router" (BFIR), and leaves the BIER domain at one or more 121 "Bit-Forwarding Egress Routers" (BFERs). A BFR that receives a 122 multicast data packet from another BFR in the same BIER domain, and 123 forwards the packet to another BFR in the same BIER domain, will be 124 known as a "transit BFR" for that packet. A single BFR may be a BFIR 125 for some multicast traffic while also being a BFER for some multicast 126 traffic and a transit BFR for some multicast traffic. In fact, for a 127 given packet, a BFR may be a BFIR and/or a transit BFR and/or (one 128 of) the BFER(s) for that packet. 130 A BIER domain may contain one or more sub-domains. Each BIER domain 131 MUST contain at least one sub-domain, the "default sub-domain" (also 132 denoted "sub-domain zero"). If a BIER domain contains more than one 133 sub-domain, each BFR in the domain MUST be provisioned to know the 134 set of sub-domains to which it belongs. Each sub-domain is 135 identified by a sub-domain-id in the range [0,255]. 137 For each sub-domain to which a given BFR belongs, if the BFR is 138 capable of acting as a BFIR or a BFER, it MUST be provisioned with a 139 "BFR-id" that is unique within the sub-domain. A BFR-id is a small 140 unstructured positive integer. For instance, if a particular BIER 141 sub-domain contains 1,374 BFRs, each one could be given a BFR-id in 142 the range 1-1374. 144 If a given BFR belongs to more than one sub-domain, it may (though it 145 need not) have a different BFR-id for each sub-domain. 147 When a multicast packet arrives from outside the domain at a BFIR, 148 the BFIR determines the set of BFERs to which the packet will be 149 sent. The BFIR also determines the sub-domain in which the packet 150 will be sent. Determining the sub-domain in which a given packet 151 will be sent is known as "assigning the packet to a sub-domain". 152 Procedures for choosing the sub-domain to which a particular packet 153 is assigned are outside the scope of this document. However, once a 154 particular packet has been assigned to a particular sub-domain, it 155 remains assigned to that sub-domain until it leaves the BIER domain. 156 That is, the sub-domain to which a packet is assigned MUST NOT be 157 changed while the packet is in flight through the BIER domain. 159 Once the BFIR determines sub-domain and the set of BFERs for a given 160 packet, the BFIR encapsulates the packet in a "BIER header". The 161 BIER header contains a bit string in which each bit represents a 162 single BFR-id. To indicate that a particular BFER is to receive a 163 given packet, the BFIR sets the bit corresponding to that BFER's 164 BFR-id in the sub-domain to which the packet has been assigned. We 165 will use term "BitString" to refer to the bit string field in the 166 BIER header. We will use the term "payload" to refer to the packet 167 that has been encapsulated. Thus a "BIER-encapsulated" packet 168 consists of a "BIER header" followed by a "payload". 170 The number of BFERs to which a given packet can be forwarded is 171 limited only by the length of the BitString in the BIER header. 172 Different deployments can use different BitString lengths. We will 173 use the term "BitStringLength" to refer to the number of bits in the 174 BitString. It is possible that some deployment will have more BFERs 175 in a given sub-domain than there are bits in the BitString. To 176 accommodate this case, the BIER encapsulation includes both the 177 BitString and a "Set Identifier" (SI). It is the BitString and the 178 SI together that determine the set of BFERs to which a given packet 179 will be delivered: 181 o by convention, the least significant (rightmost) bit in the 182 BitString is "bit 1", and the most significant (leftmost) bit is 183 "bit BitStringLength". 185 o if a BIER-encapsulated packet has an SI of n, and a BitString with 186 bit k set, then the packet must be delivered to the BFER whose 187 BFR-id (in the sub-domain to which the packet has been assigned) 188 is n*BitStringLength+k. 190 For example, suppose the BIER encapsulation uses a BitStringLength of 191 256 bits. By convention, the least significant (rightmost) bit is 192 "bit 1", and the most significant (leftmost) bit is "bit 256". 193 Suppose that a given packet has been assigned to sub-domain 0, and 194 needs to be delivered to three BFERs, where those BFERs have BFR-ids 195 in sub-domain 0 of 13, 126, and 235 respectively. The BFIR would 196 create a BIER encapsulation with the SI set to zero, and with bits 197 13, 126, and 235 of the BitString set. (All other bits of the 198 BitString would be clear.) If the packet also needs to be sent to a 199 BFER whose BFR-id is 257, the BFIR would have to create a second copy 200 of the packet, and the BIER encapsulation would specify an SI of 1, 201 and a BitString with bit 1 set and all the other bits clear. 203 It is generally advantageous to assign the BFR-ids of a given sub- 204 domain so that as many BFERs as possible can be represented in a 205 single bit string. 207 Suppose a BFR, call it BFR-A, receives a packet whose BIER 208 encapsulation specifies an SI of 0, and a BitString with bits 13, 26, 209 and 235 set. Suppose BFR-A has two BFR neighbors, BFR-B and BFR-C, 210 such that the best path to BFERs 13 and 26 is via BFR-B, but the best 211 path to BFER 235 is via BFR-C. Then BFR-A will replicate the packet, 212 sending one copy to BFR-B and one copy to BFR-C. However, BFR-A will 213 clear bit 235 in the BitString of the packet copy it sends to BFR-B, 214 and will clear bits 13 and 26 in the BitString of the packet copy it 215 sends to BFR-C. As a result, BFR-B will forward the packet only 216 towards BFERs 13 and 26, and BFR-C will forward the packet only 217 towards BFER 235. This ensures that each BFER receives only one copy 218 of the packet. 220 With this forwarding procedure, a multicast data packet can follow an 221 optimal path from its BFIR to each of its BFERs. Further, since the 222 set of BFERs for a given packet is explicitly encoded into the BIER 223 header, the packet is not sent to any BFER that does not need to 224 receive it. This allows for optimal forwarding of multicast traffic. 225 This optimal forwarding is achieved without any need for transit BFRs 226 to maintain per-flow state, or to run a multicast tree-building 227 protocol. 229 The idea of encoding the set of egress nodes into the header of a 230 multicast packet is not new. For example, [Boivie_Feldman] proposes 231 to encode the set of egress nodes as a set of IP addresses, and 232 proposes mechanisms and procedures that are in some ways similar to 233 those described in the current document. However, since BIER encodes 234 each BFR-id as a single bit in a bit string, it can represent up to 235 128 BFERs in the same number of bits that it would take to carry the 236 IPv6 address of a single BFER. Thus BIER scales to a much larger 237 number of egress nodes per packet. 239 BIER does not require that each transit BFR look up the best path to 240 each BFER that is identified in the BIER header; the number of 241 lookups required in the forwarding path for a single packet can be 242 limited to the number of neighboring BFRs; this can be much smaller 243 than the number of BFERs. See Section 6 (especially Section 6.4) for 244 details. 246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 248 document are to be interpreted as described in RFC 2119 [RFC2119]. 250 2. The BFR Identifier and BFR-Prefix 252 Each BFR MUST be assigned a single "BFR-Prefix" for each sub-domain 253 to which it belongs. A BFR's BFR-Prefix MUST be an IP address 254 (either IPv4 or IPv6) of the BFR. It is RECOMMENDED that the 255 BFR-prefix be a loopback address of the BFR. 257 If a BFR belongs to more than one sub-domain, it may (though it need 258 not) have a different BFR-prefix in each sub-domain. 260 All BFR-Prefixes used within a given sub-domain MUST belong to the 261 same address family (either IPv4 or IPv6). 263 The BFR-prefix of a given BFR in a given sub-domain MUST be routable 264 in that sub-domain. Whether a particular BFR-Prefix is routable in a 265 given sub-domain depends on the "routing underlay" associated with 266 that sub-domain. The notion of "routing underlay" is described in 267 Section 4.1. 269 A "BFR Identifier" (BFR-id) is a number in the range [1,65535]. 270 Within a given sub-domain, every BFR that may need to function as a 271 BFIR or BFER MUST have a single BFR-id, which identifies it uniquely 272 within that sub-domain. A BFR that does not need to function as a 273 BFIR or BFER in a given sub-domain does not need to have a BFR-id in 274 that sub-domain. 276 The value 0 is not a legal BFR-id. 278 The procedure for assigning a particular BFR-id to a particular BFR 279 is outside the scope of this document. However, it is RECOMMENDED 280 that the BFR-ids for each sub-domain be assigned "densely" from the 281 numbering space, as this will result in a more efficient encoding 282 (see Section 3). That is, if there are 256 or fewer BFERs, it is 283 RECOMMENDED to assign all the BFR-ids from the range [1,256]. If 284 there are more than 256 BFERs, but less than 512, it is RECOMMENDED 285 to assign all the BFR-ids from the range [1,512], with as few "holes" 286 as possible in the earlier range. However, in some deployments, it 287 may be advantageous to depart from this recommendation; this is 288 discussed further in Section 3. 290 In some deployments, it may not be possible to support (in a given 291 sub-domain) the full range of 65535 BFR-ids. For example, if the 292 BFRs in a given sub-domain only support 16 SIs and if they only 293 support BitStringLengths of 256 or less, then only 16*256=4096 BFR- 294 ids can be supported in that sub-domain. 296 3. Encoding BFR Identifiers in BitStrings 298 To encode a BFR-id in a BIER data packet, one must convert the BFR-id 299 to an SI and a BitString. This conversion depends upon the parameter 300 we are calling "BitStringLength". The conversion is done as follows. 301 If the BFR-id is N, then 303 o SI is the integer part of the quotient (N-1)/BitStringLength 305 o The BitString has one bit position set. If the low-order bit is 306 bit 1, and the high-order bit is bit BitStringLength, the bit 307 position that represents BFR-id N is 308 ((N-1) modulo BitStringLength)+1. 310 If several different BFR-ids all resolve to the same SI, then all 311 those BFR-ids can be represented in a single BitString. The 312 BitStrings for all of those BFR-ids are combined using a bitwise 313 logical OR operation. 315 Within a given BIER domain (or even within a given BIER sub-domain), 316 different values of BitStringLength may be used. Each BFR MUST be 317 provisioned to know the following: 319 o the BitStringLength ("Imposition BitStringLength") and sub-domain 320 ("Imposition sub-domain") to use when it imposes (as a BFIR) a 321 BIER encapsulation on a particular set of packets, and 323 o the BitStringLengths ("Disposition BitStringLengths") that it will 324 process when (as a BFR or BFER) it receives packets from a 325 particular sub-domain. 327 It is not required that a BFIR use the same Imposition 328 BitStringLength or the same Imposition sub-domain for all packets on 329 which it imposes the BIER encapsulation. However, if a particular 330 BFIR is provisioned to use a particular Imposition BitStringLength 331 and a particular Imposition sub-domain when imposing the 332 encapsulation on a given set of packets, all other BFRs with BFR-ids 333 in that sub-domain SHOULD be provisioned to process received BIER 334 packets with that BitStringLength (i.e., all other BFRs with BFR-ids 335 in that sub-domain SHOULD be provisioned with that BitStringLength as 336 a Disposition BitStringLength for that sub-domain. Exceptions to 337 this rule MAY be made under certain conditions; this is discussed in 338 Section 6.10. 340 Every BFIR MUST be capable of being provisioned with an Imposition 341 BitStringLength of 256. Every BFR and BFER MUST be capable of being 342 provisioned with a Disposition BitStringLength of 256. 344 Particular BIER encapsulation types MAY allow other BitStringLengths 345 to be OPTIONALLY supported. For example, when using either of the 346 encapsulations specified in [MPLS_BIER_ENCAPS], a BFR may be capable 347 of being provisioned to use any or all of the following 348 BitStringLengths as Imposition BitStringLengths and as Disposition 349 BitStringLengths: 64, 128, 256, 512, 1024, 2048, and 4096. 351 If a BFR is capable of being provisioned with a given value of 352 BitStringLength as an Imposition BitStringLength, it MUST also be 353 capable of being provisioned with that same value as one of its 354 Disposition BitStringLengths. It SHOULD be capable of being 355 provisioned with all legal smaller values of BitStringLength as both 356 Imposition and Disposition BitStringLength. 358 In order to support transition from one BitStringLength to another, 359 every BFR MUST be capable of being provisioned to simultaneously use 360 two different Disposition BitStringLengths. 362 A BFR MUST support SI values in the range [0,15], and MAY support SI 363 values in the range [0,255]. ("Supporting the values in a given 364 range" means, in this context, that any value in the given range is 365 legal, and will be properly interpreted.) Note that for a given 366 BitStringLength, the total number of BFR-ids that can be represented 367 is the product of the BitStringLength and the number of supported 368 SIs. For example, if a deployment uses (in a given sub-domain) a 369 BitStringLength of 64 and supports 256 SIs, that deployment can only 370 support 16384 BFR-ids in that sub-domain. Even a deployment that 371 supports 256 SIs will not be able to support 65535 BFR-ids unless it 372 uses a BitStringLength of at least 256. 374 When a BFIR determines that a multicast data packet, assigned to a 375 given sub-domain, needs to be forwarded to a particular set of 376 destination BFERs, the BFIR partitions that set of BFERs into 377 subsets, where each subset contains the target BFERs whose BFR-ids in 378 the given sub-domain all resolve to the same SI. Call these the 379 "SI-subsets" for the packet. Each SI-subset can be represented by a 380 single BitString. The BFIR creates a copy of the packet for each 381 SI-subset. The BIER encapsulation is then applied to each packet. 382 The encapsulation specifies a single SI for each packet, and contains 383 the BitString that represents all the BFR-ids in the corresponding 384 SI-subset. Of course, in order to properly interpret the BitString, 385 it must be possible to infer the sub-domain-id from the encapsulation 386 as well. 388 Suppose, for example, that a BFIR determines that a given packet 389 needs to be forwarded to three BFERs, whose BFR-ids (in the 390 appropriate sub-domain) are 27, 235, and 497. The BFIR will have to 391 forward two copies of the packet. One copy, associated with SI=0, 392 will have a BitString with bits 27 and 235 set. The other copy, 393 associated with SI=1, will have a BitString with bit 241 set. 395 In order to minimize the number of copies that must be made of a 396 given multicast packet, it is RECOMMENDED that the BFR-ids be 397 assigned "densely" (see Section 2) from the numbering space. This 398 will minimize the number of SIs that have to be used in the domain. 399 However, depending upon the details of a particular deployment, other 400 assignment methods may be more advantageous. Suppose, for example, 401 that in a certain deployment, every multicast flow is either intended 402 for the "east coast" or for the "west coast". In such a deployment, 403 it would be advantageous to assign BFR-ids so that all the "west 404 coast" BFR-ids fall into the same SI-subset, and so that all the 405 "east coast" BFR-ids fall into the same SI-subset. 407 When a BFR receives a BIER data packet, it will infer the SI from the 408 encapsulation. The set of BFERs to which the packet needs to be 409 forwarded can then be inferred from the SI and the BitString. 411 In some of the examples given later in this document, we will use a 412 BitStringLength of 4, and will represent a BFR-id in the form 413 "SI:xyzw", where SI is the Set Identifier of the BFR-id (assuming a 414 BitStringLength of 4), and xyzw is a string of 4 bits. A 415 BitStringLength of 4 is used only in the examples; we would not 416 expect actual deployments to have such a small BitStringLength. 418 It is possible that several different forms of BIER encapsulation 419 will be developed. If so, the particular encapsulation that is used 420 in a given deployment will depend on the type of network 421 infrastructure that is used to realize the BIER domain. Details of 422 the BIER encapsulation(s) will be given in companion documents. An 423 encapsulation for use in MPLS networks is described in 424 [MPLS_BIER_ENCAPS]; that document also describes a very similar 425 encapsulation that can be used in non-MPLS networks. 427 4. Layering 429 It is helpful to think of the BIER architecture as consisting of 430 three layers: the "routing underlay", the "BIER layer", and the 431 "multicast flow overlay". 433 4.1. The Routing Underlay 435 The "routing underlay" establishes "adjacencies" between pairs of 436 BFRs, and determines one or more "best paths" from a given BFR to a 437 given set of BFRs. Each such path is a sequence of BFRs such that BFR(k+j) is "adjacent" to 439 BFR(k+j+1) (for 0<=j and BitStringLength can be done using the 560 advertisement capabilities of the IGP. For example, if a BIER domain 561 is also an OSPF domain, these advertisements can be done using the 562 OSPF "Opaque Link State Advertisement" (Opaque LSA) mechanism. 563 Details of the necessary extensions to OSPF and IS-IS will be 564 provided in companion documents. (See [OSPF_BIER_EXTENSIONS] and 565 [ISIS_BIER_EXTENSIONS].) 567 These advertisements enable each BFR to associate a given with a given BFR-prefix. As will be seen in 569 subsequent sections of this document, knowledge of this association 570 is an important part of the forwarding process. 572 Since each BFR needs to have a unique (in each sub-domain) BFR-id, 573 two different BFRs will not advertise ownership of the same unless there has been a provisioning error. 576 o If BFR-A determines that BFR-B and BFR-C have both advertised the 577 same BFR-id for the same sub-domain, BFR-A MUST log an error. 578 Suppose that the duplicate BFR-id is "N". When BFR-A is 579 functioning as a BFIR, it MUST NOT encode the BFR-id value N in 580 the BIER encapsulation of any packet that has been assigned to the 581 given sub-domain, even if it has determined that the packet needs 582 to be received by BFR-B and/or BFR-C. 584 This will mean that BFR-B and BFR-C cannot receive multicast 585 traffic at all in the given sub-domain until the provisioning 586 error is fixed. However, that is preferable to having them 587 receive each other's traffic. 589 o If BFR-A has been provisioned with BFR-id N for a particular sub- 590 domain, has not yet advertised its ownership of BFR-id N for that 591 sub-domain, but has received an advertisement from a different BFR 592 (say BFR-B) that is advertising ownership of BFR-id N for the same 593 sub-domain, then BFR-A SHOULD log an error, and MUST NOT advertise 594 its own ownership of BFR-id N for that sub-domain as long as the 595 advertisement from BFR-B is extant. 597 This procedure may prevent the accidental misconfiguration of a 598 new BFR from impacting an existing BFR. 600 If a BFR advertises that it has a BFR-id of 0 in a particular sub- 601 domain, other BFRs receiving the advertisement MUST interpret that 602 advertisement as meaning that the advertising BFR does not have a 603 BFR-id in that sub-domain. 605 6. BIER Intra-Domain Forwarding Procedures 607 This section specifies the rules for forwarding a BIER-encapsulated 608 data packet within a BIER domain. These rules are not intended to 609 specify an implementation strategy; to conform to this specification, 610 an implementation need only produce the same results that these rules 611 produce. 613 6.1. Overview 615 This section provides a brief overview of the BIER forwarding 616 procedures. Subsequent sub-sections specify the procedures in more 617 detail. 619 To forward a BIER-encapsulated packet: 621 1. Determine the packet's sub-domain. 623 2. Determine the packet's BitStringLength and BitString. 625 3. Determine the packet's SI. 627 4. From the sub-domain, the SI and the BitString, determine the set 628 of destination BFERs for the packet. 630 5. Using information provided by the routing underlay associated 631 with the packet's sub-domain, determine the next hop adjacency 632 for each of the destination BFERs. 634 6. It is possible that the packet's BitString will have one or more 635 bits that correspond to BFR-ids that are not in use. It is also 636 possible that the packet's BitString will have one or more bits 637 that correspond to BFERs that are unreachable, i.e., that have no 638 next hop adjacency. In the following, we will consider the "next 639 hop adjacency" for all such bit positions to be the "null" next 640 hop. 642 7. Partition the set of destination BFERs such that all the BFERs in 643 a single partition have the same next hop. We will say that each 644 partition is associated with a next hop. 646 8. For each partition: 648 a. Make a copy of the packet. 650 b. Clear any bit in the packet's BitString that identifies a 651 BFER that is not in the partition. 653 c. Transmit the packet to the associated next hop. (If the next 654 hop is the null next hop, the packet is discarded.) 656 If a BFR receives a BIER-encapsulated packet whose sub-domain, SI and 657 BitString identify that BFR itself, then the BFR is also a BFER for 658 that packet. As a BFER, it must pass the payload to the multicast 659 flow overlay. If the BitString has bits set for other BFRs, the 660 packet also needs to be forwarded further within the BIER domain. If 661 the BF(E)R also forwards one or more copies of the packet within the 662 BIER domain, the bit representing the BFR's own BFR-id MUST be clear 663 in all the copies. 665 When BIER on a BFER is to pass a packet to the multicast flow 666 overlay, it of course decapsulates the packet by removing the BIER 667 header. However, it may be necessary to provide the multicast flow 668 overlay with contextual information obtained from the BIER 669 encapsulation. The information that needs to pass between the BIER 670 layer and the multicast flow overlay is specific to the multicast 671 flow overlay. Specification of the interaction between the BIER 672 layer and the multicast flow overlay is outside the scope of this 673 specification. 675 If the BIER encapsulation contains a "Time to Live" (TTL) value, this 676 value is not, by default, inherited by the payload. If a particular 677 multicast flow overlay needs to know the TTL value, this needs to be 678 specified in whatever specification defines the interaction between 679 BIER and that multicast flow overlay. 681 If the BIER encapsulation contains a Traffic Class field, a Type of 682 Service field, a Differentiated Services field, or any field of that 683 sort, the value of that field is not, by default, passed to the 684 multicast flow overlay. If a particular multicast flow overlay needs 685 to know the values of such fields, this fact needs to be specified in 686 whatever specification defines the interaction between BIER and that 687 multicast flow overlay. 689 When BIER on a BFER passes a packet to the multicast flow overlay, 690 the overlay will determine how to further dispatch the packet. If 691 the packet needs to be forwarded into another BIER domain, then the 692 BFR will act as a BFER in one BIER domain and as a BFIR in another. 693 A BIER-encapsulated packet cannot pass directly from one BIER domain 694 to another; at the boundary between BIER domains, the packet must be 695 decapsulated and passed to the multicast flow overlay. 697 Note that when a BFR transmits multiple copies of a packet within a 698 BIER domain, only one copy will be destined to any given BFER. 699 Therefore it is not possible for any BIER-encapsulated packet to be 700 delivered more than once to any BFER. 702 6.2. BFR Neighbors 704 The "BFR Neighbors" (BFR-NBRs) of a given BFR, say BFR-A, are those 705 BFRs that, according to the routing underlay, are adjacencies of 706 BFR-A. Each BFR-NBR will have a BFR-prefix. 708 Suppose a BIER-encapsulated packet arrives at BFR-A. From the 709 packet's encapsulation, BFR-A learns the sub-domain of the packet, 710 and the BFR-ids (in that sub-domain) of the BFERs to which the packet 711 is destined. Then using the information advertised per Section 5, 712 BFR-A can find the BFR-prefix of each destination BFER. Given the 713 BFR-prefix of a particular destination BFER, say BFER-D, BFR-A learns 714 from the routing underlay (associated with the packet's sub-domain) 715 an IP address of the BFR that is the next hop on the path from BFR-A 716 to BFER-D. Let's call this next hop BFR-B. BFR-A must then 717 determine the BFR-prefix of BFR-B. (This determination can be made 718 from the information advertised per Section 5.) This BFR-prefix is 719 the BFR-NBR of BFR-A on the path from BFR-A to BFER-D. 721 Note that if the routing underlay provides multiple equal cost paths 722 from BFR-A to BFER-D, BFR-A may have multiple BFR-NBRs for BFER-D. 724 Under certain circumstances, a BFR may have adjacencies (in a 725 particular routing underlay) that are not BFRs. Please see 726 Section 6.9 for a discussion of how to handle those circumstances. 728 6.3. The Bit Index Routing Table 730 The Bit Index Routing Table (BIRT) is a table that maps from the 731 BFR-id (in a particular sub-domain) of a BFER to the BFR-prefix of 732 that BFER, and to the BFR-NBR on the path to that BFER. 734 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 735 4 (0:1000) \ \ 1 (0:0001) 736 \ \ 737 ( E ) ( F ) 738 3 (0:0100) 2 (0:0010) 740 Figure 1: BIER Topology 1 742 As an example, consider the topology shown in Figure 1. In this 743 diagram, we represent the BFR-id of each BFR in the SI:xyzw form 744 discussed in Section 3. This topology will result in the BIRT of 745 Figure 2 at BFR-B. The first column shows the BFR-id as a number and 746 also (in parentheses) in the SI:BitString format that corresponds to 747 a BitStringLength of 4. (The actual minimum BitStringLength is 64, 748 but we use 4 in the examples.) 750 Note that a BIRT is specific to a particular BIER sub-domain. 752 -------------------------------------------- 753 | BFR-id | BFR-Prefix | BFR-NBR | 754 | (SI:BitString) | of Dest BFER | | 755 ============================================ 756 | 4 (0:1000) | A | A | 757 -------------------------------------------- 758 | 1 (0:0001) | D | C | 759 -------------------------------------------- 760 | 3 (0:0100) | E | E | 761 -------------------------------------------- 762 | 2 (0:0010) | F | C | 763 -------------------------------------------- 765 Figure 2: Bit Index Routing Table at BFR-B 767 6.4. The Bit Index Forwarding Table 769 The "Bit Index Forwarding Table" (BIFT) is derived from the BIRT as 770 follows. (Note that a BIFT is specific to a particular sub-domain.) 772 Suppose that several rows in the BIRT have the same SI and the same 773 BFR-NBR. By taking the logical OR of the BitStrings of those rows, 774 we obtain a bit mask that corresponds to that combination of SI and 775 BFR-NBR. We will refer to this bit mask as the "Forwarding Bit Mask" 776 (F-BM) for that combination. 778 For example, in Figure 2, we see that two of the rows have the same 779 SI (0) and same BFR-NBR (C). The Bit Mask that corresponds to is 0011 ("0001" OR'd with "0010"). 782 The BIFT is used to map from the BFR-id of a BFER to the 783 corresponding F-BM and BFR-NBR. For example, Figure 3 shows the BIFT 784 that is derived from the BIRT of Figure 2. Note that BFR-ids 1 and 2 785 have the same SI and the same BFR-NBR, hence they have the same F-BM. 787 ------------------------------------- 788 | BFR-id | F-BM | BFR-NBR | 789 | (SI:Bitstring) | | | 790 ===================================== 791 | 1 (0:0001) | 0011 | C | 792 ------------------------------------- 793 | 2 (0:0010) | 0011 | C | 794 ------------------------------------- 795 | 3 (0:0100) | 0100 | E | 796 ------------------------------------- 797 | 4 (0:1000) | 1000 | A | 798 ------------------------------------- 800 Figure 3: Bit Index Forwarding Table 802 This Bit Index Forwarding Table (BIFT) is programmed into the data- 803 plane and used to forward packets, applying the rules specified below 804 in Section 6.5. 806 6.5. The BIER Forwarding Procedure 808 Below is the procedure that a BFR uses for forwarding a BIER- 809 encapsulated packet. 811 1. Determine the packet's SI, BitStringLength, and sub-domain. 813 2. If the BitString consists entirely of zeroes, discard the packet; 814 the forwarding process has been completed. Otherwise proceed to 815 step 3. 817 3. Find the position, call it "k", of the least significant (i.e., 818 of the rightmost) bit that is set in the packet's BitString. 819 (Remember, bits are numbered from 1, starting with the least 820 significant bit.) 822 4. If bit k identifies the BFR itself, copy the packet, and send the 823 copy to the multicast flow overlay. Then clear bit k in the 824 original packet, and go to step 2. Otherwise, proceed to step 5. 826 5. Use the value k, together with the SI, sub-domain, and 827 BitStringLength, as the 'index' into the BIFT. 829 6. Extract from the BIFT the F-BM and the BFR-NBR. 831 7. Copy the packet. Update the copy's BitString by AND'ing it with 832 the F-BM (i.e., PacketCopy->BitString &= F-BM). Then forward the 833 copy to the BFR-NBR. (If the BFR-NBR is null, the copy is just 834 discarded.) Note that when a packet is forwarded to a particular 835 BFR-NBR, its BitString identifies only those BFERs that are to be 836 reached via that BFR-NBR. 838 8. Now update the original packet's BitString by AND'ing it with the 839 INVERSE of the F-BM (i.e., Packet->Bitstring &= ~F-BM). (This 840 clears the bits that identify the BFERs to which a copy of the 841 packet has just been forwarded.) Go to step 2. 843 This procedure causes the packet to be forwarded to a particular 844 BFR-NBR only once. The number of lookups in the BIFT is the same as 845 the number of BFR-NBRs to which the packet must be forwarded; it is 846 not necessary to do a separate lookup for each destination BFER. 848 When a packet is sent to a particular BFR-NBR, the BitString is not 849 the only part of the BIER header that needs to be modified. If there 850 is a TTL field in the BIER header, it will need to be decremented. 851 In addition, when either of the encapsulations of [MPLS_BIER_ENCAPS] 852 is used, the BIFT-id field is likely to require modification, based 853 on signaling from the BFR-NBR to which the packet is being sent. 855 Suppose it has been decided (by the above rules) to send a packet to 856 a particular BFR-NBR. If that BFR-NBR is connected via multiple 857 parallel interfaces, it may be desirable to apply some form of load 858 balancing. Load balancing algorithms are outside the scope of this 859 document. However, if the packet's encapsulation contains an 860 "entropy" field, the entropy field SHOULD be respected; two packets 861 with the same value of the entropy field SHOULD be sent on the same 862 interface (if possible). 864 In some cases, the routing underlay may provide multiple equal cost 865 paths (through different BFR-NBRs) to a given BFER. This is known as 866 "Equal Cost Multiple Paths" (ECMP). The procedures described in this 867 section must be augmented in order to support load balancing over 868 ECMP. The necessary augmentations can be found in Section 6.7. 870 In the event that unicast traffic to the BFR-NBR is being sent via a 871 "bypass tunnel" of some sort, the BIER-encapsulated multicast traffic 872 send to the BFR-NBR SHOULD also be sent via that tunnel. This allows 873 any existing "Fast Reroute" schemes to be applied to multicast 874 traffic as well as to unicast traffic. 876 Some examples of these forwarding procedures can be found in 877 Section 6.6. 879 The rules given in this section can be represented by the following 880 pseudocode: 882 void ForwardBitMaskPacket (Packet) 883 { 884 SI=GetPacketSI(Packet); 885 Offset=SI*BitStringLength; 886 for (Index = GetFirstBitPosition(Packet->BitString); Index ; 887 Index = GetNextBitPosition(Packet->BitString, Index)) { 888 F-BM = BIFT[Index+Offset]->F-BM; 889 if (!F-BM) continue; 890 BFR-NBR = BIFT[Index+Offset]->BFR-NBR; 891 PacketCopy = Copy(Packet); 892 PacketCopy->BitString &= F-BM; 893 PacketSend(PacketCopy, BFR-NBR); 894 Packet->BitString &= ~F-BM; 895 } 896 } 898 Figure 4: Pseudocode 900 This pseudocode assumes that at a given BFER, the BFR-NBR entry 901 corresponding to the BFER's own BFR-id will be the BFER's own 902 BFR-prefix. It also assumes that the corresponding F-BM has only one 903 bit set, the bit representing the BFER itself. In this case, the 904 "PacketSend" function sends the packet to the multicast flow overlay. 906 This pseudocode also assumes that the F-BM for the null next hop 907 contains a 1 in a given bit position if and only if that bit position 908 corresponds either to an unused BFR-id or to an unreachable BFER. 909 When the BFR-NBR is null, the "PacketSend" function discards the 910 packet. 912 6.6. Examples of BIER Forwarding 914 In this section, we give two examples of BIER forwarding, based on 915 the topology in Figure 1. In these examples, all packets have been 916 assigned to the default sub-domain, all packets have SI=0, and the 917 BitStringLength is 4. Figure 5 shows the BIFT entries for SI=0 only. 918 For compactness, we show the first column of the BIFT, the BFR-id, 919 only as an integer. 921 BFR-A BIFT BFR-B BIFT BFR-C BIFT 922 ------------------- ------------------- ------------------- 923 | Id | F-BM | NBR | | Id | F-BM | NBR | | Id | F-BM | NBR | 924 =================== =================== =================== 925 | 1 | 0111 | B | | 1 | 0011 | C | | 1 | 0001 | D | 926 ------------------- ------------------- ------------------- 927 | 2 | 0111 | B | | 2 | 0011 | C | | 2 | 0010 | F | 928 ------------------- ------------------- ------------------- 929 | 3 | 0111 | B | | 3 | 0100 | E | | 3 | 1100 | B | 930 ------------------- ------------------- ------------------- 931 | 4 | 1000 | A | | 4 | 1000 | A | | 4 | 1100 | B | 932 ------------------- ------------------- ------------------- 934 Figure 5: BIFTs for Forwarding Examples 936 6.6.1. Example 1 938 BFR-D, BFR-E and BFR-F are BFER's. BFR-A is the BFIR. Suppose that 939 BFIR-A has learned from the multicast flow overlay that BFER-D is 940 interested in a given multicast flow. If BFIR-A receives a packet of 941 that flow from outside the BIER domain, BFIR-A applies the BIER 942 encapsulation to the packet. The encapsulation must be such that the 943 SI is zero. The encapsulation also includes a BitString, with just 944 bit 1 set and with all other bits clear (i.e., 0001). This indicates 945 that BFER-D is the only BFER that needs to receive the packet. Then 946 BFIR-A follows the procedures of Section 6.5: 948 o Since the packet's BitString is 0001, BFIR-A finds that the first 949 bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-A 950 determines that the bit mask F-BM is 0111 and the BFR-NBR is 951 BFR-B. 953 o BFR-A then makes a copy of the packet, and applies F-BM to the 954 copy: Copy->BitString &= 0111. The copy's Bitstring is now 0001 955 (0001 & 0111). 957 o The copy is now sent to BFR-B. 959 o BFR-A then updates the packet's BitString by applying the inverse 960 of the F-BM: Packet->Bitstring &= ~F-BM. As a result, the 961 packet's BitString is now 0000 (0001 & 1000). 963 o As the packet's BitString is now zero, the forwarding procedure is 964 complete. 966 When BFR-B receives the multicast packet from BFR-A, it follows the 967 same procedure. The result is that a copy of the packet, with a 968 BitString of 0001, is sent to BFR-C. BFR-C applies the same 969 procedures, and as a result sends a copy of the packet, with a 970 BitString of 0001, to BFR-D. 972 At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an 973 F-BM of 0001 and a BFR-NBR of BFR-D itself. This will cause a copy 974 of the packet to be delivered to the multicast flow overlay at BFR-D. 975 The packet's BitString will be set to 0000, and the packet will not 976 be forwarded any further. 978 6.6.2. Example 2 980 This example is similar to Example 1, except that BFIR-A has learned 981 from the multicast flow overlay that both BFER-D and BFER-E are 982 interested in a given multicast flow. If BFIR-A receives a packet of 983 that flow from outside the BIER domain, BFIR-A applies the BIER 984 encapsulation to the packet. The encapsulation must be such that the 985 SI is zero. The encapsulation also includes a BitString with two 986 bits set: bit 1 is set (as in example 1) to indicate that BFR-D is a 987 BFER for this packet, and bit 3 is set to indicate that BFR-E is a 988 BFER for this packet. I.e., the BitString (assuming again a 989 BitStringLength of 4) is 0101. To forward the packet, BFIR-A follows 990 the procedures of Section 6.5: 992 o Since the packet's BitString is 0101, BFIR-A finds that the first 993 bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-A 994 determines that the bit mask F-BM is 0111 and the BFR-NBR is 995 BFR-B. 997 o BFR-A then makes a copy of the packet, and applies the F-BM to the 998 copy: Copy->BitString &= 0111. The copy's Bitstring is now 0101 999 (0101 & 0111). 1001 o The copy is now sent to BFR-B. 1003 o BFR-A then updates the packet's BitString by applying the inverse 1004 of the F-BM: Packet->Bitstring &= ~F-BM. As a result, the 1005 packet's BitString is now 0000 (0101 & 1000). 1007 o As the packet's BitString is now zero, the forwarding procedure is 1008 complete. 1010 When BFR-B receives the multicast packet from BFR-A, it follows the 1011 procedure of Section 6.5, as follows: 1013 o Since the packet's BitString is 0101, BFR-B finds that the first 1014 bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-B 1015 determines that the bit mask F-BM is 0011 and the BFR-NBR is 1016 BFR-C. 1018 o BFR-B then makes a copy of the packet, and applies the F-BM to the 1019 copy: Copy->BitString &= 0011. The copy's Bitstring is now 0001 1020 (0101 & 0011). 1022 o The copy is now sent to BFR-C. 1024 o BFR-B then updates the packet's BitString by applying the inverse 1025 of the F-BM: Packet->Bitstring &= F-BM. As a result, the 1026 packet's BitString is now 0100 (0101 & 1100). 1028 o Now BFR-B finds the next bit in the packet's (modified) BitString. 1029 This is bit 3. Looking at entry 3 in its BIFT, BFR-B determines 1030 that the F-BM is 0100 and the BFR-NBR is BFR-E. 1032 o BFR-B then makes a copy of the packet, and applies the F-BM to the 1033 copy: Copy->BitString &= 0100. The copy's Bitstring is now 0100 1034 (0100 & 0100). 1036 o The copy is now sent to BFR-E. 1038 o BFR-B then updates the packet's BitString by applying the inverse 1039 of the F-BM: Packet->Bitstring &= ~F-BM. As a result, the 1040 packet's BitString is now 0000 (0100 & 1011). 1042 o As the packet's BitString is now zero, the forwarding procedure is 1043 complete. 1045 Thus BFR-B forwards two copies of the packet. One copy of the 1046 packet, with BitString 0001, has now been sent from BFR-B to BFR-C. 1047 Following the same procedures, BFR-C will forward the packet to 1048 BFER-D. 1050 At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an 1051 F-BM of 0001 and a BFR-NBR of BFR-D itself. This will cause a copy 1052 of the packet to be delivered to the multicast flow overlay at BFR-D. 1053 The packet's BitString will be set to 0000, and the packet will not 1054 be forwarded any further. 1056 The other copy of the packet has been sent from BFR-B to BFER-E, with 1057 BitString 0100. 1059 At BFER-E, the BIFT entry (not pictured) for BFR-id 3 will specify an 1060 F-BM of 0100 and a BFR-NBR of BFR-E itself. This will cause a copy 1061 of the packet to be delivered to the multicast flow overlay at BFR-E. 1062 The packet's BitString will be set to 0000, and the packet will not 1063 be forwarded any further. 1065 6.7. Equal Cost Multi-path Forwarding 1067 In many networks, the routing underlay will provide multiple equal 1068 cost paths from a given BFR to a given BFER. When forwarding 1069 multicast packets through the network, it can be beneficial to take 1070 advantage of this by load balancing among those paths. This feature 1071 is known as "equal cost multiple path forwarding", or "ECMP". 1073 BIER supports ECMP, but the procedures of Section 6.5 must be 1074 modified slightly. Two ECMP procedures are defined. In the first 1075 (described in Section 6.7.1), the choice among equal-cost paths taken 1076 by a given packet from a given BFR to a given BFER depends on (a) the 1077 packet's entropy, and (b) the other BFERs to which that packet is 1078 destined. In the second (described in Section 6.7.2), the choice 1079 depends only upon the packet's entropy. 1081 There are tradeoffs between the two forwarding procedures described 1082 here. In the procedure of Section 6.7.1, the number of packet 1083 replications is minimized. The procedure in Section 6.7.1 also uses 1084 less memory in the BFR. In the procedure of Section 6.7.2, the path 1085 traveled by a given packet from a given BFR to a given BFER is 1086 independent of the other BFERs to which the packet is destined. 1087 While the procedures of Section 6.7.2 may cause more replications, 1088 they provide a more predictable behavior. 1090 The two procedures described here operate on identical packet formats 1091 and will interoperate correctly. However, if deterministic behavior 1092 is desired, then all BFRs would need to use the procedure from 1093 Section 6.7.2. 1095 6.7.1. Non-deterministic ECMP 1097 Figure 6 shows the operation of non-deterministic ECMP in BIER. 1099 BFR-A BIFT BFR-B BIFT BFR-C BIFT 1100 ------------------- ------------------- ------------------- 1101 | Id | F-BM | NBR | | Id | F-BM | NBR | | Id | F-BM | NBR | 1102 =================== =================== =================== 1103 | 1 | 0111 | B | | 1 | 0011 | C | | 1 | 0001 | D | 1104 ------------------- ------------------- ------------------- 1105 | 2 | 0111 | B | | 2 | 0011 | C | | 2 | 0010 | F | 1106 ------------------- | | 0110 | E | ------------------- 1107 | 3 | 0111 | B | ------------------- | 3 | 1100 | B | 1108 ------------------- | 3 | 0110 | E | ------------------- 1109 | 4 | 1000 | A | ------------------| | 4 | 1100 | B | 1110 ------------------- | 4 | 1000 | A | ------------------- 1111 ------------------- 1113 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 1114 4 (0:1000) \ \ 1 (0:0001) 1115 \ \ 1116 ( E ) ------------ ( F ) 1117 3 (0:0100) 2 (0:0010) 1119 Figure 6: Example of ECMP 1121 In this example, BFR-B has two equal cost paths to reach BFER-F, one 1122 via BFR-C and one via BFR-E. Since the BFR-id of BFER-F is 2, this 1123 is reflected in entry 2 of BFR-B's BIFT. Entry 2 shows that BFR-B 1124 has a choice of two BFR-NBRs for BFER-B, and that a different F-BM is 1125 associated with each choice. When BFR-B looks up entry 2 in the 1126 BIFT, it can choose either BFR-NBR. However, when following the 1127 procedures of Section 6.5, it MUST use the F-BM corresponding to the 1128 BFR-NBR that it chooses. 1130 How the choice is made is an implementation matter. However, the 1131 usual rules for ECMP apply: packets of a given flow SHOULD NOT be 1132 split among two paths, and any "entropy" field in the packet's 1133 encapsulation SHOULD be respected. 1135 Note however that by the rules of Section 6.5, any packet destined 1136 for both BFER-D and BFER-F will be sent via BFR-C. 1138 6.7.2. Deterministic ECMP 1140 With the procedures of Section 6.7.1, where ECMP paths exist, the 1141 path a packet takes to reach any particular BFER depends not only on 1142 routing and on the packet's entropy, but also on the set of other 1143 BFERs to which the packet is destined. 1145 For example consider the following scenario in the network of 1146 Figure 6. 1148 o There is a sequence of packets being transmitted by BFR-A, some of 1149 which are destined for both D and F, and some of which are 1150 destined only for F. 1152 o All the packets in this sequence have the same entropy value, call 1153 it "Q". 1155 o At BFR-B, when a packet with entropy value Q is forwarded via 1156 entry 2 in the BIFT, the packet is sent to E. 1158 Using the forwarding procedure of Section 6.7.1, packets of this 1159 sequence that are destined for both D and F are forwarded according 1160 to entry 1 in the BIFT, and thus will reach F via the path A-B-C-F. 1161 However, packets of this sequence that are destined only for F are 1162 forwarded according to entry 2 in the BIFT, and thus will reach F via 1163 the path A-B-E-F. 1165 That procedure minimizes the number of packets transmitted by BFR B. 1166 However, consider the following scenario: 1168 o Beginning at time t0, the multicast flow in question needs to be 1169 received ONLY by BFER-F; 1171 o Beginning at a later time, t1, the flow needs to be received by 1172 both BFER-D and BFER-F. 1174 o Beginning at a later time, t2, the no longer needs to be received 1175 by D, but still needs to be received by F. 1177 Then from t0 until t1, the flow will travel to F via the path 1178 A-B-E-F. From t1 until t2, the flow will travel to F via the path 1179 A-B-C-F. And from t2, the flow will again travel to F via the path 1180 A-B-E-F. 1182 The problem is that if D repeatedly joins and leaves the flow, the 1183 flow's path from B to F will keep switching. This could cause F to 1184 receive packets out of order. It also makes troubleshooting 1185 difficult. For example, if there is some problem on the E-F link, 1186 receivers at F will get good service when the flow is also going to D 1187 (avoiding the E-F link), but bad service when the flow is not going 1188 to D. Since it is hard to know which path is being used at any given 1189 time, this may be hard to troubleshoot. Also, it is very difficult 1190 to perform a traceroute that is known to follow the path taken by the 1191 flow at any given time. 1193 The source of this difficulty is that, in the procedures of 1194 Section 6.7.1, the path taken by a particular flow to a particular 1195 BFER depends upon whether there are lower numbered BFERs that are 1196 also receiving the flow. Thus the choice among the ECMP paths is 1197 fundamentally non-deterministic. 1199 Deterministic forwarding can be achieved by using multiple BIFTs, 1200 such that each row in a BIFT has only one path to each destination, 1201 but the multiple ECMP paths to any particular destination are spread 1202 across the multiple tables. When a BIER-encapsulated packet arrives 1203 to be forwarded, the BFR uses a hash of the BIER Entropy field to 1204 determine which BIFT to use, and then the normal BIER forwarding 1205 algorithm (as described in Sections 6.5 and 6.6) is used with the 1206 selected BIFT. 1208 As an example, suppose there are two paths to destination X (call 1209 them X1 and X2), and four paths to destination Y (call them Y1, Y2, 1210 Y3, and Y4). If there are, say, four BIFTs, one BIFT would have 1211 paths X1 and Y1, one would have X1 and Y2, one would have X2 and Y3, 1212 and one would have X2 and Y4. If traffic to X is split evenly among 1213 these four BIFTs, the traffic will be split evenly between the two 1214 paths to X; if traffic to Y is split evenly among these four BIFTs, 1215 the traffic will be split evenly between the four paths to Y. 1217 Note that if there are three paths to one destination and four paths 1218 to another, 12 BIFTs would be required in order to get even splitting 1219 of the load to each of those two destinations. Of course, each BIFT 1220 uses some memory, and one might be willing to have less optimal 1221 splitting in order to have fewer BIFTs. How that tradeoff is made is 1222 an implementation or deployment decision. 1224 6.8. Prevention of Loops and Duplicates 1226 The BitString in a BIER-encapsulated packet specifies the set of 1227 BFERs to which that packet is to be forwarded. When a BIER- 1228 encapsulated packet is replicated, no two copies of the packet will 1229 ever have a BFER in common. If one of the packet's BFERs forwards 1230 the packet further, that will first clear the bit that identifies 1231 itself. As a result, duplicate delivery of packets is not possible 1232 with BIER. 1234 As long as the routing underlay provides a loop free path between 1235 each pair of BFRs, BIER-encapsulated packets will not loop. Since 1236 the BIER layer does not create any paths of its own, there is no need 1237 for any BIER-specific loop prevention techniques beyond the 1238 forwarding procedures specified in Section 6.5. 1240 If, at some time, the routing underlay is not providing a loop free 1241 path between BFIR-A and BFER-B, then BIER encapsulated packets may 1242 loop while traveling from BFIR-A to BFER-B. However, such loops will 1243 never result in delivery of duplicate packets to BFER-B. 1245 These properties of BIER eliminate the need for the "reverse path 1246 forwarding" (RPF) check that is used in conventional IP multicast 1247 forwarding. 1249 6.9. When Some Nodes do not Support BIER 1251 The procedures of section Section 6.2 presuppose that, within a given 1252 BIER domain, all the nodes adjacent to a given BFR in a given routing 1253 underlay are also BFRs. However, it is possible to use BIER even 1254 when this is not the case, as long as the ingress and egress nodes 1255 are BFRs. In this section, we assume that the routing underlay is an 1256 SPF-based IGP that computes a shortest path tree from each node to 1257 all other nodes in the domain. 1259 At a given BFR, say BFR B, start with a copy of the IGP-computed 1260 shortest path tree from BFR B to each router in the domain. (This 1261 tree is computed by the SPF algorithm of the IGP.) Let's call this 1262 copy the "BIER-SPF tree rooted at BFR B." BFR B then modifies this 1263 BIER-SPF tree as follows. 1265 1. BFR B looks in turn at each of B's child nodes on the BIER-SPF 1266 tree. 1268 2. If one of the child nodes does not support BIER, BFR B removes 1269 that node from the tree. The child nodes of the node that has 1270 just been removed are then re-parented on the tree, so that BFR B 1271 now becomes their parent. 1273 3. BFR B then continues to look at each of its child nodes, 1274 including any nodes that have been re-parented to B as a result 1275 of the previous step. 1277 When all of the child nodes (the original child nodes plus any new 1278 ones) have been examined, B's children on the BIER-SPF tree will all 1279 be BFRs. 1281 When the BIFT is constructed, B's child nodes on the BIER-SPF tree 1282 are considered to be the BFR-NBRs. The F-BMs must be computed 1283 appropriately, based on the BFR-NBRs. 1285 If one of the encapsulations of [MPLS_BIER_ENCAPS] is used, the BIFT- 1286 id field of the packet may also be modified. The BIFT-id field of an 1287 incoming BIER packet implicitly identifies a Set Identifier, a Sub- 1288 Domain and a BitStringLength. If the packet is sent to a particular 1289 BFR-NBR, the BIFT-id field must be changed to whatever value that 1290 BFR-NBR has advertised for the same Set Identifier, Sub-Domain, and 1291 BitStringLength. The TTL field in the BIFT header MUST also be 1292 decremented. (If the encapsulation of Section 2.1 of 1294 [MPLS_BIER_ENCAPS] is used, this is essentially an MPLS label swap 1295 operation.) 1297 B may now have BFR-NBRs that are not "directly connected" to B via 1298 layer 2. To send a packet to one of these BFR-NBRs, B will have to 1299 send the packet through a unicast tunnel. In an MPLS network, this 1300 may be as simple as finding the IGP unicast next hop to the child 1301 node, and pushing on (above the BIER encapsulation header) an MPLS 1302 label that the IGP next hop has bound to an address of the child 1303 node. (This assumes that the packet is using an MPLS-based BIER 1304 encapsulation, such as the one specified in Section 2.1 of 1305 [MPLS_BIER_ENCAPS].) Of course, the BIFT-id in the BIER 1306 encapsulation header must be the BIFT-id advertised by the child node 1307 for the packet's Set Index, Sub-Domain, and BitStringLength. 1309 If for some reason the unicast tunnel cannot be an MPLS tunnel, any 1310 other kind of tunnel can be used, as long as the encapsulation for 1311 that tunnel type has a way of indicating that the payload is a BIER- 1312 encapsulated packet. 1314 Note that if a BIER-encapsulated packet is not using an MPLS-based 1315 BIER encapsulation, it will not be possible to send it through an 1316 MPLS tunnel unless it is known that the tunnel only carries BIER 1317 packets. The reason is that MPLS has no "next protocol type" field. 1318 This is not a problem if an MPLS-based BIER encapsulation is used, 1319 because in that case the BIER encapsulation begins with an MPLS label 1320 that identifies the packet as a BIER-encapsulated packet. 1322 Of course, the above is not meant as an implementation technique, 1323 just as a functional description. 1325 While the above description assumes that the routing underlay 1326 provides an SPF tree, it may also be applicable to other types of 1327 routing underlay. 1329 The technique above can also be used to provide "node protection" 1330 (i.e., to provide fast reroute around nodes that are believed to have 1331 failed). If BFR B has a failed BFR-NBR, B can remove the failed 1332 BFR-NBR from the BIER-SPF tree, and can then re-parent the child 1333 BFR-NBRs of the failed BFR-NBR so that they appear to be B's own 1334 child nodes on the tree (i.e., so that they appear to be B's 1335 BFR-NBRs). Then the usual BIER forwarding procedures apply. 1336 However, getting the packet from B to the child nodes of the failed 1337 BFR-NBR is a bit more complicated, as it may require using a unicast 1338 bypass tunnel to get around the failed node. 1340 A simpler variant of step 2 above would be the following: 1342 If one of the child nodes does not support BIER, BFR B removes 1343 that node from the tree. All BFERs that are reached through that 1344 child node are then re-parented on the tree, so that BFR B now 1345 becomes their parent. 1347 This variant is simpler because the set of BFERs that are reached 1348 through a particular child node of B can be determined from the F-BM 1349 in the BIFT. However, if this variant is used, the results are less 1350 optimal, because packets will be unicast directly from B to the BFERs 1351 that are reachable through the non-BIER child node. 1353 When using a unicast MPLS tunnel to get a packet to a BFR-NBR: 1355 o the TTL of the MPLS label entry representing the tunnel SHOULD be 1356 set to a large value, rather than being copied from the TTL value 1357 from the BIER encapsulation header, and 1359 o when the tunnel labels are popped off, the TTL from the tunnel 1360 labels SHOULD NOT be copied to the BIER encapsulation header. 1362 In other words, the TTL processing for the tunnel SHOULD be as 1363 specified in [RFC3443] for "Pipe Model" and "Short Pipe Model" LSPs. 1364 The same principle applies if the tunnels are not MPLS tunnels; the 1365 BIER packet SHOULD NOT inherit the TTL from the tunnel encapsulation. 1366 That way, the TTL of the BIER encapsulation header constrains only 1367 the number of BFRs that the packet may traverse, not the total number 1368 of hops. 1370 If two BIER packets have the same value in the entropy field of their 1371 respective BIER headers, and if both are transmitted through a given 1372 tunnel, it is desirable for the tunnel encapsulation to preserve the 1373 fact that the two packets have the same entropy. 1375 The material in this section presupposes that a given node is either 1376 a BFR or not, and that a BFR supports BIER on all its interfaces. It 1377 is however possible that a router will have some line cards that 1378 support BIER and some that do not. In such a case, one can think of 1379 the router as a "partial-BFR", that supports BIER only on some of its 1380 interfaces. If it is desired to deploy such partial-BFRs, one can 1381 use the multi-topology features of the IGP to set up a BIER-specific 1382 topology. This topology would exclude all the non-BIER-capable 1383 interfaces that attach to BFRs. BIER would then have to be run in a 1384 sub-domain that is bound to this topology. If unicast tunnels are 1385 used to bypass non-BFRs, either the tunnels have to be restricted to 1386 this topology, or the tunnel endpoints have to be BFRs that do not 1387 have any non-BIER-capable interfaces. 1389 6.10. Use of Different BitStringLengths within a Domain 1391 It is possible for different BFRs within a BIER domain to be using 1392 different Imposition and/or Disposition BitStringLengths. As stated 1393 in Section 3: 1395 "if a particular BFIR is provisioned to use a particular 1396 Imposition BitStringLength and a particular Imposition sub-domain 1397 when imposing the encapsulation on a given set of packets, all 1398 other BFRs with BFR-ids in that sub-domain SHOULD be provisioned 1399 to process received BIER packets with that BitStringLength (i.e., 1400 all other BFRs with BFR-ids in that sub-domain SHOULD be 1401 provisioned with that BitStringLength as a Disposition 1402 BitStringLength for that sub-domain)." 1404 Note that mis-provisioning can result in "black holes". If a BFIR 1405 creates a BIER packet with a particular BitStringLength, and if that 1406 packet needs to travel through a BFR that cannot process received 1407 BIER packets with that BitStringLength, then it may be impossible to 1408 forward the packet to all of the BFERs identified in its BIER header. 1409 Section 6.10.1 defines a procedure, the "BitStringLength 1410 Compatibility Check", that can be used to detect the possibility of 1411 such black holes. 1413 However, failure of the BitStringLength Compatibility Check does not 1414 necessarily result in the creation of black holes; Section 6.10.2 1415 specifies OPTIONAL procedures that allow BIER forwarding to proceed 1416 without black holes, even if the BitStringLength Compatibility Check 1417 fails. 1419 If the procedures of Section 6.10.2 are not deployed, but the 1420 BitStringLength Compatibility Check fails at some BFIR, the BFIR has 1421 two choices: 1423 o Create BIER packets with the provisioned Imposition 1424 BitStringLength, even though the packets may not be able to reach 1425 all the BFERs identified in their BitStrings 1427 o Use an Imposition BitStringLength that passes the Compatibility 1428 Check (assuming that there is one), even if this is not the 1429 provisioned Imposition BitStringLength. 1431 Section 6.10.1 discusses the implications of making one or the other 1432 of these choices. 1434 There will be times when an operator wishes to change the 1435 BitStringLengths used in a particular BIER domain. Section 6.10.3 1436 specifies a simple procedure that can be used to transition a BIER 1437 domain from one BitStringLength to another. 1439 6.10.1. BitStringLength Compatibility Check 1441 When a BFIR needs to encapsulate a packet, the BFIR first assigns the 1442 packet to a sub-domain. Then the BFIR chooses an Imposition 1443 BitStringLength L for the packet. The choice of Imposition 1444 BitStringLength is by provisioning. However, the BFIR should also 1445 perform the BitStringLength Compatibility Check defined below. 1447 The combination of Sub-Domain S and Imposition BitStringLength L 1448 passes the BitStringLength Compatibility Check if and only if the 1449 following condition holds: 1451 Every BFR that has advertised its membership in sub-domain S has 1452 also advertised that it is using Disposition BitStringLength L 1453 (and possibly other BitStringLengths as well) in that Sub-Domain. 1454 (If the MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is 1455 being used, this means that every BFR that is advertising a label 1456 for Sub-Domain S is advertising a label for the combination of 1457 Sub-Domain S and Disposition BitStringLength L.) 1459 If a BFIR has been provisioned to use a particular Imposition 1460 BitStringLength and a particular sub-domain for some set of packets, 1461 and if that combination of Imposition BitStringLength and sub-domain 1462 does not pass the BitStringLength Compatibility Check, the BFIR 1463 SHOULD log this fact as an error. It then has the following choice 1464 about what to do with the packets: 1466 1. The BFIR MAY use the provisioned Imposition BitStringLength 1467 anyway. If the procedure Paragraph 2 or Paragraph 3 of 1468 Section 6.10.2 are deployed, this will not cause black holes, and 1469 may actually be the optimal result. It should be understood 1470 though that the BFIR cannot determine by signaling whether those 1471 procedures have been deployed. 1473 2. If the BFIR is capable of using an Imposition BitStringlength 1474 that does pass the BitStringLength Compatibility Check for the 1475 particular sub-domain, the BFIR MAY use that Imposition 1476 BitStringLength instead. 1478 Which of these two choices to make is itself determined by 1479 provisioning. 1481 Note that discarding the packets is not one of the allowable choices. 1482 Suppose, for example, that all the BFIRs are provisioned to use 1483 Imposition BitStringLength L for a particular sub-domain S, but one 1484 BFR has not been provisioned to use Disposition BitStringLength L for 1485 sub-domain S. This will cause the BitStringLength Compatibility 1486 Check to fail. If the BFIR sends packets with BitStringLength L and 1487 sub-domain S, the mis-provisioned BFR will not be able to forward 1488 those packets, and thus the packets may only be able to reach a 1489 subset of the BFERs to which they are destined. However, this is 1490 still better than having the BFIRs drop the packets; if the BFIRs 1491 discard the packets, the packets won't reach any of the BFERs to 1492 which they are destined at all. 1494 If the procedures of Section 6.10.2 have not been deployed, choice 2 1495 might seem like a better option. However, there might not be any 1496 Imposition BitStringLength that a given BFIR can use that also passes 1497 the BitStringLength Compatibility Check. If it is desired to use 1498 choice 2 in a particular deployment, then there should be a "Fallback 1499 Disposition BitStringLength", call it F, such that: 1501 o Every BFR advertises that it uses BitStringLength F as a 1502 Disposition BitStringLength for every sub-domain, and 1504 o If a BFIR is provisioned to use Imposition BitStringLength X and 1505 Imposition sub-domain S for a certain class of packets, but the 1506 BitStringLength Compatibility check fails for the combination of 1507 BitStringLength X and sub-domain S, then the BFIR will fall back 1508 to using BitStringLength F as the Imposition BitStringLength 1509 whenever the Imposition sub-domain is S. 1511 It is RECOMMENDED that the value of F be 256. 1513 6.10.2. Handling BitStringLength Mismatches 1515 Suppose a packet has been BIER-encapsulated with a BitStringLength 1516 value of X, and that the packet has arrived at BFR-A. Now suppose 1517 that according to the routing underlay, the next hop is BFR-B, but 1518 BFR-B is not using X as one of its Disposition BitStringLengths. 1519 What should BFR-A do with the packet? BFR-A has three options. It 1520 MUST do one of the three, but the choice of which procedure to follow 1521 is a local matter. The three options are: 1523 1. BFR-A MAY discard the packet. 1525 2. BFR-A MAY re-encapsulate the packet, using a BIER header whose 1526 BitStringLength value is supported by BFR-B. 1528 Note that if BFR-B only uses Disposition BitStringLength values 1529 that are smaller than the BitStringLength value of the packet, 1530 this may require creating additional copies of the packet. 1531 Whether additional copies actually have to be created depends 1532 upon the bits that are actually set in the original packet's 1533 BitString. 1535 3. BFR-A MAY treat BFR-B as if BFR-B did not support BIER at all, 1536 and apply the rules of Section 6.9. 1538 Note that there is no signaling that enables a BFR to advertise which 1539 of the three options it will use. 1541 Option 2 can be useful if there is a region of the BIER domain where 1542 the BFRs are capable of using a long BitStringLength, and a region 1543 where the BFRs are only capable of using a shorter BitStringLength. 1545 6.10.3. Transitioning from One BitStringLength to Another 1547 Suppose one wants to migrate the BitStringLength used in a particular 1548 BIER domain from one value (X) to another value (Y). The following 1549 migration procedure can be used. This procedure allows the BFRs to 1550 be reprovisioned one at a time, and does not require a "flag day". 1552 First, upgrade all the BFRs in the domain so that they use both value 1553 X and value Y as their Disposition BitStringLengths. Once this is 1554 done, reprovision the BFIRs so that they use BitStringLength value Y 1555 as the Imposition BitStringLength. Once that is done, one may 1556 optionally reprovision all the BFRs so that they no longer use 1557 Dispostion BitStringLength X. 1559 7. IANA Considerations 1561 This document contains no actions for IANA. 1563 8. Security Considerations 1565 When BIER is paired with a particular multicast flow overlay, it 1566 inherits the security considerations of that layer. Similarly, when 1567 BIER is paired with a particular routing underlay, it inherits the 1568 security considerations of that layer. 1570 If the BIER encapsulation of a particular packet specifies an SI or a 1571 BitString other than the one intended by the BFIR, the packet is 1572 likely to be misdelivered. If the BIER encapsulation of a packet is 1573 modified (through error or malfeasance) in a way other than that 1574 specified in this document, the packet may be misdelivered. 1576 If the procedures used for advertising BFR-ids and BFR-prefixes are 1577 not secure, an attack on those procedures may result in incorrect 1578 delivery of BIER-encapsulated packets. 1580 Every BFR must be provisioned to know which of its interfaces lead to 1581 a BIER domain and which do not. If two interfaces lead to different 1582 BIER domains, the BFR must be provisioned to know that those two 1583 interfaces lead to different BIER domains. If the provisioning is 1584 not correct, BIER-encapsulated packets from one BIER domain may 1585 "leak" into another; this is likely to result in misdelivery of 1586 packets. 1588 9. Acknowledgements 1590 The authors wish to thank Rajiv Asati, Alia Atlas, John Bettink, Ross 1591 Callon (who contributed much of the text on deterministic ECMP), 1592 Nagendra Kumar, Christian Martin, Neale Ranns, Greg Shepherd, Albert 1593 Tian, Ramji Vaithianathan, Xiaohu Xu and Jeffrey Zhang for their 1594 ideas and contributions to this work. 1596 10. Contributor Addresses 1598 Below is a list of other contributing authors in alphabetical order: 1600 Gregory Cauchie 1601 Bouygues Telecom 1603 Email: gcauchie@bouyguestelecom.fr 1605 Mach (Guoyi) Chen 1606 Huawei 1608 Email: mach.chen@huawei.com 1610 Arkadiy Gulko 1611 Thomson Reuters 1612 195 Broadway 1613 New York NY 10007 1614 United States 1616 Email: arkadiy.gulko@thomsonreuters.com 1618 Wim Henderickx 1619 Nokia 1620 Copernicuslaan 50 1621 Antwerp 2018 1622 Belgium 1624 Email: wim.henderickx@nokia.com 1625 Martin Horneffer 1626 Deutsche Telekom 1627 Hammer Str. 216-226 1628 Muenster 48153 1629 Germany 1631 Email: Martin.Horneffer@telekom.de 1633 Uwe Joorde 1634 Deutsche Telekom 1635 Hammer Str. 216-226 1636 Muenster D-48153 1637 Germany 1639 Email: Uwe.Joorde@telekom.de 1641 Luay Jalil 1642 Verizon 1643 1201 E Arapaho Rd. 1644 Richardson, TX 75081 1645 United States 1647 Email: luay.jalil@verizon.com 1649 Jeff Tantsura 1651 Email: jefftant.ietf@gmail.com 1653 11. References 1655 11.1. Normative References 1657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1658 Requirement Levels", BCP 14, RFC 2119, 1659 DOI 10.17487/RFC2119, March 1997, 1660 . 1662 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 1663 in Multi-Protocol Label Switching (MPLS) Networks", 1664 RFC 3443, DOI 10.17487/RFC3443, January 2003, 1665 . 1667 11.2. Informative References 1669 [BIER-MVPN] 1670 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 1671 Przygienda, "Multicast VPN Using BIER", internet-draft 1672 draft-ietf-bier-mvpn-05.txt, January 2017. 1674 [Boivie_Feldman] 1675 Boivie, R. and N. Feldman, "Small Group Multicast", 1676 (expired) draft-boivie-sgm-02.txt, February 2001. 1678 [ISIS_BIER_EXTENSIONS] 1679 Ginsberg, L., Przygienda, T., Aldrin, S., and J. Zhang, 1680 "BIER Support via ISIS", internet-draft draft-ietf-bier- 1681 isis-extensions-04.txt, March 2017. 1683 [MPLS_BIER_ENCAPS] 1684 Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., 1685 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 1686 Explicit Replication in MPLS and non-MPLS Networks 1687 Networks", internet-draft draft-ietf-bier-mpls- 1688 encapsulation-07.txt, June 2017. 1690 [OSPF_BIER_EXTENSIONS] 1691 Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 1692 Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions 1693 for Bit Index Explicit Replication", internet-draft draft- 1694 ietf-bier-ospf-bier-extensions-05.txt, March 2017. 1696 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1697 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1698 2012, . 1700 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1701 Encodings and Procedures for Multicast in MPLS/BGP IP 1702 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1703 . 1705 Authors' Addresses 1707 IJsbrand Wijnands (editor) 1708 Cisco Systems, Inc. 1709 De Kleetlaan 6a 1710 Diegem 1831 1711 Belgium 1713 Email: ice@cisco.com 1714 Eric C. Rosen (editor) 1715 Juniper Networks, Inc. 1716 10 Technology Park Drive 1717 Westford, Massachusetts 01886 1718 United States 1720 Email: erosen@juniper.net 1722 Andrew Dolganow 1723 Nokia 1724 600 March Rd. 1725 Ottawa, Ontario K2K 2E6 1726 Canada 1728 Email: andrew.dolganow@nokia.com 1730 Tony Przygienda 1731 Juniper Networks, Inc. 1732 1194 N. Mathilda Ave. 1733 Sunnyvale, California 94089 1734 United States 1736 Email: prz@juniper.net 1738 Sam K Aldrin 1739 Google, Inc. 1740 1600 Amphitheatre Parkway 1741 Mountain View, California 1742 United States 1744 Email: aldrin.ietf@gmail.com