idnits 2.17.1 draft-ietf-bier-pim-signaling-12.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 (25 July 2021) is 999 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) -- Duplicate reference: RFC2119, mentioned in 'RFC8174', was also mentioned in 'RFC2119'. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Bidgoli, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track F. Xu 5 Expires: 26 January 2022 Verizon 6 J. Kotalwar 7 Nokia 8 I. Wijnands 9 M. Mishra 10 Cisco System 11 Z. Zhang 12 Juniper Networks 13 25 July 2021 15 PIM Signaling Through BIER Core 16 draft-ietf-bier-pim-signaling-12 18 Abstract 20 Consider large networks deploying traditional PIM multicast service. 21 Typically, each portion of these large networks have their own 22 mandates and requirements. It might be desirable to deploy BIER 23 technology in some part of these networks to replace traditional PIM 24 services. In such cases downstream PIM states need to be signaled 25 over the BIER Domain toward the source. 27 This draft specifies the procedure to signal PIM join/prune messages 28 through a BIER Domain, as such enabling the provisioning of 29 traditional PIM services through a BIER Domain. These procedures are 30 valid for forwarding PIM join/prune messages to the Source (SSM) or 31 Rendezvous Point (ASM). 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 26 January 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions used in this document . . . . . . . . . . . . . . 3 68 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. PIM Signaling Through BIER domain . . . . . . . . . . . . . . 4 70 3.1. Ingress BBR procedure . . . . . . . . . . . . . . . . . . 4 71 3.1.1. New Pim Join Attribute, BIER Information Vector . . . 5 72 3.1.1.1. BIER packet construction at the IBBR . . . . . . 6 73 3.2. Signaling PIM through the BIER domain procedure . . . . . 7 74 3.3. EBBR procedure . . . . . . . . . . . . . . . . . . . . . 7 75 4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Datapath traffic flow . . . . . . . . . . . . . . . . . . 8 77 5. PIM-SM behavior . . . . . . . . . . . . . . . . . . . . . . . 8 78 6. Applicability to MVPN . . . . . . . . . . . . . . . . . . . . 8 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 10.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Appendix A. Determining the EBBR . . . . . . . . . . . . . . . . 10 86 A.1. Link-State Protocols . . . . . . . . . . . . . . . . . . 10 87 A.2. Indirect next-hop . . . . . . . . . . . . . . . . . . . . 10 88 A.2.1. Static Route . . . . . . . . . . . . . . . . . . . . 11 89 A.2.2. Interior Border Gateway Protocol (iBGP) . . . . . . . 11 90 A.3. Inter-area support . . . . . . . . . . . . . . . . . . . 11 91 A.3.1. Inter-area Route summarization . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction 96 It might be desirable to simplify/upgrade some part of an existing 97 network to BIER technology, removing any legacy multicast protocols 98 like PIM. This simplification should be done with minimum 99 interruption or disruption to the other parts of the network from 100 singling, services and software upgrade point of view. To do so this 101 draft is specifies procedures for signaling multicast join and prune 102 messages over the BIER domain, this draft is not trying to create 103 FULL PIM adjacency over a BIER domain between two PIM nodes. The PIM 104 adjacency is terminated at BIER edge routers and only join/prune 105 signaling messages are transported over the BIER network. It just so 106 happened that this draft chose signaling messages to be in par with 107 PIM join/prune messages. These signaling messages are forwarded 108 upstream toward the BIER edge router on path to the Source or 109 Rendezvous point. These signaling messages are encapsulated in a 110 BIER header. 112 2. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 2.1. Definitions 122 An understanding of the BIER architecture [RFC8279] and the related 123 terminology is expected. The following are some of the new 124 definitions used in this draft. 126 BBR: 128 BIER Boundary router. A router between the PIM domain and BIER 129 domain. Maintains PIM adjacency for all routers attached to it on 130 the PIM domain and terminates the PIM adjacency toward the BIER 131 domain. 133 IBBR: 135 Ingress BIER Boundary Router. An ingress router from signaling point 136 of view. It maintains PIM adjacency toward the PIM domain and 137 signals join/prune messages across the BIER domain to EBBR as needed. 139 EBBR: 141 Egress BIER Boundary Router. An egress router in BIER domain from 142 signaling point of view. It maintains PIM adjacency to all upstream 143 PIM routers. It terminates the BIER signaling packets and creates 144 necessary PIM join/prune messages into PIM Domain. 146 3. PIM Signaling Through BIER domain 148 BBR BBR 149 |--PIM Domain--|-----BIER domain-----|--PIM domain--| 150 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 152 EBBR IBBR 153 Sig <-----PIM-----|<--BIER Tunneling----|<----PIM------ 154 (new) 155 BFIR BFER 156 ------------->|--------BIER-------->|-------------> Datapath 157 (no change) 159 Figure 1: BIER boundary router 161 Figure 1 illustrates the operation of the BIER Boundary router (BBR). 162 BBRs are connected to PIM routers in the PIM domain and BIER routers 163 in the BIER domain. PIM routers in PIM domain continue to send PIM 164 state messages to the BBR. The BBR will create PIM adjacency between 165 all the PIM routers attached to it on the PIM domain. Each BBR 166 determines if a BIER Signaling Join or Prune message needs to be 167 transmitted through the BIER domain. This draft has chosen these 168 BIER signaling messages to be PIM join/prune message, as such an 169 implementation could chose to tunnel actual PIM join/prune messages 170 through BIER network. This tunneling is only done for signaling 171 purposes and not for creating a PIM adjacency between the two 172 disjoint PIM domains through the BIER domain. 174 The terminology ingress BBR (IBBR) and egress BBR (EBBR) is relative 175 only from a signaling point of view. 177 The egress BBR will determine if the arriving BIER packet is a 178 signaling packet and if so it will generate a PIM join/prune packet 179 toward its attached PIM domain. 181 The new procedures in this draft are only applicable to signaling and 182 there are no changes from datapath point of view. 184 3.1. Ingress BBR procedure 186 The IBBR maintains a PIM adjacency [RFC7761] with any PIM router 187 attached to it on the PIM domain. 189 When a PIM Join or Prune message is received, the IBBR determines 190 whether the Source or RP is reachable through the BIER domain. The 191 EBBR is the BFR through which the Source or RP is reachable. In PIM 192 terms [RFC7761], the EBBR is the RPF Neighbor, and the RPF Interface 193 is the BIER "tunnel" used to reach it. The mechanisms used to find 194 the EBBR are outside the scope of this document and there can be many 195 mechanism depending on if the source or RP are in same area or 196 autonomous system (AS) or in different area or AS -- some examples 197 are provided in Appendix A. 199 If the lookup for source or rendezvous point results into multiple 200 EBBRs, different IBBRs could choose different EBBRs for the same 201 flow. As long as a unique IBBR chooses a unique EBBR for the same 202 flow. On downstream these EBBRs will send traffic to their 203 corresponding IBBRs. 205 After discovering the EBBR and its BFR-id, the IBBR MUST use the BIER 206 Information Vector (Section 3.1.1) which is a PIM Join Attribute type 207 [RFC5384]. The EBBR uses this attribute to obtain the necessary BIER 208 information to build its multicast state. The signaling packet, in 209 this case a PIM Join/Prune message, is encapsulated in the BIER 210 Header and forwarded through the BIER domain to the EBBR. The source 211 address of the PIM packets MUST be set to IBBR local BFR-prefix. The 212 destination address MUST be set to ALL-PIM-ROUTERS [RFC7761]. 214 The IBBR will track all the PIM interfaces on the attached PIM domain 215 which are interested in a certain (S,G). It creates multicast states 216 for arriving join messages from PIM domain, with incoming interface 217 as BIER "tunnel" interface and outgoing interface as the PIM domain 218 interface(s) on which PIM Join(s) were received on. 220 3.1.1. New Pim Join Attribute, BIER Information Vector 222 The new PIM Join Attribute " BIER Information Vector" is defined as 223 follow based on [RFC5384] 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 |F|E|Attr_Type | Length | Addr Family | BIER info 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 231 Figure 2: PIM Join Attribute 233 F bit: Transitive Attribute, as specified in [RFC5384]. MUST be set 234 to zero as this attribute is always non-transitive. If EBBR receives 235 this attribute type with the F bit set it must discard the Attribute. 237 E bit: End of Attributes, as specified in [RFC5384] 239 Attr_Type: TBD assign by IANA. 241 Length: Length of the value field, as specified in [RFC5384]. MUST 242 be set to the length of the BIER Info field + 1. For IPv4 the length 243 is 8, and 20 for IPv6. Incorrect length value compare to the Addr 244 Family must be discarded. 246 Addr Family: PIM address family as specified in [RFC7761]. 247 Unrecognized Address Family must be discarded. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 ~ IBBR Prefix IPv4 or IPv6 ~ 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | sub-domain-id | BFR-id | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 3: PIM Join Attribute detail 259 BIER Info: IBBR's BFR-prefix (IPv4 or IPv6), sub-domain-id, BFR-id 261 3.1.1.1. BIER packet construction at the IBBR 263 The BIER header will be encoded with the BFR-id of the IBBR(with 264 appropriate bit set in the BitString) and the PIM signaling packet is 265 then encapsulated in the packet. 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | BIFT-id | TC |S| TTL | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 |Nibble | Ver | BSL | Entropy | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |OAM|Rsv| DSCP | Proto | BFIR-id | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | BitString (first 32 bits) ~ 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 ~ ~ 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 ~ BitString (last 32 bits) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 4: BIER header 284 BIERHeader.Proto = PIM Addrress Family 285 BIERHeader.BitString= Bit corresponding to the BFR-id of the EBBR 287 BIERHeader.BFIR-id = BFR-Id of the BBR originating the encapsulated 288 signaling packet, i.e. the IBBR. 290 Rest of the values in the BIER header are determined based on the 291 network (MPLS/non-MPLS), capabilities (BSL), and network 292 configuration. 294 3.2. Signaling PIM through the BIER domain procedure 296 Throughout the BIER domain the BIER forwarding procedure is according 297 to [RFC8279]. No BIER router will examine the BIER the signaling 298 packet. As such there is no multicast state built in the BIER 299 domain. 301 The packet will be forwarded through the BIER domain until it reaches 302 the EBBR indicated by the BIERHeader.Bitstring. Only this targeted 303 EBBR router will remove the BIER header and examine the PIM IPv4 or 304 IPv6 signaling packet further as per EBBR Procedure section. 306 3.3. EBBR procedure 308 EBBR removes the BIER Header and determine this is a signaling 309 packet. The Received signaling packet, PIM join/prune message, is 310 processed as if it were received from neighbors on a virtual 311 interface, (i.e. as if the pim adjacency was present, regardless of 312 the fact that there is no adjacency). 314 The EBBR will build a forwarding table for the arriving (S,G) using 315 the obtained BFIR-id and the Sub-Domain information from BIER Header 316 and/or the PIM join Attributes added to the signaling packet. In 317 short it tracks all IBBRs interested in this (S,G). For a specific 318 Source and Group, EBBR SHOULD track all the interested IBBRs via 319 signaling messages arriving from the BIER Domain. BFER builds its 320 (s,g) forwarding state with incoming interface (IIF) as the Reverse 321 Path Forwarding (RPF) interface (in attached PIM domain) towards the 322 source or rendezvous point. The outgoing interfaces include a 323 virtual interface that represent BIER forwarding to tracked IBBRs. 325 The EBBR maintains a PIM adjacency [RFC7761] with any PIM router 326 attached to it on the PIM domain. At this point the end-to-end 327 multicast traffic flow setup is complete. 329 4. Datapath Forwarding 330 4.1. Datapath traffic flow 332 When multicast data traffic arrives on the BFIR (EBBR) it forwards 333 the traffic, through the BIER domain, to all interested IBBRs 334 following the procedures specified in [RFC8279]. The BFER(s) 335 (IBBR(s)) also follow the procedures in [RFC8279] and forward the 336 multicast packet through its outgoing interface(s). 338 5. PIM-SM behavior 340 The procedures described in this document can be used with Any-Source 341 Mutlicast (ASM) as long as a static Rendezvous Point (RP) or embedded 342 RP for IPv6 is used[RFC3956]. 344 It should be noted that this draft only signals PIM Joins and Prunes 345 through the BIER domain and not any other PIM message types including 346 PIM Hellos or Asserts. As such functionality related to these other 347 type of massages will not be possible through a BIER domain with this 348 draft and future drafts might cover these scenarios. As an example 349 DR selection should be done in the PIM domain or if the PIM routers 350 attached to IBBRs are performing DR selection there needs to be a 351 dedicated PIM interface between these routers. The register messages 352 are unicas encapsulatedt from the source to RP as such they are 353 forwarded without these procedures. 355 In case of PIM ASM Static RP or embedded RP for IPv6 the procedure 356 for leaves joining RP is the same as above. It should be noted that 357 for ASM, the EBBRs are determined with respect to the RP instead of 358 the source. 360 6. Applicability to MVPN 362 With just minor changes, the above procedures apply to MVPN as well, 363 with BFIR/BFER/EBBR/IBBR being VPN PEs. All the PIM related 364 procedures, and the determination of EBBR happens in the context of a 365 VRF, following procedures for PIM-MVPN. 367 When a PIM packet arrives from PIM domain attached to the VRF (IBBR), 368 and it is determined that the source is reachable via the VRF through 369 the BIER domain, a PIM signaling message is sent via BIER to the 370 EBBR. In this case usually the PE terminating the PIM-MVPN is the 371 EBBR. A label is imposed before the BIER header is imposed, and the 372 "proto" field in the BIER header is set to 1 (for "MPLS packet with 373 downstream-assigned label at top of stack"). The label is advertised 374 by the EBBR/BFIR to associate incoming packets to its correct VRF. 375 In many scenarios a label is already bound to the VRF loopback 376 address on the EBBR/BFIR and it can be used. 378 When a multicast data packet is sent via BIER by an EBBR/BFIR, a 379 label is imposed before the BIER packet is imposed, and the "proto" 380 field in the BIER header is set to 1 (for "MPLS packet with 381 downstream-assigned label at top of stack"). The label is assigned 382 to the VPN consistently on all VRFs 383 [draft-zzhang-bess-mvpn-evpn-aggregation-label-01]. 385 If the more complicated label allocation scheme is needed for the 386 data packets as specified in 387 [draft-zzhang-bess-mvpn-evpn-aggregation-label-01], then additional 388 PMSI signaling is needed as specified in [RFC6513]. 390 To support per-area subdomain in this case, the ABRs would need to 391 become VPN PEs and maintain per-VPN state so it is unlikely 392 practical. 394 7. IANA Considerations 396 IANA is requested to assign a value (TBD) to the BIER Information 397 Vector PIM Join Attribute from the PIM Join Attribute Types registry. 399 8. Security Considerations 401 The procedures of this document do not, in themselves, provide 402 privacy, integrity, or authentication for the control plane or the 403 data plane. For a discussion of the security considerations 404 regarding the use of BIER, please see [RFC8279] and [RFC8296]. The 405 security consideration for [RFC7761] aslso apply. 407 9. Acknowledgments 409 The authors would like to thank Eric Rosen, Stig Venaas for thier 410 reviews and comments. 412 10. References 414 10.1. Normative References 416 [RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate 417 Requirement Levels"", March 1997. 419 [RFC5384] "A. Boers, I. Wijnands, E. Rosen, "PIM Join Attribute 420 Format"", November 2008. 422 [RFC7761] "B.Fenner, M.Handley, H. Holbrook, I. Kouvelas, R. Parekh, 423 Z.Zhang "PIM Sparse Mode"", March 2016. 425 [RFC8174] "B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC 426 2119 Key Words"", May 2017. 428 [RFC8279] "Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. 429 and S. Aldrin, "Multicast using Bit Index Explicit 430 Replication"", October 2016. 432 [RFC8296] "IJ. Wijnands, E. Rosen, A. Dolganow, J. Yantsura, S. 433 Aldrin, I. Meilik, "Encapsulation for BIER"", January 434 2018. 436 10.2. Informative References 438 [draft-zzhang-bess-mvpn-evpn-aggregation-label-01] 439 "Z. Zhang, E. Rosen, W. Lin, Z. Li, I.Wijnands, "MVPN/EVPN 440 Tunnel Aggregation with Common labels"", April 2018. 442 [RFC3956] "P.Savola, B. Haberman "Embedding the Rendezvous Point 443 (RP) Address in an IPv6 Multicast Address"". 445 [RFC6513] "E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs"", 446 November 2008. 448 Appendix A. Determining the EBBR 450 This appendix provides some examples of routing procedures that can 451 be used to determine the EBBR at the IBBR. 453 A.1. Link-State Protocols 455 On IBBR SPF procedures can be used to find the EBBR closest to the 456 source. 458 Assuming the BIER domain consists of all BIER forwarding routers, SPF 459 calculation can identify the router advertising the prefix for the 460 source. A post process can find the EBBR by walking from the 461 advertising router back to the IBBR in the reverse direction of 462 shortest path tree branch until the first BFR is encountered. 464 A.2. Indirect next-hop 466 Alternatively, the route to the source could have an indirect next- 467 hop that identifies the EBBR. These methods are explained in the 468 following sections. 470 A.2.1. Static Route 472 A static route to the source can be configured on the IBBR with the 473 next-hop set as the EBBR's BFR-prefix. 475 A.2.2. Interior Border Gateway Protocol (iBGP) 477 Consider the following topology: 479 EBBR IBBR 480 |--PIM Domain--|-----BIER domain-----|--PIM domain--| 481 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 483 Figure 5: Static Route 485 Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM 486 Domain routes are redistributed to the BIER domain via BGP, 487 performing next-hop-self for these routes. This would include the 488 Multicast Source IP address (S). In such case BGP should use the 489 same next-hop as the EBBR BIER prefix. This will ensure that all PIM 490 domain routes, including the Multicast Source IP address (S) are 491 resolve via EBBR's BIER prefix address. When the host (h) triggers a 492 PIM join message to IBBR (D), IBBR tries to resolve (S). It resolves 493 (S) via BGP installed route and realizes its next-hop is EBBR (B). 495 A.3. Inter-area support 497 If each area has its own BIER sub-domain, the above procedure for 498 post-SPF could identify one of the ABRs and the EBBR. If a sub- 499 domain spans multiple areas, then additional procedures as described 500 in A.2 is needed. 502 A.3.1. Inter-area Route summarization 504 In a multi-area topology, a BIER sub-domain can span a single area. 505 Suppose this single area is constructed entirely of BIER capable 506 routers and the ABRs are the BIER Boundary Routers attaching the BIER 507 sub-domain in this area to PIM domains in adjacent areas. These BBRs 508 can summarize the PIM domain routes via summary routes, as an example 509 for OSPF, a type 3 summary LSAs can be used to advertise summary 510 routes from a PIM domain area to the BIER area. In such scenarios 511 the IBBR can be configured to look up the Source via IGP database and 512 use the summary routes and its Advertising Router field to resolve 513 the EBBR. The IBBR needs to ensure that the IGP summary route is 514 generated by a BFR. This can be achieved by ensuring that BIER Sub- 515 TLV exists for this route. If multiple BBRs (ABRs) have generated 516 the same summary route the lowest Advertising Router IP can be 517 selected or a vendor specific hashing algorithm can select the 518 summary route from one of the BBRs. 520 Authors' Addresses 522 Hooman Bidgoli (editor) 523 Nokia 524 Ottawa 525 Canada 527 Email: hooman.bidgoli@nokia.com 529 Fengman Xu 530 Verizon 531 Richardson, 532 United States of America 534 Email: fengman.xu@verizon.com 536 Jayant Kotalwar 537 Nokia 538 Montain View, 539 United States of America 541 Email: jayant.kotalwar@nokia.com 542 IJsbrand Wijnands 543 Cisco System 544 Diegem 545 Belgium 547 Email: ice@cisco.com 549 Mankamana Mishra 550 Cisco System 551 Milpitas, 552 United States of America 554 Email: mankamis@cisco.com 556 Zhaohui Zhang 557 Juniper Networks 558 Boston, 559 United States of America 561 Email: zzhang@juniper.com