idnits 2.17.1 draft-ietf-bess-evpn-vpls-seamless-integ-04.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 25, 2018) is 2192 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup A. Sajassi (Editor) 3 INTERNET-DRAFT S. Salam 4 Intended Status: Standard Track Cisco 5 N. Del Regno 6 Verizon 7 J. Rabadan 8 Nokia 10 Expires: October 25, 2018 April 25, 2018 12 (PBB-)EVPN Seamless Integration with (PBB-)VPLS 13 draft-ietf-bess-evpn-vpls-seamless-integ-04 15 Abstract 17 This draft specifies procedures for backward compatibility of the 18 (PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for 19 seamless integration of the two technologies in the same MPLS/IP 20 network on a per-VPN-instance basis. Implementation of this draft 21 enables service providers to introduce (PBB-)EVPN PEs in their brown- 22 field deployments of (PBB-)VPLS networks. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2018 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 (http://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 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 63 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 64 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 6 66 3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7 67 3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7 68 3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 9 70 3.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 9 71 3.4.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 10 72 4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 10 73 4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 10 74 4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 10 75 4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 11 77 4.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 11 78 4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 12 79 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 80 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 81 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 7.1 Normative References . . . . . . . . . . . . . . . . . . . 12 83 7.2 Informative References . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1 Introduction 88 Virtual Private LAN Service (VPLS) and Provider Backbone Bridging 89 VPLS (PBB-VPLS) are widely-deployed Layer-2 VPN (L2VPN) technologies. 90 Many Service Providers (SPs) who are looking at adopting Ethernet VPN 91 (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) want to 92 preserve their investment in the VPLS and PBB-VPLS networks. Hence, 93 they require procedures by which EVPN and PBB-EVPN technology can be 94 introduced into their brown-field VPLS and PBB-VPLS networks without 95 requiring any upgrades (software or hardware) to these networks. This 96 document specifies procedures for the seamless integration of the two 97 technologies in the same MPLS/IP network. Throughout this document, 98 we use the term (PBB-)EVPN to correspond to both EVPN and PBB-EVPN 99 and we use the term (PBB-)VPLS to correspond to both VPLS and PBB- 100 VPLS. 102 VPLS PE 103 +---+ 104 |PE1| 105 +---+ 106 / 107 EVPN/VPLS PE +---------------+ EVPN/VPLS PE 108 +---+ | | +---+ 109 |PE4|----| MPLS/IP |---|PE5| 110 +---+ | Core | +---+ 111 | | 112 +---------------+ 113 / \ 114 +---+ +---+ 115 |PE2| |PE3| 116 +---+ +---+ 117 VPLS PE VPLS PE 119 Figure 1: Seamless Integration of (PBB-)EVPN PEs & (PBB-)VPLS 121 Section 2 provides the details of the requirements. Section 3 122 specifies procedures for the seamless integration of VPLS and EVPN 123 networks. And section 4 specifies procedures for the seamless 124 integration of PBB-VPLS and PBB-EVPN networks. 126 It should be noted that the scenarios for PBB-VPLS integration with 127 EVPN and VPLS integration with PBB-EVPN are not covered in this 128 document because there haven't been any requirements from service 129 providers for these scenarios. The reason for that is that 130 deployments which employ PBB-VPLS typically require PBB encapsulation 131 for various reasons. Hence, it is expected that for those deployments 132 the evolution path would be from PBB-VPLS towards PBB-EVPN. 133 Furthermore, the evolution path from VPLS is expected to be towards 134 EVPN. 136 The seamless integration solution described in this document has the 137 following attributes: 139 - When ingress replication is used for multi-destination traffic 140 delivery, the solution reduces the scope of [MMRP] (which is a soft- 141 state protocol) to only that of existing VPLS PEs, and uses the more 142 robust BGP-based mechanism for multicast pruning among new EVPN PEs. 144 - It is completely backward compatible. 146 - New PEs can leverage the extensive multi-homing mechanisms and 147 provisioning simplifications of (PBB-)EVPN: 148 a. Auto-sensing of MHN / MHD 149 b. Auto-discovery of redundancy group 150 c. Auto-provisioning in DF election and VLAN carving 152 1.1. Specification of Requirements 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 1.2. Terms and Abbreviations 162 B-MAC: Backbone MAC 164 B-VID: Backbone VLAN ID 166 Broadcast Domain: In a bridged network, the broadcast domain 167 corresponds to a Virtual LAN (VLAN), where a VLAN is typically 168 represented by a single VLAN ID (VID) but can be represented by 169 several VIDs where Shared VLAN Learning (SVL) is used per 170 [IEEE.802.1ah]. 172 Bridge Table: An instantiation of a broadcast domain on a MAC-VRF 174 RIB: Routing Information Base - An instantiation of a routing table 175 on a MAC-VRF 177 FIB: Forwarding Information Base - An instantiation of a forwarding 178 table on a MAC-VRF 180 CE: A Customer Edge device, e.g., a host, router, or switch. 182 EVI: An EVPN Instance spanning the Provider Edge (PE) devices 183 participating in that EVPN. 185 MAC-VRF: A Virtual Routing and Forwarding table for Media Access 186 Control (MAC) addresses on an EVPN PE. 188 MAC address: Media Access Control address 190 ES: When a customer site (device or network) is connected to one or 191 more PEs via a set of Ethernet links, then that set of links is 192 referred to as an "Ethernet Segment". 194 ESI: An Ethernet Segment Identifier is a unique non-zero identifier 195 that identifies an ES 197 Ethernet Tag: An Ethernet Tag identifies a particular broadcast 198 domain, e.g., a VLAN. An EVPN instance consists of one or more 199 broadcast domains 201 MHD: Multi-Homed Device 203 MHN: Multi-Homed Network 205 P2MP: Point-to-Multipoint 207 PBB: Provider Backbone Bridge 209 PE: Provider Edge device 211 VSI: Virtual Switch Instance 213 VPLS: Virtual Private LAN Service 215 Single-Active Redundancy Mode: When only a single PE, among all the 216 PEs attached to an Ethernet segment, is allowed to forward traffic 217 to/from that Ethernet segment for a given VLAN, then the Ethernet 218 segment is defined to be operating in Single-Active redundancy mode. 220 All-Active Redundancy Mode: When all PEs attached to an Ethernet 221 segment are allowed to forward known unicast traffic to/from that 222 Ethernet segment for a given VLAN, then the Ethernet segment is 223 defined to be operating in All-Active redundancy mode. 225 (PBB-)EVPN: refers to both, PBB-EVPN and EVPN. This document uses 226 this abbreviation when a given description applies to both 227 technologies. 229 (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. As for EVPN, this 230 abbreviation is used when the text applies to both technologies. 232 VPLS A-D: refers to Virtual Private LAN Services with BGP-based Auto 233 Discovery as in [RFC6074]. 235 PW: Pseudowire. 237 2. Requirements 239 Following are the key requirements for backward compatibility between 240 (PBB-)EVPN and (PBB-)VPLS: 242 1. The solution MUST allow for staged migration towards (PBB-)EVPN on 243 a site-by-site basis per VPN instance - e.g., new EVPN sites to be 244 provisioned on (PBB-)EVPN Provider Edge devices (PEs). 246 2. The solution MUST require no changes to existing VPLS or PBB-VPLS 247 PEs, not even a software upgrade. 249 3. The solution MUST allow for the coexistence of PEs running (PBB- 250 )EVPN and (PBB-)VPLS for the same VPN instance and single-homed 251 segments. 253 4. The solution MUST support single-active redundancy of multi-homed 254 networks and multi-homed devices for (PBB-)EVPN PEs. 256 5. In case of single-active redundancy, the participant VPN instances 257 MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as the 258 MHD or MHN is connected to (PBB-)EVPN PEs. In case of an ES link 259 failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to the EVPN 260 peers OR MAC advertisement with MAC Mobility extended community for 261 PBB-EVPN AND follow existing VPLS MAC Flush procedures with the VPLS 262 peers. 264 6. The support of All-Active redundancy mode across both (PBB-)EVPN 265 PEs and (PBB-)VPLS PEs is outside the scope of this document. 267 These requirements collectively allow for the seamless insertion of 268 the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments. 270 3 VPLS Integration with EVPN 272 In order to support seamless integration with VPLS PEs, this document 273 requires that VPLS PEs support VPLS A-D per [RFC6074] and EVPN PEs 274 support both BGP EVPN routes per [RFC7432] and VPLS A-D per 276 [RFC6074]. All the logic for seamless integration SHALL reside on the 277 EVPN PEs. If a VPLS instance is setup without the use of VPLS A-D, it 278 is still possible (but cumbersome) for EVPN PEs to integrate into 279 that VPLS instance by manually configuring Pseudowires (PWs) to all 280 the VPLS PEs in that instance (i.e., the integration is no longer 281 seamless). 283 3.1 Capability Discovery 285 The EVPN PEs MUST advertise both the BGP VPLS Auto-Discovery (A-D) 286 route as well as the BGP EVPN Inclusive Multicast Ethernet Tag (IMET) 287 route for a given VPN instance. The VPLS PEs only advertise the BGP 288 VPLS A-D route, per the procedures specified in [RFC4761], [RFC4762] 289 and [RFC6074]. The operator may decide to use the same Route Target 290 (RT) to identify a VPN on both EVPN and VPLS networks. In this case, 291 when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the 292 basis that it belongs to an unknown SAFI. However, the operator may 293 choose to use two RTs - one to identify the VPN on VPLS network and 294 another for EVPN network and employ RT-constrained [RFC4684] in order 295 to prevent BGP EVPN routes from reaching the VPLS PEs. 297 When an EVPN PE receives both a VPLS A-D route as well as an EVPN 298 IMET route from a given remote PE for the same VPN instance, it MUST 299 give preference to the EVPN route for the purpose of discovery. This 300 ensures that, at the end of the route exchanges, all EVPN capable PEs 301 discover other EVPN capable PEs in addition to the VPLS-only PEs for 302 that VPN instance. Furthermore, all the VPLS-only PEs will discover 303 the EVPN PEs as if they were standard VPLS PEs. In other words, when 304 the discovery phase is complete, the EVPN PEs will have discovered 305 all the PEs in the VPN instance along with their associated 306 capability (EVPN or VPLS-only), whereas the VPLS PEs will have 307 discovered all the PEs in the VPN instance as if they were all VPLS- 308 only PEs. 310 3.2 Forwarding Setup and Unicast Operation 312 The procedures for forwarding state setup and unicast operation on 313 the VPLS PE are per [RFC8077], [RFC4761], [RFC4762]. 315 The procedures for forwarding state setup and unicast operation on 316 the EVPN PE are as follows: 318 - The EVPN PE MUST establish a PW to a remote PE from which it has 319 received only a VPLS A-D route for the corresponding VPN instance, 320 and MUST set up the label stack corresponding to the PW FEC. For 321 seamless integration between EVPN and VPLS PEs, the PW that is setup 322 between a pair of VPLS and EVPN PEs is between the VSI of the VPLS PE 323 and the MAC-VRF of the EVPN PE. 325 - The EVPN PE must set up the label stack corresponding to the MP2P 326 VPN unicast FEC to any remote PE that has advertised EVPN IMET route. 328 - If an EVPN PE receives a VPLS A-D route followed by an EVPN IMET 329 route from the same PE and a PW is already setup to that PE, then the 330 EVPN MUST bring that PW operationally down. 332 - If an EVPN PE receives an EVPN IMET route followed by a VPLS A-D 333 route from the same PE, then the EVPN PE will setup the PW but MUST 334 keep it operationally down. 336 - In case VPLS AD is not used in some VPLS PEs, the EVPN PEs need to 337 be provisioned manually with PWs to those remote VPLS PEs for each 338 VPN instance. In that case, if an EVPN PE receives an EVPN IMET route 339 from a PE to which a PW exists, the PW will be brought operationally 340 down. 342 When the EVPN PE receives traffic over the VPLS PWs, it learns the 343 associated C-MAC addresses in the data-plane. The C-MAC addresses 344 learned over these PWs MUST be injected into the bridge table of the 345 associated MAC-VRF on that EVPN PE. The learned C-MAC addresses MAY 346 also be injected into the RIB/FIB tables of the associated MAC-VRF on 347 that EVPN PE. For seamless integration between EVPN and VPLS PEs, 348 since these PWs belong to the same split-horizon group as the MP2P 349 EVPN service tunnels, then the C-MAC addresses learned and associated 350 to the PWs will NOT be advertised in the control plane to any remote 351 EVPN PEs. This is because every EVPN PE can send and receive traffic 352 directly to/from every VPLS PE belonging to the same VPN instance. 354 The C-MAC addresses learned over local Attachment Circuits (ACs) by 355 an EVPN PE are learned in data-plane. For EVPN PEs, these C-MAC 356 addresses MUST be injected into the corresponding MAC-VRF and 357 advertised in the control-plane using BGP EVPN routes. Furthermore, 358 the C-MAC addresses learned in the control plane via the BGP EVPN 359 routes sent by remote EVPN PEs, are injected into the corresponding 360 MAC-VRF table. 362 3.3 MAC Mobility 364 In EVPN, host addresses (C-MAC addresses) can move around among EVPN 365 PEs or even between EVPN and VPLS PEs. 367 When a C-MAC address moves from an EVPN PE to a VPLS PE, then as soon 368 as Broadcast/Unknown-unicast/Multicast (BUM) traffic is initiated 369 from that MAC address, it is flooded to all other PEs (both VPLS and 370 EVPN PEs) and the receiving PEs update their MAC tables (VSI or MAC- 371 VRF). The EVPN PEs do not advertise the C-MAC addresses learned over 372 the PW to each other because every EVPN PE learns them directly over 373 its associated PW to that VPLS PE. If only known-unicast traffic is 374 initiated from the moved C-MAC address toward a known C-MAC, then 375 this can result in black-holing of traffic destined to the C-MAC that 376 has moved until there is a BUM traffic originated with the moved C- 377 MAC address as the source MAC address (e.g., as a result of MAC age- 378 out timer expires). Note that this is behavior typical of VPLS PEs. 380 When a C-MAC address moves from a VPLS PE to an EVPN PE, then as soon 381 as BUM or known-unicast traffic is initiated from that C-MAC address, 382 the C-MAC is learned and advertised in BGP to other EVPN PEs and MAC 383 mobility procedure is exercised among EVPN PEs. For BUM traffic, both 384 EVPN and VPLS PEs learn the new location of the moved C-MAC address; 385 however, if there is only known-unicast traffic, then only EVPN PEs 386 learn the new location of the C-MAC that has moved but not VPLS PEs. 387 This can result in black-holing of traffic sent from VPLS PEs 388 destined to the C-MAC that has moved until there is a BUM traffic 389 originated with the moved C-MAC address as the source MAC address 390 (e.g., as a result of MAC age-out timer expires). Note that this is 391 behavior typical of VPLS PEs. 393 3.4 Multicast Operation 395 3.4.1 Ingress Replication 397 The procedures for multicast operation on the VPLS PE, using ingress 398 replication, are per [RFC4761], [RFC4762], and [RFC7080]. 400 The procedures for multicast operation on the EVPN PE, for ingress 401 replication, are as follows: 403 - The EVPN PE builds a replication sub-list to all the remote EVPN 404 PEs per EVPN instance as the result of the exchange of the EVPN IMET 405 routes per [RFC7432]. This will be referred to as sub-list A. It 406 comprises MP2P service tunnels used for delivering EVPN BUM traffic 407 [RFC7432]. 409 - The EVPN PE builds a replication sub-list per VPLS instance to all 410 the remote VPLS PEs. This will be referred to as sub-list B. It 411 comprises PWs from the EVPN PE in question to all the remote VPLS PEs 412 in the same VPLS instance. 414 The replication list, maintained per VPN instance, on a given EVPN PE 415 will be the union of sub-list A and sub-list B. Note that the PE must 416 enable split-horizon over all the entries in the replication list, 417 across both PWs and MP2P service tunnels. 419 3.4.2 P2MP Tunnel 421 The procedures for multicast operation on the EVPN PEs using P2MP 422 tunnels are outside of the scope of this document. 424 4 PBB-VPLS Integration with PBB-EVPN 426 In order to support seamless integration between PBB-VPLS and PBB- 427 EVPN PEs, this document requires that PBB-VPLS PEs support VPLS A-D 428 per [RFC6074] and PBB-EVPN PEs support both BGP EVPN routes per 429 [RFC7432] and VPLS A-D per [RFC6074]. All the logic for this seamless 430 integration SHALL reside on the PBB-EVPN PEs. 432 4.1 Capability Discovery 434 The procedures for capability discovery are per Section 3.1 above. 436 4.2 Forwarding Setup and Unicast Operation 438 The procedures for forwarding state setup and unicast operation on 439 the PBB-VPLS PE are per [RFC8077] and [RFC7080]. 441 The procedures for forwarding state setup and unicast operation on 442 the PBB-EVPN PE are similar to that of section 3.2 except for the 443 following: 445 - For seamless integration between EVPN and VPLS PEs, the PW that is 446 setup between a pair of PBB-VPLS and PBB-EVPN PEs, is between B- 447 components of PBB-EVPN PE and PBB-VPLS PE per section 4 of 448 [RFC7041]. 450 - When the PBB-EVPN PE receives traffic over the PBB-VPLS PWs, it 451 learns the associated B-MAC addresses in the data-plane. The B-MAC 452 addresses learned over these PWs MUST be injected into the bridge 453 table of the associated MAC-VRF on that PBB-EVPN PE. The learned B- 454 MAC addresses MAY also be injected into the RIB/FIB tables of the 455 associated the MAC-VRF on that BPP-EVPN PE. For seamless integration 456 between PBB-EVPN and PBB-VPLS PEs, since these PWs belongs to the 457 same split-horizon group as the MP2P EVPN service tunnels, then the 458 B-MAC addresses learned and associated to the PWs will NOT be 459 advertised in the control plane to any remote PBB-EVPN PEs. This is 460 because every PBB-EVPN PE can send and receive traffic directly 461 to/from every PBB-VPLS PE belonging to the same VPN instance. 463 - The C-MAC addresses learned over local Attachment Circuits (ACs) by 464 an PBB-EVPN PE are learned in data-plane. For PBB-EVPN PEs, these C- 465 MAC addresses are learned in I-component of PBB-EVPN PEs and they are 466 not advertised in the control-plane per [RFC7623]. 468 - The B-MAC addresses learned in the control plane via the BGP EVPN 469 routes sent by remote PBB-EVPN PEs, are injected into the 470 corresponding MAC-VRF table. 472 4.3 MAC Mobility 474 In PBB-EVPN, a given B-MAC address can be learnt either over the BGP 475 control-plane from a remote PBB-EVPN PE, or in the data-plane over a 476 PW from a remote PBB-VPLS PE. There is no mobility associated with B- 477 MAC addresses in this context. Hence, when the same B-MAC address 478 shows up behind both a remote PBB-VPLS PE as well as a PBB-EVPN PE, 479 the local PE can deduce that it is an anomaly and notify the 480 operator. 482 4.4 Multicast Operation 484 4.4.1 Ingress Replication 486 The procedures for multicast operation on the PBB-VPLS PE, using 487 ingress replication, are per [RFC7041] and [RFC7080]. 489 The procedures for multicast operation on the PBB-EVPN PE, for 490 ingress replication, are as follows: 492 - The PBB-EVPN PE builds a replication sub-list per I-SID to all the 493 remote PBB-EVPN PEs in a given VPN instance as a result of the 494 exchange of the EVPN IMET routes, as described in [RFC7623]. This 495 will be referred to as sub-list A. It comprises MP2P service tunnels 496 used for delivering PBB-EVPN BUM traffic. 498 - The PBB-EVPN PE builds a replication sub-list per VPN instance to 499 all the remote PBB-VPLS PEs. This will be referred to as sub-list B. 500 It comprises PWs from the PBB-EVPN PE in question to all the remote 501 PBB-VPLS PEs in the same VPN instance. 503 - The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis, 504 if [MMRP] is run over the PBB-VPLS network. This will be referred to 505 as sub-list C. This list comprises a pruned set of the PWs in the 506 sub-list B. 508 The replication list maintained per I-SID on a given PBB-EVPN PE will 509 be the union of sub-list A and sub-list B if [MMRP] is NOT used, and 510 the union of sub-list A and sub-list C if [MMRP] is used. Note that 511 the PE must enable split-horizon over all the entries in the 512 replication list, across both pseudowires and MP2P service tunnels. 514 4.4.2 P2MP Tunnel - Inclusive Tree 516 The procedures for multicast operation on the PBB-EVPN PEs using P2MP 517 tunnels are outside of the scope of this document. 519 5 Security Considerations 521 All the security considerations in [RFC4761], [RFC4762], [RFC7080], 522 [RFC7432], and [RFC7623] apply directly to this document because this 523 document leverages the control plane and the data plane procedures 524 described in these RFCs. 526 This document does not introduce any new security considerations 527 beyond that of the above RFCs because the advertisements and 528 processing of MAC addresses in BGP follow that of [RFC7432] and 529 processing of MAC addresses learned over PWs follow that of 530 [RFC4761], [RFC4762], and [RFC7080]. 532 6 IANA Considerations 534 This document has no actions for IANA. 536 7 References 538 7.1 Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, DOI 542 10.17487/RFC2119, March . 545 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 546 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 547 May 2017, . 549 [RFC8077] Martini, et al., "Pseudowire Setup and Maintenance using 550 the Label Distribution Protocol", RFC 8077, February 2017. 552 [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, 553 February, 2015. 555 [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with 556 Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015. 558 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private 559 LAN Service (VPLS) Using BGP for Auto-Discovery and 560 Signaling", RFC 4761, January 2007, . 563 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 564 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 565 Signaling", RFC 4762, January 2007, . 568 [RFC6074] Rosen et al., "Provisioning, Auto-Discovery, and Signaling 569 in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, 570 January 2011. 572 7.2 Informative References 574 [MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area 575 networks - Media Access Control (MAC) Bridges and Virtual Bridged 576 Local Area Networks", IEEE Std 802.1Q, 2013. 578 [RFC7041] Balus et al., "Extensions to VPLS PE model for Provider 579 Backbone Bridging", RFC 7041, November 2013. 581 [RFC7080] Sajassi et al., "VPLS Interoperability with Provider 582 Backbone Bridges", RFC 7080, December, 2013. 584 [IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area 585 networks - Media Access Control (MAC) Bridges and Virtual Bridged 586 Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI 587 10.1109/IEEESTD.2011.6009146. 589 [RFC4684] Marques et al., "Constrained Route Distribution for Border 590 Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet 591 Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November, 592 2006. 594 Authors' Addresses 596 Ali Sajassi 597 Cisco 598 Email: sajassi@cisco.com 599 Samer Salam 600 Cisco 601 Email: ssalam@cisco.com 603 Nick Del Regno 604 Verizon 605 Email: nick.delregno@verizon.com 607 Jorge Rabadan 608 Nokia 609 Email: jorge.rabadan@nokia.com