idnits 2.17.1 draft-zwzw-bier-prefix-redistribute-07.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 (July 12, 2020) is 1356 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) == Outdated reference: A later version (-10) exists of draft-ietf-bier-idr-extensions-07 == Outdated reference: A later version (-07) exists of draft-ietf-bier-ospfv3-extensions-02 Summary: 1 error (**), 0 flaws (~~), 3 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: January 13, 2021 Individual 6 Z. Zhang 7 Juniper Networks 8 IJ. Wijnands 9 Cisco Systems, Inc. 10 Y. Liu 11 China Mobile 12 July 12, 2020 14 BIER Prefix Redistribute 15 draft-zwzw-bier-prefix-redistribute-07 17 Abstract 19 This document defines a BIER proxy function to interconnect different 20 underlay routing protocol areas in a network. And a new BIER proxy 21 range sub-TLV is also defined to convey BIER BFR-id information 22 across the routing areas. 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 January 13, 2021. 47 Copyright Notice 49 Copyright (c) 2020 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. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. BIER proxy range sub-TLV . . . . . . . . . . . . . . . . 7 68 3.2. Proxy range sub-TLV usage . . . . . . . . . . . . . . . . 9 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 7.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Problem statement 78 +-------------------------------------------------------+ 79 | +----+ +----+ PIM | 80 | +----+ R1 +-------------+ R2 +-----+ | 81 | | +----+ +----+ | | 82 | | | | 83 | | OSPF area 0 / ISIS | | 84 | | | | 85 | | +----+ +----+ | | 86 | +-----+ +------------+ +-----+ | 87 | +------------+ R3 +---+ +---+ R4 +------------+ | 88 | | +----+ | | +----+ | | 89 | | | | | | 90 | | OSPF area 1 | | OSPF area 2 | | 91 | | | | | | 92 | | +----+ +----+ | | +----+ +----+ | | 93 | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | 94 | +----+ +----+ +----+ +----+ | 95 +-------------------------------------------------------+ 96 Figure 1 98 Figure 1 shows that there are three areas in a traditional network. 99 In some deployment situations, different routing protocols may also 100 be used in the network. There are just small amount of routers in 101 each area. Currently, multicast services are provided in this kind 102 of network by using protocol independent feature of PIM [RFC7761]. 104 BIER could be a candidate multicast protocol to replace PIM to reduce 105 multicast states in the network. BIER [RFC8279] is a new 106 architecture for the forwarding of multicast data packets. It does 107 not require a protocol for explicitly building multicast distribution 108 trees, nor does it require intermediate nodes to maintain any per- 109 flow state. In order to build BIER forwarding plane, BIER key 110 parameters must be flooded in one BIER domain such as BFR-prefix, 111 BFR-id, subdomain-id, and so on. The routing protocols which are 112 used to flood these BIER parameters are called BIER routing underlay. 113 The associated routing protocol extensions are defined in documents 114 such as [RFC8401], [RFC8444], [I-D.ietf-bier-idr-extensions], 115 [I-D.ietf-bier-ospfv3-extensions], and so on. 117 +----+ +----+ 118 +----+ R1 +-------------+ R2 +-----+ 119 | +----+ +----+ | 120 | OSPF / ISIS | 121 | BIER domain 1 | 122 | | 123 | +----+ +----+ | 124 +-----+ +------------+ +-----+ 125 +------------+ R3 +---+ +---+ R4 +------------+ 126 | +----+ | | +----+ | 127 | OSPF | | OSPF | 128 | | | | 129 | BIER domain 2 | | BIER domain 3 | 130 | +----+ +----+ | | +----+ +----+ | 131 +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ 132 +----+ +----+ +----+ +----+ 133 Figure 2 135 Based on the BIER design, a BIER domain is limited by the underlay 136 routing protocols flooding scope. In case we want deploy BIER 137 instead of PIM, there are several BIER domains because of different 138 underlay routing areas limitation. Multiple encapsulating/ 139 decapsulation executions are needed to across multiple BIER domains. 140 These executions slow down the forwarding efficiency. The border 141 routers also need to maintain overlay state, which is undesired. 143 For example in figure 2, suppose that R1 and R2 connect with 144 multicast source. Rm, Rn, Rx and Ry connect with multicast 145 receivers. According the existed advertisement method defined in 146 [RFC8401], [RFC8444], and so on, in BIER domain 1, R1, R2, R3 and R4 147 are BIER edge routers. In BIER domain 2, R3 and Rm, Rn are BIER edge 148 routers. In BIER domain 3, R4 and Rx, Ry are BIER edge routers. 150 R1/R2 encapsulates BIER packet when multicast flows come into this 151 BIER domain, R3/R4 decapsulates the BIER packet, and encapsulates 152 them again, sends them into BIER domain 2/3. Rm, Rn, Rx and Ry 153 decapsulates the packets and forwards them to receivers. 155 Due to the decapsulation and encapsulation execution in R3 and R4, 156 the forwarding efficiency is slowed down, especially when there are 157 not large amount of routers in each BIER domain. 159 Section 2.3 in [RFC8444] defines the duplication function across OSPF 160 areas. Except the homogenization network, there is the hybrid 161 network showed in figure 2 that several areas formed by different IGP 162 protocols, and they are need to be merged into one BIER domain. In 163 the hybrid network, necessary advertisement transform need to be 164 used. And further, necessary optimization method can be used to 165 reduce the amount of the advertisement items. 167 2. Proposal 169 +-------------------------------------------------------+ 170 | +----+ +----+ BIER | 171 | +----+ R1 +-------------+ R2 +-----+ domain 1 | 172 | | +----+ +----+ | | 173 | | OSPF/ISIS | | 174 | | | | 175 | | +----+ +----+ | | 176 | +-----+ +------------+ +-----+ | 177 | +------------+ R3 +---+ +---+ R4 +------------+ | 178 | | +----+ | | +----+ | | 179 | | | | | | 180 | | OSPF area 1 | | OSPF area 2 | | 181 | | | | | | 182 | | +----+ +----+ | | +----+ +----+ | | 183 | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | 184 | +----+ +----+ +----+ +----+ | 185 +-------------------------------------------------------+ 186 Figure 3 188 It is more efficient to deploy BIER by creating one BIER domain for 189 the hybrid network to achieve forwarding benefit. 191 Since the limitation of the BIER routing protocol scope, BFR-id is 192 confined to only one routing area. A BIER proxy function is 193 introduced to transport BIER BFR-id information in a BIER domain 194 across multiple routing protocol areas. So BIER forwarding tables 195 can be built across multiple underlay routing protocols to replace 196 encapsulation/ decapsulation processing. In the current deployment, 197 border router (ABR) has a similar role, ABR summaries unicast routing 198 information from one routing protocol area and sends it to another 199 routing area by new routing protocol messages. So ABR can implement 200 BIER proxy function to summarize BIER BFR-id information from one 201 routing protocol area and sends it to another routing area. 203 In figure 3, R3/R4 connects two areas which running same or different 204 routing protocols, they can be used as BIER proxies to transport BIER 205 information. For example, after R3 receives BFR-ids information from 206 OSPF area 1 and sends it to ISIS routing area (the upper area), the 207 routers in ISIS routing area can generate BIER forwarding items 208 toward the BFR-ids in OSPF area 1 through R3. Similarly, R3 receives 209 BFR-ids information from the upper area and sends them into OSPF area 210 1, the routers in OSPF area 1 can build BIER forwarding items toward 211 the BFR-ids in ISIS area. R4 does the same function, the BIER 212 forwarding plane is constructed accordingly. 214 For example, in this network, suppose that Rm and Rn have the prefix 215 of 201.1.1.1/32, 201.1.1.2/32. In order to build one BIER domain 216 which includes these three IGP areas, R3 advertises the BFR-ids of 217 Rm/Rn with associated prefixes (201.1.1.1/32, 201.1.1.2/32) into the 218 upper area. Similarly, R4 advertises the BFR-ids of Rx/Ry with 219 associated prefixes (202.1.1.1/32, 202.1.1.2/32) into the upper area 220 too. 222 And R3/R4 advertises the prefixes of R1 and R2 (suppose that the 223 prefixes are 200.1.1.1/32 and 200.1.1.2/32) with associated BFR-ids 224 into IGP area 1 and area 2. Also, R3 advertises the prefixes learned 225 from R4 (202.1.1.1/32, 202.1.1.2/32) with associated BFR-ids into IGP 226 area 1. R4 also advertises the prefixes (201.1.1.1/32, 201.1.1.2/32) 227 with associated BFR-ids into IGP area 2. 229 After the path calculation, the BIER forwarding plane is built. When 230 R1/R2 receives multicast packet which should be sent to Rm/Rn/Rx/Ry, 231 R1/R2 encapsulates the packet with BIER header and send it into the 232 upper area. When R3/R4 receives the packet, R3/R4 forwards the 233 packet into IGP area 1 and area 2 according to the BIER forwarding 234 table without doing the decapsulation and re-encapsulation actions. 236 Obviously, in order to build the large BIER domain, the BFR-id of 237 edge router in each IGP area MUST NOT be overlapped. 239 3. Advertisement 241 According to [RFC8279], each BFER needs to have a unique (in each 242 sub-domain) BFR-id, and each BFR and BFER floods itself BIER info 243 sub-TLV and associated sub-sub-TLVs in the BIER domain. To keep 244 consistent with the definition in [RFC8444], 245 [I-D.ietf-bier-ospfv3-extensions], and [RFC8401], BIER info sub-TLV 246 defined in [RFC8401] and BIER sub-TLV defined in [RFC8444], 247 [I-D.ietf-bier-ospfv3-extensions] is reused to convey the BFR-id 248 information. OSPF extended Prefix Opaque LSA [RFC7684] and TLVs 235, 249 237 defined in [RFC5120], or TLVs 135 [RFC5305], or TLV 236 [RFC5308] 250 are still used to carry the BFR-id/ BFR-prefix information, etc. 252 The key parameters got from the original routing protocol should be 253 adapted to the format of next routing protocol, such as BFR-prefix, 254 BFR-id, subdomain-id, and so on. Some parameters like BAR, MT-ID has 255 local significance, So they should be set to same values with BIER 256 proxy own advertisement when BIER proxy advertise them to the next 257 routing area. 259 And as the two BIER info sub-sub-TLVs (sub-TLVs) including MPLS 260 encapsulation and BSL conversion also have local significance. The 261 information carried in these two sub-sub-TLV need not, but MAY, be 262 advertised to next routing area. 264 In the same example, when R3 advertises the prefixes of Rm and Rn 265 into the upper area, R3 may advertise the prefixes one by one, that 266 is R3 advertises 201.1.1.1/32 with associated BFR-id, and R3 267 advertises 201.1.1.2/32 with associated BFR-id. If there is dozens 268 of edge routers in area 1, R3 advertises dozens of prefixes and 269 associated BFR-ids into the upper area. When R3 advertises the 270 prefixes from the upper area into area 1, R3 advertises the prefixes 271 of R1 and R2 with associated BFR-ids separately, and R3 advertises 272 the prefixes of Rx and Ry which come from R4 into area 1 one by one. 273 R4 does it as well. 275 3.1. BIER proxy range sub-TLV 277 In some cases unicast default route and aggregated/ summarized routes 278 are used in some routing areas and routers in next area can not see 279 the specific BFR-prefix routes from original area. Like in figure 3, 280 in case R3/R4 does not advertise specific ISIS unicast routes to OSPF 281 area and only advertises unicast default route or aggregated/ 282 summarized route to OSPF area 1/2, when R3/R4 advertises BIER info 283 sub-TLV to OSPF area 1/2, R3 MUST advertise the prefix with default 284 route or aggregated/ summarized route. In that case, multiple BFR- 285 ids will be mapped to one prefix. In order to advertise BFR-ids 286 optimally, we define a new BIER proxy range sub-TLV to advertise the 287 information of BFR-ids. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type | Length | subdomain-id | resv | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | BFR-id | BFR-id range | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | ... | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | BFR-id | BFR-id range | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 figure 4 302 o Type: 8-bit unsigned integer. TBD to indicate the BIER proxy 303 range sub-TLV. 305 o Length: 8-bit unsigned integer. Length of the BIER proxy range 306 sub-TLV in 4-octet units, not including the first 4 octets. 308 o Subdomain-id: 8-bit unsigned integer. The subdomain-id from 309 original advertisement. 311 o resv: 8-bit unsigned integer. The reserved field. 313 o BFR-id: 16-bit unsigned integer. The first BFR-id from original 314 advertisement. 316 o BFR-id range: 16-bit unsigned integer. The range of BFR-ids with 317 one subdomain-id. 319 The BIER proxy range sub-TLV is attached to the aggregated/ 320 summarized route prefix or default route prefix. The summarized/ 321 aggregated/ default prefix may need multiple BIER proxy range sub- 322 TLVs when the BFR-ids covered by the prefix are allocated from 323 different ranges (even if they're from a single range but some BFR- 324 ids in the range map to the BIER prefixes that are covered by a 325 different summarized/ aggregated prefix, then that single large range 326 needs to be broken into smaller ranges). 328 When a BFR receives a default/summary route with a BIER proxy range 329 sub-TLV, it builds a BIRT route with that default/summary prefix. It 330 also builds multiple BIFT entries for each BFR-IDs covered in the 331 proxy range sub-TLV, using the same forwarding information as in the 332 BIRT route. It is possible that a BFR-ID is covered in the proxy 333 range sub-TLV of multiple default/summary routes. In that case, ECMP 334 can be used and longest match SHOULD be used. For example, if ABR1 335 advertises default/summary route P1 while ABR2 advertises a more 336 specific summary route P2 and both have a proxy range sub-TLV that 337 covers BFR-ID 100, then the BIFT entry for BFR-ID 100 only follows 338 the P2 route in BIRT. 340 The proxy range sub-TLV can also be attached to a host BIER prefix 341 itself. Consider the situation where BGP-LU [RFC8277] is used for a 342 seamless MPLS [I-D.ietf-mpls-seamless-mpls] environment. An ABR/ASBR 343 advertises BIER prefixes via BGP over an area/AS to other ABR/ASBRs 344 but the BIER prefixes are not advertised into the IGP for the area/ 345 AS. The ABR/ASBR does advertise the BIER prefix for itself into the 346 IGP for the area/AS, with a BIER proxy range sub-TLV to cover the 347 BFR-IDs for BFRs that the ABR/ASBR has learned (either through IGP or 348 through BGP signaling). When an internal BFR receives it, it treats 349 as if a default summary route had been received with the proxy range 350 sub-TLV. Note that this imaginary default summary route is only for 351 the purpose of building BIRT/BIFT entries and not used for unicast 352 forwarding. 354 With this scheme, even though the BIER prefixes are not advertised 355 into the IGP for the area/AS and unicast traffic for those BIER 356 prefixes are tunneled through, corresponding BIFT entries are 357 maintained inside the area/AS for the purpose of efficient BIER 358 forwarding. Otherwise, BIER forwarding through the area/AS would be 359 tunneled just like unicast case. 361 The range in the BIER proxy range sub-TLV can be as granular as to 362 advertise individual BFR-ids. Though a larger range can increase 363 advertisement efficiency, it requires careful planning for BFR-id 364 assignment. 366 When the proxy range sub-TLV is used, the mapping between a BIER 367 prefix and its BFR-id is no longer conveyed in the routing underlay. 368 As a result, the mapping must be provided by other means, e.g. in the 369 multicast overlay. 371 3.2. Proxy range sub-TLV usage 373 In the same example of figure 3, in case there are 40 edge routers in 374 area 1, the BFR-ids of area 1 start from 51 to 90, and the prefixes 375 of these routers start from 201.1.1.1/32 to 201.1.1.40/32. These 376 prefixes are not overlapped with the prefixes in any other area. 378 When R3 advertises these prefixes into the upper area, the proxy 379 range sub-TLV can be used to optimize the advertisement. That is R3 380 can advertise only one prefix 201.1.1.0/24, with the BFR-id set to 381 51, the BFR-id range set to 40, into the upper area. Then the BIER 382 overlay is built among R1, R2, Rm, Rn, Rx and Ry. R3 and R4 need not 383 maintain the multicast overlay states. 385 When R3 advertises the prefixes from the upper area and area 2 into 386 area 1, R3 may advertise only one default route (0.0.0.0/0) into area 387 1 if one or more continuous BFR-id range can be attached. Suppose 388 that the BFR-id in the upper area starts from 1001 to 1050, the BFR- 389 id in area 2 starts from 201 to 250, and these ranges are not 390 overlapped with the ranges in any other area. Suppose that the sub- 391 domain ID is 1, the BIER proxy range sub-TLV may be advertised like 392 this: 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | TBD | 2 | 1 | 0 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | 1001 | 50 | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | 201 | 50 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 figure 5 405 The optimized summary/ aggregated or default prefix can be generated 406 by the operation policy which is configured by the network 407 administrator. 409 In case the range of BFR-ids in one area is overlapped with the BFR- 410 ids in any other area, the proxy range sub-TLV can not be used. In 411 the same example above, if the BFR-ids in area 1 are 21, 31, 41, 412 etc., the BFR-ids in area 2 are 22, 32, 42, etc., even if the 413 summarized prefixes are not overlapped with the prefixes in any other 414 area, when R3 advertises the summarized prefixes in area 1 into the 415 upper area, the proxy range sub-TLV may not optimize the 416 advertisement. 418 After the forwarding plane is built, when R1 receives multicast 419 packet, and the receivers of this flow are connected by Rm and Rx, R1 420 encapsulates BIER header in front of the flow packet with BFR-ids set 421 to Rm and Rx. When R3/R4 receives the packet, R3/R4 need not 422 decapsulate and re-encapsulate the packet. R3/R4 just forwards the 423 packet according to the BIER forwarding table. When the packet 424 reaches Rm and Rx, Rm and Rx remove the BIER header and forward it to 425 receivers. 427 4. IANA Considerations 429 IANA is requested to set up a new types of sub-TLV (TLV) registry 430 value for BIER proxy range advertisement in OSPF, ISIS, BGP, etc. 432 5. Security Considerations 434 Implementations must assure that malformed TLV and Sub-TLV 435 permutations do not result in errors which cause hard protocol 436 failures. 438 6. Acknowledgements 440 The authors would like to thank Stig Venaas for his valuable comments 441 and suggestions. 443 7. References 445 7.1. Normative References 447 [I-D.ietf-bier-idr-extensions] 448 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 449 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 450 idr-extensions-07 (work in progress), September 2019. 452 [I-D.ietf-bier-ospfv3-extensions] 453 Psenak, P., Nainar, N., and I. Wijnands, "OSPFv3 454 Extensions for BIER", draft-ietf-bier-ospfv3-extensions-02 455 (work in progress), May 2020. 457 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 458 Topology (MT) Routing in Intermediate System to 459 Intermediate Systems (IS-ISs)", RFC 5120, 460 DOI 10.17487/RFC5120, February 2008, 461 . 463 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 464 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 465 2008, . 467 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 468 DOI 10.17487/RFC5308, October 2008, 469 . 471 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 472 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 473 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 474 2015, . 476 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 477 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 478 Explicit Replication (BIER)", RFC 8279, 479 DOI 10.17487/RFC8279, November 2017, 480 . 482 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 483 Zhang, "Bit Index Explicit Replication (BIER) Support via 484 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 485 . 487 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 488 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 489 Extensions for Bit Index Explicit Replication (BIER)", 490 RFC 8444, DOI 10.17487/RFC8444, November 2018, 491 . 493 7.2. Informative References 495 [I-D.ietf-mpls-seamless-mpls] 496 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 497 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 498 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 500 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 501 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 502 Multicast - Sparse Mode (PIM-SM): Protocol Specification 503 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 504 2016, . 506 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 507 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 508 . 510 Authors' Addresses 512 Zheng(Sandy) Zhang 513 ZTE Corporation 515 EMail: zzhang_ietf@hotmail.com 517 Bo Wu 518 Individual 520 EMail: w1973941761@163.com 522 Zhaohui Zhang 523 Juniper Networks 525 EMail: zzhang@juniper.net 527 IJsbrand Wijnands 528 Cisco Systems, Inc. 530 EMail: ice@cisco.com 532 Yisong Liu 533 China Mobile 535 EMail: liuyisong.ietf@gmail.com