draft-ietf-bess-evpn-vpls-seamless-integ-05.txt   draft-ietf-bess-evpn-vpls-seamless-integ-06.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: May 27, 2019 November 27, 2018 Expires: July 21, 2019 January 21, 2019
(PBB-)EVPN Seamless Integration with (PBB-)VPLS (PBB-)EVPN Seamless Integration with (PBB-)VPLS
draft-ietf-bess-evpn-vpls-seamless-integ-05 draft-ietf-bess-evpn-vpls-seamless-integ-06
Abstract Abstract
This draft specifies procedures 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 (PBB-
EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider
Backbone Bridge VPLS (PBB-VPLS) solutions (PBB-)VPLS. It also Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides
provides mechanisms for seamless integration of these two mechanisms for seamless integration of these two technologies in the
technologies in the same MPLS/IP network on a per-VPN-instance basis. same MPLS/IP network on a per-VPN-instance basis. Implementation of
Implementation of this draft enables service providers to introduce this document enables service providers to introduce EVPN/PBB-EVPN
(PBB-)EVPN PEs in their brown-field deployments of (PBB-)VPLS PEs in their brown-field deployments of VPLS/PBB-VPLS networks. This
networks. document specifies control-plane and forwarding behavior needed for
auto-discovery of a VPN instance, multicast and unicast operation, as
well as MAC-mobility operation in order to enable seamless
integration between EVPN and VPLS PEs as well as between PBB-VPLS and
PBB-EVPN PEs.
Status of this Memo 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 22 skipping to change at page 2, line 26
(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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification of Requirements . . . . . . . . . . . . . . 4 1.1. Specification of Requirements . . . . . . . . . . . . . . 5
1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 6 3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 7
3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7 3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 8
3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7 3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 8
3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 9 3.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 10
3.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 9 3.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 10
3.4.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 9 3.4.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 11
4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 10 4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 11
4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 10 4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 11
4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 10 4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 11
4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 11 4.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 13
4.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 11 4.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 13
4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 12 4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 13
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 13
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1 Normative References . . . . . . . . . . . . . . . . . . . 12 7.1 Normative References . . . . . . . . . . . . . . . . . . . 14
7.2 Informative References . . . . . . . . . . . . . . . . . . 13 7.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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 (SPs) 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 investment in the VPLS and PBB-VPLS networks. Hence,
they require procedures by which EVPN and PBB-EVPN technology can be they require mechanisms by which EVPN and PBB-EVPN technologies can
introduced into their brown-field VPLS and PBB-VPLS networks without be introduced into their brown-field VPLS and PBB-VPLS networks
requiring any upgrades (software or hardware) to these networks. This without requiring any upgrades (software or hardware) to these
document specifies procedures for the seamless integration of the two networks. This document specifies procedures for the seamless
technologies in the same MPLS/IP network. Throughout this document, integration of the two technologies in the same MPLS/IP network.
we use the term (PBB-)EVPN to correspond to both EVPN and PBB-EVPN Throughout this document, we use the term (PBB-)EVPN to correspond to
and we use the term (PBB-)VPLS to correspond to both VPLS and PBB- both EVPN and PBB-EVPN and we use the term (PBB-)VPLS to correspond
VPLS. to both VPLS and PBB-VPLS. This document specifies control-plane and
forwarding behavior needed for auto-discovery of a VPN instance,
multicast and unicast operations, as well as MAC-mobility operation
in order to enable seamless integration between (PBB-)EVPN Provider
Edge(PE) devices and (PBB-)VPLS PEs.
VPLS PE 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 5, line 18 skipping to change at page 6, line 21
B-MAC address: Backbone MAC address - e.g., PE's MAC address B-MAC address: Backbone MAC address - e.g., PE's MAC address
Ethernet segment (ES): Refers to the set of Ethernet links that Ethernet segment (ES): Refers to the set of Ethernet links that
connects a customer site (device or network) to one or more PEs. connects a customer site (device or network) to one or more PEs.
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
FEC: Forwarding Equivalence Class
MHD: Multi-Homed Device MHD: Multi-Homed Device
MHN: Multi-Homed Network 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
skipping to change at page 5, line 46 skipping to change at page 6, line 51
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 (PBB-)EVPN: refers to both, PBB-EVPN and EVPN. This document uses
this abbreviation when a given description applies to both this abbreviation when a given description applies to both
technologies. technologies.
(PBB-)VPLS: refers to both, PBB-VPLS and VPLS. As for EVPN, this (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. This document uses
abbreviation is used when the text applies to both technologies. this abbreviation when a given description applies to both
technologies.
VPLS A-D: refers to Virtual Private LAN Services with BGP-based Auto VPLS A-D: refers to Virtual Private LAN Services with BGP-based Auto
Discovery as in [RFC6074]. Discovery as in [RFC6074].
PW: Pseudowire PW: Pseudowire
I-SID: Ethernet Services Instance Identifier I-SID: Ethernet Services Instance Identifier
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 Provider Edge devices (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 not require any changes to existing VPLS or PBB-
PEs, not even a software upgrade. VPLS 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 co-existence of PE devices running
)EVPN and (PBB-)VPLS for the same VPN instance and single-homed (PBB-)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 the may span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as the
MHD or MHN is connected to (PBB-)EVPN PEs. In case of an ES link MHD or MHN is connected to (PBB-)EVPN PEs.
failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to the EVPN
peers OR MAC advertisement with MAC Mobility extended community for
PBB-EVPN AND follow existing VPLS MAC Flush procedures with the VPLS
peers.
6. The support of All-Active redundancy mode across both (PBB-)EVPN 6. The support of All-Active redundancy mode across both (PBB-)EVPN
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
skipping to change at page 7, line 47 skipping to change at page 8, line 50
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 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 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 up
a PW to that PE. If it then receives an EVPN IMET route from the same a PW to that PE. If it then receives an EVPN IMET route from the same
PE, then the EVPN PE MUST bring that PW operationally down. PE, then the EVPN PE MUST bring that PW operationally down.
- If an EVPN PE receives an EVPN IMET route followed by a VPLS A-D - 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 A-D is not used in some VPLS PEs, the EVPN PEs need to
be provisioned manually with PWs to those remote VPLS PEs for each be provisioned manually with PWs to those remote VPLS PEs for each
VPN instance. In that case, if an EVPN PE receives an EVPN IMET route VPN instance. In that case, if an EVPN PE receives an EVPN IMET route
from a PE to which a PW exists, the EVPN PE MUST bring the PW from a PE to which a PW exists, the EVPN PE MUST bring the PW
operationally down. 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 as the MP2P since these PWs belong to the same split-horizon group ([RFC4761] and
EVPN service tunnels, then the C-MAC addresses learned and associated [RFC4762]) as the MP2P EVPN service tunnels, then the C-MAC addresses
to the PWs MUST NOT be advertised in the control plane to any remote learned and associated to the PWs MUST NOT be advertised in the
EVPN PEs. This is because every EVPN PE can send and receive traffic control plane to any remote EVPN PEs. This is because every EVPN PE
directly to/from every VPLS PE belonging to the same VPN instance. can send and receive traffic directly to/from every VPLS PE belonging
to the same VPN instance and thus every EVPN PE can learn the C-MAC
addresses over the corresponding PWs directly.
The C-MAC addresses learned over local Attachment Circuits (ACs) by 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 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
EVPN PEs MUST perform both of the following tasks:
a) send a BGP mass-withdraw to the EVPN peers
b) follow existing VPLS MAC Flush procedures with the VPLS peers.
3.3 MAC Mobility 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 Broadcast/Unknown-unicast/Multicast (BUM) traffic is initiated as Broadcast/Unknown-unicast/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 MAC-
VRF). The EVPN PEs do not advertise the C-MAC addresses learned over VRF). The EVPN PEs do not advertise the C-MAC addresses learned over
the PW to each other because every EVPN PE learns them directly over the PW to each other because every EVPN PE learns them directly over
its associated PW to that VPLS PE. If only known-unicast traffic is 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 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 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- 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- MAC address as the source MAC address (e.g., as a result of MAC age-
out timer expires). Note that this is behavior typical of VPLS PEs. out timer expires). Such black-holing happens for traffic destined to
the moved C-MAC from both EVPN and VPLS PEs. It should be noted that
such black-holing behavior is typical for VPLS PEs.
When a C-MAC address moves from a VPLS PE to an EVPN PE, then as soon 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 any traffic is initiated from that C-MAC address, the C-MAC is
the C-MAC is learned and advertised in BGP to other EVPN PEs and MAC learned and advertised in BGP to other EVPN PEs and MAC mobility
mobility procedure is exercised among EVPN PEs. For BUM traffic, both procedure is exercised among EVPN PEs. For BUM traffic, both EVPN and
EVPN and VPLS PEs learn the new location of the moved C-MAC address; VPLS PEs learn the new location of the moved C-MAC address; however,
however, if there is only known-unicast traffic, then only EVPN PEs if there is only known-unicast traffic, then only EVPN PEs learn the
learn the new location of the C-MAC that has moved but not VPLS PEs. new location of the C-MAC that has moved but not VPLS PEs. This can
This can result in black-holing of traffic sent from VPLS PEs result in black-holing of traffic sent from VPLS PEs destined to the
destined to the C-MAC that has moved until there is a BUM traffic C-MAC that has moved until there is a BUM traffic originated with the
originated with the moved C-MAC address as the source MAC address moved C-MAC address as the source MAC address (e.g., as a result of
(e.g., as a result of MAC age-out timer expires). Note that this is MAC age-out timer expires). Such black-holing happens for traffic
behavior typical of VPLS PEs. destined to the moved C-MAC for only VPLS PEs but not for EVPN PEs.
It should be noted that such black-holing behavior is typical for
VPLS PEs.
3.4 Multicast Operation 3.4 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 IMET
routes per [RFC7432]. This will be referred to as sub-list A. It routes per [RFC7432]. This will be referred to as sub-list A. It
comprises MP2P service tunnels used for delivering EVPN BUM traffic comprises MP2P service tunnels (for ingress replication) used for
[RFC7432]. 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 PEs
in the same VPLS instance. 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. Note that the 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
skipping to change at page 10, line 33 skipping to change at page 11, line 48
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 from
which it has received only a VPLS A-D route for the corresponding VPN which it has received only a VPLS A-D route for the corresponding VPN
instance, and MUST set up the label stack corresponding to the PW instance, and MUST set up the label stack corresponding to the PW
FEC. For seamless integration between PBB-EVPN and PBB-VPLS PEs, the FEC. For seamless integration between PBB-EVPN and PBB-VPLS PEs, the
PW that is setup between a pair of PBB-VPLS and PBB-EVPN PEs, is PW that is setup between a pair of PBB-VPLS and PBB-EVPN PEs, is
between B-components of PBB-EVPN PE and PBB-VPLS PE per section 4 of between B-components of PBB-EVPN PE and PBB-VPLS PE per section 4 of
[RFC7041]. [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. 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 sets
up a PW to that PE. If it then receives an EVPN IMET route from the up a PW to that PE. If it then receives an EVPN IMET route from the
same PE, then the PBB-EVPN PE MUST bring that PW operationally down. same PE, then the PBB-EVPN PE MUST bring that PW operationally down.
- If a PBB-EVPN PE receives an EVPN IMET route followed by a VPLS A-D - If a PBB-EVPN PE receives an EVPN IMET route followed by a VPLS A-D
route from the same PE, then the PBB-EVPN PE will setup the PW but route from the same PE, then the PBB-EVPN PE will setup the PW but
MUST keep it operationally down. MUST keep it operationally down.
- In case VPLS AD 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 PEs
need to be provisioned manually with PWs to those remote PBB-VPLS PEs need to be provisioned manually with PWs to those remote PBB-VPLS PEs
for each VPN instance. In that case, if a PBB-EVPN PE receives an for each VPN instance. In that case, if a PBB-EVPN PE receives an
EVPN IMET route from a PE to which a PW exists, the PBB-EVPN PE MUST EVPN IMET route from a PE to which a PW exists, the PBB-EVPN PE MUST
bring the PW operationally down. 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 B-MAC
addresses learned over these PWs MUST be injected into the bridge 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- 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 MAC addresses MAY also be injected into the RIB/FIB tables of the
skipping to change at page 11, line 24 skipping to change at page 12, line 41
- The C-MAC addresses learned over local Attachment Circuits (ACs) by - 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- 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 MAC addresses are learned in I-component of PBB-EVPN PEs and they are
not advertised in the control-plane per [RFC7623]. 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.
4.3 MAC Mobility In case of a link failure in a single-active Ethernet Segment, the
PBB-EVPN PEs MUST perform both of the following tasks:
In PBB-EVPN, a given B-MAC address can be learnt either over the BGP a) send a BGP B-MAC withdraw message to the PBB-EVPN peers OR MAC
advertisement with MAC Mobility extended community
b) follow existing VPLS MAC Flush procedures with the PBB-VPLS peers
4.3 MAC Mobility
In PBB-EVPN, a given B-MAC address can be learned either over the BGP
control-plane from a remote PBB-EVPN PE, or in the data-plane over a 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 B-
MAC addresses in this context. Hence, when the same B-MAC address 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
skipping to change at page 12, line 16 skipping to change at page 13, line 41
PBB-VPLS PEs in the same VPN instance. 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] 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 as sub-list C. This list comprises a pruned set of the PWs in the
sub-list B. 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 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 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 this
document leverages the control plane and the data plane procedures document leverages the control plane and the data plane procedures
described in these RFCs. described in these 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 that 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 that of [RFC7432] and
processing of MAC addresses learned over PWs follow that of processing of MAC addresses learned over PWs follow that of
[RFC4761], [RFC4762], and [RFC7080]. [RFC4761], [RFC4762], and [RFC7080].
skipping to change at page 13, line 29 skipping to change at page 15, line 6
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, January 2007, <http://www.rfc- Signaling", RFC 4761, January 2007, <http://www.rfc-
editor.org/info/rfc4761>. editor.org/info/rfc4761>.
[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>.
[RFC7041] Balus et al., "Extensions to VPLS PE model for Provider
Backbone Bridging", RFC 7041, November 2013.
[RFC6074] Rosen et al., "Provisioning, Auto-Discovery, and Signaling [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.
7.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
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 [RFC4684] Marques et al., "Constrained Route Distribution for Border
Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet
 End of changes. 31 change blocks. 
87 lines changed or deleted 115 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/