idnits 2.17.00 (12 Aug 2021) /tmp/idnits23471/draft-xie-bier-mvpn-mpls-p2mp-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 abstract seems to contain references ([RFC8279], [I-D.ietf-bier-mvpn]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 1537 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4611' is mentioned on line 594, but not defined == Missing Reference: '0-255' is mentioned on line 924, but not defined == Outdated reference: draft-ietf-bess-mvpn-expl-track has been published as RFC 8534 == Outdated reference: draft-ietf-bess-mvpn-fast-failover has been published as RFC 9026 == Outdated reference: A later version (-07) exists of draft-ietf-bier-idr-extensions-05 == Outdated reference: draft-ietf-bier-isis-extensions has been published as RFC 8401 == Outdated reference: draft-ietf-bier-mvpn has been published as RFC 8556 == Outdated reference: draft-ietf-bier-ospf-bier-extensions has been published as RFC 8444 ** Downref: Normative reference to an Informational RFC: RFC 7431 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei 4 Intended status: Standards Track M. McBride 5 Expires: September 6, 2018 Huawei Technologies 6 M. Chen 7 Huawei 8 L. Geng 9 China Mobile 10 March 5, 2018 12 Multicast VPN Using MPLS P2MP and BIER 13 draft-xie-bier-mvpn-mpls-p2mp-01 15 Abstract 17 The MVPN specifications allow the use of several different kinds of 18 P-tunnel technology, such as mLDP P2MP, RSVP-TE P2MP and PIM SSM. It 19 is common for such a P-tunnel having a multicast-specific path. Bit 20 Index Explicit Replication (BIER) is an architecture that provides 21 optimal multicast forwarding without requiring intermediate routers 22 to maintain any per-flow state by using a multicast-specific BIER 23 header. 25 [I-D.ietf-bier-mvpn] delivers a solution of MVPN using SPF based BIER 26 defined in [RFC8279]. It can not, however, support a multicast- 27 specific path well, something common in legacy MVPN deployment. 28 [RFC8279] provides a solution to support mid nodes without BIER- 29 capability. It can not, however, support deployment on a network 30 that has edge nodes without BIER-capability, which is common in some 31 SP-networks. 33 This document introduces a seamless transition mechanism from legacy 34 MVPN to MVPN using P2MP based BIER while preserving existing features 35 such as multicast-specific PATH and Live-Live protection. It also 36 introduces a seamless Live-Live protection mechanism by re-using the 37 Entropy field of the BIER header, and two methods to deploy BIER when 38 edge nodes and/or mid nodes don't have BIER-capability. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in [RFC2119]. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on September 6, 2018. 63 Copyright Notice 65 Copyright (c) 2018 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 83 4. MVPN using P2MP based BIER . . . . . . . . . . . . . . . . . 5 84 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 85 4.2. MVPN Transition from P2MP to P2MP based BIER . . . . . . 6 86 4.2.1. Use of the PTA in x-PMSI A-D Routes . . . . . . . . . 7 87 4.2.2. Use of the PTA in Leaf A-D routes . . . . . . . . . . 9 88 4.3. Building P2MP based BIER forwarding state . . . . . . . . 10 89 4.4. Inheriting and Developing of Live-Live protection . . . . 11 90 5. P2MP based BIER Forwarding Procedures . . . . . . . . . . . . 11 91 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 92 5.2. P2MP based BIER forwarding customization . . . . . . . . 13 93 5.3. When Mid, Leaf or Bud nodes do not support P-CAPABILITY . 15 94 5.4. When Leaf or Bud nodes do not support D-CAPABILITY . . . 17 95 6. Provisioning Considerations . . . . . . . . . . . . . . . . . 20 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 101 10.2. Informative References . . . . . . . . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 104 1. Introduction 106 [RFC6513] and [RFC6514] specify the protocols and procedures that a 107 Service Provider (SP) can use to provide Multicast Virtual Private 108 Network (MVPN) service to its customers. Multicast tunnels are 109 created through an SP's backbone network; these are known as 110 "P-tunnels". The P-tunnels are used for carrying multicast traffic 111 across the backbone. The MVPN specifications allow the use of 112 several different kinds of P-tunnel technology, such as mLDP P2MP, 113 RSVP-TE P2MP and PIM SSM. It is common for such a P-tunnel having a 114 multicast-specific path. 116 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 117 that provides optimal multicast forwarding through a "multicast 118 domain", without requiring intermediate routers to maintain any per- 119 flow state, by using a multicast-specific BIER header (per 120 [RFC8296]). 122 [I-D.ietf-bier-mvpn] delivers a solution of MVPN using SPF based BIER 123 defined in [RFC8279]. It can not, however, support a multicast- 124 specific path well, something common in legacy MVPN deployment. 126 [RFC8279] provides a solution to support mid nodes without BIER- 127 capability. It cannot, however, support deployment on a network that 128 has edge nodes without BIER-capability, which may be common in some 129 SP-networks, especially when most of the nodes in a network or part 130 of a network are edge or service nodes. 132 This document introduces a seamless transition mechanism from legacy 133 MVPN to MVPN using P2MP based BIER, by applying a BIER encapsulation 134 in data-plane to eliminate per-flow states, while preserving existing 135 features such as multicast-specific PATH and Live-Live protection by 136 using existing protocols. 138 It also introduces a seamless Live-Live protection developped from 139 existing Live-Live protection scheme, by re-using the Entropy field 140 of the BIER header, for the ECMP/Entropy feature is not supported in 141 P2MP (per RFC6790). 143 It also introduces a seamless deployment solution on networks with 144 Non-BIER-capability Edge nodes and/or Mid nodes, by exploring the 145 P2MP/tree based BIER forwarding procedure in detail. Such a P2MP/ 146 tree based BIER is mentioned but not explored in detail in RFC8279. 148 2. Terminology 150 Readers of this document are assumed to be familiar with the 151 terminology and concepts of the documents listed as Normative 152 References. For convenience, some of the more frequently used terms 153 and new terms list below. 155 o LSP: Label Switch Path 157 o LSR: Label Switching Router 159 o P2MP: Point to Multi-point 161 o P-tunnel: A multicast tunnel through the network of one or more 162 SPs. P-tunnels are used to transport MVPN multicast data. 164 o PMSI: Provider Multicast Service Interface 166 o x-PMSI A-D route: a route that is either an I-PMSI A-D route or an 167 S-PMSI A-D route. 169 o PTA: PMSI Tunnel attribute. A type of BGP attribute known as the 170 PMSI Tunnel attribute. 172 o P2MP based BIER: BIER using P2MP LSP as topology 174 o P-CAPABILITY: A capability to Process BitString in BIER Header of 175 a packet. 177 o D-CAPABILITY: A capability to Disposit BIER Header of a packet, 178 including or excluding the BIER Label. 180 o BSL: Bit String Length, that is 64, 128, 256, etc (per [RFC8279]). 182 3. Applicability Statement 184 The BIER architecture document [RFC8279] describes how each node 185 forwards BIER packets hop by hop to neighboring nodes without 186 generating duplicate packets. This forwarding is for the case where 187 a form of underlay called "many to many " and built by IGP is used. 188 Obviously, the case of underlay of "one to many" or P2MP is a simpler 189 scenario, and the forwarding procedure naturally applies. However, 190 as is well-known, such a forwarding procedure requires the support of 191 hardware. The usage of the same forwarding method for both complex 192 scenarios and simple scenarios will inevitably require complex 193 hardware forwarding. 195 This document describes how BIER forwarding can be customized and 196 simplified with an underlay of "one to many" or P2MP (see chapter 5). 197 This customization and simplification eliminates some of the 198 unnecessary data plane processing and so is easier to implement with 199 existing hardware. Based on this customization of the forwarding 200 method for P2MP-based BIER, a variety of Partial Deployment methods 201 are given for the different capabilities of the hardware to support 202 BIER forwarding. Compared with RFC8279, when there is no BIER 203 forwarding capability on edge nodes, Partial Deployment can be 204 carried out ; For the case where the intermediate node has no BIER 205 forwarding capability, P2MP forwarding can be used without the need 206 for unicast replication. 208 This document also describes a MVPN Transition solution that 209 eliminates the per-flow state by introducing BIER MPLS encapsulation 210 and forwarding in data-plane, while preserving the original control- 211 plane protocol and its features, especially when some sort of path 212 customizing being used. The said path customization include RSVP-TE 213 P2MP using an explicit path, PIM-SSM tree using an explicit path , 214 and MLDP P2MP where static route was used. These features Can 215 continue to retain, making the transition process seamless. 217 This document also describes a seamless redundancy mechanism for the 218 widely deployed MVPN Live-Live protection, by using the added 219 information in the BIER header as a sequence-number of per packet. 220 This will bring additional benefit to the transition process from 221 traditional MVPN using PIM-SSM/mLDP/RSVP-TE to MVPN using P2MP based 222 BIER. 224 4. MVPN using P2MP based BIER 226 4.1. Overview 228 According to [RFC8279], the P2MP based BIER is a BIER which using a 229 form of tree as the underlay. The P2MP LSP is not only a LSP, but 230 also a topology as the BIER underlay. The P2MP based BIER is 231 P-tunnel, which is used for bearing multicast flows. Every flow can 232 think as binding to an independent tunnel, which is constructed by 233 the BitString in the BIER header of every packet of the flow. 234 Multicast flows are transported in SPMSI-only mode, on P2MP based 235 BIER tunnels, and never directly on P2MP LSP tunnel. 237 Section 4.2 describes the overall principle of transitioning a Legacy 238 MVPN using P2MP to a MVPN using BIER. We call it a tick-tock 239 transitioning. It also descirbes the detail use of new types of PTA 240 in BGP MVPN routes to indicate PEs to initialize the building of P2MP 241 based BIER forwarding. 243 Section 4.3 describes the Underlay protocols to build P2MP based BIER 244 forwarding briefly. 246 Section 4.4 describes how the widely deployed Live-Live protection in 247 MVPN can be inherited and developed. This will introduce a new 248 function to BIER Layer by re-using the Entropy field of the BIER 249 encapsulation. 251 4.2. MVPN Transition from P2MP to P2MP based BIER 253 This section describes a MVPN transitioning solution that eliminates 254 the per-flow state by introducing BIER MPLS encapsulation and 255 forwarding procedure in data-plane, while preserving the originally 256 deployed control-plane protocol and its features, especially when 257 some sort of path customizing being used. 259 When transitioning a MVPN using mLDP P2MP P-tunnel, then continue 260 using mLDP to build a P2MP based BIER forwarding, preserving the 261 original mLDP features. For example, mLDP uses static route to 262 specify a path other than the path of IGP. 264 When transitioning a MVPN using RSVP-TE P2MP P-tunnel, then continue 265 using RSVP-TE to build a P2MP based BIER forwarding, preserving the 266 original RSVP-TE features. For example, RSVP-TE use explicit path to 267 specify a path other than the path of IGP. 269 When transitioning a MVPN using PIM-SSM p-tunnel, then continue using 270 PIM-SSM to build a P2MP based BIER forwarding, preserving the 271 original PIM features. For example, PIM use explicit vector to 272 specify a path other than the path of IGP. 274 It is called a tick-tock transitioning, that is to introduce a new 275 standard BIER encapsulation defined in [RFC8296], while preserving 276 old control-plane protocols, features, and most of the devices. When 277 all or most of the devices in a network support BIER forwarding, then 278 we can do a further tick-tock transitioning, that is to introducing a 279 new control-plane protocol while preserving old data-plane 280 encapsulation, when the control-plane protocol can provide all the 281 needed features of the old ones. 283 4.2.1. Use of the PTA in x-PMSI A-D Routes 285 As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by 286 an x-PMSI A-D route identifies the P-tunnel that is used to 287 instantiate a particular PMSI. If a PMSI is to be instantiated by 288 P2MP LSP based BIER, the PTA is constructed by a BFIR, which is also 289 a Ingress LSR. This document defines the following Tunnel Types: 291 + TBD - RSVP-TE built P2MP BIER 293 + TBD - mLDP built P2MP BIER 295 + TBD - PIM-SSM built P2MP BIER 297 Allocation is expected from IANA for two new tunnel type codepoints 298 from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel 299 Types" registry. These codepoints will be used to indicate that the 300 PMSIs is instantiated by MLDP or RSVP-TE or PIM extension with 301 support of BIER. 303 When the Tunnel Type is set to RSVP-TE built P2MP BIER, the Tunnel 304 Identifier include two parts, as follows: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |BS Len | Max SI | Must Be Zero | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | P2MP ID | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | MUST be zero | Tunnel Range Base | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Extended Tunnel ID | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 1: PTA of RSVP-TE built P2MP BIER 320 BS Len: A 4 bits field. The values allowed in this field are 321 specified in section 2 of [RFC8296]. 323 Max SI: A 1 octet field. Maximum Set Identifier (section 1 of 324 [RFC8279]) used in the encapsulation for this BIER sub-domain. 326 : A ID as 327 carried in the RSVP-TE P2MP LSP SESSION Object defined in [RFC4875]. 329 The "Tunnel Range" is the set of P2MP LSPs beginning with the Tunnel 330 Range base and ending with ((Tunnel Range base)+(Tunnel Number)- 1). 332 A unique Tunnel Range is allocated for the BSL and a Sub-domain-ID 333 implicited by the P2MP. 335 The size of the Tunnel Range is determined by the number of Set 336 Identifiers (SI) (section 1 of [RFC8279]) that are used in the 337 topology of the P2MP-LSP. Each SI maps to a single Tunnel in the 338 Tunnel Range. The first Tunnel is for SI=0, the second Tunnel is for 339 SI=1, etc. 341 When the Tunnel Type is set to mLDP built P2MP BIER, the Tunnel 342 Identifier include two parts, as follows: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |BS Len | Max SI | Must Be Zero | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |P2MP Type(0x06)| Address Family | Address Length| 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 ~ Root Node Address ~ 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Opaque Length(0x0007) | OV Type(0x01) |OV Len(High 8b)| 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | (Low 8b)(0x04)| Tunnel Range Base(High 24b) | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | (Low 8b) | 358 +-+-+-+-+-+-+-+-+ 360 Figure 2: PTA of MLDP built P2MP BIER 362 BS Len: A 4 bits field. The values allowed in this field are 363 specified in section 2 of [RFC8296]. 365 Max SI: A 1 octet field. Maximum Set Identifier (section 1 of 366 [RFC8279]) used in the encapsulation for this BIER sub-domain. 368 : A P2MP Forwarding Equivalence Class 370 (FEC) Element, with a Generic LSP Identifier TLV as the opaque value 371 element, defined in [RFC6388]. 373 The "Tunnel Range" is the set of P2MP LSPs beginning with the Tunnel 374 Range base and ending with ((Tunnel Range base)+(Tunnel Number)- 1). 375 A unique Tunnel Range is allocated for the BSL and a Sub-domain-ID 376 implicited by the P2MP. 378 The size of the Tunnel Range is determined by the number of Set 379 Identifiers (SI) (section 1 of [RFC8279]) that are used in the 380 topology of the P2MP-LSP. Each SI maps to a single Tunnel in the 381 Tunnel Range. The first Tunnel is for SI=0, the second Tunnel is for 382 SI=1, etc. 384 When the Tunnel Type is set to PIM-SSM built P2MP BIER, the Tunnel 385 Identifier include two parts, as follows: 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |BS Len | Max SI | Must Be Zero | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 ~ P-Root Node Address ~ 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 ~ P-Multicast Group Base ~ 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 3: PTA of PIMSSM built P2MP BIER 399 BS Len: A 4 bits field. The values allowed in this field are 400 specified in section 2 of [RFC8296]. 402 Max SI: A 1 octet field. Maximum Set Identifier (section 1 of 403 [RFC8279]) used in the encapsulation for this BIER sub-domain. 405 : A ID to build a PIM- 406 SSM tree when build the P2MP BIER information for a specified SI. 407 Use a consecutive number of Groups from P-Multicast Group Base, 408 multiple PIM-SSM trees will be built for multiple SIs, and multiple 409 P2MP BIER information will be built accordingly. 411 When the Tunnel Type is any of the above, The "MPLS label" field 412 OPTIONAL contain an upstream-assigned non-zero MPLS label. It is 413 assigned by the router (a BFIR) that constructs the PTA. Absence of 414 an MPLS Label is indicated by setting the MPLS Label field to zero. 416 When the Tunnel Type is any of the above, two of the flags, LIR and 417 LIR-pF, in the PTA "Flags" field are meaningful. Details about the 418 use of these flags can be found in [RFC6513], 419 [I-D.ietf-bess-mvpn-expl-track] and [I-D.ietf-bier-mvpn]]. 421 4.2.2. Use of the PTA in Leaf A-D routes 423 Before an egress PE can receive a (C-S,C-G) flow from a given ingress 424 PE via RSVP-TE/MLDP P2MP LSP based BIER, the egress PE must have 425 received one of the following x-PMSI A-D routes from the ingress PE: 427 o A "more specific" x-PMSI A-D route, (C-S,C-G) S-PMSI A-D route. 429 o A "less specific" x-PMSI A-D route, (C-*,C-*), (C-*,C-G), or 430 (C-S,C-*) S-PMSI A-D route. 432 In which, the PTA tunnel Type is "RSVP-TE P2MP LSP based BIER" or 433 "MLDP P2MP LSP based BIER". 435 The rules for determining which x-PMSI A-D route is the match for 436 reception are given in [RFC6625]. If such a route is found, we refer 437 to it as the "matching x-PMSI A-D route." If no matching x-PMSI A-D 438 route for (C-S,C-G) is found, the egress PE cannot receive the 439 (C-S,C-G) flow from the ingress PE via RSVP-TE/MLDP P2MP LSP based 440 BIER until such time as a matching route is received. 442 When an egress PE determines that it needs to receive a (C-S,C-G) 443 flow from a particular ingress PE via RSVP-TE/MLDP P2MP LSP based 444 BIER, it originates a Leaf A-D route. Construction of the Leaf A-D 445 route generally follows the procedures specified in [RFC6514], or 446 optionally, the procedures specified in [I-D.ietf-bess-mvpn-expl- 447 track]. However, when RSVP-TE/MLDP P2MP LSP based BIER is being 448 used, the Leaf A-D route MUST carry a PTA that is constructed as 449 follows: 451 1. The tunnel type MUST be set to RSVP-TE/MLDP P2MP LSP based BIER, 452 corresponding to the PTA of the matching x-PMSI A-D route. 454 2. The MPLS label field SHOULD be set to zero. 456 3. The BFR-Prefix field of the Tunnel Identifier field MUST be set 457 to the egress PE's IP-Address. This IP-Address is the same as 458 the Originating Router's IP Addr field of the NLRI of the Leaf 459 A-D route. 461 When an ingress PE receives such a Leaf A-D route, it learns the BFR- 462 Prefix of the egress PE from the PTA. The ingress PE does not make 463 any use the value of the PTA's MPLS label field. 465 Failure to properly construct the PTA cannot always be detected by 466 the protocol, and will cause improper delivery of the data packets. 468 4.3. Building P2MP based BIER forwarding state 470 When P2MP based BIER are used, then it is not nessary to use IGP or 471 BGP to build the BIER routing table and forwarding table. Instead, 472 the BIER layer information is carried by MLDP or RSVP-TE or PIM, when 473 they building the P2MP tree or PIM tree. 475 The detail procedure for building P2MP based BIER forwarding state 476 using mLDP, RSVP-TE or PIM is outside the scope of this document. 478 4.4. Inheriting and Developing of Live-Live protection 480 Multicast has its special service protection requirement, especially 481 when multicast service is compressed or uncompressed video. 482 Accordingly, there are some multicast-specific methods of protection, 483 such as Live-Live. [RFC7431] defines a method of detecting failure 484 locally by comparing the packets received from live-live paths, but 485 it depends on a APP level encapsulation, which may not always be 486 satisfied in any deploment. Furthermore, it is inconsequential and 487 inefficient to do such a deep detecting in a data-plane forwarding 488 procedure. [I-D.ietf-bess-mvpn-fast-failover] also defines a Live- 489 Live method for protecting Multicast in MVPN, in which a method of 490 determining the status of a tunnel using "(S,G) counter information" 491 is defined, but it does not describe how to get such a (S,G) counter. 493 This document specifies one OPTIONAL extension to enhance Live-Live 494 protection, re-using the Entropy field of BIER header as a Sequence 495 number of multicast packet, on the condition that the field is not 496 used for ECMP, such as in the P2MP LSP topology. Currently ECMP is 497 not used for P2MP LSP, as per [RFC6790]. 499 This is an optional function of BIER Layer. If this function is 500 enabled, every BFR of the domain is required to support, which means: 502 1. The BFIR (and Ingress LSR) will push a sequence-number in the 503 Entropy field, per-flow per-packet. 505 2. The middle BFR will ignore the Entropy field, and not do the 506 selection of multi-tables. 508 3. The BFER (and Egress LSR) will do packet check from live-live 509 paths, and do forward packet with zero packet loss, on a per-flow 510 basis. 512 5. P2MP based BIER Forwarding Procedures 514 The MVPN application plays the role of the "multicast flow overlay" 515 as described in [RFC8279]. 517 This section specifies some OPTIONAL rules for forwarding a BIER- 518 encapsulated data packet within a P2MP topology underlay. It is part 519 of the "BIER Layer" function, which is mentioned as an alternative 520 deployment of BIER on some sort of multicast-specific tree, but not 521 detailedly explorered in [RFC8279]. 523 These OPTIONAL rules are some sort of customization and 524 simplification to the common BIER forwarding procedures, and will 525 produce the same results as the procedures in [RFC8279], on condition 526 that the underlay topology is a P2MP. 528 These OPTIONAL rules will lead to some new methods to deploy when 529 some nodes do not support BIER forwarding. These new methods and its 530 effects will be introduced as well. 532 5.1. Overview 534 As [RFC8279] describes: 536 1. BIER support using the default topology of the unicast IGP as the 537 routing underlay. To quote from [RFC8279]: "By default, each 538 sub-domain uses the default topology of the unicast IGP as the 539 routing underlay." 541 2. BIER also support using other topologies as the routing underlay, 542 including a tree topology. To quote from [RFC8279]: 543 "Alternatively, one could deploy a routing underlay that creates 544 a multicast-specific tree of some sort. Then BIER could be used 545 to forward multicast data packets along the multicast-specific 546 tree, while unicast packets follow the 'ordinary' OSPF best 547 path." 549 This document specifies one OPTIONAL Forwarding Procedure of BIER 550 encapsulation packet, on the condition that the BIER underlay 551 topology is P2MP LSP, as describes in the above sections. It is in 552 fact a customized forwarding procedure, and a detail exploration of 553 BIER forwarding along a multicast-specific tree. Comparing to the 554 common Forwarding Procedure described in [RFC8279], there is some 555 considerable simplification: 557 1. Not need to Edit the BitString when forwarding packet to 558 Neighbor, for the underlay P2MP topology is already loop-free and 559 duplicate-free. This can further lead to a method to by-pass the 560 BIER encapsulation packet when a node does not support the 561 BitString process. 563 2. Not need to do a disposition function by parsing the BitString, 564 for a P2MP can identify a disposition function by a node's Label 565 when the P2MP is built. This can further reduce the complex 566 BitString processing for legacy hardware on edge, and lead to a 567 method to deploy on exist network when an edge node does not 568 support BitString process. 570 3. Not need to use Entropy in the BIER Header, for current P2MP 571 topology is ECMP-excluding as per [RFC6790]. This can make it 572 possible to re-use the field for other function, and lead to a 573 method of inheriting and developing of the Live-Live protection, 574 as described in charter 4. 576 The main principle of the optional forwarding procedure of the P2MP 577 based BIER is, on the basis of P2MP forwarding procedure according to 578 the BIER-MPLS label, to use the BitString to prune the undesired P2MP 579 downstream. This is an enhancement to the standard P2MP forwarding. 581 The enhancement to the P2MP forwarding is to add a Forwarding BitMask 582 to existing NHLFE defined in [RFC3031], for checking with the 583 BitString in a packet, to determin whether the packet is to be 584 forwarded or pruned. If the checking result by AND'ing a packet's 585 BitString with the F-BM of the NHLFE (i.e., Packet->BitString &= 586 F-BM) is non-zero, then forward the packet to the next-hop indicated 587 by the NHLFE entry, and the Label is switched to the proper one in 588 the NHLFE. If the result is zero, then do not forward the packet to 589 the next-hop indicated by the NHLFE entry. 591 5.2. P2MP based BIER forwarding customization 593 For a P2MP tree, every node has a role of Root, Branch, Leaf, or Bud, 594 as specified in [RFC4611]. 596 EXAMPLE 1: Take the following figure as an example. 598 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 599 (Root) \ \ 1 (0:0001) 600 \ \ 601 ( E ) ( F ) 602 3 (0:0100) 2 (0:0010) 604 Figure 4: P2MP-based BIER Topology without BUD nodes 606 Forwarding Table on A: 608 NHLFE(TreeID, OutInterface, OutLabel, F-BM<0111>) 610 Forwarding Table on C: 612 ILM (inLabel, action, 613 Flag=Branch|CheckBS, BSL) 615 NHLFE(TreeID, OutInterface, OutLabel, F-BM<0001>) 617 NHLFE(TreeID, OutInterface, OutLabel, F-BM<0010>) 619 For Node C, the ability to receive a MPLS-encapsulation BIER packet, 620 match ILM and get a TreeID, replicate to NHLFE Entries of the TreeID 621 according to the result of AND'ing the BitString of packet and the 622 F-BM of a NHLFE Entry, is called a P-CAPABILITY, which means to 623 Process BitString in each packet. 625 Forwarding Table on B is the same to C. 627 Forwarding Table on D: 629 ILM (inLabel, action, 630 Flag=Leaf|CheckBS, BSL) 632 LEAF(TreeID, F-BM<0001>, flag=PopBIERincluding) 634 When Node D receive a MPLS-encapsulation BIER packet, it get the 635 Label and match ILM, then do a replication according to the LEAF and 636 check whether to proceed by AND'ing the BitString in the replicated 637 packet and the F-BM in the LEAF entry. When the AND'ing result is 638 non-zero then do a POP to the packet to disposit the whole BIER 639 header Including the BIER Label, which has a length of (12+BSL/8) 640 octets. 642 Node D need to have a P-CAPABILITY, for it need to Process BitString 643 in each packet to determin whether to replicate to a special LEAF, 644 and then disposit the whole BIER hearder Including the BIER Label and 645 forward the IP multicast packet further. Node D also need to do the 646 disposition as well, which is called a D-CAPABILITY. D-CAPABILITY 647 means to disposit the BIER header including or excluding the BIER 648 Label in the begining. Here PopBIERincluding means pop the BIER 649 header including the BIER Label, while PopBIERexcluding means pop the 650 BIER header excluding the BIER Label. 652 Forwarding Tables on E and F are same to D. 654 Comparing to the forwarding procedure defined in [RFC8279], there are 655 two benefits of using the customized P2MP based BIER forwarding: 657 1. Not need to walk every physical neighbor, but only need to walk 658 downstream neighbors on a P2MP tree. 660 2. Not need to edit the BitString in every packet, but only need to 661 swap the BIER Label. 663 EXAMPLE 2: Another example with P2MP BUD Nodes. 665 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 666 (Root) \ 1 (0:0001) 667 \ 668 ( E ) ------------ ( F ) 669 3 (0:0100) 2 (0:0010) 671 Figure 5: P2MP-based BIER Topology with BUD nodes 673 Forwarding Table on B (Branch Node): 675 ILM (inLabel, action, 676 Flag=Branch|CheckBS, BSL) 678 NHLFE(TreeID, OutInterface, OutLabel, F-BM<0110>) 680 NHLFE(TreeID, OutInterface, OutLabel, F-BM<0001>) 682 Node B, which is a Branch Node, only need to use its P-CAPABILITY. 684 Forwarding Table on E (BUD Node): 686 ILM (inLabel, action, 687 Flag=Bud|CheckBS, BSL) 689 NHLFE(TreeID, OutInterface, OutLabel, F-BM<0010>) 691 LEAF(TreeID, F-BM<0100>, flag=PopBIERincluding) 693 When Node E receive a MPLS-encapsulation BIER packet, it get the 694 Label and match ILM, then do a replication according to the NHLFEs 695 and check whether to proceed by AND'ing the BitString in the 696 replicated packet and the F-BM in the NHLFE/LEAF entry. When the 697 AND'ing result is non-zero for the second LEAF then do a POP to the 698 packet to disposit the whole BIER header, which has a length of 699 (12+BSL/8) octets. 701 Node E, which is a BUD Node, has both the two capacities: 702 P-CAPABILITY and D-CAPABILITY. P-CAPABILITY is need to be used for 703 every NHLFE/LEAF, and D-CAPABILITY is need for the NHLFE that has a 704 PopBIERincluding flag. 706 5.3. When Mid, Leaf or Bud nodes do not support P-CAPABILITY 708 The procedures of Section 5.2 presuppose that, within a given BIER 709 domain, all the nodes adjacent to a given BFR in a given routing 710 underlay are also BFRs. However, it is possible to use BIER even 711 when this is not the case. In this section, we describe procedures 712 that can be used if the routing underlay is a P2MP tree with BIER 713 information in the domain. 715 For a P2MP tree, every node has a role of Root, Branch, Leaf, or Bud. 716 The role is determined when the tree is built. The method is 717 suitable for conditions when Mid, Leaf or Bud nodes do not support 718 P-CAPABILITY. 720 EXAMPLE 1: Take Figure 4 as an example. 722 If D, F, E support BIER, and C don't support BIER, then we can 723 configure on C to indicate it to use P2MP for BIER packets 724 forwarding. Then C build a P2MP forwarding entry, while still pass 725 the BIER information in control-plane. For example, D send a P2MP 726 FEC Mapping message to C with a BitMask 0001, F send a P2MP FEC 727 Mapping message to C with a BitMask 0010, and C send a P2MP FEC 728 Mapping message to B with a BitMask, but C build a P2MP forward entry 729 like this: 731 ILM (inLabel, action, 732 Flag=Branch) 734 NHLFE(TreeID, OutInterface, OutLabel) 736 NHLFE(TreeID, OutInterface, OutLabel) 738 If D don't support BIER P-CAPABILITY, but it support BIER 739 D-CAPABILITY, then the above method is still valid. 741 Forwarding Table on D when D don't have a P-CAPABILITY: 743 ILM (inLabel, action, 744 Flag=Leaf, BSL) 746 NHLFE(TreeID, flag=PopBIERincluding) 748 When Node D receive a MPLS-encapsulation BIER packet, it get the 749 Label and match ILM, then do a replication according to the NHLFE but 750 don't do the check by AND'ing the BitString in the replicated packet 751 and the F-BM in the NHLFE entry. And then do a POP to the packet to 752 disposit the whole BIER header, which has a length of (12+BSL/8) 753 octets. 755 Another alternative form of Forwarding Table on D can also be the 756 following when D don't have a P-CAPABILITY: 758 ILM (inLabel, action, Flag=Leaf, 759 BSL) 761 When Node D receive a MPLS-encapsulation BIER packet, it get the 762 Label and match ILM, then do a POP action according to the ILM to pop 763 the whole (12+BSL/8) octets from the Label position. 765 EXAMPLE 2: Take BUD Node E in Figure 5 as another example. 767 Forwarding Table on Bud Node E when E don't have a P-CAPABILITY: 769 Forwarding Table on E when E don't have a P-CAPABILITY: 771 ILM (inLabel, action, Flag=Bud, 772 BSL) 774 NHLFE(TreeID, OutInterface, OutLabel) 776 LEAF(TreeID, flag=PopBIERincluding) 778 One can see that, this method can support widely Non-BIER Nodes in a 779 network, no matter the node has a Mid, Leaf or Bud role, and would 780 never result in any ingress-replication through unicast tunnel, which 781 may cause a overload on a link. 783 One can also see that, [RFC8279] only support Non BIER-capability 784 nodes being the Mid nodes, and never allow a BFER nodes to be Non 785 BIER-capability. 787 5.4. When Leaf or Bud nodes do not support D-CAPABILITY 789 A more tolerant variant of the above, when Leaf or Bud nodes do not 790 support D-CAPABILITY, would be the following: 792 EXAMPLE 1: Take Figure 4 as an example. 794 If D even don't support BIER P-CAPABILITY or D-CAPABILITY, then POP 795 the whole BIER Header except the first four octets Label field of a 796 packet before it come to D. This requires C to build a forwarding 797 table like this: 799 Forwarding Table on C (Branch Node): 801 ILM (inLabel, action, 802 Flag=Branch|CheckBS, BSL) 804 NHLFE(TreeID, OutInterface, OutLabel, F-BM<0001>, 805 Flag=PopBIERexcluding) 807 NHLFE(TreeID, OutInterface, OutLabel, F-BM<0010>) 809 The Flag PopBIERexcluding means POP the BIER Header excluding the 810 first 4 octets BIER Label in a packet, that is a Length of (8+BSL/8) 812 If D don't support BIER P-CAPABILITY or D-CAPABILITY, and C don't 813 support BIER P-CAPABILITY, then it requires B to build a forwarding 814 table, to ensure the BIER Header except the first four octets Label 815 field of a packet is popped before replicated to C, and requires C to 816 build a forwarding table of a pure P2MP branch, and requires F to 817 build a forwarding table of a pure P2MP Leaf. Their forwarding 818 tables are like below: 820 Forwarding Table on B (Branch Node): 822 ILM (inLabel, action, 823 Flag=Branch|CheckBS, BSL) 825 NHLFE(TreeID, OutInterface, OutLabel, F-MB<0011>, 826 Flag=PopBIERexcluding) 828 NHLFE(TreeID, OutInterface, OutLabel, F-BM<0100>) 830 Forwarding Table on C (Branch Node): 832 ILM (inLabel, action, 833 Flag=Branch) 835 NHLFE(TreeID, OutInterface, OutLabel) 837 NHLFE(TreeID, OutInterface, OutLabel) 839 Forwarding Table on D (Branch Node): 841 ILM (inLabel, action, Flag=Leaf) 843 Here PopLabel mean to pop the Label, which is in fact a P2MP LSP 844 Label. It is a basic capability of any LSR. 846 Forwarding Table on F (Branch Node): 848 ILM (inLabel, action, Flag=Leaf) 850 Here PopLabel mean to pop the Label, which is in fact a P2MP LSP 851 Label. It is a basic capability of any LSR, and the Forwarding table 852 on F is in fact a P2MP one. 854 Note that, alrough F support BIER, which means it can deal with a 855 BIER packet, but it must downshift its forwarding table to a pure 856 P2MP one, because the packet it received doesn't include a BIER 857 Header but a P2MP Label packet due to the POP behaving of its 858 upstream node. 860 EXAMPLE 2: Take Figure 5 as another example. 862 If E even don't support BIER P-CAPABILITY or D-CAPABILITY, then POP 863 the whole BIER Header Except the first four octets Label field of a 864 packet before it come to D. This requires B to build a forwarding 865 table like this: 867 Forwarding Table on B (Branch Node): 869 ILM (inLabel, action, 870 Flag=Branch|CheckBS, BSL) 872 NHLFE(TreeID, OutInterface, OutLabel, F-MB<0011>) 874 NHLFE(TreeID, OutInterface, OutLabel, F-BM<0100>, 875 Flag=PopBIERexcluding) 877 Forwarding Table on E (Bud Node): 879 ILM (inLabel, action, Flag=Bud) 881 NHLFE(TreeID, OutInterface, OutLabel) 883 LEAF(TreeID, flag=PopLabel) 885 Forwarding Table on F (Branch Node): 887 ILM (inLabel, action, Flag=Leaf) 889 Note that, alrough F support BIER, which means it can deal with a 890 BIER packet, but it must downshift its forwarding table to a pure 891 P2MP Leaf, because the packet it received doesn't include a BIER 892 Header but a P2MP Label packet due to the POP behaving of its 893 upstream node. 895 One can see that, when some Leaf or Bud nodes even don't have a 896 D-CAPABILITY, we can do a POP action to dispositing the BIER header 897 excluding the BIER Label in the begining before the packet arrive the 898 node. This is similar to a Penultimate Hop Popping in a P2P LSP, and 899 we call it Upstream Hop Popping in P2MP based BIER. 901 6. Provisioning Considerations 903 P2MP based BIER use concepts of both P2MP and BIER. Some 904 provisioning considerations list below: 906 Sub-domain: 908 In P2MP based BIER, every P2MP is a specific BIER underlay topology, 909 and an implicit Sub-domain. RSVP-TE/MLDP/PIM build the BIER 910 information of the implicit sub-domain when building the P2MP LSP or 911 PIM tree. MVPN get the implicit sub-domain by provisioning. 913 In the following conditions, there may be requirements to configure 914 an explicit sub-domain ID for P2MP based BIER: 916 1. P2MP LSP based BIER, use the native procedure of forwarding 917 described in [RFC8279], which require Consistent Per-Sub-domain 918 BIFT. 920 2. P2MP LSP based BIER is shared by multiple VPNs, and an explicit 921 sub-domain ID is configured as anchor for using by these VPNs. 923 When explicitly configing a sub-domain ID for P2MP LSP based BIER, 924 the ID should be great than 255. For the [0-255] has been defined to 925 use by IGP, BGP and MVPN, as specified in 926 [I-D.ietf-bier-ospf-bier-extensions], 927 [I-D.ietf-bier-isis-extensions], [I-D.ietf-bier-idr-extensions] and 928 [I-D.ietf-bier-mvpn]. 930 BFR-prefix: 932 In P2MP LSP based BIER, every BFR is also a LSR. So the BFR-prefix 933 in the sub-domain is by default identified by LSR-id. Additionally, 934 When BFR/LSR is also a MVPN PE, BFR-prefix is also the same as 935 Originating Router's IP Address of x-PMSI A-D route or Leaf A-D 936 route. 938 BFR-id: 940 When using protocols like RSVP-TE, which initializes P2MP LSP from a 941 specific Ingress Node, BFR-id which is unique in P2MP LSP scope, can 942 be auto-provisioned by Ingress Node, or conventionally configure on 943 every Egress Nodes. 945 BSL and BIER-MPLS Label Block Size: 947 In P2MP LSP based BIER, Every P2MP LSP or implicit sub-domain 948 requires a single BSL, and a specific BIER-MPLS Label block size for 949 this BSL. 951 VPN-Label: 953 The P2MP based BIER 'P-tunnel' can be shared by multiple VPNs or a 954 single VPN. When a P2MP based BIER being shared by multiple VPNs, an 955 Upstream-assigned VPN-Label is required. It can be auto-provisioned 956 or manual configured by the BFIR or Ingress LSR. 958 In fact, [RFC6513] has defined the method of "Aggregating Multiple 959 MVPNs on a Single P-Tunnel". But unfortunately it is not widely 960 deployed because of the serious trade-off between state saving and 961 bandwidth waste. The BIER encapsulation and forwarding method give 962 it a chance to eliminate the trade-off while gaining a completely 963 state saving. 965 Even when such an aggregating is not used, it is still adequate to 966 use BIER to save state by sharing one P2MP based BIER "p-tunnel" for 967 multi flows in one specific VPN. 969 For seamless transitioning from legacy MVPN deployment and existing 970 network, it is recommended not to use such an aggregating, as well as 971 to use such an aggregating. 973 7. IANA Considerations 975 Allocation is expected from IANA for two new tunnel type codepoints 976 for "RSVP-TE built P2MP based BIER", "MLDP built P2MP based BIER" and 977 "PIM built P2MP based BIER" from the "P-Multicast Service Interface 978 Tunnel (PMSI Tunnel) Tunnel Types" registry. 980 8. Security Considerations 982 This document does not introduce any new security considerations 983 other than already discussed in [RFC8279]. 985 9. Acknowledgements 987 TBD 989 10. References 990 10.1. Normative References 992 [I-D.ietf-bess-mvpn-expl-track] 993 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 994 "Explicit Tracking with Wild Card Routes in Multicast 995 VPN", draft-ietf-bess-mvpn-expl-track-08 (work in 996 progress), February 2018. 998 [I-D.ietf-bess-mvpn-fast-failover] 999 Morin, T. and R. Kebler, "Multicast VPN fast upstream 1000 failover", draft-ietf-bess-mvpn-fast-failover-02 (work in 1001 progress), March 2017. 1003 [I-D.ietf-bier-idr-extensions] 1004 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 1005 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 1006 idr-extensions-05 (work in progress), March 2018. 1008 [I-D.ietf-bier-isis-extensions] 1009 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 1010 "BIER support via ISIS", draft-ietf-bier-isis- 1011 extensions-09 (work in progress), February 2018. 1013 [I-D.ietf-bier-mvpn] 1014 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 1015 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 1016 mvpn-10 (work in progress), February 2018. 1018 [I-D.ietf-bier-ospf-bier-extensions] 1019 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 1020 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 1021 for BIER", draft-ietf-bier-ospf-bier-extensions-15 (work 1022 in progress), February 2018. 1024 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1025 Label Switching Architecture", RFC 3031, 1026 DOI 10.17487/RFC3031, January 2001, 1027 . 1029 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1030 Yasukawa, Ed., "Extensions to Resource Reservation 1031 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1032 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1033 DOI 10.17487/RFC4875, May 2007, 1034 . 1036 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 1037 Thomas, "Label Distribution Protocol Extensions for Point- 1038 to-Multipoint and Multipoint-to-Multipoint Label Switched 1039 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 1040 . 1042 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1043 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1044 2012, . 1046 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1047 Encodings and Procedures for Multicast in MPLS/BGP IP 1048 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1049 . 1051 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 1052 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 1053 RFC 6625, DOI 10.17487/RFC6625, May 2012, 1054 . 1056 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1057 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1058 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1059 . 1061 [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. 1062 Decraene, "Multicast-Only Fast Reroute", RFC 7431, 1063 DOI 10.17487/RFC7431, August 2015, 1064 . 1066 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1067 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1068 Explicit Replication (BIER)", RFC 8279, 1069 DOI 10.17487/RFC8279, November 2017, 1070 . 1072 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1073 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1074 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1075 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1076 2018, . 1078 10.2. Informative References 1080 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1081 Requirement Levels", BCP 14, RFC 2119, 1082 DOI 10.17487/RFC2119, March 1997, 1083 . 1085 Authors' Addresses 1087 Jingrong Xie 1088 Huawei 1089 Q15 Huawei Campus, No.156 Beiqing Rd. 1090 Beijing 100095 1091 China 1093 Email: xiejingrong@huawei.com 1095 Mike McBride 1096 Huawei Technologies 1098 Email: mmcbride7@gmail.com 1100 Mach Chen 1101 Huawei 1103 Email: mach.chen@huawei.com 1105 Liang Geng 1106 China Mobile 1107 Beijing 100053 1108 China 1110 Email: gengliang@chinamobile.com