idnits 2.17.1 draft-hj-bier-mldp-signaling-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2124 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) -- Missing reference section? 'RFC2119' on line 115 looks like a reference Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Workgroup H. Bidgoli, Ed. 3 Internet Draft A. Dolganow 4 Intended status: Standard Track J. Kotalwar 5 Nokia 7 Expires: January 3, 2019 July 2, 2018 9 M-LDP Signaling Through BIER Core 10 draft-hj-bier-mldp-signaling-00 12 Abstract 14 Bit Index Explicit Replication (BIER) is an architecture that 15 provides multicast forwarding through a "BIER domain" without 16 requiring intermediate routers to maintain multicast related per-flow 17 state. Neither does BIER require an explicit tree-building protocol 18 for its operation. A multicast data packet enters a BIER domain at a 19 "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at 20 one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router 21 adds a BIER header to the packet. Such header contains a bit-string 22 in which each bit represents exactly one BFER to forward the packet 23 to. The set of BFERs to which the multicast packet needs to be 24 forwarded is expressed by the according set of bits switched on in 25 BIER packet header. 27 This document describes the procedure needed for mLDP tunnels to be 28 signaled and stitched through a BIER core. Allowing LDP routers to 29 run traditional Multipoint LDP services through a BIER core. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." The list 45 of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on October 8, 2017. 52 Copyright Notice 54 Copyright (c) 2018 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Conventions used in this document . . . . . . . . . . . . . . . 3 71 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. M-LDP Signaling Through BIER domain . . . . . . . . . . . . . . 5 73 3.1. Ingress BBR procedure . . . . . . . . . . . . . . . . . . . 5 74 3.2. Assigning the BIER sub-domain Tree Label . . . . . . . . . 6 75 3.2.1. Method 1: IBBR as extraction point to SDN controller . 6 76 3.2.2. Method 2, EBBR assigning the BTL . . . . . . . . . . . 7 77 3.2.2.1. BIER packet construction at IBBR for Method 2 . . . 7 78 3.2.2.2. Signaling mLDP through the BIER domain procedure . 8 79 3.3. SDN Controller procedure for updating BBRs with BTL . . . . 8 80 3.4. BGP procedure for signaling BTL for method 2 . . . . . . . 9 81 3.5. EBBR procedure method . . . . . . . . . . . . . . . . . . . 9 82 3.6. Label release . . . . . . . . . . . . . . . . . . . . . . . 10 83 3.6.1 Label release in method 1 . . . . . . . . . . . . . . . 10 84 3.6.2 Label release in method 2 . . . . . . . . . . . . . . . 10 85 4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . . 10 86 4.1. BFIR tracking of FEC . . . . . . . . . . . . . . . . . . . 10 87 4.2. Datapath traffic flow . . . . . . . . . . . . . . . . . . . 10 88 5. Recursive FEC . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 93 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 95 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 98 1. Introduction 100 This draft extends draft-ietf-bier-pim-signaling to mLDP. 102 Some operators would like to deploy BIER technology in some segment 103 of their network. This draft explains a method to signal mLDP 104 services and stitch it to a BIER domain, with minimal disruption and 105 operational impact to the mLDP domain. 107 This draft explains the procedures needed to signal and uniquely 108 identify a mLDP P2MP LSP in a BIER domain. 110 2. Conventions used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2.1. Definitions 118 Some of the terminology specified in [I-D.draft-ietf-bier- 119 architecture-05] is replicated here and extended by necessary 120 definitions: 122 BIER: 124 Bit Index Explicit Replication (The overall architecture of 125 forwarding multicast using a Bit Position). 127 BFR: 129 Bit Forwarding Router (A router that participates in Bit Index 130 Multipoint Forwarding). A BFR is identified by a unique BFR- 131 prefix in a BIER domain. 133 BFIR: 135 Bit Forwarding Ingress Router (The ingress border router that 136 inserts the Bit Map into the packet). Each BFIR must have a 137 valid BFR-id assigned. BFIR is term used for dataplain packet 138 forwarding. 140 BFER: 142 Bit Forwarding Egress Router. A router that participates in 143 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each 144 BFER must have a valid BFR-id assigned. BFIR is term used for 145 dataplain packet forwarding. 147 BBR: 149 BIER Boundary router. The router between the LDP domain and 150 BIER domain. Maintains mLDP adjacency for all routers attached 151 to it on the mLDP domain and terminates the mLDP adjacency 152 toward the BIER domain. 154 IBBR: 156 Ingress BIER Boundary Router. The ingress router from 157 signaling point of view. It maintains mLDP adjacency toward 158 the LDP domain and determines if the mLDP FEC needs to be 159 signaled across the BIER domain. If so it terminates the mLDP 160 adjacency toward the BIER domain and signals the mLDP FEC 161 through the BIER core. The router also signals the FEC 162 withdraw or release. 164 EBBR: 166 Egress BIER Boundary Router. The egress router in BIER domain 167 from signaling point of view. It terminates the BIER packet 168 sends the mLDP FEC to LDP module to be signaled through the 169 LDP domain.T: 171 BFT: 173 Bit Forwarding Tree used to reach all BFERs in a domain. 175 BIFT: 177 Bit Index Forwarding Table. 179 BIER sub-domain: 181 A further distinction within a BIER domain identified by its 182 unique sub-domain identifier. A BIER sub-domain can support 183 multiple BitString Lengths. 185 BFR-id: 187 An optional, unique identifier for a BFR within a BIER sub- 188 domain. 190 3. M-LDP Signaling Through BIER domain 192 bbr bbr 193 |---LDP Domain--|-----BIER domain-----|---LDP domain--| 194 S--( A )-----------( B ) ---- ( C ) ---- ( D )-----------( E )--h 196 ebbr ibbr 197 Sig <----MLDP------|<--Bier Tunneling----|<---M-LDP------ 198 (new) 200 bfir bfer 201 ------------->|--------BIER-------->|-------------> Datapatah 202 (new) 204 Figure 1: bier boundary router 206 As per figure 1, the procedures of mLDP signaling is done at the BIER 207 boundary routers. The BIER boundary router (BBR) are connected to LDP 208 capable routers toward the LDP domain and BIER routers toward the 209 BIER domain. LDP routers in LDP domain continue to send LDP signaling 210 messages to the BBR. The BBR will create LDP adjacency between all 211 the LDP routers attach to it on the LDP domain. That said the BBR 212 does not propagate the LDP Signaling packets natively into the BIER 213 domain. Instead when it determines that the label mapping or withdraw 214 message needs to be signaled through the BIER domain, it will execute 215 the procedures in this document to uniquely identify and stitch the 216 P2MP LSP through the BIER domain. These procedures are achievable via 217 an SDN Controller or signaling of the the mLDP FEC through the BIER 218 domain, depending on the method. For the latter method this signaling 219 is not for creating a mLDP adjacency between the two disjoint ldp 220 domains through the BIER network. 222 The terminology ingress BBR (ibbr) and egress BBR (ebbr) are relative 223 from signaling point of view. 225 To represent the mLDP P2MP FEC uniquely with in the BIER domain there 226 needs to be a BIER TREE Label (BTL). BTL in essence is mpls label 227 that represents the P2MP LSP with in the BIER domain uniquely. There 228 could be multiple methods used for assigning a BTL to a mLDP P2MP 229 LSP, this is explained in upcoming sections. 231 3.1. Ingress BBR procedure 232 IBBR will create LDP adjacency to all LDP routers attach to it toward 233 the LDP domain. 235 When a mLDP label mapping or withdraw arrives, the IBBR first 236 determines whether the root of the FEC is reachable through the BIER 237 domain. As an example, this root is located on a disjoint LDP domain 238 that is reachable through the BIER domain. If so IBBR will forward 239 the FEC to a BIER label assigning entity to allocated a BIER domain 240 label (BTL) which would uniquely represent this P2MP FEC in the BIER 241 domain. As it will be explained in upcoming sections this "BIER label 242 assigning entity" could be an SDN controller or EBBR. 244 On forwarding plane the IBBR will track all the LDP interfaces on the 245 attach LDP domain which are signaling the same FEC. It creates a 246 stitching point (ILM entry) between the assigned BTL and labels 247 received via the label mapping message on LDP interfaces in LDP 248 domain. This stitching could be a swap or pop and push. With the same 249 token if a label withdraw arrives the IBBR will remove the stitch 250 mapping and forward the FEC and the action to the "BIER label 251 assigning entity" for appropriate action. 253 3.2. Assigning the BIER sub-domain Tree Label 255 There could be 2 methods for assigning a BTL. First via a SDN 256 controller and second via the EBBR. In either method for scalability 257 the BTL needs to be assigned from a label pool represented by EBBR 258 prefixID and its BIER sub-domain . 260 3.2.1. Method 1: IBBR as extraction point to SDN controller 262 In the first method IBBR will terminate the MDLP signaling from LDP 263 domain. For label mapping/withdraw signaling packets, IBBR will 264 extract the FEC and the action and forward it to the SDN Controller 265 with its own BIER Prefix. The message format is <, FEC, 266 action>. 268 The SDN Controller has the entire view of the end to end network or 269 at minimum the view of the BIER domain network. BGP-LS could be used 270 to build this network view. The controller will examine the FEC and 271 find the EBBR closes to the root. The procedure to find the EBBR 272 closest to the root is described in ietf-draft-bier-pim-signaling. 273 After the SDN Controller determines the EBBR it will determine 274 whether this is the first occurrence of this specific mLDP FEC, if so 275 it will assign a BTL from the pool to the FEC to uniquely 276 represent the P2MP tree in the BIER domain. 278 From this point on the SDN Controller keeps track of all new IBBRs 279 which are interested in this P2MP FEC. The SDN Controller will create 280 a mapping << (BTL), FEC, action>>, IBBRs>. The SDN 281 Controller will update the relevant BBRs as described in the SDN 282 Controller section. 284 3.2.2. Method 2, EBBR assigning the BTL 286 Alternatively the IBBR can signal the to EBBR via bier 287 in-band signaling in BIER domain. This signaling could be a new BIER 288 TLV or using the mLDP packet as a signaling packet, in par with 289 draft-ietf-bier-pim-signaling. 291 IBBR will use the ROOT of the mLDP FEC to find EBBR. The procedure to 292 find EBBR is identical to ietf-draft-bier-pim-signaling. After 293 identifying the EBBR, IBBR will encapsulate the mLDP signaling in a 294 BIER packet with the correct EBBR bit set in the bier header and 295 forward the signaling packet into the BIER sub-domain. 297 The EBBR will examine the signaling packet and will allocate a BTL 298 from its pool. The EBBR then constructs <<< 299 (BTL), FEC, action>,IBBRs> mapping. EBBR needs to signal the 300 <<< (BTL), FEC> to the relevant IBBRs. This EBBR signaling 301 can be done via SDN Controller or BGP, explained in upcoming 302 sections. 304 3.2.2.1. BIER packet construction at IBBR for Method 2 306 Assuming the mLDP packet is forwarded from IBBR to EBBR for 307 signaling, the BIER header will be encoded with the BFR-id of the 308 IBBR(with appropriate bit set in the bitstring) and the mLDP 309 signaling packet is then encapsulated in the packet. 311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | BIFT-id | TC |S| TTL | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |Nibble | Ver | BSL | Entropy | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |OAM|Rsv| DSCP | Proto | BFIR-id | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | BitString (first 32 bits) ~ 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 ~ ~ 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 ~ BitString (last 32 bits) | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 BIERHeader.Proto = IPv4 or IPv6 327 BIERHeader.BitString= Bit corresponding to the BFR-ID of the EBBR 329 BIERHeader.BFIR-id = BFR-Id of the BER originating the encapsulated 330 LDP packet, i.e. the IBBR. 332 Rest of the values in the BIER header are determined based on the 333 network (MPLS/non-MPLS), capabilities (BSL), and network 334 configuration. 336 3.2.2.2. Signaling mLDP through the BIER domain procedure 338 Throughout the BIER domain the BIER forwarding procedure is in par 339 with RFC 8279. No BIER transit router will examine the BIER packet 340 encapsulating the mLDP signaling packet. 342 The packet will be forwarded through the BIER domain until it reaches 343 the BBR with matching BFR-ID as in the BIERHeader.Bitstring. This BBR 344 (EBBR) will remove the BIER header and examine the mLDP signaling 345 packet farther. 347 3.3. SDN Controller procedure for updating BBRs with BTL 349 The BBRs can use openflow message to send the mLDP FEC info to the 350 SDN Controller. On the other direction the controller can use BGP SR- 351 TE signaling (or pcep) to download the mapping information to the 352 BBRs. Detail are outside the scope of this document but a new BGP SR- 353 TE NRLI and TLVs would be needed. 355 In either method the SDN Controller will track the <<<< 356 (BTL), FEC, action>, List of > and download the < 357 (BTL), FEC, action> to the relevant BBRs. 359 In method 1 the relevant BBRs are EBBR and the IBBRs that are 360 interested in the P2MP LSP. It should be noted since in this method 361 EBBR does not know about all the IBBRs which are interested in a mLDP 362 FEC, as such the SDN Controller should download to EBBR the < (BTL), FEC, action> mapping with the list of all interested 364 IBBRs. In addition to this, every time an IBBR receives the mLDP FEC 365 it should be signaled to SDN Controller via described method and 366 added to the list. SDN Controller should update the EBBR with that 367 info. 369 In method 2 the EBBR has assigned this mapping and is aware of all 370 IBBRs that are interested in the FEC. EBBR should signal the 371 <<<< (BTL), FEC, action>, List of > to SDN 372 Controller. SDN Controller downloads the mapping to only IBBRs that 373 are interested in the P2MP lsp. As an example the list of . 374 EBBR will update the SDN controller with each arriving new IBBR that 375 wants to join the P2MP LSP. The SDN controller will update these new 376 IBBRs with the relevant mapping. 378 3.4. BGP procedure for signaling BTL for method 2 380 As described in the "Method 2, EBBR assigning the BTL" section, BGP 381 can be used to signal the < (BTL), FEC> to IBBR. This 382 signaling can be via MP-BGP MVPN address family with a new NLRI route 383 type Intra-AS BTL Route 385 +-----------------------------------+ 386 | SD (8 octets) | 387 +-----------------------------------+ 388 | EBBR Router's IP Addr | 389 +-----------------------------------+ 391 The PMSI tunnel attribute can be used to signal the (BTL, FEC) to 392 IBBRs. A new "BTL" tunnel type needs to be assigned. The PMSI TUNNEL 393 ATTRIBUTE MPLS label field can be used to encoded BTL. The Tunnel 394 Identifier will contain the FEC. 396 In addition BGP SR-TE could be used, where the EBBR is generating the 397 NRLI. As per SDN controller section this NLRI is a new NLRI, and the 398 BTL will be part of the SID list (single SID). 400 3.5. EBBR procedure method 402 After identifying the BTL for the P2MP FEC (via method 1 or method 2) 403 EBBR will assign a up stream label for the FEC and signal it toward 404 root via mLDP signaling. 406 With same token the EBBR creates a multicast state with incoming 407 interface as same interface that mLDP signaling packet was forwarded 408 and outgoing interfaces of IBBRs BFIR-ids interested in the P2MP FEC. 410 EBBR will stitch the upstream label to the downstream BTL with out 411 going interfaces the IBBRs interested in this particular P2MP tree 412 and identified via IBBRs BFIR-id. The EBBR will also build a BIER 413 reverse path forwarding table, using the IBBR BFIR-id. This is 414 explained in section 4.1. 416 It should be noted EBBR will maintain LDP adjacency toward the LDP 417 domain and all LDP routers which are connected to it. 419 At this point the end-to-end multicast traffic flow setup is 420 complete. 422 3.6. Label release 424 Assuming label release is originated from a disjoint LDP domain, the 425 EBBR needs to signal the release of BTL to all IBBRs interested in 426 this particular mLDP FEC. Also the EBBR will remove the ILM entry for 427 this FEC base on the label release. 429 3.6.1 Label release in method 1 431 In method 1 the EBBR can signal the label release to the SDN 432 Controller <<<< (BTL), FEC, action>, the SDN Controller 433 will find the list of IBBRs interested in this FEC and will update 434 them accordingly. The IBBR will in addition send a label release to 435 all mLDP neighbors on LDP domain that were signaling this FEC. The 436 EBBR and IBBR will remove the ILM entry for this FEC and the SDN 437 Controller will remove the entry and release the BTL for this FEC as 438 well. 440 3.6.2 Label release in method 2 442 In method 2 the same procedure as method 1 can be followed when the 443 SDN Controller is used for signaling. In case of BGP signaling of 444 BTL, EBBR will automatically withdraw the BTL route. 446 4. Datapath Forwarding 448 4.1. BFIR tracking of FEC 450 As explained before the BFIR has a ILM entry which stitches arriving 451 P2MP label to the BIER sub-domain Tree Label. 453 The BFIR (EBBR) also track all the interested BFERs via arriving 454 binding << (BTL), FEC, action>>, list of (IBBRs)> from SDN 455 Controller (method 1)or the FEC signaling in (method 2). BFIR should 456 build its multicast tree with incoming interface (IIF) as LDP 457 interface (in LDP domain) and out going interfaces OIFs set as the 458 of the interested BFERs (in BIER Domain). 460 4.2. Datapath traffic flow 462 On BFIR when the MPLS label for P2MP LSP arrives a lookup in ILM 463 table is done. Base on the arriving label BFIR will find the 464 stitching forwarding entry. BFIR will swap the incoming MPLS label 465 with the assigned BTL. The swap action can also be a pop of mpls 466 domain label and push of the BTL. BFIR will go through all the BTL's 467 out going interface, (i.e. the IBBRs BFIF-id interested in this P2MP 468 lsp). BFIR will put the corresponding BIER header with bit index set 469 for all IBBRs interested in this P2MP LSP. BFIR will set the 470 BIERHeader.Proto = MPLS and will forward the BIER packet into BIER 471 domain. 473 In the BIER domain normal BIER forwarding procedure will be done, as 474 per RFC 8279 476 The IBBRs will receive the BIER packet, will look at the protocol of 477 BIER header (MPLS) and find the EBBR label pool base on the arriving 478 packet BFR-ID and its sub-domain. BFER will remove the BIER header 479 and will do a lookup in the ILM for BTL. The BTL entry 480 could be swap to the MPLS domain P2MP label or a pop of BST and push 481 of MPLS domain P2MP. The MPLS domain will forward the packet as per 482 MPLS forwarding procedure to all the MPLS OIFs on the IBBR. 484 5. Recursive FEC 486 The above procedures also will work with a mLDP recursive FEC. The 487 root used to determine the EBBR is the outer root of the FEC. The 488 entire recursive FEC needs to be preserve when it is sent from IBBR 489 to EBBR via the controller or the inband BIER signaling. 491 6. IANA Considerations 493 This document contains no actions for IANA. 495 7. Security Considerations 497 TBD 499 8. References 501 8.1. Normative References 503 [BIER_ARCH] Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 504 and S. Aldrin, "Multicast using Bit Index Explicit Replication", 505 internet-draft draft-ietf-bier-architecture-08, October 2016. 507 8.2. Informative References 509 [BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 510 Dolganow, A., and T. Przygienda, "Multicast VPN Using Bier", 511 internet-draft draft-ietf-bier-mvpn-08, January 2017. 513 [ISIS_BIER_EXTENSIONS] Ginsberg, L., Przygienda, T., Aldrin, S., and 514 Z. Zhang, "BIER Support via ISIS", internet-draft draft-ietf-bier- 515 isis-extensions-06.txt, March 2017. 517 [OSPF_BIER_EXTENSIONS] Psenak, P., Kumar, N., Wijnands, IJ., 518 Dolganow, A., Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF 519 Extensions for Bit Index Explicit Replication", internet-draft draft- 520 ietf-ospf-bier-extensions-09.txt, March 2017. 522 7. Acknowledgments 524 Authors' Addresses 526 Hooman Bidgoli (editor) 527 Nokia 528 600 March Rd. 529 Ottawa, Ontario K2K 2E6 530 Canada 532 Email: hooman.bidgoli@nokia.com 534 Jayant Kotalwar 535 Nokia 536 380 N Bernardo Ave, 537 Mountain View, CA 94043 538 US 540 Email: jayant.kotalwar@nokia.com 542 Andrew Dolganow 543 Nokia 544 750D Chai Chee Rd 545 06-06, Viva Business Park 546 Singapore 469004 548 Email: Andrew.dolganow@nokia.com