idnits 2.17.1 draft-xie-bier-ipv6-encapsulation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2019) is 1740 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC2474' is mentioned on line 210, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-bier-ipv6-requirements-01 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track L. Geng 5 Expires: January 21, 2020 China Mobile 6 M. McBride 7 Futurewei 8 R. Asati 9 Cisco 10 S. Dhanaraj 11 Huawei 12 July 20, 2019 14 Encapsulation for BIER in Non-MPLS IPv6 Networks 15 draft-xie-bier-ipv6-encapsulation-03 17 Abstract 19 This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- 20 MPLS IPv6 Networks using the IPv6 Destination Option extension 21 header. 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] and 28 [RFC8174]. 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 21, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 3 67 3.1. BIER Option in IPv6 Destination Options Header . . . . . 3 68 3.2. Multicast and Unicast Destination Address . . . . . . . . 6 69 3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8 70 4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 11 74 6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 11 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 9.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 85 that provides optimal multicast forwarding without requiring 86 intermediate routers to maintain any per-flow state by using a 87 multicast-specific BIER header. 89 [RFC8296] defines a common BIER Header format for MPLS and Non-MPLS 90 networks. It has defined two types of encapsulation methods using 91 the common BIER Header, (1) BIER encapsulation in MPLS networks, 92 here-in after referred as MPLS BIER Header in this document and (2) 93 BIER encapsulation in Non-MPLS networks, here-in after referred as 94 Non-MPLS BIER Header in this document. [RFC8296] also assigned 95 Ethertype=0xAB37 for Non-MPLS BIER Header packets to be directly 96 carried over the Ethernet links. 98 This document proposes a BIER IPv6 encapsulation for Non-MPLS IPv6 99 Networks, defining a method to carry the standard Non-MPLS BIER 100 header (as defined in [RFC8296]) in the native IPv6 header. A new 101 IPv6 Option type - BIER Option is defined to encode the standard Non- 102 MPLS BIER header and this newly defined BIER Option is carried under 103 the Destination Options header of the native IPv6 Header [RFC8200]. 105 This document details one of the proposed solutions for transporting 106 BIER packets in an IPv6 network. To better understand the overall 107 BIER IPv6 problem space, use cases and proposed solutions, refer to 108 [I-D.ietf-bier-ipv6-requirements]. 110 2. Terminology 112 Readers of this document are assumed to be familiar with the 113 terminology and concepts of the documents listed as Normative 114 References. 116 The following new terms are used throughout this document: 118 o BIERv6 - BIER IPv6. 120 o BIER Option - An Option type carried in IPv6 Destination Options 121 Header which includes the standard Non-MPLS BIER Header. 123 o BIERv6 Header - An IPv6 Header with BIER Option. 125 o BIERv6 Packet - An IPv6 packet with BIERv6 Header. Such an IPv6 126 packet typically carries the user multicast payload and is 127 forwarded by BFRs in the BIERv6 network towards the multicast 128 receivers. 130 3. BIER IPv6 Encapsulation 132 3.1. BIER Option in IPv6 Destination Options Header 134 Destination Options Header and the Options that can be carried under 135 this extension header is defined in [RFC8200]. This document defines 136 a new Option type - BIER Option, to encode the Non-MPLS BIER header. 137 As specified in Section 4.2 [RFC8200], the BIER Option follows type- 138 length-value (TLV) encoding format and the standard Non-MPLS BIER 139 header [RFC8296] is encoded in the value portion of the BIER Option 140 TLV. 142 This BIER Option MUST be carried only inside the IPv6 Destination 143 Options header and MUST NOT be carried under the Hop-by-Hop Options 144 header. 146 Co-existence of Destination Options Header with BIER option TLV and 147 other IPv6 extension headers MUST confirm to the general requirements 148 defined in [RFC8200]. In addition to the requirements defined in 149 [RFC8200], this document requires that the Destination Options Header 150 with a BIER Option TLV MUST appear only after the Routing Header if 151 the Routing Header is present in the IPv6 Header. 153 The BIER Option is encoded in type-length-value (TLV) format as 154 follows: 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Next Header | Hdr Ext Len | Option Type | Option Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | | 162 ~ Non-MPLS BIER Header (defined in RFC8296) ~ 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Next Header 8-bit selector. Identifies the type of header 167 immediately following the Destination Options header. 169 Hdr Ext Len 8-bit unsigned integer. Length of the Destination 170 Options header in 8-octet units, not including the first 8 octets. 172 Option Type To be allocated by IANA. See section 6. 174 Option Length 8-bit unsigned integer. Length of the option, in 175 octets, excluding the Option Type and Option Length fields. 177 Non-MPLS BIER Header The Non-MPLS BIER Header defined in RFC8296. 178 Fields in the Non-MPLS BIER Header MUST be encoded as below. 180 BIFT-id: The BIFT-id is a domain-wide unique value in Non-MPLS 181 IPv6 encapsulation. See Section 2.2 of RFC 8296. 183 TC: SHOULD be set to binary value 000 upon transmission and MUST 184 be ignored upon. See Section 2.2 of RFC 8296. 186 S bit: SHOULD be set to 1 upon transmission, and MUST be ignored 187 upon reception. See Section 2.2 of RFC 8296. 189 TTL: MUST be set to 0 upon transmission, and MUST be ignored 190 upon reception. The function of TTL is replaced by the Hop 191 Limit field in IPv6 header. 193 Nibble: SHOULD be set to 0000 upon transmission, and MUST be 194 ignored upon reception. See Section 2.2 of RFC 8296. 196 Ver: MUST be set to 0 upon transmission, and MUST be discarded 197 when it is not 0 upon reception. See Section 2.2 of RFC 8296. 199 BSL: See Section 2.1.2 of RFC 8296. 201 Entropy: See Section 2.1.2 of RFC 8296. 203 OAM: See Section 2.1.2 of RFC 8296. 205 Rsv: See Section 2.1.2 of RFC 8296. 207 DSCP: SHOULD be set to binary value 000000 upon transmission and 208 MUST be ignored upon reception. In IPv6 BIER encapsulation, 209 uses highest 6-bit of Traffic Class field of IPv6 header to hold 210 a Differentiated Services Codepoint [RFC2474]. 212 Proto: SHOULD be set to 0 upon transmission and MUST be ignored 213 upon reception. In IPv6 BIER encapsulation, the functionality 214 of this 6-bit Proto field is replaced by the Next Header field 215 in Destination Options header, which is the last IPv6 extension 216 header, to indicate the BIER payload, which is also IPv6 217 payload. 219 For BIER Proto 1, indicating a Downstream-assigned MPLS 220 payload, use Next Header value 137. 222 For BIER Proto 2, indicating an Upstream-assigned MPLS 223 payload, there is no Next Header code currently. An 224 upstream-assigned MPLS label within the context of special 225 BFIR router, which in turn is represented by the BFIR-id and 226 the Sub-domain indirectly indicated by the BIFT-id in a BIER- 227 MPLS or BIER-ETH packet, can be replaced by an IPv6 source 228 address in a BIER IPv6 encapsulation packet in a direct 229 manner. In this case, use Next Header value 4 for IPv4 230 payload, or value 41 for IPv6 payload. 232 For BIER Proto 3, indicating an Ethernet payload, use Next 233 Header value 97. 235 For BIER Proto 4, indicating an IPv4 payload, use Next Header 236 value 4. 238 For BIER Proto 5, indicating a BIER-OAM payload, use Next 239 Header value 58. How the BIER-PING is supported with BIER 240 IPv6 encapsulation is outside the scope of this document. 242 For BIER Proto 6, indicating an IPv6 payload, use Next Header 243 value 41. 245 BFIR-id: See Section 2.1.2 of RFC 8296. 247 BitString: See Section 2.1.2 of RFC 8296. 249 3.2. Multicast and Unicast Destination Address 251 BIER is generally a hop-by-hop and one-to-many architecture, and thus 252 the IPv6 Destination Address (DA) being a Multicast Address is a way 253 one may think of as an approach for both the two paradigms in BIERv6 254 encapsulation. 256 However using a unicast address has the following benefits: 258 1. Tunneling a BIERv6 packet over a non-BIER capable router. 260 2. Fast rerouting a BIERv6 packet using a unicast by-pass tunnel. 262 3. Forwarding a BIERv6 packet to one of the many BFR neighbors 263 connected on a LAN. 265 4. Connecting BIER domains, for example Data Center domains, in an 266 overlay manner. 268 Some of the above functions are assumed very basic requirements and 269 part of BIER architecture as described in [RFC8279]. This document 270 uses unicast address for both one-hop replication and multi-hop 271 replication. 273 The unicast address used in BIERv6 packet targeting a BFR SHOULD be 274 the IPv6 BFR-Prefix advertised from this BFR. When a BFR advertises 275 the BIER information with BIERv6 encapsulation capability, the IPv6 276 BFR-prefix of this BFR MUST be selected specifically for BIERv6 277 packet forwarding. Locally this "BIER Specific" IPv6 address is 278 initialized in FIB with a flag of "BIER specific handling", 279 represented as End.BIER function. For convenience, the indication in 280 FIB share the same space as SRv6 Endpoints Behaviors defined in 281 [I-D.ietf-spring-srv6-network-programming]. Apart from this sharing 282 of code space, there is nothing dependent on SRv6. The co-existance 283 of BIERv6 and SRv6 is outside the scope of this document. 285 BFR Prefix is used only in control plane in BIER MPLS encapsulation 286 but not used in data plane. While in BIERv6, BFR prefix is used in 287 both control plane and data plane. For the convinence of migration 288 to BIERv6, it is RECOMMENDED to use an "exclusive" IPv6 address as 289 BFR prefix when deploying BIER-MPLS in IPv6 networks. The 290 "exclusive" IPv6 address should not be used for general purpose like 291 BGP session establishment, but for "BIER specific" function. For 292 Non-BIER IPv6 routers, the IPv6 address is a regular IPv6 prefix 293 reachable through IPv6 unicast routing. 295 The following is an example of configuring a BIER specific IPv6 296 address and using this address as BFR prefix: 298 # Config a BIER specific IPv6 address with 128-bit mask on loopback0. 299 interface loopback0 300 ipv6 address 2001:DB8::AB37 128 End.BIER 302 # Config the BIER-specific IPv6 address on loopback0 as BFR Prefix. 303 bier sub-domain 6 ipv6-underlay 304 bfr-prefix interface loopback0 306 The address used as "BIER specific" IPv6 address can be from inside 307 the scope of an SRv6 Locator or outside the scope of the SRv6 308 Locator(s) since it is a host prefix (128-bit prefix-length prefix). 310 Each "BIER specific" address can be used in one or many sub-domains 311 as BFR-prefix, such that it can be associated with one or many Multi- 312 Topologies (MTs) or algorithms. 314 More than one "BIER specific" address are also allowed as different 315 BFR-prefix of more than one sub-domain, as described in section 2 of 316 [RFC8279]. 318 The following is an example pseudo-code of the End.BIER function: 320 1. IF NH = 60 and HopLimit > 0 ;;Ref1 321 2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2 322 3. Lookup the BIER Header inside the BIER option TLV. 323 4. Forward via the matched entry. 324 5. ELSE ;;Ref3 325 6. Drop the packet and end the process. 326 7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4 327 8. Send to CPU. 328 9. ELSE ;;Ref5 329 10. Drop the packet. 331 Ref1: Destination options header follows the IPv6 header directly and 332 HopLimit is bigger than zero. 334 Ref2: The first TLV is BIER type and is the only TLV present in 335 Destination options header. 337 Ref3/Ref5: Undesired packet is droped because the destination address 338 is the BIER specific IPv6 address (End.BIER function). 340 Ref4: An ICMPv6 packet using End.BIER as destination address. 342 3.3. BIERv6 Packet Format 344 As a multicast packet enters the BIER domain in a Non-MPLS IPv6 345 network, the multicast packet will be encapsulated with BIERv6 346 Header. 348 Typically a BIERv6 header would contain the Destination Options 349 Header as the only Extensions Header besides IPv6 Header. However, 350 it is allowed and possible for other extension headers to appear 351 along with the Destination Options Header as long as the requirements 352 listed in section 3.1 of this document is met. 354 Format of the multicast packet with BIERv6 encapsulation carrying 355 only the Destination Options header is depicted in the below figure. 357 +---------------+--------------+------------ 358 | IPv6 header | Dest Options | X type of 359 | | Header with | multicast 360 | | BIER Option | packet 361 | | | 362 | Next Hdr = 60 | Nxt Hdr = X | 363 +---------------+--------------+------------ 365 Format of the multicast packet with BIERv6 encapsulation carrying 366 other extension headers along with Destination Options extension 367 header is required to follow general recommendations of [RFC8200] and 368 examples in other RFCs. [RFC6275] introduces how the order should be 369 when other extension headers carries along with Home address option 370 in a destination options header. Similar to this example, this 371 document requires the Destination Options Header carrying the BIER 372 option MUST be placed as follows: 374 o After the routing header, if that header is present 376 o Before the Fragment Header, if that header is present 377 o Before the AH Header or ESP Header, if either one of those headers 378 is present 380 Source Address field in the IPv6 header MUST be a routable IPv6 381 unicast address of the BFIR in any case. 383 BFIR encodes the Non-MPLS BIER header in the above mentioned 384 encapsulation format and forwards the BIERv6 packet to the nexthop 385 BFR following the local BIFT table. 387 BFRs in the IPv6 network, processes and replicates the packets 388 towards the BFERs using the local BIFT table. The bit-string field 389 in the Non-MPLS BIER header may be changed by the BFRs as they 390 replicate the packet. BFRs MUST follow the procedures defined in 391 section 3.1 as they modify the other fields in the Non-MPLS BIER 392 header. The source address in the IPv6 header MUST NOT be modified 393 by the BFRs. 395 4. BIERv6 Packet Processing 397 There is no BIER-specific processing, and all the 8 steps in section 398 6.5 of RFC8279 apply to BIERv6 packet processing. However, there are 399 some IPv6-specific processing procedures due to the base and general 400 procedures of IPv6. 402 On the overlay layer, when a multicast packet enters the BIER domain 403 in a Non-MPLS IPv6 network, the Ingress BFR (BFIR) encapsulates the 404 multicast packet with a BIERv6 Header, transforming it to a BIERv6 405 packet. The BIERv6 header includes an IPv6 header and IPv6 406 Destination Options Header within a standard Non-MPLS BIER header. 407 Source Address field in the IPv6 header MUST be set to a routable 408 IPv6 unicast address of the BFIR. Destination Address field in the 409 IPv6 header is set to the BFR prefix of the next-hop BFR the BIERv6 410 packet replicating to, no matter next-hop BFR is directly connected 411 (one-hop) or not directly connected (multi-hop). 413 On the BIER layer, upon receiving an BIERv6 packet, the BFR processes 414 the IPv6 header first. This is the general procedure of IPv6. 416 If the IPv6 Destination address is an IPv6 BFR-Prefix unicast address 417 of this BFR, a 'BIER Specific Handling' indication will be obtained 418 by the preceding Unicast DA lookup (FIB lookup). The BIER option, if 419 exists, will be checked to decide which neighbor(s) to replicate the 420 BIERv6 packet to. 422 It is a local behavior to handle the combination of extension 423 headers, options and the BIER option(s) in destination options header 424 when a 'BIER Specific Handling' indication is got by the preceding 425 FIB lookup. Early deployment of BIERv6 may require there is only one 426 BIER option TLV in the destination options header followed the IPv6 427 header. How other extension headers or more BIER option TLVs in a 428 BIERv6 packet is handled is outside the scope of this document. 430 A packet having a 'BIER Specific Handling' indication but not having 431 a BIER option is supposed to be a wrong packet or an ICMPv6 packet, 432 and the process can be refered to the example in section 3.2. 434 A packet not having a 'BIER Specific Handling' indication but having 435 a BIER option SHOULD be processed normally as unicast forwarding 436 procedures, which may be a behavior of drop, or send to CPU, or other 437 behaviors in existing implementations. 439 The Destination Address field in the IPv6 Header MUST change to the 440 nexthop BFR's BFR Prefix if Unicast address is used in BIERv6. 442 The Hop Limit field of IPv6 header MUST decrease by 1 when sending 443 packets to a BFR neighbor, while the TTL in the BIER header MUST be 444 unchanged. 446 The BitString in the BIER header in the Destination Options Header 447 may change when sending packets to a neighbor. Such change of 448 BitString MUST be aligned with the procedure defined in RFC8279. 449 Because of the requirement to change the content of the option when 450 forwarding BIERv6 packet, the BIER option type should have chg flag 1 451 per section 4.2 of RFC8200. 453 The procedures applies normally if a bit corresponding to the self 454 bfr-id is set in the bit-string field of the Non-MPLS BIER header of 455 the BIERv6 packet. The node is considered to be an Egress BFR (BFER) 456 in this case. The BFER removes the BIERv6 header, including the IPv6 457 header and the Destination Options header, and copies the packet to 458 the multicast flow overlay. The egress VRF of a packet may be 459 determined by a further lookup on the IPv6 source address instead of 460 the upstream-assigned MPLS Label as described in [RFC8556]. 462 The Fragment Header, AH Header or ESP Header, if exists after the 463 BIER options header, can be processed on BFER only as part of the 464 multicast flow overlay process. 466 5. Security Considerations 468 A BIERv6 packet with a special IPv6 Destination Address, the BFR 469 prefix functioning as End.BIER, would be processed by BIER forwarding 470 procedure only when the 'BIER Specific Handling' flag has been 471 obtained ahead in the FIB lookup of the IPv6 header. Otherwise the 472 packet with an IPv6 BIER Option will not be processed by the 473 procedure but be processed as normal IPv6 packet. A possible way of 474 handling IPv6 packets with extension may be send to CPU for slow path 475 processing. 477 6. IANA Considerations 479 6.1. BIER Option Type 481 Allocation is expected from IANA for a BIER Option Type codepoint 482 from the "Destination Options and Hop-by-Hop Options" sub-registry of 483 the "Internet Protocol Version 6 (IPv6) Parameters" registry. The 484 value 0x70 is suggested. 486 +-----------+-----+-----+-------+-------------+------------+ 487 | Hex Value | act | chg | rest | Description | Reference | 488 +-----------+-----+-----+-------+-------------+------------+ 489 | 0x70 | 01 | 1 | 10000 | BIER Option | This draft | 490 +-----------+-----+-----+-------+-------------+------------+ 492 6.2. End.BIER Function 494 Allocation is expected from IANA for an End.BIER function codepoint 495 from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is 496 suggested. 498 +-------+--------+--------------------------+------------+ 499 | Value | Hex | Endpoint function | Reference | 500 +-------+--------+--------------------------+------------+ 501 | TBD | TBD | End.BIER | This draft | 502 +-------+--------+--------------------------+------------+ 504 7. Acknowledgements 506 The authors would like to thank Stig Venaas for his valuable 507 comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda, 508 Toerless Eckert, Jeffrey Zhang for the helpful comments to improve 509 this document. 511 8. Contributors 512 Gang Yan 513 Huawei Technologies 514 China 515 Email: yangang@huawei.com 517 Yang(Yolanda) Xia 518 Huawei Technologies 519 China 520 Email: yolanda.xia@huawei.com 522 9. References 524 9.1. Normative References 526 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 527 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 528 2011, . 530 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 531 (IPv6) Specification", STD 86, RFC 8200, 532 DOI 10.17487/RFC8200, July 2017, 533 . 535 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 536 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 537 Explicit Replication (BIER)", RFC 8279, 538 DOI 10.17487/RFC8279, November 2017, 539 . 541 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 542 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 543 for Bit Index Explicit Replication (BIER) in MPLS and Non- 544 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 545 2018, . 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 9.2. Informative References 554 [I-D.ietf-bier-ipv6-requirements] 555 McBride, M., Xie, J., Dhanaraj, S., and R. Asati, "BIER 556 IPv6 Requirements", draft-ietf-bier-ipv6-requirements-01 557 (work in progress), July 2019. 559 [I-D.ietf-spring-srv6-network-programming] 560 Filsfils, C., Camarillo, P., Leddy, J., 561 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 562 Network Programming", draft-ietf-spring-srv6-network- 563 programming-01 (work in progress), July 2019. 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, 567 DOI 10.17487/RFC2119, March 1997, 568 . 570 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 571 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 572 May 2017, . 574 Authors' Addresses 576 Jingrong Xie 577 Huawei Technologies 579 Email: xiejingrong@huawei.com 581 Liang Geng 582 China Mobile 583 Beijing 10053 585 Email: gengliang@chinamobile.com 587 Mike McBride 588 Futurewei 590 Email: mmcbride7@gmail.com 592 Rajiv Asati 593 Cisco 595 Email: rajiva@cisco.com 597 Senthil Dhanaraj 598 Huawei 600 Email: senthil.dhanaraj@huawei.com