idnits 2.17.1 draft-ietf-bier-pim-signaling-11.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 16, 2020) is 1256 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: 'TBD' is mentioned on line 481, but not defined == Unused Reference: 'RFC4607' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'RFC8401' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC8444' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RFC8556' is defined on line 540, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: May 20, 2021 Verizon 6 J. Kotalwar 7 Nokia 8 I. Wijnands 9 M. Mishra 10 Cisco System 11 Z. Zhang 12 Juniper Networks 13 November 16, 2020 15 PIM Signaling Through BIER Core 16 draft-ietf-bier-pim-signaling-11 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. 24 It might be desirable to deploy BIER technology in some part of these 25 networks to replace traditional PIM services. In such cases 26 downstream PIM states need to be signaled over BIER Domain toward the 27 source. 29 This draft explains the procedure to signal PIM joins and prunes 30 through a BIER Domain, as such enable provisioning of traditional PIM 31 services through a BIER Domain. 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 May 20, 2021. 50 Copyright Notice 52 Copyright (c) 2020 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 (https://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. Conventions used in this document . . . . . . . . . . . . . . 3 69 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. PIM Signaling Through BIER domain . . . . . . . . . . . . . . 5 71 3.1. Ingress BBR procedure . . . . . . . . . . . . . . . . . . 5 72 3.1.1. Determining EBBR on IBBR . . . . . . . . . . . . . . 6 73 3.1.2. Considering ECMP in EBBR selection . . . . . . . . . 6 74 3.1.3. PIM Signaling packet construction at IBBR . . . . . . 7 75 3.1.3.1. BIER packet construction at IBBR . . . . . . . . 8 76 3.2. Signaling PIM through the BIER domain procedure . . . . . 8 77 3.3. EBBR procedure . . . . . . . . . . . . . . . . . . . . . 9 78 4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . 9 79 4.1. BFIR tracking of (S,G) . . . . . . . . . . . . . . . . . 9 80 4.2. Datapath traffic flow . . . . . . . . . . . . . . . . . . 9 81 5. PIM-SM behavior . . . . . . . . . . . . . . . . . . . . . . . 9 82 6. Applicability to MVPN . . . . . . . . . . . . . . . . . . . . 10 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 10.2. Informative References . . . . . . . . . . . . . . . . . 11 89 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 A.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 A.2. Indirect next-hop . . . . . . . . . . . . . . . . . . . . 12 92 A.2.1. Static Route . . . . . . . . . . . . . . . . . . . . 13 93 A.2.2. Interior Border Gateway Protocol (iBGP) . . . . . . . 13 94 A.3. Inter-area support . . . . . . . . . . . . . . . . . . . 13 95 A.3.1. Inter-area Route summarization . . . . . . . . . . . 13 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 98 1. Introduction 100 Consider large networks deploying traditional PIM multicast service. 101 Typically, each portion of these large networks have their own 102 mandates and requirements. 104 It might be desirable to deploy BIER technology in some part of these 105 networks to replace traditional PIM services. In such cases 106 downstream PIM states need to be signaled over BIER Domain toward the 107 source. 109 This draft explains the procedure to signal PIM joins and prunes 110 through a BIER Domain, as such enable provisioning of traditional PIM 111 services through a BIER Domain. 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as describe in [RFC2119]. 119 2.1. Definitions 121 Some of the terminology specified in [RFC8279] is replicated here and 122 extended by necessary definitions: 124 BIER: 126 Bit Index Explicit Replication (The overall architecture of 127 forwarding multicast using a Bit Position). 129 BFR: 131 Bit Forwarding Router (A router that participates in Bit Index 132 Multipoint Forwarding).A BFR is identified by a unique BFR-prefix in 133 a BIER domain. 135 BFIR: 137 Bit Forwarding Ingress Router (The ingress border router that 138 performs BIER encapsulation). Each BFIR must have a valid BFR-id 139 assigned. In this draft BIER will be used for forwarding and 140 tunneling of control plane packet (i.e. PIM) and forwarding 141 dataplane packets. BFIR is the term used for dataplane packet 142 forwarding. 144 BFER: 146 Bit Forwarding Egress Router. A router that participates in Bit 147 Index Forwarding as leaf. Each BFER must have a valid BFR-id 148 assigned. In this draft BIER will be used for forwarding and 149 tunneling of control plane packet (i.e. PIM) and forwarding 150 dataplane packets. BFIR is the term used for dataplane packet 151 forwarding. 153 BBR: 155 BIER Boundary router. A router between the PIM domain and BIER 156 domain. Maintains PIM adjacency for all routers attached to it on 157 the PIM domain and terminates the PIM adjacency toward the BIER 158 domain. 160 IBBR: 162 Ingress BIER Boundary Router. An ingress router from signaling point 163 of view. It maintains PIM adjacency toward the PIM domain and 164 determines if PIM joins and prunes arriving from PIM domain need to 165 be signaled across the BIER domain. If so it terminates the PIM 166 adjacency toward the BIER domain and signals the PIM joins/prunes 167 through the BIER core. 169 EBBR: 171 Egress BIER Boundary Router. An egress router in BIER domain from 172 signaling point of view. It terminates the BIER packet and forwards 173 the signaled joins and prunes into PIM Domain. 175 BFT: 177 Bit Forwarding Tree used to reach all BFERs in a domain. 179 BIFT: 181 Bit Index Forwarding Table. 183 BIER sub-domain: 185 A further distinction within a BIER domain identified by its unique 186 sub-domain identifier. A BIER sub-domain can support multiple 187 BitString Lengths. 189 BFR-id: 191 An optional, unique identifier for a BFR within a BIER sub-domain. 193 3. PIM Signaling Through BIER domain 195 BBR BBR 196 |--PIM Domain--|-----BIER domain-----|--PIM domain--| 197 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 199 EBBR IBBR 200 Sig <-----PIM-----|<--BIER Tunneling----|<----PIM------ 201 (new) 202 BFIR BFER 203 ------------->|--------BIER-------->|-------------> Datapath 204 (no change) 206 Figure 1: BIER boundary router 208 As per figure 1, the procedures of PIM signaling is done at the BIER 209 boundary router. The BIER boundary routers (BBR) are connected to 210 PIM capable routers toward the PIM domain and BIER routers toward the 211 BIER domain. PIM routers in PIM domain continue to send PIM state 212 messages to the BBR. The BBR will create PIM adjacency between all 213 the PIM routers attached to it on the PIM domain. That said the BBR 214 does not propagate all PIM packets natively into the BIER domain. 215 Instead when it determines that the PIM join or prune messages needs 216 to be signaled through the BIER domain it will tunnel the PIM packet 217 through the BIER network. This tunneling is only done for signaling 218 purposes and not for creating a PIM adjacency between the two 219 disjoint PIM domains through the BIER domain. 221 The terminology ingress BBR (IBBR) and egress BBR (EBBR) are relative 222 from signaling point of view. 224 The ingress BBR will determine if an arriving PIM join or prune needs 225 to be signaled across the BIER domain. While the egress BBR will 226 determine if the arriving BIER packet is a signaling packet and if so 227 it will generate a PIM join/prune packet toward its attached PIM 228 domain. 230 The BFER and BFIR are BBR from datapath point of view. It should be 231 noted the new procedures in this draft are only applicable to 232 signaling and there are no changes from datapath point of view. 234 3.1. Ingress BBR procedure 236 IBBR will create PIM adjacency to all PIM routers attached to it 237 toward the PIM domain. 239 When a PIM join or prune for certain (S,G) arrives, the IBBR first 240 determines whether the join or prune is meant for a source that is 241 reachable through the BIER domain. As an example, this source is 242 located in a disjoint PIM domain that is reachable through the BIER 243 domain. If so the IBBR will try to resolve the source via an EBBR 244 closest to the source. 246 The procedure to find the EBBR (BFIR from datapath point of view) can 247 be via many mechanisms explained in more detail in upcoming section. 249 After discovering the EBBR and its BFR-ID, the IBBR will include a 250 new PIM Join Attribute in the join/prune message as per [RFC5384]. 251 Two new "BIER IBBR" attributes are defined and explained in upcoming 252 section. The PIM Join Attribute is used on EBBR to obtain necessary 253 BIER information to build its multicast states. In addition the IBBR 254 will change the PIM signaling packet source IP address to its BIER 255 prefix address (standard PIM procedure). It will also keep the 256 destination address as the well known multicast IP address. It then 257 will construct the BIER header. The signaling packet, in this case 258 the PIM join/prune packet, is encapsulated in the BIER header and 259 transported through BIER domain to EBBR. 261 The IBBR will track all the PIM interfaces on the attached PIM domain 262 which are interested in a certain (S,G). It creates multicast states 263 for arriving (S,G)s from PIM domain, with incoming interface as BIER 264 "tunnel" interface and outgoing interface as the PIM domain 265 interface(s) on which PIM Join(s) were received on. 267 3.1.1. Determining EBBR on IBBR 269 As it was explained in the previous section, IBBR needs to determine 270 the EBBR closest to the source. This is needed to encode the BIER 271 header BitString field to forward the signaling packet through the 272 BIER domain. 274 It should be noted, the PIM domains can be either part of the same 275 IGP area as BIER domain(single area) or are stitched to the BIER 276 domain via an ABR or ASBR routers. As such on IBBR, there can be 277 many different procedures to determine the EBBR. Some examples of 278 these procedures have been provided in Appendix A. 280 3.1.2. Considering ECMP in EBBR selection 282 If the lookup for source results into multiple EBBRs, then the EBBR 283 selection algorithm should ensure that all signaling for a particular 284 (C-S, C-G) is forwarded to a single EBBR. How this selection is done 285 is vendor specific and beyond this draft. As an example it can be 286 round robin per (C-S, C-G) or lowest EBBR IP for all (C-S, C-G)s. 288 3.1.3. PIM Signaling packet construction at IBBR 290 To ensure all necessary BIER information needed by EBBR is present in 291 the BIER signaling message, a new PIM Join Attribute [RFC5384] is 292 used. EBBR can use this attribute to build its multicast states, as 293 described in EBBR procedure section. This new PIM join Attribute is 294 added to PIM signaling message on the IBBR. Its format is as follow: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |F|E| Type=tbd | Length | Addr Family | BIER info 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 302 Figure 2: PIM Join Attribute 304 F bit: The Transitive bit. Specifies whether this attribute is 305 transitive or non-transitive. MUST be set to zero. This attribute 306 is ALWAYS non-transitive. 308 E bit: End-of-Attributes bit. Specifies whether this attribute is 309 the last. Set to zero if there are more attributes. Set to 1 if 310 this is the last attribute. 312 Type: TBD assign by IANA. 314 Length: The length in octets of the attribute value. MUST be set to 315 the length in octets of the BIER info +1 octet to account for the 316 Address Family field. For IPv4 AF Length = 7+1 For IPv6 AF Length = 317 19+1. 319 Addr Family: Signaled PIM Join/Prune address family as defined in 320 [RFC7761]. 322 BIER Info: IBBR Prefix (IPv4 or IPv6), SD, bfr-id as per below figure 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 ~ IBBR Prefix IPv4 or IPv6 ~ 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | subdomain-id | BFR-ID | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 3: PIM Join Attribute detail 334 3.1.3.1. BIER packet construction at IBBR 336 The BIER header will be encoded with the BFR-id of the IBBR(with 337 appropriate bit set in the BitString) and the PIM signaling packet is 338 then encapsulated in the packet. 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | BIFT-id | TC |S| TTL | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 |Nibble | Ver | BSL | Entropy | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 |OAM|Rsv| DSCP | Proto | BFIR-id | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | BitString (first 32 bits) ~ 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 ~ ~ 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 ~ BitString (last 32 bits) | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Figure 4: BIER header 357 BIERHeader.Proto = IPv4 or IPv6 359 BIERHeader.BitString= Bit corresponding to the BFR-ID of the EBBR 361 BIERHeader.BFIR-id = BFR-Id of the BBR originating the encapsulated 362 PIM packet, i.e. the IBBR. 364 Rest of the values in the BIER header are determined based on the 365 network (MPLS/non-MPLS), capabilities (BSL), and network 366 configuration. 368 3.2. Signaling PIM through the BIER domain procedure 370 Throughout the BIER domain the BIER forwarding procedure is on par 371 with [RFC8279]. No BIER router will examine the BIER packet 372 encapsulating the PIM signaling packet. As such there is no 373 multicast state built in the BIER domain. 375 The packet will be forwarded through the BIER domain until it reaches 376 the BER with matching BFR-ID as in the BIERHeader.Bitstring. EBBR 377 will remove the BIER header and examine the PIM IPv4 or IPv6 378 signaling packet further as per EBBR Procedure section. 380 3.3. EBBR procedure 382 EBBR will remove the BIER header and determine this is a signaling 383 packet. The Received PIM join/prune Signaling packet is processed as 384 if it were received from neighbors on a virtual interface, (i.e. as 385 if the pim adjacency was present, regardless of the fact that there 386 is no adjacency). 388 The EBBR will build a forwarding table for the arriving (S,G) using 389 the obtained BFIR-id and the Sub-Domain information from BIER Header 390 and/or the PIM join Attributes added to the PIM Signaling packet. In 391 short it tracks all IBBRs interested in this (S,G). This is 392 explained in section 4.1. 394 The multicast state on EBBR will contain PIM domain incoming 395 interfaces, according to PIM specification and outgoing interfaces 396 based on the above procedure to build the forwarding table. 398 It should be noted EBBR will maintain PIM adjacency toward the PIM 399 domain and all PIM routers which are connected to it. At this point 400 the end-to-end multicast traffic flow setup is complete. 402 4. Datapath Forwarding 404 4.1. BFIR tracking of (S,G) 406 For a specific Source and Group, BFIR (EBBR)should track all the 407 interested BFERs (IBBRs) via PIM signaling messages arriving from the 408 BIER Domain. BFIR builds its (s,g) forwarding state with incoming 409 interface (IIF) as the Reverse Path Forwarding (RPF) interface (in 410 attached PIM domain) towards the source. The outgoing interfaces are 411 the tracked BFERs in the Bier Sub Domain. 413 4.2. Datapath traffic flow 415 When the multicast data traffic arrives on the BFIR (EBBR) the router 416 will find all the interested BFERs for that specific (S,G). The 417 router then constructs the BIERHeader.BitString with all the BFER 418 interested in the group and will forward the packet to the BIER 419 domain. The BFER(s) will accept the packets and remove the BIER 420 header and forward the multicast packet as per pre-built multicast 421 state for (S,G) and its outgoing interfaces. 423 5. PIM-SM behavior 425 The procedures described in this document can work with Any-Source 426 Mutlicast (ASM) as long as static Rendevous Point (RP) or embedded RP 427 for IPv6 is used. Future drafts would cover Bootstrap Router (BSR) 428 and more complicated SM discovery mechanisms. 430 It should be noted that this draft only signals PIM Joins and Prunes 431 through the BIER domain and not any other PIM message types including 432 PIM Hellos or Asserts. As such functionality related to these other 433 type of massages will not be possible through a BIER domain with this 434 draft and future drafts might cover these scenarios. As an example 435 DR selection should be done in the PIM domain or if the PIM routers 436 attached to IBBRs are performing DR selection there needs to be a 437 dedicated PIM interface between these routers. 439 In case of PIM ASM Static RP or embedded RP for IPv6 the procedure 440 for leaves joining RP is the same as above. It should be noted that 441 for ASM, the EBBRs are determined with respect to the RP instead of 442 the source. 444 6. Applicability to MVPN 446 With just minor changes, the above procedures apply to MVPN as well, 447 with BFIR/BFER/EBBR/IBBR being VPN PEs. All the PIM related 448 procedures, and the determination of EBBR happens in the context of a 449 VRF, following procedures for PIM-MVPN. 451 When a PIM packet arrives from PIM domain attached to the VRF (IBBR), 452 and it is determined that the source is reachable via the VRF through 453 the BIER domain, a PIM signaling message is sent via BIER to the 454 EBBR. In this case usually the PE terminating the PIM-MVPN is the 455 EBBR. A label is imposed before the BIER header is imposed, and the 456 "proto" field in the BIER header is set to 1 (for "MPLS packet with 457 downstream-assigned label at top of stack"). The label is advertised 458 by the EBBR/BFIR to associate incoming packets to its correct VRF. 459 In many scenarios a label is already bound to the VRF loopback 460 address on the EBBR/BFIR and it can be used. 462 When a multicast data packet is sent via BIER by an EBBR/BFIR, a 463 label is imposed before the BIER packet is imposed, and the "proto" 464 field in the BIER header is set to 1 (for "MPLS packet with 465 downstream-assigned label at top of stack"). The label is assigned 466 to the VPN consistently on all VRFs 467 [draft-zzhang-bess-mvpn-evpn-aggregation-label-01]. 469 If the more complicated label allocation scheme is needed for the 470 data packets as specified in 471 [draft-zzhang-bess-mvpn-evpn-aggregation-label-01], then additional 472 PMSI signaling is needed as specified in [RFC6513]. 474 To support per-area subdomain in this case, the ABRs would need to 475 become VPN PEs and maintain per-VPN state so it is unlikely 476 practical. 478 7. IANA Considerations 480 In the "PIM Join Attribute Types" registry, IANA to assign a new 481 value [TBD] to the BIER Info Vector. 483 8. Security Considerations 485 The procedures of this document do not, in themselves, provide 486 privacy, integrity, or authentication for the control plane or the 487 data plane. For a discussion of the security considerations 488 regarding the use of BIER, please see [RFC8279] and [RFC8296]. 489 Security considerations regarding PIM protocol is based on [RFC7761]. 491 9. Acknowledgments 493 The authors would like to thank Eric Rosen, Stig Venaas for thier 494 reviews and comments. 496 10. References 498 10.1. Normative References 500 [RFC4607] "H. Holbrook, B. Cain, "Source-Specific multicast for 501 IP"", October 2016. 503 [RFC8279] "Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. 504 and S. Aldrin, "Multicast using Bit Index Explicit 505 Replication"", October 2016. 507 10.2. Informative References 509 [draft-zzhang-bess-mvpn-evpn-aggregation-label-01] 510 "Z. Zhang, E. Rosen, W. Lin, Z. Li, I.Wijnands, "MVPN/EVPN 511 Tunnel Aggregation with Common labels"", April 2018. 513 [RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate 514 Requirement Levels"", March 1997. 516 [RFC5384] "A. Boers, I. Wijnands, E. Rosen, "PIM Join Attribute 517 Format"", November 2008. 519 [RFC6513] "E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs"", 520 November 2008. 522 [RFC6826] "IJ. Wijnands, T. Echert, N. Leymann, M. Napierala, 523 "Multipoint LDP In-Band Singnaling for PtP MPtMP LSP"", 524 January 2013. 526 [RFC7761] "B.Fenner, M.Handley, H. Holbrook, I. Kouvelas, R. Parekh, 527 Z.Zhang "PIM Sparse Mode"", March 2016. 529 [RFC8296] "IJ. Wijnands, E. Rosen, A. Dolganow, J. Yantsura, S. 530 Aldrin, I. Meilik, "Encapsulation for BIER"", January 531 2018. 533 [RFC8401] "Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 534 "BIER Support via ISIS"", June 2018. 536 [RFC8444] "Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 537 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 538 for Bit Index Explicit Replication"", June 2018. 540 [RFC8556] "Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, 541 S.,Dolganow, A., and T. Przygienda, "Multicast VPN Using 542 BIER"", March 2018. 544 Appendix A. 546 This appendix provides some examples and routing procedures that can 547 be used to determine the EBBR on IBBR. It should be noted, the PIM 548 domains can be either part of the same IGP area as BIER domain(single 549 area) or are stitched to the BIER domain via an ABR or ASBR routers. 550 As such on IBBR, there can be many different procedures to determine 551 the EBBR. Not all procedures are listed below. 553 A.1. SPF 555 On IBBR SPF procedures can be used to find the EBBR closest to the 556 source. 558 Assuming the BIER domain consists of all BIER forwarding routers, SPF 559 calculation can identify the router advertising the prefix for the 560 source. A post process can find the EBBR by walking from the 561 advertising router back to the IBBR in the reverse direction of 562 shortest path tree branch until the first BFR is encountered. 564 A.2. Indirect next-hop 566 Alternatively, the route to the source could have an indirect next- 567 hop that identifies the EBBR. These methods are explained in the 568 following sections. 570 A.2.1. Static Route 572 On IBBR there can be a static route configured for the source, with 573 source next-hop set as EBBR BIER prefix. 575 A.2.2. Interior Border Gateway Protocol (iBGP) 577 Consider the following topology: 579 BBR BBR 580 EBBR IBBR 581 |--PIM Domain--|-----BIER domain-----|--PIM domain--| 582 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 584 Figure 5: Static Route 586 Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM 587 Domain routes are redistributed to the BIER domain via BGP. This 588 would include the Multicast Source IP address (S), which resides in 589 the PIM Domain. In such case BGP should use the same loopback 590 interface as its next-hop as the BBR prefix. This will ensure that 591 all PIM domain routes, including the Multicast Source IP address (S) 592 are resolve via BBR's BIER prefix id as their next-hop. When the 593 host (h) triggers a PIM join message to IBBR (D), IBBR tries to 594 resolve (S). It resolves (S) via BGP installed route and realizes 595 its next-hop is EBBR (B). IBBR will use this next-hop (B) to find 596 its corresponding BIER bit index. 598 This procedure is inline with [RFC6826] mLDP in-band signaling 599 section 601 A.3. Inter-area support 603 If each area has its own BIER sub-domain, the above procedure for 604 post-SPF could identify one of the ABRs and the EBBR. If a sub- 605 domain spans multiple areas, then additional procedures as described 606 in A.2 is needed. 608 A.3.1. Inter-area Route summarization 610 In a multi-area topology, a BIER sub-domain can span a single area. 611 Suppose this single area is constructed entirely of BIER capable 612 routers and the ABRs are the BIER Boundary Routers attaching the BIER 613 sub-domain in this area to PIM domains in adjacent areas. These BBRs 614 can summarize the PIM domain routes via summary routes, as an example 615 for OSPF, a type 3 summary LSAs can be used to advertise summary 616 routes from a PIM domain area to the BIER area. In such scenarios 617 the IBBR can be configured to look up the Source via IGP database and 618 use the summary routes and its Advertising Router field to resolve 619 the EBBR. The IBBR needs to ensure that the IGP summary route is 620 generated by a BFR. This can be achieved by ensuring that BIER Sub- 621 TLV exists for this route. If multiple BBRs (ABRs) have generated 622 the same summary route the lowest Advertising Router IP can be 623 selected or a vendor specific hashing algorithm can select the 624 summary route from one of the BBRs. 626 Authors' Addresses 628 Hooman Bidgoli (editor) 629 Nokia 630 Ottawa 631 Canada 633 Email: hooman.bidgoli@nokia.com 635 Fengman Xu 636 Verizon 637 Richardson 638 US 640 Email: fengman.xu@verizon.com 642 Jayant Kotalwar 643 Nokia 644 Montain View 645 US 647 Email: jayant.kotalwar@nokia.com 649 IJsbrand Wijnands 650 Cisco System 651 Diegem 652 Belgium 654 Email: ice@cisco.com 656 Mankamana Mishra 657 Cisco System 658 Milpitas 659 USA 661 Email: mankamis@cisco.com 662 Zhaohui Zhang 663 Juniper Networks 664 Boston 665 USA 667 Email: zzhang@juniper.com