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