idnits 2.17.1 draft-zwzw-bier-prefix-redistribute-06.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 (June 4, 2020) is 1419 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 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: December 6, 2020 Individual 6 Z. Zhang 7 Juniper Networks 8 IJ. Wijnands 9 Cisco Systems, Inc. 10 Y. Liu 11 June 4, 2020 13 BIER Prefix Redistribute 14 draft-zwzw-bier-prefix-redistribute-06 16 Abstract 18 This document defines a BIER proxy function to interconnect different 19 underlay routing protocol areas in a network. And a new BIER proxy 20 range sub-TLV is also defined to convey BIER BFR-id information 21 across the routing areas. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC2119. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 6, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. BIER proxy range sub-TLV . . . . . . . . . . . . . . . . 7 67 3.2. Proxy range sub-TLV usage . . . . . . . . . . . . . . . . 9 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 7.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Problem statement 77 +-------------------------------------------------------+ 78 | +----+ +----+ PIM | 79 | +----+ R1 +-------------+ R2 +-----+ | 80 | | +----+ +----+ | | 81 | | | | 82 | | OSPF area 0 / ISIS | | 83 | | | | 84 | | +----+ +----+ | | 85 | +-----+ +------------+ +-----+ | 86 | +------------+ R3 +---+ +---+ R4 +------------+ | 87 | | +----+ | | +----+ | | 88 | | | | | | 89 | | OSPF area 1 | | OSPF area 2 | | 90 | | | | | | 91 | | +----+ +----+ | | +----+ +----+ | | 92 | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | 93 | +----+ +----+ +----+ +----+ | 94 +-------------------------------------------------------+ 95 Figure 1 97 Figure 1 shows that there are three areas in a traditional network. 98 In some deployment situations, different routing protocols may also 99 be used in the network. There are just small amount of routers in 100 each area. Currently, multicast services are provided in this kind 101 of network by using protocol independent feature of PIM [RFC7761]. 103 BIER could be a candidate multicast protocol to replace PIM to reduce 104 multicast states in the network. BIER [RFC8279] is a new 105 architecture for the forwarding of multicast data packets. It does 106 not require a protocol for explicitly building multicast distribution 107 trees, nor does it require intermediate nodes to maintain any per- 108 flow state. In order to build BIER forwarding plane, BIER key 109 parameters must be flooded in one BIER domain such as BFR-prefix, 110 BFR-id, subdomain-id, and so on. The routing protocols which are 111 used to flood these BIER parameters are called BIER routing underlay. 112 The associated routing protocol extensions are defined in documents 113 such as [RFC8401], [RFC8444], [I-D.ietf-bier-idr-extensions], 114 [I-D.ietf-bier-ospfv3-extensions], and so on. 116 +----+ +----+ 117 +----+ R1 +-------------+ R2 +-----+ 118 | +----+ +----+ | 119 | OSPF / ISIS | 120 | BIER domain 1 | 121 | | 122 | +----+ +----+ | 123 +-----+ +------------+ +-----+ 124 +------------+ R3 +---+ +---+ R4 +------------+ 125 | +----+ | | +----+ | 126 | OSPF | | OSPF | 127 | | | | 128 | BIER domain 2 | | BIER domain 3 | 129 | +----+ +----+ | | +----+ +----+ | 130 +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ 131 +----+ +----+ +----+ +----+ 132 Figure 2 134 Based on the BIER design, a BIER domain is limited by the underlay 135 routing protocols flooding scope. In case we want deploy BIER 136 instead of PIM, there are several BIER domains because of different 137 underlay routing areas limitation. Multiple encapsulating/ 138 decapsulation executions are needed to across multiple BIER domains. 139 These executions slow down the forwarding efficiency. The border 140 routers also need to maintain overlay state, which is undesired. 142 For example in figure 2, suppose that R1 and R2 connect with 143 multicast source. Rm, Rn, Rx and Ry connect with multicast 144 receivers. According the existed advertisement method defined in 145 [RFC8401], [RFC8444], and so on, in BIER domain 1, R1, R2, R3 and R4 146 are BIER edge routers. In BIER domain 2, R3 and Rm, Rn are BIER edge 147 routers. In BIER domain 3, R4 and Rx, Ry are BIER edge routers. 149 R1/R2 encapsulates BIER packet when multicast flows come into this 150 BIER domain, R3/R4 decapsulates the BIER packet, and encapsulates 151 them again, sends them into BIER domain 2/3. Rm, Rn, Rx and Ry 152 decapsulates the packets and forwards them to receivers. 154 Due to the decapsulation and encapsulation execution in R3 and R4, 155 the forwarding efficiency is slowed down, especially when there are 156 not large amount of routers in each BIER domain. 158 Section 2.3 in [RFC8444] defines the duplication function across OSPF 159 areas. Except the homogenization network, there is the hybrid 160 network showed in figure 2 that several areas formed by different IGP 161 protocols, and they are need to be merged into one BIER domain. In 162 the hybrid network, necessary advertisement transform need to be 163 used. And further, necessary optimization method can be used to 164 reduce the amount of the advertisement items. 166 2. Proposal 168 +-------------------------------------------------------+ 169 | +----+ +----+ BIER | 170 | +----+ R1 +-------------+ R2 +-----+ domain 1 | 171 | | +----+ +----+ | | 172 | | OSPF/ISIS | | 173 | | | | 174 | | +----+ +----+ | | 175 | +-----+ +------------+ +-----+ | 176 | +------------+ R3 +---+ +---+ R4 +------------+ | 177 | | +----+ | | +----+ | | 178 | | | | | | 179 | | OSPF area 1 | | OSPF area 2 | | 180 | | | | | | 181 | | +----+ +----+ | | +----+ +----+ | | 182 | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | 183 | +----+ +----+ +----+ +----+ | 184 +-------------------------------------------------------+ 185 Figure 3 187 It is more efficient to deploy BIER by creating one BIER domain for 188 the hybrid network to achieve forwarding benefit. 190 Since the limitation of the BIER routing protocol scope, BFR-id is 191 confined to only one routing area. A BIER proxy function is 192 introduced to transport BIER BFR-id information in a BIER domain 193 across multiple routing protocol areas. So BIER forwarding tables 194 can be built across multiple underlay routing protocols to replace 195 encapsulation/ decapsulation processing. In the current deployment, 196 border router (ABR) has a similar role, ABR summaries unicast routing 197 information from one routing protocol area and sends it to another 198 routing area by new routing protocol messages. So ABR can implement 199 BIER proxy function to summarize BIER BFR-id information from one 200 routing protocol area and sends it to another routing area. 202 In figure 3, R3/R4 connects two areas which running same or different 203 routing protocols, they can be used as BIER proxies to transport BIER 204 information. For example, after R3 receives BFR-ids information from 205 OSPF area 1 and sends it to ISIS routing area (the upper area), the 206 routers in ISIS routing area can generate BIER forwarding items 207 toward the BFR-ids in OSPF area 1 through R3. Similarly, R3 receives 208 BFR-ids information from the upper area and sends them into OSPF area 209 1, the routers in OSPF area 1 can build BIER forwarding items toward 210 the BFR-ids in ISIS area. R4 does the same function, the BIER 211 forwarding plane is constructed accordingly. 213 For example, in this network, suppose that Rm and Rn have the prefix 214 of 201.1.1.1/32, 201.1.1.2/32. In order to build one BIER domain 215 which includes these three IGP areas, R3 advertises the BFR-ids of 216 Rm/Rn with associated prefixes (201.1.1.1/32, 201.1.1.2/32) into the 217 upper area. Similarly, R4 advertises the BFR-ids of Rx/Ry with 218 associated prefixes (202.1.1.1/32, 202.1.1.2/32) into the upper area 219 too. 221 And R3/R4 advertises the prefixes of R1 and R2 (suppose that the 222 prefixes are 200.1.1.1/32 and 200.1.1.2/32) with associated BFR-ids 223 into IGP area 1 and area 2. Also, R3 advertises the prefixes learned 224 from R4 (202.1.1.1/32, 202.1.1.2/32) with associated BFR-ids into IGP 225 area 1. R4 also advertises the prefixes (201.1.1.1/32, 201.1.1.2/32) 226 with associated BFR-ids into IGP area 2. 228 After the path calculation, the BIER forwarding plane is built. When 229 R1/R2 receives multicast packet which should be sent to Rm/Rn/Rx/Ry, 230 R1/R2 encapsulates the packet with BIER header and send it into the 231 upper area. When R3/R4 receives the packet, R3/R4 forwards the 232 packet into IGP area 1 and area 2 according to the BIER forwarding 233 table without doing the decapsulation and re-encapsulation actions. 235 Obviously, in order to build the large BIER domain, the BFR-id of 236 edge router in each IGP area MUST NOT be overlapped. 238 3. Advertisement 240 According to [RFC8279], each BFER needs to have a unique (in each 241 sub-domain) BFR-id, and each BFR and BFER floods itself BIER info 242 sub-TLV and associated sub-sub-TLVs in the BIER domain. To keep 243 consistent with the definition in [RFC8444], 244 [I-D.ietf-bier-ospfv3-extensions], and [RFC8401], BIER info sub-TLV 245 defined in [RFC8401] and BIER sub-TLV defined in [RFC8444], 246 [I-D.ietf-bier-ospfv3-extensions] is reused to convey the BFR-id 247 information. OSPF extended Prefix Opaque LSA [RFC7684] and TLVs 235, 248 237 defined in [RFC5120], or TLVs 135 [RFC5305], or TLV 236 [RFC5308] 249 are still used to carry the BFR-id/ BFR-prefix information, etc. 251 The key parameters got from the original routing protocol should be 252 adapted to the format of next routing protocol, such as BFR-prefix, 253 BFR-id, subdomain-id, and so on. Some parameters like BAR, MT-ID has 254 local significance, So they should be set to same values with BIER 255 proxy own advertisement when BIER proxy advertise them to the next 256 routing area. 258 And as the two BIER info sub-sub-TLVs (sub-TLVs) including MPLS 259 encapsulation and BSL conversion also have local significance. The 260 information carried in these two sub-sub-TLV need not, but MAY, be 261 advertised to next routing area. 263 In the same example, when R3 advertises the prefixes of Rm and Rn 264 into the upper area, R3 may advertise the prefixes one by one, that 265 is R3 advertises 201.1.1.1/32 with associated BFR-id, and R3 266 advertises 201.1.1.2/32 with associated BFR-id. If there is dozens 267 of edge routers in area 1, R3 advertises dozens of prefixes and 268 associated BFR-ids into the upper area. When R3 advertises the 269 prefixes from the upper area into area 1, R3 advertises the prefixes 270 of R1 and R2 with associated BFR-ids separately, and R3 advertises 271 the prefixes of Rx and Ry which come from R4 into area 1 one by one. 272 R4 does it as well. 274 3.1. BIER proxy range sub-TLV 276 In some cases unicast default route and aggregated/ summarized routes 277 are used in some routing areas and routers in next area can not see 278 the specific BFR-prefix routes from original area. Like in figure 3, 279 in case R3/R4 does not advertise specific ISIS unicast routes to OSPF 280 area and only advertises unicast default route or aggregated/ 281 summarized route to OSPF area 1/2, when R3/R4 advertises BIER info 282 sub-TLV to OSPF area 1/2, R3 MUST advertise the prefix with default 283 route or aggregated/ summarized route. In that case, multiple BFR- 284 ids will be mapped to one prefix. In order to advertise BFR-ids 285 optimally, we define a new BIER proxy range sub-TLV to advertise the 286 information of BFR-ids. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | subdomain-id | resv | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | BFR-id | BFR-id range | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | ... | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | BFR-id | BFR-id range | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 figure 4 301 o Type: 8-bit unsigned integer. TBD to indicate the BIER proxy 302 range sub-TLV. 304 o Length: 8-bit unsigned integer. Length of the BIER proxy range 305 sub-TLV in 4-octet units, not including the first 4 octets. 307 o Subdomain-id: 8-bit unsigned integer. The subdomain-id from 308 original advertisement. 310 o resv: 8-bit unsigned integer. The reserved field. 312 o BFR-id: 16-bit unsigned integer. The first BFR-id from original 313 advertisement. 315 o BFR-id range: 16-bit unsigned integer. The range of BFR-ids with 316 one subdomain-id. 318 The BIER proxy range sub-TLV is attached to the aggregated/ 319 summarized route prefix or default route prefix. The summarized/ 320 aggregated/ default prefix may need multiple BIER proxy range sub- 321 TLVs when the BFR-ids covered by the prefix are allocated from 322 different ranges (even if they're from a single range but some BFR- 323 ids in the range map to the BIER prefixes that are covered by a 324 different summarized/ aggregated prefix, then that single large range 325 needs to be broken into smaller ranges). 327 When a BFR receives a default/summary route with a BIER proxy range 328 sub-TLV, it builds a BIRT route with that default/summary prefix. It 329 also builds multiple BIFT entries for each BFR-IDs covered in the 330 proxy range sub-TLV, using the same forwarding information as in the 331 BIRT route. It is possible that a BFR-ID is covered in the proxy 332 range sub-TLV of multiple default/summary routes. In that case, ECMP 333 can be used and longest match SHOULD be used. For example, if ABR1 334 advertises default/summary route P1 while ABR2 advertises a more 335 specific summary route P2 and both have a proxy range sub-TLV that 336 covers BFR-ID 100, then the BIFT entry for BFR-ID 100 only follows 337 the P2 route in BIRT. 339 The proxy range sub-TLV can also be attached to a host BIER prefix 340 itself. Consider the situation where BGP-LU [RFC3107] is used for a 341 seamless MPLS [I-D.ietf-mpls-seamless-mpls] environment. An ABR/ASBR 342 advertises BIER prefixes via BGP over an area/AS to other ABR/ASBRs 343 but the BIER prefixes are not advertised into the IGP for the area/ 344 AS. The ABR/ASBR does advertise the BIER prefix for itself into the 345 IGP for the area/AS, with a BIER proxy range sub-TLV to cover the 346 BFR-IDs for BFRs that the ABR/ASBR has learned (either through IGP or 347 through BGP signaling). When an internal BFR receives it, it treats 348 as if a default summary route had been received with the proxy range 349 sub-TLV. Note that this imaginary default summary route is only for 350 the purpose of building BIRT/BIFT entries and not used for unicast 351 forwarding. 353 With this scheme, even though the BIER prefixes are not advertised 354 into the IGP for the area/AS and unicast traffic for those BIER 355 prefixes are tunneled through, corresponding BIFT entries are 356 maintained inside the area/AS for the purpose of efficient BIER 357 forwarding. Otherwise, BIER forwarding through the area/AS would be 358 tunneled just like unicast case. 360 The range in the BIER proxy range sub-TLV can be as granular as to 361 advertise individual BFR-ids. Though a larger range can increase 362 advertisement efficiency, it requires careful planning for BFR-id 363 assignment. 365 When the proxy range sub-TLV is used, the mapping between a BIER 366 prefix and its BFR-id is no longer conveyed in the routing underlay. 367 As a result, the mapping must be provided by other means, e.g. in the 368 multicast overlay. 370 3.2. Proxy range sub-TLV usage 372 In the same example of figure 3, in case there are 40 edge routers in 373 area 1, the BFR-ids of area 1 start from 51 to 90, and the prefixes 374 of these routers start from 201.1.1.1/32 to 201.1.1.40/32. These 375 prefixes are not overlapped with the prefixes in any other area. 377 When R3 advertises these prefixes into the upper area, the proxy 378 range sub-TLV can be used to optimize the advertisement. That is R3 379 can advertise only one prefix 201.1.1.0/24, with the BFR-id set to 380 51, the BFR-id range set to 40, into the upper area. Then the BIER 381 overlay is built among R1, R2, Rm, Rn, Rx and Ry. R3 and R4 need not 382 maintain the multicast overlay states. 384 When R3 advertises the prefixes from the upper area and area 2 into 385 area 1, R3 may advertise only one default route (0.0.0.0/0) into area 386 1 if one or more continuous BFR-id range can be attached. Suppose 387 that the BFR-id in the upper area starts from 1001 to 1050, the BFR- 388 id in area 2 starts from 201 to 250, and these ranges are not 389 overlapped with the ranges in any other area. Suppose that the sub- 390 domain ID is 1, the BIER proxy range sub-TLV may be advertised like 391 this: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | TBD | 2 | 1 | 0 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | 1001 | 50 | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | 201 | 50 | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 figure 5 404 The optimized summary/ aggregated or default prefix can be generated 405 by the operation policy which is configured by the network 406 administrator. 408 In case the range of BFR-ids in one area is overlapped with the BFR- 409 ids in any other area, the proxy range sub-TLV can not be used. In 410 the same example above, if the BFR-ids in area 1 are 21, 31, 41, 411 etc., the BFR-ids in area 2 are 22, 32, 42, etc., even if the 412 summarized prefixes are not overlapped with the prefixes in any other 413 area, when R3 advertises the summarized prefixes in area 1 into the 414 upper area, the proxy range sub-TLV may not optimize the 415 advertisement. 417 After the forwarding plane is built, when R1 receives multicast 418 packet, and the receivers of this flow are connected by Rm and Rx, R1 419 encapsulates BIER header in front of the flow packet with BFR-ids set 420 to Rm and Rx. When R3/R4 receives the packet, R3/R4 need not 421 decapsulate and re-encapsulate the packet. R3/R4 just forwards the 422 packet according to the BIER forwarding table. When the packet 423 reaches Rm and Rx, Rm and Rx remove the BIER header and forward it to 424 receivers. 426 4. IANA Considerations 428 IANA is requested to set up a new types of sub-TLV (TLV) registry 429 value for BIER proxy range advertisement in OSPF, ISIS, BGP, etc. 431 5. Security Considerations 433 Implementations must assure that malformed TLV and Sub-TLV 434 permutations do not result in errors which cause hard protocol 435 failures. 437 6. Acknowledgements 439 The authors would like to thank Stig Venaas for his valuable comments 440 and suggestions. 442 7. References 444 7.1. Normative References 446 [I-D.ietf-bier-idr-extensions] 447 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 448 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 449 idr-extensions-07 (work in progress), September 2019. 451 [I-D.ietf-bier-ospfv3-extensions] 452 Psenak, P., Nainar, N., and I. Wijnands, "OSPFv3 453 Extensions for BIER", draft-ietf-bier-ospfv3-extensions-02 454 (work in progress), May 2020. 456 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 457 Topology (MT) Routing in Intermediate System to 458 Intermediate Systems (IS-ISs)", RFC 5120, 459 DOI 10.17487/RFC5120, February 2008, 460 . 462 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 463 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 464 2008, . 466 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 467 DOI 10.17487/RFC5308, October 2008, 468 . 470 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 471 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 472 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 473 2015, . 475 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 476 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 477 Explicit Replication (BIER)", RFC 8279, 478 DOI 10.17487/RFC8279, November 2017, 479 . 481 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 482 Zhang, "Bit Index Explicit Replication (BIER) Support via 483 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 484 . 486 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 487 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 488 Extensions for Bit Index Explicit Replication (BIER)", 489 RFC 8444, DOI 10.17487/RFC8444, November 2018, 490 . 492 7.2. Informative References 494 [I-D.ietf-mpls-seamless-mpls] 495 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 496 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 497 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 499 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 500 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 501 . 503 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 504 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 505 Multicast - Sparse Mode (PIM-SM): Protocol Specification 506 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 507 2016, . 509 Authors' Addresses 511 Zheng(Sandy) Zhang 512 ZTE Corporation 514 EMail: zzhang_ietf@hotmail.com 516 Bo Wu 517 Individual 519 EMail: w1973941761@163.com 521 Zhaohui Zhang 522 Juniper Networks 524 EMail: zzhang@juniper.net 526 IJsbrand Wijnands 527 Cisco Systems, Inc. 529 EMail: ice@cisco.com 531 Yisong Liu 533 EMail: liuyisong.ietf@gmail.com