BESS Workgroup                                       A. Sajassi (Editor)
INTERNET-DRAFT                                                  S. Salam
Intended Status: Standard Track                                    Cisco
                                                            N. Del Regno
                                                                 Verizon
                                                              J. Rabadan
                                                                   Nokia

Expires: July 31, 2019                                  January 31, 2019


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


Abstract

   This document specifies mechanisms for backward compatibility of
   Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB-
   EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider
   Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides
   mechanisms for seamless integration of these two technologies in the
   same MPLS/IP network on a per-VPN-instance basis. Implementation of
   this document enables service providers to introduce EVPN/PBB-EVPN
   PEs in their brown-field deployments of VPLS/PBB-VPLS networks. This
   document specifies control-plane and forwarding behavior needed for
   auto-discovery of a VPN instance, multicast and unicast operation, as
   well as MAC-mobility operation in order to enable seamless
   integration between EVPN and VPLS PEs as well as between PBB-VPLS and
   PBB-EVPN PEs.


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



Sajassi et al.           Expires July 31, 2019                  [Page 1]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   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
     1.1.  Specification of Requirements  . . . . . . . . . . . . . .  5
     1.2.  Terms and Abbreviations  . . . . . . . . . . . . . . . . .  5
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . .  8
     3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . .  8
     3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . .  8
     3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.4 Multicast Operation  . . . . . . . . . . . . . . . . . . . . 10
       3.4.1 Ingress Replication  . . . . . . . . . . . . . . . . . . 10
       3.4.2 P2MP Tunnel  . . . . . . . . . . . . . . . . . . . . . . 11
   4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 11
     4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 11
     4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 11
     4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.4 Multicast Operation  . . . . . . . . . . . . . . . . . . . . 13
       4.4.1 Ingress Replication  . . . . . . . . . . . . . . . . . . 13
       4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 14
   5 Security Considerations  . . . . . . . . . . . . . . . . . . . . 14
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1  Normative References  . . . . . . . . . . . . . . . . . . . 14
     7.2  Informative References  . . . . . . . . . . . . . . . . . . 15



Sajassi et al.           Expires July 31, 2019                  [Page 2]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15


















































Sajassi et al.           Expires July 31, 2019                  [Page 3]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


1  Introduction

   Virtual Private LAN Service (VPLS) and Provider Backbone Bridging
   VPLS (PBB-VPLS) are widely-deployed Layer-2 VPN (L2VPN) technologies.
   Many service providers who are looking at adopting Ethernet VPN
   (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) want to
   preserve their investment in the VPLS and PBB-VPLS networks. Hence,
   they require mechanisms by which EVPN and PBB-EVPN technologies can
   be introduced into their brown-field VPLS and 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.
   Throughout this document, we use the term (PBB-)EVPN to correspond to
   both EVPN and PBB-EVPN and we use the term (PBB-)VPLS to correspond
   to both VPLS and PBB-VPLS. This document specifies control-plane and
   forwarding behavior needed for auto-discovery of a VPN instance,
   multicast and unicast operations, as well as MAC-mobility operation
   in order to enable seamless integration between (PBB-)EVPN Provider
   Edge(PE) devices and (PBB-)VPLS PEs.

                            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 & (PBB-)VPLS

   Section 2 provides the details of the requirements. Section 3
   specifies procedures for the seamless integration of VPLS and EVPN
   networks. And section 4 specifies procedures for the seamless
   integration of PBB-VPLS and PBB-EVPN networks.

   It should be noted that the scenarios for PBB-VPLS integration with
   EVPN and VPLS integration with PBB-EVPN are not covered in this
   document because there haven't been any requirements from service
   providers for these scenarios. The reason for that is that



Sajassi et al.           Expires July 31, 2019                  [Page 4]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   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.
   Furthermore, the evolution path from VPLS is expected to be towards
   EVPN.

   The seamless integration solution described in this document has the
   following attributes:

   - 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 of Designated Forwarder election and
         VLAN carving

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

   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

   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.



Sajassi et al.           Expires July 31, 2019                  [Page 5]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


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

   MAC address: Media Access Control address

   C-MAC address: Customer MAC address - e.g., host or CE's MAC address

   B-MAC address: Backbone MAC address - e.g., PE's MAC address

   Ethernet segment (ES): Refers to the set of Ethernet links that
   connects a customer site (device or network) to one or more PEs.

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

   FEC: Forwarding Equivalence Class

   LSP: Label Switched Path

   MHD: Multi-Homed Device

   MHN: Multi-Homed Network

   P2MP:  Point to Multipoint - a P2MP LSP typically refers to a LSP for
   multicast traffic

   MP2P: Multipoint to Point - a MP2P LSP typically refers to a LSP for
   unicast traffic as the result of downstream-assigned label

   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.




Sajassi et al.           Expires July 31, 2019                  [Page 6]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   (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. This document uses
   this abbreviation when a given description applies to both
   technologies.

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

   PW: Pseudowire

   I-SID: Ethernet Services Instance Identifier


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 Provider Edge devices (PEs).

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

   3. The solution must allow for the co-existence of PE devices 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 the
   MHD or MHN is connected to (PBB-)EVPN PEs.

   6. The support of All-Active redundancy mode across both (PBB-)EVPN
   PEs and (PBB-)VPLS PEs is outside the scope of this document. All-
   Active redundancy is not applicable to VPLS and PBB-VPLS. Therefore,
   when EVPN (or PBB-EVPN) PEs need to operate seamlessly with VPLS (or
   PBB-VPLS) PEs, then they MUST use a redundancy mode that is
   applicable to VPLS (or PBB-VPLS). This redundancy mode is Single-
   Active.





Sajassi et al.           Expires July 31, 2019                  [Page 7]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


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

3 VPLS Integration with EVPN

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

3.1 Capability Discovery

   The EVPN PEs MUST advertise both the BGP VPLS Auto-Discovery (A-D)
   route as well as the BGP EVPN Inclusive Multicast Ethernet Tag (IMET)
   route for a given VPN instance. The VPLS PEs only advertise the BGP
   VPLS A-D route, per the procedures specified in [RFC4761], [RFC4762]
   and [RFC6074]. The operator may decide to use the same Route Target
   (RT) to identify a VPN on both EVPN and VPLS networks. In this case,
   when a VPLS PE receives the EVPN IMET route, it 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 VPLS network and
   another for EVPN network and employ RT-constrained [RFC4684] in order
   to prevent BGP EVPN routes from reaching the VPLS PEs.

   When an EVPN PE receives both a VPLS A-D route as well as an EVPN
   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 EVPN capable PEs
   discover other EVPN capable PEs in addition to the VPLS-only PEs for
   that VPN instance. Furthermore, all the VPLS-only PEs will discover
   the EVPN PEs as if they were standard VPLS PEs. In other words, when
   the discovery phase is complete, the EVPN PEs will have discovered
   all the PEs in the VPN instance along with their associated
   capability (EVPN or VPLS-only), whereas the VPLS PEs will have
   discovered all the PEs in the VPN instance as if they were all VPLS-
   only PEs.


3.2 Forwarding Setup and Unicast Operation

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




Sajassi et al.           Expires July 31, 2019                  [Page 8]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


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

   - The EVPN PE MUST establish a PW to each remote PE from which it has
   received only a VPLS A-D route for the corresponding VPN instance,
   and MUST set up the label stack corresponding to the PW FEC. For
   seamless integration between EVPN and VPLS PEs, the PW that is setup
   between a pair of VPLS and EVPN PEs is between the VSI of the VPLS PE
   and the MAC-VRF of the EVPN PE.

   - The EVPN PE MUST set up the label stack corresponding to the MP2P
   VPN unicast FEC to any remote PE that has advertised EVPN IMET route.

   - If an EVPN PE receives a VPLS A-D route from a given PE, it sets up
   a PW to that PE. If it then receives an EVPN IMET route from the same
   PE, then the EVPN PE MUST bring that PW operationally down.

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

   - In case VPLS A-D 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 an EVPN PE receives an EVPN IMET route
   from a PE to which a PW exists, the EVPN PE MUST bring the PW
   operationally down.

   When the EVPN PE receives traffic over the VPLS PWs, it learns the
   associated C-MAC addresses in the data-plane. The C-MAC addresses
   learned over these PWs MUST be injected into the bridge table of the
   associated MAC-VRF on that EVPN PE. The learned C-MAC addresses MAY
   also be injected into the 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 ([RFC4761] and
   [RFC4762]) as the MP2P EVPN service tunnels, then the C-MAC addresses
   learned and associated to the PWs MUST NOT be advertised in the
   control plane to any remote EVPN PEs. This is because every EVPN PE
   can send and receive traffic directly to/from every VPLS PE belonging
   to the same VPN instance and thus every EVPN PE can learn the C-MAC
   addresses over the corresponding PWs directly.

   The C-MAC addresses learned over local Attachment Circuits (ACs) by
   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 the control-plane using BGP EVPN routes. Furthermore,
   the C-MAC addresses learned in the control plane via the BGP EVPN
   routes sent by remote EVPN PEs, are injected into the corresponding
   MAC-VRF table.



Sajassi et al.           Expires July 31, 2019                  [Page 9]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   In case of a link failure in a single-active Ethernet Segment, the
   EVPN PEs MUST perform both of the following tasks:

   a) send a BGP mass-withdraw to the EVPN peers

   b) follow existing VPLS MAC Flush procedures with the VPLS peers.

3.3 MAC Mobility

   In EVPN, host addresses (C-MAC addresses) can move around among EVPN
   PEs or even between EVPN and VPLS PEs.

   When a C-MAC address moves from an EVPN PE to a VPLS PE, then as soon
   as Broadcast/Unknown-unicast/Multicast (BUM) traffic is initiated
   from that MAC address, it is flooded to all other PEs (both VPLS and
   EVPN PEs) and the receiving PEs update their MAC tables (VSI or MAC-
   VRF). The EVPN PEs do not advertise the C-MAC addresses learned over
   the PW to each other because every EVPN PE learns them directly over
   its associated PW to that VPLS PE. If only known-unicast traffic is
   initiated from the moved C-MAC address toward a known C-MAC, then
   this can result in black-holing of traffic destined to the C-MAC that
   has moved until there is a BUM traffic originated with the moved C-
   MAC address as the source MAC address (e.g., as a result of MAC age-
   out timer expires). Such black-holing happens for traffic destined to
   the moved C-MAC from both EVPN and VPLS PEs. It should be noted that
   such black-holing behavior is typical for VPLS PEs.

   When a C-MAC address moves from a VPLS PE to an EVPN PE, then as soon
   as any traffic is initiated from that C-MAC address, the 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 learn the new location of the moved C-MAC address; however,
   if there is only known-unicast traffic, then only EVPN PEs learn the
   new location of the C-MAC that has moved but not VPLS PEs. This can
   result in black-holing of traffic sent from VPLS PEs destined to the
   C-MAC that has moved until there is a BUM traffic originated with the
   moved C-MAC address as the source MAC address (e.g., as a result of
   MAC age-out timer expires). Such black-holing happens for traffic
   destined to the moved C-MAC for only VPLS PEs but not for EVPN PEs.
   It should be noted that such black-holing behavior is typical for
   VPLS PEs.


3.4 Multicast Operation

3.4.1 Ingress Replication

   The procedures for multicast operation on the VPLS PE, using ingress



Sajassi et al.           Expires July 31, 2019                 [Page 10]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   replication, are per [RFC4761], [RFC4762], and [RFC7080].

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

   - The EVPN PE builds a replication sub-list to all the remote EVPN
   PEs per EVPN instance as the result of the exchange of the EVPN IMET
   routes per [RFC7432]. This will be referred to as sub-list A. It
   comprises MP2P service tunnels (for ingress replication) used for
   delivering EVPN BUM traffic [RFC7432].

   - The EVPN PE builds a replication sub-list per VPLS instance to all
   the remote VPLS PEs. This will be referred to as sub-list B. It
   comprises PWs from the EVPN PE in question to all the remote VPLS PEs
   in the same VPLS instance.

   The replication list, maintained per VPN instance, on a given EVPN PE
   will be the union of sub-list A and sub-list B. The EVPN 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 using P2MP
   tunnels are outside of the scope of this document.



4 PBB-VPLS Integration with PBB-EVPN

   In order to 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 are per [RFC8077] and [RFC7080].

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




Sajassi et al.           Expires July 31, 2019                 [Page 11]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   - The PBB-EVPN PE MUST establish a PW to each remote PBB-VPLS PE from
   which it has received only a VPLS A-D route for the corresponding VPN
   instance, and MUST set up the label stack corresponding to the PW
   FEC. For seamless integration between PBB-EVPN and PBB-VPLS PEs, the
   PW that is setup between a 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].

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

   - If a PBB-EVPN PE receives a VPLS A-D route from a given PE, it sets
   up a PW to that PE. If it then receives an EVPN IMET route from the
   same PE, then the PBB-EVPN PE MUST bring that PW operationally down.

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

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

   - When the PBB-EVPN PE receives traffic 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 BPP-EVPN PE. For seamless integration
   between PBB-EVPN and PBB-VPLS PEs, since these PWs belongs to the
   same split-horizon group as the MP2P EVPN service tunnels, then the
   B-MAC addresses learned and associated to the PWs MUST 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 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 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.




Sajassi et al.           Expires July 31, 2019                 [Page 12]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   In case of a link failure in a single-active Ethernet Segment, the
   PBB-EVPN PEs MUST perform both of the following tasks:


   a) send a BGP B-MAC withdraw message to the PBB-EVPN peers OR MAC
   advertisement with MAC Mobility extended community

   b) follow existing VPLS MAC Flush procedures with the PBB-VPLS peers


4.3 MAC Mobility

   In PBB-EVPN, a given B-MAC address can be learned either over the BGP
   control-plane from a remote PBB-EVPN PE, or in the data-plane over a
   PW from 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 as well as a PBB-EVPN PE,
   the local PE can deduce that it is an anomaly and SHOULD notify the
   operator.

4.4 Multicast Operation

4.4.1 Ingress Replication

   The procedures for multicast operation on the PBB-VPLS PE, using
   ingress replication, are per [RFC7041] and [RFC7080].

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

   - The PBB-EVPN PE builds a replication sub-list per I-SID to all the
   remote PBB-EVPN PEs in a given VPN instance as a result of the
   exchange of 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 PBB-EVPN PE builds a replication sub-list per VPN instance to
   all the remote PBB-VPLS PEs. This will be referred to as sub-list B.
   It comprises PWs from the PBB-EVPN PE in question to all the remote
   PBB-VPLS PEs in the same VPN instance.

   - The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis,
   by running [MMRP] over the PBB-VPLS network. This will be referred to
   as sub-list C. This list comprises a pruned set of the PWs in the
   sub-list B.

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



Sajassi et al.           Expires July 31, 2019                 [Page 13]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   the 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.


5 Security Considerations

   All the security considerations in [RFC4761], [RFC4762], [RFC7080],
   [RFC7432], and [RFC7623] apply directly to this document because this
   document leverages the control plane and the data plane procedures
   described in these RFCs.

   This document does not introduce any new security considerations
   beyond that of the above RFCs because the advertisements and
   processing of MAC addresses in BGP follow that of [RFC7432] and
   processing of MAC addresses learned over PWs follow that of
   [RFC4761], [RFC4762], and [RFC7080].


6  IANA Considerations

   This document has no actions for IANA.


7  References

7.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.



Sajassi et al.           Expires July 31, 2019                 [Page 14]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   [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>.

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

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


7.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.

   [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



Sajassi et al.           Expires July 31, 2019                 [Page 15]


INTERNET DRAFT  draft-ietf-bess-evpn-vpls-seamless-integ    Jan 31, 2019


   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



































Sajassi et al.           Expires July 31, 2019                 [Page 16]