draft-ietf-bess-evpn-vpls-seamless-integ-07.txt   rfc8560.txt 
BESS Workgroup A. Sajassi (Editor) Internet Engineering Task Force (IETF) A. Sajassi, Ed.
INTERNET-DRAFT S. Salam Request for Comments: 8560 S. Salam
Intended Status: Standard Track Cisco Category: Standards Track Cisco
N. Del Regno ISSN: 2070-1721 N. Del Regno
Verizon Verizon
J. Rabadan J. Rabadan
Nokia Nokia
May 2019
Expires: July 31, 2019 January 31, 2019 Seamless Integration of Ethernet VPN (EVPN) with
Virtual Private LAN Service (VPLS) and
(PBB-)EVPN Seamless Integration with (PBB-)VPLS Their Provider Backbone Bridge (PBB) Equivalents
draft-ietf-bess-evpn-vpls-seamless-integ-07
Abstract Abstract
This document specifies mechanisms for backward compatibility of This document specifies mechanisms for backward compatibility of
Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB- Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN
EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider (PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) and
Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides Provider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides
mechanisms for seamless integration of these two technologies in the mechanisms for the seamless integration of these two technologies in
same MPLS/IP network on a per-VPN-instance basis. Implementation of the same MPLS/IP network on a per-VPN-instance basis. Implementation
this document enables service providers to introduce EVPN/PBB-EVPN of this document enables service providers to introduce EVPN/PBB-EVPN
PEs in their brown-field deployments of VPLS/PBB-VPLS networks. This Provider Edges (PEs) in their brownfield deployments of VPLS/PBB-VPLS
document specifies control-plane and forwarding behavior needed for networks. This document specifies the control-plane and forwarding
auto-discovery of a VPN instance, multicast and unicast operation, as behavior needed for the auto-discovery of the following: 1) a VPN
well as MAC-mobility operation in order to enable seamless instance, 2) multicast and unicast operation, and 3) a Media Access
integration between EVPN and VPLS PEs as well as between PBB-VPLS and Control (MAC) mobility operation. This enables seamless integration
PBB-EVPN PEs. 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 Status of This Memo
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 This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
http://www.ietf.org/1id-abstracts.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8560.
Copyright and License Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 5 1.1. Specification of Requirements . . . . . . . . . . . . . . 4
1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 8 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 8 3. VPLS Integration with EVPN . . . . . . . . . . . . . . . . . 7
3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 8 3.1. Capability Discovery . . . . . . . . . . . . . . . . . . 7
3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Forwarding Setup and Unicast Operation . . . . . . . . . 8
3.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 10 3.3. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 10 3.4. Multicast Operation . . . . . . . . . . . . . . . . . . . 10
3.4.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 11 3.4.1. Ingress Replication . . . . . . . . . . . . . . . . . 10
4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 11 3.4.2. P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . 10
4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 11 4. PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . 10
4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 11 4.1. Capability Discovery . . . . . . . . . . . . . . . . . . 11
4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Forwarding Setup and Unicast Operation . . . . . . . . . 11
4.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 13 4.3. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . 12
4.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 13 4.4. Multicast Operation . . . . . . . . . . . . . . . . . . . 12
4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 14 4.4.1. Ingress Replication . . . . . . . . . . . . . . . . . 12
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 4.4.2. P2MP Tunnel: Inclusive Tree . . . . . . . . . . . . . 13
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1 Normative References . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2 Informative References . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1 Introduction 1. Introduction
Virtual Private LAN Service (VPLS) and Provider Backbone Bridging Virtual Private LAN Service (VPLS) and Provider Backbone Bridging
VPLS (PBB-VPLS) are widely-deployed Layer-2 VPN (L2VPN) technologies. VPLS (PBB-VPLS) are widely deployed Layer 2 VPN (L2VPN) technologies.
Many service providers who are looking at adopting Ethernet VPN Many service providers who are looking at adopting Ethernet VPN
(EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) want to (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) want to
preserve their investment in the VPLS and PBB-VPLS networks. Hence, preserve their investments in the VPLS and PBB-VPLS networks. Hence,
they require mechanisms by which EVPN and PBB-EVPN technologies can they require mechanisms by which EVPN and PBB-EVPN technologies can
be introduced into their brown-field VPLS and PBB-VPLS networks be introduced into their brownfield VPLS and PBB-VPLS networks
without requiring any upgrades (software or hardware) to these without requiring any upgrades (software or hardware) to these
networks. This document specifies procedures for the seamless networks. This document specifies procedures for the seamless
integration of the two technologies in the same MPLS/IP network. integration of the two technologies in the same MPLS/IP network.
Throughout this document, we use the term (PBB-)EVPN to correspond to Throughout this document, we use the term "(PBB-)EVPN" to correspond
both EVPN and PBB-EVPN and we use the term (PBB-)VPLS to correspond to both EVPN and PBB-EVPN, and we use the term "(PBB-)VPLS" to
to both VPLS and PBB-VPLS. This document specifies control-plane and correspond to both VPLS and PBB-VPLS. This document specifies the
forwarding behavior needed for auto-discovery of a VPN instance, control-plane and forwarding behavior needed for 1) auto-discovery of
multicast and unicast operations, as well as MAC-mobility operation a VPN instance, 2) multicast and unicast operations, and 3) a MAC
in order to enable seamless integration between (PBB-)EVPN Provider mobility operation. This enables seamless integration between
Edge(PE) devices and (PBB-)VPLS PEs. (PBB-)EVPN Provider Edge (PE) devices and (PBB-)VPLS PEs.
VPLS PE VPLS PE
+---+ +---+
|PE1| |PE1|
+---+ +---+
/ /
EVPN/VPLS PE +---------------+ EVPN/VPLS PE EVPN/VPLS PE +---------------+ EVPN/VPLS PE
+---+ | | +---+ +---+ | | +---+
|PE4|----| MPLS/IP |---|PE5| |PE4|----| MPLS/IP |---|PE5|
+---+ | Core | +---+ +---+ | Core | +---+
| | | |
+---------------+ +---------------+
/ \ / \
+---+ +---+ +---+ +---+
|PE2| |PE3| |PE2| |PE3|
+---+ +---+ +---+ +---+
VPLS PE VPLS PE VPLS PE VPLS PE
Figure 1: Seamless Integration of (PBB-)EVPN & (PBB-)VPLS Figure 1: Seamless Integration of (PBB-)EVPN and (PBB-)VPLS
Section 2 provides the details of the requirements. Section 3 Section 2 provides the details of the requirements. Section 3
specifies procedures for the seamless integration of VPLS and EVPN specifies procedures for the seamless integration of VPLS and EVPN
networks. And section 4 specifies procedures for the seamless networks. Section 4 specifies procedures for the seamless
integration of PBB-VPLS and PBB-EVPN networks. integration of PBB-VPLS and PBB-EVPN networks.
It should be noted that the scenarios for PBB-VPLS integration with It should be noted that the scenarios for both PBB-VPLS integration
EVPN and VPLS integration with PBB-EVPN are not covered in this with EVPN and VPLS integration with PBB-EVPN are not covered in this
document because there haven't been any requirements from service document because there haven't been any requirements from service
providers for these scenarios. The reason for that is that providers for these scenarios; deployments that employ PBB-VPLS
deployments which employ PBB-VPLS typically require PBB encapsulation typically require PBB encapsulation for various reasons. Hence, it
for various reasons. Hence, it is expected that for those deployments is expected that for those deployments, the evolution path would move
the evolution path would be from PBB-VPLS towards PBB-EVPN. from PBB-VPLS towards PBB-EVPN. Furthermore, the evolution path from
Furthermore, the evolution path from VPLS is expected to be towards VPLS is expected to move towards EVPN.
EVPN.
The seamless integration solution described in this document has the The seamless integration solution described in this document has the
following attributes: following attributes:
- When ingress replication is used for multi-destination traffic - When ingress replication is used for multi-destination traffic
delivery, the solution reduces the scope of [MMRP] (which is a soft- 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 state protocol defined in Clause 10 of [IEEE.802.1Q]) to only that
robust BGP-based mechanism for multicast pruning among new EVPN PEs. of existing VPLS PEs and uses the more robust BGP-based mechanism
for multicast pruning among new EVPN PEs.
- It is completely backward compatible. - It is completely backward compatible.
- New PEs can leverage the extensive multi-homing mechanisms and - New PEs can leverage the extensive multihoming mechanisms and
provisioning simplifications of (PBB-)EVPN: provisioning simplifications of (PBB-)EVPN:
a. Auto-sensing of MHN / MHD
b. Auto-discovery of redundancy group (a) Auto-sensing of Multihomed Networks (MHNs) / Multihomed
c. Auto-provisioning of Designated Forwarder election and Devices (MHDs)
VLAN carving
(b) Auto-discovery of redundancy groups
(c) Auto-provisioning of Designated Forwarder election and VLAN
carving
1.1. Specification of Requirements 1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Terms and Abbreviations 1.2. Abbreviations
Broadcast Domain: In a bridged network, the broadcast domain B-MAC: Backbone MAC, e.g., the PE's MAC address
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 C-MAC: Customer MAC, e.g., a host or CE's MAC address
RIB: Routing Information Base - An instantiation of a routing table CE: A Customer Edge device, e.g., a host, router, or switch
on a MAC-VRF
FIB: Forwarding Information Base - An instantiation of a forwarding ES: Ethernet Segment -- refers to the set of Ethernet links
table on a MAC-VRF that connects a customer site (device or network) to one
or more PEs
CE: A Customer Edge device, e.g., a host, router, or switch. FEC: Forwarding Equivalence Class
FIB: Forwarding Information Base -- an instantiation of a
forwarding table on a MAC-VRF
MAC-VRF: A Virtual Routing and Forwarding table for Media Access I-SID: Service Instance Identifier
Control (MAC) addresses on an EVPN PE.
MAC address: Media Access Control address LSP: Label Switched Path
C-MAC address: Customer MAC address - e.g., host or CE's MAC address MAC: Media Access Control
B-MAC address: Backbone MAC address - e.g., PE's MAC address MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on an EVPN PE
Ethernet segment (ES): Refers to the set of Ethernet links that MHD: Multihomed Device
connects a customer site (device or network) to one or more PEs.
Ethernet Tag: An Ethernet Tag identifies a particular broadcast MHN: Multihomed Network
domain, e.g., a VLAN. An EVPN instance consists of one or more
broadcast domains
FEC: Forwarding Equivalence Class MP2P: Multipoint to Point -- an MP2P LSP typically refers to an
LSP for unicast traffic as the result of a downstream-
assigned label
LSP: Label Switched Path P2MP: Point to Multipoint -- a P2MP LSP typically refers to an
LSP for multicast traffic
MHD: Multi-Homed Device PBB: Provider Backbone Bridge
MHN: Multi-Homed Network (PBB-)EVPN: Both PBB-EVPN and EVPN -- this document uses this
abbreviation when a given description applies to both
technologies
P2MP: Point to Multipoint - a P2MP LSP typically refers to a LSP for (PBB-)VPLS: Both PBB-VPLS and VPLS -- this document uses this
multicast traffic abbreviation when a given description applies to both
technologies
MP2P: Multipoint to Point - a MP2P LSP typically refers to a LSP for PE: Provider Edge device
unicast traffic as the result of downstream-assigned label
PBB: Provider Backbone Bridge PW: Pseudowire
PE: Provider Edge device RIB: Routing Information Base -- an instantiation of a routing
table on a MAC-VRF
VSI: Virtual Switch Instance VSI: Virtual Switch Instance
VPLS: Virtual Private LAN Service VPLS: Virtual Private LAN Service
Single-Active Redundancy Mode: When only a single PE, among all the VPLS A-D: Virtual Private LAN Service with BGP-based auto-discovery
PEs attached to an Ethernet segment, is allowed to forward traffic as in [RFC6074]
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 1.3. Terminology
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 All-Active redundancy mode: When all PEs attached to an Ethernet
this abbreviation when a given description applies to both segment are allowed to forward known unicast traffic to/from that
technologies. Ethernet segment for a given VLAN, then the Ethernet segment is
defined as operating in All-Active redundancy mode.
(PBB-)VPLS: refers to both, PBB-VPLS and VPLS. This document uses Bridge table: An instantiation of a broadcast domain on a MAC-VRF
this abbreviation when a given description applies to both (VPN Routing and Forwarding).
technologies.
VPLS A-D: refers to Virtual Private LAN Services with BGP-based Auto Broadcast domain: In a bridged network, the broadcast domain
Discovery as in [RFC6074]. 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.1Q].
PW: Pseudowire Ethernet Tag: An Ethernet Tag identifies a particular broadcast
domain, e.g., a VLAN. An EVPN instance consists of one or more
broadcast domains.
I-SID: Ethernet Services Instance Identifier 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 as operating in Single-Active redundancy mode.
2. Requirements 2. Requirements
Following are the key requirements for backward compatibility between The following are the key requirements for backward compatibility
(PBB-)EVPN and (PBB-)VPLS: between (PBB-)EVPN and (PBB-)VPLS:
1. The solution must allow for staged migration towards (PBB-)EVPN on 1. The solution must allow for staged migration towards (PBB-)EVPN
a site-by-site basis per VPN instance - e.g., new EVPN sites to be on a site-by-site basis per VPN instance, e.g., new EVPN sites to
provisioned on (PBB-)EVPN Provider Edge devices (PEs). be provisioned on (PBB-)EVPN Provider Edge devices (PEs).
2. The solution must not require any changes to existing VPLS or PBB- 2. The solution must not require any changes to existing VPLS or
VPLS PEs, not even a software upgrade. PBB-VPLS PEs, not even a software upgrade.
3. The solution must allow for the co-existence of PE devices running 3. The solution must allow for the coexistence of PE devices running
(PBB-)EVPN and (PBB-)VPLS for the same VPN instance and single-homed (PBB-)EVPN and (PBB-)VPLS for the same VPN instance and single-
segments. homed segments.
4. The solution must support single-active redundancy of multi-homed 4. The solution must support single-active redundancy of multihomed
networks and multi-homed devices for (PBB-)EVPN PEs. networks and multihomed devices for (PBB-)EVPN PEs.
5. In case of single-active redundancy, the participant VPN instances 5. In cases of single-active redundancy, the participant VPN
may span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as the instances may span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs
MHD or MHN is connected to (PBB-)EVPN 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 6. Support of the All-Active redundancy mode across both (PBB-)EVPN
PEs and (PBB-)VPLS PEs is outside the scope of this document. All- PEs and (PBB-)VPLS PEs is outside the scope of this document.
Active redundancy is not applicable to VPLS and PBB-VPLS. Therefore, All-Active redundancy is not applicable to VPLS and PBB-VPLS.
when EVPN (or PBB-EVPN) PEs need to operate seamlessly with VPLS (or Therefore, when EVPN (or PBB-EVPN) PEs need to operate seamlessly
PBB-VPLS) PEs, then they MUST use a redundancy mode that is with VPLS (or PBB-VPLS) PEs, they MUST use a redundancy mode that
applicable to VPLS (or PBB-VPLS). This redundancy mode is Single- is applicable to VPLS (or PBB-VPLS). This redundancy mode is
Active. Single-Active.
These requirements collectively allow for the seamless insertion of These requirements collectively allow for the seamless insertion of
the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments. (PBB-)EVPN technology into brownfield (PBB-)VPLS deployments.
3 VPLS Integration with EVPN 3. VPLS Integration with EVPN
In order to support seamless integration with VPLS PEs, this document In order to support seamless integration with VPLS PEs, this document
requires that VPLS PEs support VPLS A-D per [RFC6074] and EVPN PEs requires that VPLS PEs support VPLS A-D per [RFC6074], and it
support both BGP EVPN routes per [RFC7432] and VPLS A-D per requires EVPN PEs to support both BGP EVPN routes per [RFC7432] and
[RFC6074]. All the logic for seamless integration shall reside on the VPLS A-D per [RFC6074]. All the logic for seamless integration shall
EVPN PEs. If a VPLS instance is setup without the use of VPLS A-D, it reside on the EVPN PEs. If a VPLS instance is set up without the use
is still possible (but cumbersome) for EVPN PEs to integrate into of VPLS A-D, it is still possible (but cumbersome) for EVPN PEs to
that VPLS instance by manually configuring Pseudowires (PWs) to all integrate that VPLS instance by manually configuring pseudowires
the VPLS PEs in that instance (i.e., the integration is no longer (PWs) to all the VPLS PEs in that instance (i.e., the integration is
seamless). no longer seamless).
3.1 Capability Discovery 3.1. Capability Discovery
The EVPN PEs MUST advertise both the BGP VPLS Auto-Discovery (A-D) 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 as well as the BGP EVPN Inclusive Multicast Ethernet Tag (IMET)
route for a given VPN instance. The VPLS PEs only advertise the BGP route for a given VPN instance. The VPLS PEs only advertise the BGP
VPLS A-D route, per the procedures specified in [RFC4761], [RFC4762] VPLS A-D route, per the procedures specified in [RFC4761], [RFC4762]
and [RFC6074]. The operator may decide to use the same Route Target 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, (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 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 basis that it belongs to an unknown Subsequent Address Family
choose to use two RTs - one to identify the VPN on VPLS network and Identifier (SAFI). However, the operator may choose to use two RTs
another for EVPN network and employ RT-constrained [RFC4684] in order -- one to identify the VPN on the VPLS network and another for the
EVPN network -- and employ RT Constrain mechanisms [RFC4684] in order
to prevent BGP EVPN routes from reaching the VPLS PEs. 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 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 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 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 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 discover other EVPN-capable PEs in addition to the VPLS-only PEs for
that VPN instance. Furthermore, all the VPLS-only PEs will discover 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 EVPN PEs as if they were standard VPLS PEs. In other words, when
the discovery phase is complete, the EVPN PEs will have discovered the discovery phase is complete, the EVPN PEs will have discovered
all the PEs in the VPN instance along with their associated all the PEs in the VPN instance along with their associated
capability (EVPN or VPLS-only), whereas the VPLS PEs will have 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- discovered all the PEs in the VPN instance as if they were all VPLS-
only PEs. only PEs.
3.2 Forwarding Setup and Unicast Operation 3.2. Forwarding Setup and Unicast Operation
The procedures for forwarding state setup and unicast operation on The procedures for the forwarding state setup and unicast operation
the VPLS PE are per [RFC8077], [RFC4761], [RFC4762]. on the VPLS PE are per [RFC8077], [RFC4761], and [RFC4762].
The procedures for forwarding state setup and unicast operation on The procedures for forwarding state setup and unicast operation on
the EVPN PE are as follows: the EVPN PE are as follows:
- The EVPN PE MUST establish a PW to each remote PE from which it has - The EVPN PE MUST establish a PW to each remote PE from which it
received only a VPLS A-D route for the corresponding VPN instance, has received only a VPLS A-D route for the corresponding VPN
and MUST set up the label stack corresponding to the PW FEC. For instance and MUST set up the label stack corresponding to the PW
seamless integration between EVPN and VPLS PEs, the PW that is setup FEC. For seamless integration between EVPN and VPLS PEs, the PW
between a pair of VPLS and EVPN PEs is between the VSI of the VPLS PE that is set up between a pair of VPLS and EVPN PEs is between the
and the MAC-VRF of the EVPN PE. 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 - 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. VPN unicast FEC to any remote PE that has advertised an EVPN IMET
route.
- If an EVPN PE receives a VPLS A-D route from a given PE, it sets up - If an EVPN PE receives a VPLS A-D route from a given PE, it sets
a PW to that PE. If it then receives an EVPN IMET route from the same up a PW to that PE. If it then receives an EVPN IMET route from
PE, then the EVPN PE MUST bring that PW operationally down. the same PE, the EVPN PE MUST bring that PW operationally down.
- If an EVPN PE receives an EVPN IMET route followed by a VPLS A-D - 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 route from the same PE, then the EVPN PE will set up the PW but
keep it operationally down. MUST keep it operationally down.
- In case VPLS A-D is not used in some VPLS PEs, the EVPN PEs need to - In case VPLS A-D is not used in some VPLS PEs, the EVPN PEs need
be provisioned manually with PWs to those remote VPLS PEs for each to be provisioned manually with PWs to those remote VPLS PEs for
VPN instance. In that case, if an EVPN PE receives an EVPN IMET route each VPN instance. In that case, if an EVPN PE receives an EVPN
from a PE to which a PW exists, the EVPN PE MUST bring the PW IMET route from a PE to which a PW exists, the EVPN PE MUST bring
operationally down. the PW operationally down.
When the EVPN PE receives traffic over the VPLS PWs, it learns the 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 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 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 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 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, that EVPN PE. For seamless integration between EVPN and VPLS PEs,
since these PWs belong to the same split-horizon group ([RFC4761] and because these PWs belong to the same split-horizon group (see
[RFC4762]) as the MP2P EVPN service tunnels, then the C-MAC addresses [RFC4761] and [RFC4762]) as the MP2P EVPN service tunnels, the C-MAC
learned and associated to the PWs MUST NOT be advertised in the addresses learned and associated with the PWs MUST NOT be advertised
control plane to any remote EVPN PEs. This is because every EVPN PE in the control plane to any remote EVPN PEs. This is because every
can send and receive traffic directly to/from every VPLS PE belonging EVPN PE can send and receive traffic directly to/from every VPLS PE
to the same VPN instance and thus every EVPN PE can learn the C-MAC belonging to the same VPN instance; thus, every EVPN PE can learn the
addresses over the corresponding PWs directly. C-MAC addresses over the corresponding PWs directly.
The C-MAC addresses learned over local Attachment Circuits (ACs) by 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 an EVPN PE are learned in the data plane. For EVPN PEs, these C-MAC
addresses MUST be injected into the corresponding MAC-VRF and addresses MUST be injected into the corresponding MAC-VRF and
advertised in the control-plane using BGP EVPN routes. Furthermore, advertised in the control plane using BGP EVPN routes. Furthermore,
the C-MAC addresses learned in the control plane via the BGP EVPN the C-MAC addresses learned in the control plane via the BGP EVPN
routes sent by remote EVPN PEs, are injected into the corresponding routes sent by remote EVPN PEs are injected into the corresponding
MAC-VRF table. MAC-VRF table.
In case of a link failure in a single-active Ethernet Segment, the In case of a link failure in a single-active Ethernet segment, the
EVPN PEs MUST perform both of the following tasks: EVPN PEs MUST perform both of the following tasks:
a) send a BGP mass-withdraw to the EVPN peers 1. send a BGP mass withdraw to the EVPN peers
b) follow existing VPLS MAC Flush procedures with the VPLS peers. 2. follow existing VPLS MAC Flush procedures with the VPLS peers
3.3 MAC Mobility 3.3. MAC Mobility
In EVPN, host addresses (C-MAC addresses) can move around among EVPN In EVPN, host addresses (C-MAC addresses) can move around among EVPN
PEs or even between EVPN and VPLS PEs. 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 When a C-MAC address moves from an EVPN PE to a VPLS PE, as soon as
as Broadcast/Unknown-unicast/Multicast (BUM) traffic is initiated Broadcast, Unknown Unicast, and Multicast (BUM) traffic is initiated
from that MAC address, it is flooded to all other PEs (both VPLS and 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- EVPN PEs), and the receiving PEs update their MAC tables (VSI or
VRF). The EVPN PEs do not advertise the C-MAC addresses learned over MAC-VRF). The EVPN PEs do not advertise the C-MAC addresses learned
the PW to each other because every EVPN PE learns them directly over over the PW to each other because every EVPN PE learns them directly
its associated PW to that VPLS PE. If only known-unicast traffic is over its associated PW to that VPLS PE. If only known unicast
initiated from the moved C-MAC address toward a known C-MAC, then traffic is initiated from the moved C-MAC address toward a known
this can result in black-holing of traffic destined to the C-MAC that C-MAC, the result can be the black-holing of traffic destined to the
has moved until there is a BUM traffic originated with the moved C- C-MAC that has moved until there is BUM traffic that has been
MAC address as the source MAC address (e.g., as a result of MAC age- originated with the moved C-MAC address as the source MAC address
out timer expires). Such black-holing happens for traffic destined to (e.g., as a result of the MAC age-out timer expiring). Such
the moved C-MAC from both EVPN and VPLS PEs. It should be noted that black-holing happens for traffic destined to the moved C-MAC from
such black-holing behavior is typical for VPLS PEs. both EVPN and VPLS PEs and is typical for VPLS PEs.
When a C-MAC address moves from a VPLS PE to an EVPN PE, then as soon 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 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 learned and advertised in the BGP to other EVPN PEs, and the MAC
procedure is exercised among EVPN PEs. For BUM traffic, both EVPN and mobility procedure is performed among EVPN PEs. For BUM traffic,
VPLS PEs learn the new location of the moved C-MAC address; however, both EVPN and VPLS PEs learn the new location of the moved C-MAC
if there is only known-unicast traffic, then only EVPN PEs learn the address; however, if there is only known unicast traffic, then only
new location of the C-MAC that has moved but not VPLS PEs. This can EVPN PEs learn the new location of the C-MAC that has moved and not
result in black-holing of traffic sent from VPLS PEs destined to the VPLS PEs. This can result in the black-holing of traffic sent from
C-MAC that has moved until there is a BUM traffic originated with the VPLS PEs destined to the C-MAC that has moved until there is BUM
moved C-MAC address as the source MAC address (e.g., as a result of traffic originated with the moved C-MAC address as the source MAC
MAC age-out timer expires). Such black-holing happens for traffic address (e.g., as a result of the MAC age-out timer expiring). Such
destined to the moved C-MAC for only VPLS PEs but not for EVPN PEs. black-holing happens for traffic destined to the moved C-MAC for only
It should be noted that such black-holing behavior is typical for VPLS PEs but not for EVPN PEs and is typical for VPLS PEs.
VPLS PEs.
3.4 Multicast Operation 3.4. Multicast Operation
3.4.1 Ingress Replication 3.4.1. Ingress Replication
The procedures for multicast operation on the VPLS PE, using ingress The procedures for multicast operation on the VPLS PE using ingress
replication, are per [RFC4761], [RFC4762], and [RFC7080]. replication are per [RFC4761], [RFC4762], and [RFC7080].
The procedures for multicast operation on the EVPN PE, for ingress The procedures for multicast operation on the EVPN PE for ingress
replication, are as follows: replication are as follows:
- The EVPN PE builds a replication sub-list to all the remote EVPN - 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 PEs per EVPN instance as the result of the exchange of the EVPN
routes per [RFC7432]. This will be referred to as sub-list A. It IMET routes per [RFC7432]. This will be referred to as sub-list
comprises MP2P service tunnels (for ingress replication) used for A. It comprises MP2P service tunnels (for ingress replication)
delivering EVPN BUM traffic [RFC7432]. used for delivering EVPN BUM traffic [RFC7432].
- The EVPN PE builds a replication sub-list per VPLS instance to all - 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 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 comprises PWs from the EVPN PE in question to all the remote VPLS
in the same VPLS instance. PEs in the same VPLS instance.
The replication list, maintained per VPN instance, on a given EVPN PE 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 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, enable split horizon over all the entries in the replication list
across both PWs and MP2P service tunnels. across both PWs and MP2P service tunnels.
3.4.2 P2MP Tunnel 3.4.2. P2MP Tunnel
The procedures for multicast operation on the EVPN PEs using P2MP The procedures for multicast operation on the EVPN PEs using P2MP
tunnels are outside of the scope of this document. tunnels are outside of the scope of this document.
4 PBB-VPLS Integration with PBB-EVPN 4. PBB-VPLS Integration with PBB-EVPN
In order to support seamless integration between PBB-VPLS and PBB- In order to support seamless integration between PBB-VPLS and
EVPN PEs, this document requires that PBB-VPLS PEs support VPLS A-D PBB-EVPN PEs, this document requires that PBB-VPLS PEs support VPLS
per [RFC6074] and PBB-EVPN PEs support both BGP EVPN routes per 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 [RFC7432] and VPLS A-D per [RFC6074]. All the logic for this
integration shall reside on the PBB-EVPN PEs. seamless integration shall reside on the PBB-EVPN PEs.
4.1 Capability Discovery 4.1. Capability Discovery
The procedures for capability discovery are per Section 3.1 above. The procedures for capability discovery are per Section 3.1.
4.2 Forwarding Setup and Unicast Operation 4.2. Forwarding Setup and Unicast Operation
The procedures for forwarding state setup and unicast operation on The procedures for forwarding state setup and unicast operation on
the PBB-VPLS PE are per [RFC8077] and [RFC7080]. the PBB-VPLS PE are per [RFC8077] and [RFC7080].
The procedures for forwarding state setup and unicast operation on The procedures for forwarding state setup and unicast operation on
the PBB-EVPN PE are as follows: the PBB-EVPN PE are as follows:
- The PBB-EVPN PE MUST establish a PW to each remote PBB-VPLS PE from - The PBB-EVPN PE MUST establish a PW to each remote PBB-VPLS PE
which it has received only a VPLS A-D route for the corresponding VPN from which it has received only a VPLS A-D route for the
instance, and MUST set up the label stack corresponding to the PW corresponding VPN instance and MUST set up the label stack
FEC. For seamless integration between PBB-EVPN and PBB-VPLS PEs, the corresponding to the PW FEC. For seamless integration between
PW that is setup between a pair of PBB-VPLS and PBB-EVPN PEs, is PBB-EVPN and PBB-VPLS PEs, the PW that is set up between a pair of
between B-components of PBB-EVPN PE and PBB-VPLS PE per section 4 of PBB-VPLS and PBB-EVPN PEs is between the B-components of PBB-EVPN
[RFC7041]. PE and PBB-VPLS PE per Section 4 of [RFC7041].
- The PBB-EVPN PE MUST set up the label stack corresponding to the - 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 MP2P VPN unicast FEC to any remote PBB-EVPN PE that has advertised
EVPN IMET route. an EVPN IMET route.
- If a PBB-EVPN PE receives a VPLS A-D route from a given PE, it sets - If a PBB-EVPN PE receives a VPLS A-D route from a given PE, it
up a PW to that PE. If it then receives an EVPN IMET route from the sets up a PW to that PE. If it then receives an EVPN IMET route
same PE, then the PBB-EVPN PE MUST bring that PW operationally down. from the same PE, 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 - If a PBB-EVPN PE receives an EVPN IMET route followed by a VPLS
route from the same PE, then the PBB-EVPN PE will setup the PW but A-D route from the same PE, then the PBB-EVPN PE will set up the
MUST keep it operationally down. PW but MUST keep it operationally down.
- In case VPLS A-D is not used in some PBB-VPLS PEs, the PBB-EVPN PEs - In case VPLS A-D is not used in some PBB-VPLS PEs, the PBB-EVPN
need to be provisioned manually with PWs to those remote PBB-VPLS PEs PEs need to be provisioned manually with PWs to those remote
for each VPN instance. In that case, if a PBB-EVPN PE receives an PBB-VPLS PEs for each VPN instance. In that case, if a PBB-EVPN
EVPN IMET route from a PE to which a PW exists, the PBB-EVPN PE MUST PE receives an EVPN IMET route from a PE to which a PW exists, the
bring the PW operationally down. PBB-EVPN PE MUST bring the PW operationally down.
- When the PBB-EVPN PE receives traffic over the PBB-VPLS PWs, it - 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 learns the associated B-MAC addresses in the data plane. The
addresses learned over these PWs MUST be injected into the bridge B-MAC addresses learned over these PWs MUST be injected into the
table of the associated MAC-VRF on that PBB-EVPN PE. The learned B- bridge table of the associated MAC-VRF on that PBB-EVPN PE. The
MAC addresses MAY also be injected into the RIB/FIB tables of the learned B-MAC addresses MAY also be injected into the RIB/FIB
associated the MAC-VRF on that BPP-EVPN PE. For seamless integration tables of the associated MAC-VRF on that BPP-EVPN PE. For
between PBB-EVPN and PBB-VPLS PEs, since these PWs belongs to the seamless integration between PBB-EVPN and PBB-VPLS PEs, since
same split-horizon group as the MP2P EVPN service tunnels, then the these PWs belong to the same split-horizon group as the MP2P EVPN
B-MAC addresses learned and associated to the PWs MUST NOT be service tunnels, the B-MAC addresses learned and associated with
advertised in the control plane to any remote PBB-EVPN PEs. This is the PWs MUST NOT be advertised in the control plane to any remote
because every PBB-EVPN PE can send and receive traffic directly PBB-EVPN PEs. This is because every PBB-EVPN PE can send and
to/from every PBB-VPLS PE belonging to the same VPN instance. 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 - The C-MAC addresses learned over local Attachment Circuits (ACs)
an PBB-EVPN PE are learned in data-plane. For PBB-EVPN PEs, these C- by a PBB-EVPN PE are learned in the data plane. For PBB-EVPN PEs,
MAC addresses are learned in I-component of PBB-EVPN PEs and they are these C-MAC addresses are learned in the I-component of PBB-EVPN
not advertised in the control-plane per [RFC7623]. PEs and are not advertised in the control plane, per [RFC7623].
- The B-MAC addresses learned in the control plane via the BGP EVPN - The B-MAC addresses learned in the control plane via the BGP EVPN
routes sent by remote PBB-EVPN PEs, are injected into the routes sent by remote PBB-EVPN PEs are injected into the
corresponding MAC-VRF table. corresponding MAC-VRF table.
In case of a link failure in a single-active Ethernet Segment, the In case of a link failure in a single-active Ethernet segment, the
PBB-EVPN PEs MUST perform both of the following tasks: 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 1. send a BGP B-MAC withdraw message to the PBB-EVPN peers *or* MAC
advertisement with MAC Mobility extended community advertisement with the MAC Mobility extended community
b) follow existing VPLS MAC Flush procedures with the PBB-VPLS peers 2. follow existing VPLS MAC Flush procedures with the PBB-VPLS peers
4.3 MAC Mobility 4.3. MAC Mobility
In PBB-EVPN, a given B-MAC address can be learned either over the BGP 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 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- PW from a remote PBB-VPLS PE. There is no mobility associated with
MAC addresses in this context. Hence, when the same B-MAC address 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, 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 the local PE can deduce that it is an anomaly and SHOULD notify the
operator. operator.
4.4 Multicast Operation 4.4. Multicast Operation
4.4.1 Ingress Replication 4.4.1. Ingress Replication
The procedures for multicast operation on the PBB-VPLS PE, using The procedures for multicast operation on the PBB-VPLS PE using
ingress replication, are per [RFC7041] and [RFC7080]. ingress replication are per [RFC7041] and [RFC7080].
The procedures for multicast operation on the PBB-EVPN PE, for The procedures for multicast operation on the PBB-EVPN PE for ingress
ingress replication, are as follows: replication are as follows:
- The PBB-EVPN PE builds a replication sub-list per I-SID to all the - 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 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 exchange of the EVPN IMET routes, as described in [RFC7623]. This
will be referred to as sub-list A. It comprises MP2P service tunnels will be referred to as sub-list A. It comprises MP2P service
used for delivering PBB-EVPN BUM traffic. tunnels used for delivering PBB-EVPN BUM traffic.
- The PBB-EVPN PE builds a replication sub-list per VPN instance to - 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. all the remote PBB-VPLS PEs. This will be referred to as sub-list
It comprises PWs from the PBB-EVPN PE in question to all the remote B. It comprises PWs from the PBB-EVPN PE in question to all the
PBB-VPLS PEs in the same VPN instance. 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, - 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 by running MMRP (see Clause 10 of [IEEE.802.1Q]) over the PBB-VPLS
as sub-list C. This list comprises a pruned set of the PWs in the network. This will be referred to as sub-list C. This list
sub-list B. comprises a pruned set of the PWs in sub-list B.
The replication list maintained per I-SID on a given PBB-EVPN PE will 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 be the union of sub-list A and sub-list B if MMRP is not used and the
the union of sub-list A and sub-list C if [MMRP] is used. Note that union of sub-list A and sub-list C if MMRP is used. Note that the PE
the PE MUST enable split-horizon over all the entries in the MUST enable split horizon over all the entries in the replication
replication list, across both pseudowires and MP2P service tunnels. list, across both pseudowires and MP2P service tunnels.
4.4.2 P2MP Tunnel - Inclusive Tree 4.4.2. P2MP Tunnel: Inclusive Tree
The procedures for multicast operation on the PBB-EVPN PEs using P2MP The procedures for multicast operation on the PBB-EVPN PEs using P2MP
tunnels are outside of the scope of this document. tunnels are outside of the scope of this document.
5 Security Considerations 5. Security Considerations
All the security considerations in [RFC4761], [RFC4762], [RFC7080], All the security considerations in [RFC4761], [RFC4762], [RFC7080],
[RFC7432], and [RFC7623] apply directly to this document because this [RFC7432], and [RFC7623] apply directly to this document because it
document leverages the control plane and the data plane procedures leverages the control-plane and data-plane procedures described in
described in these RFCs. those RFCs.
This document does not introduce any new security considerations This document does not introduce any new security considerations
beyond that of the above RFCs because the advertisements and beyond those of the above RFCs because the advertisements and
processing of MAC addresses in BGP follow that of [RFC7432] and processing of MAC addresses in BGP follow [RFC7432], and the
processing of MAC addresses learned over PWs follow that of processing of MAC addresses learned over PWs follows [RFC4761],
[RFC4761], [RFC4762], and [RFC7080]. [RFC4762], and [RFC7080].
6 IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no IANA actions.
7 References 7. References
7.1 Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI Requirement Levels", BCP 14, RFC 2119,
10.17487/RFC2119, March <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <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 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
the Label Distribution Protocol", RFC 8077, February 2017. LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>.
[RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
February, 2015. LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.
[RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015. "Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", RFC 6074,
DOI 10.17487/RFC6074, January 2011,
<https://www.rfc-editor.org/info/rfc6074>.
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed.,
LAN Service (VPLS) Using BGP for Auto-Discovery and "Extensions to the Virtual Private LAN Service (VPLS)
Signaling", RFC 4761, January 2007, <http://www.rfc- Provider Edge (PE) Model for Provider Backbone Bridging",
editor.org/info/rfc4761>. RFC 7041, DOI 10.17487/RFC7041, November 2013,
<https://www.rfc-editor.org/info/rfc7041>.
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
LAN Service (VPLS) Using Label Distribution Protocol (LDP) Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Signaling", RFC 4762, January 2007, <http://www.rfc- Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
editor.org/info/rfc4762>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7041] Balus et al., "Extensions to VPLS PE model for Provider [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and
Backbone Bridging", RFC 7041, November 2013. W. Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC6074] Rosen et al., "Provisioning, Auto-Discovery, and Signaling [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, Maintenance Using the Label Distribution Protocol (LDP)",
January 2011. STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<https://www.rfc-editor.org/info/rfc8077>.
7.2 Informative References [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>.
[MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area 7.2. Informative References
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 [IEEE.802.1Q]
Backbone Bridges", RFC 7080, December, 2013. IEEE, "IEEE Standard for Local and Metropolitan Area
Network -- Bridges and Bridged Networks", IEEE
Standard 802.1Q, DOI 10.1109/IEEESTD.2018.8403927, July
2018.
[IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
networks - Media Access Control (MAC) Bridges and Virtual Bridged R., Patel, K., and J. Guichard, "Constrained Route
Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI Distribution for Border Gateway Protocol/MultiProtocol
10.1109/IEEESTD.2011.6009146. Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC4684] Marques et al., "Constrained Route Distribution for Border [RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual
Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Private LAN Service (VPLS) Interoperability with Provider
Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November, Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080,
2006. December 2013, <https://www.rfc-editor.org/info/rfc7080>.
Authors' Addresses Authors' Addresses
Ali Sajassi Ali Sajassi (editor)
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
Samer Salam Samer Salam
Cisco Cisco
Email: ssalam@cisco.com Email: ssalam@cisco.com
Nick Del Regno Nick Del Regno
Verizon Verizon
Email: nick.delregno@verizon.com Email: nick.delregno@verizon.com
Jorge Rabadan Jorge Rabadan
Nokia Nokia
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
 End of changes. 153 change blocks. 
417 lines changed or deleted 438 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/