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