idnits 2.17.1 draft-ietf-bier-evpn-01.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 27, 2018) is 2191 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 156, but not defined == Missing Reference: 'RFC7900' is mentioned on line 304, but not defined == Unused Reference: 'RFC2119' is defined on line 527, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-03 == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-01 == Outdated reference: A later version (-13) exists of draft-ietf-bess-mvpn-expl-track-09 == Outdated reference: A later version (-04) exists of draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-00 Summary: 0 errors (**), 0 flaws (~~), 8 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 29, 2018 A. Sajassi 6 Cisco Systems 7 J. Rabadan 8 Nokia 9 April 27, 2018 11 EVPN BUM Using BIER 12 draft-ietf-bier-evpn-01 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 29, 2018. 43 Copyright Notice 45 Copyright (c) 2018 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. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 5 64 2.1.1. Using IMET/SMET routes . . . . . . . . . . . . . . . 5 65 2.1.2. Using S-PMSI/Leaf A-D Routes . . . . . . . . . . . . 6 66 2.2. MPLS Label in PTA . . . . . . . . . . . . . . . . . . . . 7 67 3. Multihoming Split Horizon . . . . . . . . . . . . . . . . . . 7 68 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 8 70 4.1.1. At a BFIR that is an Ingress PE . . . . . . . . . . . 8 71 4.1.2. At a BFIR that is a P-tunnel Segmentation Point . . . 10 72 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 10 74 4.2.2. At a BFER that is a P-tunnel Segmentation Point . . . 11 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 [RFC7432] and [RFC8365] specify the protocols and procedures for 86 Ethernet VPNs (EVPNs). For broadcast, unknown unicast and multicast 87 (BUM) traffic, provider/underlay tunnels (referred to as P-tunnels) 88 are used to carry the BUM traffic. Several kinds of tunnel 89 technologies can be used, as specified in [RFC7432]. 91 Bit Index Explicit Replication (BIER) ([RFC8279]) is an architecture 92 that provides optimal multicast forwarding through a "multicast 93 domain", without requiring intermediate routers to maintain any per- 94 flow state or to engage in an explicit tree-building protocol. The 95 purpose of this document is to specify the protocols and procedures 96 to transport EVPN BUM traffic using BIER. 98 The EVPN BUM procedures specified in [RFC7432] and extended in 99 [I-D.ietf-bess-evpn-bum-procedure-updates], 100 [I-D.ietf-bess-evpn-igmp-mld-proxy], and 101 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] are much aligned with 102 MVPN procedures. As such, this document is also very much aligned 103 with [I-D.ietf-bier-mvpn]. For terseness, some background, terms and 104 concepts are not repeated here. Additionally, some text is borrowed 105 verbatim from [I-D.ietf-bier-mvpn]. 107 1.1. Terminologies 109 o BFR: Bit-Forwarding Router. 111 o BFIR: Bit-Forwarding Ingress Router. 113 o BFER: Bit-Forwarding Egress Router. 115 o BFR-Prefix: An IP address that uniquely identifies a BFR and is 116 routeable in a BIER domain. 118 o C-S: A multicast source address, identifying a multicast source 119 located at a VPN customer site. 121 o C-G: A multicast group address used by a VPN customer. 123 o C-flow: A customer multicast flow. Each C-flow is identified by 124 the ordered pair (source address, group address), where each 125 address is in the customer's address space. The identifier of a 126 particular C-flow is usually written as (C-S,C-G). Sets of 127 C-flows can be identified by the use of the "C-*" wildcard (see 128 [RFC6625]), e.g., (C-*,C-G). 130 o P-tunnel. A multicast tunnel through the network of one or more 131 SPs. P-tunnels are used to transport MVPN multicast data 133 o IMET Route: Inclusive Multicast Ethernet Tag Auto-Discovery route. 134 Carried in BGP Update messages, these routes are used to advertise 135 the "default" P-tunnel for a particular broadcast domain. 137 o SMET Route: Selective Multicast Ethernet Tag Auto-Discovery route. 138 Carried in BGP Update messages, these routes are used to advertise 139 the C-flows that the advertising PE is interested in. 141 o S-PMSI A-D route: Selective Provider Multicast Service Interface 142 Auto-Discovery route. Carried in BGP Update messages, these 143 routes are used to advertise the fact that particular C-flows are 144 bound to (i.e., are traveling through) particular P-tunnels. 146 o PMSI Tunnel attribute (PTA). This BGP attribute carried is used 147 to identify a particular P-tunnel. When C-flows of multiple VPNs 148 are carried in a single P-tunnel, this attribute also carries the 149 information needed to multiplex and demultiplex the C-flows. 151 2. Use of the PMSI Tunnel Attribute 153 [RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET) 154 routes carry a PMSI Tunnel Attribute (PTA) to identify the particular 155 P-tunnel to which one or more BUM flows are being assigned, the same 156 as specified in [RFC6514] for MVPN. [I-D.ietf-bier-mvpn] specifies 157 the encoding of PTA for use of BIER with MVPN. Much of that 158 specification is reused for use of BIER with EVPN and much of the 159 text below is borrowed verbatim from [I-D.ietf-bier-mvpn]. 161 The PMSI Tunnel Attribute (PTA) contains the following fields: 163 o "Tunnel Type". The same codepoint 0x0B that IANA has assigned for 164 [I-D.ietf-bier-mvpn] for the new tunnel type "BIER" is used for 165 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 [I-D.ietf-bier-mvpn]. 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.2. For EVPN-VXLAN/NVGRE 196 [RFC8365], this field is a 24-bit VNI/VSID of global significance. 198 o "Flags". When the tunnel type is BIER, two of the flags in the 199 PTA Flags field are meaningful. Details about the use of these 200 flags can be found in Section 2.1. 202 * "Leaf Info Required per Flow (LIR-pF)" 203 [I-D.ietf-bess-mvpn-expl-track] 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. Explicit Tracking 219 When using BIER to transport an EVPN BUM data packet through a BIER 220 domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR 221 must determine the set of BFERs to which the packet needs to be 222 delivered. This can be done in either of two ways in the following 223 two sections. 225 2.1.1. Using IMET/SMET routes 227 Both IMET and SMET (Selective Multicast Ethernet Tag 228 [I-D.ietf-bess-evpn-igmp-mld-proxy]) routes provide explicit tracking 229 functionality. 231 For an inclusive PMSI, the set of BFERs to deliver traffic to 232 includes the originators of all IMET routes for a broadcast domain. 233 For a selective PMSI, the set of BFERs to deliver traffic to includes 234 the originators of corresponding SMET routes. 236 The SMET routes do not carry a PTA. When an ingress PE sends traffic 237 on a selective tunnel using BIER, it uses the upstream assigned label 238 that is advertised in its IMET route. 240 Only when selectively forwarding is for all flows without tunnel 241 segmentation, SMET routes are used without the need for S-PMSI A-D 242 routes. Otherwise, the procedures in the following section apply. 244 2.1.2. Using S-PMSI/Leaf A-D Routes 246 There are two cases where S-PMSI/Leaf A-D routes are used as 247 discussed in the following two sections. 249 2.1.2.1. Selective Forwarding Only for Some Flows 251 With the SMET procedure, a PE advertises an SMET route for each 252 (C-S,C-G) or (C-*,C-G) state that it learns on its ACs, and each SMET 253 route is tracked by every PE in the same broadcast domain. It may be 254 desired that SMET routes are not used to reduce the burden of 255 explicit tracking. 257 In this case, most multicast traffic will follow the I-PMSI 258 (advertised via IMET route) and only some flows follow S-PMSIs. To 259 achieve that, S-PMSI/Leaf A-D routes can be used, as specified in 260 [I-D.ietf-bess-evpn-bum-procedure-updates]. 262 The rules specified in Section 2.2.1 and Section 2.2.2 of 263 [I-D.ietf-bier-mvpn] apply. 265 2.1.2.2. Tunnel Segmentation 267 Another case where S-PMSI/Leaf A-D routes are necessary is tunnel 268 segmentation, which is also specified in 269 [I-D.ietf-bess-evpn-bum-procedure-updates], and further clarified in 270 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] for segmentation with 271 SMET routes. This is only applicable to EVPN-MPLS. 273 The rules specified in Section 2.2.1 of [I-D.ietf-bier-mvpn] apply. 274 Section 2.2.2 of [I-D.ietf-bier-mvpn] do not apply, because similar 275 to MVPN, the LIR-pF flag cannot be used with segmentation. 277 2.1.2.3. Applicability of Additional MVPN Sepcifications 279 As with the MVPN case, Section "3. Use of the PMSI Tunnel Attribute 280 in Leaf A-D routes" of [I-D.ietf-bier-mvpn] apply. 282 Notice that, [I-D.ietf-bier-mvpn] refers to procedures specified in 283 [RFC6625] and [I-D.ietf-bess-mvpn-expl-track]. Those two documents 284 were specified for MVPN but are actually applicable to IP multicast 285 payload in EVPN as well. 287 2.2. MPLS Label in PTA 289 Rules in section 2.1 of [I-D.ietf-bier-mvpn] apply, EXCEPT the 290 following three bullets (they do NOT apply to EVPN) in that section: 292 o If the two routes do not have the same Address Family Identifier 293 (AFI) value, then their respective PTAs MUST contain different 294 MPLS label values. This ensures that when an egress PE receives a 295 data packet with the given label, the egress PE can infer from the 296 label whether the payload is an IPv4 packet or an IPv6 packet. 298 o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900]) 299 functionality, and if the two routes originate from different VRFs 300 on this ingress PE, then the respective PTAs of the two routes 301 MUST contain different MPLS label values. 303 o If the BFIR is an ingress PE supporting the "Extranet Separation" 304 feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if 305 one of the routes carries the "Extranet Separation" extended 306 community but the other does not, then the respective PTAs of the 307 two routes MUST contain different MPLS label values. 309 3. Multihoming Split Horizon 311 For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify 312 the ES from which a BUM packet originates. A PE receiving that 313 packet from the core side will not forward it to the same ES. The 314 procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP 315 P2MP tunnels, using downstream- and upstream-assigned ESI labels 316 respectively. For EVPN-VXLAN/NVGRE, [RFC8365] specifies local-bias 317 procedures, with which a PE receiving a BUM packet from the core side 318 knows from encapsulation the ingress PE so it does not forward the 319 packet to any multihoming ESes that the ingress PE is on, because the 320 ingress PE already forwarded the packet to those ESes, regardless of 321 whether the ingress PE is a DF for those ESes. 323 With BIER, the local-bias procedure still applies for EVPN-VXLAN/ 324 NVGRE as the BFIR-id in the BIER header identifies the ingress PE. 325 For EVPN-MPLS, ESI label procedures also still apply though two 326 upstream assigned labels will be used (one for identifying the 327 broadcast domain and one for identifying the ES) - the same as in the 328 case of using a single P2MP tunnel for multiple broadcast domains. 329 The BFIR-id in the BIER header identifies the ingress PE that 330 assigned those two labels. 332 4. Data Plane 334 Similar to MVPN, the EVPN application plays the role of the 335 "multicast flow overlay" as described in [RFC8279]. 337 4.1. Encapsulation and Transmission 339 A BFIR could be either an ingress PE or a P-tunnel segmentation 340 point. The procedures are slightly different as described below. 342 4.1.1. At a BFIR that is an Ingress PE 344 To transmit a BUM data packet, an ingress PE first determines the 345 route matched for transmission and routes for tracking leaves 346 according to the following rules. 348 1. If selective forwarding is not used, or it is not an IP Multicast 349 packet after the ethernet header, the IMET route originated for 350 the BD by the ingress PE is the route matched for transmission. 351 Leaf tracking routes are all other received IMET routes for the 352 BD. 354 2. Otherwise, if selective forwarding is used for all IP Multicast 355 traffic based on SMET routes, the IMET route originated for the 356 BD by the ingress PE is the route matched for transmisssion. 357 Received SMET routes for the BD that best match the source and 358 destination IP adddress are leaf tracking routes. 360 3. Otherwise, route matched for transmission is the S-PMSI A-D route 361 originated by the ingress PE for the BD, that best matches the 362 packet's source and destination IP address and has a PTA 363 specifying a valid tunnel type that is not "no tunnel info". 364 Leaf tracking routes are determined as following: 366 1) If the match for transmission route carries a PTA that has 367 the LIR flag set but does not have the LIR-pF flag set, the 368 routes matched for tracking are Leaf A-D routes whose "route 369 key" field is identical to the NLRI of the S-PMSI A-D route. 371 2) If the match for transmission route carries a PTA that has 372 the LIR-pF flag, the leaf tracking routes are Leaf A-D routes 373 whose "route key" field is derived from the NLRI of the 374 S-PMSI A-D route according to the procedures described in 375 Section 5.2 of [I-D.ietf-bess-mvpn-expl-track]. 377 Note that in both cases, SMET routes may be used in lieu of Leaf 378 A-D routes, as a PE may omit the Leaf A-D route in response to an 379 S-PMSI A-D route with LIR or LIR-pF bit set, if an SMET route 380 with the corresponding Tag, Source and Group fields is already 381 originated [I-D.ietf-bess-evpn-bum-procedure-updates]. In 382 particular, in the second case above, even though the SMET route 383 does not have a PTA attached, it is still considered as a Leaf 384 A-D route in response to a wildcard S-PMSI A-D route with the 385 LIR-pF bit set. 387 4. Otherwise, route matched for transmission and leaf tracking 388 routes are determined as in rule 1. 390 If no route is matched for transmission, the packet is not forwarded 391 onto a p-tunnel. If the tunnel that the ingress determines to use 392 based on the route matched for transmission (and considering 393 interworking with PEs that do not support certain tunnel types per 394 procedures in [I-D.ietf-bess-evpn-igmp-mld-proxy]) requires leaf 395 tracking (e.g. Ingress Replication, RSVP-TE P2MP tunnel, or BIER) 396 but there are no leaf tracking routes, the packet will not be 397 forwarded onto a p-tunnel either. 399 The following text assumes that BIER is the determined tunnel type. 400 The ingress PE pushes an upstream assigned ESI label per [RFC7432] if 401 the following conditions are all met: 403 o The packet is received on a multihomed ES. 405 o It's EVPN-MPLS. 407 o ESI label procedure is used for split-horizon. 409 The (upstream-assigned) MPLS label from the PTA of the route matched 410 for transmission is then pushed onto the packet's label stack in case 411 of EVPN-MPLS. In case of EVPN-VXLAN/NVGRE, a VXLAN/NVGRE header is 412 prepended to the packet with the VNI/VSID set to the value in the 413 PTA's label field and no IP/UDP header is used. 415 Then the packet is encapsulated in a BIER header and forwarded, 416 according to the procedures of [RFC8279] and [RFC8296]. See 417 especially Section 4, "Imposing and Processing the BIER 418 Encapsulation", of [RFC8296]. The "Proto" field in the BIER header 419 is set to 2 in case of EVPN-MPLS or a value to be assigned in case of 420 EVPN-VXLAN/NVGRE (Section 5). 422 In order to create the proper BIER header for a given packet, the 423 BFIR must know all the BFERs that need to receive that packet. This 424 is determined from the set of leaf tracking routes. 426 4.1.2. At a BFIR that is a P-tunnel Segmentation Point 428 In this case, the encapsulation for upstream segment of the p-tunnel 429 includes (among other things) a label that identifies the x-PMSI or 430 IMET A-D route that is the match for reception on the upstream 431 segment. The segmentation point re-advertised the route into one or 432 more downstream regions. Each instance of the re-advertised route 433 for a downstream region has a PTA that specify tunnel information 434 that is the same as or different from that of the route for a 435 different region. For any particular downstream region, the route 436 matched for transmission is the re-advertised route, and the leaf 437 tracking routes are determined as following if needed for the tunnel 438 type: 440 o If the route matched for transmission is an x-PMSI route, it must 441 have the LIR flag set in its PTA and the leaf tracking routes are 442 all the matching Leaf A-D and SMET routes received in the 443 downstream region. 445 o If the route matched for transmission is an IMET route, the leaf 446 tracking routes are all the IMET routes for the same BD received 447 in the downtream region. 449 If the downtream region uses BIER, the packet is forwarded as 450 following: the upstream segmentation's encapsulation is removed and 451 the above mentioned label is swapped to the upstream-assigned label 452 in the PTA of the route matched for transmission, and then a BIER 453 header is imposed as in Section 4.1.1. 455 4.2. Disposition 457 The same procedures in section 4.2 of [I-D.ietf-bier-mvpn] are 458 followed for EVPN-MPLS, except some EVPN specifics discussed in the 459 following two sub-sections in this document. 461 For EVPN-VXLAN/NVGRE, the only difference is that the payload is 462 VXLAN/NVGRE and the VNI/VSID field in the VXLAN/NVGRE header is used 463 to determine the corresponding mac VRF or broadcast domain. 465 4.2.1. At a BFER that is an Egress PE 467 Once the corresponding mac VRF or broadcast domain is determined from 468 the upstream assigned label or VNI/VSID, EVPN forwarding procedures 469 per [RFC7432] or [RFC8365] are followed. In case of EVPN-MPLS, if 470 there is an inner label in the label stack following the BIER header, 471 that inner label is considered as the upstream assigned ESI label for 472 split horizon purpose. 474 4.2.2. At a BFER that is a P-tunnel Segmentation Point 476 This is only applicable to EVPN-MPLS. The same procedures in 477 Section 4.2.2 of [I-D.ietf-bier-mvpn] are followed, subject to 478 multihoming procedures specified in 479 [I-D.ietf-bess-evpn-bum-procedure-updates]. 481 5. IANA Considerations 483 This document requests two assignments in "BIER Next Protocol 484 Identifiers" registry, with the following two recommended values: 486 o 7: Payload is VXLAN encapsulated (no IP/UDP header) 488 o 8: Payload is NVGRE encapsulated (no IP header) 490 6. Security Considerations 492 To be updated. 494 7. Acknowledgements 496 The authors thank Eric Rosen for his review and suggestions. 497 Additionally, much of the text is borrowed verbatim from 498 [I-D.ietf-bier-mvpn]. 500 8. References 502 8.1. Normative References 504 [I-D.ietf-bess-evpn-bum-procedure-updates] 505 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 506 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 507 bess-evpn-bum-procedure-updates-03 (work in progress), 508 April 2018. 510 [I-D.ietf-bess-evpn-igmp-mld-proxy] 511 Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., 512 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- 513 bess-evpn-igmp-mld-proxy-01 (work in progress), March 514 2018. 516 [I-D.ietf-bess-mvpn-expl-track] 517 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 518 "Explicit Tracking with Wild Card Routes in Multicast 519 VPN", draft-ietf-bess-mvpn-expl-track-09 (work in 520 progress), April 2018. 522 [I-D.ietf-bier-mvpn] 523 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 524 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 525 mvpn-11 (work in progress), March 2018. 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 533 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 534 RFC 6625, DOI 10.17487/RFC6625, May 2012, 535 . 537 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 538 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 539 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 540 2015, . 542 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 543 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 544 Explicit Replication (BIER)", RFC 8279, 545 DOI 10.17487/RFC8279, November 2017, 546 . 548 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 549 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 550 for Bit Index Explicit Replication (BIER) in MPLS and Non- 551 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 552 2018, . 554 8.2. Informative References 556 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] 557 Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN 558 C-Multicast Routes Enhancements", draft-zzhang-bess-mvpn- 559 evpn-cmcast-enhancements-00 (work in progress), July 2016. 561 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 562 Uttaro, J., and W. Henderickx, "A Network Virtualization 563 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 564 DOI 10.17487/RFC8365, March 2018, 565 . 567 Authors' Addresses 569 Zhaohui Zhang 570 Juniper Networks 572 EMail: zzhang@juniper.net 574 Antoni Przygienda 575 Juniper Networks 577 EMail: prz@juniper.net 579 Ali Sajassi 580 Cisco Systems 582 EMail: sajassi@cisco.com 584 Jorge Rabadan 585 Nokia 587 EMail: jorge.rabadan@nokia.com