idnits 2.17.1 draft-ietf-bier-evpn-03.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 (April 16, 2020) is 1464 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 321, but not defined == Unused Reference: 'I-D.ietf-bess-evpn-optimized-ir' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-tunnel-encaps' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC8317' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'I-D.boutros-bess-evpn-geneve' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-php' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'I-D.keyupate-bess-evpn-virtual-hub' is defined on line 606, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-08 == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-04 == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-optimized-ir-06 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-15 == Outdated reference: A later version (-11) exists of draft-ietf-bier-php-04 == Outdated reference: A later version (-04) exists of draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01 Summary: 0 errors (**), 0 flaws (~~), 16 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: October 18, 2020 A. Sajassi 6 Cisco Systems 7 J. Rabadan 8 Nokia 9 April 16, 2020 11 EVPN BUM Using BIER 12 draft-ietf-bier-evpn-03 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 October 18, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 12 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)" 204 [I-D.ietf-bess-mvpn-expl-track] 206 * "Leaf Info Required Bit (LIR)" 208 Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI 209 A-D, or per-region I-PMSI A-D route, the route MUST NOT be 210 distributed beyond the boundaries of a BIER domain. That is, any 211 routers that receive the route must be in the same BIER domain as the 212 originator of the route. If the originator is in more than one BIER 213 domain, the route must be distributed only within the BIER domain in 214 which the BFR-Prefix in the PTA uniquely identifies the originator. 215 As with all MVPN routes, distribution of these routes is controlled 216 by the provisioning of Route Targets. 218 2.1. IP Based Tunnel and BIER PHP 220 When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP 221 header (and UDP header in case of VXLAN/GENVE) is not included in the 222 BIER payload, except when it is known apriori that BIER PHP [I- 223 D.ietf-bier-php] is used in the BIER domain and the encapsulation 224 (after BIER header is popped) between the BIER Penultimate Hop and 225 the egress PE does not have a way to indicate the next header is 226 VXLAN/NVGRE/GENEVE. In that case the full VXLAN/NVGRE/GENEVE 227 encapsulation with an IP header MUST be included in the BIER payload. 228 A well-known IP multicast address (to be assigned by IANA) is used as 229 the destination address and the egress PEs MUST be set up to receive 230 and process packets addressed to the address. The address is used 231 for all BDs, and the inner VXLAN/NVGRE/GENEVE header will be used to 232 identify BDs. 234 2.2. Explicit Tracking 236 When using BIER to transport an EVPN BUM data packet through a BIER 237 domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR 238 must determine the set of BFERs to which the packet needs to be 239 delivered. This can be done in either of two ways in the following 240 two sections. 242 2.2.1. Using IMET/SMET routes 244 Both IMET and SMET (Selective Multicast Ethernet Tag 245 [I-D.ietf-bess-evpn-igmp-mld-proxy]) routes provide explicit tracking 246 functionality. 248 For an inclusive PMSI, the set of BFERs to deliver traffic to 249 includes the originators of all IMET routes for a broadcast domain. 250 For a selective PMSI, the set of BFERs to deliver traffic to includes 251 the originators of corresponding SMET routes. 253 The SMET routes do not carry a PTA. When an ingress PE sends traffic 254 on a selective tunnel using BIER, it uses the upstream assigned label 255 that is advertised in its IMET route. 257 Only when selectively forwarding is for all flows without tunnel 258 segmentation, SMET routes are used without the need for S-PMSI A-D 259 routes. Otherwise, the procedures in the following section apply. 261 2.2.2. Using S-PMSI/Leaf A-D Routes 263 There are two cases where S-PMSI/Leaf A-D routes are used as 264 discussed in the following two sections. 266 2.2.2.1. Selective Forwarding Only for Some Flows 268 With the SMET procedure, a PE advertises an SMET route for each 269 (C-S,C-G) or (C-*,C-G) state that it learns on its ACs, and each SMET 270 route is tracked by every PE in the same broadcast domain. It may be 271 desired that SMET routes are not used to reduce the burden of 272 explicit tracking. 274 In this case, most multicast traffic will follow the I-PMSI 275 (advertised via IMET route) and only some flows follow S-PMSIs. To 276 achieve that, S-PMSI/Leaf A-D routes can be used, as specified in 277 [I-D.ietf-bess-evpn-bum-procedure-updates]. 279 The rules specified in Section 2.2.1 and Section 2.2.2 of [RFC8556] 280 apply. 282 2.2.2.2. Tunnel Segmentation 284 Another case where S-PMSI/Leaf A-D routes are necessary is tunnel 285 segmentation, which is also specified in 286 [I-D.ietf-bess-evpn-bum-procedure-updates], and further clarified in 287 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] for segmentation with 288 SMET routes. This is only applicable to EVPN-MPLS. 290 The rules specified in Section 2.2.1 of [RFC8556] apply. 291 Section 2.2.2 of [RFC8556] do not apply, because similar to MVPN, the 292 LIR-pF flag cannot be used with segmentation. 294 2.2.2.3. Applicability of Additional MVPN Sepcifications 296 As with the MVPN case, Section "3. Use of the PMSI Tunnel Attribute 297 in Leaf A-D routes" of [RFC8556] apply. 299 Notice that, [RFC8556] refers to procedures specified in [RFC6625] 300 and [I-D.ietf-bess-mvpn-expl-track]. Those two documents were 301 specified for MVPN but are actually applicable to IP multicast 302 payload in EVPN as well. 304 2.3. MPLS Label in PTA 306 Rules in section 2.1 of [RFC8556] apply, EXCEPT the following three 307 bullets (they do NOT apply to EVPN) in that section: 309 o If the two routes do not have the same Address Family Identifier 310 (AFI) value, then their respective PTAs MUST contain different 311 MPLS label values. This ensures that when an egress PE receives a 312 data packet with the given label, the egress PE can infer from the 313 label whether the payload is an IPv4 packet or an IPv6 packet. 315 o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900]) 316 functionality, and if the two routes originate from different VRFs 317 on this ingress PE, then the respective PTAs of the two routes 318 MUST contain different MPLS label values. 320 o If the BFIR is an ingress PE supporting the "Extranet Separation" 321 feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if 322 one of the routes carries the "Extranet Separation" extended 323 community but the other does not, then the respective PTAs of the 324 two routes MUST contain different MPLS label values. 326 3. Multihoming Split Horizon 328 For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify 329 the ES from which a BUM packet originates. A PE receiving that 330 packet from the core side will not forward it to the same ES. The 331 procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP 332 P2MP tunnels, using downstream- and upstream-assigned ESI labels 333 respectively. For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies 334 local-bias procedures, with which a PE receiving a BUM packet from 335 the core side knows from encapsulation the ingress PE so it does not 336 forward the packet to any multihoming ESes that the ingress PE is on, 337 because the ingress PE already forwarded the packet to those ESes, 338 regardless of whether the ingress PE is a DF for those ESes. 340 With BIER, the local-bias procedure still applies for EVPN- 341 VXLAN/NVGRE/GENEVE as the BFIR-id in the BIER header identifies the 342 ingress PE. For EVPN-MPLS, ESI label procedures also still apply 343 though two upstream assigned labels will be used (one for identifying 344 the broadcast domain and one for identifying the ES) - the same as in 345 the case of using a single P2MP tunnel for multiple broadcast 346 domains. The BFIR-id in the BIER header identifies the ingress PE 347 that assigned those two labels. 349 4. Data Plane 351 Similar to MVPN, the EVPN application plays the role of the 352 "multicast flow overlay" as described in [RFC8279]. 354 4.1. Encapsulation and Transmission 356 A BFIR could be either an ingress PE or a P-tunnel segmentation 357 point. The procedures are slightly different as described below. 359 4.1.1. At a BFIR that is an Ingress PE 361 To transmit a BUM data packet, an ingress PE first determines the 362 route matched for transmission and routes for tracking leaves 363 according to the following rules. 365 1. If selective forwarding is not used, or it is not an IP Multicast 366 packet after the ethernet header, the IMET route originated for 367 the BD by the ingress PE is the route matched for transmission. 368 Leaf tracking routes are all other received IMET routes for the 369 BD. 371 2. Otherwise, if selective forwarding is used for all IP Multicast 372 traffic based on SMET routes, the IMET route originated for the 373 BD by the ingress PE is the route matched for transmisssion. 375 Received SMET routes for the BD that best match the source and 376 destination IP adddress are leaf tracking routes. 378 3. Otherwise, route matched for transmission is the S-PMSI A-D route 379 originated by the ingress PE for the BD, that best matches the 380 packet's source and destination IP address and has a PTA 381 specifying a valid tunnel type that is not "no tunnel info". 382 Leaf tracking routes are determined as following: 384 1) If the match for transmission route carries a PTA that has 385 the LIR flag set but does not have the LIR-pF flag set, the 386 routes matched for tracking are Leaf A-D routes whose "route 387 key" field is identical to the NLRI of the S-PMSI A-D route. 389 2) If the match for transmission route carries a PTA that has 390 the LIR-pF flag, the leaf tracking routes are Leaf A-D routes 391 whose "route key" field is derived from the NLRI of the 392 S-PMSI A-D route according to the procedures described in 393 Section 5.2 of [I-D.ietf-bess-mvpn-expl-track]. 395 Note that in both cases, SMET routes may be used in lieu of Leaf 396 A-D routes, as a PE may omit the Leaf A-D route in response to an 397 S-PMSI A-D route with LIR or LIR-pF bit set, if an SMET route 398 with the corresponding Tag, Source and Group fields is already 399 originated [I-D.ietf-bess-evpn-bum-procedure-updates]. In 400 particular, in the second case above, even though the SMET route 401 does not have a PTA attached, it is still considered as a Leaf 402 A-D route in response to a wildcard S-PMSI A-D route with the 403 LIR-pF bit set. 405 4. Otherwise, route matched for transmission and leaf tracking 406 routes are determined as in rule 1. 408 If no route is matched for transmission, the packet is not forwarded 409 onto a p-tunnel. If the tunnel that the ingress determines to use 410 based on the route matched for transmission (and considering 411 interworking with PEs that do not support certain tunnel types per 412 procedures in [I-D.ietf-bess-evpn-igmp-mld-proxy]) requires leaf 413 tracking (e.g. Ingress Replication, RSVP-TE P2MP tunnel, or BIER) 414 but there are no leaf tracking routes, the packet will not be 415 forwarded onto a p-tunnel either. 417 The following text assumes that BIER is the determined tunnel type. 418 The ingress PE pushes an upstream assigned ESI label per [RFC7432] if 419 the following conditions are all met: 421 o The packet is received on a multihomed ES. 423 o It's EVPN-MPLS. 425 o ESI label procedure is used for split-horizon. 427 The MPLS label from the PTA of the route matched for transmission is 428 then pushed onto the packet's label stack for EVPN-MPLS. For EVPN- 429 VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to the 430 packet with the VNI/VSID set to the value in the PTA's label field, 431 and then an IP/UDP header is prepended if needed (e.g. for PHP 432 purpose). 434 Then the packet is encapsulated in a BIER header and forwarded, 435 according to the procedures of [RFC8279] and [RFC8296]. See 436 especially Section 4, "Imposing and Processing the BIER 437 Encapsulation", of [RFC8296]. The "Proto" field in the BIER header 438 is set to 2 in case of EVPN-MPLS, or a value to be assigned in case 439 of EVPN-VXLAN/NVGRE/GENEVE (Section 5) when IP header is not used, or 440 4/6 if IP header is used for EVPN-VXLAN/NVGRE/GENEVE. 442 In order to create the proper BIER header for a given packet, the 443 BFIR must know all the BFERs that need to receive that packet. This 444 is determined from the set of leaf tracking routes. 446 4.1.2. At a BFIR that is a P-tunnel Segmentation Point 448 In this case, the encapsulation for upstream segment of the p-tunnel 449 includes (among other things) a label that identifies the x-PMSI or 450 IMET A-D route that is the match for reception on the upstream 451 segment. The segmentation point re-advertised the route into one or 452 more downstream regions. Each instance of the re-advertised route 453 for a downstream region has a PTA that specify tunnel information 454 that is the same as or different from that of the route for a 455 different region. For any particular downstream region, the route 456 matched for transmission is the re-advertised route, and the leaf 457 tracking routes are determined as following if needed for the tunnel 458 type: 460 o If the route matched for transmission is an x-PMSI route, it must 461 have the LIR flag set in its PTA and the leaf tracking routes are 462 all the matching Leaf A-D and SMET routes received in the 463 downstream region. 465 o If the route matched for transmission is an IMET route, the leaf 466 tracking routes are all the IMET routes for the same BD received 467 in the downtream region. 469 If the downtream region uses BIER, the packet is forwarded as 470 following: the upstream segmentation's encapsulation is removed and 471 the above mentioned label is swapped to the upstream-assigned label 472 in the PTA of the route matched for transmission, and then a BIER 473 header is imposed as in Section 4.1.1. 475 4.2. Disposition 477 The same procedures in section 4.2 of [RFC8556] are followed for 478 EVPN-MPLS, except some EVPN specifics discussed in the following two 479 sub-sections in this document. 481 For EVPN-VXLAN/NVGRE/GENEVE, the only difference is that the payload 482 is VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID 483 field in the VXLAN/NVGRE/GENEVE header is used to determine the 484 corresponding mac VRF or broadcast domain. 486 4.2.1. At a BFER that is an Egress PE 488 Once the corresponding mac VRF or broadcast domain is determined from 489 the upstream assigned label or VNI/VSID, EVPN forwarding procedures 490 per [RFC7432] or [RFC8365] are followed. In case of EVPN-MPLS, if 491 there is an inner label in the label stack following the BIER header, 492 that inner label is considered as the upstream assigned ESI label for 493 split horizon purpose. 495 4.2.2. At a BFER that is a P-tunnel Segmentation Point 497 This is only applicable to EVPN-MPLS. The same procedures in 498 Section 4.2.2 of [RFC8556] are followed, subject to multihoming 499 procedures specified in [I-D.ietf-bess-evpn-bum-procedure-updates]. 501 5. IANA Considerations 503 This document requests two assignments in "BIER Next Protocol 504 Identifiers" registry, with the following two recommended values: 506 o 7: Payload is VXLAN encapsulated (no IP/UDP header) 508 o 8: Payload is NVGRE encapsulated (no IP header) 510 o 9: Payload is GENEVE encapsulated (no IP/UDP header) 512 This document requests one assignment of a multicast address for the 513 case discussed in Section 2.1. Preferrably this is assigned from the 514 Local Network Control Block (224.0.0/24). 516 6. Security Considerations 518 To be updated. 520 7. Acknowledgements 522 The authors thank Eric Rosen for his review and suggestions. 523 Additionally, much of the text is borrowed verbatim from [RFC8556]. 525 8. References 527 8.1. Normative References 529 [I-D.ietf-bess-evpn-bum-procedure-updates] 530 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 531 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 532 bess-evpn-bum-procedure-updates-08 (work in progress), 533 November 2019. 535 [I-D.ietf-bess-evpn-igmp-mld-proxy] 536 Sajassi, A., Thoria, S., Patel, K., Drake, J., and W. Lin, 537 "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp- 538 mld-proxy-04 (work in progress), September 2019. 540 [I-D.ietf-bess-evpn-optimized-ir] 541 Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A. 542 Sajassi, "Optimized Ingress Replication solution for 543 EVPN", draft-ietf-bess-evpn-optimized-ir-06 (work in 544 progress), October 2018. 546 [I-D.ietf-bess-mvpn-expl-track] 547 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 548 "Explicit Tracking with Wild Card Routes in Multicast 549 VPN", draft-ietf-bess-mvpn-expl-track-13 (work in 550 progress), November 2018. 552 [I-D.ietf-idr-tunnel-encaps] 553 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 554 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 555 (work in progress), December 2019. 557 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 558 Requirement Levels", BCP 14, RFC 2119, 559 DOI 10.17487/RFC2119, March 1997, 560 . 562 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 563 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 564 RFC 6625, DOI 10.17487/RFC6625, May 2012, 565 . 567 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 568 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 569 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 570 2015, . 572 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 573 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 574 Explicit Replication (BIER)", RFC 8279, 575 DOI 10.17487/RFC8279, November 2017, 576 . 578 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 579 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 580 for Bit Index Explicit Replication (BIER) in MPLS and Non- 581 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 582 2018, . 584 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 585 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 586 Support in Ethernet VPN (EVPN) and Provider Backbone 587 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 588 January 2018, . 590 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 591 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 592 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 593 2019, . 595 8.2. Informative References 597 [I-D.boutros-bess-evpn-geneve] 598 Boutros, S., Sajassi, A., Drake, J., Rabadan, J., and S. 599 Aldrin, "EVPN control plane for Geneve", draft-boutros- 600 bess-evpn-geneve-04 (work in progress), March 2019. 602 [I-D.ietf-bier-php] 603 Zhang, Z., "BIER Penultimate Hop Popping", draft-ietf- 604 bier-php-04 (work in progress), October 2019. 606 [I-D.keyupate-bess-evpn-virtual-hub] 607 Patel, K., Sajassi, A., Drake, J., Zhang, Z., and W. 608 Henderickx, "Virtual Hub-and-Spoke in BGP EVPNs", draft- 609 keyupate-bess-evpn-virtual-hub-02 (work in progress), 610 September 2019. 612 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] 613 Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN 614 C-Multicast Routes Enhancements", draft-zzhang-bess-mvpn- 615 evpn-cmcast-enhancements-01 (work in progress), March 616 2019. 618 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 619 Uttaro, J., and W. Henderickx, "A Network Virtualization 620 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 621 DOI 10.17487/RFC8365, March 2018, 622 . 624 Authors' Addresses 626 Zhaohui Zhang 627 Juniper Networks 629 EMail: zzhang@juniper.net 631 Antoni Przygienda 632 Juniper Networks 634 EMail: prz@juniper.net 636 Ali Sajassi 637 Cisco Systems 639 EMail: sajassi@cisco.com 641 Jorge Rabadan 642 Nokia 644 EMail: jorge.rabadan@nokia.com