idnits 2.17.1 draft-ietf-bess-evpn-vpls-seamless-integ-05.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 27, 2018) is 1948 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: May 27, 2019 November 27, 2018 12 (PBB-)EVPN Seamless Integration with (PBB-)VPLS 13 draft-ietf-bess-evpn-vpls-seamless-integ-05 15 Abstract 17 This draft specifies procedures for backward compatibility of 18 Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB- 19 EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider 20 Backbone Bridge VPLS (PBB-VPLS) solutions (PBB-)VPLS. It also 21 provides mechanisms for seamless integration of these two 22 technologies in the same MPLS/IP network on a per-VPN-instance basis. 23 Implementation of this draft enables service providers to introduce 24 (PBB-)EVPN PEs in their brown-field deployments of (PBB-)VPLS 25 networks. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 67 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 68 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 6 70 3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7 71 3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7 72 3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 9 74 3.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 9 75 3.4.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 9 76 4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 10 77 4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 10 78 4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 10 79 4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 11 81 4.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 11 82 4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 12 83 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 84 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 85 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7.1 Normative References . . . . . . . . . . . . . . . . . . . 12 87 7.2 Informative References . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 90 1 Introduction 92 Virtual Private LAN Service (VPLS) and Provider Backbone Bridging 93 VPLS (PBB-VPLS) are widely-deployed Layer-2 VPN (L2VPN) technologies. 94 Many Service Providers (SPs) who are looking at adopting Ethernet VPN 95 (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) want to 96 preserve their investment in the VPLS and PBB-VPLS networks. Hence, 97 they require procedures by which EVPN and PBB-EVPN technology can be 98 introduced into their brown-field VPLS and PBB-VPLS networks without 99 requiring any upgrades (software or hardware) to these networks. This 100 document specifies procedures for the seamless integration of the two 101 technologies in the same MPLS/IP network. Throughout this document, 102 we use the term (PBB-)EVPN to correspond to both EVPN and PBB-EVPN 103 and we use the term (PBB-)VPLS to correspond to both VPLS and PBB- 104 VPLS. 106 VPLS PE 107 +---+ 108 |PE1| 109 +---+ 110 / 111 EVPN/VPLS PE +---------------+ EVPN/VPLS PE 112 +---+ | | +---+ 113 |PE4|----| MPLS/IP |---|PE5| 114 +---+ | Core | +---+ 115 | | 116 +---------------+ 117 / \ 118 +---+ +---+ 119 |PE2| |PE3| 120 +---+ +---+ 121 VPLS PE VPLS PE 123 Figure 1: Seamless Integration of (PBB-)EVPN & (PBB-)VPLS 125 Section 2 provides the details of the requirements. Section 3 126 specifies procedures for the seamless integration of VPLS and EVPN 127 networks. And section 4 specifies procedures for the seamless 128 integration of PBB-VPLS and PBB-EVPN networks. 130 It should be noted that the scenarios for PBB-VPLS integration with 131 EVPN and VPLS integration with PBB-EVPN are not covered in this 132 document because there haven't been any requirements from service 133 providers for these scenarios. The reason for that is that 134 deployments which employ PBB-VPLS typically require PBB encapsulation 135 for various reasons. Hence, it is expected that for those deployments 136 the evolution path would be from PBB-VPLS towards PBB-EVPN. 137 Furthermore, the evolution path from VPLS is expected to be towards 138 EVPN. 140 The seamless integration solution described in this document has the 141 following attributes: 143 - When ingress replication is used for multi-destination traffic 144 delivery, the solution reduces the scope of [MMRP] (which is a soft- 145 state protocol) to only that of existing VPLS PEs, and uses the more 146 robust BGP-based mechanism for multicast pruning among new EVPN PEs. 148 - It is completely backward compatible. 150 - New PEs can leverage the extensive multi-homing mechanisms and 151 provisioning simplifications of (PBB-)EVPN: 152 a. Auto-sensing of MHN / MHD 153 b. Auto-discovery of redundancy group 154 c. Auto-provisioning of Designated Forwarder election and 155 VLAN carving 157 1.1. Specification of Requirements 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in BCP 162 14 [RFC2119] [RFC8174] when, and only when, they appear in all 163 capitals, as shown here. 165 1.2. Terms and Abbreviations 167 Broadcast Domain: In a bridged network, the broadcast domain 168 corresponds to a Virtual LAN (VLAN), where a VLAN is typically 169 represented by a single VLAN ID (VID) but can be represented by 170 several VIDs where Shared VLAN Learning (SVL) is used per 171 [IEEE.802.1ah]. 173 Bridge Table: An instantiation of a broadcast domain on a MAC-VRF 175 RIB: Routing Information Base - An instantiation of a routing table 176 on a MAC-VRF 178 FIB: Forwarding Information Base - An instantiation of a forwarding 179 table on a MAC-VRF 181 CE: A Customer Edge device, e.g., a host, router, or switch. 183 MAC-VRF: A Virtual Routing and Forwarding table for Media Access 184 Control (MAC) addresses on an EVPN PE. 186 MAC address: Media Access Control address 188 C-MAC address: Customer MAC address - e.g., host or CE's MAC address 190 B-MAC address: Backbone MAC address - e.g., PE's MAC address 192 Ethernet segment (ES): Refers to the set of Ethernet links that 193 connects a customer site (device or network) to one or more PEs. 195 Ethernet Tag: An Ethernet Tag identifies a particular broadcast 196 domain, e.g., a VLAN. An EVPN instance consists of one or more 197 broadcast domains 199 MHD: Multi-Homed Device 201 MHN: Multi-Homed Network 203 P2MP: Point-to-Multipoint 205 PBB: Provider Backbone Bridge 207 PE: Provider Edge device 209 VSI: Virtual Switch Instance 211 VPLS: Virtual Private LAN Service 213 Single-Active Redundancy Mode: When only a single PE, among all the 214 PEs attached to an Ethernet segment, is allowed to forward traffic 215 to/from that Ethernet segment for a given VLAN, then the Ethernet 216 segment is defined to be operating in Single-Active redundancy mode. 218 All-Active Redundancy Mode: When all PEs attached to an Ethernet 219 segment are allowed to forward known unicast traffic to/from that 220 Ethernet segment for a given VLAN, then the Ethernet segment is 221 defined to be operating in All-Active redundancy mode. 223 (PBB-)EVPN: refers to both, PBB-EVPN and EVPN. This document uses 224 this abbreviation when a given description applies to both 225 technologies. 227 (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. As for EVPN, this 228 abbreviation is used when the text applies to both technologies. 230 VPLS A-D: refers to Virtual Private LAN Services with BGP-based Auto 231 Discovery as in [RFC6074]. 233 PW: Pseudowire 234 I-SID: Ethernet Services Instance Identifier 236 2. Requirements 238 Following are the key requirements for backward compatibility between 239 (PBB-)EVPN and (PBB-)VPLS: 241 1. The solution MUST allow for staged migration towards (PBB-)EVPN on 242 a site-by-site basis per VPN instance - e.g., new EVPN sites to be 243 provisioned on (PBB-)EVPN Provider Edge devices (PEs). 245 2. The solution MUST require no changes to existing VPLS or PBB-VPLS 246 PEs, not even a software upgrade. 248 3. The solution MUST allow for the coexistence of PEs running (PBB- 249 )EVPN and (PBB-)VPLS for the same VPN instance and single-homed 250 segments. 252 4. The solution MUST support single-active redundancy of multi-homed 253 networks and multi-homed devices for (PBB-)EVPN PEs. 255 5. In case of single-active redundancy, the participant VPN instances 256 MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as the 257 MHD or MHN is connected to (PBB-)EVPN PEs. In case of an ES link 258 failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to the EVPN 259 peers OR MAC advertisement with MAC Mobility extended community for 260 PBB-EVPN AND follow existing VPLS MAC Flush procedures with the VPLS 261 peers. 263 6. The support of All-Active redundancy mode across both (PBB-)EVPN 264 PEs and (PBB-)VPLS PEs is outside the scope of this document. 266 These requirements collectively allow for the seamless insertion of 267 the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments. 269 3 VPLS Integration with EVPN 271 In order to support seamless integration with VPLS PEs, this document 272 requires that VPLS PEs support VPLS A-D per [RFC6074] and EVPN PEs 273 support both BGP EVPN routes per [RFC7432] and VPLS A-D per 274 [RFC6074]. All the logic for seamless integration shall reside on the 275 EVPN PEs. If a VPLS instance is setup without the use of VPLS A-D, it 276 is still possible (but cumbersome) for EVPN PEs to integrate into 277 that VPLS instance by manually configuring Pseudowires (PWs) to all 278 the VPLS PEs in that instance (i.e., the integration is no longer 279 seamless). 281 3.1 Capability Discovery 283 The EVPN PEs MUST advertise both the BGP VPLS Auto-Discovery (A-D) 284 route as well as the BGP EVPN Inclusive Multicast Ethernet Tag (IMET) 285 route for a given VPN instance. The VPLS PEs only advertise the BGP 286 VPLS A-D route, per the procedures specified in [RFC4761], [RFC4762] 287 and [RFC6074]. The operator may decide to use the same Route Target 288 (RT) to identify a VPN on both EVPN and VPLS networks. In this case, 289 when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the 290 basis that it belongs to an unknown SAFI. However, the operator may 291 choose to use two RTs - one to identify the VPN on VPLS network and 292 another for EVPN network and employ RT-constrained [RFC4684] in order 293 to prevent BGP EVPN routes from reaching the VPLS PEs. 295 When an EVPN PE receives both a VPLS A-D route as well as an EVPN 296 IMET route from a given remote PE for the same VPN instance, it MUST 297 give preference to the EVPN route for the purpose of discovery. This 298 ensures that, at the end of the route exchanges, all EVPN capable PEs 299 discover other EVPN capable PEs in addition to the VPLS-only PEs for 300 that VPN instance. Furthermore, all the VPLS-only PEs will discover 301 the EVPN PEs as if they were standard VPLS PEs. In other words, when 302 the discovery phase is complete, the EVPN PEs will have discovered 303 all the PEs in the VPN instance along with their associated 304 capability (EVPN or VPLS-only), whereas the VPLS PEs will have 305 discovered all the PEs in the VPN instance as if they were all VPLS- 306 only PEs. 308 3.2 Forwarding Setup and Unicast Operation 310 The procedures for forwarding state setup and unicast operation on 311 the VPLS PE are per [RFC8077], [RFC4761], [RFC4762]. 313 The procedures for forwarding state setup and unicast operation on 314 the EVPN PE are as follows: 316 - The EVPN PE MUST establish a PW to each remote PE from which it has 317 received only a VPLS A-D route for the corresponding VPN instance, 318 and MUST set up the label stack corresponding to the PW FEC. For 319 seamless integration between EVPN and VPLS PEs, the PW that is setup 320 between a pair of VPLS and EVPN PEs is between the VSI of the VPLS PE 321 and the MAC-VRF of the EVPN PE. 323 - The EVPN PE must set up the label stack corresponding to the MP2P 324 VPN unicast FEC to any remote PE that has advertised EVPN IMET route. 326 - If an EVPN PE receives a VPLS A-D route from a given PE, it sets up 327 a PW to that PE. If it then receives an EVPN IMET route from the same 328 PE, then the EVPN PE MUST bring that PW operationally down. 330 - If an EVPN PE receives an EVPN IMET route followed by a VPLS A-D 331 route from the same PE, then the EVPN PE will setup the PW but MUST 332 keep it operationally down. 334 - In case VPLS AD is not used in some VPLS PEs, the EVPN PEs need to 335 be provisioned manually with PWs to those remote VPLS PEs for each 336 VPN instance. In that case, if an EVPN PE receives an EVPN IMET route 337 from a PE to which a PW exists, the EVPN PE MUST bring the PW 338 operationally down. 340 When the EVPN PE receives traffic over the VPLS PWs, it learns the 341 associated C-MAC addresses in the data-plane. The C-MAC addresses 342 learned over these PWs MUST be injected into the bridge table of the 343 associated MAC-VRF on that EVPN PE. The learned C-MAC addresses MAY 344 also be injected into the RIB/FIB tables of the associated MAC-VRF on 345 that EVPN PE. For seamless integration between EVPN and VPLS PEs, 346 since these PWs belong to the same split-horizon group as the MP2P 347 EVPN service tunnels, then the C-MAC addresses learned and associated 348 to the PWs MUST NOT be advertised in the control plane to any remote 349 EVPN PEs. This is because every EVPN PE can send and receive traffic 350 directly to/from every VPLS PE belonging to the same VPN instance. 352 The C-MAC addresses learned over local Attachment Circuits (ACs) by 353 an EVPN PE are learned in data-plane. For EVPN PEs, these C-MAC 354 addresses MUST be injected into the corresponding MAC-VRF and 355 advertised in the control-plane using BGP EVPN routes. Furthermore, 356 the C-MAC addresses learned in the control plane via the BGP EVPN 357 routes sent by remote EVPN PEs, are injected into the corresponding 358 MAC-VRF table. 360 3.3 MAC Mobility 362 In EVPN, host addresses (C-MAC addresses) can move around among EVPN 363 PEs or even between EVPN and VPLS PEs. 365 When a C-MAC address moves from an EVPN PE to a VPLS PE, then as soon 366 as Broadcast/Unknown-unicast/Multicast (BUM) traffic is initiated 367 from that MAC address, it is flooded to all other PEs (both VPLS and 368 EVPN PEs) and the receiving PEs update their MAC tables (VSI or MAC- 369 VRF). The EVPN PEs do not advertise the C-MAC addresses learned over 370 the PW to each other because every EVPN PE learns them directly over 371 its associated PW to that VPLS PE. If only known-unicast traffic is 372 initiated from the moved C-MAC address toward a known C-MAC, then 373 this can result in black-holing of traffic destined to the C-MAC that 374 has moved until there is a BUM traffic originated with the moved C- 375 MAC address as the source MAC address (e.g., as a result of MAC age- 376 out timer expires). Note that this is behavior typical of VPLS PEs. 378 When a C-MAC address moves from a VPLS PE to an EVPN PE, then as soon 379 as BUM or known-unicast traffic is initiated from that C-MAC address, 380 the C-MAC is learned and advertised in BGP to other EVPN PEs and MAC 381 mobility procedure is exercised among EVPN PEs. For BUM traffic, both 382 EVPN and VPLS PEs learn the new location of the moved C-MAC address; 383 however, if there is only known-unicast traffic, then only EVPN PEs 384 learn the new location of the C-MAC that has moved but not VPLS PEs. 385 This can result in black-holing of traffic sent from VPLS PEs 386 destined to the C-MAC that has moved until there is a BUM traffic 387 originated with the moved C-MAC address as the source MAC address 388 (e.g., as a result of MAC age-out timer expires). Note that this is 389 behavior typical of VPLS PEs. 391 3.4 Multicast Operation 393 3.4.1 Ingress Replication 395 The procedures for multicast operation on the VPLS PE, using ingress 396 replication, are per [RFC4761], [RFC4762], and [RFC7080]. 398 The procedures for multicast operation on the EVPN PE, for ingress 399 replication, are as follows: 401 - The EVPN PE builds a replication sub-list to all the remote EVPN 402 PEs per EVPN instance as the result of the exchange of the EVPN IMET 403 routes per [RFC7432]. This will be referred to as sub-list A. It 404 comprises MP2P service tunnels used for delivering EVPN BUM traffic 405 [RFC7432]. 407 - The EVPN PE builds a replication sub-list per VPLS instance to all 408 the remote VPLS PEs. This will be referred to as sub-list B. It 409 comprises PWs from the EVPN PE in question to all the remote VPLS PEs 410 in the same VPLS instance. 412 The replication list, maintained per VPN instance, on a given EVPN PE 413 will be the union of sub-list A and sub-list B. Note that the PE must 414 enable split-horizon over all the entries in the replication list, 415 across both PWs and MP2P service tunnels. 417 3.4.2 P2MP Tunnel 419 The procedures for multicast operation on the EVPN PEs using P2MP 420 tunnels are outside of the scope of this document. 422 4 PBB-VPLS Integration with PBB-EVPN 424 In order to support seamless integration between PBB-VPLS and PBB- 425 EVPN PEs, this document requires that PBB-VPLS PEs support VPLS A-D 426 per [RFC6074] and PBB-EVPN PEs support both BGP EVPN routes per 427 [RFC7432] and VPLS A-D per [RFC6074]. All the logic for this seamless 428 integration shall reside on the PBB-EVPN PEs. 430 4.1 Capability Discovery 432 The procedures for capability discovery are per Section 3.1 above. 434 4.2 Forwarding Setup and Unicast Operation 436 The procedures for forwarding state setup and unicast operation on 437 the PBB-VPLS PE are per [RFC8077] and [RFC7080]. 439 The procedures for forwarding state setup and unicast operation on 440 the PBB-EVPN PE are as follows: 442 - The PBB-EVPN PE MUST establish a PW to each remote PBB-VPLS PE from 443 which it has received only a VPLS A-D route for the corresponding VPN 444 instance, and MUST set up the label stack corresponding to the PW 445 FEC. For seamless integration between PBB-EVPN and PBB-VPLS PEs, the 446 PW that is setup between a pair of PBB-VPLS and PBB-EVPN PEs, is 447 between B-components of PBB-EVPN PE and PBB-VPLS PE per section 4 of 448 [RFC7041]. 450 - The PBB-EVPN PE must set up the label stack corresponding to the 451 MP2P VPN unicast FEC to any remote PBB-EVPN PE that has advertised 452 EVPN IMET route. 454 - If a PBB-EVPN PE receives a VPLS A-D route from a given PE, it sets 455 up a PW to that PE. If it then receives an EVPN IMET route from the 456 same PE, then the PBB-EVPN PE MUST bring that PW operationally down. 458 - If a PBB-EVPN PE receives an EVPN IMET route followed by a VPLS A-D 459 route from the same PE, then the PBB-EVPN PE will setup the PW but 460 MUST keep it operationally down. 462 - In case VPLS AD is not used in some PBB-VPLS PEs, the PBB-EVPN PEs 463 need to be provisioned manually with PWs to those remote PBB-VPLS PEs 464 for each VPN instance. In that case, if a PBB-EVPN PE receives an 465 EVPN IMET route from a PE to which a PW exists, the PBB-EVPN PE MUST 466 bring the PW operationally down. 468 - When the PBB-EVPN PE receives traffic over the PBB-VPLS PWs, it 469 learns the associated B-MAC addresses in the data-plane. The B-MAC 470 addresses learned over these PWs MUST be injected into the bridge 471 table of the associated MAC-VRF on that PBB-EVPN PE. The learned B- 472 MAC addresses MAY also be injected into the RIB/FIB tables of the 473 associated the MAC-VRF on that BPP-EVPN PE. For seamless integration 474 between PBB-EVPN and PBB-VPLS PEs, since these PWs belongs to the 475 same split-horizon group as the MP2P EVPN service tunnels, then the 476 B-MAC addresses learned and associated to the PWs MUST NOT be 477 advertised in the control plane to any remote PBB-EVPN PEs. This is 478 because every PBB-EVPN PE can send and receive traffic directly 479 to/from every PBB-VPLS PE belonging to the same VPN instance. 481 - The C-MAC addresses learned over local Attachment Circuits (ACs) by 482 an PBB-EVPN PE are learned in data-plane. For PBB-EVPN PEs, these C- 483 MAC addresses are learned in I-component of PBB-EVPN PEs and they are 484 not advertised in the control-plane per [RFC7623]. 486 - The B-MAC addresses learned in the control plane via the BGP EVPN 487 routes sent by remote PBB-EVPN PEs, are injected into the 488 corresponding MAC-VRF table. 490 4.3 MAC Mobility 492 In PBB-EVPN, a given B-MAC address can be learnt either over the BGP 493 control-plane from a remote PBB-EVPN PE, or in the data-plane over a 494 PW from a remote PBB-VPLS PE. There is no mobility associated with B- 495 MAC addresses in this context. Hence, when the same B-MAC address 496 shows up behind both a remote PBB-VPLS PE as well as a PBB-EVPN PE, 497 the local PE can deduce that it is an anomaly and SHOULD notify the 498 operator. 500 4.4 Multicast Operation 502 4.4.1 Ingress Replication 504 The procedures for multicast operation on the PBB-VPLS PE, using 505 ingress replication, are per [RFC7041] and [RFC7080]. 507 The procedures for multicast operation on the PBB-EVPN PE, for 508 ingress replication, are as follows: 510 - The PBB-EVPN PE builds a replication sub-list per I-SID to all the 511 remote PBB-EVPN PEs in a given VPN instance as a result of the 512 exchange of the EVPN IMET routes, as described in [RFC7623]. This 513 will be referred to as sub-list A. It comprises MP2P service tunnels 514 used for delivering PBB-EVPN BUM traffic. 516 - The PBB-EVPN PE builds a replication sub-list per VPN instance to 517 all the remote PBB-VPLS PEs. This will be referred to as sub-list B. 518 It comprises PWs from the PBB-EVPN PE in question to all the remote 519 PBB-VPLS PEs in the same VPN instance. 521 - The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis, 522 by running [MMRP] over the PBB-VPLS network. This will be referred to 523 as sub-list C. This list comprises a pruned set of the PWs in the 524 sub-list B. 526 The replication list maintained per I-SID on a given PBB-EVPN PE will 527 be the union of sub-list A and sub-list B if [MMRP] is not used, and 528 the union of sub-list A and sub-list C if [MMRP] is used. Note that 529 the PE must enable split-horizon over all the entries in the 530 replication list, across both pseudowires and MP2P service tunnels. 532 4.4.2 P2MP Tunnel - Inclusive Tree 534 The procedures for multicast operation on the PBB-EVPN PEs using P2MP 535 tunnels are outside of the scope of this document. 537 5 Security Considerations 539 All the security considerations in [RFC4761], [RFC4762], [RFC7080], 540 [RFC7432], and [RFC7623] apply directly to this document because this 541 document leverages the control plane and the data plane procedures 542 described in these RFCs. 544 This document does not introduce any new security considerations 545 beyond that of the above RFCs because the advertisements and 546 processing of MAC addresses in BGP follow that of [RFC7432] and 547 processing of MAC addresses learned over PWs follow that of 548 [RFC4761], [RFC4762], and [RFC7080]. 550 6 IANA Considerations 552 This document has no actions for IANA. 554 7 References 556 7.1 Normative References 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, DOI 560 10.17487/RFC2119, March . 563 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 564 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 565 May 2017, . 567 [RFC8077] Martini, et al., "Pseudowire Setup and Maintenance using 568 the Label Distribution Protocol", RFC 8077, February 2017. 570 [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, 571 February, 2015. 573 [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with 574 Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015. 576 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private 577 LAN Service (VPLS) Using BGP for Auto-Discovery and 578 Signaling", RFC 4761, January 2007, . 581 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 582 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 583 Signaling", RFC 4762, January 2007, . 586 [RFC6074] Rosen et al., "Provisioning, Auto-Discovery, and Signaling 587 in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, 588 January 2011. 590 7.2 Informative References 592 [MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area 593 networks - Media Access Control (MAC) Bridges and Virtual Bridged 594 Local Area Networks", IEEE Std 802.1Q, 2013. 596 [RFC7041] Balus et al., "Extensions to VPLS PE model for Provider 597 Backbone Bridging", RFC 7041, November 2013. 599 [RFC7080] Sajassi et al., "VPLS Interoperability with Provider 600 Backbone Bridges", RFC 7080, December, 2013. 602 [IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area 603 networks - Media Access Control (MAC) Bridges and Virtual Bridged 604 Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI 605 10.1109/IEEESTD.2011.6009146. 607 [RFC4684] Marques et al., "Constrained Route Distribution for Border 608 Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet 609 Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November, 610 2006. 612 Authors' Addresses 614 Ali Sajassi 615 Cisco 616 Email: sajassi@cisco.com 618 Samer Salam 619 Cisco 620 Email: ssalam@cisco.com 622 Nick Del Regno 623 Verizon 624 Email: nick.delregno@verizon.com 626 Jorge Rabadan 627 Nokia 628 Email: jorge.rabadan@nokia.com