INTERNET-DRAFT                                               Ali
BESS Workgroup                                       A. Sajassi (Editor)
INTERNET-DRAFT                                                  S. Salam
Intended Status: Standard Track                              Samer Salam                                    Cisco

                                                          Nick
                                                            N. Del Regno
                                                                 Verizon

                                                           Jorge
                                                              J. Rabadan
                                                          Alcatel-Lucent
                                                                   Nokia

Expires: September 29, October 15, 2018                               March 29,                                 April 15, 2018

            (PBB-)EVPN Seamless Integration with (PBB-)VPLS
              draft-ietf-bess-evpn-vpls-seamless-integ-02
              draft-ietf-bess-evpn-vpls-seamless-integ-03

Abstract

   This draft specifies procedures for backward compatibility of the
   (PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for
   seamless integration of the two technologies in the same MPLS/IP
   network on a per-VPN-instance basis. Implementation of this draft
   enables service providers to introduce (PBB-)EVPN PEs in their
   brownfield deployments of (PBB-)VPLS networks.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice
   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
     1.1.  Specification of Requirements  . . . . . . . . . . . . . .  4  3
     1.2.  Terms and Abbreviations  . . . . . . . . . . . . . . . . .  5  4
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6  5
   3 PBB-VPLS VPLS Integration with PBB-EVPN EVPN . . . . . . . . . . . . . . .  7 . . . .  6
     3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . .  7  6
     3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . .  7
     3.3 Multicast Operation  . . . . . . . . . . . . . . MAC Mobility . . . . . .  8
       3.3.1 Ingress Replication . . . . . . . . . . . . . . . . . .  8
       3.3.2 P2MP Tunnel  . .
     3.4 Multicast Operation  . . . . . . . . . . . . . . . . . . . .  9
   4 VPLS Integration with EVPN .
       3.4.1 Ingress Replication  . . . . . . . . . . . . . . . . . .  9
     4.1 Capability Discovery . . . . . . . . .
       3.4.2 P2MP Tunnel  . . . . . . . . . . .  9
     4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . .  9
       4.2.1 MAC Mobility . . . . . . .
   4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . .  9
     4.3 Multicast Operation  . . . . . . . . . . . . . . . . . . . . 10
       4.3.1 Ingress Replication  . . . . . . . . . . . . . .
     4.1 Capability Discovery . . . . 10
       4.3.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 10
   5 VPLS Integration with PBB-EVPN . .  9
     4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . .  9
     4.3 MAC Mobility . . . . 10
     5.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 10
     5.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 11
     5.3
     4.4 Multicast Operation  . . . . . . . . . . . . . . . . . . . . 11
       5.3.1 10
       4.4.1 Ingress Replication  . . . . . . . . . . . . . . . . . . 11
       5.3.2 10
       4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 11
   6
   5 Solution Advantages  . . . . . . . . . . . . . . . . . . . . . . 11
   7
   6 Security Considerations  . . . . . . . . . . . . . . . . . . . . 11
   8 12
   7  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
   9
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1
     8.1  Normative References  . . . . . . . . . . . . . . . . . . . 12
     9.2
     8.2  Informative References  . . . . . . . . . . . . . . . . . . 12 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

1  Introduction

   VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many
   Service Providers (SPs) who are looking at adopting EVPN and PBB-EVPN
   want to preserve their investment in the (PBB-)VPLS networks. Hence,
   they require procedures by which (PBB-)EVPN technology can be
   introduced into their brownfield (PBB-)VPLS networks without
   requiring any upgrades (software or hardware) to these networks. This
   document specifies procedures for the seamless integration of the two
   technologies in the same MPLS/IP network.

                            VPLS PE
                             +---+
                             |PE1|
                             +---+
                               /
        EVPN/VPLS PE  +---------------+   EVPN/VPLS PE
             +---+    |               |   +---+
             |PE4|----|    MPLS/IP    |---|PE5|
             +---+    |     Core      |   +---+
                      |               |
                      +---------------+
                        /        \
                     +---+     +---+
                     |PE2|     |PE3|
                     +---+     +---+
                   VPLS PE     VPLS PE

     Figure 1: Seamless Integration of (PBB-)EVPN PEs & (PBB-)VPLS

   Section 2 provides the details of the requirements. Section 3
   specifies procedures for the seamless integration of PBB-VPLS and
   PBB-EVPN networks. Section 4 specifies procedures for the seamless
   integration of VPLS and EVPN
   networks. Section 5 4 specifies procedures for the seamless integration
   of VPLS PBB-VPLS and PBB-EVPN networks, and
   finally networks. Section 6 5 discusses the solution
   advantages.

   It is worth noting should be noted that the scenario where scenarios for PBB-VPLS is integrated integration with EVPN, is
   EVPN and VPLS integration with PBB-EVPN are not covered in this draft
   document because there hasn't haven't been any
   requirement requirements from service
   providers for such integration. these scenarios. The reason for that is that
   deployments which employ PBB-VPLS typically require PBB encapsulation
   for various reasons. Hence, it is expected that for those deployments
   the evolution path would be from PBB-VPLS towards
   PBB-EVPN, rather than PBB-EVPN.
   Furthermore, the evolution path from VPLS is expected to be towards
   EVPN.

1.1.  Specification of Requirements
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Terms and Abbreviations

   B-MAC: Backbone MAC

   B-VID: Backbone VLAN ID

   Broadcast Domain:  In a bridged network, the broadcast domain
   corresponds to a Virtual LAN (VLAN), where a VLAN is typically
   represented by a single VLAN ID (VID) but can be represented by
   several VIDs where Shared VLAN Learning (SVL) is used per
   [IEEE.802.1ah].

   Bridge Table:  An instantiation of a broadcast domain on a MAC-VRF.

   CE:  A Customer Edge device, MAC-VRF

   RIB: Routing Information Base - An instantiation of a routing table
   on a MAC-VRF

   FIB: Forwarding Information Base - An instantiation of a forwarding
   table on a MAC-VRF

   CE:  A Customer Edge device, e.g., a host, router, or switch.

   EVI:  An EVPN Instance spanning the Provider Edge (PE) devices
   participating in that EVPN.

   MAC-VRF:  A Virtual Routing and Forwarding table for Media Access
   Control (MAC) addresses on an EVPN PE.

   MAC address: Media Access Control address

   ES:  When a customer site (device or network) is connected to one or
   more PEs via a set of Ethernet links, then that set of links is
   referred to as an "Ethernet Segment".

   ESI:  An Ethernet Segment Identifier is a unique non-zero identifier
   that identifies an ES

   Ethernet Tag:  An Ethernet Tag identifies a particular broadcast
   domain, e.g., a VLAN.  An EVPN instance consists of one or more
   broadcast domains

   MHD: Multi-Homed Device
   MHN: Multi-Homed Network

   P2MP:  Point-to-Multipoint

   PBB: Provider Backbone Bridge

   PE:  Provider Edge device

   VSI: Virtual Switch Instance

   VPLS: Virtual Private LAN Service

   Single-Active Redundancy Mode: When only a single PE, among all the
   PEs attached to an Ethernet segment, is allowed to forward traffic
   to/from that Ethernet segment for a given VLAN, then the Ethernet
   segment is defined to be operating in Single-Active redundancy mode.

   All-Active Redundancy Mode: When all PEs attached to an Ethernet
   segment are allowed to forward known unicast traffic to/from that
   Ethernet segment for a given VLAN, then the Ethernet segment is
   defined to be operating in All-Active redundancy mode.

   (PBB-)EVPN: refers to both, PBB-EVPN and EVPN. This document uses
   this abbreviation when a given description applies to both
   technologies.

   (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. As for EVPN, this
   abbreviation is used when the text applies to both technologies.

   VPLS A-D: refers to Virtual Private LAN Services with BGP-based Auto
   Discovery as in [RFC6074].

   PW: Pseudowire.

2.  Requirements

   Following are the key requirements for backward compatibility between
   (PBB-)EVPN and (PBB-)VPLS:

   1. The solution MUST allow for staged migration towards (PBB-)EVPN on
   a site-by-site basis per VPN instance - e.g., new EVPN sites to be
   provisioned on (PBB-)EVPN PEs.

   2. The solution MUST require no changes to existing VPLS or PBB-VPLS
   PEs, not even a software upgrade.

   3. The solution MUST allow for the coexistence of PEs running (PBB-
   )EVPN and (PBB-)VPLS for the same VPN instance and single-homed
   segments.

   4. The solution MUST support single-active redundancy of multi-homed
   networks and multi-homed devices for (PBB-)EVPN PEs.

   5. In case of single-active redundancy, the participant VPN instances
   MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as
   single-active redundancy the
   MHD or MHN is employed by connected to (PBB-)EVPN PEs. In case of an ES link
   failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to the EVPN
   peers OR MAC advertisement with MAC Mobility extended community for
   PBB-EVPN AND an LDP follow existing VPLS MAC withdrawal to Flush procedures with the VPLS
   peers.

   6. The solution SHOULD support All-Active redundancy mode of multi-
   homed networks and multi-homed devices for (PBB-)EVPN PEs. In case of All-Active redundancy mode, the participant VPN instances SHOULD be
   confined to mode across both (PBB-)EVPN
   PEs only. and (PBB-)VPLS PEs is outside the scope of this document.

   These requirements collectively allow for the seamless insertion of
   the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments.

3 PBB-VPLS VPLS Integration with PBB-EVPN EVPN

   In order to support seamless integration with (PBB-)VPLS VPLS PEs, the
   (PBB-)EVPN this document
   requires that VPLS PEs MUST support VPLS A-D per [RFC6074] and EVPN PEs
   support both BGP EVPN routes (EVPN SAFI) per [RFC7432] and VPLS AD
   route (VPLS SAFI). A-D per
   [RFC6074]. All the logic for this seamless integration SHALL reside
   on the (PBB-)EVPN EVPN PEs. However, if If a VPLS instance is setup without the use of BGP auto-discovery, VPLS
   A-D, it is still possible (but cumbersome) for (PBB-)EVPN EVPN PEs to integrate
   into that VPLS instance. instance by manually configuring PWs to all the VPLS
   PEs in that instance (i.e., the integration is no longer seamless).

3.1 Capability Discovery

   The (PBB-)EVPN EVPN PEs MUST advertise both the BGP VPLS auto-discovery
   (AD) A-D route as well as
   the BGP EVPN Inclusive Multicast Ethernet Tag (IMET) route for a
   given VPN instance. The (PBB-)VPLS VPLS PEs only advertise the BGP VPLS AD A-D
   route, per current standard procedures specified in [RFC4761] [RFC4761],
   [RFC4762] and [RFC6074]. The operator may decide to use the same BGP RT
   Route Target (RT) to identify a VPN on both (PBB-)EVPN EVPN and (PBB-)VPLS VPLS networks.
   In this case, when a (PBB-)VPLS VPLS PE receives the EVPN Inclusive Multicast IMET route, it will MUST
   ignore it on the basis that it belongs to an unknown SAFI. However,
   the operator may choose to use two RTs - one to identify the VPN on
   (PBB-)VPLS
   VPLS network and another for (PBB-)EVPN EVPN network and employ RT-
   constraint RT-constrained
   [RFC4684] in order to prevent EVPN BGP EVPN routes from reaching the
   (PBB-)VPLS VPLS
   PEs.

   When a (PBB-)EVPN EVPN PE receives both a VPLS AD A-D route as well as an EVPN
   Inclusive Multicast IMET
   route from a given remote PE for the same VPN instance, it MUST give
   preference to the EVPN route for the purpose of discovery. This
   ensures that, at the end of the route exchanges, all (PBB-)EVPN EVPN capable PEs
   discover other (PBB-)EVPN EVPN capable PEs in addition to the (PBB-)VPLS-only VPLS-only PEs for
   that VPN instance. Furthermore, all the (PBB-)VPLS-only VPLS-only PEs would discover
   the (PBB-
   )EVPN EVPN PEs as if they were standard (PBB-)VPLS VPLS PEs. In other words, when
   the discovery phase is complete, the (PBB-)EVPN EVPN PEs would have discovered
   all the PEs in the VPN instance along with their associated
   capability: (PBB-)EVPN EVPN or VPLS-only. Whereas the (PBB-
   )VPLS VPLS PEs would have
   discovered all the PEs in the VPN instance, instance as if they were all VPLS-only VPLS-
   only PEs.

3.2 Forwarding Setup and Unicast Operation

   The procedures for forwarding state setup and unicast operation on
   the
   (PBB-)VPLS VPLS PE are per [RFC8077] and [RFC7080]. [RFC8077], [RFC4761], [RFC4762].

   The procedures for forwarding state setup and unicast operation on
   the (PBB-)EVPN EVPN PE are as follows:

   - The (PBB-)EVPN EVPN PE MUST establish a pseudowire PW to a remote PE from which it has
   received only a VPLS AD A-D route for the corresponding VPN instance,
   and MUST set up the label stack corresponding to the
   pseudowire PW FEC. For
   seamless integration between PBB-EVPN EVPN and PBB- VPLS PEs, this the PW that is setup
   between B-components a pair of PBB-EVPN PE VPLS and PBB-VPLS
   PE per section 4 of  [RFC7041].

   - EVPN PEs is between the VSI of the VPLS PE
   and the MAC-VRF of the EVPN PE.

   - The (PBB-)EVPN EVPN PE must set up the label stack corresponding to the MP2P
   VPN unicast FEC to any remote PE that has advertised EVPN AD IMET route.

   - If a (PBB-)EVPN EVPN PE receives a VPLS AD A-D route followed by an EVPN AD IMET
   route from the same PE and a pseudowire PW is already setup to that PE, then the
   (PBB-)EVPN
   EVPN MUST bring that pseudowire PW operationally down.

   - If a (PBB-)EVPN EVPN PE receives an EVPN AD IMET route followed by a VPLS AD A-D
   route from the same PE, then the (PBB-)EVPN EVPN PE will setup the
   pseudowire PW but MUST
   keep it operationally down.

   - In case VPLS AD is not used in some VPLS PEs, the EVPN PEs need to
   be provisioned manually with PWs to those remote VPLS PEs for each
   VPN instance. In that case, if a EVPN PE receives an EVPN IMET route
   from a PE to which a PW exists, the PW will be brought operationally
   down.

   When the (PBB-)EVPN EVPN PE receives traffic over the pseudowires, VPLS PWs, it learns the
   associated MAC C-MAC addresses in the data-plane. This is
   analogous to dynamic learning in IEEE bridges. The MAC C-MAC addresses
   learned over these PWs are not MUST be injected into (PBB-)EVPN the bridge table of the
   associated MAC-VRF tables but
   rather they are on that EVPN PE. The learned C-MAC addresses MAY
   also be injected into their corresponding (PBB-)VPLS VSI
   table. If the core-facing PW belongs RIB/FIB tables of the associated MAC-VRF on
   that EVPN PE. For seamless integration between EVPN and VPLS PEs,
   since these PWs belong to the same split-horizon group as the core-facing MP2P
   EVPN service tunnels, then the MAC C-MAC addresses learned and associated
   to the PW PWs will NOT be advertised in the control plane to any remote (PBB-)EVPN PE.
   EVPN PEs. This is because every
   (PBB-)EVPN EVPN PE can send and receive traffic
   directly to/from every
   (PBB-)VPLS VPLS PE belonging to the same VPN instance.

   The MAC C-MAC addresses learned over local Attachment Circuits (ACs) by a
   (PBB-)EVPN
   an EVPN PE are learned in data-plane. For EVPN PEs, these C-MAC
   addresses MUST be injected into the corresponding MAC-VRF and
   advertised in control plane the control-plane using BGP EVPN routes
   to other (PBB-)EVPN PEs. routes. Furthermore,
   the MAC C-MAC addresses learned in the control plane, plane via the BGP EVPN
   routes sent by remote (PBB-)EVPN EVPN PEs, are injected into the corresponding
   MAC-VRF table. This is
   analogous to static learning in IEEE bridges. In PBB-EVPN, a given B-

3.3 MAC address Mobility

   In EVPN, host addresses (C-MAC addresses) can be learnt either over the BGP control-plane from a
   remote PBB-EVPN PE, move around among EVPN
   PEs or in the data-plane over even between EVPN and VPLS PEs.

   When a pseudowire C-MAC address moves from an EVPN PE to a
   remote PBB-VPLS PE. There is no mobility associated with B-MAC
   addresses in this context. Hence, when the same B-MAC address shows
   up behind both a remote PBB-VPLS PE VPLS PE, then as well soon
   as a PBB-EVPN PE, the
   local PE can deduce BUM traffic is initiated from that MAC address, it is an anomaly flooded to
   all other PEs (both VPLS and notify the operator.

3.3 Multicast Operation

3.3.1 Ingress Replication The procedures for multicast operation on the
   (PBB-)VPLS PE, using ingress replication, are per [RFC4761],
   [RFC4762], EVPN PEs) and [RFC7080].

   The procedures for multicast operation on the PBB-EVPN PE, for
   ingress replication, are as follows:

   - receiving PEs update
   their MAC tables (VSI or MAC-VRF). The PBB-EVPN EVPN PEs do not advertise the
   C-MAC address learned over PW to each other because every EVPN PE builds a replication sub-list per I-SID
   learns it directly over its associated PW to all that VPLS PE. If only
   known-unicast traffic is initiated from the
   remote PBB-EVPN PEs in a given VPN instance, as moved C-MAC address
   toward a known C-MAC, then this can result of the
   exchange of the EVPN Inclusive multicast routes, as described in
   [RFC7623]. This will be referred black-holing of traffic
   destined to as sub-list A. It comprises MP2P
   service tunnels used for delivering PBB-EVPN the C-MAC that has moved until there is a BUM traffic [RFC7432].

   - The PBB-EVPN PE builds a replication sub-list per VPN instance to
   all
   originated with the remote PBB-VPLS PEs , moved C-MAC address as the source MAC address
   (e.g., as a result of MAC age-out timer expires) but this is the exchange
   typical behavior of the VPLS
   AD routes. This will be referred to as sub-list B. It comprises
   pseudowires PEs.

   When a C-MAC address moves from the PBB-EVPN a VPLS PE in question to all an EVPN PE, then as soon
   as BUM or known-unicast traffic is initiated from that C-MAC address,
   the remote PBB- C-MAC is learned and advertised in BGP to other EVPN PEs and MAC
   mobility procedure is exercised among EVPN PEs. For BUM traffic, both
   EVPN and VPLS PEs in learn the same VPN instance.

   - The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis, new location of the moved C-MAC address;
   however, if [MMRP] there is run over only known-unicast traffic, then only EVPN PEs
   learn the PBB-VPLS network. This will be referred to
   as sub-list C. This list comprises a pruned set new location of the pseudowires C-MAC that has moved but not VPLS PEs.
   This can result in
   sub-list B.

   The replication list, maintained per I-SID, on a given PBB-EVPN PE
   will be the union black-holing of sub-list A and sub-list B if [MMRP] is NOT used,
   and traffic sent from VPLS PEs
   destined to the union of sub-list A and sub-list C if [MMRP] is used. Note C-MAC that has moved until there is a BUM traffic
   originated with the PE must enable split-horizon over all moved C-MAC address as the entries in source MAC address
   (e.g., as a result of MAC age-out timer expires) but this is the
   replication list, across both pseudowires and MP2P service tunnels.

3.3.2 P2MP Tunnel
   typical behavior of VPLS PEs.

3.4 Multicast Operation

3.4.1 Ingress Replication

   The procedures for multicast operation on the PBB-EVPN
   PEs using P2MP tunnels are outside of the scope of this document.

4 VPLS Integration with EVPN

4.1 Capability Discovery

   The procedures for capability discovery PE, using ingress
   replication, are per Section 3.1 above.

4.2 Forwarding Setup [RFC4761], [RFC4762], and Unicast Operation [RFC7080].

   The procedures for multicast operation here is largely similar to that of PBB-EVPN integration
   with PBB-VPLS, with one major exception in handling MAC mobility that
   is described in on the next section. EVPN PE, for ingress
   replication, are as follows:

   - For seamless integration among The EVPN and VPLS PEs, the PW that is
   setup between PE builds a pair of VPLS and replication sub-list to all the remote EVPN
   PEs is between VSI per EVPN instance as the result of VPLS PE
   and MAC-VRF the exchange of EVPN PE.

4.2.1 MAC Mobility
   Contrary to PBB-EVPN, where the association between a B-MAC and a
   PBB-EVPN PE is fixed and thus there is no B-MAC mobility, in EVPN,
   host addresses (C-MAC addresses) can move around among EVPN PEs or
   even between IMET
   routes per [RFC7432]. This will be referred to as sub-list A. It
   comprises MP2P service tunnels used for delivering EVPN and VPLS PEs.

   When a MAC address moves from an BUM traffic
   [RFC7432].

   - The EVPN PE to builds a replication sub-list per VPLS PE, then as soon instance to all
   the remote VPLS PEs. This will be referred to as BUM traffic is initiated sub-list B. It
   comprises PWs from that MAC address, it is flooded the EVPN PE in question to all other the remote VPLS PEs (both
   in the same VPLS and instance.

   The replication list, maintained per VPN instance, on a given EVPN PEs) PE
   will be the union of sub-list A and sub-list B. Note that the receiving PEs update
   their MAC tables (VSI or MAC-VRF). PE must
   enable split-horizon over all the entries in the replication list,
   across both PWs and MP2P service tunnels.

3.4.2 P2MP Tunnel

   The procedures for multicast operation on the EVPN PEs do not advertise using P2MP
   tunnels are outside of the
   MAC address learned over PW scope of this document.

4 PBB-VPLS Integration with PBB-EVPN

   In order to each other because every support seamless integration between PBB-VPLS and PBB-
   EVPN PEs, this document requires that PBB-VPLS PEs support VPLS A-D
   per [RFC6074] and PBB-EVPN PEs support both BGP EVPN routes per
   [RFC7432] and VPLS A-D per [RFC6074]. All the logic for this seamless
   integration SHALL reside on the PBB-EVPN PEs.

4.1 Capability Discovery

   The procedures for capability discovery are per Section 3.1 above.

4.2 Forwarding Setup and Unicast Operation

   The procedures for forwarding state setup and unicast operation on
   the PBB-VPLS PE
   learns it directly over its associated PW are per [RFC8077] and [RFC7080].

   The procedures for forwarding state setup and unicast operation on
   the PBB-EVPN PE are similar to that of section 3.2 except for the
   following:

   - For seamless integration between EVPN and VPLS PE. If only
   known-unicast traffic is initiated from PEs, the moved MAC address toward PW that is
   setup between a known MAC, then this can result in black-holing pair of PBB-VPLS and PBB-EVPN PEs, is between B-
   components of PBB-EVPN PE and PBB-VPLS PE per section 4 of
   [RFC7041].

   - When the PBB-EVPN PE receives traffic destined
   to over the PBB-VPLS PWs, it
   learns the associated B-MAC addresses in the data-plane. The B-MAC
   addresses learned over these PWs MUST be injected into the bridge
   table of the associated MAC-VRF on that PBB-EVPN PE. The learned B-
   MAC addresses MAY also be injected into the RIB/FIB tables of the
   associated the MAC-VRF on that has moved until BPP-EVPN PE. For seamless integration
   between PBB-EVPN and PBB-VPLS PEs, since these PWs belongs to the MAC age-out timer expires but
   this
   same split-horizon group as the MP2P EVPN service tunnels, then the
   B-MAC addresses learned and associated to the PWs will NOT be
   advertised in the control plane to any remote PBB-EVPN PEs. This is
   because every PBB-EVPN PE can send and receive traffic directly
   to/from every PBB-VPLS PE belonging to the typical behavior same VPN instance.

   - The C-MAC addresses learned over local Attachment Circuits (ACs) by
   an PBB-EVPN PE are learned in data-plane. For PBB-EVPN PEs, these C-
   MAC addresses are learned in I-component of VPLS PEs.

   When a host PBB-EVPN PEs and they are
   not advertised in the control-plane per [RFC7623].

   - The B-MAC addresses learned in the control plane via the BGP EVPN
   routes sent by remote PBB-EVPN PEs, are injected into the
   corresponding MAC-VRF table.

4.3 MAC Mobility

   In PBB-EVPN, a given B-MAC address moves can be learnt either over the BGP
   control-plane from a VPLS PE to an EVPN remote PBB-EVPN PE, then as
   soon as BUM or known-unicast traffic is initiated from that MAC
   address, in the MAC data-plane over a
   PW from a remote PBB-VPLS PE. There is learned and advertised in BGP to other EVPN PEs
   and MAC no mobility procedure is exercised among EVPN PEs. For BUM
   traffic, both EVPN and VPLS PES learn the new location of the moved associated with B-
   MAC address; however, if there is only known-unicast traffic, then
   only EVPN PEs learn addresses in this context. Hence, when the new location of same B-MAC address
   shows up behind both a remote PBB-VPLS PE as well as a PBB-EVPN PE,
   the MAC that has moved but
   not VPLS PEs. This local PE can result in black-holing of traffic sent from
   VPLS PEs destined to the MAC deduce that has moved until the MAC age-out
   timer expires but this it is an anomaly and notify the typical behavior of VPLS PEs.

4.3
   operator.

4.4 Multicast Operation

4.3.1

4.4.1 Ingress Replication
   The operation is per the procedures of Section 3.3.1 above for the
   scenario WITHOUT [MMRP]. The replication list is maintained per VPN
   instance rather than per I-SID.

4.3.2 P2MP Tunnel - Inclusive Tree

   The procedures for multicast operation on the EVPN PEs PBB-VPLS PE, using P2MP
   tunnels are outside of the scope of this document.

5 VPLS Integration with PBB-EVPN

5.1 Capability Discovery

   The procedures for capability discovery
   ingress replication, are per Section 3.1 above.

5.2 Forwarding Setup [RFC7041] and Unicast Operation [RFC7080].

   The procedures for multicast operation here is largely similar to that of on the PBB-EVPN integration
   with PBB-VPLS, with a few exceptions listed below: PE, for
   ingress replication, are as follows:

   - When a PW is setup between a The PBB-EVPN PE and builds a VPLS PE, it gets
   setup between replication sub-list per I-SID to all the I-component of
   remote PBB-EVPN PE and PEs in a given VPN instance as a result of the VSI
   exchange of VPLS PE. the EVPN IMET routes, as described in [RFC7623]. This
   will be referred to as sub-list A. It comprises MP2P service tunnels
   used for delivering PBB-EVPN BUM traffic.

   - The MAC mobility aspect is PBB-EVPN PE builds a replication sub-list per VPN instance to
   all the same remote PBB-VPLS PEs. This will be referred to as that of VPLS network or PBB-
   VPLS network since sub-list B.
   It comprises PWs from the PBB-EVPN PE in both cases question to all the host MAC (C-MAC) learning over
   MPLS/IP core is done via data-plane learning.

5.3 Multicast Operation

5.3.1 Ingress Replication remote
   PBB-VPLS PEs in the same VPN instance.

   - The operation is PBB-EVPN PE may further prune sub-list B, on a per I-SID basis,
   if [MMRP] is run over the procedures PBB-VPLS network. This will be referred to
   as sub-list C. This list comprises a pruned set of Section 3.3.1 above for the
   scenario WITHOUT [MMRP]. PWs in the
   sub-list B.

   The replication list is maintained per I-SID on the a given PBB-EVPN PEs PE will
   be the union of sub-list A and sub-list B if [MMRP] is NOT used, and per VPN instance on
   the VPLS PEs.

5.3.2 union of sub-list A and sub-list C if [MMRP] is used. Note that
   the PE must enable split-horizon over all the entries in the
   replication list, across both pseudowires and MP2P service tunnels.

4.4.2 P2MP Tunnel - Inclusive Tree

   The procedures for multicast operation on the PBB-EVPN PEs using P2MP
   tunnels are outside of the scope of this document.

6

5 Solution Advantages

   The solution for seamless integration of (PBB-)EVPN with (PBB-)VPLS
   has the following advantages:

   - When ingress replication is used for multi-destination traffic
   delivery, the solution reduces the scope of [MMRP] (which is a soft-
   state protocol) to only that of existing VPLS PEs, and uses the more
   robust BGP-based mechanism for multicast pruning among new EVPN PEs.

   - It is completely backward compatible.

   - New PEs can leverage the extensive multi-homing mechanisms and
   provisioning simplifications of PBB-EVPN:

      a. Auto-sensing of MHN / MHD
      b. Auto-discovery of redundancy group
      c. Auto-provisioning in DF election and VLAN carving

7

6 Security Considerations

   No new security considerations beyond those for VPLS and EVPN.

8

7  IANA Considerations

   This document has no actions for IANA.

9

8  References

9.1

8.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI
              10.17487/RFC2119, March <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8077] Martini, et al., "Pseudowire Setup and Maintenance using
              the Label Distribution Protocol", RFC 8077, February 2017.

   [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432,
              February, 2015.

   [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with
              Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015.

   [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, January 2007, <http://www.rfc-
              editor.org/info/rfc4761>.

   [RFC4762]  Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
              Signaling", RFC 4762, January 2007, <http://www.rfc-
              editor.org/info/rfc4762>.

   [RFC6074] Rosen et al., "Provisioning, Auto-Discovery, and Signaling
              in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074,
              January 2011.

9.2

8.2  Informative References

   [MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area
   networks - Media Access Control (MAC) Bridges and Virtual Bridged
   Local Area Networks", IEEE Std 802.1Q, 2013.

   [RFC7041] Balus et al., "Extensions to VPLS PE model for Provider
   Backbone Bridging", RFC 7041, November 2013.

   [RFC7080] Sajassi et al., "VPLS Interoperability with Provider
   Backbone Bridges", RFC 7080, December, 2013.

   [IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area
   networks - Media Access Control (MAC) Bridges and Virtual Bridged
   Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI
   10.1109/IEEESTD.2011.6009146.

   [RFC4684] Marques et al., "Constrained Route Distribution for Border
   Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet
   Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November,
   2006.

Authors' Addresses

   Ali Sajassi
   Cisco
   Email: sajassi@cisco.com

   Samer Salam
   Cisco
   Email: ssalam@cisco.com

   Nick Del Regno
   Verizon
   Email: nick.delregno@verizon.com

   Jorge Rabadan
   Nokia
   Email: jorge.rabadan@nokia.com