idnits 2.17.1 draft-ietf-bier-mvpn-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (June 27, 2017) is 2466 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- 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: Experimental M. Sivakumar 5 Expires: December 29, 2017 Cisco Systems, Inc. 6 S. Aldrin 7 Google, Inc. 8 A. Dolganow 9 Nokia 10 T. Przygienda 11 Juniper Networks, Inc. 12 June 27, 2017 14 Multicast VPN Using BIER 15 draft-ietf-bier-mvpn-06 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 http://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 December 29, 2017. 48 Copyright Notice 50 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 7 69 2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 8 70 2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 8 71 3. Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . . 9 72 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 10 74 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 12 76 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 12 77 5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 12 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 9.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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) ([BIER_ARCH]) is an 97 architecture that provides optimal multicast forwarding through a 98 "multicast domain", without requiring intermediate routers to 99 maintain any per-flow state or to engage in an explicit tree-building 100 protocol. The purpose of the current document is to specify the 101 protocols and procedures needed in order to provide MVPN service 102 using BIER to 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 [BIER_ARCH]: 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). 158 Sets of C-flows can be identified by the use of the "C-*" wildcard 159 (see [RFC6625]), e.g., (C-*,C-G). 161 o I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route. Carried in 162 BGP Update messages, these routes are used to advertise the 163 "default" P-tunnel for a particular MVPN. 165 o S-PMSI A-D route: Selective PMSI Auto-Discovery route. Carried in 166 BGP Update messages, these routes are used to advertise the fact 167 that particular C-flows are bound to (i.e., are traveling through) 168 particular P-tunnels. 170 o x-PMSI A-D route: a route that is either an I-PMSI A-D route or an 171 S-PMSI A-D route. 173 o Leaf A-D route: a route that a multicast egress node sends in 174 order to join a particular P-tunnel. 176 o PMSI Tunnel attribute (PTA). In an x-PMSI A-D route, the NLRI of 177 the route identifies a PMSI. The BGP attribute known as the PMSI 178 Tunnel attribute is attached to such a route in order to identify 179 a particular P-tunnel that is associated with the PMSI. When 180 C-flows of multiple VPNs are carried in a single P-tunnel, this 181 attribute also carries the information needed to multiplex and 182 demultiplex the C-flows. A PTA can also be carried by a Leaf A-D 183 root. In this case, it contains information that is needed in 184 order for the originator of the route to join the specified 185 P-tunnel. 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC 2119 [RFC2119]. 191 2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes 193 As defined in [RFC6514], the PMSI Tunnel attribute (PTA) is used to 194 identify the P-tunnel that is used to instantiate a particular PMSI. 195 If a PMSI is to be instantiated by BIER, the PTA is constructed as 196 follows. 198 The PTA contains the following fields: 200 o "Tunnel Type". IANA is requested to assign a new tunnel type 201 codepoint for "BIER" from the "P-Multicast Service Interface 202 Tunnel (PMSI Tunnel) Tunnel Types" registry. This codepoint will 203 be used to indicate that the PMSI is instantiated by BIER. 204 (Although BIER does not actually create tunnels, the MVPN 205 procedures treat BIER as if it were a type of tunnel.) 207 o "Tunnel Identifier". When the "tunnel type" is "BIER", this field 208 contains two subfields: 210 1. The first subfield is a single octet, containing a BIER sub- 211 domain-id. (See [BIER_ARCH].) This indicates that packets 212 sent on the PMSI will be sent on the specified BIER sub- 213 domain. How that sub-domain is chosen is outside the scope of 214 this document. 216 2. The second subfield is the BFR-Prefix (see [BIER_ARCH]) of the 217 originator of the route that is carrying this PTA. This must 218 be the originator's BFR-prefix in the specified sub-domain. 219 The BFR-Prefix will either be a /32 IPv4 address or a /128 220 IPv6 address. Whether the address is IPv4 or IPv6 can be 221 inferred from the total length of the PMSI Tunnel attribute. 223 The BFR-Prefix need not be the same IP address that is carried 224 in any other field of the x-PMSI A-D route. 226 Failure to properly set the Tunnel Identifier field cannot be 227 detected by the protocol, and will result in improper delivery of 228 the data packets sent on the PMSI. 230 o "MPLS label". This field MUST contain an upstream-assigned MPLS 231 label. It is assigned by the router that originates the BGP route 232 to which the PTA is attached. Constraints on the way in which the 233 originating router selects this label are discussed in 234 Section 2.1. 236 Failure to follow the constraints on label assignment cannot be 237 detected by the protocol, and may result in improper handling of 238 data packets by the egress PE routers. 240 o "Flags". When the tunnel type is BIER, two of the flags in the 241 PTA Flags field are meaningful. Details about the use of these 242 flags can be found in Section 2.2. 244 * "Leaf Info Required per Flow (LIR-pF)". This flag is 245 introduced in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this 246 flag UNLESS it knows that all the BFERs in the BIER domain (or 247 at least all the BFERs to which it needs to transmit) support 248 this flag. (How this is known is outside the scope of this 249 document.) Procedures for the use of this flag are given in 250 Section 2.2.2. Support for this flag is OPTIONAL. 252 * "Leaf Info Required Bit". See Section 2.2.1. 254 If a PTA specifying tunnel type "BIER" is attached to an x-PMSI A-D 255 route, the route MUST NOT be distributed beyond the boundaries of a 256 BIER domain. That is, any routers that receive the route must be in 257 the same BIER domain as the originator of the route. If the 258 originator is in more than one BIER domain, the route must be 259 distributed only within the BIER domain in which the BFR-Prefix in 260 the PTA uniquely identifies the originator. As with all MVPN routes, 261 distribution of these routes is controlled by the provisioning of 262 Route Targets. Thus the requirement expressed in this paragraph is 263 really a requirement on the way the Route Targets are provisioned. 265 2.1. MPLS Label 267 Suppose an ingress PE originates two x-PMSI A-D routes. Suppose each 268 route carries a PTA, and the PTA of each route specifies a tunnel 269 type of "BIER". 271 o If the two routes do not carry the same set of Route Targets 272 (RTs), then their respective PTAs MUST contain different MPLS 273 label values. 275 o If the two routes do not have the same Address Family Identifier 276 (AFI) value, then their respective PTAs MUST contain different 277 MPLS label values. This ensures that when an egress PE receives a 278 data packet with the given label, the egress PE can infer from the 279 label whether the payload is an IPv4 packet or an IPv6 packet. 281 o If the ingress PE is supporting MVPN extranet ([RFC7900]) 282 functionality, and if the two routes originate from different 283 VRFs, then the respective PTAs of the two routes MUST contain 284 different MPLS label values. 286 o If the ingress PE is supporting the "Extranet Separation" feature 287 of MVPN extranet (see Section 7.3 of [RFC7900], section ), and if 288 one of the routes carries the "Extranet Separation" extended 289 community and the other does not, then the respective PTAs of the 290 two routes MUST contain different MPLS label values. 292 o If segmented P-tunnels are being used, then the respective PTAs of 293 the two routes MUST contain different MPLS label values, as long 294 as the NLRIs are not identical. In this case, the MPLS label can 295 be used by the BFER to identify the particular C-flow to which a 296 data packet belongs, and this greatly simplifies the process of 297 forwarding a received packet to its next P-tunnel segment. This 298 is explained further below. See also Section 4. 300 When segmented P-tunnels are being used, an ABR or ASBR may receive, 301 from a BIER domain, an x-PMSI A-D route whose PTA specifies "BIER". 302 This means that BIER is being used for one segment of a segmented 303 P-tunnel. The ABR/ASBR may in turn need to originate an x-PMSI A-D 304 route whose PTA identifies the next segment of the P-tunnel. The 305 next segment may also be "BIER". Suppose an ASBR receives x-PMSI A-D 306 routes R1 and R2, and as a result originates x-PMSI A-D routes R3 and 307 R4 respectively, where the PTAs of each of the four routes specify 308 BIER. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS 309 label, UNLESS both of the following conditions hold: 311 o R1 and R2 have the same "originating router" in their respective 312 NLRIs. 314 o R1 and R2 specify the same MPLS label in their respective PTAs. 316 The ABR/ASBR MUST then program its dataplane such that a packet 317 arriving with the upstream-assigned label specified in route R1 is 318 transmitted with the upstream-assigned label specified in route R3, 319 and a packet arriving with the upstream-assigned label specified in 320 route R2 is transmitted with the label specified in route R4. Of 321 course, the data plane must also be programmed to encapsulate the 322 transmitted packets with an appropriate BIER header, whose BitString 323 is determined by the multicast flow overlay. 325 2.2. Explicit Tracking 327 When using BIER to transport an MVPN data packet through a BIER 328 domain, an ingress PE functions as a BFIR (see [BIER_ARCH]). The 329 BFIR must determine the set of BFERs to which the packet needs to be 330 delivered. This can be done in either of two ways: 332 1. Using the explicit tracking mechanism based on the "Leaf Info 333 Required" flag specified in [RFC6513] and [RFC6514]. This method 334 is further described in Section 2.2.1. 336 2. Using the OPTIONAL explicit tracking mechanism based on the LIR- 337 pF flag specified in [EXPLICIT_TRACKING]. This method, further 338 described in Section 2.2.2, may be used if (and only if) 339 segmented P-tunnels are not being used. 341 2.2.1. Using the LIR Flag 343 To determine the set of BFERs to which the packets of a given C-flow 344 must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for 345 the given C-flow. It MUST attach a PTA to that route, and MUST set 346 the LIR flag in the PTA. Per [RFC6514], the BFERs that need to 347 receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By 348 matching the received Leaf A-D routes to the originated S-PMSI A-D 349 routes, the originator of the S-PMSI A-D route determines the set of 350 BFERs that need to receive the multicast data flow that is identified 351 in the NLRI of S-PMSI A-D route. 353 Suppose an ingress PE has originated an I-PMSI A-D route or a 354 wildcard S-PMSI A-D route [RFC6625] with a PTA specifying a tunnel 355 type of BIER. Now suppose the ingress PE originates an S-PMSI A-D 356 route specifying (C-S, C-G), where (C-S, C-G) "matches" (according to 357 the rules of [RFC6625]) the wildcard S-PMSI A-D route or the I-PMSI 358 A-D route. Instead of attaching to the (C-S, C-G) route a PTA 359 specifying BIER, the ingress PE MAY attach a PTA specifying a tunnel 360 type of "no tunnel information". This is equivalent to attaching the 361 same PTA attached to the matching "less specific" route. 363 2.2.2. Using the LIR-pF Flag 365 If segmented P-tunnels are not being used, the BFIR can determine the 366 set of BFERs that need to receive the packets of a given (C-S,C-G) 367 C-flow as follows. The BFIR MUST originate a wildcard S-PMSI A-D 368 route (either (C-*,C-*), (C-*,C-G), or (C-S,C-G)) and the PTA of that 369 route MUST the following settings: 371 o The LIR-pF flag MUST be set; 373 o The tunnel type MUST be set to "BIER"; 375 o A non-zero MPLS label MUST be specified. 377 Per [EXPLICIT_TRACKING], a BFER that needs to receive (C-S,C-G) 378 traffic from the BFIR will respond with a Leaf A-D route. 380 A BFIR MUST NOT use this method of finding the set of BFERs needing 381 to receive a given C-flow unless it knows that all those BFERs 382 support the LIR-pF flag. How this is known is outside the scope of 383 this document. 385 This method greatly reduces the number of S-PMSI A-D routes that a 386 BFIR needs to originate; it can now originate as few as one such 387 route (a (C-*,C-*) S-PMSI A-D route), rather than one for each 388 C-flow. However, the method does not provide a way for the BFIR to 389 assign a distinct label to each C-flow. Therefore it cannot be used 390 when segmented P-tunnels are in use (see Section 4 for an 391 explanation). 393 Note: if a BFIR originates a (C-*,C-*) S-PMSI A-D route with the LIR- 394 pF flag set, but also originates a more specific wildcard route that 395 matches a particular (C-S,C-G), the BFERs will not originate Leaf A-D 396 routes for that (C-S,C-G) unless the LIR-pF flag is also set in the 397 more specific wildcard route. If the BFIR also originates a 398 (C-S,C-G) S-PMSI A-D route without the LIR flag set, the BFERs will 399 not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag 400 is also set in that route. 402 3. Use of the PMSI Tunnel Attribute in Leaf A-D routes 404 Before an egress PE can receive a (C-S,C-G) flow from a given ingress 405 PE via BIER, the egress PE must have received one of the following 406 x-PMSI A-D routes from the ingress PE: 408 o A (C-S,C-G) S-PMSI A-D route (i.e., an S-PMSI A-D route whose NLRI 409 encodes (C-S,C-G) and whose PTA specifies a tunnel type of "BIER". 410 If such a route is found, we refer to it as the "matching x-PMSI 411 A-D route." 413 o A "less specific" x-PMSI A-D route (one specifying (C-*,C-*), 414 (C-*,C-G), or (C-S,C-G)) whose PTA specifies a tunnel type of 415 "BIER", and that is the egress PE's "match for reception" of 416 (C-S,C-G). 418 The rules for determining which x-PMSI A-D route is the match for 419 reception are given in [RFC6625]. However, these rules are 420 modified here to exclude any x-PMSI A-D route that does not have a 421 PTA, or whose PTA specifies "no tunnel type". 423 If such a route is found, we refer to it as the "matching x-PMSI 424 A-D route." 426 If no matching x-PMSI A-D route for (C-S,C-G) is found, the egress PE 427 cannot receive the (C-S,C-G) flow from the ingress PE via BIER. 429 When an egress PE determines that it needs to receive a (C-S,C-G) 430 flow from a particular ingress PE via BIER, it originates a Leaf A-D 431 route. Construction of the Leaf A-D route generally follows the 432 procedures specified in [RFC6514], or optionally, the procedures 433 specified in [EXPLICIT_TRACKING]. However, when BIER is being used, 434 the Leaf A-D route MUST carry a PTA that is constructed as follows: 436 1. The tunnel type MUST be set to "BIER". 438 2. The MPLS label field SHOULD be set to zero. 440 3. The sub-domain-id field of the Tunnel Identifier field (as 441 defined in Section 2) MUST be set to the corresponding value from 442 the PTA of the matching x-PMSI A-D route. 444 4. The BFR-Prefix field of the Tunnel Identifier field (as defined 445 in Section 2) MUST be set to the egress PE's BFR-Prefix in the 446 sub-domain identifiers in the PTA of the matching x-PMSI A-D 447 route. 449 The BFR-Prefix need not be the same IP address that is carried in 450 any other field of the Leaf A-D route. 452 When an ingress PE receives such a Leaf A-D route, it learns the BFR- 453 Prefix of the egress PE from the PTA. The ingress PE does not make 454 any use the value of the PTA's MPLS label field. 456 Failure to properly construct the PTA cannot always be detected by 457 the protocol, and will cause improper delivery of the data packets. 459 4. Data Plane 461 The MVPN application plays the role of the "multicast flow overlay" 462 as described in [BIER_ARCH]. 464 4.1. Encapsulation and Transmission 466 To transmit an MVPN data packet, an ingress PE follows the rules of 467 [RFC6625] to find the x-PMSI A-D route that is a "match for 468 transmission" for that packet. (In applying the rules of [RFC6625], 469 any S-PMSI A-D route with a PTA specifying "no tunnel information" is 470 ignored.) If the matching route has a PTA specifying "BIER", the 471 (upstream-assigned) MPLS label from that PTA is pushed on the 472 packet's label stack. Then the packet is encapsulated in a BIER 473 header. That is, the ingress PE functions as a BFIR. The BIER sub- 474 domain used for transmitting the packet is specified in the PTA of 475 the abovementioned x-PMSI A-D route. 477 In order to create the proper BIER header for a given packet, the 478 BFIR must know all the BFERs that need to receive that packet. It 479 determines this by finding all the Leaf A-D routes that correspond to 480 the S-PMSI A-D route that is the packet's match for transmission. 481 There are two different cases to consider: 483 1. The S-PMSI A-D route that is the match for transmission carries a 484 PTA that has the LIR flag set but does not have the LIR-pF flag 485 set. 487 In this case, the corresponding Leaf A-D routes are those whose 488 "route key" field is identical to the NLRI of the S-PMSI A-D 489 route. 491 2. The S-PMSI A-D route that is the match for transmission carries a 492 PTA that has the LIR-pF flag. 494 In this case, the corresponding Leaf A-D routes are those whose 495 "route key" field is derived from the NLRI of the S-PMSI A-D 496 route according to the procedures described in Section 5.2 of 497 [EXPLICIT_TRACKING]. 499 The Leaf A-D route from a given BFER will contain a PTA that 500 specifies the BFER's BFR-Prefix. With this information, the BFIR can 501 construct the BIER BitString. 503 However, if the PTA of the Leaf A-D route from a given BFER specifies 504 a sub-domain other than the one being used for transmitting the 505 packet, the bit for that BFER cannot be determined, and that BFER 506 will not receive the packet. 508 The BIER-encapsulated packet is then forwarded, according to the 509 procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially 510 Section 4, "Imposing and Processing the BIER Encapsulation", of 511 [BIER_ENCAPS].) 513 4.2. Disposition 515 When a BFER receives an MVPN multicast data packet that has been 516 BIER-encapsulated, the BIER layer passes the following information to 517 the multicast flow overlay: 519 o The BFR-prefix corresponding to the sub-domain-id and BFIR-id in 520 the BIER header. 522 o The "payload", which is an MPLS packet whose top label is an 523 upstream-assigned label. The BFR-prefix provides the "context" in 524 which the upstream-assigned label is interpreted. 526 Note that per [RFC5331], the context for an upstream-assigned 527 label is the IP address of the label assigner, which in this case 528 is the BFR-prefix of the BFIR. 530 By looking up the upstream-assigned label in the appropriate context, 531 the multicast flow overlay determines whether the BFER is an egress 532 PE for the packet. 534 Note that if segmented P-tunnels are in use, a BFER might be a 535 P-tunnel segmentation border router rather than an egress PE, or a 536 BFER might be both an egress PE and a P-tunnel segmentation border 537 router. Depending upon the role of the BFER for given packet, it may 538 need to follow the procedures of Section 4.2.1, the procedures of 539 Section 4.2.2, or both. 541 4.2.1. At a BFER that is an Egress PE 543 From looking up the packet's upstream-assigned label in the context 544 of the packet's BFIR-prefix, the egress PE determines the egress VRF 545 for the packet. From the IP header of the payload, the multicast 546 states of the VRF, the upstream-assigned label, and the BFR-prefix, 547 the egress PE can determine whether the packet needs to be forwarded 548 out one or more VRF interfaces. 550 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary 552 When segmented P-tunnels are being used, a BFER that receives a BIER- 553 encapsulated MVPN multicast data packet may need to be forwarded on 554 its next P-tunnel segment. The choice of the next P-tunnel segment 555 for the packet depends upon the C-flow to which the packet belongs. 556 As long as the BFIR has assigned the MPLS label according to the 557 constraints specified in Section 2.1, the BFIR will have assigned 558 distinct upstream-assigned MPLS labels to distinct C-flows. The BFER 559 can thus select the proper "next P-tunnel segment" for a given packet 560 simply by looking up the upstream-assigned label that immediately 561 follows the BIER header. 563 5. Contributor Addresses 565 Below is a list of other contributing authors in alphabetical order: 567 IJsbrand Wijnands 568 Cisco Systems, Inc. 569 De Kleetlaan 6a 570 Diegem 1831 571 Belgium 573 Email: ice@cisco.com 575 6. Acknowledgments 577 The authors wish to thank Jeffrey Zhang for his ideas and 578 contributions to this work. We also thank Stig Venaas for his review 579 and comments. 581 7. IANA Considerations 583 IANA is requested to assign a value for "BIER" from the "P-Multicast 584 Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The 585 reference should be this document. 587 8. Security Considerations 589 The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513] 590 and [RFC6514] are applicable. 592 9. References 594 9.1. Normative References 596 [BIER_ARCH] 597 Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 598 and S. Aldrin, "Multicast using Bit Index Explicit 599 Replication", internet-draft draft-ietf-bier-architecture- 600 07, June 2017. 602 [BIER_ENCAPS] 603 Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and 604 S. Aldrin, "Encapsulation for Bit Index Explicit 605 Replication in MPLS Networks", internet-draft draft-ietf- 606 bier-mpls-encapsulation-07.txt, June 2017. 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, 610 DOI 10.17487/RFC2119, March 1997, 611 . 613 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 614 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 615 2006, . 617 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 618 Label Assignment and Context-Specific Label Space", 619 RFC 5331, DOI 10.17487/RFC5331, August 2008, 620 . 622 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 623 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 624 2012, . 626 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 627 Encodings and Procedures for Multicast in MPLS/BGP IP 628 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 629 . 631 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 632 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 633 RFC 6625, DOI 10.17487/RFC6625, May 2012, 634 . 636 9.2. Informative References 638 [EXPLICIT_TRACKING] 639 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 640 "Explicit Tracking with Wild Card Routes in Multicast 641 VPN", internet-draft draft-ietf-bess-mvpn-expl-track-02, 642 June 2017. 644 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 645 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 646 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 647 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 648 . 650 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 651 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 652 RFC 7900, DOI 10.17487/RFC7900, June 2016, 653 . 655 Authors' Addresses 656 Eric C. Rosen (editor) 657 Juniper Networks, Inc. 658 10 Technology Park Drive 659 Westford, Massachusetts 01886 660 United States 662 Email: erosen@juniper.net 664 Mahesh Sivakumar 665 Cisco Systems, Inc. 666 510 McCarthy Blvd 667 Milpitas, California 95035 668 United States 670 Email: masivaku@cisco.com 672 Sam K Aldrin 673 Google, Inc. 674 1600 Amphitheatre Parkway 675 Mountain View, California 676 United States 678 Email: aldrin.ietf@gmail.com 680 Andrew Dolganow 681 Nokia 682 600 March Rd. 683 Ottawa, Ontario K2K 2E6 684 Canada 686 Email: andrew.dolganow@nokia.com 688 Tony Przygienda 689 Juniper Networks, Inc. 690 1137 Innovation Way 691 San Jose, California 94089 692 United States 694 Email: prz@juniper.net