idnits 2.17.1 draft-ietf-bier-evpn-05.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 (December 7, 2021) is 868 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: 'RFC6514' is mentioned on line 157, but not defined == Missing Reference: 'RFC7900' is mentioned on line 319, but not defined == Unused Reference: 'I-D.ietf-bess-evpn-optimized-ir' is defined on line 537, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC8317' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'RFC9012' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'I-D.boutros-bess-evpn-geneve' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-php' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'I-D.keyupate-bess-evpn-virtual-hub' is defined on line 602, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-14 == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-optimized-ir-11 == Outdated reference: A later version (-11) exists of draft-ietf-bier-php-06 == Outdated reference: A later version (-04) exists of draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Z. Zhang 3 Internet-Draft A. Przygienda 4 Intended status: Standards Track Juniper Networks 5 Expires: June 10, 2022 A. Sajassi 6 Cisco Systems 7 J. Rabadan 8 Nokia 9 December 7, 2021 11 EVPN BUM Using BIER 12 draft-ietf-bier-evpn-05 14 Abstract 16 This document specifies protocols and procedures for forwarding 17 broadcast, unknown unicast and multicast (BUM) traffic of Ethernet 18 VPNs (EVPN) using Bit Index Explicit Replication (BIER). 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC2119. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 10, 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4 63 2.1. IP Based Tunnel and BIER PHP . . . . . . . . . . . . . . 5 64 2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 6 65 2.2.1. Using IMET/SMET routes . . . . . . . . . . . . . . . 6 66 2.2.2. Using S-PMSI/Leaf A-D Routes . . . . . . . . . . . . 6 67 2.3. MPLS Label in PTA . . . . . . . . . . . . . . . . . . . . 7 68 3. Multihoming Split Horizon . . . . . . . . . . . . . . . . . . 7 69 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 8 71 4.1.1. At a BFIR that is an Ingress PE . . . . . . . . . . . 8 72 4.1.2. At a BFIR that is a P-tunnel Segmentation Point . . . 10 73 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 11 75 4.2.2. At a BFER that is a P-tunnel Segmentation Point . . . 11 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 8.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 [RFC7432] and [RFC8365] specify the protocols and procedures for 87 Ethernet VPNs (EVPNs). For broadcast, unknown unicast and multicast 88 (BUM) traffic, provider/underlay tunnels (referred to as P-tunnels) 89 are used to carry the BUM traffic. Several kinds of tunnel 90 technologies can be used, as specified in [RFC7432]. 92 Bit Index Explicit Replication (BIER) ([RFC8279]) is an architecture 93 that provides optimal multicast forwarding through a "multicast 94 domain", without requiring intermediate routers to maintain any per- 95 flow state or to engage in an explicit tree-building protocol. The 96 purpose of this document is to specify the protocols and procedures 97 to transport EVPN BUM traffic using BIER. 99 The EVPN BUM procedures specified in [RFC7432] and extended in 100 [I-D.ietf-bess-evpn-bum-procedure-updates], 101 [I-D.ietf-bess-evpn-igmp-mld-proxy], and 102 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] are much aligned with 103 MVPN procedures. As such, this document is also very much aligned 104 with [RFC8556]. For terseness, some background, terms and concepts 105 are not repeated here. Additionally, some text is borrowed verbatim 106 from [RFC8556]. 108 1.1. Terminologies 110 o BFR: Bit-Forwarding Router. 112 o BFIR: Bit-Forwarding Ingress Router. 114 o BFER: Bit-Forwarding Egress Router. 116 o BFR-Prefix: An IP address that uniquely identifies a BFR and is 117 routeable in a BIER domain. 119 o C-S: A multicast source address, identifying a multicast source 120 located at a VPN customer site. 122 o C-G: A multicast group address used by a VPN customer. 124 o C-flow: A customer multicast flow. Each C-flow is identified by 125 the ordered pair (source address, group address), where each 126 address is in the customer's address space. The identifier of a 127 particular C-flow is usually written as (C-S,C-G). Sets of 128 C-flows can be identified by the use of the "C-*" wildcard (see 129 [RFC6625]), e.g., (C-*,C-G). 131 o P-tunnel. A multicast tunnel through the network of one or more 132 SPs. P-tunnels are used to transport MVPN multicast data 134 o IMET Route: Inclusive Multicast Ethernet Tag Auto-Discovery route. 135 Carried in BGP Update messages, these routes are used to advertise 136 the "default" P-tunnel for a particular broadcast domain. 138 o SMET Route: Selective Multicast Ethernet Tag Auto-Discovery route. 139 Carried in BGP Update messages, these routes are used to advertise 140 the C-flows that the advertising PE is interested in. 142 o S-PMSI A-D route: Selective Provider Multicast Service Interface 143 Auto-Discovery route. Carried in BGP Update messages, these 144 routes are used to advertise the fact that particular C-flows are 145 bound to (i.e., are traveling through) particular P-tunnels. 147 o PMSI Tunnel attribute (PTA). This BGP attribute carried is used 148 to identify a particular P-tunnel. When C-flows of multiple VPNs 149 are carried in a single P-tunnel, this attribute also carries the 150 information needed to multiplex and demultiplex the C-flows. 152 2. Use of the PMSI Tunnel Attribute 154 [RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET) 155 routes carry a PMSI Tunnel Attribute (PTA) to identify the particular 156 P-tunnel to which one or more BUM flows are being assigned, the same 157 as specified in [RFC6514] for MVPN. [RFC8556] specifies the encoding 158 of PTA for use of BIER with MVPN. Much of that specification is 159 reused for use of BIER with EVPN and much of the text below is 160 borrowed verbatim from [RFC8556]. 162 The PMSI Tunnel Attribute (PTA) contains the following fields: 164 o "Tunnel Type". The same codepoint 0x0B that IANA has assigned for 165 [RFC8556] for the new tunnel type "BIER" is used for EVPN as well. 167 o "Tunnel Identifier". When the "tunnel type" field is "BIER", this 168 field contains two subfields. The text below is exactly as in 169 [RFC8556]. 171 1 The first subfield is a single octet, containing the sub- 172 domain-id of the sub-domain to which the BFIR will assign the 173 packets that it transmits on the PMSI identified by the NLRI of 174 the IMET, S-PMSI A-D, or per-region I-PMSI A-D route that 175 contains this PTA. How that sub-domain is chosen is outside 176 the scope of this document. 178 2 The second subfield is a two-octet field containing the BFR-id, 179 in the sub-domain identified in the first subfield, of the 180 router that is constructing the PTA. 182 3 The third subfield is the BFR-Prefix (see [RFC8279]) of the 183 originator of the route that is carrying this PTA. This will 184 either be a /32 IPv4 address or a /128 IPv6 address. Whether 185 the address is IPv4 or IPv6 can be inferred from the total 186 length of the PMSI Tunnel attribute. 188 The BFR-prefix need not be the same IP address that is carried 189 in any other field of the x-PMSI A-D route, even if the BFIR is 190 the originating router of the x-PMSI A-D route. 192 o "MPLS label". For EVPN-MPLS [RFC7432], this field contains an 193 upstream-assigned MPLS label. It is assigned by the BFIR. 194 Constraints on the way in which the originating router selects 195 this label are discussed in Section 2.3. For EVPN-VXLAN/NVGRE/ 196 GENEVE [RFC8365], this field is a 24-bit VNI/VSID of global 197 significance. 199 o "Flags". When the tunnel type is BIER, two of the flags in the 200 PTA Flags field are meaningful. Details about the use of these 201 flags can be found in Section 2.2. 203 * "Leaf Info Required per Flow (LIR-pF)" [RFC8534] 205 * "Leaf Info Required Bit (LIR)" 207 Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI 208 A-D, or per-region I-PMSI A-D route, the route MUST NOT be 209 distributed beyond the boundaries of a BIER domain. That is, any 210 routers that receive the route must be in the same BIER domain as the 211 originator of the route. If the originator is in more than one BIER 212 domain, the route must be distributed only within the BIER domain in 213 which the BFR-Prefix in the PTA uniquely identifies the originator. 214 As with all MVPN routes, distribution of these routes is controlled 215 by the provisioning of Route Targets. 217 2.1. IP Based Tunnel and BIER PHP 219 When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP 220 header (and UDP header in case of VXLAN/GENVE) is not included in the 221 BIER payload, except when it is known apriori that BIER PHP [I- 222 D.ietf-bier-php] is used in the BIER domain and the encapsulation 223 (after BIER header is popped) between the BIER Penultimate Hop and 224 the egress PE does not have a way to indicate the next header is 225 VXLAN/NVGRE/GENEVE. In that case the full VXLAN/NVGRE/GENEVE 226 encapsulation with an IP header MUST be included in the BIER payload. 227 A well-known IP multicast address (to be assigned by IANA) is used as 228 the destination address and the egress PEs MUST be set up to receive 229 and process packets addressed to the address. The address is used 230 for all BDs, and the inner VXLAN/NVGRE/GENEVE header will be used to 231 identify BDs. 233 2.2. Explicit Tracking 235 When using BIER to transport an EVPN BUM data packet through a BIER 236 domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR 237 must determine the set of BFERs to which the packet needs to be 238 delivered. This can be done in either of two ways in the following 239 two sections. 241 2.2.1. Using IMET/SMET routes 243 Both IMET and SMET (Selective Multicast Ethernet Tag 244 [I-D.ietf-bess-evpn-igmp-mld-proxy]) routes provide explicit tracking 245 functionality. 247 For an inclusive PMSI, the set of BFERs to deliver traffic to 248 includes the originators of all IMET routes for a broadcast domain. 249 For a selective PMSI, the set of BFERs to deliver traffic to includes 250 the originators of corresponding SMET routes. 252 The SMET routes do not carry a PTA. When an ingress PE sends traffic 253 on a selective tunnel using BIER, it uses the upstream assigned label 254 that is advertised in its IMET route. 256 Only when selectively forwarding is for all flows without tunnel 257 segmentation, SMET routes are used without the need for S-PMSI A-D 258 routes. Otherwise, the procedures in the following section apply. 260 2.2.2. Using S-PMSI/Leaf A-D Routes 262 There are two cases where S-PMSI/Leaf A-D routes are used as 263 discussed in the following two sections. 265 2.2.2.1. Selective Forwarding Only for Some Flows 267 With the SMET procedure, a PE advertises an SMET route for each 268 (C-S,C-G) or (C-*,C-G) state that it learns on its ACs, and each SMET 269 route is tracked by every PE in the same broadcast domain. It may be 270 desired that SMET routes are not used to reduce the burden of 271 explicit tracking. 273 In this case, most multicast traffic will follow the I-PMSI 274 (advertised via IMET route) and only some flows follow S-PMSIs. To 275 achieve that, S-PMSI/Leaf A-D routes can be used, as specified in 276 [I-D.ietf-bess-evpn-bum-procedure-updates]. 278 The rules specified in Section 2.2.1 and Section 2.2.2 of [RFC8556] 279 apply. 281 2.2.2.2. Tunnel Segmentation 283 Another case where S-PMSI/Leaf A-D routes are necessary is tunnel 284 segmentation, which is also specified in 285 [I-D.ietf-bess-evpn-bum-procedure-updates], and further clarified in 286 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] for segmentation with 287 SMET routes. This is only applicable to EVPN-MPLS. 289 The rules specified in Section 2.2.1 of [RFC8556] apply. 290 Section 2.2.2 of [RFC8556] do not apply, because similar to MVPN, the 291 LIR-pF flag cannot be used with segmentation. 293 2.2.2.3. Applicability of Additional MVPN Sepcifications 295 As with the MVPN case, Section "3. Use of the PMSI Tunnel Attribute 296 in Leaf A-D routes" of [RFC8556] apply. 298 Notice that, [RFC8556] refers to procedures specified in [RFC6625] 299 and [RFC8534]. Those two documents were specified for MVPN but are 300 actually applicable to IP multicast payload in EVPN as well. 302 2.3. MPLS Label in PTA 304 Rules in section 2.1 of [RFC8556] apply, EXCEPT the following three 305 bullets (they do NOT apply to EVPN) in that section: 307 o If the two routes do not have the same Address Family Identifier 308 (AFI) value, then their respective PTAs MUST contain different 309 MPLS label values. This ensures that when an egress PE receives a 310 data packet with the given label, the egress PE can infer from the 311 label whether the payload is an IPv4 packet or an IPv6 packet. 313 o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900]) 314 functionality, and if the two routes originate from different VRFs 315 on this ingress PE, then the respective PTAs of the two routes 316 MUST contain different MPLS label values. 318 o If the BFIR is an ingress PE supporting the "Extranet Separation" 319 feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if 320 one of the routes carries the "Extranet Separation" extended 321 community but the other does not, then the respective PTAs of the 322 two routes MUST contain different MPLS label values. 324 3. Multihoming Split Horizon 326 For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify 327 the ES from which a BUM packet originates. A PE receiving that 328 packet from the core side will not forward it to the same ES. The 329 procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP 330 P2MP tunnels, using downstream- and upstream-assigned ESI labels 331 respectively. For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies 332 local-bias procedures, with which a PE receiving a BUM packet from 333 the core side knows from encapsulation the ingress PE so it does not 334 forward the packet to any multihoming ESes that the ingress PE is on, 335 because the ingress PE already forwarded the packet to those ESes, 336 regardless of whether the ingress PE is a DF for those ESes. 338 With BIER, the local-bias procedure still applies for EVPN- 339 VXLAN/NVGRE/GENEVE as the BFIR-id in the BIER header identifies the 340 ingress PE. For EVPN-MPLS, ESI label procedures also still apply 341 though two upstream assigned labels will be used (one for identifying 342 the broadcast domain and one for identifying the ES) - the same as in 343 the case of using a single P2MP tunnel for multiple broadcast 344 domains. The BFIR-id in the BIER header identifies the ingress PE 345 that assigned those two labels. 347 4. Data Plane 349 Similar to MVPN, the EVPN application plays the role of the 350 "multicast flow overlay" as described in [RFC8279]. 352 4.1. Encapsulation and Transmission 354 A BFIR could be either an ingress PE or a P-tunnel segmentation 355 point. The procedures are slightly different as described below. 357 4.1.1. At a BFIR that is an Ingress PE 359 To transmit a BUM data packet, an ingress PE first determines the 360 route matched for transmission and routes for tracking leaves 361 according to the following rules. 363 1. If selective forwarding is not used, or it is not an IP Multicast 364 packet after the ethernet header, the IMET route originated for 365 the BD by the ingress PE is the route matched for transmission. 366 Leaf tracking routes are all other received IMET routes for the 367 BD. 369 2. Otherwise, if selective forwarding is used for all IP Multicast 370 traffic based on SMET routes, the IMET route originated for the 371 BD by the ingress PE is the route matched for transmisssion. 372 Received SMET routes for the BD that best match the source and 373 destination IP adddress are leaf tracking routes. 375 3. Otherwise, route matched for transmission is the S-PMSI A-D route 376 originated by the ingress PE for the BD, that best matches the 377 packet's source and destination IP address and has a PTA 378 specifying a valid tunnel type that is not "no tunnel info". 379 Leaf tracking routes are determined as following: 381 1) If the match for transmission route carries a PTA that has 382 the LIR flag set but does not have the LIR-pF flag set, the 383 routes matched for tracking are Leaf A-D routes whose "route 384 key" field is identical to the NLRI of the S-PMSI A-D route. 386 2) If the match for transmission route carries a PTA that has 387 the LIR-pF flag, the leaf tracking routes are Leaf A-D routes 388 whose "route key" field is derived from the NLRI of the 389 S-PMSI A-D route according to the procedures described in 390 Section 5.2 of [RFC8534]. 392 Note that in both cases, SMET routes may be used in lieu of Leaf 393 A-D routes, as a PE may omit the Leaf A-D route in response to an 394 S-PMSI A-D route with LIR or LIR-pF bit set, if an SMET route 395 with the corresponding Tag, Source and Group fields is already 396 originated [I-D.ietf-bess-evpn-bum-procedure-updates]. In 397 particular, in the second case above, even though the SMET route 398 does not have a PTA attached, it is still considered as a Leaf 399 A-D route in response to a wildcard S-PMSI A-D route with the 400 LIR-pF bit set. 402 4. Otherwise, route matched for transmission and leaf tracking 403 routes are determined as in rule 1. 405 If no route is matched for transmission, the packet is not forwarded 406 onto a p-tunnel. If the tunnel that the ingress determines to use 407 based on the route matched for transmission (and considering 408 interworking with PEs that do not support certain tunnel types per 409 procedures in [I-D.ietf-bess-evpn-igmp-mld-proxy]) requires leaf 410 tracking (e.g. Ingress Replication, RSVP-TE P2MP tunnel, or BIER) 411 but there are no leaf tracking routes, the packet will not be 412 forwarded onto a p-tunnel either. 414 The following text assumes that BIER is the determined tunnel type. 415 The ingress PE pushes an upstream assigned ESI label per [RFC7432] if 416 the following conditions are all met: 418 o The packet is received on a multihomed ES. 420 o It's EVPN-MPLS. 422 o ESI label procedure is used for split-horizon. 424 The MPLS label from the PTA of the route matched for transmission is 425 then pushed onto the packet's label stack for EVPN-MPLS. For EVPN- 426 VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to the 427 packet with the VNI/VSID set to the value in the PTA's label field, 428 and then an IP/UDP header is prepended if needed (e.g. for PHP 429 purpose). 431 Then the packet is encapsulated in a BIER header and forwarded, 432 according to the procedures of [RFC8279] and [RFC8296]. See 433 especially Section 4, "Imposing and Processing the BIER 434 Encapsulation", of [RFC8296]. The "Proto" field in the BIER header 435 is set to 2 in case of EVPN-MPLS, or a value to be assigned in case 436 of EVPN-VXLAN/NVGRE/GENEVE (Section 5) when IP header is not used, or 437 4/6 if IP header is used for EVPN-VXLAN/NVGRE/GENEVE. 439 In order to create the proper BIER header for a given packet, the 440 BFIR must know all the BFERs that need to receive that packet. This 441 is determined from the set of leaf tracking routes. 443 4.1.2. At a BFIR that is a P-tunnel Segmentation Point 445 In this case, the encapsulation for upstream segment of the p-tunnel 446 includes (among other things) a label that identifies the x-PMSI or 447 IMET A-D route that is the match for reception on the upstream 448 segment. The segmentation point re-advertised the route into one or 449 more downstream regions. Each instance of the re-advertised route 450 for a downstream region has a PTA that specify tunnel information 451 that is the same as or different from that of the route for a 452 different region. For any particular downstream region, the route 453 matched for transmission is the re-advertised route, and the leaf 454 tracking routes are determined as following if needed for the tunnel 455 type: 457 o If the route matched for transmission is an x-PMSI route, it must 458 have the LIR flag set in its PTA and the leaf tracking routes are 459 all the matching Leaf A-D and SMET routes received in the 460 downstream region. 462 o If the route matched for transmission is an IMET route, the leaf 463 tracking routes are all the IMET routes for the same BD received 464 in the downtream region. 466 If the downtream region uses BIER, the packet is forwarded as 467 following: the upstream segmentation's encapsulation is removed and 468 the above mentioned label is swapped to the upstream-assigned label 469 in the PTA of the route matched for transmission, and then a BIER 470 header is imposed as in Section 4.1.1. 472 4.2. Disposition 474 The same procedures in section 4.2 of [RFC8556] are followed for 475 EVPN-MPLS, except some EVPN specifics discussed in the following two 476 sub-sections in this document. 478 For EVPN-VXLAN/NVGRE/GENEVE, the only difference is that the payload 479 is VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID 480 field in the VXLAN/NVGRE/GENEVE header is used to determine the 481 corresponding mac VRF or broadcast domain. 483 4.2.1. At a BFER that is an Egress PE 485 Once the corresponding mac VRF or broadcast domain is determined from 486 the upstream assigned label or VNI/VSID, EVPN forwarding procedures 487 per [RFC7432] or [RFC8365] are followed. In case of EVPN-MPLS, if 488 there is an inner label in the label stack following the BIER header, 489 that inner label is considered as the upstream assigned ESI label for 490 split horizon purpose. 492 4.2.2. At a BFER that is a P-tunnel Segmentation Point 494 This is only applicable to EVPN-MPLS. The same procedures in 495 Section 4.2.2 of [RFC8556] are followed, subject to multihoming 496 procedures specified in [I-D.ietf-bess-evpn-bum-procedure-updates]. 498 5. IANA Considerations 500 This document requests two assignments in "BIER Next Protocol 501 Identifiers" registry, with the following two recommended values: 503 o 7: Payload is VXLAN encapsulated (no IP/UDP header) 505 o 8: Payload is NVGRE encapsulated (no IP header) 507 o 9: Payload is GENEVE encapsulated (no IP/UDP header) 509 This document requests one assignment of a multicast address for the 510 case discussed in Section 2.1. Preferrably this is assigned from the 511 Local Network Control Block (224.0.0/24). 513 6. Security Considerations 515 To be updated. 517 7. Acknowledgements 519 The authors thank Eric Rosen for his review and suggestions. 520 Additionally, much of the text is borrowed verbatim from [RFC8556]. 522 8. References 524 8.1. Normative References 526 [I-D.ietf-bess-evpn-bum-procedure-updates] 527 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 528 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 529 bess-evpn-bum-procedure-updates-14 (work in progress), 530 November 2021. 532 [I-D.ietf-bess-evpn-igmp-mld-proxy] 533 Sajassi, A., Thoria, S., Mishra, M., Drake, J., and W. 534 Lin, "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn- 535 igmp-mld-proxy-14 (work in progress), October 2021. 537 [I-D.ietf-bess-evpn-optimized-ir] 538 Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A. 539 Sajassi, "Optimized Ingress Replication Solution for 540 Ethernet VPN (EVPN)", draft-ietf-bess-evpn-optimized-ir-11 541 (work in progress), November 2021. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, 545 DOI 10.17487/RFC2119, March 1997, 546 . 548 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 549 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 550 RFC 6625, DOI 10.17487/RFC6625, May 2012, 551 . 553 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 554 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 555 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 556 2015, . 558 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 559 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 560 Explicit Replication (BIER)", RFC 8279, 561 DOI 10.17487/RFC8279, November 2017, 562 . 564 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 565 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 566 for Bit Index Explicit Replication (BIER) in MPLS and Non- 567 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 568 2018, . 570 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 571 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 572 Support in Ethernet VPN (EVPN) and Provider Backbone 573 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 574 January 2018, . 576 [RFC8534] Dolganow, A., Kotalwar, J., Rosen, E., Ed., and Z. Zhang, 577 "Explicit Tracking with Wildcard Routes in Multicast VPN", 578 RFC 8534, DOI 10.17487/RFC8534, February 2019, 579 . 581 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 582 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 583 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 584 2019, . 586 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 587 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 588 DOI 10.17487/RFC9012, April 2021, 589 . 591 8.2. Informative References 593 [I-D.boutros-bess-evpn-geneve] 594 Boutros, S., Sajassi, A., Drake, J., Rabadan, J., and S. 595 Aldrin, "EVPN control plane for Geneve", draft-boutros- 596 bess-evpn-geneve-04 (work in progress), March 2019. 598 [I-D.ietf-bier-php] 599 Zhang, Z., "BIER Penultimate Hop Popping", draft-ietf- 600 bier-php-06 (work in progress), August 2020. 602 [I-D.keyupate-bess-evpn-virtual-hub] 603 Patel, K., Sajassi, A., Drake, J. E., Zhang, Z., and W. 604 Henderickx, "Virtual Hub-and-Spoke in BGP EVPNs", draft- 605 keyupate-bess-evpn-virtual-hub-02 (work in progress), 606 September 2019. 608 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] 609 Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN 610 C-Multicast Routes Enhancements", draft-zzhang-bess-mvpn- 611 evpn-cmcast-enhancements-01 (work in progress), March 612 2019. 614 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 615 Uttaro, J., and W. Henderickx, "A Network Virtualization 616 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 617 DOI 10.17487/RFC8365, March 2018, 618 . 620 Authors' Addresses 622 Zhaohui Zhang 623 Juniper Networks 625 EMail: zzhang@juniper.net 627 Antoni Przygienda 628 Juniper Networks 630 EMail: prz@juniper.net 632 Ali Sajassi 633 Cisco Systems 635 EMail: sajassi@cisco.com 637 Jorge Rabadan 638 Nokia 640 EMail: jorge.rabadan@nokia.com