idnits 2.17.00 (12 Aug 2021) /tmp/idnits10819/draft-zzhang-bier-multicast-as-a-service-03.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 abstract seems to contain references ([RFC8279], [RFC8444], [RFC8401], [RFC7279]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2021) is 212 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: 'RFC7279' is mentioned on line 20, but not defined == Missing Reference: 'RFC4023' is mentioned on line 506, but not defined == Missing Reference: 'RFC7510' is mentioned on line 506, but not defined == Unused Reference: 'RFC2119' is defined on line 549, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-ietf-bier-prefix-redistribute-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track E. Rosen 5 Expires: April 17, 2022 Individual 6 D. Awduche 7 Verizon 8 L. Geng 9 China Mobile 10 G. Shepherd 11 Individual 12 October 14, 2021 14 Multicast/BIER As A Service 15 draft-zzhang-bier-multicast-as-a-service-03 17 Abstract 19 This document describes a framework for providing multicast as a 20 service via Bit Index Explicit Replication (BIER) [RFC7279], and 21 specifies a few enhancements to [draft-ietf-bier-idr-extensions] 22 [RFC8279] [RFC8401] [RFC8444] to enable multicast/BIER as a service. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC2119. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 17, 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. A CDN of A Single Provider . . . . . . . . . . . . . . . 4 67 1.2.1. IGP/BGP Interworking . . . . . . . . . . . . . . . . 5 68 1.3. A CDN That Involves Another Provider . . . . . . . . . . 6 69 1.3.1. Providing Independent BAAS To Multiple Customers . . 6 70 1.3.2. Control and Accounting . . . . . . . . . . . . . . . 7 71 1.4. Sets and Segmentation . . . . . . . . . . . . . . . . . . 8 72 1.4.1. Multiple Sets . . . . . . . . . . . . . . . . . . . . 8 73 1.4.2. Segmentation . . . . . . . . . . . . . . . . . . . . 8 74 2. Specifications for Enhancements to BIER Signaling with 75 BGP/IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 2.1. BGP Procedures . . . . . . . . . . . . . . . . . . . . . 9 77 2.2. ISIS/OSPF Procedures . . . . . . . . . . . . . . . . . . 10 78 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 7.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 Currently multicast is primarily used in the following scenarios: 91 o Enterprise Applications. For example, large scale financial data 92 publishing. 94 o Provider/underlay tunnels for MVPN and for EVPN BUM. 96 o Real-time IPTV offered by a service provider to its customers. 98 Besides the above, large scale multicast services, especially transit 99 multicast transport provided by large Internet Service Providers is 100 virtually non-existent. This is mainly because of the following 101 chicken and egg dilemma: 103 o Traditional multicast technologies are complicated and lack 104 scalability. The revenue that multicast services bring in cannot 105 offset the Capex and Opex that an operator has to invest, so 106 provider networks typically do not enable multicast even though 107 the deployed equipment does support multicast. 109 o As a result, Content Providers cannot take advantage of multicast 110 and instead use less efficient methods like Ingress Replication, 111 Peer2Peer, or multicast at application layer. 113 A recent multicast technology breakthrough, BIER, provides a simple 114 and scalable solution for large scale multicast deployment, 115 independent of number of multicast flows. In the meantime, large 116 scale distribution of ultra high definition video content has become 117 more and more popular and important. Service providers simply cannot 118 keep on increasing their network capacity even if they could shift 119 cost to Content Providers. With these developments, service 120 providers now have both the need and means to provide scalable 121 multicast service, potentially across multiple providers. 123 This document describes a framework for Multicast As A Service (MAAS) 124 enabled by BIER. We use Content Delivery Network (CDN) as example, 125 though it applies to any large scale multicast delivery service. 127 1.1. Terminologies 129 Readers are assumed to be familiar with multicast, BIER, BGP and 130 ISIS/OSPF concepts and procedures. Some terminologies are listed 131 here for convenience. 133 o BFR: BIER Forwarding Router. 135 o BFIR: BIER Forwarding Ingress Router. 137 o BFER: BIER Forwarding Egress Router. 139 o EBFR: Edge BFR. Including BFIR and BFER. 141 o BSL: BitStrengLength. Number of bits in the BitString of a BIER 142 header. 144 1.2. A CDN of A Single Provider 146 To make it easier to understand, we first consider a simple example: 147 a CDN owned by a single operator, which could be a Content Provider 148 itself. The network spans multiple ASes as shown in the following 149 figure: 151 ++++ ++++ 152 EBFR11+ +EBFR12 EBFR21+ + EBFR22 153 + + + + 154 + + + + 155 + AS100 + + AS200 + 156 + + + + 157 + + + + 158 + ASBR132 +++++++++ ASBR231+ +EBFR23 159 EBFR13 + \ + + / ++++ 160 + + ASBR312 ASBR321 161 +++ ASBR131 + + 162 \ + AS300 + 163 ASBR311 (BFR) + 164 ASBR341 ASBR351 (BFR) 165 / + + \ 166 ++++ / ++++++++++++ \ +++++* 167 EBFR43 ASBR431 ASBR531 EBFR53 168 + + + + 169 + AS400 + + AS500 + 170 + + + + 171 EBFR41 EBFR42 EBFR51 EBFR52 172 + + + + 173 ++++++ +++++++ 175 The CDN uses BIER for multicast transport and Edge BIER Forwarding 176 Routers (EBFRs) are located throughout the network. Some of them are 177 connected towards multicast content sources and are referred to as 178 BIER Forwarding Ingress Routers (BFIRs) in BIER architecture. Most 179 of them are connected towards multicast content receivers and are 180 referred to as BIER Forwarding Egress Routers (BFERs). Notice that 181 between content sources and BFIRs there may be Protocol Independent 182 Multicast (PIM) in use, while between content receivers and BFERs 183 there may be PIM and/or IGMP in use. 185 At the initial deployment stage, there might be only a few transit 186 BIER Forwarding Routers (BFRs) at strategic points in the network 187 (e.g. ASBR311 and ASBR351). BGP sessions are established among the 188 EBFRs and BFRs, and BGP extensions as defined in 190 [I-D.ietf-bier-idr-extensions] are used to signal BIER information. 191 All these are in a single BIER sub-domain. 193 In the example of initial stage with only ASBR311 and ASBR351 as 194 BFRs, multicast traffic arriving at EBFR11 will be imposed with a 195 BIER header and replicated to EBFR12/EBFR13/ASBR311 over tunnels. 196 ASBR311 will further replicate traffic to 197 ASBR351/EBFR41/EBFR42/EBFR43/EBFR21/EBFR22/EBFR23 over tunnels, and 198 ASBR351 will further replicate traffic to EBFR51/EBFR52/EBFR53 over 199 tunnels. 201 The BGP signaling and a necessary enhancement can be explained using 202 the following example. EBFR43 advertises its BIER prefix (a loopback 203 address) as /32 IPv4 or /128 IPv6 prefix in BGP with a BIER Path 204 Attribute (BPA) [RFC8279] [I-D.ietf-bier-idr-extensions]. ASBR431 205 receives it and re-advertises it (with BGP Next Hop changed to 206 itself) but does not do anything wrt BIER because it does not support 207 BIER. Same happens on ASBR341. When ASBR311 and ASBR351 receive it 208 from ASBR341, they create a BIFT entry corresponding to EBFR43's BFR- 209 ID. The entry causes a BIER packet with corresponding bit set in its 210 BitString to be tunneled to EBFR43. This cannot be based on BGP Next 211 Hop in the advertisement because the BGP Next Hop is ASBR341. When 212 eventually EBFR11 receives the re-advertised route, it creates a BIFT 213 entry that causes corresponding packets to be tunneled to ASBR311 214 (but not to EBFR43 directly). Now it is clear that this cannot be 215 based on either the BIER prefix itself or the BGP Next Hop. The 216 solution is that the originating EBFR attaches a Tunnel Encap 217 Attribute (TEA) [RFC9012] with the tunnel destination set to itself, 218 and whenever a BFR re-advertises the route it changes the tunnel 219 destination to itself. When a BFR creates the BIFT entry, it uses 220 the Tunnel Egress Endpoint in the TEA to find out where to tunnel 221 packets. 223 Over time, more routers in network may be upgraded to support BIER 224 and become a BFR. For example, once ASBR431 is upgraded to a BFR, 225 ASBR311 no longer needs to tunnel traffic to EBFR41/EBFR42/EBFR43 but 226 only need to tunnel one copy to ASBR431, who will then replicate to 227 EBFR41/EBFR42/EBFR43. 229 1.2.1. IGP/BGP Interworking 231 Additionally, if enough routers in an AS (or just one of its IGP 232 areas) can be upgraded to run BIER, then hop-by-hop BIER forwarding 233 can be utilized there, using IGP extensions for BIER signaling 234 [RFC8401] [RFC8444]. 236 Notice that even with this there is still only one BIER sub-domain, 237 with mixed IGP and BGP signaling for BIER. To redistribute BIER 238 information between IGP and BGP, procedures specified in 239 [I-D.ietf-bier-prefix-redistribute] and detailed in Section 2.2 are 240 followed. 242 1.3. A CDN That Involves Another Provider 244 In the above example, the CDN is providing multicast transport 245 service, with simplicity and scalability provided by BIER (the per- 246 flow state is confined to the edges). Now let us go one step further 247 and consider that AS300 belongs to a different Internet Service 248 Provider. Now the ISP is providing BIER As A Service (BAAS) to the 249 CDN, by being part of the CDN's BIER sub-domain. Notice that, not 250 only does the ISP not have per-tree state (it does not have EBFRs), 251 but also its BFRs do not need BFR-ID assigned. The ISP does need to 252 learn about all the EBFRs and their corresponding BFR-IDs (through 253 signaling). 255 1.3.1. Providing Independent BAAS To Multiple Customers 257 Now consider that the ISP also provides BAAS for another CDN. Each 258 of the two CDNs has its own BIER domain, with its own BFR-ID or even 259 sub-domain ID assignment that could conflict between the two CDNs. 260 For example, both have BFR-ID 100 and sub-domain ID 0 assigned but 261 they are totally independent of each other. For an BFR in the ISP to 262 support this, with BGP signaling it needs to advertise its own BFR 263 prefix multiple times, each time with a different RD that is mapped 264 to the corresponding CDN. A new SAFI BIER (to be allocated by IANA) 265 is used. 267 In the above example, there are two paths between AS100 and AS300. 268 It is possible that while ASBR311 is the BFR, ASBR312 is the unicast 269 best path into AS300 and beyond from AS100. Advertising BIER 270 prefixes using a different SAFI with a RD also has the side benefit 271 of allowing incongruent topologies for unicast and BIER. 273 In the existing BIER architecture and IGP extensions for BIER a sub- 274 domain is tied to a single topology (either the one and only topology 275 if Multi-topology ISIS/OSPF is not used, or a topology as defined in 276 Multi-topology ISIS/OSPF). In the BIER sub-TLV that ISIS/OSPF 277 attaches to a BIER prefix, a Sub-domain-ID value can only appear once 278 for a particular topology. In this document, a BFR in the BAAS 279 provider may belong to different and independent BIER domains, and 280 the same sub-domain ID needs to be signaled multiple times, once for 281 each BIER domain (notice that the same sub-domain-ID actually 282 identifies different sub-domains in different BIER domains, so this 283 does not really change the architectural requirement that a sub- 284 domain is tied to a single topology). To do so, a new "BIER Domain" 285 sub-TLV is introduced, and its value field includes a RD (as in the 286 BGP signaling) and a BIER sub-sub-TLV that is the same as currently 287 specified in ISIS/OSPF extensions for BIER. 289 This works very well because of the flexible BIER architecture - a 290 BIER packet is forwarded based on a Bit Index Forwarding Table (BIFT) 291 that is determined by a 20-bit BIFT ID in front of the BIER header, 292 and each (subdomain, BSL, set) tuple has its own BIFT. 293 Traditionally, a subdomain is identified by a sub-domain ID but in 294 this document a subdomain is now identified by a (RD, sub-domain ID) 295 tuple in the control plane. 297 With this, the scaling aspect on a BFR comes to how many BAAS 298 customer the provider needs to support. For example, if it needs to 299 support 16 BAAS customers, one BSL, and four sets (Section 1.4.1) for 300 each customer, then the provider needs to support 64 BIFTs (16 x 1 x 301 4). If the BSL is 256, then each BIFT has 256 entries in it and the 302 total number of BIFT entries (routes) is 4k (256 x 64). Notice that 303 this 4k number is not related to the number of customers' multicast 304 flows, but only related to the number of customers and number of 305 customer EBFRs. The number of customers with their own independent 306 BIER domains are likely not very large initially, but if multicast as 307 a service gets more widely used, the protocol and procedures defined 308 in this document can scale up to the extent of how many BIFTs (and 309 BIFT entries) a BFR can support. Since there is no real difference 310 between a BIFT entry and a unicast RIB/FIB entry, as long as the 311 scaling requirements are adequately considered in the BIER forwarding 312 plane implementation (e.g., enough memory is allocated for the 313 BIFTs), scaling will not become a bottleneck. 315 Building/updating the BIFTs is the same as in the base BIER 316 architecture, except that in the control plane a subdomain is 317 identified by a (RD, sub-domain ID) tuple instead of just a sub- 318 domain ID. This is transparent to the forwarding plane - a BIFT is 319 always identified by an opaque 20-bit opaque number. This opaque 320 number is either a label for MPLS encapsulation or an opaque number 321 for non-MPLS encapsulation, and the optional static encoding as 322 specified in [I-D.ietf-bier-non-mpls-bift-encoding] cannot be used. 324 1.3.2. Control and Accounting 326 With BGP based signaling, internal routers of a BAAS provider does 327 not need explicit configuration for the BIER transport services that 328 it support. In the above example, the ASBRs (ASBR311, ASBR312, 329 ASBR321, ASBR341, ASBR351) in AS300 only need to have BGP policy 330 configured to allow certain received BIER prefix advertisements to 331 trigger necessary BIER state and additional signaling of their own. 332 For example, when ASBR351 receives the BIER prefix advertisement, if 333 its local configuration allows it may create corresponding BIFTs and 334 BIFT entries, and additionally originates or updates its own BIER 335 prefix advertisement. An internal BFR inside AS300, upon receiving 336 the BGP advertisements, may or may not need to go through the same 337 policy check again (based on the providers operation model). 339 When the ASBRs (re-)advertise BIER prefixes toward their external 340 peers, they could enable statistics counters for the corresponding 341 BIER labels so that they can count incoming BIER packets from 342 external peers specifically for this BAAS. Similarly, the ASBRs can 343 enable statistics counters for BIER labels they receive from external 344 peers, so that they can count outgoing BIER packets delivered to the 345 external peers. These incoming and outgoing counters can be used for 346 accounting and billing purposes. 348 1.4. Sets and Segmentation 350 The number of EBFRs could very well be larger than the BSL. There 351 are two ways to handle that - multiple sets or segmentation. 353 1.4.1. Multiple Sets 355 With this method the set of EBFRs are grouped into multiple sets, and 356 the number of EBFRs in a set is smaller than the BSL. A BFIR may 357 need to send multiple copies of a multicast packet to reach all 358 BFERs, one copy for each set that covers one or more expecting BFERs. 359 A separate BIFT is needed for each set (because the same bit in the 360 BitString of packets for different sets maps to different BFERs). 361 This not only leads to multiple copies to be sent over the same link, 362 but also requires additional BIFTs. In the earlier example, 64 BIFTs 363 are needed for 16 BAAS customers because each customer needs 4 BIFTs 364 for the multiple sets. 366 1.4.2. Segmentation 368 With this method, a BIER network is segmented into multiple regions, 369 each with its own BIER sub-domain. In the earlier example, each AS 370 could be an independent sub-domain. A BIER packet from EBFR11 will 371 be decapsulated by the segmentation border router ASBR311, and then 372 sent into next sub-domain in AS300 with a new BIER header. The 373 segmentation [RFC7524] involves Multicast Flow Overlay [RFC8279] 374 [RFC8556] so that the segmentation border routers know what BitString 375 to use when sending onto the next segment. The advantage of 376 segmentation is that only a single copy needs to be sent, and the 377 number of BIFTs is also reduced on all BFRs. The disadvantage is 378 that the segmentation points need to run multicast flow overlay 379 protocol and maintain related state in control plane and data plane. 381 A deployment may start without the need for either multiple sets or 382 segmentation when the number of EBFRs is small. When the number of 383 EBFRs grows, segmentation can be introduced incrementally. A new BFR 384 can be added as, or an existing BFR could be converted to, a 385 segmentation point, splitting the original sub-domain into two 386 independent sub-domains. The segmentation point does not re- 387 advertise BIER information from one sub-domain to another. Other 388 BFRs/EBFRs do not need any configuration changes except to make sure 389 that all BIER information exchange is restricted to a single sub- 390 domain (for example, two BFRs were BGP peers before and were 391 exchanging BIER information but now they belong to two sub-domains 392 and only exchange BIER information with the segmentation point and 393 other BFRs in the same sub-domain). 395 In the earlier example of a CDN of a single provider, using 396 segmentation may be acceptable, even though the overlay state needs 397 to be kept by the segmentation points. A BAAS provider may need to 398 carefully consider if it wants to keep a customer's overlay state on 399 those segmentation points. On the other hand, the provider may 400 consider hosting per-customer segmentation points. For example, 401 tethering small or virtual BFRs to an ASBR and have those BFRs be the 402 segmentation points [I-D.ietf-bier-tether]. 404 2. Specifications for Enhancements to BIER Signaling with BGP/IGP 406 2.1. BGP Procedures 408 When an EBFR advertises a BIER prefix with a BIER Path Attribute 409 (BPA), it SHOULD attach a Tunnel Encap Attribute (TEA) with the 410 tunnel destination set to itself. 412 A BFR receiving the advertisement MUST use the tunnel destination in 413 the TEA to determine where to forward a BIER packet whose BitString 414 has a set bit corresponding to the BIER prefix, unless the TEA does 415 not exist, in which case the BIER prefix itself is used for the 416 determination. When the BFR re-advertises the BIER prefixes, it MUST 417 change the tunnel destination in the TEA to itself, or add a TEA with 418 the tunnel destination set to itself if there was no TEA in the 419 received advertisement. 421 The TEA SHOULD have a Protocol Sub-TLV with protocol type BIER 422 (0xAB37). 424 A transit BFR that is allowed (by provisioning or based on policy) to 425 participate in a BIER sub-domain MUST advertise its own BIER prefix 426 with a BPA. The BFR-id in the BPA SHOULD be 0. Depending on the 427 operational model of the operator, the advertisement MAY be based on 428 received BIER prefixes (subject to certain BGP policy verification), 429 or MAY do so only with explicit configuration. 431 If a provider provides independent BAAS services to multiple 432 customers, when its BFR receives BIER prefixes from a customer it 433 MUST re-advetise with a new BIER SAFI. For simplicity, all BFRs of 434 the provider use the same RD that is specifically assigned for the 435 customer. When a BFR re-advertises BIER prefixes to a customer, it 436 MUST re-advertise with SAFI 1 or 2. 438 If multiple providers together provide BAAS to a customer, then the 439 two providers may assign the same RD for the customer or do RD 440 rewriting when re-advertising BIER prefixes from one provider to 441 another. 443 2.2. ISIS/OSPF Procedures 445 This document defines a new BIER Domain Sub-TLV of ISIS TLVs 135, 446 235, 236, and 237. The sub-TLV type is to be allocated. 448 This document also defines a new BIER Domain Sub-TLV of OSPF Extended 449 Prefix TLV. The sub-TLV type is to be allocated. 451 The value part of the BIER Domain Sub-TLV includes a 64-bit Route 452 Distinguisher followed by one or more BIER Info Sub-TLV (as defined 453 in [RFC8401] and [RFC8444] respectively) as its sub-sub-TLVs . 455 When a BFR redistribute a BIER prefix from BGP into ISIS/OSPF, if the 456 BGP advertisement is of BIER SAFI, a BIER Domain sub-TLV is attached, 457 with the RD part of the sub-TLV copied from the BGP advertisement. 458 For each BIER TLV in the BPA, a BIER Info sub-sub-TLV is added in the 459 BIER Domain sub-TLV, with the subdomain-id and BFR-id copied from the 460 corresponding BIER TLV in the BPA, and the Encapsulation sub-sub-sub- 461 TLV omitted because it is not needed. 463 If the BGP advertisement is of SAFI 1 or 2, BIER Info Sub-TLVs are 464 constructed as above directly, without using a BIER Domain sub-TLV. 466 When a BFR redistribute a BIER prefix from ISIS/OSPF into BGP, if 467 there is a BIER Domain sub-TLV in the corresponding ISIS LSP or OSPF 468 LSA, the BGP advertisement is of BIER SAFI and the RD part of the 469 NLRI is set to the RD from the BIER Domain sub-TLV. For each BIER 470 Info sub-sub-TLV in the BIER Domain sub-TLV, a BIER TLV is included 471 in the BPA, with the subdomain-id and BFR-id copied from the 472 corresponding BIER Info sub-sub-TLV. The MPLS Encapsulation sub-TLV 473 is omitted. The tunnel destination in the TEA is set to the BFR's 474 BIER prefix. 476 If there is no BIER Domain sub-TLV in the corresponding ISIS LSP or 477 OSPF LSA for the BIER Prefix, the BGP advertisement is of SAFI 1 or 478 2, and the BPA is constructed similar to the above (the only 479 difference is that in this case BIER Info sub-TLVs are not part of a 480 BIER Domain sub-TLV). 482 3. IANA Considerations 484 This document requests the following IANA assignments: 486 o A sub-TLV type for BIER Domain Sub-TLV from ISIS "Sub-TLVs for 487 TLVs 135, 235, 236, and 237" registry. 489 o A sub-TLV type for BIER Domain Sub-TLV from OSPFv2 Extended Prefix 490 Sub-TLV registry. 492 o A BIER SAFI from Subsequent Address Family Identifiers (SAFI) 493 registry. 495 4. Security Considerations 497 There are no security concerns wrt exchange of BIER information 498 besides what have been discussed in [I-D.ietf-bier-idr-extensions] 499 and [RFC8401] [RFC8444]. 501 The tunnels between BFRs that are not directly connected are ideally 502 auto-configured to reduce provisioning burdens. Given that they may 503 span multiple ASes and MPLS may not always be available, BIER over 504 UDP/GRE/IPv4/IPv6 becomes very convenient, though that has the same 505 security concerns well discussed in "Security Considerations" of 506 [RFC4023] and [RFC7510]. 508 As one mitigation when the tunnel is not secured, a BFR MAY use 509 source address filtering based on pre-provisioned or dynamically 510 learned allowable addresses. With dynamic learning, if a BFR 511 receives a BIER prefix with a BPA and a TEA (see Section 2.1), it 512 sets up a forwarding filter to allow IP/GRE/UDP tunneling from the 513 address encoded in the "Tunnel Egress Endpoint" sub-TLV of Tunnel 514 TLVs in the TEA. While that is the address for this BFR to tunnel 515 traffic to, this BFR will also likely receive tunneled traffic from 516 that address. 518 5. Contributors 520 The following people also contributed to this document. 522 Zheng Zhang 523 ZTE 524 zhang.zheng@zte.com.cn 526 Gyan Mishra 527 Verizon 528 Email: hayabusagsm@gmail.com 530 6. Acknowledgements 532 The authors thank Lenny Giuliano and Antoni Przygenda for their 533 review and suggestions. 535 7. References 537 7.1. Normative References 539 [I-D.ietf-bier-idr-extensions] 540 Xu, X., Chen, M., Patel, K., Wijnands, I., and A. 541 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 542 idr-extensions-07 (work in progress), September 2019. 544 [I-D.ietf-bier-prefix-redistribute] 545 Zhang, Z., Wu, B., Zhang, Z., Wijnands, I., and Y. Liu, 546 "BIER Prefix Redistribute", draft-ietf-bier-prefix- 547 redistribute-00 (work in progress), August 2020. 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, 551 DOI 10.17487/RFC2119, March 1997, 552 . 554 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 555 Zhang, "Bit Index Explicit Replication (BIER) Support via 556 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 557 . 559 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 560 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 561 Extensions for Bit Index Explicit Replication (BIER)", 562 RFC 8444, DOI 10.17487/RFC8444, November 2018, 563 . 565 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 566 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 567 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 568 2019, . 570 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 571 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 572 DOI 10.17487/RFC9012, April 2021, 573 . 575 7.2. Informative References 577 [I-D.ietf-bier-non-mpls-bift-encoding] 578 Wijnands, I., Mishra, M., Xu, X., and H. Bidgoli, "An 579 Optional Encoding of the BIFT-id Field in the non-MPLS 580 BIER Encapsulation", draft-ietf-bier-non-mpls-bift- 581 encoding-04 (work in progress), May 2021. 583 [I-D.ietf-bier-tether] 584 Zhang, Z., Warnke, N., Wijnands, I., and D. Awduche, 585 "Tethering A BIER Router To A BIER incapable Router", 586 draft-ietf-bier-tether-01 (work in progress), January 587 2021. 589 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 590 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 591 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 592 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 593 . 595 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 596 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 597 Explicit Replication (BIER)", RFC 8279, 598 DOI 10.17487/RFC8279, November 2017, 599 . 601 Authors' Addresses 603 Zhaohui Zhang 604 Juniper Networks 606 EMail: zzhang@juniper.net 608 Eric Rosen 609 Individual 611 EMail: erosen52@gmail.com 612 Daniel Awduche 613 Verizon 615 EMail: daniel.awduche@verizon.com 617 Liang Geng 618 China Mobile 620 EMail: gengliang@chinamobile.com 622 Greg Shepherd 623 Individual 625 EMail: gjshep@gmail.com