idnits 2.17.1 draft-zzhang-bess-mvpn-evpn-composite-tunnel-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 29, 2019) is 1640 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: 'RFC7988' is mentioned on line 133, but not defined == Missing Reference: 'RF6514' is mentioned on line 195, but not defined == Missing Reference: 'EVPN-BIER' is mentioned on line 431, but not defined == Missing Reference: 'AR' is mentioned on line 443, but not defined == Unused Reference: 'RFC2119' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC8279' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-evpn' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 516, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-optimized-ir-06 == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-03 == Outdated reference: A later version (-14) exists of draft-ietf-bier-evpn-01 == Outdated reference: A later version (-11) exists of draft-ietf-bier-php-03 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track J. Rabadan, Ed. 5 Expires: May 1, 2020 Nokia 6 A. Sajassi 7 Cisco Systems 8 October 29, 2019 10 MVPN/EVPN Composite Tunnel 11 draft-zzhang-bess-mvpn-evpn-composite-tunnel-01 13 Abstract 15 EVPN E-Tree defines a composite tunnel to be used for a Root PE to 16 simultaneously indicate a non-Ingress-Replication tunnel (e.g., P2MP 17 tunnel) in the transmit direction and an Ingress Replication tunnel 18 in the receive direction for BUM traffic. This document extends it 19 to more generic use in both MVPN and general EVPN. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC2119. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 1, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2.1. P2MP Tunnels . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. MP2MP Tunnels . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. General MVPN/EVPN Use of Composite Tunnels . . . . . . . 4 67 3.2. EVPN-IP Assisted Replication with BIER-IR Composite 68 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. BIER-IR Composite Tunnels in EVPN Networks . . . . . . . 7 71 4.2. Assisted Replication and BIER Composite Tunnels . . . . . 8 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 8.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Terminologies 82 Familiarity with BIER/MVPN/EVPN protocols and procedures is assumed. 83 Some terminologies are listed below for convenience. 85 [To be added]. 87 2. Introduction 89 The composite tunnel defined in [RFC8317] is specifically designed 90 for the particular use case of EVPN E-Tree in that the Root PE only 91 needs to receive on the Ingress Replication (IR) tunnel and transmit 92 on the non-IR tunnel encoded in the PMSI Tunnel Attribute (PTA) that 93 specifies a Composite Tunnel, hence the following language quoted 94 from [RFC8317]: 96 Composite tunnel type is advertised by the Root PE to 97 simultaneously indicate a non-Ingress-Replication tunnel (e.g., P2MP 98 tunnel) in the transmit direction and an Ingress Replication tunnel 99 in the receive direction for the BUM traffic. 101 However, the underlying principal of MVPN PMSI A-D route, EVPN IMET 102 route and the PTA that the routes carry allows the composite tunnel 103 to be used in more generic use cases for both MVPN and EVPN, as 104 explained in Section 2.1 and Section 2.2. 106 The EVPN IMET route is the equivalent of MVPN I-PMSI A-D route. In 107 the rest of the document, unless explicitly stated, I-PMSI A-D route 108 refers to MVPN Intra-AS I-PMSI A-D route and/or EVPN IMET route. 110 2.1. P2MP Tunnels 112 As specified in [RFC6514] [RFC7432], an I-PMSI A-D route advertises a 113 PE's membership in a VPN or Broadcast Domain (BD). The route carries 114 a PTA, whose Tunnel Identifier field specifies the tunnel that the 115 advertising PE uses to send traffic unless the tunnel type is either 116 "No tunnel information present" or "Ingress Replication". A PE that 117 imports the route into a VRF/BD/EVI will join the specified tunnel if 118 it needs to receive traffic from the advertising PE. 120 As specified in [RFC6514] and clarified in [RFC7988], if the tunnel 121 type is Ingress Replication, and the Leaf Information Required (LIR) 122 bit in the PTA's Flags field is set to 0, the advertising PE is 123 actually not indicating that it uses IR to send traffic, but that it 124 will receive traffic using the label that is part of the Tunnel 125 Identifier field of the PTA. A PTA with tunnel type set to IR and 126 LIR bit set to 1 does indicate that the advertising router will use 127 IR to send traffic. In that case, the label field in the Tunnel 128 Identifier is set to 0 and receiving PEs will need to send a Leaf A-D 129 route to "join" the IR tunnel. The label value in the Tunnel 130 Identifier of the Leaf A-D route's PTA is used when sending traffic 131 to the advertiser of the Leaf A-D route. 133 While [RFC7988] is MVPN specific, the above IR procedures and 134 clarifications are also applicable to EVPN, as the EVPN IMET route is 135 the equivalent of an I-PMSI A-D route with the LIR flag set to 0. 137 In summary, w/o considering composite tunnel, when IR is specified in 138 I-PMSI A-D routes w/ the LIR bit NOT set, the tunnel is used to 139 receive traffic (even from PEs not advertising IR in its PMSI A-D 140 routes). The composite tunnel introduced in [RFC8317] combines a 141 transmitting non-IR tunnel and a receiving IR tunnel, but a PE 142 advertising a composite tunnel should be still be able to send to 143 certain PEs using IR. 145 2.2. MP2MP Tunnels 147 When the PTA specifies one of the MP2MP tunnels (BIDIR-PIM, mLDP 148 MP2MP, BIER), it means the advertising PE will use the MP2MP tunnel 149 for both sending and receiving. While [RFC8317] specifies composite 150 tunnel only as transmitting non-IR + receiving IR, an MP2MP tunnel 151 can also be part of composite tunnel to receive traffic. The rest of 152 the document focuses on BIER, but it equally applies to mLDP MP2MP or 153 BIDIR-PIM. 155 3. Specifications 157 While not previously done so, this document makes it explicit that, 158 an MVPN/EVPN PE1 advertising a non-IR tunnel can also send to another 159 PE2 using IR if PE2 advertises to receive traffic with IR (whether 160 PE2 advertises IR standalone or as part of a composite tunnel), as 161 long as it is known that PE2 will receive from PE1 the same data only 162 via IR. 164 3.1. General MVPN/EVPN Use of Composite Tunnels 166 This document extends the use of composite tunnel to appropriate 167 general MVPN/EVPN scenarios where a PE advertises a composite tunnel 168 in its I-PMSI A-D route to receive traffic on IR tunnel and send 169 traffic on non-IR tunnel. 171 This document also allows an MP2MP tunnel to be part of a composite 172 tunnel so that the advertising PE can use both the MP2MP tunnel and 173 IR to receive traffic. 175 For a regular, non-composite tunnel in the PMSI Tunnel Attribute 176 (PTA) of a PMSI/Leaf A-D route, the PTA includes an "MPLS Label" 177 field between the "Tunnel Type" field and the "Tunnel Identifier" 178 field. The label is for "tunnel aggregation" purpose - traffic on 179 the same tunnel could carry different labels for multiplexing purpose 180 (e.g. for different VPNs/BDs). For an IR tunnel, the label is 181 downstream- assigned; for non-IR tunnels, the label is either 0 (no 182 aggregation) or upstream-assigned, or from a Domain-wide Common Block 183 (DCB) [I-D.ietf-bess-mvpn-evpn-aggregation-label]. 185 +---------------------------------+ 186 | Flags (1 octet) | 187 +---------------------------------+ 188 | Tunnel Type (1 octets) | 189 +---------------------------------+ 190 | MPLS Label (3 octets) | 191 +---------------------------------+ 192 | Tunnel Identifier (variable) | 193 +---------------------------------+ 195 PTA Fields [RF6514] 197 [RFC8317] specifies that the "Tunnel Identifier" field includes a 198 three-octet label before the actual identifier of the non-IR tunnel, 199 though the text/diagram about the roles of the labels is unclear/ 200 confusing. For easier reference this document moves the added label 201 out, so that the "Tunnel Identifier" is the actual identifier of the 202 non-IR tunnel: 204 +-------------------------------------------+ 205 | Flags (1 octet) | 206 +-------------------------------------------+ 207 | Tunnel Type (1 octet) | 208 +-------------------------------------------+ 209 | Non-IR Tunnel Aggregation Label (3 octets)| 210 +-------------------------------------------+ 211 | Ingress Replication MPLS Label (3 octets) | 212 +-------------------------------------------+ 213 | Non-IR Tunnel Identifier (variable) | 214 +-------------------------------------------+ 216 PTA Fields for Composite Tunnel [This Document] 218 An example of composite tunnel is BIER-IR tunnel, where the tunnel 219 type is set to 0x8B, and BIER Tunnel Aggregation Label and BIER 220 Tunnel Identifier are as specified in [I-D.ietf-bier-mvpn]. 222 Section Section 4.1 gives an example application of using BIER-IR 223 tunnel for BIER capable EVPN PEs to send/receive BUM traffic via 224 BIER, and receive BUM traffic from BIER incapable PEs via IR; BIER 225 incapable PEs send BUM traffic using IR; BIER traffic from BIER 226 capable PEs will have the BIER header popped off by a Penultimate Hop 227 before reaching BIER incapable PEs [I-D.ietf-bier-php]. The same can 228 be used for MVPN as well. 230 3.2. EVPN-IP Assisted Replication with BIER-IR Composite Tunnel 232 For the example in Section Section 4.1, instead of having BIER 233 incapable PEs send BUM traffic using IR to every PE, Assisted 234 Replication (AR) [I-D.ietf-bess-evpn-optimized-ir] can be used for a 235 BIER incapable PE to send BUM traffic to a BIER capable Assisted 236 Replication Replicator (AR-R) via IR, who will then relay to other 237 PEs via BIER. 239 The same concept applies to MVPN as well, though AR for MVPN is via 240 Virtual Hub and Spoke (VHS) [RFC7024], similar to AR for EVPN-MPLS 241 [I-D.keyupate-bess-evpn-virtual-hub] 242 ([I-D.ietf-bess-evpn-optimized-ir] is for EVPN-IP). The procedures 243 for those two cases will be specified in separate documents. 245 EVPN-IP AR with BIER-IR composite tunnels follows similar procedures 246 as in [I-D.ietf-bess-evpn-optimized-ir], with the following 247 differences: 249 o The IMET route from a BIER capable AR-Replicator that has the IR- 250 IP address in the Originating PE field encodes BIER tunnel in the 251 PTA, as specified in [EVPN-BIER]. 253 o An AR-Leaf originates an IMET route with BIER-IR tunnel with AR- 254 Leaf flag. If it is BIER capable, it both sends and receives BM 255 traffic via BIER. If it is not BIER capable, it sends BM traffic 256 via IR to the AR-Replicator, who will then relay to other PEs 257 using BIER. 259 o The AR-R does NOT relay traffic that arrive with BIER 260 encapsulation. 262 o Only non-selective mode is supported. 264 The above rules are illustrated in further details in 265 Section Section 4.2. Notice that, composite-tunnel is used because 266 [I-D.ietf-bess-evpn-optimized-ir] requires falling back to IR when 267 the AR-Replicator is not available. 269 4. Use-cases 271 This section describes some Composite Tunnel use-cases. We refer to 272 BIER-IR as the PTA's Tunnel Type with the high-order bit set and BIER 273 type, I.e., Tunnel Type = 0x8B, as per [RFC8317]. In this section, a 274 BIER non-capable PE is assumed to be a PE that does not support BIER 275 tunnel data plane transmission or termination. However, these BIER 276 non-capable PEs support the required control plane extensions to 277 advertise BIER tunnel information in the IMET PTAs. 279 4.1. BIER-IR Composite Tunnels in EVPN Networks 281 BIER-IR composite tunnels may be used in a group of PEs attached to 282 the same EVPN tenant network. This would allow some of those PEs to 283 use BIER P-tunnels where other PEs in the same group may use Ingress 284 Replication (IR). While these BIER-IR composite tunnels can be used 285 in a similar use case as described in [RFC8317], they can also be 286 used along with PHP as a way to introduce BIER in EVPN networks where 287 some of the PEs do not support BIER data plane. 289 Figure 1 illustrates an example of an EVPN BD where the PE1 and PE2 290 support BIER data plane, but PE3/PE4/PE5 do not. The network could 291 still benefit of BIER if the BFRs connected to the receiver PEs (BFR1 292 and BFR2), either directly or through a tunnel, pop the BIER header 293 and send the EVPN payload natively to PE3/PE4/PE5, as described in 294 [I-D.ietf-bier-php]. 296 IMET(BIER-IR) 297 <-------- 298 PE2 IMET(BIER-IR) PE3 299 +-----------+ ----------> +-----------+ 300 | +-------+ | | +-------+ |--> R1 301 | | BD | |<---+ +---------->| | BD | | 302 | +-------+ | | BFR1 | | +-------+ |--> R2 303 +-----------+ | +---+ +-----------+ 304 +---->| | PE4 305 PE1 | +---+ +-----------+ 306 +-----------+ | | | +-------+ | 307 | +-------+ | | +---------->| | BD | |--> R3 308 S1--> | | BD | |----+ | +-------+ | 309 | +-------+ | | +-----------+ 310 +-----------+ | BFR2 PE5 311 | +---+ +-----------+ 312 +---->| |-------->| +-------+ | 313 +---+ | | BD | |--> R4 314 | +-------+ | 315 | | +-----------+ 316 |<---------------->| 317 | BIER | 318 BFIR BFER 319 (PHP) 320 | | 321 |<------------------------------------->| 322 | EVPN | 324 Figure 1 - BIER Composite Tunnels in EVPN 326 In this example: 328 o All the PEs advertise an IMET route containing a BIER-IR composite 329 tunnel in the PTA (PMSI Tunnel Attribute): 331 * The Tunnel Type has a value of 0x8B (BIER-IR composite tunnel). 333 * The BIER Tunnel Identifier (composed Sub-Domain ID, BFR-ID and 334 BFR-Prefix) and Flags are populated as in [EVPN-BIER]. The IR 335 Label is a downstream allocated Label that allows remote PEs to 336 send BUM traffic to the advertising PE using Ingress 337 Replication, as in [RFC8317]. 339 o When PE1/PE2 need to transmit BUM packets, they follow the 340 procedures in [EVPN-BIER]. BUM packets received on PE1/PE2 from 341 other BIER capable PEs will be received with a BIER encapsulation 342 and procedures in [EVPN-BIER] will be followed. PHP nodes pop the 343 BIER header before delivering the EVPN packets to PE3/PE4/PE5. 345 o When PE3/PE4/PE5 need to send BUM packets to each other or to PE1/ 346 PE2, they use Ingress Replication and the IR label that is 347 received from the other PEs as part of the composite tunnel Tunnel 348 Identifier. 350 4.2. Assisted Replication and BIER Composite Tunnels 352 The use case in section Section 4.1 allows the introduction of BIER 353 in EVPN tenant networks where BIER capable and BIER non-capable PEs 354 are attached to the same EVPN tenant network. However, BIER non- 355 capable PEs still send multiple copies of the same BUM packet to 356 reach the other PEs. 358 In overlay networks, the use case can be optimized so that the BIER 359 non-capable PEs send a single copy per packet by using Assisted 360 Replication along with BIER-IR composite tunnels. Figure 2 361 illustrates this use case with an example, where AR-L1/AR-L2/AR-L3 362 and AR-L4 are Assisted Replication Leaf routers [AR] that do not 363 support BIER data plane. AR-R1/AR-R2 are Non-Selective Assisted 364 Replication Replicators [AR] that do support BIER data plane and are 365 connected to other BFRs, such as BFR1 and BFR2. 367 AR-L2 368 +-------+ --> R1 369 +--->| BD | 370 IMET BFR1 | +-------+ --> R2 371 (BIER-IR,AR-Leaf) +---+ 372 ---> +-->| | 373 | +---+ AR-L3 374 AR-L1 AR-R1 | | +-------+ 375 +-------+ +-------+ | +--->| BD | --> R3 376 S1-->| BD |------->| BD |--+ +-------+ 377 +-------+ +-------+ | 378 | 379 <---- AR-R2 | BFR2 AR-L4 380 IMET +-------+ | +---+ +-------+ 381 (AR,AR-R) | BD | +-->| |->| BD | --> R4 382 +-------+ +---+ +-------+ 384 | | 385 |<------------>| 386 | BIER | 387 BFIR BFER 388 (PHP) 389 | | 390 |<------------------------------------->| 391 | EVPN | 393 Figure 2 - BIER-IR Composite Tunnels and AR 395 In this example: 397 o The AR-R PEs issue two IMET routes each: 399 * An IMET route that includes the AR-IP in the Originating PE, 400 Tunnel Type AR, IR label, Flags Type = 01 (AR-Replicator) and L 401 = 0 (no Leaf Information Required). The IR Label is a 402 downstream allocated Label that will be used by the AR-L PEs 403 that transmit BUM traffic to the receiving AR-R for replication 404 to remote AR-L PEs. No change with respect to [AR]. 406 * And an IMET route that includes the IR-IP in the Originating PE 407 field, Tunnel Type and Tunnel Identifier with BIER information, 408 as in [EVPN-BIER]. 410 o Each AR-L PE issues an IMET route with: 412 * The Flags field populated as in [AR] with AR Type set to AR- 413 LEAF. 415 * The Tunnel Type and Tunnel Identifier have composite BIER-IR 416 information, as in Section Section 4.1. The IR Label is a 417 downstream allocated Label that will be used by the remote AR-L 418 PEs when IR is used for unknown unicast traffic. The MPLS 419 Label field in the PTA MAY be zero. 421 When an AR-R receives a BM packet encapsulated in an overlay tunnel, 422 it will do a tunnel destination IP lookup and if the destination IP 423 is the AR-R IR-IP Address, the AR-R will proceed as in [AR]. If the 424 destination IP is the AR-R AR-IP Address, the AR-R MUST forward the 425 packet to the BIER network and any local AC (if any). When creating 426 the BIER header, the AR-R will behave as a BFIR and will include all 427 the remote AR-L and AR-R in the BIER header, excluding the AR-L from 428 which the BM packet was received. 430 If an AR-R receives a BM packet encapsulated in BIER, it will follow 431 the procedures in [EVPN-BIER] as any other BIER PE. It MUST NOT send 432 the BM packets to any overlay tunnels, only to local ACs. 434 In the example of Figure 2, when AR-R1 receives a BM packet from 435 AR-L1 in an overlay tunnel with its AR-IP as tunnel destination 436 address, it will forward the packet encapsulated with a BIER header 437 that includes AR-L2, AR-L3 and AR-L4 as BFERs, but not AR-L1. 439 As in [AR], if the AR-L does not discover any AR-R in the service, it 440 MUST use IR to send BM traffic to the remote AR-L PEs and AR-R PEs 441 with local ACs. If there is one or more AR-Rs (discovered by 442 tracking the received AR-R routes) the AR-L selects a AR-R to send 443 the BM traffic to. The selection rules are described in [AR]. The 444 AR-L encapsulates the BM packets into an overlay tunnel that uses the 445 AR-IP and AR Label advertised by the selected AR-R. In the example 446 of Figure 2, AR-L1 selects AR-R1 as the AR-R. If AR-R1 becomes 447 unavailable, AR-R2 is selected. If no AR-R is available, AR-L1 would 448 use IR to send the BM packets to the remote AR-L PEs. 450 AR-L PEs receive the BUM packets without a BIER header (since it is 451 popped by the PHP node) and with the MPLS Label / VNI imposed by the 452 AR-R (or the source AR-L if there is no AR for the packet). 454 5. Security Considerations 456 This specification does not introduce additional security concerns. 458 6. IANA Considerations 459 7. Acknowledgements 461 8. References 463 8.1. Normative References 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, 467 DOI 10.17487/RFC2119, March 1997, 468 . 470 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 471 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 472 Explicit Replication (BIER)", RFC 8279, 473 DOI 10.17487/RFC8279, November 2017, 474 . 476 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 477 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 478 Support in Ethernet VPN (EVPN) and Provider Backbone 479 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 480 January 2018, . 482 8.2. Informative References 484 [I-D.ietf-bess-evpn-optimized-ir] 485 Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A. 486 Sajassi, "Optimized Ingress Replication solution for 487 EVPN", draft-ietf-bess-evpn-optimized-ir-06 (work in 488 progress), October 2018. 490 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 491 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 492 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 493 ietf-bess-mvpn-evpn-aggregation-label-03 (work in 494 progress), October 2019. 496 [I-D.ietf-bier-evpn] 497 Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, 498 "EVPN BUM Using BIER", draft-ietf-bier-evpn-01 (work in 499 progress), April 2018. 501 [I-D.ietf-bier-mvpn] 502 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 503 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 504 mvpn-11 (work in progress), March 2018. 506 [I-D.ietf-bier-php] 507 Zhang, Z., "BIER Penultimate Hop Popping", draft-ietf- 508 bier-php-03 (work in progress), October 2019. 510 [I-D.keyupate-bess-evpn-virtual-hub] 511 Patel, K., Sajassi, A., Drake, J., Zhang, Z., and W. 512 Henderickx, "Virtual Hub-and-Spoke in BGP EVPNs", draft- 513 keyupate-bess-evpn-virtual-hub-02 (work in progress), 514 September 2019. 516 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 517 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 518 2012, . 520 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 521 Encodings and Procedures for Multicast in MPLS/BGP IP 522 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 523 . 525 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 526 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 527 VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013, 528 . 530 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 531 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 532 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 533 2015, . 535 Authors' Addresses 537 Zhaohui Zhang 538 Juniper Networks 540 EMail: zzhang@juniper.net 542 Jorge Rabadan (editor) 543 Nokia 545 EMail: jorge.rabadan@nokia.com 547 Ali Sajassi 548 Cisco Systems 550 EMail: sajassi@cisco.com