idnits 2.17.00 (12 Aug 2021) /tmp/idnits19454/draft-xie-bier-mvpn-mpls-p2mp-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 1412 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 401, but not defined == Unused Reference: 'RFC6625' is defined on line 808, but no explicit reference was found in the text == Outdated reference: draft-ietf-bess-mvpn-expl-track has been published as RFC 8534 == Outdated reference: draft-ietf-bier-mvpn has been published as RFC 8556 Summary: 0 errors (**), 0 flaws (~~), 5 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 M. McBride 4 Intended status: Standards Track M. Chen 5 Expires: January 3, 2019 Huawei Technologies 6 L. Geng 7 China Mobile 8 July 2, 2018 10 Multicast VPN Using MPLS P2MP and BIER 11 draft-xie-bier-mvpn-mpls-p2mp-02 13 Abstract 15 MVPN is a widely deployed multicast service with mLDP or RSVP-TE P2MP 16 as the P-tunnel. Bit Index Explicit Replication (BIER) is an 17 architecture that provides optimal multicast forwarding without 18 requiring intermediate routers to maintain any per-flow state by 19 using a multicast-specific BIER header. This document introduces a 20 seamless transition mechanism from legacy MVPN using mLDP/RSVP-TE 21 P2MP to MVPN using BIER by combining P2MP and BIER to form a P2MP 22 based BIER as the P-tunnel. This will leverage the widely supported 23 P2MP capability in both data-plane and control-plane, and will help 24 introducing BIER in existing multicast networks to shift multicast 25 delivery from MVPN using mLDP/RSVP-TE P2MP by two means: It is easier 26 and more efficient for legacy routers to support BIER forwarding on 27 the basis of widely supported P2MP forwarding, and it is more 28 seamless for existing multicast networks to deploy BIER when some 29 routers do not support BIER forwarding. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 3, 2019. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 74 4. MVPN using P2MP based BIER . . . . . . . . . . . . . . . . . 5 75 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.2. MVPN Transition from P2MP to P2MP based BIER . . . . . . 5 77 4.2.1. Use of the PTA in x-PMSI A-D Routes . . . . . . . . . 6 78 4.3. Building P2MP based BIER forwarding state . . . . . . . . 8 79 5. P2MP based BIER Forwarding Procedures . . . . . . . . . . . . 8 80 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 81 5.2. P2MP based BIER forwarding . . . . . . . . . . . . . . . 9 82 5.3. When Mid, Leaf or Bud nodes do not support P-CAPABILITY . 11 83 5.4. When Leaf or Bud nodes do not support D-CAPABILITY . . . 13 84 6. Provisioning Considerations . . . . . . . . . . . . . . . . . 15 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 90 10.2. Informative References . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 [RFC6513] and [RFC6514] specify the protocols and procedures that a 96 Service Provider (SP) can use to provide Multicast Virtual Private 97 Network (MVPN) service to its customers. Multicast tunnels are 98 created through an SP's backbone network; these are known as 99 "P-tunnels". The P-tunnels are used for carrying multicast traffic 100 across the backbone. The MVPN specifications allow the use of 101 several different kinds of P-tunnel technology, such as mLDP P2MP and 102 RSVP-TE P2MP. It is common for such a P-tunnel having a multicast- 103 specific path. 105 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 106 that provides optimal multicast forwarding through a "multicast 107 domain", without requiring intermediate routers to maintain any per- 108 flow state, by using a multicast-specific BIER header (per 109 [RFC8296]). 111 [I-D.ietf-bier-mvpn] delivers a solution of MVPN using SPF based BIER 112 defined in [RFC8279]. It can not, however, support a multicast- 113 specific path well, something common in legacy MVPN deployment. 115 [RFC8279] provides a solution to support mid nodes without BIER- 116 capability. It cannot, however, support deployment on a network that 117 has edge nodes without BIER-capability, which may be common in some 118 SP-networks, especially when most of the nodes in a network or part 119 of a network are edge or service nodes. 121 This document introduces a seamless transition mechanism from legacy 122 MVPN to MVPN using P2MP based BIER, by applying a BIER encapsulation 123 in data-plane to eliminate per-flow states, while preserving existing 124 features such as multicast-specific PATH. 126 It also introduces a seamless deployment solution on networks with 127 Non-BIER-capability Edge nodes and/or Mid nodes, by exploring the 128 P2MP/tree based BIER forwarding procedure in detail. Such a P2MP/ 129 tree based BIER is mentioned but not explored in detail in RFC8279. 131 2. Terminology 133 Readers of this document are assumed to be familiar with the 134 terminology and concepts of the documents listed as Normative 135 References. For convenience, some of the more frequently used terms 136 and new terms list below. 138 o LSP: Label Switch Path 140 o LSR: Label Switching Router 141 o P2MP: Point to Multi-point 143 o P-tunnel: A multicast tunnel through the network of one or more 144 SPs. P-tunnels are used to transport MVPN multicast data. 146 o PMSI: Provider Multicast Service Interface 148 o x-PMSI A-D route: a route that is either an I-PMSI A-D route or an 149 S-PMSI A-D route. 151 o PTA: PMSI Tunnel attribute. A type of BGP attribute known as the 152 PMSI Tunnel attribute. 154 o P2MP based BIER: BIER using P2MP LSP as topology 156 o P-CAPABILITY: A capability to Process BitString in BIER Header of 157 a packet. 159 o D-CAPABILITY: A capability to Disposit BIER Header of a packet, 160 including or excluding the BIER Label. 162 o BSL: Bit String Length, that is 64, 128, 256, etc (per [RFC8279]). 164 3. Applicability Statement 166 The BIER architecture document [RFC8279] describes how each node 167 forwards BIER packets hop by hop to neighboring nodes without 168 generating duplicate packets. This forwarding is for the case where 169 a form of underlay called "many to many " and built by IGP is used. 170 Obviously, the case of underlay of "one to many" or P2MP is a simpler 171 scenario, and the forwarding procedure naturally applies. However, 172 as is well-known, such a forwarding procedure requires the support of 173 hardware. The usage of the same forwarding method for both complex 174 scenarios and simple scenarios will inevitably require complex 175 hardware forwarding. 177 This document describes how BIER forwarding can be customized and 178 simplified with an underlay of "one to many" or P2MP (see chapter 5). 179 This customization and simplification eliminates some of the 180 unnecessary data plane processing and so is easier to implement with 181 existing hardware. Based on this customization of the forwarding 182 method for P2MP-based BIER, a variety of Partial Deployment methods 183 are given for the different capabilities of the hardware to support 184 BIER forwarding. Compared with RFC8279, when there is no BIER 185 forwarding capability on edge nodes, Partial Deployment can be 186 carried out ; For the case where the intermediate node has no BIER 187 forwarding capability, P2MP forwarding can be used without the need 188 for unicast replication. 190 This document also describes a MVPN Transition solution that 191 eliminates the per-flow state by introducing BIER MPLS encapsulation 192 and forwarding in data-plane, while preserving the original control- 193 plane protocol and its features, especially when some sort of path 194 customizing being used. The said path customization include RSVP-TE 195 P2MP using an explicit path, and MLDP P2MP where static route was 196 used. These features can continue to retain, making the transition 197 process seamless. 199 4. MVPN using P2MP based BIER 201 4.1. Overview 203 According to [RFC8279], the P2MP based BIER is a BIER which using a 204 form of tree as the underlay. The P2MP LSP is not only a LSP, but 205 also a topology as the BIER underlay. The P2MP based BIER is 206 P-tunnel, which is used for bearing multicast flows. Every flow can 207 be seen as binding to an independent tunnel, which is constructed by 208 the BitString in the BIER header of every packet of the flow. 209 Multicast flows are transported in SPMSI-only mode, on P2MP based 210 BIER tunnels, and never directly on P2MP LSP tunnel. 212 Section 4.2 describes the overall principle of transitioning a Legacy 213 MVPN using P2MP to a MVPN using BIER. It also descirbes the detail 214 use of new types of PTA in BGP MVPN routes to indicate PEs to 215 initialize the building of P2MP based BIER forwarding. 217 Section 4.3 describes the Underlay protocols to build P2MP based BIER 218 forwarding briefly. 220 4.2. MVPN Transition from P2MP to P2MP based BIER 222 This section describes a MVPN transitioning solution that eliminates 223 the per-flow state by introducing BIER MPLS encapsulation and 224 forwarding procedure in data-plane, while preserving the originally 225 deployed control-plane protocol and its features, especially when 226 some sort of path customizing being used. 228 When transitioning a MVPN using mLDP P2MP P-tunnel, then continue 229 using mLDP to build a P2MP based BIER forwarding, preserving the 230 original mLDP features. For example, mLDP uses static route to 231 specify a path other than the path of IGP. 233 When transitioning a MVPN using RSVP-TE P2MP P-tunnel, then continue 234 using RSVP-TE to build a P2MP based BIER forwarding, preserving the 235 original RSVP-TE features. For example, RSVP-TE use explicit path to 236 specify a path other than the path of IGP. 238 4.2.1. Use of the PTA in x-PMSI A-D Routes 240 As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by 241 an x-PMSI A-D route identifies the P-tunnel that is used to 242 instantiate a particular PMSI. If a PMSI is to be instantiated by 243 P2MP LSP based BIER, the PTA is constructed by a BFIR, which is also 244 a Ingress LSR. This document defines the following Tunnel Types: 246 + TBD - RSVP-TE built P2MP BIER 248 + TBD - mLDP built P2MP BIER 250 Allocation is expected from IANA for two new tunnel type codepoints 251 from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel 252 Types" registry. These codepoints will be used to indicate that the 253 PMSIs is instantiated by MLDP or RSVP-TE extension with support of 254 BIER. 256 When the Tunnel Type is set to RSVP-TE built P2MP BIER, the Tunnel 257 Identifier include two parts, as follows: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 |BS Len | Max SI | Must Be Zero | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | P2MP ID | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | MUST be zero | Tunnel Range Base | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Extended Tunnel ID | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 1: PTA of RSVP-TE built P2MP BIER 273 BS Len: A 4 bits field. The values allowed in this field are 274 specified in section 2 of [RFC8296]. 276 Max SI: A 1 octet field. Maximum Set Identifier (section 1 of 277 [RFC8279]) used in the encapsulation for this BIER sub-domain. 279 : A ID as 280 carried in the RSVP-TE P2MP LSP SESSION Object defined in [RFC4875]. 282 The "Tunnel Range" is the set of P2MP LSPs beginning with the Tunnel 283 Range base and ending with ((Tunnel Range base)+(Tunnel Number)- 1). 284 A unique Tunnel Range is allocated for the BSL and a Sub-domain-ID 285 implicited by the P2MP. 287 The size of the Tunnel Range is determined by the number of Set 288 Identifiers (SI) (section 1 of [RFC8279]) that are used in the 289 topology of the P2MP-LSP. Each SI maps to a single Tunnel in the 290 Tunnel Range. The first Tunnel is for SI=0, the second Tunnel is for 291 SI=1, etc. 293 When the Tunnel Type is set to mLDP built P2MP BIER, the Tunnel 294 Identifier include two parts, as follows: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |BS Len | Max SI | Must Be Zero | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |P2MP Type(0x06)| Address Family | Address Length| 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 ~ Root Node Address ~ 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Opaque Length(0x0007) | OV Type(0x01) |OV Len(High 8b)| 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | (Low 8b)(0x04)| Tunnel Range Base(High 24b) | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | (Low 8b) | 310 +-+-+-+-+-+-+-+-+ 312 Figure 2: PTA of MLDP built P2MP BIER 314 BS Len: A 4 bits field. The values allowed in this field are 315 specified in section 2 of [RFC8296]. 317 Max SI: A 1 octet field. Maximum Set Identifier (section 1 of 318 [RFC8279]) used in the encapsulation for this BIER sub-domain. 320 : A P2MP Forwarding Equivalence Class 322 (FEC) Element, with a Generic LSP Identifier TLV as the opaque value 323 element, defined in [RFC6388]. 325 The "Tunnel Range" is the set of P2MP LSPs beginning with the Tunnel 326 Range base and ending with ((Tunnel Range base)+(Tunnel Number)- 1). 327 A unique Tunnel Range is allocated for the BSL and a Sub-domain-ID 328 implicited by the P2MP. 330 The size of the Tunnel Range is determined by the number of Set 331 Identifiers (SI) (section 1 of [RFC8279]) that are used in the 332 topology of the P2MP-LSP. Each SI maps to a single Tunnel in the 333 Tunnel Range. The first Tunnel is for SI=0, the second Tunnel is for 334 SI=1, etc. 336 When the Tunnel Type is any of the above, The "MPLS label" field 337 contain an upstream-assigned non-zero MPLS label. It is assigned by 338 the router (a BFIR) that constructs the PTA. Absence of an MPLS 339 Label is indicated by setting the MPLS Label field to zero. 341 When the Tunnel Type is any of the above, two of the flags, LIR and 342 LIR-pF, in the PTA "Flags" field are meaningful. Details about the 343 use of these flags can be found in [RFC6513], 344 [I-D.ietf-bess-mvpn-expl-track] and [I-D.ietf-bier-mvpn]]. 346 4.3. Building P2MP based BIER forwarding state 348 When P2MP based BIER are used, then it is not nessary to use IGP or 349 BGP to build the BIER routing table and forwarding table. Instead, 350 the BIER layer information is carried by MLDP or RSVP-TE, when they 351 build the P2MP tree. 353 The detail procedure for building P2MP based BIER forwarding state 354 using mLDP or RSVP-TE is outside the scope of this document. 356 5. P2MP based BIER Forwarding Procedures 358 5.1. Overview 360 This document specifies one OPTIONAL Forwarding Procedure of BIER 361 encapsulation packet, on the condition that the BIER underlay 362 topology is P2MP LSP, as describes in the above sections. It is in 363 fact a customized forwarding procedure, and a detail exploration of 364 BIER forwarding along a multicast-specific tree. Comparing to the 365 common Forwarding Procedure described in [RFC8279], there is some 366 considerable simplification: 368 1. Not need to Edit the BitString when forwarding packet to 369 Neighbor, for the underlay P2MP topology is already loop-free and 370 duplicate-free. This can further lead to a method to by-pass the 371 BIER encapsulation packet when a node does not support the 372 BitString process. 374 2. Not need to do a disposition function by parsing the BitString, 375 for a P2MP can identify a disposition function by a node's Label 376 when the P2MP is built. This can further reduce the complex 377 BitString processing for legacy hardware on edge, and lead to a 378 method to deploy on exist network when an edge node does not 379 support BitString process. 381 The main principle of the optional forwarding procedure of the P2MP 382 based BIER is, on the basis of P2MP forwarding procedure according to 383 the BIER-MPLS label, to use the BitString to prune/filter the 384 undesired P2MP downstream. This is an smooth enhancement to the 385 widely deployed P2MP forwarding, and easier to deploy on existing 386 routers comparing to the many-to-many BIER forwarding. 388 The enhancement to the P2MP forwarding is to add a Forwarding BitMask 389 to existing NHLFE defined in [RFC3031], for checking with the 390 BitString in a packet, to determin whether the packet is to be 391 forwarded or pruned. If the checking result by AND'ing a packet's 392 BitString with the F-BM of the NHLFE (i.e., Packet->BitString &= 393 F-BM) is non-zero, then forward the packet to the next-hop indicated 394 by the NHLFE entry, and the Label is switched to the proper one in 395 the NHLFE. If the result is zero, then do not forward the packet to 396 the next-hop indicated by the NHLFE entry. 398 5.2. P2MP based BIER forwarding 400 For a P2MP tree, every node has a role of Root, Branch, Leaf, or Bud, 401 as specified in [RFC4611]. 403 EXAMPLE 1: Take the following figure as an example. 405 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 406 (Root) \ \ 1 (0:0001) 407 \ \ 408 ( E ) ( F ) 409 3 (0:0100) 2 (0:0010) 411 Figure 3: P2MP-based BIER Topology without BUD nodes 413 Forwarding Table on A: 415 o NHLFE(TreeID, OutInterface, OutLabel, F-BM<0111>) 417 Forwarding Table on C: 419 o ILM(inLabel, action, Flag=Branch|CheckBS, BSL) 421 o NHLFE(TreeID, OutInterface, OutLabel, F-BM<0001>) 423 o NHLFE(TreeID, OutInterface, OutLabel, F-BM<0010>) 425 For Node C, the ability to receive a MPLS-encapsulation BIER packet, 426 match ILM and get a TreeID, replicate to NHLFE Entries of the TreeID 427 according to the result of AND'ing the BitString of packet and the 428 F-BM of a NHLFE Entry, is called a P-CAPABILITY, which means to 429 Process BitString in each packet. 431 Forwarding Table on B is the same to C. 433 Forwarding Table on D: 435 o ILM(inLabel, action, Flag=Leaf|CheckBS, BSL) 437 o LEAF(TreeID, F-BM<0001>, flag=PopBIERincluding) 439 When Node D receive a MPLS-encapsulation BIER packet, it get the 440 Label and match ILM, then do a replication according to the LEAF and 441 check whether to proceed by AND'ing the BitString in the replicated 442 packet and the F-BM in the LEAF entry. When the AND'ing result is 443 non-zero then do a POP to the packet to disposit the whole BIER 444 header Including the BIER Label, which has a length of (12+BSL/8) 445 octets. 447 Node D need to have a P-CAPABILITY, for it need to Process BitString 448 in each packet to determin whether to replicate to a special LEAF, 449 and then disposit the whole BIER hearder Including the BIER Label and 450 forward the IP multicast packet further. Node D also need to do the 451 disposition as well, which is called a D-CAPABILITY. D-CAPABILITY 452 means to disposit the BIER header including or excluding the BIER 453 Label in the begining. Here PopBIERincluding means pop the BIER 454 header including the BIER Label, while PopBIERexcluding means pop the 455 BIER header excluding the BIER Label. 457 Forwarding Tables on E and F are same to D. 459 Comparing to the forwarding procedure defined in [RFC8279], there are 460 two benefits of using the customized P2MP based BIER forwarding: 462 1. Not need to walk every physical neighbor, but only need to walk 463 downstream neighbors on a P2MP tree. 465 2. Not need to edit the BitString in every packet, but only need to 466 swap the BIER Label. 468 EXAMPLE 2: Another example with P2MP BUD Nodes. 470 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 471 (Root) \ 1 (0:0001) 472 \ 473 ( E ) ------------ ( F ) 474 3 (0:0100) 2 (0:0010) 476 Figure 4: P2MP-based BIER Topology with BUD nodes 478 Forwarding Table on B (Branch Node): 480 o ILM(inLabel, action, Flag=Branch|CheckBS, BSL) 481 o NHLFE(TreeID, OutInterface, OutLabel, F-BM<0110>) 483 o NHLFE(TreeID, OutInterface, OutLabel, F-BM<0001>) 485 Node B, which is a Branch Node, only need to use its P-CAPABILITY. 487 Forwarding Table on E (BUD Node): 489 o ILM(inLabel, action, Flag=Bud|CheckBS, BSL) 491 o NHLFE(TreeID, OutInterface, OutLabel, F-BM<0010>) 493 o LEAF(TreeID, F-BM<0100>, flag=PopBIERincluding) 495 When Node E receive a MPLS-encapsulation BIER packet, it get the 496 Label and match ILM, then do a replication according to the NHLFEs 497 and check whether to proceed by AND'ing the BitString in the 498 replicated packet and the F-BM in the NHLFE/LEAF entry. When the 499 AND'ing result is non-zero for the second LEAF then do a POP to the 500 packet to disposit the whole BIER header, which has a length of 501 (12+BSL/8) octets. 503 Node E, which is a BUD Node, has both the two capacities: 504 P-CAPABILITY and D-CAPABILITY. P-CAPABILITY is need to be used for 505 every NHLFE/LEAF, and D-CAPABILITY is need for the NHLFE that has a 506 PopBIERincluding flag. 508 5.3. When Mid, Leaf or Bud nodes do not support P-CAPABILITY 510 The procedures of Section 5.2 presuppose that, within a given BIER 511 domain, all the nodes adjacent to a given BFR in a given routing 512 underlay are also BFRs. However, it is possible to use BIER even 513 when this is not the case. In this section, we describe procedures 514 that can be used if the routing underlay is a P2MP tree with BIER 515 information in the domain. 517 For a P2MP tree, every node has a role of Root, Branch, Leaf, or Bud. 518 The role is determined when the tree is built. The method is 519 suitable for conditions when Mid, Leaf or Bud nodes do not support 520 P-CAPABILITY. 522 EXAMPLE 1: Take Figure 4 as an example. 524 If D, F, E support BIER, and C don't support BIER, then we can 525 configure on C to indicate it to use P2MP for BIER packets 526 forwarding. Then C build a P2MP forwarding entry, while still pass 527 the BIER information in control-plane. For example, D send a P2MP 528 FEC Mapping message to C with a BitMask 0001, F send a P2MP FEC 529 Mapping message to C with a BitMask 0010, and C send a P2MP FEC 530 Mapping message to B with a BitMask, but C build a P2MP forward entry 531 like this: 533 o ILM(inLabel, action, Flag=Branch) 535 o NHLFE(TreeID, OutInterface, OutLabel) 537 o NHLFE(TreeID, OutInterface, OutLabel) 539 If D don't support BIER P-CAPABILITY, but it support BIER 540 D-CAPABILITY, then the above method is still valid. 542 Forwarding Table on D when D don't have a P-CAPABILITY: 544 o ILM(inLabel, action, Flag=Leaf, BSL) 546 o NHLFE(TreeID, flag=PopBIERincluding) 548 When Node D receive a MPLS-encapsulation BIER packet, it get the 549 Label and match ILM, then do a replication according to the NHLFE but 550 don't do the check by AND'ing the BitString in the replicated packet 551 and the F-BM in the NHLFE entry. And then do a POP to the packet to 552 disposit the whole BIER header, which has a length of (12+BSL/8) 553 octets. 555 Another alternative form of Forwarding Table on D can also be the 556 following when D don't have a P-CAPABILITY: 558 o ILM(inLabel, action, Flag=Leaf, BSL) 560 When Node D receive a MPLS-encapsulation BIER packet, it get the 561 Label and match ILM, then do a POP action according to the ILM to pop 562 the whole (12+BSL/8) octets from the Label position. 564 EXAMPLE 2: Take BUD Node E in Figure 5 as another example. 566 Forwarding Table on Bud Node E when E don't have a P-CAPABILITY: 568 Forwarding Table on E when E don't have a P-CAPABILITY: 570 o ILM(inLabel, action, Flag=Bud, BSL) 572 o NHLFE(TreeID, OutInterface, OutLabel) 574 o LEAF(TreeID, flag=PopBIERincluding) 575 One can see that, this method can support widely Non-BIER Nodes in a 576 network, no matter the node has a Mid, Leaf or Bud role, and would 577 never result in any ingress-replication through unicast tunnel, which 578 may cause a overload on a link. 580 One can also see that, [RFC8279] only support Non BIER-capability 581 nodes being the Mid nodes, and never allow a BFER nodes to be Non 582 BIER-capability. 584 5.4. When Leaf or Bud nodes do not support D-CAPABILITY 586 A more tolerant variant of the above, when Leaf or Bud nodes do not 587 support D-CAPABILITY, would be the following: 589 EXAMPLE 1: Take Figure 4 as an example. 591 If D even don't support BIER P-CAPABILITY or D-CAPABILITY, then POP 592 the whole BIER Header except the first four octets Label field of a 593 packet before it come to D. This requires C to build a forwarding 594 table like this: 596 Forwarding Table on C (Branch Node): 598 o ILM(inLabel, action, Flag=Branch|CheckBS, BSL) 600 o NHLFE(TreeID, OutInterface, OutLabel, F-BM<0001>, 601 Flag=PopBIERexcluding) 603 o NHLFE(TreeID, OutInterface, OutLabel, F-BM<0010>) 605 The Flag PopBIERexcluding means POP the BIER Header excluding the 606 first 4 octets BIER Label in a packet, that is a Length of (8+BSL/8) 608 If D don't support BIER P-CAPABILITY or D-CAPABILITY, and C don't 609 support BIER P-CAPABILITY, then it requires B to build a forwarding 610 table, to ensure the BIER Header except the first four octets Label 611 field of a packet is popped before replicated to C, and requires C to 612 build a forwarding table of a pure P2MP branch, and requires F to 613 build a forwarding table of a pure P2MP Leaf. Their forwarding 614 tables are like below: 616 Forwarding Table on B (Branch Node): 618 o ILM(inLabel, action, Flag=Branch|CheckBS, BSL) 620 o NHLFE(TreeID, OutInterface, OutLabel, F-MB<0011>, 621 Flag=PopBIERexcluding) 623 o NHLFE(TreeID, OutInterface, OutLabel, F-BM<0100>) 625 Forwarding Table on C (Branch Node): 627 o ILM(inLabel, action, Flag=Branch) 629 o NHLFE(TreeID, OutInterface, OutLabel) 631 o NHLFE(TreeID, OutInterface, OutLabel) 633 Forwarding Table on D (Branch Node): 635 o ILM(inLabel, action, Flag=Leaf) 637 Here PopLabel mean to pop the Label, which is in fact a P2MP LSP 638 Label. It is a basic capability of any LSR. 640 Forwarding Table on F (Branch Node): 642 o ILM(inLabel, action, Flag=Leaf) 644 Here PopLabel mean to pop the Label, which is in fact a P2MP LSP 645 Label. It is a basic capability of any LSR, and the Forwarding table 646 on F is in fact a P2MP one. 648 Note that, alrough F support BIER, which means it can deal with a 649 BIER packet, but it must downshift its forwarding table to a pure 650 P2MP one, because the packet it received doesn't include a BIER 651 Header but a P2MP Label packet due to the POP behaving of its 652 upstream node. 654 EXAMPLE 2: Take Figure 5 as another example. 656 If E even don't support BIER P-CAPABILITY or D-CAPABILITY, then POP 657 the whole BIER Header Except the first four octets Label field of a 658 packet before it come to D. This requires B to build a forwarding 659 table like this: 661 Forwarding Table on B (Branch Node): 663 o ILM(inLabel, action, Flag=Branch|CheckBS, BSL) 665 o NHLFE(TreeID, OutInterface, OutLabel, F-MB<0011>) 667 o NHLFE(TreeID, OutInterface, OutLabel, F-BM<0100>, 668 Flag=PopBIERexcluding) 670 Forwarding Table on E (Bud Node): 672 o ILM(inLabel, action, Flag=Bud) 674 o NHLFE(TreeID, OutInterface, OutLabel) 676 o LEAF(TreeID, flag=PopLabel) 678 Forwarding Table on F (Branch Node): 680 o ILM(inLabel, action, Flag=Leaf) 682 Note that, alrough F support BIER, which means it can deal with a 683 BIER packet, but it must downshift its forwarding table to a pure 684 P2MP Leaf, because the packet it received doesn't include a BIER 685 Header but a P2MP Label packet due to the POP behaving of its 686 upstream node. 688 One can see that, when some Leaf or Bud nodes even don't have a 689 D-CAPABILITY, we can do a POP action to dispositing the BIER header 690 excluding the BIER Label in the begining before the packet arrive the 691 node. This is similar to a Penultimate Hop Popping in a P2P LSP. 693 6. Provisioning Considerations 695 P2MP based BIER use concepts of both P2MP and BIER. Some 696 provisioning considerations list below: 698 Sub-domain: 700 In P2MP based BIER, every P2MP is a specific BIER underlay topology, 701 and an implicit Sub-domain. RSVP-TE/MLDP build the BIER information 702 of the implicit sub-domain when building the P2MP tree. MVPN get the 703 implicit sub-domain by provisioning. 705 BFR-prefix: 707 In P2MP LSP based BIER, every BFR is also a LSR. So the BFR-prefix 708 in the sub-domain is by default identified by LSR-id. Additionally, 709 When BFR/LSR is also a MVPN PE, BFR-prefix is also the same as 710 Originating Router's IP Address of x-PMSI A-D route or Leaf A-D 711 route. 713 BFR-id: 715 When using protocols like RSVP-TE, which initializes P2MP LSP from a 716 specific Ingress Node, BFR-id which is unique in P2MP LSP scope, can 717 be auto-provisioned by Ingress Node, or conventionally configure on 718 every Egress Nodes. 720 BSL and BIER-MPLS Label Block Size: 722 In P2MP LSP based BIER, Every P2MP LSP or implicit sub-domain 723 requires a single BSL, and a specific BIER-MPLS Label block size for 724 this BSL. 726 VPN-Label: 728 The P2MP based BIER 'P-tunnel' can be shared by multiple VPNs or a 729 single VPN. When a P2MP based BIER being shared by multiple VPNs, an 730 Upstream-assigned VPN-Label is required. It can be auto-provisioned 731 or manual configured by the BFIR or Ingress LSR. 733 In fact, [RFC6513] has defined the method of "Aggregating Multiple 734 MVPNs on a Single P-Tunnel". But unfortunately it is not widely 735 deployed because of the serious trade-off between state saving and 736 bandwidth waste. The BIER encapsulation and forwarding method give 737 it a chance to eliminate the trade-off while gaining a completely 738 state saving. 740 Even when such an aggregating is not used, it is still adequate to 741 use BIER to save state by sharing one P2MP based BIER "P-tunnel" for 742 multi flows in one specific VPN. 744 For seamless transitioning from legacy MVPN deployment and existing 745 network, it is recommended not to use such an aggregating, as well as 746 to use such an aggregating. 748 7. IANA Considerations 750 Allocation is expected from IANA for two new tunnel type codepoints 751 for "RSVP-TE built P2MP based BIER" and "MLDP built P2MP based BIER" 752 from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel 753 Types" registry. 755 8. Security Considerations 757 This document does not introduce any new security considerations 758 other than already discussed in [RFC8279]. 760 9. Acknowledgements 762 The authors would like to thank Eric Rosen, Tony Przygienda, IJsbrand 763 Wijnands and Toerless Eckert for their thoughtful comments and kind 764 suggestions. 766 10. References 768 10.1. Normative References 770 [I-D.ietf-bess-mvpn-expl-track] 771 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 772 "Explicit Tracking with Wild Card Routes in Multicast 773 VPN", draft-ietf-bess-mvpn-expl-track-09 (work in 774 progress), April 2018. 776 [I-D.ietf-bier-mvpn] 777 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 778 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 779 mvpn-11 (work in progress), March 2018. 781 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 782 Label Switching Architecture", RFC 3031, 783 DOI 10.17487/RFC3031, January 2001, 784 . 786 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 787 Yasukawa, Ed., "Extensions to Resource Reservation 788 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 789 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 790 DOI 10.17487/RFC4875, May 2007, 791 . 793 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 794 Thomas, "Label Distribution Protocol Extensions for Point- 795 to-Multipoint and Multipoint-to-Multipoint Label Switched 796 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 797 . 799 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 800 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 801 2012, . 803 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 804 Encodings and Procedures for Multicast in MPLS/BGP IP 805 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 806 . 808 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 809 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 810 RFC 6625, DOI 10.17487/RFC6625, May 2012, 811 . 813 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 814 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 815 Explicit Replication (BIER)", RFC 8279, 816 DOI 10.17487/RFC8279, November 2017, 817 . 819 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 820 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 821 for Bit Index Explicit Replication (BIER) in MPLS and Non- 822 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 823 2018, . 825 10.2. Informative References 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, 829 DOI 10.17487/RFC2119, March 1997, 830 . 832 Authors' Addresses 834 Jingrong Xie 835 Huawei Technologies 837 Email: xiejingrong@huawei.com 839 Mike McBride 840 Huawei Technologies 842 Email: mmcbride7@gmail.com 844 Mach Chen 845 Huawei Technologies 847 Email: mach.chen@huawei.com 849 Liang Geng 850 China Mobile 851 Beijing 100053 853 Email: gengliang@chinamobile.com