idnits 2.17.1 draft-ietf-bier-mvpn-10.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 (February 22, 2018) is 2252 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Rosen, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track M. Sivakumar 5 Expires: August 26, 2018 Cisco Systems, Inc. 6 S. Aldrin 7 Google, Inc. 8 A. Dolganow 9 Nokia 10 T. Przygienda 11 Juniper Networks, Inc. 12 February 22, 2018 14 Multicast VPN Using BIER 15 draft-ietf-bier-mvpn-10 17 Abstract 19 The Multicast Virtual Private Network (MVPN) specifications require 20 the use of multicast tunnels ("P-tunnels") that traverse a Service 21 Provider's backbone network. The P-tunnels are used for carrying 22 multicast traffic across the backbone. A variety of P-tunnel types 23 are supported. Bit Index Explicit Replication (BIER) is a new 24 architecture that provides optimal multicast forwarding through a 25 "multicast domain", without requiring intermediate routers to 26 maintain any per-flow state or to engage in an explicit tree-building 27 protocol. This document specifies the protocol and procedures that 28 allow MVPN to use BIER as the method of carrying multicast traffic 29 over an SP backbone network. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 26, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes . . . . 5 67 2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 9 69 2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 9 70 2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 10 71 3. Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . . 11 72 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 12 74 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 14 76 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 14 77 5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 14 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 9.2. Informative References . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 [RFC6513] and [RFC6514] specify the protocols and procedures that a 89 Service Provider (SP) can use to provide Multicast Virtual Private 90 Network (MVPN) service to its customers. Multicast tunnels are 91 created through an SP's backbone network; these are known as 92 "P-tunnels". The P-tunnels are used for carrying multicast traffic 93 across the backbone. The MVPN specifications allow the use of 94 several different kinds of P-tunnel technology. 96 Bit Index Explicit Replication (BIER) ([RFC8279]) is an architecture 97 that provides optimal multicast forwarding through a "multicast 98 domain", without requiring intermediate routers to maintain any per- 99 flow state or to engage in an explicit tree-building protocol. The 100 purpose of the current document is to specify the protocols and 101 procedures needed in order to provide MVPN service using BIER to 102 transport the multicast traffic over the backbone. 104 Although BIER does not explicitly build and maintain multicast 105 tunnels, one can think of BIER as using a number of implicitly 106 created tunnels through a "BIER domain". In particular, one can 107 think of there as being one Point-to-Multipoint (P2MP) tunnel from 108 each "Bit Forwarding Ingress Router" (BFIR) to all the "Bit 109 Forwarding Egress Routers" (BFERs) in the BIER domain, where a BIER 110 domain is generally co-extensive with an IGP network. These 111 "tunnels" are not specific to any particular VPN. However, the MVPN 112 architecture provides protocols and procedures that allow the traffic 113 of multiple MVPNs to be aggregated on a single P-tunnel. In this 114 document, we specify how to use these multi-VPN aggregation 115 procedures to enable BIER to transport traffic from multiple MVPNs. 117 MVPN traffic must sometimes traverse more than one IGP domain, 118 whereas BIER only carries multicast traffic within a single IGP 119 domain. However, the MVPN specifications allow P-tunnels to be 120 "segmented", where the segmentation points may either be Autonomous 121 System Border Routers (ASBRs), as described in [RFC6514], or Area 122 Border Routers (ABRs), as described in [RFC7524]. As long as the 123 segmentation points are capable of acting as BFIRs and BFERs, BIER 124 can be used to provide some or all of the segments of a P-tunnel. 126 Procedures to support MVPN customers who are using BIDIR-PIM are 127 outside the scope of this document. 129 This document uses the following terminology from [RFC8279]: 131 o BFR: Bit-Forwarding Router. 133 o BFIR: Bit-Forwarding Ingress Router. 135 o BFER: Bit-Forwarding Egress Router. 137 This document uses the following terminology from [RFC6513]: 139 o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in 140 which multicast service is offered. 142 o P-tunnel. A multicast tunnel through the network of one or more 143 SPs. P-tunnels are used to transport MVPN multicast data 145 o PMSI: Provider Multicast Service Interface. PMSI is an 146 abstraction that represents a multicast service for carrying 147 packets. A PMSI is instantiated via one or more P-tunnels. 149 o C-S: A multicast source address, identifying a multicast source 150 located at a VPN customer site. 152 o C-G: A multicast group address used by a VPN customer. 154 o C-flow: A customer multicast flow. Each C-flow is identified by 155 the ordered pair (source address, group address), where each 156 address is in the customer's address space. The identifier of a 157 particular C-flow is usually written as (C-S,C-G). 159 Sets of C-flows can be identified by the use of the "C-*" wildcard 160 (see [RFC6625]), e.g., (C-*,C-G). 162 o I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route. Carried in 163 BGP Update messages, these routes are used to advertise the 164 "default" P-tunnel for a particular MVPN. 166 o S-PMSI A-D route: Selective PMSI Auto-Discovery route. Carried in 167 BGP Update messages, these routes are used to advertise the fact 168 that particular C-flows are bound to (i.e., are traveling through) 169 particular P-tunnels. 171 o x-PMSI A-D route: a route that is either an I-PMSI A-D route or an 172 S-PMSI A-D route. 174 o Leaf A-D route: a route that a multicast egress node sends in 175 order to join a particular P-tunnel. 177 o PMSI Tunnel attribute (PTA). In an x-PMSI A-D route, the NLRI of 178 the route identifies a PMSI. The BGP attribute known as the PMSI 179 Tunnel attribute is attached to such a route in order to identify 180 a particular P-tunnel that is associated with the PMSI. When 181 C-flows of multiple VPNs are carried in a single P-tunnel, this 182 attribute also carries the information needed to multiplex and 183 demultiplex the C-flows. A PTA can also be carried by a Leaf A-D 184 root. In this case, it contains information that is needed in 185 order for the originator of the route to join the specified 186 P-tunnel. 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes 196 As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by 197 an x-PMSI A-D route identifies the P-tunnel that is used to 198 instantiate a particular PMSI. If a PMSI is to be instantiated by 199 BIER, the PTA is constructed by a BFIR. 201 If segmented P-tunnels are not being used, the PTA attached to a 202 given x-PMSI A-D route is constructed by the router that originated 203 the route (typically by the ingress PE), and the PTA is not changed 204 as the route is propagated. 206 If segmented P-tunnels are being used, the PTA attached to a given 207 x-PMSI A-D route by the route's originator may be replaced, at a 208 segmentation point (a BFER), by a PTA identifying the next segment of 209 the P-tunnel. If the next segment of the P-tunnel is instantiated by 210 BIER, the segmentation point serves as the BFIR for that next 211 segment. 213 In either case, a PTA is constructed by a BFIR as follows (see 214 Figure 1): 216 The PTA contains the following fields: 218 o "Tunnel Type". IANA has assigned 0x0B as the tunnel type 219 codepoint for "BIER" in the "P-Multicast Service Interface Tunnel 220 (PMSI Tunnel) Tunnel Types" registry. This codepoint is used to 221 indicate that the PMSI is instantiated by BIER. 223 Although BIER does not actually create tunnels, the MVPN 224 procedures treat BIER as if it were a type of tunnel. 226 o "Tunnel Identifier". When the "tunnel type" is "BIER", this field 227 contains three subfields: 229 1. The first subfield is a single octet, containing a BIER 230 sub-domain-id. (See [RFC8279].) This indicates that packets 231 sent on the PMSI will be sent on the specified BIER 232 sub-domain. How that sub-domain is chosen is outside the 233 scope of this document. 235 2. The second subfield is a two-octet field containing the 236 BFR-id, in the sub-domain identified in the first subfield, of 237 the router that is constructing the PTA. 239 3. The third subfield is the BFR-prefix (see [RFC8279]) of the 240 router (a BFIR) that is constructing the PTA. The BFR-prefix 241 will either be a /32 IPv4 address or a /128 IPv6 address. 243 Whether the address is IPv4 or IPv6 can be inferred from the 244 total length of the PTA. 246 The BFR-prefix need not be the same IP address that is carried 247 in any other field of the x-PMSI A-D route, even if the BFIR 248 is the originating router of the x-PMSI A-D route. 250 Failure to properly set the Tunnel Identifier field cannot be 251 detected by the protocol, and will result in improper delivery of 252 the data packets sent on the PMSI. 254 o "MPLS Label". This field MUST contain an upstream-assigned non- 255 zero MPLS label. It is assigned by the router (a BFIR) that 256 constructs the PTA. Constraints on the way in which a BFIR 257 selects this label are discussed in Section 2.1. 259 Failure to follow the constraints on label assignment cannot be 260 detected by the protocol, and may result in improper handling of 261 data packets by the egress PE routers. 263 o "Flags". When the tunnel type is BIER, two of the flags in the 264 PTA Flags field are meaningful. Details about the use of these 265 flags can be found in Section 2.2. 267 * "Leaf Info Required per Flow (LIR-pF)". This flag is 268 introduced in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this 269 flag UNLESS it knows that all the BFERs in the BIER domain (or 270 at least all the BFERs to which it needs to transmit) support 271 this flag. (How this is known is outside the scope of this 272 document.) Procedures for the use of this flag are given in 273 Section 2.2.2. Support for this flag is OPTIONAL. 275 * "Leaf Info Required Bit". See Section 2.2.1. 277 +---------------------------------+ 278 | Flags (1 octet) | 279 +---------------------------------+ 280 | Tunnel Type = 0x0B (1 octet) | 281 +---------------------------------+ 282 | MPLS Label (3 octets) | 283 +---------------------------------+ 284 | Sub-domain-id (1 octet) | <--- 285 +---------------------------------+ | 286 | BFR-id (2 octets) | |-- Tunnel 287 +---------------------------------+ | Identifier 288 | BFR-prefix (4 or 16 octets) | <--- 289 +---------------------------------+ 291 Figure 1: PMSI Tunnel Attribute for BIER 293 If a PTA specifying tunnel type "BIER" is attached to an x-PMSI A-D 294 route, the route MUST NOT be distributed beyond the boundaries of a 295 BIER domain. That is, any routers that receive the route must be in 296 the same BIER domain as the originator of the route. If the 297 originator is in more than one BIER domain, the route must be 298 distributed only within the BIER domain in which the BFR-prefix in 299 the PTA uniquely identifies the originator. As with all MVPN routes, 300 distribution of these routes is controlled by the provisioning of 301 Route Targets. Thus the requirement expressed in this paragraph is 302 really a requirement on the way the Route Targets are provisioned. 304 2.1. MPLS Label 306 The MPLS Label carried in the PTA is an upstream-assigned label. 308 If two PTAs contain the same BFR-prefix in their respective Tunnel 309 Identifier fields, then the labels carried in those PTAs MUST come 310 from the same label space. (See section 7 of [RFC5331].) An 311 implementation may choose to use this fact when setting up the tables 312 it uses to interpret the upstream-assigned labels. 314 Suppose a BFIR attaches a PTA to each of two x-PMSI A-D routes, and 315 both PTAs specify a tunnel type of "BIER". 317 o If the two routes do not carry the same set of Route Targets 318 (RTs), then their respective PTAs MUST contain different MPLS 319 label values. 321 o If the two routes do not have the same Address Family Identifier 322 (AFI) value, then their respective PTAs MUST contain different 323 MPLS label values. This ensures that when an egress PE receives a 324 data packet with the given label, the egress PE can infer from the 325 label whether the payload is an IPv4 packet or an IPv6 packet. 327 o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900]) 328 functionality, and if the two routes originate from different VRFs 329 on this ingress PE, then the respective PTAs of the two routes 330 MUST contain different MPLS label values. 332 o If the BFIR is an ingress PE supporting the "Extranet Separation" 333 feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if 334 one of the routes carries the "Extranet Separation" extended 335 community but the other does not, then the respective PTAs of the 336 two routes MUST contain different MPLS label values. 338 o If segmented P-tunnels are being used, then the respective PTAs of 339 the two routes MUST contain different MPLS label values whenever 340 the respective NLRIs of the two routes are not identical. The 341 MPLS label can then be used at the next segmentation point to 342 switch packets from one P-tunnel segment directly to the next, 343 without requiring the segmentation points to contain any other 344 multicast forwarding state. This is explained further below. See 345 also Section 4. 347 When segmented P-tunnels are being used, a segmentation point, call 348 it "B1", may receive, from within a given BIER domain, an x-PMSI A-D 349 route whose PTA specifies "BIER". This means that BIER is being used 350 for the previous segment of a segmented P-tunnel. If the next 351 segment is also of type "BIER", B1 will be the BFIR for the next 352 segment. That is, B1 is a BFER of one BIER domain (corresponding to 353 the previous segment), and a BFIR of another BIER domain 354 (corresponding to the next segment). B1 needs to replace the PTA of 355 the x-PMSI A-D route with a new PTA, specifying its own BFR-prefix, 356 and specifying an upstream-assigned label assigned by B1 itself. 358 Suppose B1 has received two x-PMSI A-D routes, R1 and R2, where: 360 o R1 and R2 each have a PTA specifying BIER, 362 o R1's PTA specifies BFR-prefix B2 and Label L2. 364 o R2's PTA specifies BFR-prefix B3 and Label L3. 366 Suppose B1 decides to propagate both R1 and R2, replacing each PTA 367 with a new PTA specifying BIER. Suppose these new PTAs specify 368 labels L4 and L5 respectively. Then L4 and L5 MUST be different 369 (upstream-assigned) label values, UNLESS both of the following 370 conditions hold: 372 o R1 and R2 have the same value in the Originating Router field of 373 their respective NLRIs, and 375 o B2 is equal to B3, and 377 o L2 is equal to L3. 379 The segmentation point (B1 in this example) MUST also program its 380 dataplane appropriately. For example, when: 382 o B1 receives a BIER packet for which it is a BFER, and 384 o the BIER header specifies the BFIR-id that corresponds to B2,and 386 o the BIER payload is an MPLS packet with upstream-assigned label, 387 and 389 o the top label value is L2, 391 then the dataplane must be programmed to replace L2 with L4, and to 392 reencapsulate the packet in a BIER header, with B1's BFR-id in the 393 BFIR-id field. The BitString of the new BIER header is determined by 394 the MVPN explicit tracking procedures (see Section 2.2 in the BIER 395 domain of the next segment. 397 2.2. Explicit Tracking 399 When using BIER to transport an MVPN data packet through a BIER 400 domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR 401 must determine the set of BFERs to which the packet needs to be 402 delivered. This can be done in either of two ways: 404 1. Using the explicit tracking mechanism based on the "Leaf Info 405 Required" flag specified in [RFC6513] and [RFC6514]. This method 406 is further described in Section 2.2.1. 408 2. Using the OPTIONAL explicit tracking mechanism based on the 409 LIR-pF flag specified in [EXPLICIT_TRACKING]. This method, 410 further described in Section 2.2.2, may be used if (and only if) 411 segmented P-tunnels are not being used. 413 2.2.1. Using the LIR Flag 415 To determine the set of BFERs to which the packets of a given C-flow 416 must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for 417 the given C-flow. It MUST attach a PTA to that route, and MUST set 418 the LIR flag in the PTA. Per [RFC6514], the BFERs that need to 419 receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By 420 matching the received Leaf A-D routes to the originated S-PMSI A-D 421 routes, the originator of the S-PMSI A-D route determines the set of 422 BFERs that need to receive the multicast data flow that is identified 423 in the NLRI of S-PMSI A-D route. 425 Suppose an ingress PE has originated an I-PMSI A-D route or a 426 wildcard S-PMSI A-D route [RFC6625] with a PTA specifying a tunnel 427 type of BIER. Now suppose the ingress PE originates an S-PMSI A-D 428 route specifying (C-S, C-G), where (C-S, C-G) "matches" (according to 429 the rules of [RFC6625]) the wildcard S-PMSI A-D route or the I-PMSI 430 A-D route. Instead of attaching to the (C-S, C-G) route a PTA 431 specifying BIER, the ingress PE MAY attach a PTA specifying a tunnel 432 type of "no tunnel information". This is equivalent to attaching the 433 same PTA attached to the matching "less specific" route. 435 2.2.2. Using the LIR-pF Flag 437 If segmented P-tunnels are not being used, the BFIR can determine the 438 set of BFERs that need to receive the packets of a given (C-S,C-G) 439 C-flow as follows. The BFIR MUST originate a wildcard S-PMSI A-D 440 route (either (C-*,C-*), (C-*,C-G), or (C-S,C-G)) and the PTA of that 441 route MUST the following settings: 443 o The LIR-pF flag MUST be set; 445 o The tunnel type MUST be set to "BIER"; 447 o A non-zero MPLS label MUST be specified. 449 Per [EXPLICIT_TRACKING], a BFER that needs to receive (C-S,C-G) 450 traffic from the BFIR will respond with a Leaf A-D route. 452 A BFIR MUST NOT use this method of finding the set of BFERs needing 453 to receive a given C-flow unless it knows that all those BFERs 454 support the LIR-pF flag. How this is known is outside the scope of 455 this document. 457 This method greatly reduces the number of S-PMSI A-D routes that a 458 BFIR needs to originate; it can now originate as few as one such 459 route (a (C-*,C-*) S-PMSI A-D route), rather than one for each 460 C-flow. However, the method does not provide a way for the BFIR to 461 assign a distinct label to each C-flow. Therefore it cannot be used 462 when segmented P-tunnels are in use (see Section 4 for an 463 explanation). 465 Note: if a BFIR originates a (C-*,C-*) S-PMSI A-D route with the 466 LIR-pF flag set, but also originates a more specific wildcard route 467 that matches a particular (C-S,C-G), the BFERs will not originate 468 Leaf A-D routes for that (C-S,C-G) unless the LIR-pF flag is also set 469 in the more specific wildcard route. If the BFIR also originates a 470 (C-S,C-G) S-PMSI A-D route without the LIR flag set, the BFERs will 471 not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag 472 is also set in that route. 474 3. Use of the PMSI Tunnel Attribute in Leaf A-D routes 476 Before an egress PE can receive a (C-S,C-G) flow from a given ingress 477 PE via BIER, the egress PE must have received one of the following 478 x-PMSI A-D routes from the ingress PE: 480 o A (C-S,C-G) S-PMSI A-D route (i.e., an S-PMSI A-D route whose NLRI 481 encodes (C-S,C-G) and whose PTA specifies a tunnel type of "BIER". 482 If such a route is found, we refer to it as the "matching x-PMSI 483 A-D route." 485 o A "less specific" x-PMSI A-D route (one specifying (C-*,C-*), 486 (C-*,C-G), or (C-S,C-G)) whose PTA specifies a tunnel type of 487 "BIER", and that is the egress PE's "match for reception" of 488 (C-S,C-G). 490 The rules for determining which x-PMSI A-D route is the match for 491 reception are given in [RFC6625]. However, these rules are 492 modified here to exclude any x-PMSI A-D route that does not have a 493 PTA, or whose PTA specifies "no tunnel type". 495 If such a route is found, we refer to it as the "matching x-PMSI 496 A-D route." 498 If no matching x-PMSI A-D route for (C-S,C-G) is found, the egress PE 499 cannot receive the (C-S,C-G) flow from the ingress PE via BIER until 500 such time as a matching route is received. 502 When an egress PE determines that it needs to receive a (C-S,C-G) 503 flow from a particular ingress PE via BIER, it originates a Leaf A-D 504 route. Construction of the Leaf A-D route generally follows the 505 procedures specified in [RFC6514], or optionally, the procedures 506 specified in [EXPLICIT_TRACKING]. However, when BIER is being used, 507 the Leaf A-D route MUST carry a PTA that is constructed as follows: 509 1. The tunnel type MUST be set to "BIER". 511 2. The MPLS Label field SHOULD be set to zero. 513 3. The Sub-domain-id subfield of the Tunnel Identifier field (as 514 defined in Section 2) MUST be set to the corresponding value from 515 the PTA of the matching x-PMSI A-D route. 517 4. The BFR-id subfield of the Tunnel Identifier field MUST be set to 518 the BFR-id, in the sub-domain identified by the sub-domain-id 519 subfield, of the egress PE (BFER). 521 5. The BFR-prefix field of the Tunnel Identifier field (as defined 522 in Section 2) MUST be set to the egress PE's (BFER's) BFR-prefix. 524 The BFR-prefix need not be the same IP address that is carried in 525 any other field of the Leaf A-D route. 527 When an ingress PE receives such a Leaf A-D route, it learns the 528 BFR-prefix of the egress PE from the PTA. The ingress PE does not 529 make any use the value of the PTA's MPLS label field. 531 Failure to properly construct the PTA cannot always be detected by 532 the protocol, and will cause improper delivery of the data packets. 534 4. Data Plane 536 The MVPN application plays the role of the "multicast flow overlay" 537 as described in [RFC8279]. 539 4.1. Encapsulation and Transmission 541 To transmit an MVPN data packet, an ingress PE follows the rules of 542 [RFC6625] to find the x-PMSI A-D route that is a "match for 543 transmission" for that packet. (In applying the rules of [RFC6625], 544 any S-PMSI A-D route with a PTA specifying "no tunnel information" is 545 ignored.) If the matching route has a PTA specifying "BIER", the 546 (upstream-assigned) MPLS label from that PTA is pushed on the 547 packet's label stack. Then the packet is encapsulated in a BIER 548 header. That is, the ingress PE functions as a BFIR. The BIER 549 sub-domain used for transmitting the packet is specified in the PTA 550 of the abovementioned x-PMSI A-D route. 552 In order to create the proper BIER header for a given packet, the 553 BFIR must know all the BFERs that need to receive that packet. It 554 determines this by finding all the Leaf A-D routes that correspond to 555 the S-PMSI A-D route that is the packet's match for transmission. 556 There are two different cases to consider: 558 1. The S-PMSI A-D route that is the match for transmission carries a 559 PTA that has the LIR flag set but does not have the LIR-pF flag 560 set. 562 In this case, the corresponding Leaf A-D routes are those whose 563 "route key" field is identical to the NLRI of the S-PMSI A-D 564 route. 566 2. The S-PMSI A-D route that is the match for transmission carries a 567 PTA that has the LIR-pF flag. 569 In this case, the corresponding Leaf A-D routes are those whose 570 "route key" field is derived from the NLRI of the S-PMSI A-D 571 route according to the procedures described in Section 5.2 of 572 [EXPLICIT_TRACKING]. 574 The Leaf A-D route from a given BFER will contain a PTA that 575 specifies the BFER's BFR-prefix. With this information, the BFIR can 576 construct the BIER BitString. 578 However, if the PTA of the Leaf A-D route from a given BFER specifies 579 a sub-domain other than the one being used for transmitting the 580 packet, the bit for that BFER cannot be determined, and that BFER 581 will not receive the packet. 583 The BIER-encapsulated packet is then forwarded, according to the 584 procedures of [RFC8279] and [RFC8296]. (See especially Section 4, 585 "Imposing and Processing the BIER Encapsulation", of [RFC8296].) 587 4.2. Disposition 589 When a BFER receives an MVPN multicast data packet that has been 590 BIER-encapsulated, the BIER layer passes the following information to 591 the multicast flow overlay: 593 o The sub-domain-id and the BFIR-id from the BIER header. (As the 594 sub-domain-id is inferred from the BIFT-id field of the BIER 595 header, an implementation might choose to pass the BIFT-id rather 596 than the sub-domain-id; this is an implementation matter.) 598 o The "payload", which is an MPLS packet whose top label is an 599 upstream-assigned label. In the dataplane, the BFIR-id and the 600 sub-domain-id provide the context in which the upstream-assigned 601 label is interpreted. 603 By looking up the upstream-assigned label in the appropriate context, 604 the multicast flow overlay determines whether the BFER is an egress 605 PE for the packet. 607 Note that if segmented P-tunnels are in use, a BFER might be a 608 P-tunnel segmentation border router rather than an egress PE, or a 609 BFER might be both an egress PE and a P-tunnel segmentation border 610 router. Depending upon the role of the BFER for given packet, it may 611 need to follow the procedures of Section 4.2.1, the procedures of 612 Section 4.2.2, or both. 614 4.2.1. At a BFER that is an Egress PE 616 From looking up the packet's upstream-assigned label in the context 617 of the packet's BFIR-prefix, the egress PE determines the egress VRF 618 for the packet. From the IP header of the payload, the multicast 619 states of the VRF, the upstream-assigned label, and the BFR-prefix, 620 the egress PE can determine whether the packet needs to be forwarded 621 out one or more VRF interfaces. 623 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary 625 When segmented P-tunnels are being used, a BFER that receives a BIER- 626 encapsulated MVPN multicast data packet may need to be forwarded on 627 its next P-tunnel segment. The choice of the next P-tunnel segment 628 for the packet depends upon the C-flow to which the packet belongs. 629 As long as the BFIR has assigned the MPLS label according to the 630 constraints specified in Section 2.1, the BFIR will have assigned 631 distinct upstream-assigned MPLS labels to distinct C-flows. The BFER 632 can thus select the proper "next P-tunnel segment" for a given packet 633 simply by looking up the upstream-assigned label that immediately 634 follows the BIER header. 636 5. Contributor Addresses 638 Below is a list of other contributing authors in alphabetical order: 640 IJsbrand Wijnands 641 Cisco Systems, Inc. 642 De Kleetlaan 6a 643 Diegem 1831 644 Belgium 646 Email: ice@cisco.com 648 6. Acknowledgments 650 The authors wish to thank Jeffrey Zhang for his ideas and 651 contributions to this work. We also thank Stig Venaas for his review 652 and comments. 654 7. IANA Considerations 656 IANA has assigned the codepoint 0x0B to "BIER" in the "P-Multicast 657 Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. 659 8. Security Considerations 661 The security considerations of [RFC8279], [RFC8296], [RFC6513] and 662 [RFC6514] are applicable. 664 9. References 666 9.1. Normative References 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, 670 DOI 10.17487/RFC2119, March 1997, 671 . 673 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 674 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 675 2006, . 677 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 678 Label Assignment and Context-Specific Label Space", 679 RFC 5331, DOI 10.17487/RFC5331, August 2008, 680 . 682 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 683 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 684 2012, . 686 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 687 Encodings and Procedures for Multicast in MPLS/BGP IP 688 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 689 . 691 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 692 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 693 RFC 6625, DOI 10.17487/RFC6625, May 2012, 694 . 696 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 697 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 698 May 2017, . 700 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 701 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 702 Explicit Replication (BIER)", RFC 8279, 703 DOI 10.17487/RFC8279, November 2017, 704 . 706 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 707 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 708 for Bit Index Explicit Replication (BIER) in MPLS and Non- 709 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 710 2018, . 712 9.2. Informative References 714 [EXPLICIT_TRACKING] 715 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 716 "Explicit Tracking with Wild Card Routes in Multicast 717 VPN", internet-draft draft-ietf-bess-mvpn-expl-track-02, 718 June 2017. 720 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 721 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 722 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 723 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 724 . 726 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 727 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 728 RFC 7900, DOI 10.17487/RFC7900, June 2016, 729 . 731 Authors' Addresses 733 Eric C. Rosen (editor) 734 Juniper Networks, Inc. 735 10 Technology Park Drive 736 Westford, Massachusetts 01886 737 United States 739 Email: erosen@juniper.net 741 Mahesh Sivakumar 742 Cisco Systems, Inc. 743 510 McCarthy Blvd 744 Milpitas, California 95035 745 United States 747 Email: masivaku@cisco.com 748 Sam K Aldrin 749 Google, Inc. 750 1600 Amphitheatre Parkway 751 Mountain View, California 752 United States 754 Email: aldrin.ietf@gmail.com 756 Andrew Dolganow 757 Nokia 758 438B Alexandra Rd #08-07/10 759 Alexandra Technopark 760 Singapore 119968 762 Email: andrew.dolganow@nokia.com 764 Tony Przygienda 765 Juniper Networks, Inc. 766 1137 Innovation Way 767 San Jose, California 94089 768 United States 770 Email: prz@juniper.net