idnits 2.17.1 draft-ietf-bier-pim-signaling-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. 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 (January 24, 2019) is 1919 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 126 looks like a reference -- Missing reference section? 'RFC5384' on line 296 looks like a reference -- Missing reference section? 'RFC8279' on line 309 looks like a reference -- Missing reference section? 'RFC6513' on line 436 looks like a reference Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 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 6 Fengman Xu 7 Verizon 8 IJ. Wijnand 9 Mankamana Mishra 10 Cisco Systems, Inc. 11 Z. Zhang 12 Juniper Networks 14 Expires: July 28, 2019 January 24, 2019 16 PIM Signaling Through BIER Core 17 draft-ietf-bier-pim-signaling-05 19 Abstract 21 Bit Index Explicit Replication (BIER) is an architecture that 22 provides multicast forwarding through a "BIER domain" without 23 requiring intermediate routers to maintain multicast related per-flow 24 state. Neither does BIER require an explicit tree-building protocol 25 for its operation. A multicast data packet enters a BIER domain at a 26 "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at 27 one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router 28 adds a BIER header to the packet. Such header contains a bit-string 29 in which each bit represents exactly one BFER to forward the packet 30 to. The set of BFERs to which the multicast packet needs to be 31 forwarded is expressed by the according set of bits switched on in 32 BIER packet header. 34 This document describes the procedure needed for PIM Joins and Prunes 35 to be signaled through a BIER core. Allowing PIM routers to run 36 traditional PIM multicast services through a BIER core. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." The list 52 of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 This Internet-Draft will expire on October 8, 2017. 60 Copyright Notice 62 Copyright (c) 2019 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Conventions used in this document . . . . . . . . . . . . . . . 3 79 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 80 3. PIM Signaling Through BIER domain . . . . . . . . . . . . . . . 5 81 3.1. Ingress BBR procedure . . . . . . . . . . . . . . . . . . . 6 82 3.1.1. Determining EBBR on IBBR . . . . . . . . . . . . . . . 7 83 3.1.4. Pim Signaling packet construction at IBBR . . . . . . . 7 84 3.1.4.1 BIER packet construction at IBBR . . . . . . . . . . 7 85 3.2. Signaling PIM through the BIER domain procedure . . . . . . 8 86 3.3. EBBR procedure . . . . . . . . . . . . . . . . . . . . . . 8 87 4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . . 9 88 4.1. BFIR tracking of (S,G) . . . . . . . . . . . . . . . . . . 9 89 4.2. Datapath traffic flow . . . . . . . . . . . . . . . . . . . 9 90 5. PIM-ASM behavior . . . . . . . . . . . . . . . . . . . . . . . 9 91 6. Applicability to MVPN . . . . . . . . . . . . . . . . . . . . . 9 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 97 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 98 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 99 A.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 100 A.2. Indirect next-hop . . . . . . . . . . . . . . . . . . . . . 11 101 A.2.1. Static Route . . . . . . . . . . . . . . . . . . . . . 11 102 A.2.2. Interior Border Gateway Protocol (iBGP) . . . . . . . . 11 103 A.3. Inter-area support . . . . . . . . . . . . . . . . . . . . 12 104 A.3.1. Inter-area Route summarization . . . . . . . . . . . . 12 106 1. Introduction 108 Consider large networks deploying traditional PIM multicast service. 109 Typically, each portion of these large networks have their own 110 mandates and requirements. 112 It might be desirable to deploy BIER technology in some part of these 113 networks to replace traditional PIM services. In such cases 114 downstream PIM states need to be signaled over BIER Domain toward the 115 source. 117 This draft explains the procedure to signal PIM joins and prunes 118 through a BIER Domain, as such enable provisioning of traditional PIM 119 services through a BIER Domain. 121 2. Conventions used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2.1. Definitions 129 Some of the terminology specified in [I-D. rfc8279] is replicated 130 here and extended by necessary definitions: 132 BIER: 134 Bit Index Explicit Replication (The overall architecture of 135 forwarding multicast using a Bit Position). 137 BFR: 139 Bit Forwarding Router (A router that participates in Bit Index 140 Multipoint Forwarding).A BFR is identified by a unique BFR- 141 prefix in a BIER domain. 143 BFIR: 145 Bit Forwarding Ingress Router (The ingress border router that 146 inserts the BM into the packet). Each BFIR must have a valid 147 BFR-id assigned. In this draft BIER will be used for 148 forwarding and tunneling of control plain packet (i.e. PIM) 149 and forwarding dataplane packets. BFIR is term used for 150 dataplane packet forwarding. 152 BFER: 154 Bit Forwarding Egress Router. A router that participates in 155 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each 156 BFER must have a valid BFR-id assigned. In this draft BIER 157 will be used for forwarding and tunneling of control plain 158 packet (i.e. PIM) and forwarding dataplane packets. BFIR is 159 term used for dataplane packet forwarding. 161 BBR: 163 BIER Boundary router. A router between the PIM domain and BIER 164 domain. Maintains PIM adjacency for all routers attached to it 165 on the PIM domain and terminates the PIM adjacency toward the 166 BIER domain. 168 IBBR: 170 Ingress BIER Boundary Router. An ingress router from signaling 171 point of view. It maintains PIM adjacency toward the PIM 172 domain and determines if PIM joins and prunes arriving from 173 PIM domain need to be signaled across the BIER domain. If so 174 it terminates the PIM adjacency toward the BIER domain and 175 signals the PIM joins/prunes through the BIER core. 177 EBBR: 179 Egress BIER Boundary Router. An egress router in BIER domain 180 from signaling point of view. It terminates the BIER packet 181 and forwards the signaled joins and prunes into PIM Domain. 183 BFT: 185 Bit Forwarding Tree used to reach all BFERs in a domain. 187 BIFT: 189 Bit Index Forwarding Table. 191 BIER sub-domain: 193 A further distinction within a BIER domain identified by its 194 unique sub-domain identifier. A BIER sub-domain can support 195 multiple BitString Lengths. 197 BFR-id: 199 An optional, unique identifier for a BFR within a BIER sub- 200 domain. 202 3. PIM Signaling Through BIER domain 204 BBR BBR 205 |--PIM Domain--|-----BIER domain-----|--PIM domain--| 206 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 208 EBBR IBBR 209 Sig <-----PIM-----|<--BIER Tunneling----|<----PIM------ 210 (new) 212 bfir bfer 213 ------------->|--------BIER-------->|-------------> Datapath 214 (no change) 216 Figure 1: BIER boundary router 218 As per figure 1, the procedures of PIM signaling is done at the BIER 219 boundary router. The BIER boundary router (BBR) are connected to PIM 220 capable routers toward the PIM domain and BIER routers toward the 221 BIER domain. PIM routers in PIM domain continue to send PIM state 222 messages to the BBR. The BBR will create PIM adjacency between all 223 the PIM routers attached to it on the PIM domain. That said the BBR 224 does not propagate all PIM packets natively into the BIER domain. 225 Instead when it determines that the PIM join or prune messages needs 226 to be signaled through the BIER domain it will tunnel the PIM packet 227 through the BIER network. This tunneling is only done for signaling 228 purposes and not for creating a PIM adjacency between the two 229 disjoint PIM domains through the BIER domain. 231 The terminology ingress BBR (IBBR) and egress BBR (EBBR) are relative 232 from signaling point of view. 234 The ingress BBR will determine if an arriving PIM join or prune needs 235 to be signaled across the BIER domain. While the egress BBR will 236 determine if the arriving BIER packet is a signaling packet and if so 237 it will generate a PIM signaling packet toward its attached PIM 238 domain. 240 The BFER and BFIR are BBR from datapath point of view. It should be 241 noted the new procedures in this draft are only applicable to 242 signaling and there are no changes from datapath point of view. 244 3.1. Ingress BBR procedure 246 IBBR will create PIM adjacency to all PIM routers attached to it 247 toward the PIM domain. 249 When a PIM join or prune for certain (S,G) arrives, the IBBR first 250 determines weather the join or prune is meant for a source that is 251 reachable through the BIER domain. As an example, this source is 252 located on a disjoint PIM domain that is reachable through the BIER 253 domain. If so the IBBR will try to resolve the source via an EBBR 254 closest to the source. 256 The procedure to find the EBBR (BFIR from datapath point of view) can 257 be via many mechanisms explained in more detail in upcoming section. 259 After discovering the EBBR and its BFR-ID (flooded via IGP BIER 260 extension), the IBBR will construct a PIM Join Attribute encoded as 261 TLVs into the Source Address field of the PIM Join Message as per 262 [RFC5384] and include it in PIM signaling message. Two new "BIER 263 IBBR" attributes are define and explained in upcoming section. The 264 PIM Join Attribute is used on EBBR to obtain necessary bier 265 information to build its multicast states. In addition the IBBR will 266 change the PIM signaling packet source IP address to its BIER prefix 267 address (standard PIM procedure). It will also keep the destination 268 address as the well known multicast IP address. It then will 269 construct the BIER header. The signaling packet, in this case the PIM 270 join/prune packet, is encapsulated in the BIER header and transported 271 through BIER domain to EBBR. 273 The IBBR will track all the PIM interfaces on the attached PIM domain 274 which are interested in a certain (S,G). It creates multicast states 275 for arriving (S,G)s from PIM domain, with incoming interface as BIER 276 "tunnel" interface and outgoing interface as the PIM domain 277 interface(s) on which PIM Join(s) were received on. 279 3.1.1. Determining EBBR on IBBR 281 As it was explained in previous section, IBBR needs to determine the 282 EBBR closest to the source. This is needed to encode the BIER header 283 BitString field to forward the signaling packet through the BIER 284 domain. 286 It should be noted, the PIM domains can be either part of the same 287 IGP area as BIER domain(single area) or are stitched to the BIER 288 domain via an ABR or ASBR routers. As such on IBBR, there can be many 289 different procedures to determine the EBBR. Some examples of these 290 procedures have been provided in Appendix A. 292 3.1.4. Pim Signaling packet construction at IBBR 294 To ensure all necessary bier information needed by EBBR to build its 295 multicast states (as described in EBBR procedure section) is present 296 in the PIM signaling message, PIM Join Attribute [RFC5384] is used in 297 PIM signaling Join message. Two new Attr-Type are defined: 299 Attr_type=TBD (BIER IBBR info IPv4): lenght=6 ; value=IBBR Prefix 300 (ipv4), SD, bfr-id 302 Attr_type=TBD (BIER IBBR info IPv6): lenght=19 ; value=IBBR Prefix 303 (ipv6), SD, bfr-id 305 IBBR Prefix: this is IPv4 or IPv6 BFR-Prefix of the IBBR for the 306 specific subdomain as described in [RFC8279] SD: This is a 8-bit 307 field that encodes the Sub-Domain as described in [RFC8279]. BFR-ID: 308 this is a 16-bit field which identifies the BFR uniquely with in the 309 subdomain as described in [RFC8279] 311 3.1.4.1 BIER packet construction at IBBR 313 The BIER header will be encoded with the BFR-id of the IBBR(with 314 appropriate bit set in the bitstring) and the PIM signaling packet is 315 then encapsulated in the packet. 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | BIFT-id | TC |S| TTL | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |Nibble | Ver | BSL | Entropy | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 |OAM|Rsv| DSCP | Proto | BFIR-id | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | BitString (first 32 bits) ~ 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 ~ ~ 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 ~ BitString (last 32 bits) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 BIERHeader.Proto = IPv4 or IPv6 334 BIERHeader.BitString= Bit corresponding to the BFR-ID of the EBBR 336 BIERHeader.BFIR-id = BFR-Id of the BER originating the encapsulated 337 PIM packet, i.e. the IBBR. 339 Rest of the values in the BIER header are determined based on the 340 network (MPLS/non-MPLS), capabilities (BSL), and network 341 configuration. 343 3.2. Signaling PIM through the BIER domain procedure 345 Throughout the BIER domain the BIER forwarding procedure is in par 346 with RFC 8279. No BIER router will examine the BIER packet 347 encapsulating the PIM signaling packet. As such there is no multicast 348 state build in the BIER domain. 350 The packet will be forwarded through the BIER domain until it reaches 351 the BER with matching BFR-ID as in the BIERHeader.Bitstring. EBBR 352 will remove the BIER header and examine the PIM IPv4 or IPv6 353 signaling packet farther as per EBBR Procedure section. 355 3.3. EBBR procedure 357 After receiving the BIER packet and determining this packet is a 358 signaling packet, EBBR will remove the BIER header from PIM packet. 359 The Received PIM join/prune Signaling packet is processed as if it 360 were received from neighbors on a virtual interface, (i.e. as if the 361 pim adjacency was presents, regardless of the fact there is no 362 adjacency) 364 With same token the EBBR creates a multicast state with incoming 365 interface as same interface that PIM join packet was forwarded and 366 outgoing interfaces of BIER tunnel to BFER identified with BFIR-id 367 and its corresponding Sub-Domain obtained from the BIER header or via 368 PIM Join Attributes added to the PIM signaling packet by the IBBR. 370 The EBBR will also build a forwarding table for the arriving (S,G) 371 using the obtained BFIR-id and the Sub-Domain information, in short 372 it tracks all IBBRs interested in this (S,G). This is explained in 373 section 4.1. 375 It should be noted EBBR will maintain PIM adjacency toward the PIM 376 domain and all PIM routers which are connected to it. 378 At this point the end-to-end multicast traffic flow setup is 379 complete. 381 4. Datapath Forwarding 383 4.1. BFIR tracking of (S,G) 385 For a specific Source and Group, BFIR (EBBR)should track all the 386 interested BFERs (IBBRs) via arriving PIM signaling from BIER Domain. 387 BFIR builds its (s,g)forwarding state with incoming interface (IIF) 388 as the RPF interface (in PIM domain) towards the source and one of 389 the outgoing interfaces as for sending to tracked BFERs in the SD. 391 4.2. Datapath traffic flow 393 When the multicast data traffic arrives on the BFIR (EBBR) the router 394 will find all the interested BFERs for that specific (S,G). The 395 router then constructs the BIERHeader.BitString with all the BFER 396 interested in the group and will forward the packet to the BIER 397 domain. The BFER(s) will accept the packets and remove the BIER 398 header and forward the multicast packet as per pre-build multicast 399 state for (S,G) and its outgoing interfaces. 401 5. PIM-ASM behavior 403 In case of PIM ASM the procedure for LEAFs joining RP is same as 404 above. It should be noted that for ASM, the EBBR is determined with 405 respect to the RP instead of the source. 407 6. Applicability to MVPN 409 With just minor changes, the above procedures apply to MVPN as well, 410 with BFIR/BFER/EBBR/IBBR being VPN PEs. 412 All the PIM related procedures, and the determination of EBBR happens 413 in the context of a VRF, following procedures for PIM-MVPN. 415 When a PIM packet arrives from PIM domain attached to the vrf (IBBR), 416 and it is determine that the source is reachable via the vrf through 417 the BIER domain, a PIM signaling message is sent via BIER to the 418 EBBR. In this case usually the PE terminating the PIM-MVPN is the 419 EBBR. A label is imposed before the BIER header is imposed, and the 420 "proto" field in the BIER header is set to 1 (for "MPLS packet with 421 downstream-assigned label at top of stack"). The label is advertised 422 by the EBBR/BFIR to associate incoming packets to its correct VRF. In 423 many scenarios a label is already bound to the VRF loopback address 424 on the EBBR/BFIR and it can be used. 426 When a multicast data packet is sent via BIER by an EBBR/BFIR, a 427 label is imposed before the BIER packet is imposed, and the "proto" 428 field in the BIER header is set to 1 (for "MPLS packet with 429 downstream-assigned label at top of stack"). The label is assigned to 430 the VPN consistently on all VRFs [draft-zzhang-bess-mvpn-evpn- 431 aggregation-label]. 433 If the more complicated label allocation scheme is needed for the 434 data packets as specified in [draft-zzhang-bess-mvpn-evpn- 435 aggregation-label], then additional PMSI signaling is needed as 436 specified in [RFC6513]. 438 To support per-area subdomain in this case, the ABRs would need to 439 become VPN PEs and maintain per-VPN state so it is unlikely 440 practical. 442 7. IANA Considerations 444 This document contains no actions for IANA. 446 8. Security Considerations 448 The procedures of this document do not, in themselves, provide 449 privacy, integrity, or authentication for the control plane or the 450 data plane. For a discussion of the security considerations regarding 451 the use of BIER, please see RFC8279 and RFC8296. Security 452 considerations regarding PIM protocol is based on RFC4601. 454 9. References 456 9.1. Normative References 458 [BIER_ARCH] Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 459 and S. Aldrin, "Multicast using Bit Index Explicit Replication", rfc 460 8279, October 2016. 462 9.2. Informative References 464 [BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 465 Dolganow, A., and T. Przygienda, "Multicast VPN Using Bier", 466 internet-draft draft-ietf-bier-mvpn-11, March 2018. 468 [ISIS_BIER_EXTENSIONS] Ginsberg, L., Przygienda, T., Aldrin, S., and 469 Z. Zhang, "BIER Support via ISIS", internet-draft draft-ietf-bier- 470 isis-extensions-11.txt, June 2018. 472 [OSPF_BIER_EXTENSIONS] Psenak, P., Kumar, N., Wijnands, IJ., 473 Dolganow, A., Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF 474 Extensions for Bit Index Explicit Replication", internet-draft draft- 475 ietf-ospf-bier-extensions-18.txt, June 2018. 477 10. Acknowledgments 479 The authors would like to thank Eric Rosen, Stig Venaas for thier 480 reviews and comments. 482 Appendix A 484 This section provides some examples and routing procedures that can 485 be used to determine the EBBR on IBBR. It should be noted, the PIM 486 domains can be either part of the same IGP area as BIER domain(single 487 area) or are stitched to the BIER domain via an ABR or ASBR routers. 488 As such on IBBR, there can be many different procedures to determine 489 the EBBR. Not all procedures are listed below. 491 A.1. SPF 493 On IBBR SPF procedures can be used to find the EBBR closest to the 494 source. 496 Assuming the BIER domain is consist of all BIER forwarding routers, 497 SPF calculation can identify the router advertising the prefix for 498 the source. A post process can find the EBBR by walking from the 499 advertising router back to the IBBR in the reverse direction of 500 shortest path tree branch until the first BFR is encountered. 502 A.2. Indirect next-hop 504 Alternatively, the route to the source could have an indirect next- 505 hop that identifies the EBBR. These methods are explained in the 506 following sections. 508 A.2.1. Static Route 510 On IBBR there can be a static route configured for the source, with 511 source next-hop set as EBBR BIER prefix. 513 A.2.2. Interior Border Gateway Protocol (iBGP) 515 Consider the following topology: 517 BBR BBR 518 EBBR IBBR 519 |--PIM Domain--|-----bier domain-----|--PIM domain--| 520 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 522 Figure 2 524 Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM 525 Domain routes are redistributed to the BIER domain via BGP. This 526 would include the Multicast Source IP address (S), which resides in 527 the PIM Domain. In such case BGP should use the same loopback 528 interface as its next-hop as the BBR prefix. This will ensure that 529 all PIM domain routes, including the Multicast Source IP address (S) 530 are resolve via BBR's bier prefix id as their next-hop. When the host 531 (h) triggers a PIM join message to IBBR (D), IBBR tries to resolve 532 (S). It resolves (S) via BGP installed route and realizes its next- 533 hop is EBBR (B). IBBR will use this next-hop (B) to find its 534 corresponding BIER bit index. 536 This procedure is inline with RFC6826 mLDP in-band signaling section 537 2. 539 A.3. Inter-area support 541 If each area has its own BIER sub-domain, the above procedure for 542 post-SPF could identify one of the ABRs and the EBBR. If a sub-domain 543 spans multiple areas, then additional procedures as described in A.2 544 is needed. 546 A.3.1. Inter-area Route summarization 548 In a multi-area topology, a BIER sub-domain can span a single area. 549 Suppose this single area is constructed entirely of Bier capable 550 routers and the ABRs are the BIER Boundary Routers attaching the BIER 551 sub-domain in this area to PIM domains in adjacent areas. These BBRs 552 can summarize the PIM domain routes via summary routes, as an example 553 for OSPF, a type 3 summary LSAs can be used to advertise summary 554 routes from a PIM domain area to the BIER area. In such scenarios the 555 IBBR can be configured to look up the Source via IGP database and use 556 the summary routes and its Advertising Router field to resolve the 557 EBBR. The IBBR needs to ensure that the IGP summary route is 558 generated by a BFR. This can be achieved by ensuring that bier sub- 559 tlv exists for this route. If multiple BBRs (ABRs) have generated the 560 same summary route the lowest Advertising Router IP can be selected 561 or a vendor specific hashing algorithm can select the summary route 562 from one of the BBRs. 564 Hooman Bidgoli (editor) 565 Nokia 566 600 March Rd. 567 Ottawa, Ontario K2K 2E6 568 Canada 570 Email: hooman.bidgoli@nokia.com 572 Fengman Xu 573 Verizon 574 400 International PKWY 575 Richardson, Tx 75081 576 US 578 Email: fengman.xu@verizon.com 580 Jayant Kotalwar 581 Nokia 582 380 N Bernardo Ave 583 Mountain View, CA 94043 584 US 586 Email: jayant.kotalwar@nokia.com 588 Andrew Dolganow 589 Nokia 590 750D Chai Chee Rd 591 06-06, Viva Business Park 592 Singapore 469004 594 Email: Andrew.dolganow@nokia.com 596 IJsbrand Wijnands 597 Cisco System 598 De Kleetlaan 6a 599 Diegem 1831 600 Belgium 602 Email: ice@cisco.com 604 Mankamana Mishra 605 Cisco System 606 821 alder drive 607 Milpitas California 608 USA 610 Email: mankamis@cisco.com 611 Zhaohui Zhang 612 Juniper Networks 613 USA 615 EMail: zzhang@juniper.net