draft-ietf-bess-evpn-vpls-seamless-integ-02.txt   draft-ietf-bess-evpn-vpls-seamless-integ-03.txt 
INTERNET-DRAFT Ali Sajassi BESS Workgroup A. Sajassi (Editor)
Intended Status: Standard Track Samer Salam INTERNET-DRAFT S. Salam
Cisco Intended Status: Standard Track Cisco
N. Del Regno
Nick Del Regno
Verizon Verizon
J. Rabadan
Nokia
Jorge Rabadan Expires: October 15, 2018 April 15, 2018
Alcatel-Lucent
Expires: September 29, 2018 March 29, 2018
(PBB-)EVPN Seamless Integration with (PBB-)VPLS (PBB-)EVPN Seamless Integration with (PBB-)VPLS
draft-ietf-bess-evpn-vpls-seamless-integ-02 draft-ietf-bess-evpn-vpls-seamless-integ-03
Abstract Abstract
This draft specifies procedures for backward compatibility of the This draft specifies procedures for backward compatibility of the
(PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for (PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for
seamless integration of the two technologies in the same MPLS/IP seamless integration of the two technologies in the same MPLS/IP
network on a per-VPN-instance basis. Implementation of this draft network on a per-VPN-instance basis. Implementation of this draft
enables service providers to introduce (PBB-)EVPN PEs in their enables service providers to introduce (PBB-)EVPN PEs in their
brownfield deployments of (PBB-)VPLS networks. brownfield deployments of (PBB-)VPLS networks.
skipping to change at page 2, line 22 skipping to change at page 2, line 19
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . 4 1.1. Specification of Requirements . . . . . . . . . . . . . . 3
1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 7 3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 6
3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7 3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 6
3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7 3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7
3.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 8 3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 8 3.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 9
3.3.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 9 3.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 9
4 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 9 3.4.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 9
4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 9
4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 9 4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 9
4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 9 4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 9
4.2.1 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . 9 4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 10 4.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 10
4.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 10 4.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 10
4.3.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 10 4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 11
5 VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . . . 10 5 Solution Advantages . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 10 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 12
5.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 11 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
5.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 11 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12
5.3.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 11 8.2 Informative References . . . . . . . . . . . . . . . . . . 13
6 Solution Advantages . . . . . . . . . . . . . . . . . . . . . . 11
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 11
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1 Normative References . . . . . . . . . . . . . . . . . . . 12
9.2 Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1 Introduction 1 Introduction
VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many
Service Providers (SPs) who are looking at adopting EVPN and PBB-EVPN Service Providers (SPs) who are looking at adopting EVPN and PBB-EVPN
want to preserve their investment in the (PBB-)VPLS networks. Hence, want to preserve their investment in the (PBB-)VPLS networks. Hence,
they require procedures by which (PBB-)EVPN technology can be they require procedures by which (PBB-)EVPN technology can be
introduced into their brownfield (PBB-)VPLS networks without introduced into their brownfield (PBB-)VPLS networks without
requiring any upgrades (software or hardware) to these networks. This requiring any upgrades (software or hardware) to these networks. This
skipping to change at page 4, line 36 skipping to change at page 3, line 36
+---------------+ +---------------+
/ \ / \
+---+ +---+ +---+ +---+
|PE2| |PE3| |PE2| |PE3|
+---+ +---+ +---+ +---+
VPLS PE VPLS PE VPLS PE VPLS PE
Figure 1: Seamless Integration of (PBB-)EVPN PEs & (PBB-)VPLS Figure 1: Seamless Integration of (PBB-)EVPN PEs & (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 PBB-VPLS and specifies procedures for the seamless integration of VPLS and EVPN
PBB-EVPN networks. Section 4 specifies procedures for the seamless networks. Section 4 specifies procedures for the seamless integration
integration of VPLS and EVPN networks. Section 5 specifies procedures of PBB-VPLS and PBB-EVPN networks. Section 5 discusses the solution
for the seamless integration of VPLS and PBB-EVPN networks, and advantages.
finally Section 6 discusses the solution advantages.
It is worth noting that the scenario where PBB-VPLS is integrated It should be noted that the scenarios for PBB-VPLS integration with
with EVPN, is not covered in this draft because there hasn't been any EVPN and VPLS integration with PBB-EVPN are not covered in this
requirement from service providers for such integration. The reason document because there haven't been any requirements from service
for that is that deployments which employ PBB-VPLS typically require providers for these scenarios. The reason for that is that
PBB encapsulation for various reasons. Hence, it is expected that for deployments which employ PBB-VPLS typically require PBB encapsulation
those deployments the evolution path would be from PBB-VPLS towards for various reasons. Hence, it is expected that for those deployments
PBB-EVPN, rather than EVPN. the evolution path would be from PBB-VPLS towards PBB-EVPN.
Furthermore, the evolution path from VPLS is expected to be towards
EVPN.
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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. Terms and Abbreviations
B-MAC: Backbone MAC B-MAC: Backbone MAC
skipping to change at page 5, line 21 skipping to change at page 4, line 22
B-MAC: Backbone MAC B-MAC: Backbone MAC
B-VID: Backbone VLAN ID B-VID: Backbone VLAN ID
Broadcast Domain: In a bridged network, the broadcast domain Broadcast Domain: In a bridged network, the broadcast domain
corresponds to a Virtual LAN (VLAN), where a VLAN is typically corresponds to a Virtual LAN (VLAN), where a VLAN is typically
represented by a single VLAN ID (VID) but can be represented by represented by a single VLAN ID (VID) but can be represented by
several VIDs where Shared VLAN Learning (SVL) is used per several VIDs where Shared VLAN Learning (SVL) is used per
[IEEE.802.1ah]. [IEEE.802.1ah].
Bridge Table: An instantiation of a broadcast domain on a MAC-VRF. 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. CE: A Customer Edge device, e.g., a host, router, or switch.
EVI: An EVPN Instance spanning the Provider Edge (PE) devices EVI: An EVPN Instance spanning the Provider Edge (PE) devices
participating in that EVPN. participating in that EVPN.
MAC-VRF: A Virtual Routing and Forwarding table for Media Access MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on an EVPN PE. Control (MAC) addresses on an EVPN PE.
MAC address: Media Access Control address MAC address: Media Access Control address
skipping to change at page 5, line 44 skipping to change at page 4, line 51
more PEs via a set of Ethernet links, then that set of links is more PEs via a set of Ethernet links, then that set of links is
referred to as an "Ethernet Segment". referred to as an "Ethernet Segment".
ESI: An Ethernet Segment Identifier is a unique non-zero identifier ESI: An Ethernet Segment Identifier is a unique non-zero identifier
that identifies an ES that identifies an ES
Ethernet Tag: An Ethernet Tag identifies a particular broadcast Ethernet Tag: An Ethernet Tag identifies a particular broadcast
domain, e.g., a VLAN. An EVPN instance consists of one or more domain, e.g., a VLAN. An EVPN instance consists of one or more
broadcast domains broadcast domains
MHD: Multi-Homed Device
MHN: Multi-Homed Network
P2MP: Point-to-Multipoint P2MP: Point-to-Multipoint
PBB: Provider Backbone Bridge PBB: Provider Backbone Bridge
PE: Provider Edge device PE: Provider Edge device
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 Single-Active Redundancy Mode: When only a single PE, among all the
PEs attached to an Ethernet segment, is allowed to forward traffic PEs attached to an Ethernet segment, is allowed to forward traffic
to/from that Ethernet segment for a given VLAN, then the Ethernet to/from that Ethernet segment for a given VLAN, then the Ethernet
segment is defined to be operating in Single-Active redundancy mode. segment is defined to be operating in Single-Active redundancy mode.
All-Active Redundancy Mode: When all PEs attached to an Ethernet All-Active Redundancy Mode: When all PEs attached to an Ethernet
segment are allowed to forward known unicast traffic to/from that segment are allowed to forward known unicast traffic to/from that
Ethernet segment for a given VLAN, then the Ethernet segment is Ethernet segment for a given VLAN, then the Ethernet segment is
skipping to change at page 6, line 16 skipping to change at page 5, line 26
Single-Active Redundancy Mode: When only a single PE, among all the Single-Active Redundancy Mode: When only a single PE, among all the
PEs attached to an Ethernet segment, is allowed to forward traffic PEs attached to an Ethernet segment, is allowed to forward traffic
to/from that Ethernet segment for a given VLAN, then the Ethernet to/from that Ethernet segment for a given VLAN, then the Ethernet
segment is defined to be operating in Single-Active redundancy mode. segment is defined to be operating in Single-Active redundancy mode.
All-Active Redundancy Mode: When all PEs attached to an Ethernet All-Active Redundancy Mode: When all PEs attached to an Ethernet
segment are allowed to forward known unicast traffic to/from that segment are allowed to forward known unicast traffic to/from that
Ethernet segment for a given VLAN, then the Ethernet segment is Ethernet segment for a given VLAN, then the Ethernet segment is
defined to be operating in All-Active redundancy mode. 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 2. Requirements
Following are the key requirements for backward compatibility between Following are the key requirements for backward compatibility between
(PBB-)EVPN and (PBB-)VPLS: (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 on
a site-by-site basis per VPN instance - e.g., new EVPN sites to be a site-by-site basis per VPN instance - e.g., new EVPN sites to be
provisioned on (PBB-)EVPN PEs. provisioned on (PBB-)EVPN PEs.
2. The solution MUST require no changes to existing VPLS or PBB-VPLS 2. The solution MUST require no changes to existing VPLS or PBB-VPLS
PEs, not even a software upgrade. PEs, not even a software upgrade.
3. The solution MUST allow for the coexistence of PEs running (PBB- 3. The solution MUST allow for the coexistence of PEs running (PBB-
)EVPN and (PBB-)VPLS for the same VPN instance and single-homed )EVPN and (PBB-)VPLS for the same VPN instance and single-homed
segments. segments.
4. The solution MUST support single-active redundancy of multi-homed 4. The solution MUST support single-active redundancy of multi-homed
networks and multi-homed devices for (PBB-)EVPN PEs. networks and multi-homed devices for (PBB-)EVPN PEs.
5. In case of single-active redundancy, the participant VPN instances 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 MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as the
single-active redundancy is employed by (PBB-)EVPN PEs. In case of an MHD or MHN is connected to (PBB-)EVPN PEs. In case of an ES link
ES link failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to the EVPN
the EVPN peers OR MAC advertisement with MAC Mobility extended peers OR MAC advertisement with MAC Mobility extended community for
community for PBB-EVPN AND an LDP MAC withdrawal to the VPLS peers. PBB-EVPN AND follow existing VPLS MAC Flush procedures with the VPLS
peers.
6. The solution SHOULD support All-Active redundancy mode of multi- 6. The support of All-Active redundancy mode across both (PBB-)EVPN
homed networks and multi-homed devices for (PBB-)EVPN PEs. In case of PEs and (PBB-)VPLS PEs is outside the scope of this document.
All-Active redundancy mode, the participant VPN instances SHOULD be
confined to (PBB-)EVPN PEs only.
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. the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments.
3 PBB-VPLS Integration with PBB-EVPN 3 VPLS Integration with EVPN
In order to support seamless integration with (PBB-)VPLS PEs, the In order to support seamless integration with VPLS PEs, this document
(PBB-)EVPN PEs MUST support EVPN BGP routes (EVPN SAFI) and VPLS AD requires that VPLS PEs support VPLS A-D per [RFC6074] and EVPN PEs
route (VPLS SAFI). All the logic for this seamless integration SHALL support both BGP EVPN routes per [RFC7432] and VPLS A-D per
reside on the (PBB-)EVPN PEs. However, if a VPLS instance is setup [RFC6074]. All the logic for this seamless integration SHALL reside
without the use of BGP auto-discovery, it is still possible (but on the EVPN PEs. If a VPLS instance is setup without the use of VPLS
cumbersome) for (PBB-)EVPN PEs to integrate into that VPLS instance. A-D, it is still possible (but cumbersome) for EVPN PEs to integrate
into that VPLS 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 3.1 Capability Discovery
The (PBB-)EVPN PEs MUST advertise both the BGP VPLS auto-discovery The EVPN PEs MUST advertise both the BGP VPLS A-D route as well as
(AD) route as well as the BGP EVPN Inclusive Multicast route for a the BGP EVPN Inclusive Multicast Ethernet Tag (IMET) route for a
given VPN instance. The (PBB-)VPLS PEs only advertise the BGP VPLS AD given VPN instance. The VPLS PEs only advertise the BGP VPLS A-D
route, per current standard procedures specified in [RFC4761] and route, per current standard procedures specified in [RFC4761],
[RFC6074]. The operator may decide to use the same BGP RT to identify [RFC4762] and [RFC6074]. The operator may decide to use the same
a VPN on both (PBB-)EVPN and (PBB-)VPLS networks. In this case, when Route Target (RT) to identify a VPN on both EVPN and VPLS networks.
a (PBB-)VPLS PE receives the EVPN Inclusive Multicast route, it will 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, 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 the operator may choose to use two RTs - one to identify the VPN on
(PBB-)VPLS network and another for (PBB-)EVPN network and employ RT- VPLS network and another for EVPN network and employ RT-constrained
constraint in order to prevent EVPN BGP routes from reaching the [RFC4684] in order to prevent BGP EVPN routes from reaching the VPLS
(PBB-)VPLS PEs. PEs.
When a (PBB-)EVPN PE receives both a VPLS AD route as well as an EVPN When a EVPN PE receives both a VPLS A-D route as well as an EVPN IMET
Inclusive Multicast route from a given remote PE for the same VPN route from a given remote PE for the same VPN instance, it MUST give
instance, it MUST give preference to the EVPN route for the purpose preference to the EVPN route for the purpose of discovery. This
of discovery. This ensures that, at the end of the route exchanges, ensures that, at the end of the route exchanges, all EVPN capable PEs
all (PBB-)EVPN capable PEs discover other (PBB-)EVPN capable PEs in discover other EVPN capable PEs in addition to the VPLS-only PEs for
addition to the (PBB-)VPLS-only PEs for that VPN instance. that VPN instance. Furthermore, all the VPLS-only PEs would discover
Furthermore, all the (PBB-)VPLS-only PEs would discover the (PBB- the EVPN PEs as if they were standard VPLS PEs. In other words, when
)EVPN PEs as if they were standard (PBB-)VPLS PEs. In other words, the discovery phase is complete, the EVPN PEs would have discovered
when the discovery phase is complete, the (PBB-)EVPN PEs would have all the PEs in the VPN instance along with their associated
discovered all the PEs in the VPN instance along with their capability: EVPN or VPLS-only. Whereas the VPLS PEs would have
associated capability: (PBB-)EVPN or VPLS-only. Whereas the (PBB- discovered all the PEs in the VPN instance as if they were all VPLS-
)VPLS PEs would have discovered all the PEs in the VPN instance, as only PEs.
if they were all VPLS-only PEs.
3.2 Forwarding Setup and Unicast Operation 3.2 Forwarding Setup and Unicast Operation
The procedures for forwarding setup and unicast operation on the The procedures for forwarding state setup and unicast operation on
(PBB-)VPLS PE are per [RFC8077] and [RFC7080]. the VPLS PE are per [RFC8077], [RFC4761], [RFC4762].
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 EVPN PE are as follows:
- The (PBB-)EVPN PE MUST establish a pseudowire to a remote PE from - The EVPN PE MUST establish a PW to a remote PE from which it has
which it has received only a VPLS AD route for the corresponding VPN received only a VPLS A-D route for the corresponding VPN instance,
instance, and MUST set up the label stack corresponding to the and MUST set up the label stack corresponding to the PW FEC. For
pseudowire FEC. For seamless integration between PBB-EVPN and PBB- seamless integration between EVPN and VPLS PEs, the PW that is setup
VPLS PEs, this PW is between B-components of PBB-EVPN PE and PBB-VPLS between a pair of VPLS and EVPN PEs is between the VSI of the VPLS PE
PE per section 4 of [RFC7041]. and the MAC-VRF of the EVPN PE.
- The (PBB-)EVPN PE must set up the label stack corresponding to the - The EVPN PE must set up the label stack corresponding to the MP2P
MP2P VPN unicast FEC to any remote PE that has advertised EVPN AD VPN unicast FEC to any remote PE that has advertised EVPN IMET route.
route.
- If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD - If a EVPN PE receives a VPLS A-D route followed by an EVPN IMET
route from the same PE and a pseudowire is setup to that PE, then the route from the same PE and a PW is already setup to that PE, then the
(PBB-)EVPN MUST bring that pseudowire operationally down. EVPN MUST bring that PW operationally down.
- If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD - If a 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 route from the same PE, then the EVPN PE will setup the PW but MUST
pseudowire but MUST keep it operationally down. keep it operationally down.
When the (PBB-)EVPN PE receives traffic over the pseudowires, it - In case VPLS AD is not used in some VPLS PEs, the EVPN PEs need to
learns the associated MAC addresses in the data-plane. This is be provisioned manually with PWs to those remote VPLS PEs for each
analogous to dynamic learning in IEEE bridges. The MAC addresses VPN instance. In that case, if a EVPN PE receives an EVPN IMET route
learned over PWs are not injected into (PBB-)EVPN MAC-VRF tables but from a PE to which a PW exists, the PW will be brought operationally
rather they are injected into their corresponding (PBB-)VPLS VSI down.
table. If the core-facing PW belongs to the same split-horizon group
as the core-facing MP2P EVPN service tunnels, then the MAC addresses
learned and associated to the PW will NOT be advertised in the
control plane to any remote (PBB-)EVPN PE. 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 MAC addresses learned over local Attachment Circuits (ACs) by a When the EVPN PE receives traffic over the VPLS PWs, it learns the
(PBB-)EVPN PE are advertised in control plane using BGP EVPN routes associated C-MAC addresses in the data-plane. The C-MAC addresses
to other (PBB-)EVPN PEs. Furthermore, the MAC addresses learned in learned over these PWs MUST be injected into the bridge table of the
the control plane, via the BGP EVPN routes sent by remote (PBB-)EVPN associated MAC-VRF on that EVPN PE. The learned C-MAC addresses MAY
PEs, are injected into the corresponding MAC-VRF table. This is also be injected into the RIB/FIB tables of the associated MAC-VRF on
analogous to static learning in IEEE bridges. In PBB-EVPN, a given B- that EVPN PE. For seamless integration between EVPN and VPLS PEs,
MAC address can be learnt either over the BGP control-plane from a since these PWs belong to the same split-horizon group as the MP2P
remote PBB-EVPN PE, or in the data-plane over a pseudowire from a EVPN service tunnels, then the C-MAC addresses learned and associated
remote PBB-VPLS PE. There is no mobility associated with B-MAC to the PWs will NOT be advertised in the control plane to any remote
addresses in this context. Hence, when the same B-MAC address shows EVPN PEs. This is because every EVPN PE can send and receive traffic
up behind both a remote PBB-VPLS PE as well as a PBB-EVPN PE, the directly to/from every VPLS PE belonging to the same VPN instance.
local PE can deduce that it is an anomaly and notify the operator.
3.3 Multicast Operation 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.
3.3.1 Ingress Replication The procedures for multicast operation on the 3.3 MAC Mobility
(PBB-)VPLS PE, using ingress replication, are per [RFC4761],
[RFC4762], and [RFC7080].
The procedures for multicast operation on the PBB-EVPN PE, for In EVPN, host addresses (C-MAC addresses) can move around among EVPN
ingress replication, are as follows: PEs or even between EVPN and VPLS PEs.
- The PBB-EVPN PE builds a replication sub-list per I-SID to all the When a C-MAC address moves from an EVPN PE to a VPLS PE, then as soon
remote PBB-EVPN PEs in a given VPN instance, as a result of the as BUM traffic is initiated from that MAC address, it is flooded to
exchange of the EVPN Inclusive multicast routes, as described in all other PEs (both VPLS and EVPN PEs) and the receiving PEs update
[RFC7623]. This will be referred to as sub-list A. It comprises MP2P their MAC tables (VSI or MAC-VRF). The EVPN PEs do not advertise the
service tunnels used for delivering PBB-EVPN BUM traffic [RFC7432]. C-MAC address learned over PW to each other because every EVPN PE
learns it 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) but this is the
typical behavior of VPLS PEs.
- The PBB-EVPN PE builds a replication sub-list per VPN instance to When a C-MAC address moves from a VPLS PE to an EVPN PE, then as soon
all the remote PBB-VPLS PEs , as a result of the exchange of the VPLS as BUM or known-unicast traffic is initiated from that C-MAC address,
AD routes. This will be referred to as sub-list B. It comprises the C-MAC is learned and advertised in BGP to other EVPN PEs and MAC
pseudowires from the PBB-EVPN PE in question to all the remote PBB- mobility procedure is exercised among EVPN PEs. For BUM traffic, both
VPLS PEs in the same VPN instance. 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) but this is the
typical behavior of VPLS PEs.
- The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis, 3.4 Multicast Operation
if [MMRP] is run over the PBB-VPLS network. This will be referred to
as sub-list C. This list comprises a pruned set of the pseudowires in
sub-list B.
The replication list, maintained per I-SID, on a given PBB-EVPN PE 3.4.1 Ingress Replication
will be the union of sub-list A and sub-list B if [MMRP] is NOT used,
and 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.
3.3.2 P2MP Tunnel The procedures for multicast operation on the PBB-EVPN The procedures for multicast operation on the VPLS PE, using ingress
PEs using P2MP tunnels are outside of the scope of this document. replication, are per [RFC4761], [RFC4762], and [RFC7080].
4 VPLS Integration with EVPN The procedures for multicast operation on the EVPN PE, for ingress
replication, are as follows:
4.1 Capability Discovery - 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 used for delivering EVPN BUM traffic
[RFC7432].
The procedures for capability discovery are per Section 3.1 above. - 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.
4.2 Forwarding Setup and Unicast Operation The replication list, maintained per VPN instance, on a given EVPN PE
will be the union of sub-list A and sub-list B. Note that the PE must
enable split-horizon over all the entries in the replication list,
across both PWs and MP2P service tunnels.
The operation here is largely similar to that of PBB-EVPN integration 3.4.2 P2MP Tunnel
with PBB-VPLS, with one major exception in handling MAC mobility that
is described in the next section.
- For seamless integration among EVPN and VPLS PEs, the PW that is The procedures for multicast operation on the EVPN PEs using P2MP
setup between a pair of VPLS and EVPN PEs is between VSI of VPLS PE tunnels are outside of the scope of this document.
and MAC-VRF of EVPN PE.
4.2.1 MAC Mobility 4 PBB-VPLS Integration with PBB-EVPN
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 EVPN and VPLS PEs.
When a MAC address moves from an EVPN PE to a VPLS PE, then as soon In order to support seamless integration between PBB-VPLS and PBB-
as BUM traffic is initiated from that MAC address, it is flooded to EVPN PEs, this document requires that PBB-VPLS PEs support VPLS A-D
all other PEs (both VPLS and EVPN PEs) and the receiving PEs update per [RFC6074] and PBB-EVPN PEs support both BGP EVPN routes per
their MAC tables (VSI or MAC-VRF). The EVPN PEs do not advertise the [RFC7432] and VPLS A-D per [RFC6074]. All the logic for this seamless
MAC address learned over PW to each other because every EVPN PE integration SHALL reside on the PBB-EVPN PEs.
learns it directly over its associated PW to that VPLS PE. If only
known-unicast traffic is initiated from the moved MAC address toward
a known MAC, then this can result in black-holing of traffic destined
to the MAC that has moved until the MAC age-out timer expires but
this is the typical behavior of VPLS PEs.
When a host MAC address moves from a VPLS PE to an EVPN PE, then as 4.1 Capability Discovery
soon as BUM or known-unicast traffic is initiated from that MAC
address, the 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
MAC address; however, if there is only known-unicast traffic, then
only EVPN PEs learn the new location of the MAC that has moved but
not VPLS PEs. This can result in black-holing of traffic sent from
VPLS PEs destined to the MAC that has moved until the MAC age-out
timer expires but this is the typical behavior of VPLS PEs.
4.3 Multicast Operation The procedures for capability discovery are per Section 3.1 above.
4.3.1 Ingress Replication 4.2 Forwarding Setup and Unicast Operation
The operation is per the procedures of Section 3.3.1 above for the The procedures for forwarding state setup and unicast operation on
scenario WITHOUT [MMRP]. The replication list is maintained per VPN the PBB-VPLS PE are per [RFC8077] and [RFC7080].
instance rather than per I-SID.
4.3.2 P2MP Tunnel - Inclusive Tree 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:
The procedures for multicast operation on the EVPN PEs using P2MP - For seamless integration between EVPN and VPLS PEs, the PW that is
tunnels are outside of the scope of this document. 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].
5 VPLS Integration with PBB-EVPN - 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 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 same VPN instance.
5.1 Capability Discovery - 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 procedures for capability discovery are per Section 3.1 above. - 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.
5.2 Forwarding Setup and Unicast Operation 4.3 MAC Mobility
The operation here is largely similar to that of PBB-EVPN integration In PBB-EVPN, a given B-MAC address can be learnt either over the BGP
with PBB-VPLS, with a few exceptions listed below: 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 notify the
operator.
- When a PW is setup between a PBB-EVPN PE and a VPLS PE, it gets 4.4 Multicast Operation
setup between the I-component of PBB-EVPN PE and the VSI of VPLS PE.
- The MAC mobility aspect is the same as that of VPLS network or PBB- 4.4.1 Ingress Replication
VPLS network since in both cases the host MAC (C-MAC) learning over The procedures for multicast operation on the PBB-VPLS PE, using
MPLS/IP core is done via data-plane learning. ingress replication, are per [RFC7041] and [RFC7080].
5.3 Multicast Operation The procedures for multicast operation on the PBB-EVPN PE, for
ingress replication, are as follows:
5.3.1 Ingress Replication - 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 operation is per the procedures of Section 3.3.1 above for the - The PBB-EVPN PE builds a replication sub-list per VPN instance to
scenario WITHOUT [MMRP]. The replication list is maintained per I-SID all the remote PBB-VPLS PEs. This will be referred to as sub-list B.
on the PBB-EVPN PEs and per VPN instance on the VPLS PEs. It comprises PWs from the PBB-EVPN PE in question to all the remote
PBB-VPLS PEs in the same VPN instance.
5.3.2 P2MP Tunnel - Inclusive Tree - The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis,
if [MMRP] is run 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
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 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.
6 Solution Advantages 5 Solution Advantages
The solution for seamless integration of (PBB-)EVPN with (PBB-)VPLS The solution for seamless integration of (PBB-)EVPN with (PBB-)VPLS
has the following advantages: has the following advantages:
- 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) to only that of existing VPLS PEs, and uses the more
robust BGP-based mechanism for multicast pruning among new EVPN PEs. robust BGP-based mechanism for multicast pruning among new EVPN PEs.
- It is completely backward compatible. - It is completely backward compatible.
skipping to change at page 11, line 44 skipping to change at page 12, line 4
- 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) to only that of existing VPLS PEs, and uses the more
robust BGP-based mechanism for multicast pruning among new EVPN PEs. 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 multi-homing mechanisms and
provisioning simplifications of PBB-EVPN: provisioning simplifications of PBB-EVPN:
a. Auto-sensing of MHN / MHD a. Auto-sensing of MHN / MHD
b. Auto-discovery of redundancy group b. Auto-discovery of redundancy group
c. Auto-provisioning in DF election and VLAN carving c. Auto-provisioning in DF election and VLAN carving
7 Security Considerations 6 Security Considerations
No new security considerations beyond those for VPLS and EVPN. No new security considerations beyond those for VPLS and EVPN.
8 IANA Considerations 7 IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9 References 8 References
9.1 Normative References 8.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, DOI
10.17487/RFC2119, March <https://www.rfc- 10.17487/RFC2119, March <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 12, line 46 skipping to change at page 13, line 7
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007, <http://www.rfc- Signaling", RFC 4762, January 2007, <http://www.rfc-
editor.org/info/rfc4762>. editor.org/info/rfc4762>.
[RFC6074] Rosen et al., "Provisioning, Auto-Discovery, and Signaling [RFC6074] Rosen et al., "Provisioning, Auto-Discovery, and Signaling
in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074,
January 2011. January 2011.
9.2 Informative References 8.2 Informative References
[MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area [MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area
networks - Media Access Control (MAC) Bridges and Virtual Bridged networks - Media Access Control (MAC) Bridges and Virtual Bridged
Local Area Networks", IEEE Std 802.1Q, 2013. Local Area Networks", IEEE Std 802.1Q, 2013.
[RFC7041] Balus et al., "Extensions to VPLS PE model for Provider [RFC7041] Balus et al., "Extensions to VPLS PE model for Provider
Backbone Bridging", RFC 7041, November 2013. Backbone Bridging", RFC 7041, November 2013.
[RFC7080] Sajassi et al., "VPLS Interoperability with Provider [RFC7080] Sajassi et al., "VPLS Interoperability with Provider
Backbone Bridges", RFC 7080, December, 2013. Backbone Bridges", RFC 7080, December, 2013.
[IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area [IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area
networks - Media Access Control (MAC) Bridges and Virtual Bridged networks - Media Access Control (MAC) Bridges and Virtual Bridged
Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI
10.1109/IEEESTD.2011.6009146. 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 Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
Samer Salam Samer Salam
Cisco Cisco
Email: ssalam@cisco.com Email: ssalam@cisco.com
 End of changes. 70 change blocks. 
224 lines changed or deleted 278 lines changed or added

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