idnits 2.17.1 draft-ietf-bess-evpn-vpls-seamless-integ-07.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 (January 31, 2019) is 1884 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) ** Downref: Normative reference to an Informational RFC: RFC 7041 Summary: 1 error (**), 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: July 31, 2019 January 31, 2019 12 (PBB-)EVPN Seamless Integration with (PBB-)VPLS 13 draft-ietf-bess-evpn-vpls-seamless-integ-07 15 Abstract 17 This document specifies mechanisms 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. It also provides 21 mechanisms for seamless integration of these two technologies in the 22 same MPLS/IP network on a per-VPN-instance basis. Implementation of 23 this document enables service providers to introduce EVPN/PBB-EVPN 24 PEs in their brown-field deployments of VPLS/PBB-VPLS networks. This 25 document specifies control-plane and forwarding behavior needed for 26 auto-discovery of a VPN instance, multicast and unicast operation, as 27 well as MAC-mobility operation in order to enable seamless 28 integration between EVPN and VPLS PEs as well as between PBB-VPLS and 29 PBB-EVPN PEs. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as 39 Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright and License Notice 54 Copyright (c) 2018 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Specification of Requirements . . . . . . . . . . . . . . 5 71 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5 72 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 8 74 3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 8 75 3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 8 76 3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 10 78 3.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 10 79 3.4.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 11 80 4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 11 81 4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 11 82 4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 11 83 4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 13 84 4.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 13 85 4.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 13 86 4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 14 87 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 88 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 89 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 7.1 Normative References . . . . . . . . . . . . . . . . . . . 14 91 7.2 Informative References . . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 95 1 Introduction 97 Virtual Private LAN Service (VPLS) and Provider Backbone Bridging 98 VPLS (PBB-VPLS) are widely-deployed Layer-2 VPN (L2VPN) technologies. 99 Many service providers who are looking at adopting Ethernet VPN 100 (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) want to 101 preserve their investment in the VPLS and PBB-VPLS networks. Hence, 102 they require mechanisms by which EVPN and PBB-EVPN technologies can 103 be introduced into their brown-field VPLS and PBB-VPLS networks 104 without requiring any upgrades (software or hardware) to these 105 networks. This document specifies procedures for the seamless 106 integration of the two technologies in the same MPLS/IP network. 107 Throughout this document, we use the term (PBB-)EVPN to correspond to 108 both EVPN and PBB-EVPN and we use the term (PBB-)VPLS to correspond 109 to both VPLS and PBB-VPLS. This document specifies control-plane and 110 forwarding behavior needed for auto-discovery of a VPN instance, 111 multicast and unicast operations, as well as MAC-mobility operation 112 in order to enable seamless integration between (PBB-)EVPN Provider 113 Edge(PE) devices and (PBB-)VPLS PEs. 115 VPLS PE 116 +---+ 117 |PE1| 118 +---+ 119 / 120 EVPN/VPLS PE +---------------+ EVPN/VPLS PE 121 +---+ | | +---+ 122 |PE4|----| MPLS/IP |---|PE5| 123 +---+ | Core | +---+ 124 | | 125 +---------------+ 126 / \ 127 +---+ +---+ 128 |PE2| |PE3| 129 +---+ +---+ 130 VPLS PE VPLS PE 132 Figure 1: Seamless Integration of (PBB-)EVPN & (PBB-)VPLS 134 Section 2 provides the details of the requirements. Section 3 135 specifies procedures for the seamless integration of VPLS and EVPN 136 networks. And section 4 specifies procedures for the seamless 137 integration of PBB-VPLS and PBB-EVPN networks. 139 It should be noted that the scenarios for PBB-VPLS integration with 140 EVPN and VPLS integration with PBB-EVPN are not covered in this 141 document because there haven't been any requirements from service 142 providers for these scenarios. The reason for that is that 143 deployments which employ PBB-VPLS typically require PBB encapsulation 144 for various reasons. Hence, it is expected that for those deployments 145 the evolution path would be from PBB-VPLS towards PBB-EVPN. 146 Furthermore, the evolution path from VPLS is expected to be towards 147 EVPN. 149 The seamless integration solution described in this document has the 150 following attributes: 152 - When ingress replication is used for multi-destination traffic 153 delivery, the solution reduces the scope of [MMRP] (which is a soft- 154 state protocol) to only that of existing VPLS PEs, and uses the more 155 robust BGP-based mechanism for multicast pruning among new EVPN PEs. 157 - It is completely backward compatible. 159 - New PEs can leverage the extensive multi-homing mechanisms and 160 provisioning simplifications of (PBB-)EVPN: 161 a. Auto-sensing of MHN / MHD 162 b. Auto-discovery of redundancy group 163 c. Auto-provisioning of Designated Forwarder election and 164 VLAN carving 166 1.1. Specification of Requirements 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 1.2. Terms and Abbreviations 176 Broadcast Domain: In a bridged network, the broadcast domain 177 corresponds to a Virtual LAN (VLAN), where a VLAN is typically 178 represented by a single VLAN ID (VID) but can be represented by 179 several VIDs where Shared VLAN Learning (SVL) is used per 180 [IEEE.802.1ah]. 182 Bridge Table: An instantiation of a broadcast domain on a MAC-VRF 184 RIB: Routing Information Base - An instantiation of a routing table 185 on a MAC-VRF 187 FIB: Forwarding Information Base - An instantiation of a forwarding 188 table on a MAC-VRF 190 CE: A Customer Edge device, e.g., a host, router, or switch. 192 MAC-VRF: A Virtual Routing and Forwarding table for Media Access 193 Control (MAC) addresses on an EVPN PE. 195 MAC address: Media Access Control address 197 C-MAC address: Customer MAC address - e.g., host or CE's MAC address 199 B-MAC address: Backbone MAC address - e.g., PE's MAC address 201 Ethernet segment (ES): Refers to the set of Ethernet links that 202 connects a customer site (device or network) to one or more PEs. 204 Ethernet Tag: An Ethernet Tag identifies a particular broadcast 205 domain, e.g., a VLAN. An EVPN instance consists of one or more 206 broadcast domains 208 FEC: Forwarding Equivalence Class 210 LSP: Label Switched Path 212 MHD: Multi-Homed Device 214 MHN: Multi-Homed Network 216 P2MP: Point to Multipoint - a P2MP LSP typically refers to a LSP for 217 multicast traffic 219 MP2P: Multipoint to Point - a MP2P LSP typically refers to a LSP for 220 unicast traffic as the result of downstream-assigned label 222 PBB: Provider Backbone Bridge 224 PE: Provider Edge device 226 VSI: Virtual Switch Instance 228 VPLS: Virtual Private LAN Service 230 Single-Active Redundancy Mode: When only a single PE, among all the 231 PEs attached to an Ethernet segment, is allowed to forward traffic 232 to/from that Ethernet segment for a given VLAN, then the Ethernet 233 segment is defined to be operating in Single-Active redundancy mode. 235 All-Active Redundancy Mode: When all PEs attached to an Ethernet 236 segment are allowed to forward known unicast traffic to/from that 237 Ethernet segment for a given VLAN, then the Ethernet segment is 238 defined to be operating in All-Active redundancy mode. 240 (PBB-)EVPN: refers to both, PBB-EVPN and EVPN. This document uses 241 this abbreviation when a given description applies to both 242 technologies. 244 (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. This document uses 245 this abbreviation when a given description applies to both 246 technologies. 248 VPLS A-D: refers to Virtual Private LAN Services with BGP-based Auto 249 Discovery as in [RFC6074]. 251 PW: Pseudowire 253 I-SID: Ethernet Services Instance Identifier 255 2. Requirements 257 Following are the key requirements for backward compatibility between 258 (PBB-)EVPN and (PBB-)VPLS: 260 1. The solution must allow for staged migration towards (PBB-)EVPN on 261 a site-by-site basis per VPN instance - e.g., new EVPN sites to be 262 provisioned on (PBB-)EVPN Provider Edge devices (PEs). 264 2. The solution must not require any changes to existing VPLS or PBB- 265 VPLS PEs, not even a software upgrade. 267 3. The solution must allow for the co-existence of PE devices running 268 (PBB-)EVPN and (PBB-)VPLS for the same VPN instance and single-homed 269 segments. 271 4. The solution must support single-active redundancy of multi-homed 272 networks and multi-homed devices for (PBB-)EVPN PEs. 274 5. In case of single-active redundancy, the participant VPN instances 275 may span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as the 276 MHD or MHN is connected to (PBB-)EVPN PEs. 278 6. The support of All-Active redundancy mode across both (PBB-)EVPN 279 PEs and (PBB-)VPLS PEs is outside the scope of this document. All- 280 Active redundancy is not applicable to VPLS and PBB-VPLS. Therefore, 281 when EVPN (or PBB-EVPN) PEs need to operate seamlessly with VPLS (or 282 PBB-VPLS) PEs, then they MUST use a redundancy mode that is 283 applicable to VPLS (or PBB-VPLS). This redundancy mode is Single- 284 Active. 286 These requirements collectively allow for the seamless insertion of 287 the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments. 289 3 VPLS Integration with EVPN 291 In order to support seamless integration with VPLS PEs, this document 292 requires that VPLS PEs support VPLS A-D per [RFC6074] and EVPN PEs 293 support both BGP EVPN routes per [RFC7432] and VPLS A-D per 294 [RFC6074]. All the logic for seamless integration shall reside on the 295 EVPN PEs. If a VPLS instance is setup without the use of VPLS A-D, it 296 is still possible (but cumbersome) for EVPN PEs to integrate into 297 that VPLS instance by manually configuring Pseudowires (PWs) to all 298 the VPLS PEs in that instance (i.e., the integration is no longer 299 seamless). 301 3.1 Capability Discovery 303 The EVPN PEs MUST advertise both the BGP VPLS Auto-Discovery (A-D) 304 route as well as the BGP EVPN Inclusive Multicast Ethernet Tag (IMET) 305 route for a given VPN instance. The VPLS PEs only advertise the BGP 306 VPLS A-D route, per the procedures specified in [RFC4761], [RFC4762] 307 and [RFC6074]. The operator may decide to use the same Route Target 308 (RT) to identify a VPN on both EVPN and VPLS networks. In this case, 309 when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the 310 basis that it belongs to an unknown SAFI. However, the operator may 311 choose to use two RTs - one to identify the VPN on VPLS network and 312 another for EVPN network and employ RT-constrained [RFC4684] in order 313 to prevent BGP EVPN routes from reaching the VPLS PEs. 315 When an EVPN PE receives both a VPLS A-D route as well as an EVPN 316 IMET route from a given remote PE for the same VPN instance, it MUST 317 give preference to the EVPN route for the purpose of discovery. This 318 ensures that, at the end of the route exchanges, all EVPN capable PEs 319 discover other EVPN capable PEs in addition to the VPLS-only PEs for 320 that VPN instance. Furthermore, all the VPLS-only PEs will discover 321 the EVPN PEs as if they were standard VPLS PEs. In other words, when 322 the discovery phase is complete, the EVPN PEs will have discovered 323 all the PEs in the VPN instance along with their associated 324 capability (EVPN or VPLS-only), whereas the VPLS PEs will have 325 discovered all the PEs in the VPN instance as if they were all VPLS- 326 only PEs. 328 3.2 Forwarding Setup and Unicast Operation 330 The procedures for forwarding state setup and unicast operation on 331 the VPLS PE are per [RFC8077], [RFC4761], [RFC4762]. 333 The procedures for forwarding state setup and unicast operation on 334 the EVPN PE are as follows: 336 - The EVPN PE MUST establish a PW to each remote PE from which it has 337 received only a VPLS A-D route for the corresponding VPN instance, 338 and MUST set up the label stack corresponding to the PW FEC. For 339 seamless integration between EVPN and VPLS PEs, the PW that is setup 340 between a pair of VPLS and EVPN PEs is between the VSI of the VPLS PE 341 and the MAC-VRF of the EVPN PE. 343 - The EVPN PE MUST set up the label stack corresponding to the MP2P 344 VPN unicast FEC to any remote PE that has advertised EVPN IMET route. 346 - If an EVPN PE receives a VPLS A-D route from a given PE, it sets up 347 a PW to that PE. If it then receives an EVPN IMET route from the same 348 PE, then the EVPN PE MUST bring that PW operationally down. 350 - If an EVPN PE receives an EVPN IMET route followed by a VPLS A-D 351 route from the same PE, then the EVPN PE will setup the PW but MUST 352 keep it operationally down. 354 - In case VPLS A-D is not used in some VPLS PEs, the EVPN PEs need to 355 be provisioned manually with PWs to those remote VPLS PEs for each 356 VPN instance. In that case, if an EVPN PE receives an EVPN IMET route 357 from a PE to which a PW exists, the EVPN PE MUST bring the PW 358 operationally down. 360 When the EVPN PE receives traffic over the VPLS PWs, it learns the 361 associated C-MAC addresses in the data-plane. The C-MAC addresses 362 learned over these PWs MUST be injected into the bridge table of the 363 associated MAC-VRF on that EVPN PE. The learned C-MAC addresses MAY 364 also be injected into the RIB/FIB tables of the associated MAC-VRF on 365 that EVPN PE. For seamless integration between EVPN and VPLS PEs, 366 since these PWs belong to the same split-horizon group ([RFC4761] and 367 [RFC4762]) as the MP2P EVPN service tunnels, then the C-MAC addresses 368 learned and associated to the PWs MUST NOT be advertised in the 369 control plane to any remote EVPN PEs. This is because every EVPN PE 370 can send and receive traffic directly to/from every VPLS PE belonging 371 to the same VPN instance and thus every EVPN PE can learn the C-MAC 372 addresses over the corresponding PWs directly. 374 The C-MAC addresses learned over local Attachment Circuits (ACs) by 375 an EVPN PE are learned in data-plane. For EVPN PEs, these C-MAC 376 addresses MUST be injected into the corresponding MAC-VRF and 377 advertised in the control-plane using BGP EVPN routes. Furthermore, 378 the C-MAC addresses learned in the control plane via the BGP EVPN 379 routes sent by remote EVPN PEs, are injected into the corresponding 380 MAC-VRF table. 382 In case of a link failure in a single-active Ethernet Segment, the 383 EVPN PEs MUST perform both of the following tasks: 385 a) send a BGP mass-withdraw to the EVPN peers 387 b) follow existing VPLS MAC Flush procedures with the VPLS peers. 389 3.3 MAC Mobility 391 In EVPN, host addresses (C-MAC addresses) can move around among EVPN 392 PEs or even between EVPN and VPLS PEs. 394 When a C-MAC address moves from an EVPN PE to a VPLS PE, then as soon 395 as Broadcast/Unknown-unicast/Multicast (BUM) traffic is initiated 396 from that MAC address, it is flooded to all other PEs (both VPLS and 397 EVPN PEs) and the receiving PEs update their MAC tables (VSI or MAC- 398 VRF). The EVPN PEs do not advertise the C-MAC addresses learned over 399 the PW to each other because every EVPN PE learns them directly over 400 its associated PW to that VPLS PE. If only known-unicast traffic is 401 initiated from the moved C-MAC address toward a known C-MAC, then 402 this can result in black-holing of traffic destined to the C-MAC that 403 has moved until there is a BUM traffic originated with the moved C- 404 MAC address as the source MAC address (e.g., as a result of MAC age- 405 out timer expires). Such black-holing happens for traffic destined to 406 the moved C-MAC from both EVPN and VPLS PEs. It should be noted that 407 such black-holing behavior is typical for VPLS PEs. 409 When a C-MAC address moves from a VPLS PE to an EVPN PE, then as soon 410 as any traffic is initiated from that C-MAC address, the C-MAC is 411 learned and advertised in BGP to other EVPN PEs and MAC mobility 412 procedure is exercised among EVPN PEs. For BUM traffic, both EVPN and 413 VPLS PEs learn the new location of the moved C-MAC address; however, 414 if there is only known-unicast traffic, then only EVPN PEs learn the 415 new location of the C-MAC that has moved but not VPLS PEs. This can 416 result in black-holing of traffic sent from VPLS PEs destined to the 417 C-MAC that has moved until there is a BUM traffic originated with the 418 moved C-MAC address as the source MAC address (e.g., as a result of 419 MAC age-out timer expires). Such black-holing happens for traffic 420 destined to the moved C-MAC for only VPLS PEs but not for EVPN PEs. 421 It should be noted that such black-holing behavior is typical for 422 VPLS PEs. 424 3.4 Multicast Operation 426 3.4.1 Ingress Replication 428 The procedures for multicast operation on the VPLS PE, using ingress 429 replication, are per [RFC4761], [RFC4762], and [RFC7080]. 431 The procedures for multicast operation on the EVPN PE, for ingress 432 replication, are as follows: 434 - The EVPN PE builds a replication sub-list to all the remote EVPN 435 PEs per EVPN instance as the result of the exchange of the EVPN IMET 436 routes per [RFC7432]. This will be referred to as sub-list A. It 437 comprises MP2P service tunnels (for ingress replication) used for 438 delivering EVPN BUM traffic [RFC7432]. 440 - The EVPN PE builds a replication sub-list per VPLS instance to all 441 the remote VPLS PEs. This will be referred to as sub-list B. It 442 comprises PWs from the EVPN PE in question to all the remote VPLS PEs 443 in the same VPLS instance. 445 The replication list, maintained per VPN instance, on a given EVPN PE 446 will be the union of sub-list A and sub-list B. The EVPN PE MUST 447 enable split-horizon over all the entries in the replication list, 448 across both PWs and MP2P service tunnels. 450 3.4.2 P2MP Tunnel 452 The procedures for multicast operation on the EVPN PEs using P2MP 453 tunnels are outside of the scope of this document. 455 4 PBB-VPLS Integration with PBB-EVPN 457 In order to support seamless integration between PBB-VPLS and PBB- 458 EVPN PEs, this document requires that PBB-VPLS PEs support VPLS A-D 459 per [RFC6074] and PBB-EVPN PEs support both BGP EVPN routes per 460 [RFC7432] and VPLS A-D per [RFC6074]. All the logic for this seamless 461 integration shall reside on the PBB-EVPN PEs. 463 4.1 Capability Discovery 465 The procedures for capability discovery are per Section 3.1 above. 467 4.2 Forwarding Setup and Unicast Operation 469 The procedures for forwarding state setup and unicast operation on 470 the PBB-VPLS PE are per [RFC8077] and [RFC7080]. 472 The procedures for forwarding state setup and unicast operation on 473 the PBB-EVPN PE are as follows: 475 - The PBB-EVPN PE MUST establish a PW to each remote PBB-VPLS PE from 476 which it has received only a VPLS A-D route for the corresponding VPN 477 instance, and MUST set up the label stack corresponding to the PW 478 FEC. For seamless integration between PBB-EVPN and PBB-VPLS PEs, the 479 PW that is setup between a pair of PBB-VPLS and PBB-EVPN PEs, is 480 between B-components of PBB-EVPN PE and PBB-VPLS PE per section 4 of 481 [RFC7041]. 483 - The PBB-EVPN PE MUST set up the label stack corresponding to the 484 MP2P VPN unicast FEC to any remote PBB-EVPN PE that has advertised 485 EVPN IMET route. 487 - If a PBB-EVPN PE receives a VPLS A-D route from a given PE, it sets 488 up a PW to that PE. If it then receives an EVPN IMET route from the 489 same PE, then the PBB-EVPN PE MUST bring that PW operationally down. 491 - If a PBB-EVPN PE receives an EVPN IMET route followed by a VPLS A-D 492 route from the same PE, then the PBB-EVPN PE will setup the PW but 493 MUST keep it operationally down. 495 - In case VPLS A-D is not used in some PBB-VPLS PEs, the PBB-EVPN PEs 496 need to be provisioned manually with PWs to those remote PBB-VPLS PEs 497 for each VPN instance. In that case, if a PBB-EVPN PE receives an 498 EVPN IMET route from a PE to which a PW exists, the PBB-EVPN PE MUST 499 bring the PW operationally down. 501 - When the PBB-EVPN PE receives traffic over the PBB-VPLS PWs, it 502 learns the associated B-MAC addresses in the data-plane. The B-MAC 503 addresses learned over these PWs MUST be injected into the bridge 504 table of the associated MAC-VRF on that PBB-EVPN PE. The learned B- 505 MAC addresses MAY also be injected into the RIB/FIB tables of the 506 associated the MAC-VRF on that BPP-EVPN PE. For seamless integration 507 between PBB-EVPN and PBB-VPLS PEs, since these PWs belongs to the 508 same split-horizon group as the MP2P EVPN service tunnels, then the 509 B-MAC addresses learned and associated to the PWs MUST NOT be 510 advertised in the control plane to any remote PBB-EVPN PEs. This is 511 because every PBB-EVPN PE can send and receive traffic directly 512 to/from every PBB-VPLS PE belonging to the same VPN instance. 514 - The C-MAC addresses learned over local Attachment Circuits (ACs) by 515 an PBB-EVPN PE are learned in data-plane. For PBB-EVPN PEs, these C- 516 MAC addresses are learned in I-component of PBB-EVPN PEs and they are 517 not advertised in the control-plane per [RFC7623]. 519 - The B-MAC addresses learned in the control plane via the BGP EVPN 520 routes sent by remote PBB-EVPN PEs, are injected into the 521 corresponding MAC-VRF table. 523 In case of a link failure in a single-active Ethernet Segment, the 524 PBB-EVPN PEs MUST perform both of the following tasks: 526 a) send a BGP B-MAC withdraw message to the PBB-EVPN peers OR MAC 527 advertisement with MAC Mobility extended community 529 b) follow existing VPLS MAC Flush procedures with the PBB-VPLS peers 531 4.3 MAC Mobility 533 In PBB-EVPN, a given B-MAC address can be learned either over the BGP 534 control-plane from a remote PBB-EVPN PE, or in the data-plane over a 535 PW from a remote PBB-VPLS PE. There is no mobility associated with B- 536 MAC addresses in this context. Hence, when the same B-MAC address 537 shows up behind both a remote PBB-VPLS PE as well as a PBB-EVPN PE, 538 the local PE can deduce that it is an anomaly and SHOULD notify the 539 operator. 541 4.4 Multicast Operation 543 4.4.1 Ingress Replication 545 The procedures for multicast operation on the PBB-VPLS PE, using 546 ingress replication, are per [RFC7041] and [RFC7080]. 548 The procedures for multicast operation on the PBB-EVPN PE, for 549 ingress replication, are as follows: 551 - The PBB-EVPN PE builds a replication sub-list per I-SID to all the 552 remote PBB-EVPN PEs in a given VPN instance as a result of the 553 exchange of the EVPN IMET routes, as described in [RFC7623]. This 554 will be referred to as sub-list A. It comprises MP2P service tunnels 555 used for delivering PBB-EVPN BUM traffic. 557 - The PBB-EVPN PE builds a replication sub-list per VPN instance to 558 all the remote PBB-VPLS PEs. This will be referred to as sub-list B. 559 It comprises PWs from the PBB-EVPN PE in question to all the remote 560 PBB-VPLS PEs in the same VPN instance. 562 - The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis, 563 by running [MMRP] over the PBB-VPLS network. This will be referred to 564 as sub-list C. This list comprises a pruned set of the PWs in the 565 sub-list B. 567 The replication list maintained per I-SID on a given PBB-EVPN PE will 568 be the union of sub-list A and sub-list B if [MMRP] is not used, and 569 the union of sub-list A and sub-list C if [MMRP] is used. Note that 570 the PE MUST enable split-horizon over all the entries in the 571 replication list, across both pseudowires and MP2P service tunnels. 573 4.4.2 P2MP Tunnel - Inclusive Tree 575 The procedures for multicast operation on the PBB-EVPN PEs using P2MP 576 tunnels are outside of the scope of this document. 578 5 Security Considerations 580 All the security considerations in [RFC4761], [RFC4762], [RFC7080], 581 [RFC7432], and [RFC7623] apply directly to this document because this 582 document leverages the control plane and the data plane procedures 583 described in these RFCs. 585 This document does not introduce any new security considerations 586 beyond that of the above RFCs because the advertisements and 587 processing of MAC addresses in BGP follow that of [RFC7432] and 588 processing of MAC addresses learned over PWs follow that of 589 [RFC4761], [RFC4762], and [RFC7080]. 591 6 IANA Considerations 593 This document has no actions for IANA. 595 7 References 597 7.1 Normative References 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, DOI 601 10.17487/RFC2119, March . 604 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 605 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 606 May 2017, . 608 [RFC8077] Martini, et al., "Pseudowire Setup and Maintenance using 609 the Label Distribution Protocol", RFC 8077, February 2017. 611 [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, 612 February, 2015. 614 [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with 615 Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015. 617 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private 618 LAN Service (VPLS) Using BGP for Auto-Discovery and 619 Signaling", RFC 4761, January 2007, . 622 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 623 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 624 Signaling", RFC 4762, January 2007, . 627 [RFC7041] Balus et al., "Extensions to VPLS PE model for Provider 628 Backbone Bridging", RFC 7041, November 2013. 630 [RFC6074] Rosen et al., "Provisioning, Auto-Discovery, and Signaling 631 in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, 632 January 2011. 634 7.2 Informative References 636 [MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area 637 networks - Media Access Control (MAC) Bridges and Virtual Bridged 638 Local Area Networks", IEEE Std 802.1Q, 2013. 640 [RFC7080] Sajassi et al., "VPLS Interoperability with Provider 641 Backbone Bridges", RFC 7080, December, 2013. 643 [IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area 644 networks - Media Access Control (MAC) Bridges and Virtual Bridged 645 Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI 646 10.1109/IEEESTD.2011.6009146. 648 [RFC4684] Marques et al., "Constrained Route Distribution for Border 649 Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet 650 Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November, 651 2006. 653 Authors' Addresses 655 Ali Sajassi 656 Cisco 657 Email: sajassi@cisco.com 659 Samer Salam 660 Cisco 661 Email: ssalam@cisco.com 663 Nick Del Regno 664 Verizon 665 Email: nick.delregno@verizon.com 667 Jorge Rabadan 668 Nokia 669 Email: jorge.rabadan@nokia.com