idnits 2.17.1 draft-wijnands-bier-architecture-02.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 (December 4, 2014) is 3431 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 294 -- Looks like a reference, but probably isn't: '255' on line 294 -- Looks like a reference, but probably isn't: '1' on line 259 -- Looks like a reference, but probably isn't: '65535' on line 244 -- Looks like a reference, but probably isn't: '256' on line 257 -- Looks like a reference, but probably isn't: '512' on line 259 -- Looks like a reference, but probably isn't: '15' on line 293 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: Standards Track E. Rosen, Ed. 5 Expires: June 7, 2015 Juniper Networks, Inc. 6 A. Dolganow 7 Alcatel-Lucent 8 T. Przygienda 9 Ericsson 10 S. Aldrin 11 Huawei Technologies 12 December 4, 2014 14 Multicast using Bit Index Explicit Replication 15 draft-wijnands-bier-architecture-02 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 22 any explicit tree-building protocol, nor does it require intermediate 23 nodes to maintain any per-flow state. This architecture is known as 24 "Bit Index Explicit Replication" (BIER). When a multicast data 25 packet enters the domain, the ingress router determines the set of 26 egress routers to which the packet needs to be sent. The ingress 27 router then encapsulates the packet in a BIER header. The BIER 28 header contains a bitstring in which each bit represents exactly one 29 egress router in the domain; to forward the packet to a given set of 30 egress routers, the bits corresponding to those routers are set in 31 the BIER header. Elimination of the per-flow state and the explicit 32 tree-building protocols results in a considerable simplification. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 7, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. The BFR Identifier and BFR-Prefix . . . . . . . . . . . . . . 5 69 3. Encoding BFR Identifiers in BitStrings . . . . . . . . . . . 6 70 4. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. The Routing Underlay . . . . . . . . . . . . . . . . . . 8 72 4.2. The BIER Layer . . . . . . . . . . . . . . . . . . . . . 9 73 4.3. The Multicast Flow Overlay . . . . . . . . . . . . . . . 10 74 5. Advertising BFR-ids and BFR-Prefixes . . . . . . . . . . . . 10 75 6. BIER Intra-Domain Forwarding Procedures . . . . . . . . . . . 11 76 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.2. BFR Neighbors . . . . . . . . . . . . . . . . . . . . . . 13 78 6.3. The Bit Index Routing Table . . . . . . . . . . . . . . . 13 79 6.4. The Bit Index Forwarding Table . . . . . . . . . . . . . 14 80 6.5. The BIER Forwarding Procedure . . . . . . . . . . . . . . 15 81 6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 17 82 6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 18 83 6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18 84 6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 20 85 6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 21 86 6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 22 87 6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 23 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 91 10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 24 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 94 11.2. Informative References . . . . . . . . . . . . . . . . . 26 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 97 1. Introduction 99 This document specifies a new architecture for the forwarding of 100 multicast data packets. It provides optimal forwarding of multicast 101 data packets through a "multicast domain". However, it does not 102 require any explicit tree-building protocol, and does not require 103 intermediate nodes to maintain any per-flow state. This architecture 104 is known as "Bit Index Explicit Replication" (BIER). 106 A router that supports BIER is known as a "Bit-Forwarding Router" 107 (BFR). A BIER domain is a connected set of BFRs. The BIER control 108 plane protocols (see Section 4.2) run within a BIER domain, allowing 109 the BFRs within that domain to exchange the necessary information. 111 A multicast data packet enters a BIER domain at a "Bit-Forwarding 112 Ingress Router" (BFIR), and leaves the BIER domain at one or more 113 "Bit-Forwarding Egress Routers" (BFERs). A BFR that receives a 114 multicast data packet from another BFR in the same BIER domain, and 115 forwards the packet to another BFR in the same BIER domain, will be 116 known as a "transit BFR" for that packet. A single BFR may be a BFIR 117 for some multicast traffic while also being a BFER for some multicast 118 traffic and a transit BFR for some multicast traffic. In fact, a BFR 119 may be the BFIR for a given packet and may also be (one of) the 120 BFER(s), for that packet; it may also forward that packet to one or 121 more additional BFRs. 123 A BIER domain may contain one or more sub-domains. Each BIER domain 124 MUST contain at least one sub-domain, the "default sub-domain" (also 125 denoted "sub-domain zero"). If a BIER domain contains more than one 126 sub-domain, each BFR in the domain MUST be provisioned to know the 127 set of sub-domains to which it belongs. Each sub-domain is 128 identified by a sub-domain-id in the range [0,255]. 130 For each sub-domain to which a given BFR belongs, if the BFR is 131 capable of acting as a BFIR or a BFER, it MUST be provisioned with a 132 "BFR-id" that is unique within the sub-domain. A BFR-id is a small 133 unstructured number. For instance, if a particular BIER sub-domain 134 contains 1,374 BFRs, each one could be given a BFR-id in the range 135 1-1374. 137 If a given BFR belongs to more than one sub-domain, it may (though it 138 need not) have a different BFR-id for each sub-domain. 140 When a multicast packet arrives from outside the domain at a BFIR, 141 the BFIR determines the set of BFERs to which the packet must be 142 sent. The BFIR also determines the sub-domain over which the packet 143 must be sent. (Procedures for assigning a particular packet to a 144 particular sub-domain are outside the scope of this document.) The 145 BFIR then encapsulates the packet in a "BIER header". The BIER 146 header contains a bit string in which each bit represents a single 147 BFR-id. To indicate that a particular BFER needs to receive a given 148 packet, the BFIR sets the bit corresponding to that BFER's BFR-id in 149 the sub-domain to which the packet has been assigned. We will use 150 term "BitString" to refer to the bit string field in the BIER header. 151 We will use the term "payload" to refer to the packet that has been 152 encapsulated. Thus a "BIER-encapsulated" packet consists of a "BIER 153 header" followed by a "payload". 155 The number of BFERs to which a given packet can be forwarded is 156 limited only by the length of the BitString in the BIER header. 157 Different deployments can use different BitString lengths. We will 158 use the term "BitStringLength" to refer to the number of bits in the 159 BitString. It is possible that some deployment will have more BFERs 160 in a given sub-domain than there are bits in the BitString. To 161 accommodate this case, the BIER encapsulation includes both the 162 BitString and a "Set Identifier" (SI). It is the BitString and the 163 SI together that determine the set of BFERs to which a given packet 164 will be delivered: 166 o by convention, the least significant (rightmost) bit in the 167 BitString is "bit 1", and the most significant (leftmost) bit is 168 "bit BitStringLength". 170 o if a BIER-encapsulated packet has an SI of n, and a BitString with 171 bit k set, then the packet must be delivered to the BFER whose 172 BFR-id (in the sub-domain to which the packet has been assigned) 173 is n*BitStringLength+k. 175 For example, suppose the BIER encapsulation uses a BitStringLength of 176 256 bits. By convention, the least significant (rightmost) bit is 177 "bit 1", and the most significant (leftmost) bit is "bit 256". 178 Suppose that a given packet has been assigned to sub-domain 0, and 179 needs to be delivered to three BFERs, where those BFERs have BFR-ids 180 in sub-domain 0 of 13, 126, and 235 respectively. The BFIR would 181 create a BIER encapsulation with the SI set to zero, and with bits 182 13, 126, and 235 of the BitString set. (All other bits of the 183 BitString would be clear.) If the packet also needs to be sent to a 184 BFER whose BFR-id is 257, the BFIR would have to create a second copy 185 of the packet, and the BIER encapsulation would specify an SI of 1, 186 and a BitString with bit 1 set and all the other bits clear. 188 Note that it is generally advantageous to assign the BFR-ids so that 189 as many BFERs as possible can be represented in a single bit string. 191 Suppose a BFR, call it BFR-A, receives a packet whose BIER 192 encapsulation specifies an SI of 0, and a BitString with bits 13, 26, 193 and 235 set. Suppose BFR-A has two BFR neighbors, BFR-B and BFR-C, 194 such that the best path to BFERs 13 and 26 is via BFR-B, but the best 195 path to BFER 235 is via BFR-C. Then BFR-A will replicate the packet, 196 sending one copy to BFR-B and one copy to BFR-C. However, BFR-A will 197 clear bit 235 in the BitString of the packet copy it sends to BFR-B, 198 and will clear bits 13 and 26 in the BitString of the packet copy it 199 sends to BFR-C. As a result, BFR-B will forward the packet only 200 towards BFERs 13 and 26, and BFR-C will forward the packet only 201 towards BFER 235. This ensures that each BFER receives only one copy 202 of the packet. 204 With this forwarding procedure, a multicast data packet can follow an 205 optimal path from its BFIR to each of its BFERs. Further, since the 206 set of BFERs for a given packet is explicitly encoded into the BIER 207 header, the packet is not sent to any BFER that does not need to 208 receive it. This allows for optimal forwarding of multicast traffic. 209 This optimal forwarding is achieved without any need for transit BFRs 210 to maintain per-flow state, or to run a multicast tree-building 211 protocol. 213 The idea of encoding the set of egress nodes into the header of a 214 multicast packet is not new. For example, [Boivie_Feldman] proposes 215 to encode the set of egress nodes as a set of IP addresses, and 216 proposes mechanisms and procedures that are in some ways similar to 217 those described in the current document. However, since BIER encodes 218 each BFR-id as a single bit in a bit string, it can represent up to 219 128 BFERs in the same number of bits that it would take to carry the 220 IPv6 address of a single BFER. Thus BIER scales to a much larger 221 number of egress nodes per packet. 223 BIER does not require that each transit BFR look up the best path to 224 each BFER that is identified in the BIER header; the number of 225 lookups required in the forwarding path for a single packet can be 226 limited to the number of neighboring BFRs; this can be much smaller 227 than the number of BFERs. See Section 6 (especially Section 6.4) for 228 details. 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in RFC 2119 [RFC2119]. 234 2. The BFR Identifier and BFR-Prefix 236 Each BFR MUST be assigned a "BFR-Prefix". A BFR's BFR-Prefix MUST be 237 an IP address (either IPv4 or IPv6) of the BFR, and MUST be unique 238 and routable within the BIER domain. It is RECOMMENDED that the 239 BFR-prefix be a loopback address of the BFR. Two BFRs in the same 240 BIER domain MUST NOT be assigned the same BFR-Prefix. Note that a 241 BFR in a given BIER domain has the same BFR-prefix in all the sub- 242 domains of that BIER domain. 244 A "BFR Identifier" (BFR-id) is a number in the range [1,65535]. In 245 general, each BFR in a given BIER sub-domain must be assigned a 246 unique number from this range (i.e., two BFRs in the same BIER sub- 247 domain MUST NOT have the same BFR-id in that sub-domain). However, 248 if it is known that a given BFR will never need to function as a BFER 249 in a given sub-domain, then it is not necessary to assign a BFR-id 250 for that sub-domain to that BFR. 252 The procedure for assigning a particular BFR-id to a particular BFR 253 is outside the scope of this document. However, it is RECOMMENDED 254 that the BFR-ids for each sub-domain be assigned "densely" from the 255 numbering space, as this will result in a more efficient encoding 256 (see Section 3). That is, if there are 256 or fewer BFERs, it is 257 RECOMMENDED to assign all the BFR-ids from the range [1,256]. If 258 there are more than 256 BFERs, but less than 512, it is RECOMMENDED 259 to assign all the BFR-ids from the range [1,512], with as few "holes" 260 as possible in the earlier range. However, in some deployments, it 261 may be advantageous to depart from this recommendation; this is 262 discussed further in Section 3. 264 3. Encoding BFR Identifiers in BitStrings 266 To encode a BFR-id in a BIER data packet, one must convert the BFR-id 267 to an SI and a BitString. This conversion depends upon the parameter 268 we are calling "BitStringLength". The conversion is done as follows. 269 If the BFR-id is N, then 271 o SI is the integer part of the quotient (N-1)/BitStringLength 273 o The BitString has one bit position set. If the low-order bit is 274 bit 1, and the high-order bit is bit BitStringLength, the bit 275 position that represents BFR-id N is 276 ((N-1) modulo BitStringLength)+1. 278 If several different BFR-ids all resolve to the same SI, then all 279 those BFR-ids can be represented in a single BitString. The 280 BitStrings for all of those BFR-ids are combined using a bitwise 281 logical OR operation. 283 Different BIER domains may use different values of BitStringLength. 284 Within a BIER domain, all BFRs MUST use the same BitStringLength 285 value; this value is known by provisioning. A BFR MUST support a 286 BitStringLength value of 256. Particular encapsulation types MAY 287 allow other BitStringLengths to be optionally supported. For 288 example, when using the encapsulation specified in 290 [MPLS_BIER_ENCAPS], a BFR may support any or all of the following 291 BitStringLengths: 64, 128, 256, 512, 1024, 2048, and 4096. 293 A BFR MUST support SI values in the range [0,15], and MAY support SI 294 values in the range [0,255]. ("Supporting the values in a given 295 range" means, in this context, that any value in the given range is 296 legal, and will be properly interpreted.) 298 It is possible to design procedures that allow BFRs within a given 299 BIER domain to use different BitStringLength values, and to enable 300 each BFR to discover the BitStringLength values used by all the other 301 BFRs in the domain. However, this document presupposes that they all 302 use the same value; procedures for the use of different values may be 303 specified in future documents. Note that the supported 304 BitStringLength values are a property of the BIER domain, not a 305 property of the individual sub-domains. 307 When a BFIR determines that a multicast data packet, assigned to a 308 given sub-domain, needs to be forwarded to a particular set of 309 destination BFERs, the BFIR partitions that set of BFERs into 310 subsets, where each subset contains the target BFERs whose BFR-ids in 311 the given sub-domain all resolve to the same SI. Call these the 312 "SI-subsets" for the packet. Each SI-subset can be represented by a 313 single BitString. The BFIR creates a copy of the packet for each 314 SI-subset. The BIER encapsulation is then applied to each packet. 315 The encapsulation specifies a single SI for each packet, and contains 316 the BitString that represents all the BFR-ids in the corresponding 317 SI-subset. Of course, in order to properly interpret the BitString, 318 it must be possible to infer the sub-domain-id from the encapsulation 319 as well. 321 Suppose, for example, that a BFIR determines that a given packet 322 needs to be forwarded to three BFERs, whose BFR-ids (in the 323 appropriate sub-domain) are 27, 235, and 497. The BFIR will have to 324 forward two copies of the packet. One copy, associated with SI=0, 325 will have a BitString with bits 27 and 235 set. The other copy, 326 associated with SI=1, will have a BitString with bit 241 set. 328 In order to minimize the number of copies that must be made of a 329 given multicast packet, it is RECOMMENDED that the BFR-ids be 330 assigned "densely" (see Section 2) from the numbering space. This 331 will minimize the number of SIs that have to be used in the domain. 332 However, depending upon the details of a particular deployment, other 333 assignment methods may be more advantageous. Suppose, for example, 334 that in a certain deployment, every multicast flow is either intended 335 for the "east coast" or for the "west coast". In such a deployment, 336 it would be advantageous to assign BFR-ids so that all the "west 337 coast" BFR-ids fall into the same SI-subset, and so that all the 338 "east coast" BFR-ids fall into the same SI-subset. 340 When a BFR receives a BIER data packet, it will infer the SI from the 341 encapsulation. Then the set of BFERs to which the packet needs to be 342 forwarded can then be inferred from the SI and the BitString. 344 In some of the examples given later in this document, we will use a 345 BitStringLength of 4, and will represent a BFR-id in the form 346 "SI:xyzw", where SI is the Set Identifier of the BFR-id (assuming a 347 BitStringLength of 4), and xyzw is a string of 4 bits. A 348 BitStringLength of 4 is used only in the examples; we would not 349 expect actual deployments to have such a small BitStringLength. 351 It is expected that there will be several different forms of BIER 352 encapsulation. The particular encapsulation that is used in a given 353 deployment will depend on the type of network infrastructure that is 354 used to realize the BIER domain. Details of the BIER encapsulation 355 will be given in companion documents. An encapsulation for use in 356 MPLS networks is described in [MPLS_BIER_ENCAPS] 358 4. Layering 360 It is helpful to think of the BIER architecture as consisting of 361 three layers: the "routing underlay", the "BIER layer", and the 362 "multicast flow overlay". 364 4.1. The Routing Underlay 366 The "routing underlay" establishes "adjacencies" between pairs of 367 BFRs, and determines one or more "best paths" from a given BFR to a 368 given set of BFRs. Each such path is a sequence of BFRs such that BFR(k+j) is "adjacent" to 370 BFR(k+j+1) (for 0<=j and BitStringLength can be done using the 479 advertisement capabilities of the IGP. For example, if a BIER domain 480 is also an OSPF domain, these advertisements can be done using the 481 OSPF "Opaque Link State Advertisement" (Opaque LSA) mechanism. 482 Details of the necessary extensions to OSPF and IS-IS will be 483 provided in companion documents. (See [OSPF_BIER_EXTENSIONS] and 484 [ISIS_BIER_EXTENSIONS].) 486 These advertisements enable each BFR to associate a given with a given BFR-prefix. As will be seen in 488 subsequent sections of this document, knowledge of this association 489 is an important part of the forwarding process. 491 Since each BFR needs to have a unique (in each sub-domain) BFR-id, 492 two different BFRs will not advertise ownership of the same unless there has been a provisioning error. 495 o If BFR-A determines that BFR-B and BFR-C have both advertised the 496 same BFR-id for the same sub-domain, BFR-A MUST log an error. 497 Suppose that the duplicate BFR-id is "N". When BFR-A is 498 functioning as a BFIR, it MUST NOT encode the BFR-id value N in 499 the BIER encapsulation of any packet that has been assigned to the 500 given sub-domain, even if it has determined that the packet needs 501 to be received by BFR-B and/or BFR-C. 503 This will mean that BFR-B and BFR-C cannot receive multicast 504 traffic at all in the given sub-domain until the provisioning 505 error is fixed. However, that is preferable to having them 506 receive each other's traffic. 508 o If BFR-A has been provisioned with BFR-id N for a particular sub- 509 domain, has not yet advertised its ownership of BFR-id N for that 510 sub-domain, but has received an advertisement from a different BFR 511 (say BFR-B) that is advertising ownership of BFR-id N for the same 512 sub-domain, then BFR-A SHOULD log an error, and MUST NOT advertise 513 its own ownership of BFR-id N for that sub-domain as long as the 514 advertisement from BFR-B is extant. 516 This procedure may prevent the accidental misconfiguration of a 517 new BFR from impacting an existing BFR. 519 6. BIER Intra-Domain Forwarding Procedures 521 This section specifies the rules for forwarding a BIER-encapsulated 522 data packet within a BIER domain. 524 6.1. Overview 526 This section provides a brief overview of the BIER forwarding 527 procedures. Subsequent sub-sections specify the procedures in more 528 detail. 530 To forward a BIER-encapsulated packet: 532 1. Determine the packet's sub-domain. 534 2. Determine the packet's SI. 536 3. From the sub-domain, the SI and the BitString, determine the set 537 of destination BFERs for the packet. 539 4. Using information provided by the routing underlay associated 540 with the packet's sub-domain, determine the next hop adjacency 541 for each of the destination BFERs. 543 5. Partition the set of destination BFERs such that all the BFERs in 544 a single partition have the same next hop. We will say that each 545 partition is associated with a next hop. 547 6. For each partition: 549 a. Make a copy of the packet. 551 b. Clear any bit in the packet's BitString that identifies a 552 BFER that is not in the partition. 554 c. Transmit the packet to the associated next hop. 556 If a BFR receives a BIER-encapsulated packet whose sub-domain, SI and 557 BitString identify that BFR itself, then the BFR is also a BFER for 558 that packet. As a BFER, it must pass the payload to the multicast 559 flow overlay. If the BitString has more than one bit set, the packet 560 also needs to be forwarded further within the BIER domain. If the 561 BF(E)R also forwards one or more copies of the packet within the BIER 562 domain, the bit representing the BFR's own BFR-id will be cleared in 563 all the copies. 565 When BIER on a BFER passes a packet to the multicast flow overlay, it 566 may need to provide contextual information obtained from the BIER 567 encapsulation. The information that needs to pass between the BIER 568 layer and the multicast flow layer is specific to the multicast flow 569 layer. Specification of the interaction between the BIER layer and 570 the multicast flow layer is outside the scope of this specification. 572 When BIER on a BFER passes a packet to the multicast flow overlay, 573 the overlay will determine how to further dispatch the packet. If 574 the packet needs to be forwarded into another BIER domain, then the 575 BFR will act as a BFER in one BIER domain and as a BFIR in another. 576 A BIER-encapsulated packet cannot pass directly from one BIER domain 577 to another; at the boundary between BIER domains, the packet must be 578 decapsulated and passed to the multicast flow layer. 580 Note that when a BFR transmits multiple copies of a packet within a 581 BIER domain, only one copy will be destined to any given BFER. 582 Therefore it is not possible for any BIER-encapsulated packet to be 583 delivered more than once to any BFER. 585 6.2. BFR Neighbors 587 The "BFR Neighbors" (BFR-NBRs) of a given BFR, say BFR-A, are those 588 BFRs that, according to the routing underlay, are adjacencies of 589 BFR-A. Each BFR-NBR will have a BFR-prefix. 591 Suppose a BIER-encapsulated packet arrives at BFR-A. From the 592 packet's encapsulation, BFR-A learns the sub-domain of the packet, 593 and the BFR-ids (in that sub-domain) of the BFERs to which the packet 594 is destined. Then using the information advertised per Section 5, 595 BFR-A can find the BFR-prefix of each destination BFER. Given the 596 BFR-prefix of a particular destination BFER, say BFER-D, BFR-A learns 597 from the routing underlay (associated with the packet's sub-domain) 598 an IP address of the BFR that is the next hop on the path from BFR-A 599 to BFER-D. Let's call this next hop BFR-NH. BFR-A must then 600 determine the BFR-prefix of BFR-NH. (This determination can be made 601 from the information advertised per Section 5.) This BFR-prefix is 602 the BFR-NBR of BFR-A on the path from BFR-A to BFER-D. 604 Note that if the routing underlay provides multiple equal cost paths 605 from BFR-A to BFER-D, BFR-A may have multiple BFR-NBRs for BFER-D. 607 6.3. The Bit Index Routing Table 609 The Bit Index Routing Table (BIRT) is a table that maps from the 610 BFR-id (in a particular sub-domain) of a BFER to the BFR-prefix of 611 that BFER, and to the BFR-NBR on the path to that BFER. 613 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 614 4 (0:1000) \ \ 1 (0:0001) 615 \ \ 616 ( E ) ( F ) 617 3 (0:0100) 2 (0:0010) 619 Figure 1: BIER Topology 1 621 As an example, consider the topology shown in Figure 1. In this 622 diagram, we represent the BFR-id of each BFR in the SI:xyzw form 623 discussed in Section 3. This topology will result in the BIRT of 624 Figure 2 at BFR-B. The first column shows the BFR-id as a number and 625 also (in parentheses) in the SI:BitString format that corresponds to 626 a BitStringLength of 4. (The actual minimum BitStringLength is 64, 627 but we use 4 in the examples.) 629 Note that a BIRT is specific to a particular BIER sub-domain. 631 -------------------------------------------- 632 | BFR-id | BFR-Prefix | BFR-NBR | 633 | (SI:BitString) | of Dest BFER | | 634 ============================================ 635 | 4 (0:1000) | A | A | 636 -------------------------------------------- 637 | 1 (0:0001) | D | C | 638 -------------------------------------------- 639 | 3 (0:0100) | E | E | 640 -------------------------------------------- 641 | 2 (0:0010) | F | C | 642 -------------------------------------------- 644 Figure 2: Bit Index Routing Table at BFR-B 646 6.4. The Bit Index Forwarding Table 648 The "Bit Index Forwarding Table" (BIFT) is derived from the BIRT as 649 follows. (Note that a BIFT is specific to a particular sub-domain.) 651 Suppose that several rows in the BIRT have the same SI and the same 652 BFR-NBR. By taking the logical OR of the BitStrings of those rows, 653 we obtain a bit mask that corresponds to that combination of SI and 654 BFR-NBR. We will refer to this bit mask as the "Forwarding Bit Mask" 655 (F-BM) for that combination. 657 For example, in Figure 2, we see that two of the rows have the same 658 SI (0) and same BFR-NBR (C). The Bit Mask that corresponds to is 0011 ("0001" OR'd with "0010"). 661 The BIFT is used to map from the BFR-id of a BFER to the 662 corresponding F-BM and BFR-NBR. For example, Figure 3 shows the BIFT 663 that is derived from the BIRT of Figure 2. Note that BFR-ids 1 and 2 664 have the same SI and the same BFR-NBR, hence they have the same F-BM. 666 ------------------------------------- 667 | BFR-id | F-BM | BFR-NBR | 668 | (SI:Bitstring) | | | 669 ===================================== 670 | 1 (0:0001) | 0011 | C | 671 ------------------------------------- 672 | 2 (0:0010) | 0011 | C | 673 ------------------------------------- 674 | 3 (0:0100) | 0100 | E | 675 ------------------------------------- 676 | 4 (0:1000) | 1000 | A | 677 ------------------------------------- 679 Figure 3: Bit Index Forwarding Table 681 This Bit Index Forwarding Table (BIFT) is programmed into the data- 682 plane and used to forward packets, applying the rules specified below 683 in Section 6.5. 685 6.5. The BIER Forwarding Procedure 687 Below is the procedure for forwarding a BIER-encapsulated packet. 689 1. Determine the packet's SI. 691 2. Find the position of least significant (rightmost) bit in the 692 packet's BitString that is set. (Remember, bits are numbered 693 from 1, starting with the least significant bit.) Use that bit 694 position, together with the SI, as the 'index' into the BIFT. 696 3. Extract from the BIFT the F-BM and the BFR-NBR. 698 4. Copy the packet. Update the copy's BitString by AND'ing it with 699 the F-BM (i.e., PacketCopy->BitString &= F-BM). Then forward the 700 copy to the BFR-NBR. Note that when a packet is forwarded to a 701 particular BFR-NBR, its BitString identifies only those BFERs 702 that are to be reached via that BFR-NBR. 704 5. Now update the original packet's BitString by AND'ing it with the 705 INVERSE of the F-BM (i.e., Packet->Bitstring &= ~F-BM). (This 706 clears the bits that identify the BFERs to which a copy of the 707 packet has just been forwarded.) Go to step 2. 709 Note that this procedure causes the packet to be forwarded to a 710 particular BFR-NBR only once. The number of lookups in the BIFT is 711 the same as the number of BFR-NBRs to which the packet must be 712 forwarded; it is not necessary to do a separate lookup for each 713 destination BFER. 715 Suppose it has been decided (by the above rules) to send a packet to 716 a particular BFR-NBR. If that BFR-NBR is connected via multiple 717 parallel interfaces, it may be desirable to apply some form of load 718 balancing. Load balancing algorithms are outside the scope of this 719 document. However, if the packet's encapsulation contains an 720 "entropy" field, the entropy field SHOULD be respected; two packets 721 with the same value of the entropy field SHOULD be sent on the same 722 interface (if possible). 724 In some cases, the routing underlay may provide multiple equal cost 725 paths (through different BFR-NBRs) to a given BFER. This is known as 726 "Equal Cost Multiple Paths" (ECMP). The procedures described in this 727 section must be augmented in order to support load balancing over 728 ECMP. The necessary augmentations can be found in Section 6.7. 730 In the event that unicast traffic to the BFR-NBR is being sent via a 731 "bypass tunnel" of some sort, the BIER-encapsulated multicast traffic 732 send to the BFR-NBR SHOULD also be sent via that tunnel. This allows 733 any existing "Fast Reroute" schemes to be applied to multicast 734 traffic as well as to unicast traffic. 736 Some examples of these forwarding procedures can be found in 737 Section 6.6. 739 The rules given in this section can be represented by the following 740 pseudocode: 742 void ForwardBitMaskPacket (Packet) 743 { 744 SI=GetPacketSI(Packet); 745 Offset=SI*BitStringLength; 746 for (Index = GetFirstBitPosition(Packet->BitString); Index ; 747 Index = GetNextBitPosition(Packet->BitString, Index)) { 748 F-BM = BIFT[Index+Offset]->F-BM; 749 if (!F-BM) continue; 750 BFR-NBR = BIFT[Index+Offset]->BFR-NBR; 751 PacketCopy = Copy(Packet); 752 PacketCopy->BitString &= F-BM; 753 PacketSend(PacketCopy, BFR-NBR); 754 Packet->BitString &= ~F-BM; 755 } 756 } 758 Figure 4: Pseudocode 760 Note that at a given BFER, the BFR-NBR entry corresponding to the 761 BFER's own BFR-id will be the BFER's own BFR-prefix. In this case, 762 the "PacketSend" function sends the packet to the multicast flow 763 layer. 765 6.6. Examples of BIER Forwarding 767 In this section, we give two examples of BIER forwarding, based on 768 the topology in Figure 1. In these examples, all packets have been 769 assigned to the default sub-domain, all packets have SI=0, and the 770 BitStringLength is 4. Figure 5 shows the BIFT entries for SI=0 only. 771 For compactness, we show the first column of the BIFT, the BFR-id, 772 only as an integer. 774 BFR-A BIFT BFR-B BIFT BFR-C BIFT 775 ------------------- ------------------- ------------------- 776 | Id | F-BM | NBR | | Id | F-BM | NBR | | Id | F-BM | NBR | 777 =================== =================== =================== 778 | 1 | 0111 | B | | 1 | 0011 | C | | 1 | 0001 | D | 779 ------------------- ------------------- ------------------- 780 | 2 | 0111 | B | | 2 | 0011 | C | | 2 | 0010 | F | 781 ------------------- ------------------- ------------------- 782 | 3 | 0111 | B | | 3 | 0100 | E | | 3 | 1100 | B | 783 ------------------- ------------------- ------------------- 784 | 4 | 1000 | A | | 4 | 1000 | A | | 4 | 1100 | B | 785 ------------------- ------------------- ------------------- 787 Figure 5: BIFTs for Forwarding Examples 789 6.6.1. Example 1 791 BFR-D, BFR-E and BFR-F are BFER's. BFR-A is the BFIR. Suppose that 792 BFIR-A has learned from the multicast flow layer that BFER-D is 793 interested in a given multicast flow. If BFIR-A receives a packet of 794 that flow from outside the BIER domain, BFIR-A applies the BIER 795 encapsulation to the packet. The encapsulation must be such that the 796 SI is zero. The encapsulation also includes a BitString, with just 797 bit 1 set and with all other bits clear (i.e., 0001). This indicates 798 that BFER-D is the only BFER that needs to receive the packet. Then 799 BFIR-A follows the procedures of Section 6.5: 801 o Since the packet's BitString is 0001, BFIR-A finds that the first 802 bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-A 803 determines that the bit mask F-BM is 0111 and the BFR-NBR is 804 BFR-B. 806 o BFR-A then makes a copy of the packet, and applies F-BM to the 807 copy: Copy->BitString &= 0111. The copy's Bitstring is now 0001 808 (0001 & 0111). 810 o The copy is now sent to BFR-B. 812 o BFR-A then updates the packet's BitString by applying the inverse 813 of the F-BM: Packet->Bitstring &= ~F-BM. As a result, the 814 packet's BitString is now 0000 (0001 & 1000). 816 o As the packet's BitString is now zero, the forwarding procedure is 817 complete. 819 When BFR-B receives the multicast packet from BFR-A, it follows the 820 same procedure. The result is that a copy of the packet, with a 821 BitString of 0001, is sent to BFR-C. BFR-C applies the same 822 procedures, and as a result sends a copy of the packet, with a 823 BitString of 0001, to BFR-D. 825 At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an 826 F-BM of 0000 and a BFR-NBR of BFR-D itself. This will cause a copy 827 of the packet to be delivered to the multicast flow layer at BFR-D. 828 The packet's BitString will be set to 0000, and the packet will not 829 be forwarded any further. 831 6.6.2. Example 2 833 This example is similar to Example 1, except that BFIR-A has learned 834 from the multicast flow layer that both BFER-D and BFER-E are 835 interested in a given multicast flow. If BFIR-A receives a packet of 836 that flow from outside the BIER domain, BFIR-A applies the BIER 837 encapsulation to the packet. The encapsulation must be such that the 838 SI is zero. The encapsulation also includes a BitString with two 839 bits set: bit 1 is set (as in example 1) to indicate that BFR-D is a 840 BFER for this packet, and bit 3 is set to indicate that BFR-E is a 841 BFER for this packet. I.e., the BitString (assuming again a 842 BitStringLength of 4) is 0101. To forward the packet, BFIR-A follows 843 the procedures of Section 6.5: 845 o Since the packet's BitString is 0101, BFIR-A finds that the first 846 bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-A 847 determines that the bit mask F-BM is 0111 and the BFR-NBR is 848 BFR-B. 850 o BFR-A then makes a copy of the packet, and applies the F-BM to the 851 copy: Copy->BitString &= 0111. The copy's Bitstring is now 0101 852 (0101 & 0111). 854 o The copy is now sent to BFR-B. 856 o BFR-A then updates the packet's BitString by applying the inverse 857 of the F-BM: Packet->Bitstring &= ~F-BM. As a result, the 858 packet's BitString is now 0000 (0101 & 1000). 860 o As the packet's BitString is now zero, the forwarding procedure is 861 complete. 863 When BFR-B receives the multicast packet from BFR-A, it follows the 864 procedure of Section 6.5, as follows: 866 o Since the packet's BitString is 0101, BFR-B finds that the first 867 bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-B 868 determines that the bit mask F-BM is 0011 and the BFR-NBR is 869 BFR-C. 871 o BFR-B then makes a copy of the packet, and applies the F-BM to the 872 copy: Copy->BitString &= 0011. The copy's Bitstring is now 0001 873 (0101 & 0011). 875 o The copy is now sent to BFR-C. 877 o BFR-B then updates the packet's BitString by applying the inverse 878 of the F-BM: Packet->Bitstring &= F-BM. As a result, the 879 packet's BitString is now 0100 (0101 & 1100). 881 o Now BFR-B finds the next bit in the packet's (modified) BitString. 882 This is bit 3. Looking at entry 3 in its BIFT, BFR-B determines 883 that the F-BM is 0100 and the BFR-NBR is BFR-E. 885 o BFR-B then makes a copy of the packet, and applies the F-BM to the 886 copy: Copy->BitString &= 0100. The copy's Bitstring is now 0100 887 (0100 & 0100). 889 o The copy is now sent to BFR-E. 891 o BFR-B then updates the packet's BitString by applying the inverse 892 of the F-BM: Packet->Bitstring &= ~F-BM. As a result, the 893 packet's BitString is now 0000 (0100 & 1011). 895 o As the packet's BitString is now zero, the forwarding procedure is 896 complete. 898 Thus BFR-B forwards two copies of the packet. One copy of the 899 packet, with BitString 0001, has now been sent from BFR-B to BFR-C. 900 Following the same procedures, BFR-C will forward the packet to 901 BFER-D. 903 At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an 904 F-BM of 0000 and a BFR-NBR of BFR-D itself. This will cause a copy 905 of the packet to be delivered to the multicast flow layer at BFR-D. 906 The packet's BitString will be set to 0000, and the packet will not 907 be forwarded any further. 909 The other copy of the packet has been sent from BFR-B to BFER-E, with 910 BitString 0100. 912 At BFER-E, the BIFT entry (not pictured) for BFR-id 3 will specify an 913 F-BM of 0000 and a BFR-NBR of BFR-E itself. This will cause a copy 914 of the packet to be delivered to the multicast flow layer at BFR-E. 915 The packet's BitString will be set to 0000, and the packet will not 916 be forwarded any further. 918 6.7. Equal Cost Multi-path Forwarding 920 In many networks, the routing underlay will provide multiple equal 921 cost paths from a given BFR to a given BFER. When forwarding 922 multicast packets through the network, it can be beneficial to take 923 advantage of this by load balancing among those paths. This feature 924 is known as "equal cost multiple path forwarding", or "ECMP". 926 BIER supports ECMP, but the procedures of Section 6.5 must be 927 modified slightly. Two ECMP procedures are defined. In the first 928 (described in Section 6.7.1), the choice among equal-cost paths taken 929 by a given packet from a given BFR to a given BFER depends on (a) the 930 packet's entropy, and (b) the other BFERs to which that packet is 931 destined. In the second (described in Section 6.7.2), the choice 932 depends only upon the packet's entropy. 934 There are tradeoffs between the two forwarding procedures described 935 here. In the procedure of Section 6.7.1, the number of packet 936 replications is minimized. The procedure in Section 6.7.1 also uses 937 less memory in the BFR. In the procedure of Section 6.7.2, the path 938 traveled by a given packet from a given BFR to a given BFER is 939 independent of the other BFERs to which the packet is destined. 940 While the procedures of Section 6.7.2 may cause more replications, 941 they provide a more predictable behavior. 943 The two procedures described here operate on identical packet formats 944 and will interoperate correctly. However, if deterministic behavior 945 is desired, then all BFRs would need to use the procedure from 946 Section 6.7.2. 948 6.7.1. Non-deterministic ECMP 950 Figure 6 shows the operation of non-deterministic ECMP in BIER. 952 BFR-A BIFT BFR-B BIFT BFR-C BIFT 953 ------------------- ------------------- ------------------- 954 | Id | F-BM | NBR | | Id | F-BM | NBR | | Id | F-BM | NBR | 955 =================== =================== =================== 956 | 1 | 0111 | B | | 1 | 0011 | C | | 1 | 0001 | D | 957 ------------------- ------------------- ------------------- 958 | 2 | 0111 | B | | 2 | 0011 | C | | 2 | 0010 | F | 959 ------------------- | | 0110 | E | ------------------- 960 | 3 | 0111 | B | ------------------- | 3 | 1100 | B | 961 ------------------- | 3 | 0110 | E | ------------------- 962 | 4 | 1000 | A | ------------------| | 4 | 1100 | B | 963 ------------------- | 4 | 1000 | A | ------------------- 964 ------------------- 966 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 967 4 (0:1000) \ \ 1 (0:0001) 968 \ \ 969 ( E ) ------------ ( F ) 970 3 (0:0100) 2 (0:0010) 972 Figure 6: Example of ECMP 974 In this example, BFR-B has two equal cost paths to reach BFER-F, one 975 via BFR-C and one via BFR-E. Since the BFR-id of BFER-F is 2, this 976 is reflected in entry 2 of BFR-B's BIFT. Entry 2 shows that BFR-B 977 has a choice of two BFR-NBRs for BFER-B, and that a different F-BM is 978 associated with each choice. When BFR-B looks up entry 2 in the 979 BIFT, it can choose either BFR-NBR. However, when following the 980 procedures of Section 6.5, it MUST use the F-BM corresponding to the 981 BFR-NBR that it chooses. 983 How the choice is made is an implementation matter. However, the 984 usual rules for ECMP apply: packets of a given flow SHOULD NOT be 985 split among two paths, and any "entropy" field in the packet's 986 encapsulation SHOULD be respected. 988 Note however that by the rules of Section 6.5, any packet destined 989 for both BFER-D and BFER-F will be sent via BFR-C. 991 6.7.2. Deterministic ECMP 993 With the procedures of Section 6.7.1, where ECMP paths exist, the 994 path a packet takes to reach any particular BFER depends not only on 995 routing and on the packet's entropy, but also on the set of other 996 BFERs to which the packet is destined. 998 For example consider the network in Figure 6. Suppose that there is 999 a sequence of packets being transmitted by BFR A, some of which are 1000 destined for D and F, and some of which are destined for E and F. 1001 And suppose that all the packets in this sequence have the same 1002 entropy value. Using the forwarding procedures of Section 6.7.1, the 1003 packets destined for both D and F would follow the path A-B-C-F, 1004 while the packets destined for both E and F would follow the path 1005 A-B-E-F. 1007 That procedure minimizes the number of packets transmitted by BFR B. 1008 However, consider a particular multicast flow that initially needs to 1009 be received ONLY by BFER-F. Let's suppose that the packets of that 1010 flow have an entropy value that causes B to forward them along the 1011 path B-C-F. Now suppose that E needs to start receiving the flow. 1012 By the procedures of Section 6.7.1, B will now switch the packets to 1013 the path B-E-F. When E no longer needs to receive the flow, B will 1014 switch the packets back to the path B-C-F. 1016 The problem is that if E repeatedly joins and leaves the flow, the 1017 flow's path from B to F will keep switching. This could cause F to 1018 receive packets out of order. It also makes troubleshooting 1019 difficult. For example, if there is some problem on the C-F link, 1020 receivers at F will get good service when the flow is also going to E 1021 (avoiding the C-F link), but bad service when the flow is not going 1022 to E. Since it is hard to know which path is being used at any given 1023 time, this may be hard to troubleshoot. Also, it is very difficult 1024 to perform a traceroute that is known to follow the path taken by the 1025 flow at any given time. 1027 The source of this difficulty is that, in the procedures of 1028 Section 6.7.1, the path taken by a particular flow to a particular 1029 BFER depends upon whether there are "lower numbered" BFERs that are 1030 also receiving the flow. Thus the choice among the ECMP paths is 1031 fundamentally non-deterministic. 1033 Deterministic forwarding can be achieved by using multiple BIFTs, 1034 such that each row in a BIFT has only one path to each destination, 1035 but the multiple ECMP paths to any particular destination are spread 1036 across the multiple tables. When a BIER-encapsulated packet arrives 1037 to be forwarded, the BFR uses a hash of the BIER Entropy field to 1038 determine which BIFT to use, and then the normal BIER forwarding 1039 algorithm (as described in Sections 6.5 and 6.6) is used with the 1040 selected BIFT. 1042 ECMP is achieved by having a particular path may appear in multiple 1043 tables. For example, suppose there are two paths to destination X 1044 (call them X1 and X2), and four paths to destination Y (call them Y1, 1045 Y2, Y3, and Y4). If there are, say, four BIFTs, one BIFT would have 1046 paths X1 and Y1, one would have X1 and Y2, one would have X2 and Y3, 1047 and one would have X2 and Y4. Note that if there are three paths to 1048 one destination and four paths to another, 12 BIFTs would be required 1049 in order to get even splitting of the load. 1051 6.8. Prevention of Loops and Duplicates 1053 The BitString in a BIER-encapsulated packet specifies the set of 1054 BFERs to which that packet is to be forwarded. When a BIER- 1055 encapsulated packet is replicated, no two copies of the packet will 1056 ever have a BFER in common. If one of the packet's BFERs forwards 1057 the packet further, that will first clear the bit that identifies 1058 itself. As a result, duplicate delivery of packets is not possible 1059 with BIER. 1061 As long as the routing underlay provides a loop free path between 1062 each pair of BFRs, BIER-encapsulated packets will not loop. Since 1063 the BIER layer does not create any paths of its own, there is no need 1064 for any BIER-specific loop prevention techniques beyond the 1065 forwarding procedures specified in Section 6.5. 1067 If, at some time, the routing underlay is not providing a loop free 1068 path between BFIR-A and BFER-B, then BIER encapsulated packets may 1069 loop while traveling from BFIR-A to BFER-B. However, such loops will 1070 never result in delivery of duplicate packets to BFER-B. 1072 These properties of BIER eliminate the need for the "reverse path 1073 forwarding" (RPF) check that is used in conventional IP multicast 1074 forwarding. 1076 7. IANA Considerations 1078 This document contains no actions for IANA. 1080 8. Security Considerations 1082 When BIER is paired with a particular multicast flow layer, it 1083 inherits the security considerations of that layer. Similarly, when 1084 BIER is paired with a particular routing underlay, it inherits the 1085 security considerations of that layer. 1087 If the BIER encapsulation of a particular packet specifies an SI or a 1088 BitString other than the one intended by the BFIR, the packet is 1089 likely to be misdelivered. If the BIER encapsulation of a packet is 1090 modified (through error or malfeasance) in a way other than that 1091 specified in this document, the packet may be misdelivered. 1093 If the procedures used for advertising BFR-ids and BFR-prefixes are 1094 not secure, an attack on those procedures may result in incorrect 1095 delivery of BIER-encapsulated packets. 1097 Every BFR must be provisioned to know which of its interfaces lead to 1098 a BIER domain and which do not. If two interfaces lead to different 1099 BIER domains, the BFR must be provisioned to know that those two 1100 interfaces lead to different BIER domains. If the provisioning is 1101 not correct, BIER-encapsulated packets from one BIER domain may 1102 "leak" into another; this is likely to result in misdelivery of 1103 packets. 1105 9. Acknowledgements 1107 The authors wish to thank Rajiv Asati, John Bettink, Ross Callon (who 1108 contributed much of the text on deterministic ECMP), Nagendra Kumar, 1109 Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, 1110 and Jeffrey Zhang for their ideas and contributions to this work. 1112 10. Contributor Addresses 1114 Below is a list of other contributing authors in alphabetical order: 1116 Gregory Cauchie 1117 Bouygues Telecom 1119 Email: gcauchie@bouyguestelecom.fr 1121 Mach (Guoyi) Chen 1122 Huawei 1123 Email: mach.chen@huawei.com 1125 Arkadiy Gulko 1126 Thomson Reuters 1127 195 Broadway 1128 New York NY 10007 1129 US 1131 Email: arkadiy.gulko@thomsonreuters.com 1133 Wim Henderickx 1134 Alcatel-Lucent 1135 Copernicuslaan 50 1136 Antwerp 2018 1137 BE 1139 Email: wim.henderickx@alcatel-lucent.com 1141 Martin Horneffer 1142 Deutsche Telekom 1143 Hammer Str. 216-226 1144 Muenster 48153 1145 DE 1147 Email: Martin.Horneffer@telekom.de 1149 Uwe Joorde 1150 Deutsche Telekom 1151 Hammer Str. 216-226 1152 Muenster D-48153 1153 DE 1155 Email: Uwe.Joorde@telekom.de 1157 Jeff Tantsura 1158 Ericsson 1159 300 Holger Way 1160 San Jose, CA 95134 1161 US 1163 Email: jeff.tantsura@ericsson.com 1165 11. References 1167 11.1. Normative References 1169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1170 Requirement Levels", BCP 14, RFC 2119, March 1997. 1172 11.2. Informative References 1174 [Boivie_Feldman] 1175 Boivie, R. and N. Feldman, "Small Group Multicast", 1176 (expired) draft-boivie-sgm-02.txt, February 2001. 1178 [ISIS_BIER_EXTENSIONS] 1179 Przygienda, T., Ginsberg, L., Aldrin, S., and J. Zhang, 1180 "OSPF Extensions for Bit Index Explicit Replication", 1181 internet-draft draft-przygienda-bier-isis-ranges-01.txt, 1182 October 2014. 1184 [MPLS_BIER_ENCAPS] 1185 Wijnands, IJ., "BIER Encapsulation for MPLS Networks", 1186 internet-draft draft-wijnands-mpls-bier-encaps-02.txt, 1187 December 2014. 1189 [OSPF_BIER_EXTENSIONS] 1190 Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 1191 Przygienda, T., and J. Zhang, "OSPF Extensions for Bit 1192 Index Explicit Replication", internet-draft draft-psenak- 1193 ospf-bier-extensions-01.txt, October 2014. 1195 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 1196 VPNs", RFC 6513, February 2012. 1198 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1199 Encodings and Procedures for Multicast in MPLS/BGP IP 1200 VPNs", RFC 6514, February 2012. 1202 Authors' Addresses 1204 IJsbrand Wijnands (editor) 1205 Cisco Systems, Inc. 1206 De Kleetlaan 6a 1207 Diegem 1831 1208 BE 1210 Email: ice@cisco.com 1211 Eric C. Rosen (editor) 1212 Juniper Networks, Inc. 1213 10 Technology Park Drive 1214 Westford, Massachusetts 01886 1215 US 1217 Email: erosen@juniper.net 1219 Andrew Dolganow 1220 Alcatel-Lucent 1221 600 March Rd. 1222 Ottawa, Ontario K2K 2E6 1223 CA 1225 Email: andrew.dolganow@alcatel-lucent.com 1227 Tony Przygienda 1228 Ericsson 1229 300 Holger Way 1230 San Jose, California 95134 1231 US 1233 Email: antoni.przygienda@ericsson.com 1235 Sam K Aldrin 1236 Huawei Technologies 1237 2330 Central Express Way 1238 Santa Clara, California 1239 US 1241 Email: aldrin.ietf@gmail.com