draft-ietf-bess-evpn-vpls-seamless-integ-03.txt   draft-ietf-bess-evpn-vpls-seamless-integ-04.txt 
BESS Workgroup A. Sajassi (Editor) BESS Workgroup A. Sajassi (Editor)
INTERNET-DRAFT S. Salam INTERNET-DRAFT S. Salam
Intended Status: Standard Track Cisco Intended Status: Standard Track Cisco
N. Del Regno N. Del Regno
Verizon Verizon
J. Rabadan J. Rabadan
Nokia Nokia
Expires: October 15, 2018 April 15, 2018 Expires: October 25, 2018 April 25, 2018
(PBB-)EVPN Seamless Integration with (PBB-)VPLS (PBB-)EVPN Seamless Integration with (PBB-)VPLS
draft-ietf-bess-evpn-vpls-seamless-integ-03 draft-ietf-bess-evpn-vpls-seamless-integ-04
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 brown-
brownfield deployments of (PBB-)VPLS networks. field deployments of (PBB-)VPLS networks.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 4
1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 6 3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 6
3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 6 3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7
3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7 3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7
3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 9 3.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 9
3.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 9 3.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 9
3.4.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 9 3.4.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 10
4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 9 4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 10
4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 9 4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 10
4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 9 4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 10
4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 10 4.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 11
4.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 10 4.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 11
4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 11 4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 12
5 Solution Advantages . . . . . . . . . . . . . . . . . . . . . . 11 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 12
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1 Normative References . . . . . . . . . . . . . . . . . . . 12
8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 7.2 Informative References . . . . . . . . . . . . . . . . . . 13
8.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1 Introduction 1 Introduction
VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many Virtual Private LAN Service (VPLS) and Provider Backbone Bridging
Service Providers (SPs) who are looking at adopting EVPN and PBB-EVPN VPLS (PBB-VPLS) are widely-deployed Layer-2 VPN (L2VPN) technologies.
want to preserve their investment in the (PBB-)VPLS networks. Hence, Many Service Providers (SPs) who are looking at adopting Ethernet VPN
they require procedures by which (PBB-)EVPN technology can be (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) want to
introduced into their brownfield (PBB-)VPLS networks without preserve their investment in the VPLS and PBB-VPLS networks. Hence,
they require procedures by which EVPN and PBB-EVPN technology can be
introduced into their brown-field VPLS and PBB-VPLS networks without
requiring any upgrades (software or hardware) to these networks. This requiring any upgrades (software or hardware) to these networks. This
document specifies procedures for the seamless integration of the two document specifies procedures for the seamless integration of the two
technologies in the same MPLS/IP network. technologies in the same MPLS/IP network. Throughout this document,
we use the term (PBB-)EVPN to correspond to both EVPN and PBB-EVPN
and we use the term (PBB-)VPLS to correspond to both VPLS and PBB-
VPLS.
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 | +---+
skipping to change at page 3, line 37 skipping to change at page 3, line 42
/ \ / \
+---+ +---+ +---+ +---+
|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 VPLS and EVPN specifies procedures for the seamless integration of VPLS and EVPN
networks. Section 4 specifies procedures for the seamless integration networks. And section 4 specifies procedures for the seamless
of PBB-VPLS and PBB-EVPN networks. Section 5 discusses the solution integration of PBB-VPLS and PBB-EVPN networks.
advantages.
It should be noted that the scenarios for PBB-VPLS integration with It should be noted that the scenarios for PBB-VPLS integration with
EVPN and VPLS integration with PBB-EVPN are not covered in this 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. The reason for that is that
deployments which employ PBB-VPLS typically require PBB encapsulation deployments which employ PBB-VPLS typically require PBB encapsulation
for various reasons. Hence, it is expected that for those deployments for various reasons. Hence, it is expected that for those deployments
the evolution path would be from PBB-VPLS towards PBB-EVPN. the evolution path would be from PBB-VPLS towards PBB-EVPN.
Furthermore, the evolution path from VPLS is expected to be towards Furthermore, the evolution path from VPLS is expected to be towards
EVPN. EVPN.
The seamless integration solution described in this document has the
following attributes:
- When ingress replication is used for multi-destination traffic
delivery, the solution reduces the scope of [MMRP] (which is a soft-
state protocol) to only that of existing VPLS PEs, and uses the more
robust BGP-based mechanism for multicast pruning among new EVPN PEs.
- It is completely backward compatible.
- New PEs can leverage the extensive multi-homing mechanisms and
provisioning simplifications of (PBB-)EVPN:
a. Auto-sensing of MHN / MHD
b. Auto-discovery of redundancy group
c. Auto-provisioning in DF 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 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 45 skipping to change at page 6, line 18
PW: Pseudowire. 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 Provider Edge devices (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.
skipping to change at page 6, line 31 skipping to change at page 7, line 4
PEs and (PBB-)VPLS PEs is outside the scope of this document. PEs and (PBB-)VPLS PEs is outside the scope of this document.
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 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 EVPN PEs
support both BGP EVPN routes per [RFC7432] and VPLS A-D per support both BGP EVPN routes per [RFC7432] and VPLS A-D per
[RFC6074]. All the logic for this seamless integration SHALL reside
on the EVPN PEs. If a VPLS instance is setup without the use of VPLS [RFC6074]. All the logic for seamless integration SHALL reside on the
A-D, it is still possible (but cumbersome) for EVPN PEs to integrate EVPN PEs. If a VPLS instance is setup without the use of VPLS A-D, it
into that VPLS instance by manually configuring PWs to all the VPLS is still possible (but cumbersome) for EVPN PEs to integrate into
PEs in that instance (i.e., the integration is no longer seamless). that VPLS instance by manually configuring Pseudowires (PWs) to all
the VPLS PEs in that instance (i.e., the integration is no longer
seamless).
3.1 Capability Discovery 3.1 Capability Discovery
The EVPN PEs MUST advertise both the BGP VPLS A-D route as well as The EVPN PEs MUST advertise both the BGP VPLS Auto-Discovery (A-D)
the BGP EVPN Inclusive Multicast Ethernet Tag (IMET) route for a route as well as the BGP EVPN Inclusive Multicast Ethernet Tag (IMET)
given VPN instance. The VPLS PEs only advertise the BGP VPLS A-D route for a given VPN instance. The VPLS PEs only advertise the BGP
route, per current standard procedures specified in [RFC4761], VPLS A-D route, per the procedures specified in [RFC4761], [RFC4762]
[RFC4762] and [RFC6074]. The operator may decide to use the same and [RFC6074]. The operator may decide to use the same Route Target
Route Target (RT) to identify a VPN on both EVPN and VPLS networks. (RT) to identify a VPN on both EVPN and VPLS networks. In this case,
In this case, when a VPLS PE receives the EVPN IMET route, it MUST when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the
ignore it on the basis that it belongs to an unknown SAFI. However, basis that it belongs to an unknown SAFI. However, the operator may
the operator may choose to use two RTs - one to identify the VPN on choose to use two RTs - one to identify the VPN on VPLS network and
VPLS network and another for EVPN network and employ RT-constrained another for EVPN network and employ RT-constrained [RFC4684] in order
[RFC4684] in order to prevent BGP EVPN routes from reaching the VPLS to prevent BGP EVPN routes from reaching the VPLS PEs.
PEs.
When a EVPN PE receives both a VPLS A-D route as well as an EVPN IMET When an EVPN PE receives both a VPLS A-D route as well as an EVPN
route from a given remote PE for the same VPN instance, it MUST give IMET route from a given remote PE for the same VPN instance, it MUST
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 would 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 would 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 would 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 forwarding state setup and unicast operation on
the VPLS PE are per [RFC8077], [RFC4761], [RFC4762]. 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 EVPN PE are as follows: the EVPN PE are as follows:
skipping to change at page 7, line 36 skipping to change at page 8, line 9
- The EVPN PE MUST establish a PW to a remote PE from which it has - The EVPN PE MUST establish a PW to a remote PE from which it has
received only a VPLS A-D route for the corresponding VPN instance, received only a VPLS A-D route for the corresponding VPN instance,
and MUST set up the label stack corresponding to the PW FEC. For and MUST set up the label stack corresponding to the PW FEC. For
seamless integration between EVPN and VPLS PEs, the PW that is setup seamless integration between EVPN and VPLS PEs, the PW that is setup
between a pair of VPLS and EVPN PEs is between the VSI of the VPLS PE between a pair of VPLS and EVPN PEs is between the VSI of the VPLS PE
and the MAC-VRF of the EVPN 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 EVPN IMET route.
- If a EVPN PE receives a VPLS A-D route followed by an EVPN IMET - If an EVPN PE receives a VPLS A-D route followed by an EVPN IMET
route from the same PE and a PW is already setup to that PE, then the route from the same PE and a PW is already setup to that PE, then the
EVPN MUST bring that PW operationally down. EVPN MUST bring that PW operationally down.
- If a 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 setup the PW but MUST
keep it operationally down. keep it operationally down.
- In case VPLS AD is not used in some VPLS PEs, the EVPN PEs need to - In case VPLS AD is not used in some VPLS PEs, the EVPN PEs need to
be provisioned manually with PWs to those remote VPLS PEs for each be provisioned manually with PWs to those remote VPLS PEs for each
VPN instance. In that case, if a EVPN PE receives an EVPN IMET route VPN instance. In that case, if an EVPN PE receives an EVPN IMET route
from a PE to which a PW exists, the PW will be brought operationally from a PE to which a PW exists, the PW will be brought operationally
down. 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 as the MP2P since these PWs belong to the same split-horizon group as the MP2P
skipping to change at page 8, line 28 skipping to change at page 8, line 49
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.
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, then as soon
as BUM traffic is initiated from that MAC address, it is flooded to as Broadcast/Unknown-unicast/Multicast (BUM) traffic is initiated
all other PEs (both VPLS and EVPN PEs) and the receiving PEs update from that MAC address, it is flooded to all other PEs (both VPLS and
their MAC tables (VSI or MAC-VRF). The EVPN PEs do not advertise the EVPN PEs) and the receiving PEs update their MAC tables (VSI or MAC-
C-MAC address learned over PW to each other because every EVPN PE VRF). The EVPN PEs do not advertise the C-MAC addresses learned over
learns it directly over its associated PW to that VPLS PE. If only the PW to each other because every EVPN PE learns them directly over
known-unicast traffic is initiated from the moved C-MAC address its associated PW to that VPLS PE. If only known-unicast traffic is
toward a known C-MAC, then this can result in black-holing of traffic initiated from the moved C-MAC address toward a known C-MAC, then
destined to the C-MAC that has moved until there is a BUM traffic this can result in black-holing of traffic destined to the C-MAC that
originated with the moved C-MAC address as the source MAC address has moved until there is a BUM traffic originated with the moved C-
(e.g., as a result of MAC age-out timer expires) but this is the MAC address as the source MAC address (e.g., as a result of MAC age-
typical behavior of VPLS PEs. out timer expires). Note that this is behavior typical of 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 BUM or known-unicast traffic is initiated from that C-MAC address, as BUM or known-unicast traffic is initiated from that C-MAC address,
the C-MAC is learned and advertised in BGP to other EVPN PEs and MAC the C-MAC is learned and advertised in BGP to other EVPN PEs and MAC
mobility procedure is exercised among EVPN PEs. For BUM traffic, both mobility procedure is exercised among EVPN PEs. For BUM traffic, both
EVPN and VPLS PEs learn the new location of the moved C-MAC address; 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 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. 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 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 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 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 (e.g., as a result of MAC age-out timer expires). Note that this is
typical behavior of VPLS PEs. behavior typical of 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:
skipping to change at page 11, line 37 skipping to change at page 12, line 11
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 union of sub-list A and sub-list C if [MMRP] is used. Note that 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 the PE must enable split-horizon over all the entries in the
replication list, across both pseudowires and MP2P service tunnels. replication 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 Solution Advantages 5 Security Considerations
The solution for seamless integration of (PBB-)EVPN with (PBB-)VPLS
has the following advantages:
- When ingress replication is used for multi-destination traffic
delivery, the solution reduces the scope of [MMRP] (which is a soft-
state protocol) to only that of existing VPLS PEs, and uses the more
robust BGP-based mechanism for multicast pruning among new EVPN PEs.
- It is completely backward compatible.
- New PEs can leverage the extensive multi-homing mechanisms and
provisioning simplifications of PBB-EVPN:
a. Auto-sensing of MHN / MHD
b. Auto-discovery of redundancy group
c. Auto-provisioning in DF election and VLAN carving
6 Security Considerations All the security considerations in [RFC4761], [RFC4762], [RFC7080],
[RFC7432], and [RFC7623] apply directly to this document because this
document leverages the control plane and the data plane procedures
described in these RFCs.
No new security considerations beyond those for VPLS and EVPN. This document does not introduce any new security considerations
beyond that of the above RFCs because the advertisements and
processing of MAC addresses in BGP follow that of [RFC7432] and
processing of MAC addresses learned over PWs follow that of
[RFC4761], [RFC4762], and [RFC7080].
7 IANA Considerations 6 IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8 References 7 References
8.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, 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 13, line 7 skipping to change at page 13, line 20
[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.
8.2 Informative References 7.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.
 End of changes. 31 change blocks. 
94 lines changed or deleted 105 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/