idnits 2.17.1 draft-ietf-bier-prefix-redistribute-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (23 December 2021) is 855 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) == Unused Reference: 'RFC7761' is defined on line 426, 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 (-04) exists of draft-ietf-bier-lsr-ethernet-extensions-02 == Outdated reference: A later version (-07) exists of draft-ietf-bier-ospfv3-extensions-05 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Z. Zhang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track B. Wu 5 Expires: 26 June 2022 Individual 6 Z. Zhang, Ed. 7 Juniper Networks 8 IJ. Wijnands 9 Cisco Systems, Inc. 10 Y. Liu 11 China Mobile 12 H. Bidgoli 13 Nokia 14 23 December 2021 16 BIER Prefix Redistribute 17 draft-ietf-bier-prefix-redistribute-01 19 Abstract 21 This document defines a BIER proxy function to support a single BIER 22 sub-domain over multiple underlay routing protocol regions 23 (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is 24 defined to redistribute BIER BFR-id information across the routing 25 regions. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC2119. 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 June 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 Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Multipe IGP domains . . . . . . . . . . . . . . . . . . . 3 69 2.2. Seamless MPLS Network . . . . . . . . . . . . . . . . . . 4 70 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Specifications . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. Redistribution of BIER Information . . . . . . . . . . . 5 73 4.2. BIER proxy range sub-TLV . . . . . . . . . . . . . . . . 6 74 4.3. BIRT/BIFT Calculation . . . . . . . . . . . . . . . . . . 7 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 8.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Appendix A. Proxy range sub-TLV usage . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Terminology 86 It is assumed that readers of this document are familiar with BIER 87 architecture [RFC8279] and OSPF/ISIS/BGP signaling for BIER 88 [RFC8401], [RFC8444], [I-D.ietf-bier-idr-extensions], 89 [I-D.ietf-bier-ospfv3-extensions]. The following terminologies are 90 listed for convenience. (to be added)... 92 2. Problem statement 94 BIER [RFC8279] is a new multicast architecture that does not need 95 per-tree state inside a network for multicast forwarding. BIER 96 forwarding state (which is not per-tree) is built according to a 97 routing underlay, which is defaulted to an IGP domain though not 98 limited to that. In this routin underlay, BIER information like 99 BIER-prefix, BFR-id, subdomain-id, and encapsulation is propagated 100 using IGP or BGP as specified in documents such as [RFC8401], 101 [RFC8444], [I-D.ietf-bier-idr-extensions], 102 [I-D.ietf-bier-ospfv3-extensions], 103 [I-D.ietf-bier-lsr-ethernet-extensions]. 105 In some deployment situations, different routing protocols may be 106 used in differet parts of a network yet there are just small number 107 of BFERs in each protocol domain, so a single BIER sub-domain is 108 desired. This requires BIER information redistribution among 109 different protocols, as described in the following two sections. 111 2.1. Multipe IGP domains 113 +----+ +----+ 114 +----+ R1 +-------------+ R2 +-----+ 115 | +----+ +----+ | 116 | OSPF / ISIS | 117 | domain 1 | 118 | | 119 | +----+ +----+ | 120 +-----+ +------------+ +-----+ 121 +------------+ R3 +---+ +---+ R4 +------------+ 122 | +----+ | | +----+ | 123 | OSPF | | OSPF | 124 | | | | 125 | domain 2 | | domain 3 | 126 | +----+ +----+ | | +----+ +----+ | 127 +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ 128 +----+ +----+ +----+ +----+ 129 Figure 1 131 While one could treat each IGP domain in the above network as a 132 separate BIER sub-domain, the border routers R3/R4 would need 133 decapsulate incoming BIER header in one BIER sub-domain, forward 134 based on flow overlay per-tree state, and re-ecapsulate with a BIER 135 header for forwarding in the next BIER sub-domain. This not only is 136 inefficient in forwarding, but also require per-tree state on the 137 border routers, which is undesired. 139 A better solution is to treat the entire network of multiple IGP 140 domains as single BIER sub-domain with a single routing underlay. 142 2.2. Seamless MPLS Network 144 Figure 1 could also depict a Seamless MPLS 145 [I-D.ietf-mpls-seamless-mpls] network, where BGP-LU [RFC8277] is used 146 to distribute routes for edge routers (e.g. R1/R2/Rm/Rn/Rx/Ry) among 147 the edge routers and border routers (e.g. R3/R4), but those routes 148 are not redistributed into other IGP areas/domains. With that, 149 internal routers in an area/domain will only have routes to local 150 nodes, yet they still need to build BIER forwarding state for BFERs 151 in other areas/domains. 153 3. Proposed Solution 155 For the multiple IGP domains scenario in Section 2.1, BIER 156 information from one domain needs to be redistributed into another 157 domain, like that BIER information is redistributed from one IGP area 158 to another as specified in [RFC8401], [RFC8444], and 159 [I-D.ietf-bier-ospfv3-extensions]. 161 Specifically, when an ASBR redistributes BIER prefixes for BFERs from 162 one protocol domain to another, BIER information is also 163 redistributed except the encapsulation information (because BFRs in 164 one domain will not directly send BIER packets to BFRs in the other 165 domain so only the BFR-IDs of the BFERs matters). When BIER prefixes 166 for non-BFIR/BFER (i.e. whose BFR-ID is 0) are redistributed, BIER 167 information is not redistributed. 169 If route summarization is used, because a summarized prefix may cover 170 many BFERs, the BFR-IDs of those covered BFERs needs to be explicitly 171 listed in proxy range sub-TLV (see Section 4.2). In case of Seamless 172 MPLS (Section 2.2), when a border router advertise BIER information 173 for itself in one area/domain, it also explicitly lists the BFIRs/ 174 BFERs in other areas/domains that are reachable via itself in the 175 proxy range sub-TLV. 177 In figure 1, R3/R4 connects two routing domains. After R3 receives 178 BIER information for Rm/Rn from domain 2 and redistribute to domain 179 1, BFRs in domain 1 can build BIER forwarding state for BFERs in 180 domain 2 through R3. Similarly, R3 receives BIER information for R1/ 181 R2 from domain 1 and redistribute into domain 2. BFRs in domain 2 182 can build BIER forwarding state for BFERs in domain 1 through R3. 184 For example, in this network, suppose that Rm and Rn have the prefix 185 of 201.1.1.1/32, 201.1.1.2/32. In order to build one BIER sub-domain 186 which includes these three IGP domains, R3 advertises the BFR-ids of 187 Rm/Rn with associated prefixes (201.1.1.1/32, 201.1.1.2/32) into the 188 upper domain. Similarly, R4 advertises the BFR-ids of Rx/Ry with 189 associated prefixes (202.1.1.1/32, 202.1.1.2/32) into the upper 190 domain too. 192 And R3/R4 advertises the prefixes of R1 and R2 (suppose that the 193 prefixes are 200.1.1.1/32 and 200.1.1.2/32) with associated BFR-ids 194 into IGP domain 1 and domain 2. Also, R3 advertises the prefixes 195 learned from R4 (202.1.1.1/32, 202.1.1.2/32) with associated BFR-ids 196 into IGP domain 1. R4 also advertises the prefixes (201.1.1.1/32, 197 201.1.1.2/32) with associated BFR-ids into IGP domain 2. 199 Obviously, in order to build the large BIER sub-domain, the BFR-id of 200 edge router in each IGP domain MUST NOT overlap. 202 4. Specifications 204 4.1. Redistribution of BIER Information 206 Consider a BIER sub-domain that spans multiple routing domains. The 207 procedures in this section apply if a border router, which is also a 208 BFR, redistribute routing information from one routing domain into 209 another. 211 If a redistributed route is for a host route for a BFIR/BFER (i.e. 212 the BFR-ID is not zero) in the same sub-domain, BIER information for 213 the BFIR/BFERs MUST be advertised in the target routing domain as 214 following: 216 * If the target routing domain is OSPFv2, a BIER Sub-TLV [RFC8444] 217 is attached to the OSPFv2 Extended Prefix TLV in the OSPFv2 218 Extended Prefix Opaque LSA [RFC7684] corresponding to the 219 redistributed host route. 221 * If the target routing domain is OSPFv3, a BIER Sub-TLV 222 [I-D.ietf-bier-ospfv3-extensions] is attached to the OSPFv3 223 Extended LSA TLVs in the Intra-Area-Prefix TLV [RFC8362]. 224 corresponding to the redistributed host route. 226 * If the target routing domain is ISIS, a BIER Info Sub-TLV 227 [RFC8401] is attached to the TLVs of 235, 237, [RFC5120], 135 228 [RFC5305], or 236 [RFC5308]. 230 * If the target routing domain is BGP, a BIER TLV 231 [I-D.ietf-bier-idr-extensions] is attached to BGP Path Attribute. 233 The BIER Sub-TLV (in case of OSPF2 and OSPFv3), BIER Info Sub-TLV (in 234 case of IS-IS) and BIER TLV (in case of BGP) are encoded as specified 235 in [RFC8444], [I-D.ietf-bier-ospfv3-extensions], and [RFC8401], and 236 [I-D.ietf-bier-idr-extensions]. The encapsulation sub-TLV SHOULD NOT 237 be included because it would not be used. 239 If a redistributed route is for a host route for a transit BFR (i.e. 240 the BFR-ID is zero), BIER information for the BFR SHOULD NOT be 241 redistributed, because it would not be used. 243 If the redistributed route is a summary or default route, and it 244 covers some BFIR/BFERs, a BIER Sub-TLV (for OSPFv2 and OSPFv3), or a 245 BIER Info Sub-TLV (in case of IS-IS), or a BIER TLV (in case of BGP) 246 MUST be used to advertise the covered BFIRs/BFERs via the BIER proxy 247 range sub-TLV as specified in the following section. 249 4.2. BIER proxy range sub-TLV 251 The BIER Sub-TLV can include a proxy range sub-TLV, which lists 252 BFIRs/BFERs covered by a summary/default route or reachable via a 253 BFR. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type | Length | subdomain-id | resv | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | BFR-id | BFR-id range | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | ... | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | BFR-id | BFR-id range | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 figure 2 268 * Type: 8-bit unsigned integer. TBD to indicate the BIER proxy 269 range sub-TLV. 271 * Length: 8-bit unsigned integer. Length of the BIER proxy range 272 sub-TLV in 4-octet units, not including the first 4 octets. 274 * Subdomain-id: 8-bit unsigned integer. 276 * resv: 16-bit unsigned integer. The reserved field. 278 * BFR-id: 16-bit unsigned integer. The first BFR-id from original 279 advertisement. 281 * BFR-id range: 16-bit unsigned integer. The range of BFR-ids with 282 one subdomain-id. 284 The BIER proxy range sub-TLV is included in the BIER Sub-TLV for an 285 aggregated/summary route prefix or default route prefix, or in the 286 BIER Sub-TLV for a BIER prefix (for a border router in a Seamless 287 MPLS network). Multiple BIER proxy range sub-TLVs MAY be included in 288 the BIER Sub-TLV. 290 The range in the BIER proxy range sub-TLV can be as granular as to 291 advertise individual BFR-ids. Though a larger range can increase 292 advertisement efficiency, that requires careful planning for BFR-id 293 assignment. 295 When the proxy range sub-TLV is used, the mapping between a BIER 296 prefix and its BFR-id is no longer conveyed in the routing underlay. 297 As a result, the mapping must be provided by other means, e.g. in the 298 multicast overlay. 300 4.3. BIRT/BIFT Calculation 302 If a BFR receives a BIER prefix whose BIER Sub-TLV includes a proxy 303 range sub-TLV (i.e., the Seamless MPLS scenario), it treats as if 304 that the originator advertised a default route with the proxy range 305 sub-TLV. Note that this imaginary default route is only for the 306 purpose of building BIRT/BIFT entries and not used for unicast 307 forwarding. 309 With the BIER prefixes originated in the local routing area/domain, 310 the BIER prefixes and summary/default routes redistributed into the 311 local routing area/domain, and the imaginary default route mentioned 312 above, a BFR builds BIRTs as specified in [RFC8279] with entries 313 including host/summary/default prefixes. 315 BIFT entries are then derived from a corresponding BIRT. For a BFER 316 covered by the proxy range sub-TLVs associated with the summary/ 317 default prefixes (whether or not the deafult prefix is the imaginary 318 one as mentioned above), its BIFT entry is derived from the summary/ 319 default prefix entry in the BIRT. It is possible that a BFER is 320 covered in the proxy range sub-TLV of multiple default/summary 321 routes. In that case, ECMP MAY be used and longest match SHOULD be 322 used. For example, if ABR1 advertises default/summary route P1 while 323 ABR2 advertises a more specific summary route P2 and both have a 324 proxy range sub-TLV that covers BFR-ID 100, then the BIFT entry for 325 BFR-ID 100 should follow the P2 route in BIRT. 327 With this scheme, even though the BIER prefixes are not advertised 328 into the IGP for an area/domain in a Seamless MPLS network and 329 unicast traffic for those BIER prefixes are tunneled through, 330 corresponding BIFT entries are maintained inside the area/domain for 331 the purpose of efficient BIER forwarding. Otherwise, BIER forwarding 332 through the area/domain would be tunneled just like unicast case. 334 5. IANA Considerations 336 IANA is requested to set up a new types of sub-TLV (TLV) registry 337 value for BIER proxy range advertisement in OSPF, ISIS, BGP, etc. 339 6. Security Considerations 341 Implementations must assure that malformed TLV and Sub-TLV 342 permutations do not result in errors which cause hard protocol 343 failures. 345 7. Acknowledgements 347 The authors would like to thank Stig Venaas for his valuable comments 348 and suggestions. 350 8. References 352 8.1. Normative References 354 [I-D.ietf-bier-idr-extensions] 355 Xu, X., Chen, M., Patel, K., Wijnands, I., and A. 356 Przygienda, "BGP Extensions for BIER", Work in Progress, 357 Internet-Draft, draft-ietf-bier-idr-extensions-07, 6 358 September 2019, . 361 [I-D.ietf-bier-lsr-ethernet-extensions] 362 Dhanaraj, S., Yan, G., Wijnands, I., Psenak, P., Zhang, 363 Z., and J. Xie, "LSR Extensions for BIER over Ethernet", 364 Work in Progress, Internet-Draft, draft-ietf-bier-lsr- 365 ethernet-extensions-02, 2 December 2020, 366 . 369 [I-D.ietf-bier-ospfv3-extensions] 370 Psenak, P., Nainar, N. K., and I. Wijnands, "OSPFv3 371 Extensions for BIER", Work in Progress, Internet-Draft, 372 draft-ietf-bier-ospfv3-extensions-05, 19 November 2021, 373 . 376 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 377 Topology (MT) Routing in Intermediate System to 378 Intermediate Systems (IS-ISs)", RFC 5120, 379 DOI 10.17487/RFC5120, February 2008, 380 . 382 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 383 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 384 2008, . 386 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 387 DOI 10.17487/RFC5308, October 2008, 388 . 390 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 391 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 392 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 393 2015, . 395 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 396 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 397 Explicit Replication (BIER)", RFC 8279, 398 DOI 10.17487/RFC8279, November 2017, 399 . 401 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 402 F. Baker, "OSPFv3 Link State Advertisement (LSA) 403 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 404 2018, . 406 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 407 Zhang, "Bit Index Explicit Replication (BIER) Support via 408 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 409 . 411 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 412 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 413 Extensions for Bit Index Explicit Replication (BIER)", 414 RFC 8444, DOI 10.17487/RFC8444, November 2018, 415 . 417 8.2. Informative References 419 [I-D.ietf-mpls-seamless-mpls] 420 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 421 M., and D. Steinberg, "Seamless MPLS Architecture", Work 422 in Progress, Internet-Draft, draft-ietf-mpls-seamless- 423 mpls-07, 28 June 2014, . 426 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 427 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 428 Multicast - Sparse Mode (PIM-SM): Protocol Specification 429 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 430 2016, . 432 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 433 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 434 . 436 Appendix A. Proxy range sub-TLV usage 438 This appendix is to make the function understood more easily. Except 439 for inter-area case, the function is also suitable for inter-as case. 440 In the same example of figure 1, in case there are 40 edge routers in 441 domain 1, the BFR-ids of domain 1 start from 51 to 90, and the 442 prefixes of these routers start from 201.1.1.1/32 to 201.1.1.40/32. 443 These assigned BFR-IDs are not overlapped with the BFR-IDs in any 444 other domain. 446 In order to build a BIER sub-domain across these areas, the two 447 advertisement methods defined in Section 4.2 can be used: 449 * As a transit node, R3 advertises the BIER sub-TLV with BFR-ID set 450 to 0. When R3 is not allowed to advertise the summary or specific 451 prefixes into the upper domain, R3 can advertise the proxy range 452 sub-TLV with the host prefix directly. So there are two sub-TLVs 453 advertisement associated with the host prefix of R3. 455 * As a transit node, R3 advertises the BIER sub-TLV with BFR-ID set 456 to 0. When R3 is allowed to advertise the summary prefix into the 457 upper domain, R3 can advertise the proxy range sub-TLV with the 458 summarized prefix, 201.1.1.0/24, with the BFR-id set to 51, the 459 BFR-id range set to 40, into the upper domain. In this case, 460 there are two prefixes advertised by R3. But the summary prefix 461 can not be used to encapsulate BIER packet directly in case of 462 tunneling case. The summary prefix is only used to generate the 463 BIFT. 465 Then the router in the uppler domain can build the BIER forwarding 466 table, the nexthops of BFR-IDs in the proxy range sub-TLV are set to 467 R3. 469 The same function is also applied to R4 when it advertises the BFR- 470 IDs to the upper domain. This method is also applied to R3/R4 when 471 it advertises the BFR-IDs to the lower domain. When R3 advertises 472 the prefixes from the upper domain and domain 2 into domain 1, except 473 the host prefix of R3 with BFR-ID set to 0, R3 may advertise only one 474 default route (0.0.0.0/0) into domain 1 if one or more continuous 475 BFR-id range can be attached. Suppose that the BFR-id in the upper 476 domain starts from 1001 to 1050, the BFR-id in domain 2 starts from 477 201 to 250, and these ranges are not overlapped with the ranges in 478 any other domain. Suppose that the sub-domain ID is 1, the BIER 479 proxy range sub-TLV may be advertised like this: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | TBD | 2 | 1 | 0 | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | 1001 | 50 | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | 201 | 50 | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 figure 3 492 Then the BIER overlay is built among R1, R2, Rm, Rn, Rx and Ry. R3 493 and R4 need not maintain the multicast overlay states. The optimized 494 summary/ aggregated or default prefix can be generated by the 495 operation policy which is configured by the network administrator. 497 If two or more ABRs in one domain are used to reistribute the prefix, 498 for example in figure 4 below: 500 +-------------------------------------------------------+ 501 | +----+ +----+ BIER | 502 | +-----------+ R1 +-------------+ R2 +-----+ domain 1 | 503 | | +----+ +----+ | | 504 | | OSPF/ISIS | | 505 | | | | 506 | | +----+ +----+ +----+ | | 507 | +--+ +----+ +------------+ +-----+ | 508 | +--+ R5 +----+ R3 +---+ +---+ R4 +------------+ | 509 | | +----+ +----+ | | +----+ | | 510 | | | | | | 511 | | OSPF domain 1 | | OSPF domain 2 | | 512 | | | | | | 513 | | +----+ +----+ | | +----+ +----+ | | 514 | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | 515 | +----+ +----+ +----+ +----+ | 516 +-------------------------------------------------------+ 517 Figure 4 519 As the ABRs, except the host prefixes of R3 and R5 advertisement, R3 520 and R5 can both advertise the proxy range sub-TLV with their host 521 prefix, the routers can select one of them as the nexthop, or select 522 both of them for ECMP. 524 If R3 and R5 are allowed to advertise the summary prefix received 525 from the upper domain. They can advertise the same summary prefixes 526 or the different prefixes according to the operation policy. When 527 they advertise the same summary prefixes, the R3 and R5 can also be 528 used for ECMP. When they advertise the different summary prefixes, 529 the more specific prefixes are used to generate the BIER forwarding 530 table. Whatever the same or different prefixes are advertised, the 531 nexthop is set to R3/R5. 533 In case the range of BFR-ids in one domain is overlapped with the 534 BFR-ids in any other domain, the proxy range sub-TLV may not be used. 535 In the same example above, if the BFR-ids in domain 1 are 21, 31, 41, 536 etc., the BFR-ids in domain 2 are 22, 32, 42, etc., even if the 537 summarized prefixes are not overlapped with the prefixes in any other 538 domain, when R3 advertises the summarized prefixes in domain 1 into 539 the upper domain, the proxy range sub-TLV may not optimize the 540 advertisement. 542 After the forwarding plane is built, the nexthop of the range BFR-IDs 543 is set to the ABR router. For example, when R1 receives multicast 544 packet, and the receivers of this flow are connected by Rm and Rx, R1 545 encapsulates BIER header in front of the flow packet with BFR-ids set 546 to Rm and Rx. The routers in the upper domain forward the packet to 547 the ABR routers: R3, R4 and R5. When R3/R4/R5 receives the packet, 548 R3/R4/R5 needs not decapsulate and re-encapsulate the packet. R3/R4/ 549 R5 just forwards the packet according to the BIER forwarding table. 550 Similar with the upper domain, the routers in lower domain forward 551 the packet to the edge routers: Rm and Rx. When the packet reaches 552 Rm and Rx, Rm and Rx remove the BIER header and forward it to 553 receivers. 555 Authors' Addresses 557 Zheng(Sandy) Zhang 558 ZTE Corporation 560 Email: zhang.zheng@zte.com.cn 562 Bo Wu 563 Individual 565 Email: w1973941761@163.com 567 Zhaohui Zhang (editor) 568 Juniper Networks 570 Email: zzhang@juniper.net 572 IJsbrand Wijnands 573 Cisco Systems, Inc. 575 Email: ice@cisco.com 577 Yisong Liu 578 China Mobile 580 Email: liuyisong.ietf@gmail.com 582 Hooman Bidgoli 583 Nokia 585 Email: hooman.bidgoli@nokia.com