Internet DRAFT - draft-lin-bess-evpn-bgp-based-l2vpn-seamless-integ
draft-lin-bess-evpn-bgp-based-l2vpn-seamless-integ
BESS W. Lin
Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track B. Wen
Expires: May 4, 2020 V. Kozak
Comcast
J. Rabadan
Nokia
November 1, 2019
EVPN and BGP-based L2VPN Seamless Integration
draft-lin-bess-evpn-bgp-based-l2vpn-seamless-integ-00
Abstract
This document presents a seamless integration solution for BGP-based
Layer-2 VPN (L2VPN) and EVPN to provide point-to-point Virtual
Private Wire Service (VPWS). In addition, this document also extends
the existing seamless integration for multipoint Ethernet VPN service
with all-active multihoming support. The specified solution allows
the coexistence of EVPN and L2VPN services under the same point-to-
point or multipoint VPN instance. By using this seamless integration
solution, a service provider can introduce EVPN into their existing
L2VPN network or migrate from an existing L2VPN based network to
EVPN.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Lin, et al. Expires May 4, 2020 [Page 1]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
This Internet-Draft will expire on May 4, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. L2VPN PE, EVPN PE and Composite PE . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Model of Operation for Seamless Integration of Point-to-point
Ethernet VPN . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Point-to-point Ethernet VPN . . . . . . . . . . . . . . . 6
5.2. Operation Model for Seamless Integration . . . . . . . . 7
5.3. Seamless Integration for Single Homing or Multihoming . . 7
5.4. Control Plane Overview . . . . . . . . . . . . . . . . . 8
5.5. Data Plane Overview . . . . . . . . . . . . . . . . . . . 8
6. Seamless Integration Solution for Point-to-point Ethernet VPN 8
6.1. Local ID and Remote ID . . . . . . . . . . . . . . . . . 9
6.2. Composite PE Control Plane Procedure . . . . . . . . . . 9
6.2.1. Auto-Discovery . . . . . . . . . . . . . . . . . . . 9
6.2.2. Control Plane Signaling . . . . . . . . . . . . . . . 10
6.2.3. Status of an Attachment Circuit . . . . . . . . . . . 11
6.2.4. Layer 2 Extended Community . . . . . . . . . . . . . 11
6.2.5. Port-active Multihoming and DF election . . . . . . . 12
6.2.6. Optimization . . . . . . . . . . . . . . . . . . . . 12
6.3. Composite PE Forwarding Procedure . . . . . . . . . . . . 13
6.4. Composite PE Procedures for All-Active Multi-Homing . . . 15
7. Extended Seamless Integration Solution for Multipoint
Ethernet VPN . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. All-Active Multi-Homing and Seamless Integration for BGP-
VPLS services . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Extensions for MAC Flush . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
Lin, et al. Expires May 4, 2020 [Page 2]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
[RFC6624] specifies a point-to-point L2VPN solution by using BGP
auto-discovery and signaling. This BGP-based L2VPN service may offer
point-to-point service using different types of L2 encapsulation,
such as Ethernet, frame relay, etc., and with single home or active-
standby redundancy.
EVPN VPWS leverages the latest EVPN technology and brings extra
functions to Layer 2 point-to-point Ethernet service, such as all-
active redundancy, load balancing and mass withdrawal. All-active
redundancy also makes it easier to achieve fast convergence on an
access link or node failure.
When expanding an existing L2VPN network with Ethernet encapsulation,
service provider may want to deploy EVPN VPWS to provide additional
Layer 2 point to point Ethernet services, and at the same time some
of the customer traffic may still need to be terminated on the
existing L2VPN PEs within the service provider network.
This document describes a seamless-integration solution that allows
the co-existence of point-to-point Ethernet services using BGP-based
L2VPN procedure per [RFC6624] or EVPN VPWS procedure per [RFC8214]
under the same VPN network and over the same MPLS/IP network.
Service providers may also use the seamless integration solution for
migration a traditional L2VPN network to EVPN VPWS based network.
For the multipoint Ethernet VPN service, [RFC8560] specifies a
seamless integration solution for VPLS and EVPN with single home and
single-active redundancy support. This document extends the seamless
integration solution defined in [RFC8560] with all-active multihoming
support for PEs that can support both VPLS per [RFC4761] and EVPN
procedures. In the extended solution, VPLS [RFC4761] procedure is
used to establish PWs to the rest of VPLS PEs in the same VPN
network. Support for using VPLS [RFC4762] procedure to set up PWs to
the rest of VPLS PEs is outside the scope of this document.
In this document, section 5 and 6 describe the requirements and
operation model for the seamless integration solution for point-to-
point Ethernet VPN. Section 6 covers the solution and procedure in
more detail.
Lin, et al. Expires May 4, 2020 [Page 3]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
The extended seamless integration solution for multipoint Ethernet
VPN is covered in Section 7.
2. Terminology
AC: Attachment Circuit. In EVPN VPWS, an attachment circuit for EVPN
is also referred to as an Ethernet Segment (ES).
L2: Layer 2
VPWS: Virtual Private Wire Service
Point to point: P2P
P2P Ethernet Service: a point-to-point L2 service where the hand-off
between a Provide Edge (PE) and a Customer Edge (CE) is based on L2
Ethernet. In this document a P2P Ethernet service is established
based on control plane procedure specified in this document or EVPN
VPWS [RFC8214] or BGP based L2VPN [RFC6624]. Forwarding is based on
using an MPLS label as the demultiplexer.
L2VPN PE: a PE supports L2VPN services based on the procedures
specified in [RFC6624]
EVPN VPWS PE: a PE supports EVPN VPWS based on the procedures
specified in [RFC8214]. In this document an EVPN VPWS PE may also be
referred to as an EVPN PE for short. An EVPN PE may or may not
support seamless integration solution specified in this document.
BGP VPLS PE: a PE supports VPLS procedure and multipoint Ethernet VPN
service defined in [RFC4761].
Composite PE: In the context of a point-to-point Ethernet VPN, a
composite PE is a PE that can provide seamless integration solution
specified in this document based on both L2VPN procedure per
[RFC6624] and EVPN VPWS procedure per [RFC8214] under the same VPN
instance. In the context of a multipoint Ethernet VPN, a composite
PE is a PE that can provide seamless integration solution based on
[RFC8560] as well as the extended procedure specified in this
document under section 7.
L2VPN Route: a BGP NLRI used for auto-discovery and signaling for
L2VPN per [RFC6624]. [RFC6624], in turns, uses BGP VPLS NRLI defined
in [RFC4761] for L2VPN. Through out this document, the terms "L2VPN
A-D route" and "L2VN route" are used exchangeable.
BGP-VPLS route: a BGP NLRI used for auto-discovery and signaling for
BGP-based VPLS per [RFC4761].
Lin, et al. Expires May 4, 2020 [Page 4]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
EVPN E-AD per EVI Route: an EVPN Ethernet A-D per EVI route used for
auto-discovery and signaling for EVPN VPWS per [RFC8214].
This document does not distinguish between "all-active" and "active-
active" and they are used interchangeably. The same applies to
"single-active" and "active-standby".
This document also uses the terms "P2P Ethernet service" and "VPWS"
interchangeably. For simplicity, this document may refer to a P2P
Ethernet service as a P2P service for short.
This document also makes frequent use of the terminologies specified
in [RFC4761], [RFC6624], [RFC7432] and [RFC8214]
3. L2VPN PE, EVPN PE and Composite PE
There are three types of PEs defined in this seamless integration
solution: L2VPN PE, EVPN PE and composite PE. Under a given Layer 2
Ethernet VPN, the type of PE is categorized by the technology it is
provisioned for. For instance, a PE that is provisioned to use L2VPN
and EVPN on the same VPN service is considered a composite PE. A
L2VPN PE that provides BGP-VPLS service per [RFC4761] is also
referred to as BGP-VPLS or VPLS PE for short.
Also in this document in the context of a given Layer 2 Ethernet VPN,
an EVPN PE is a PE that is provisioned to provide only the EVPN
solution per [RFC8214], or [RFC7432] or both, but not seamless
integration solution. It is irrelevant whether an EVPN PE is capable
to support seamless integration solution.
For example, for a non-L2VPN PE, a network administrator may know
a-priori that the PE does not need to establish any P2P Ethernet
service that involves L2VPN PE under a given Layer 2 Ethernet VPN
instance. In this case, the PE can be provisioned to act only as an
EVPN PE for that VPN even though it is capable of providing seamless
integration procedure. If such a prior knowledge is unavailable,
then a PE SHALL be provisioned to act as a composite PE if it is
capable of. Otherwise, it is unable to establish a P2P Ethernet
service with a L2VPN PE.
The term "homogeneous PEs" refers to PEs that are of the same types.
Unless explicitly specified in this specification, a PE's type
applies to a given Layer 2 Ethernet VPN instance. A PE may act as an
EVPN PE for one VPN, but as a composite PE for another VPN.
Lin, et al. Expires May 4, 2020 [Page 5]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
4. Requirements
The seamless integration solution for point-to-point Ethernet VPN
meets the following requirements:
o It must allow L2VPN, EVPN and composite PEs to participate in the
same Layer 2 Ethernet VPN instance.
o The composite PE, the PE that supports the seamless integration
solution, must be backward compatible to support both EVPN VPWS
and L2VPN when Ethernet is used as the hand-off between the PE and
CE. The composite PE must support the establishment of a layer 2
P2P Ethernet service with a L2VPN PE or an EVPN PE.
o No change should be required for any exiting L2VPN PEs beyond what
are already specified in [RFC6624].
o The seamless integration solution must support a CE single homed
to PEs of different types: L2VPN, EVPN and composite PEs.
o The seamless solution must support active-standby, also known as
single-active, redundancy for L2VPN PEs or EVPN PEs or composite
PEs, as long as PEs connecting to the same multihomed CE are of
the same type.
o Composite PEs provisioned for all-active multihoming for their
multithemed CE(s) MUST work with L2VPN PE(s) working in single
home or active-standby multihoming.
o The solution SHALL support control word forwarding procedure
defined in [RFC4448].
o The solution SHALL support staged migration to EVPN VPWS network
when all L2VPN PEs are upgraded to support EVPN VPWS.
The requirements for the seamless integration solution for multipoint
Ethernet VPN are specified in [RFC8560] and they are also reiterated
in section 7.
5. Model of Operation for Seamless Integration of Point-to-point
Ethernet VPN
5.1. Point-to-point Ethernet VPN
In the seamless integration solution described in this document, PEs
participating in a VPN offer point-to-point Layer 2 connections
between different customer sites, and Ethernet is used as the Layer 2
hand-off between a PE and a CE. Under the seamless integration
Lin, et al. Expires May 4, 2020 [Page 6]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
solution, two different techniques can be used to establish P2P
Ethernet services under the same VPN: some P2P Ethernet services may
use the technique specified per [RFC6624], while others may use the
technique specified per [RFC8214]. [RFC6624] uses the terminology of
"Layer 2 VPN (L2VPN)". [RFC8214] uses the terminology of "Ethernet
VPN (EVPN)". In this document, we refer to a VPN that is capable of
offering Layer 2 Ethernet services by using both L2VPN and EVPN VPWS
technologies as a point-to-point Ethernet VPN.
5.2. Operation Model for Seamless Integration
A PE participating in a point-to-point Ethernet VPN offers P2P
Ethernet services with different remote PEs. By nature of point-to-
point service, there is no requirement for full mesh among all the
PEs participating in the same point-to-point Ethernet VPN instance.
The seamless integration solution allows the coexistence of composite
PE, L2VPN PE and EVPN PE under the same VPN instance. It allows the
establishment of P2P Ethernet services over the same MPLS/IP core:
(a) between two homogenous PEs, or (b) between a composite PE and a
L2VPN PE, or (c) between a composite PE and a EVPN PE.
A composite PE can establish a P2P Ethernet service with a L2VPN PE
and different a P2P service with an EVPN PE. It is the sole
responsibility of a composite PE to seamless integrate with L2VPN PEs
and EVPN PEs.
There will be no P2P service between an EVPN PE and a L2VPN PE in the
same L2 Ethernet VPN as an EVPN PE is provisioned only to provide the
procedure/function per EVPN VPWS.
5.3. Seamless Integration for Single Homing or Multihoming
L2VPN offers single home as well as active-standby multihoming
support, but not active-active multihoming support. Under the
seamless integration solution, a composite PE can integrate with
L2VPN PE(s) working in:
Case 1: single home
Case 2: active-standby multihoming with its peer L2VPN PE(s)
A composite PE supports seamless integration with EVPN PE(s) working
in:
Case 1: single home
Case 2: single-active multihoming with its peer EVPN PE(s)
Lin, et al. Expires May 4, 2020 [Page 7]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
Case 3: all-active multihoming with its peer EVPN PE(s)
While providing seamless integration solution, a composite PE may
provide single home support as well as single-active or all-active
multihoming support support to its locally attached CE.
For single-active multihoming, there are two options that a
multihomed CE may connect to a redundant set of composite PEs:
1. Through a LAG interface while the composite PEs working in a
port-active for single-active multihoming, and the DF or non-DF
role on the composite PE is elected on a per port basis.
2. Through a separate interface to each composite PE working in
single-active multihoming, and the DF or non-DF role on the
composite PE is elected on a per access interface basis.
5.4. Control Plane Overview
In the seamless integration solution, a L2VPN PE continues to use the
standard procedure per [RFC6624] without any change or additional new
procedure. An EVPN PE also continues to use procedure per [RFC8214]
without any change or additional new procedure.
A composite PE follows the seamless integration procedure defined in
this document.
A composite PE uses EVPN VPWS procedure per [RFC8214] to establish a
P2P Ethernet service with an EVPN PE.
5.5. Data Plane Overview
Regardless of the type of a PE, data traffic continues to be carried
over a MPLS/IP tunnel from an ingress PE to an egress PE. At the
egress PE, an MPLS label is used as the demultiplexer to identify the
attachment circuit for a P2P Ethernet service.
6. Seamless Integration Solution for Point-to-point Ethernet VPN
It is the sole responsibility of a composite PE to provide seamless
integration solution with a L2VPN PE. So the focus of the solution
is the composite PE. This section and its sub-sections follow
specify the solution and procedures a composite PE provides.
Lin, et al. Expires May 4, 2020 [Page 8]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
6.1. Local ID and Remote ID
Similar to other PEs, a composite PE is provisioned for the VPN it
participates through Route Target(s) and a Route Distinguisher (RD).
For each P2P Ethernet service, the PE involved is provisioned with a
pair of local and remote IDs. The local ID identifies an local
attachment circuit associated with a P2P service, while the remote ID
identifies an attachment circuit attached to a remote PE.
For a given P2P Ethernet service, a local ID for a PE is the remote
ID for its corresponding remote PE. It is required that that both
PEs involved in a P2P Ethernet service must have a matching pair of
local/remote IDs correspondingly. In the BGP signaling procedure for
auto-discovery, only local ID is signaled in the control plane, but
not remote ID.
In L2VPN, the ID used to identify an attachment circuit associated
with a P2P service is referred to as a VE ID or site ID which is a
16-bit integer. A valid VE-ID for L2VPN is in the range of 1 to
0xFFFE.
In EVPN VPWS, the ID used to identify an attachment associated with a
P2P service is referred as an EVPN VPWS service instance identifier
which is a 24-bit integer. A valid service instance identifier for
EVPN VPWS is in the range of 1 to 0xFFFFFF.
A p2p Ethernet service using L2VPN procedure MUST keep its local/
remote ID within the range of 0x1 to 0xFFFE.
6.2. Composite PE Control Plane Procedure
This section and the sub-sections under it cover the control plane
procedure of a composite PE to interact with other types of PEs.
6.2.1. Auto-Discovery
All three types of PEs defined in this document continue to use MP-
BGP for auto-discovery. An auto-discovery procedure involves two
parts: A PE needs to identify itself for other PEs to discover it,
and a PE needs to auto discover other PEs. Auto-discovery is only
meaningful to PEs participating in the same VPN.
A composite PE needs to identify itself and discover other PE(s)
participating in the same point-to-point Ethernet VPN. If a
composite PE does not know a-priori the type of remote PE for a given
P2P Ethernet service it tries to establish, a composite PE MUST
participate in both L2VPN and EVPN auto-discovery procedures per
Lin, et al. Expires May 4, 2020 [Page 9]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
[RFC6624] and [RFC8214] except in the cases specified in section
6.2.5.
Similar to a L2VPN or EVPN PE, a composite PE uses Route Target
community to identify itself as a part of a point-to-point Ethernet
VPN instance. A composite PE announces itself through both BGP L2VPN
A-D route and EVPN E-AD per EVI route, and with the RT(s) belong to
the VPN it participates. A network operator may choose to use
different RT(s) to identify L2VPN PEs and EVPN PEs participating in
the same VPN. In this case, A composite PE needs to be provisioned
with RTs used by L2VPN PEs and EVPN PEs.
A composite PE discovers other L2VPN PEs by processing L2VPN A-D
routes that have route target(s) matching its import RT(s). At the
same time, a composite PE discovers other EVPN or composite PEs by
processing EVPN E-AD per EVI routes that have the RT(s) matching its
import RT(s).
At the end of discovery procedure, a L2VPN PE discovers all L2VPN PEs
and all composite PEs participating in the same VPN. However a L2VPN
cannot distinguish a L2VPN from a composite PE. From a point of
L2VPN PE, all composite PEs are L2VPN PEs.
Also at the end of discovery procedure, an EVPN PE discovers all EVPN
PEs and all composite PEs participating in the same VPN. Similarly,
an EVPN PE cannot distinguish an EVPN PE from a composite PE. From a
point of EVPN PE, all composite PEs are EVPN PEs.
6.2.2. Control Plane Signaling
In the seamless integration solution, a composite PE relies on MP-BGP
signaling to exchange information for each of its P2P Ethernet
service. A composite PE uses the procedures defined in [RFC6624] and
[RFC8214] for control plane signaling, and by default it originates
both a L2VPN route and an EVPN E-AD per EVI route for each of its P2P
Ethernet service. Note that these are the same routes used for auto-
discovery.
Lin, et al. Expires May 4, 2020 [Page 10]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
+-------------------------------+
Composite PE1 L2VPN PE2
+--------+ +---> <---+ +--------+
| +----+ | VE-ID=1 VE-ID=2 | +----+ |
CE1------+VPWS| | | |VPWS+-----CE2
| +----+ | +---> | +----+ |
+--------+ EthTag=1 +--------+
| |
+-------------------------------+
Figure 1: BGP-L2VPN and EVPN-VPWS integration
As it is shown in Figure 1 above, PE1 is provisioned to be a
composite PE. PE1 originates both L2VPN A-D route with local VE-ID
(1) as well as EVPN E-AD per EVI route with local Ethernet Tag ID (1)
in their corresponding NLRIs. PE2 is a L2VPN PE and it originates a
L2VPN A-D route with a local VE-ID (2) in its NLRI. A p2p Ethernet
service is established between PE1 and PE2 based the L2VPN procedure
per [RFC4761] when both PEs have the matching local/remote VE-IDs.
A composite PE may be optimized to originate either L2VPN route or
EVPN E-AD per EVI route, but not both based on its provisioning
model. Please see section 6.2.6 for detail.
If a CE is multihomed to composite PEs in multihoming mode, each
composite PE also originates an EVPN E-AD per ES route and EVPN
Ethernet segment per [RFC8214].
6.2.3. Status of an Attachment Circuit
A composite PE uses status vector TLV to notify other L2VPN PEs
through its L2VPN route the status of its attachment circuit per . A
composite PE updates the corresponding L2VPN route with an updated
status vector when there is a status change in its attachment
circuit.
A composite PE withdraws its corresponding EVPN E-AD route per
procedure defined in [RFC8214] when its locally attached Ethernet
segment goes down.
6.2.4. Layer 2 Extended Community
A composite PE uses L2VPN info extended community for L2VPN per
[RFC6624]. It shall support L2 encapsulation of type 4 and type 5.
Lin, et al. Expires May 4, 2020 [Page 11]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
A composite PE uses EVPN Layer 2 attribute extended community
specified in [RFC8214] for EVPN, and it attaches the Layer 2 extended
community in the EVPN A-D route it originates.
6.2.5. Port-active Multihoming and DF election
For the seamless migration, it is desirable that a multihomed CE uses
a LAG interface to connect to a redundant set of composite PEs, such
that when L2VPN PE involved in a Layer 2 P2P Ethernet service is
migrated to support EVPN-VPWS, there is no need to touch the
multihomed CE device if at that stage the redundant set of composite
PEs are changed to provide all-active multihoming.
In addition, if the LACP protocol is running for the interface and
while in single-active scenario, it is recommended a non-DF composite
PE sends out-of-sync state for the interface instead of operational
down. To that end, each composite PE is required to play a DF or
non-DF role on a per port basis instead of per VLAN or per (ES, VLAN)
basis.
To support multihomed CE connecting to the composite PEs working in a
single-active multihoming scenario through a LAG interface, each
composite PE must support port-active load-balancing, similar as it
is specified in section 3 of [EVPN-MH-PA] except that a composite PE
must also provide L2VPN functionality per [RFC6624].
Please note that per port DF/non-DF role can be achieved by using one
of the standard based DF election algorithms, as long as the
algorithm can be easily carried out on a per port basis, such as the
preference based DF election when both the ESI and preference are
configured on a per port basis.
Supporting port based single-active multihoming on the composite PEs
with its multihomed CE using LAG interface does not change the
control plane signaling, and it is oblivious to L2VPN PE. Since we
cannot change the behavior of a L2VPN PE, a composite PE will
continue to signal the preference for L2VPN on a per access interface
basis through the Layer 2 extended community alongside its
corresponding L2VPN A-D route. A L2VPN PE continues to carry the DF
election based on its normal L2VPN process.
6.2.6. Optimization
With the simplest provisioning model, if a composite PE does not know
a-priori whether the remote PE for a given P2P service is a L2VPN PE
or an EVPN PE, the composite needs to participate in the auto-
discovery and signaling procedures for both L2VPN and EVPN. This
works well as it allows a composite to establish a P2P service with
Lin, et al. Expires May 4, 2020 [Page 12]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
different types of PEs composite PE, and to switch from using a L2VPN
PW to EVPN VPWS dynamically during the migration process.
The simples provisioning model may not be optimal though, in that a
composite PE originates twice as many A-D routes as they are required
to establish the number of P2P services it is provisioned to.
Therefore in some scenario, it is desirable that a composite PE be
optimized to perform either L2VPN or EVPN VPWS procedure for a given
P2P service, but not both.
For a composite PE, if a Service Provider has the prior knowledge
about the types of remote PEs for some or all of its P2P Ethernet
services, reducing the number of routes a composite PE originates can
be achieved through the configuration. Based on the configuration, a
composite may advertise EVPN route but not L2VPN A-D route for a P2P
Ethernet service, or vice versa. It is up to the Service Provider to
decide based on the network requirement.
6.3. Composite PE Forwarding Procedure
A composite PE supports forwarding procedure defined in [RFC6624] and
[RFC8214].
When a packet arrives at an ingress composite PE, the composite PE
adds a VPN service label based on the AC that packet arrives at, and
it encapsulates the packet and sends it through a tunnel to the
egress PE.
o A composite PE will not forward customer traffic to the L2VPN PE
playing a non-DF role
o If a composite PE detects that two or more EVPN PEs are attached
to the same ES and they are working in all-active mode, it will
load balance the traffic among the EVPN PEs.
o If a composite PE detects that two or more EVPN PEs are attached
to the same ES and they are working in single-active mode, it will
only forward the traffic to the EVPN PE playing a DF role.
o If a set of composites PEs work in all-active multihoming mode for
the same multihomed CE, then regardless of DF or Non-DF role each
composite PE plays, it must forward the packet received from its
multihomed CE to the remote L2VPN DF PE.
o If a composite PE receives both L2VPN and EVPN A-D routes from a
remote PE for the same p2p Ethernet service, the composite should
install forwarding routes in a make-before-break fashion:
Lin, et al. Expires May 4, 2020 [Page 13]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
a. For the traffic coming from the remote PE to its local access
interface direction, to achieve a fast failover, the composite
may install forwarding routes based on both L2VPN and EVPN A-D
routes. However, to save system resource in a scaled setup,
the composite may choose to install only the forwarding route
for the EVPN A-D route and it should do so before it deletes
the forwarding route for the L2VPN A-D route if it was
installed beforehand.
b. For traffic coming from its local access interface to the
remote PE direction, only one route can be installed for the
same local access interface. Forwarding should be based on
the EVPN A-D route. The composite PE should update the
forwarding route in a make-before-break fashion if the
forwarding route for L2VPN A-D route has already been
installed before the processing of the incoming EVPN A-D
route.
o If a composite PE receives both L2VPN and EVPN A-D routes from a
remote PE for the same p2p Ethernet service, and later on the
remote PE is reverted back to a L2VPN only PE and withdraws its
EVPN A-D route, the composite PE should also update the forwarding
route accordingly in a make-before-break fashion:
a. For the traffic coming from the remote PE to its local access
interface direction, if the forwarding route for the L2VPN A-D
route is not there, the composite PE should install the
forwarding route for the L2VPN A-D route before it tears down
the forwarding route for the EVPN A-D route.
b. For the traffic coming from its local access interface to the
remote PE direction, only one route can be installed for the
same local access interface. The composite PE should update
the forwarding route based on the L2VPN A-D route in a make-
before-break fashion.
o Upon reception of an A-D per EVI route and an L2VPN route for the
same P2P service, if both routes match the configured IDs, a
composite PE MUST select the EVPN route and forward the traffic
only to the EVPN PE, and not the L2VPN PE.
When a packet arrives at an egress PE, the VPN service label carried
in the packet is used as the demultiplexer to identify the AC
connecting to the destination CE.
Lin, et al. Expires May 4, 2020 [Page 14]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
6.4. Composite PE Procedures for All-Active Multi-Homing
Two or more Composite PEs MAY be attached to the same All-Active
multi-homed CE and still be seamlessly integrated in an L2VPN
network. This is illustrated in Figure 2.
+------------------------+
+ |
Composite PE11 |
+--------+ +---> |
| +----+ | VE-ID=1 |
+----------+VPWS| | |
| | +----+ | +---> L2VPN PE2
+---+ | +--------+ EthTag=1 +--------+
|CE1+--+ LAG-1 | <---+ | +----+ |
| +--+ | VE-ID=2 | |VPWS+-----CE2
+---+ | Composite PE12 | +----+ |
| +--------+ +---> +--------+
| | +----+ | VE-ID=1 |
+----------+VPWS| | |
| +----+ | +---> |
+--------+ EthTag=1 |
| |
+------------------------+
Figure 2: L2VPN and EVPN-VPWS integration with all-active multi-homed
CEs
In the example of Figure 2, PE11 and PE12 are configured as composite
PEs with the same local CE identifiers. That is, both PEs are
configured with local VE-ID (1) and the same remote VE-ID (2). Also,
both will be configured with the same EVPN local Ethernet Tag (1) and
remote Ethernet Tag (2). As long as PE2 does not become a composite
PE or an EVPN PE, it will not import the A-D per-EVI routes and will
import the L2VPN routes only. PE2 will make a selection to use
either PE11 or PE12 to setup an L2VPN VPWS service.
For example, assuming PE11 is selected, PE2 forwards the traffic
coming from CE2 to PE11 (there is no per-flow load-balancing). In
case of failure, upon receiving the L2VPN rout withdraw from PE11,
PE2 will change its forwarding next-hop to PE12.
In the reverse direction, CE1 will perform per-flow load-balancing to
PE11 and PE12. Both PEs will program their forwarding paths to send
CE1 traffic to PE2.
Lin, et al. Expires May 4, 2020 [Page 15]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
The benefit of this solution is that when PE2 can be upgraded to an
EVPN or composite PE, the P2P service can be migrated to EVPN VPWS
with no changes on CE1 or PE11/PE12.
7. Extended Seamless Integration Solution for Multipoint Ethernet VPN
[RFC8560] specifies how EVPN and VPLS PEs can be seamlessly
integrated into the same network, assuming the VPLS PEs use [RFC4761]
or [RFC4762] procedures to setup the pseudowires to the remote VPLS
PEs or composite PEs. [RFC8560] procedures consider that CEs can be
multi-homed to two VPLS PEs, or to a group of composite PEs in a
single-active or port-active Ethernet Segment. All-active multi-
homing is out of scope.
This specification updates [RFC8560] in case All-Active multi-homing
is used on two or more composite PEs of the same multipoint VPN
service and the composite PEs and VPLS PEs use the BGP-VPLS [RFC4761]
control and data plane procedures. Seamless integration and All-
active multi-homing procedures for [RFC4762] VPLS is out of scope.
This document also updates [RFC8560] to clarify the required MAC
Flush procedures in case single-active/all-active/por-active multi-
homing is used on the composite PEs.
7.1. All-Active Multi-Homing and Seamless Integration for BGP-VPLS
services
All-active Ethernet Segments MAY be used in a VPLS service composed
of composite and BGP-VPLS PEs. Ethernet Segments are an EVPN
construct, hence only supported in composite PEs and not BGP-VPLS
PEs. Figure 3 illustrates an example of the use of All-active
Ethernet Segments and seamless integration between BGP-VPLS and EVPN.
Lin, et al. Expires May 4, 2020 [Page 16]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
+------------------------+
+ |
Composite PE11 BGP VPLS PE2
+--------+ +---> +--------+
| +----+ | <---+ | +----+ |
+----------+EVI | | VE-ID=2 | |VPLS+-----CE2
| | +----+ | | +----+ |
+---+ | +--------+ +--------+
|CE1+--+ LAG-1 | |
| +--+ + +
+---+ | Composite PE12 BGP VPLS PE3
| +--------+ +---> +--------+
| | +----+ | <---+ | +----+ |
+----------+EVI | | VE-ID=3 | |VPLS+-----CE3
| +----+ | | +----+ |
+--------+ +--------+
| |
+------------------------+
Figure 3: BGP-VPLS and EVPN PEs with all-active multi-homing
In Figure 3, the composite PEs will be provisioned for EVPN and All-
active Multi-homing as specified in [RFC7432]. In addition, BGP-VPLS
is enabled on the same services. PE11 and PE12 will therefore
advertise the corresponding EVPN and BGP-VPLS routes. The EVPN
routes are only imported by PE11 and PE12, whereas the BGP-VPLS
routes are imported by all the PEs in the service.
In this case, the PEs MUST follow the procedures in [RFC8560] that
are repeated below for the reader's benefit:
o The composite PEs MUST place their EVPN MP2P service tunnels and
BGP-VPLS PWs in the same Split Horizon Group. I.e., traffic
coming from a BGP-VPLS PW MUST NOT be forwarded to an EVPN tunnel.
o If two composite PEs successfully attempt to setup a BGP-VPLS PW
and an EVPN tunnel, the BGP-VPLS pseudowire will be brought
operationally down.
o The composite PEs will not advertise any MAC/IP routes for MAC
address learned on a BGP-VPLS PW that is part of the Split Horizon
Group assigned to the EVPN tunnels.
In addition, this document updates [RFC8560] so that All-active
multi-homing Ethernet Segments MAY exist in the composite PEs. If an
all-active multi-homing ES is defined in a group of composite PEs,
all the BDs associated to the LAG MUST support and follow the EVPN
multi-homing procedures.
Lin, et al. Expires May 4, 2020 [Page 17]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
If a group of composite PEs work in all-active multihoming and
another group of composite PEs work in single-active, normal EVPN
procedure will be used between these two group of composite PEs.
If a group of composite PEs work in all-active multihoming and remote
BGP-VPLS PEs work in single-active, BGP-VPLS procedure will be used
between composite PEs and BGP-VPLS PEs.
When all-active multi-homing is used, a MAC flip-flopping effect will
exist on the BGP-VPLS PEs. In Figure 3, this effect results in CE1's
MAC moving between two different PWs in PE2 and PE3. E.g., at first
CE1 may hash the traffic to PE11, and PE2 may learn CE1's MAC on its
pseudowire PE2-PE11. Later, if CE1 hashes the traffic (for a
different flow) to PE12, PE2 will move CE1's MAC to its PW PE2-PE12.
This MAC move or "flip-flopping" can happen continuously and may have
harmful consequences for the BGP-VPLS PEs. In some cases, the BGP-
VPLS PEs will consider this to be a loop.
The solution to avoid the MAC "flip-flopping" is based on the support
of "MAC Pinning" on the BGP-VPLS PEs, as follows:
o In Figure 3, the composite PEs and BGP-VPLS PEs will setup their
PWs normally.
o The MAC flip-flopping effect would be avoided by enabling MAC
Pinning on the PE2 and PE3 pseudowires.
o With MAC Pinning enabled, PE2 and PE3 will learn CE1's MAC on only
one PW and will not be relearned in the same or different PW until
the MAC ages out. E.g., consider CE1 hashes the first flow to
PE11 and PE11 forwards to PE2. PE2 learns CE1's MAC on PW
PE2-PE11. Since MAC Pinning is applied on that PW, subsequent
frames arriving at PW PE2-PE12 with CE1's MAC will not trigger a
relearn process on PE2.
MAC Pinning is assumed to be supported by all the BGP-VPLS PEs in the
network, therefore no upgrade is required on the BGP-VPLS PEs to
support this specification.
7.2. Extensions for MAC Flush
Irrespective of the type of multi-homing used on the composite PEs,
in case of a failure on the Ethernet Segment (node or link failure)
the composite PEs MUST indicate the need to flush MAC addresses to
the remote BGP-VPLS PEs.
E.g., in Figure 3, consider CE1's MAC is learned on PW PE2-PE11 (on
PE2). If the link CE1-PE11 fails, PE2 will continue sending the
Lin, et al. Expires May 4, 2020 [Page 18]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
unicast traffic to CE1 using the PW to PE11, and therefore causing a
blackhole until CE1's MAC ages out.
A MAC flush mechanism is required in order to speed up the
convergence in case of ES failures. This requires some extensions to
[RFC8560] and it will be added in future versions.
8. IANA Considerations
This document raises no new IANA request. There is no IANA actions.
9. Security Considerations
This document does not introduce any new security concern. This
document inherits the same security as they are specified in
[RFC6624] and [RFC8214].
10. Acknowledgements
The authors would like to thank Hitesh Mali and Vasu Venkatraman for
their valuable comments and feedbacks. They would also like to thank
John Drake for his review and support.
11. Contributors
In addition to the authors listed, the following individuals also
contributed to this document:
Vinod Prabhu, Nokia
12. References
12.1. Normative References
[EVPN-MH-PA]
Brissette, P., Thoria, S., and A. Sajassi, "EVPN multi-
homing port-active load-balancing", internet-draft draft-
brissette-bess-evpn-mh-pa-04, March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>.
Lin, et al. Expires May 4, 2020 [Page 19]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
<https://www.rfc-editor.org/info/rfc6624>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[RFC8560] Sajassi, A., Ed., Salam, S., Del Regno, N., and J.
Rabadan, "Seamless Integration of Ethernet VPN (EVPN) with
Virtual Private LAN Service (VPLS) and Their Provider
Backbone Bridge (PBB) Equivalents", RFC 8560,
DOI 10.17487/RFC8560, May 2019,
<https://www.rfc-editor.org/info/rfc8560>.
12.2. Informative References
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<https://www.rfc-editor.org/info/rfc4448>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.
Authors' Addresses
Wen Lin
Juniper Networks, Inc.
EMail: wlin@juniper.net
Lin, et al. Expires May 4, 2020 [Page 20]
Internet-DraftEVPN and BGP-based L2VPN Seamless IntegrationNovember 2019
Bin Wen
Comcast
EMail: bin_wen@comcast.com
Voiteck Kozak
Comcast
EMail: voitek_kozak@comcast.com
Jorge Rabadan
Nokia
EMail: jorge.rabadan@nokia.com
Lin, et al. Expires May 4, 2020 [Page 21]
